从我在无锁编程中收集到的信息来看，要正确地做是非常困难的……我同意。光是想一些问题就头疼。但我想知道的是，为什么没有广泛使用高级包装器（例如无锁队列和类似的东西）？例如 boost 没有无锁库，尽管据我所知有人建议。我的意思是我猜有很多应用程序无法避免关键部分是负载的很大一部分这一事实。那么有哪些原因呢？是吗...
所以我的问题是：为什么使用无锁编程的高级抽象不是很流行，而同时“常规”多线程编程是“in”？
编辑：boost 有一个无锁库 :)
很少有人对该领域足够熟悉来实现易于使用的无锁库。在这少数甚至更少的免费发布工作中，几乎没有人做重要的额外工作以使库可用- 例如发布完整的 API 文档等。他们倾向于只发布一个包含代码的 zip 文件，这几乎是无用的. 然后当然你还需要找到一个用你想要使用的语言编写的库，在你使用的平台上编译，最后，这个库的词必须出去，所以人们知道它存在。
专利是一个问题，因为它们限制了可以提供的内容。例如，据我所知，没有未获得专利的单链表。所有跳过列表的东西也都获得了大量专利。
这个领域的英雄是 Cliff Click，他提出了一个无锁哈希，他或多或少地将其置于公共领域。
你可以在这里找到我的无锁库；
另一个是 Samy Bahra 的并发工具包；
仅供参考 Microsoft 的 .Net 框架在 .Net 4.0 中获得了一些无锁类。即 System.Collections.Concurrent 命名空间中的容器类，它们是：
ConcurrentDictionary
ConcurrentQueue
ConcurrentStack
我研究了它们的实现，它们在引擎盖下相对繁琐/复杂，因此它们确实代表了设计和测试方面的大量工作（众所周知，线程问题很难以高标准进行测试）。
您可以查看libcds C++ 库。它是无锁容器（堆栈、队列、集合和映射）和安全内存回收算法的集合。
恕我直言，关于 C++（我对其他语言并不先进）。新的 C++ 标准刚刚发布，编译器开发人员需要时间来实现其要求。如今，并非所有编译器都完全支持 C++11 内存模型，因为它需要对编译器的优化规则进行重大更改。最近，Microsoft 宣布支持原子操作，这是 VC++ 11 Developer Preview 中无锁编程的基础。这对我们来说是个好消息。据我所知，GCC 将在 4.8（或更高版本）中支持它。
第二个问题是专利。许多有趣的无锁容器算法都获得了专利，这是将它们包含到供应商库中的障碍。
第三，无锁容器的主要部分是垃圾收集（安全内存回收）。C++ 没有任何 GC（幸运的是）。有一些 GC 算法（Hazard Pointer、Pass-the-Buck、epoch-based 等），但其中大多数也获得了专利。
第四，没有足够的工具来证明在你的无锁实现中应用的内存栅栏的正确性。现在我只知道一个——relacy (http://www.1024cores.net/home/relacy-race-detector)。
我认为 2-3 年后，我们将看到许多生产就绪的多平台 C++ 无锁容器和算法库。这些库是由供应商和爱好者开发的。
但是，在我看来，我们的未来是硬件事务存储器（HTM）。今天 AMD、Sun（对不起，Oracle）、英特尔（？）正在研究 HTM，结果非常有趣。我们等等吧。
至少有一个“无锁”框架有点流行：Erlang。
一个主要问题是，除非使用过多的内存屏障，否则很难确定是否有足够的内存屏障。如果确实使用了过多的内存屏障，则性能可能会不如使用锁所获得的性能。
锁最大的问题不是性能，而是健壮性。如果一个线程在持有锁时被阻塞，系统就会死掉。相反，如果一个正在访问无锁数据结构的线程被阻塞，它不会影响其他线程的使用。在某些情况下，无锁数据结构可能比使用锁的数据结构更可取，即使性能较差，因为必须保护系统不被故障线程关闭（例如，即使一个人准备在不关闭进程的情况下杀死一个遇到 StackOverflowException 的线程，如何防止一个线程放置大量在调用方法以访问该方法的受锁保护的数据结构之前，先将其堆栈中的内容，以使受锁保护的方法遇到堆栈溢出？）如果使用无锁数据结构，则不存在此类风险。