使用锁而不是原子内在函数的开销

Question

有没有人知道已发布的锁定开销基准，而不是仅仅依赖于原子操作/内在函数（在多处理器系统上）？

我对一般结论特别感兴趣，例如：类似“无论平台如何，锁定至少比内在因素慢十倍。”（这就是为什么我不能仅仅自我测试。）

我对直接比较感兴趣，例如使用

的速度有多快

#pragma omp atomic
++x;

而不是

#pragma omp critical
++x;

（假设x的每次更新都很关键。）

基本上，我需要这个来证明一个复杂的无锁实现，而不是一个直接的锁定，其中饥饿不是问题。传统观点认为，虽然锁定更简单，但非锁定实现具有许多优点。但我很难找到可靠的数据。

Answer 1

我不知道具体的研究在哪里，但你不可能在任何地方找到明确的锁定 - 更好的答案。这在很大程度上取决于你如何使用它们，它们受到多少争用，以及你使用这些原语是什么。如果您只想增加数字，那么是的，您可能会发现原子基元比锁更快，但是如果您想要执行多字比较和交换，或者对树结构进行复杂更新等，那么会发现无锁代码不仅复杂得多且难以调试，而且与精心设计的基于锁的实现相比，性能优势最多也是不确定的，并且几乎不值得大幅增加复杂性。 TANSTAAFL。

Answer 2

  

我对一般情况特别感兴趣   结论，例如就像是   “无论平台如何，锁定   至少比X慢一个因子X.   内部函数“。

我担心没有一般性结论，因为这个问题与架构师的原子指令设计，缓存布局和内存总线有关。这些可能在x86和MIPS之间有很大差异。您可以对可能使用的架构师进行基准测试，并进行比较。锁的设计可能会对基准产生很大的影响，所以即使您找到报告，也不应该简单地相信。

Answer 3

MS为.NET 4中的新并发集合类做了一些基准测试。

http://blogs.msdn.com/b/pfxteam/archive/2010/04/26/9997562.aspx

不是C / C ++，但基本原则是相同的：使用平台CAS /互锁操作而不是锁定在哪里。

Cliff Click也在他的无锁哈希表上有一些基准测试： http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf

尽管如此，使用无锁方法与锁定的性能增益（或丢失）在很大程度上取决于算法和确切的用例。

Answer 4

这类问题的答案非常复杂：无锁代码经常旋转而不是等待争用，因此在高争用情况下，如果线程刚刚阻塞自身，可能会显着慢在一个锁后面的队列中。此外，无锁代码仍然会花费大量时间发布内存障碍，因此可能在不同硬件和不同平台上具有意外的性能特征。

因此，对性能问题的旧备用答案再次出现：在您的情况下测量它们，并选择更快的答案。

  

基本上，我需要这个来证明一个复杂的无锁实现，而不是一个直接锁定饥饿不是问题的实现。

嗯，总而言之，除非这个数据结构处于大规模多线程应用程序的绝对中心，否则我会使用基于锁的解决方案，尽可能少的锁。这些错误将更容易找到，这将是值得的。在涉及线程的地方，我个人发现很难证明任何类型的复杂实现，无锁或其他。