使用无锁编程深层次的高级抽象不受欢迎的原因是什么？

Question

从我在锁定免费编程中收集的信息来看，这是非常难以做到的......我同意。 只是想一些问题会让我头疼。但我想知道的是，为什么不是 广泛使用高级包装（例如锁定免费队列和类似的东西）？ 例如，boost没有锁定免费库，但据我所知，有人建议使用。 我的意思是我猜有很多应用程序，你不能避免关键的事实 部分是负载的重要部分。那么原因是什么？是吗......

1. 专利 - 我听说有些与无锁编程有关的东西已获得专利。
2. 性能。
3. Google和微软都有这样的内部库，但没有一个是公开的......
4. 别的什么？

所以我的问题是：为什么使用无锁编程的高级抽象不是很深入 流行，而同时“常规”多线程编程是“在”？

编辑：boost获得了一个无锁lib：）

Answer 1

很少有人熟悉该领域以实现易于使用的无锁库。在这些少数人中，免费的发布工作甚至更少的发布工作都是使图书馆可用的重要额外工作 - 例如发布完整的API文档等。他们倾向于只发布一个包含代码的zip文件，这几乎是无用的。当然，你还需要找到一个用你想要使用的语言编写的库，在你正在使用的平台上编译，最后，图书馆的文字必须出来，所以人们都知道它存在。

专利是一个问题，因为它们限制了可以提供的东西。例如，据我所知，没有非专利的单链表。所有跳过列表的东西也都获得了大量专利。

这个领域的英雄是Cliff Click，他提出了一个无锁的哈希，他或多或少地置于公共领域。

你可以在这里找到我的无锁图书馆;

http://www.liblfds.org

另一个是Samy Bahra的Concurrency Kit;

http://www.concurrencykit.org

Answer 2

仅供参考。微软的.Net框架在.Net 4.0中获得了一些无锁类。即System.Collections.Concurrent命名空间中的容器类，它们是：

ConcurrentDictionary
ConcurrentQueue
ConcurrentStack

我已经研究了它们的实现，它们相对繁琐/复杂，因此它们确实代表了设计和测试方面的大量工作（线程问题当然非常难以测试到高标准）。 / p>

Answer 3

您可以查看libcds C ++库。它是无锁容器（堆栈，队列，集合和映射）和安全内存回收算法的集合。

关于C ++的恕我直言（我在其他语言中没有进步）。新的C ++标准刚刚发布，编译器开发人员需要时间来实现其需求。今天，所有编译器都不完全支持C ++ 11内存模型，因为它需要对编译器的优化规则进行重大更改。最近，微软宣布支持原子操作，这是VC ++ 11 Developer Preview中无锁编程的基础。这对我们来说是个好消息。据我所知，海湾合作委员会将在4.8（或以上）支持它。

第二个问题是专利。许多有趣的无锁容器算法已获得专利，这是将它们包含在供应商库中的障碍。

第三，无锁容器的主要部分是垃圾收集（安全内存回收）。 C ++不受任何GC的影响（幸运的是）。有一些GC算法（危险指针，传递降压，基于纪元的等等），但大多数也是专利。

第四，没有足够的工具来证明在无锁实现中应用的内存栅栏的正确性。现在我只知道一个 - relacy（http://www.1024cores.net/home/relacy-race-detector）。

我认为在2 - 3年后，我们将看到许多生产就绪的多平台C ++库，包括无锁容器和算法。这些库由供应商和爱好者开发。

但是，在我看来，我们的未来是硬件交易记忆（HTM）。今天AMD，Sun（对不起，甲骨文），英特尔（？）正在研究HTM，结果非常有趣。我们等一下。

Answer 4

一个主要问题是，除非使用过多的记忆障碍，否则很难确定一个人有足够的记忆障碍;如果确实使用了过多的内存屏障，性能可能会低于使用锁的性能。

锁的最大问题不是性能，而是稳健性。如果一个线程在持有锁定时被移动，系统就会死掉。相反，如果访问无锁数据结构的线程得到了格式化，它将不会影响其他线程的使用。在某些情况下，无锁数据结构可能优于使用锁定的数据结构，即使性能较差，因为必须保护系统不被故障线程关闭（例如，甚至如果一个人准备杀死一个没有取下进程的StackOverflowException的线程，那么在调用一个方法来访问一个锁定保护的数据结构之前，如何防止一个线程将很多东西放在它的堆栈上，如果锁定保护的方法遇到堆栈溢出？）如果使用无锁数据结构，这样的风险不是问题。

Answer 5

至少有一个“无锁”框架有点流行：Erlang。