使用锁代替原子内在函数的开销 [英] Overhead of using locks instead of atomic intrinsics

问题描述

有谁知道已发布的锁定开销基准测试，而不是仅依赖于原子操作/内部函数(在多处理器系统上)?

Does anyone know of published benchmarks of the overhead of locking instead of relying on certainly atomic operations/intrinsics (on a multiprocessor system) only?

我对一般结论特别感兴趣，例如类似于无论平台如何，锁定至少比内在函数慢 X 倍".(这就是为什么我不能只对自己进行基准测试.)

I’m particularly interested in general conclusions, e.g. something like "regardless of the platform, locking is at least a factor X slower than intrinsics." (That’s why I can’t just benchmark myself.)

我对直接比较感兴趣，例如使用速度有多快

I’m interested in direct comparisons, e.g. how much faster is using

#pragma omp atomic
++x;

代替

#pragma omp critical
++x;

(假设 x 的所有其他更新也很关键).

(assuming that every other update of x is also critical).

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

Basically, I need this to justify a complex lock-free implementation instead of a straightforward locking one where starvation isn’t an issue. Conventional wisdom is that while locking is simpler, non-locking implementations have tons of advantages. But I’m hard pressed to find reliable data.

推荐答案

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

I don't know where specific studies are, but you are unlikely to find a definitive locks-are-better answer anywhere. It depends very much on how you use them, how much contention they are subject to, and what you are using the primitives for. If all you want to do is increment numbers, then yes, you'll probably find atomic primitives to be faster than locks, but if you want to perform multi-word compare and swap, or complex updates to tree structures, etc., you'll find that the lock-free code is not only much more complex and difficult to debug, but that the performance advantages over a well-designed lock-based implementation are inconclusive at best, and hardly worth the substantial increase in complexity. TANSTAAFL.

这篇关于使用锁代替原子内在函数的开销的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！