通用的无锁同步

Posted 2023-02-26

【中文标题】通用的无锁同步

【英文标题】：a generic lock-free synchronization

【发布时间】：2020-05-23 07:06:19

【问题描述】：

无锁数据结构的实现有时并不容易实现。以下方法可能看起来通用且简单，但我认为这里存在一些问题：

private AtomicBoolean lock = new AtomicBoolean(false);

    public void func(...) 
        while !lock.compareAndSet(false,true);
        // Some code goes here...
        ...
        ...
        ...
        lock.set(false); 
    

我认为上面的代码并不是真正的“无锁”，因为它在忙等待模式下锁定了 while 循环中的等待线程。

因此，该代码仅适用于“正确”的无锁同步是不可能的情况。

我的问题是 - 是否有可能用一些不同的方法实现一个通用的无锁，它可以工作，所以线程不会处于阻塞（如同步）或繁忙模式状态，代码将并行运行，所以我们改进性能？

我的目标是保持线程运行。我知道如果代码很长，最好使用同步机制而不是无锁实现，所以我们假设我们在谈论短代码。

例如，下面是 Linkedlist 的示例，我认为这是一个很好的方法，但它不适用于常见的数据结构。 如果我们在这里与上面显示的 AtomicBoolean 一起使用，它将不是真正的“无锁”。

public class LinkedList<T> 

    private AtomicReference<Link<T>> head = new AtomicReference(null);

    public  void add(T data) 
      Link<T> localHead;
      Link<T> newHead = new Link<>(null, data);

      do 
        localHead = head.get();
        newHead.next = localHead;        
       while (!head.compareAndSet(localHead, newHead));
    

【问题讨论】：

你所说的“通用无锁”是什么意思？

@kaya3 我已经用另一种方法为linkedList 更新了我的帖子，这似乎是一个不错的方法，但是如果我们在linkedList 中使用AtomicBoolean 方法，我们将再次处于忙碌等待状态。

您是否正在寻找一种完全通用的方法来获取一段代码，将Atomic 放在几个地方并让生成的代码无锁？

@kaya3 完全正确！

【参考方案1】：

确实有无锁甚至无等待算法的通用构造方案。例如：

A Methodology for Implementing Highly Concurrent Data Structures A highly-efficient wait-free universal construction A Wait-Free Universal Construct for Large Objects

但是，从理论角度来看，这些通常比实际角度更有趣。在实践中，专门的无锁算法通常比从这些通用结构派生的算法执行得更好。

如果您对无锁编程领域感兴趣，我建议您从The Art of Multiprocessor Programming 这本书开始。

【讨论】：

虽然理论上可以回答这个问题，it would be preferable 在这里包含答案的基本部分，并提供链接以供参考。放下4个不同的链接......并不能构成一个真正的答案......

@GhostCat 向 Monica C 致敬。你到底错过了什么？问题是是否存在使算法无锁的通用方法。我确实回答了这个问题（是的，有），有关更多信息，我提到了我所知道的最重要和最新的出版物。我当然不想复制和粘贴这些文章的内容，所以我不确定我应该包含哪些额外信息。

问题在于“是的，有”本身……这对您未来的读者有多大价值？链接到其他地方的答案的重点是......最后，当链接全部断开时，您的答案应该仍然“有效”。问问自己：如果上面的所有链接都被破坏了，你的答案会有多少价值？

我明白你的意思，但即使链接损坏，出版物的标题也应该足以让您使用我们最喜欢的搜索引擎自行找到它。我可以添加其他信息，例如原始作者，以使搜索更容易。但总的来说，这个主题过于广泛和复杂，以至于在一篇简单的文章中包含所有细节，所以我仍然更喜欢参考外部资源。

是的，有人可能会争辩说这个问题本身已经不适合这个地方......