具有等级操作的无锁跳过列表答案

【问题标题】：lock-free skiplist with rank operation具有等级操作的无锁跳过列表
【发布时间】：2012-02-03 18:58:10
【问题描述】：

是否有人知道任何支持排名操作（即查找第 k 个元素）的无锁跳过列表实现和/或研究论文？或者，是否有人知道这种操作永远无法奏效的根本原因？

奖励积分：

不假设垃圾收集的实现。根据我的经验，很多研究论文都忽略了内存管理。

支持：

有关如何在常规跳过列表中完成排名操作的描述：William Pugh 的“跳过列表食谱”

关于更好的无锁跳过列表描述之一：Keir Fraser 的“Practical lock-freedom”

更好的无锁跳过列表实现之一：http://www.1024cores.net/home/parallel-computing/concurrent-skip-list

【问题讨论】：

标签： concurrency lock-free skip-lists

【解决方案1】：

与key、value和level不同，它们是skiplist中元素的局部属性，不受与其他元素的操作影响, rank 元素的，即它在列表中的位置，是一个随着插入和删除较低级别的元素而变化的属性。因此，对于一个并发的跳过列表，一个元素的排名是非常短暂的，因为它可能在任何时刻被同时运行的插入或删除较低排名元素的操作改变。

例如，假设您通过 1 级列表对第 k 个元素进行线性搜索。在您执行 k 步骤的那一刻，并发修改可能会添加或删除任意数量的先前元素，因此您刚刚找到的元素的当前排名实际上是未知的。此外，当线程执行 k 次前向迭代时，可以在其当前位置和开始搜索时第 k 次的元素之间进行并发更改。因此，搜索结束的既不是当前排名为 k 的元素，也不是搜索开始时排名为 k 的元素。这只是一些随机元素！

简而言之，对于并发列表，元素的排名是一个定义不明确的概念，按排名搜索是一个定义不明确的操作。这是它永远无法工作的根本原因，也是实现者永远不应该费心提供此类操作的根本原因。

【讨论】：

我想我明白你在说什么，但我认为你在更新每个级别的节点的“下一个”指针时遇到同样的困难。对于插入操作，插入节点的前驱节点的“下一个”指针都需要更新，以保持跳过列表的属性。假设排名存储在每个节点中，那么需要更新“下一个”指针的节点也需要更新它们的排名。对我来说真正的困难似乎是需要多字比较和交换来更新排名和“下一个”指针。
如果 rank 是一个节点在列表中的位置，那么当插入一个新项目时，不仅应该设置它的 rank，而且应该更新列表中所有后续节点的所有 rank。
当然，我说错了。我的意思是每个节点存储它在每个级别跳过的节点数。我相信这个数字可以在更新前任的“下一个”指针的同时更新。
但是，你怎么知道每个级别跳过了多少节点？搜索位置时会记录每个级别要更新的先前节点，但是您无法正确计算该位置距该位置的距离，因为可能同时插入或删除了一些节点。