与无争议的原子变量（例如 C++ 的 std::atomic<T>）操作相比，它的速度快/慢多少。
另外，有争议的原子变量相对于无争议的锁要慢多少？
我正在研究的架构是 x86-64。
【问题讨论】：
标签： c++ multithreading performance x86-64 thread-synchronization
我碰巧有很多低级速度测试。然而，速度究竟意味着什么是非常不确定的，因为它在很大程度上取决于你到底在做什么（甚至与操作本身无关）。
以下是 AMD 64 位 Phenom II X6 3.2Ghz 的一些数字。我也在英特尔芯片上运行过它，而且时间确实有很大差异（同样，具体取决于正在做的事情）。
GCC __sync_fetch_and_add 是一个完全隔离的原子加法，平均为 16ns，最短时间为 4ns。最短时间可能更接近事实（尽管我有一点开销）。
一个无争议的 pthread 互斥体（通过 boost）是 14ns（这也是它的最小值）。请注意，这也有点太低了，因为如果其他东西锁定了互斥体，但它现在不是无争议的（因为它会导致缓存同步），时间实际上会增加。
一个失败的 try_lock 是 9ns。
我没有一个普通的旧原子公司，因为在 x86_64 上这只是一个正常的交换操作。可能接近最小可能时间，所以 1-2ns。
在没有服务员的情况下对条件变量调用 notify 是 25ns（如果有东西在等待大约 304ns）。
然而，由于所有锁都会导致某些 CPU 排序保证，因此您修改的内存量（存储缓冲区中适合的内存量）将改变此类操作所需的时间。很明显，如果您曾经对互斥锁发生争用，那是您最糟糕的时刻。即使实际上没有发生线程切换，任何返回到 linux 内核的时间都可能是数百纳秒。这通常是原子锁表现不佳的地方，因为它们不涉及任何内核调用：平均情况下的性能也是最差的情况。如果有等待线程，互斥锁解锁也会产生开销，而原子则不会。
注意：进行此类测量充满了问题，因此结果总是有问题。我的测试尝试通过固定 CPU 速度、设置线程的 cpu 亲和性、不运行其他进程以及对大型结果集进行平均来最小化变化。
【讨论】：
xchg（即使它有一个隐含的lock 前缀）。 lock add [mem], 1 在大多数 CPU 上几乎与 lock xadd [mem], eax 一样昂贵，只是稍微简单一些。它肯定不会像 1ns（3GHz CPU 上的 3 个时钟）那么快，lock 前缀的完整障碍不会阻止非内存指令的乱序执行。 Agner Fog 的指令表没有来自 K10 的 lock 数字，但 Piledriver lock add 是每 ~40 个周期一个（与 xchg [mem],reg 相同），而 lock xadd 是每 ~39 个周期一个。
有一个project on GitHub，目的是在不同平台上衡量这一点。不幸的是，在我的硕士论文之后，我从来没有真正有时间跟进这个，但至少基本代码在那里。
与 __sync_fetch_and_add 内在函数相比，它测量 pthread 和 OpenMP 锁。
据我记忆，我们预计锁和原子操作之间会有相当大的差异（〜一个数量级），但实际差异却非常小。
但是，现在在我的系统上测量得到的结果反映了我最初的猜测，即（无论使用 pthread 还是 OpenMP）原子操作的速度大约快五倍，单个锁定增量操作大约需要 35ns（这包括获取锁，执行增量，释放锁）。
【讨论】：
lock add [mem], 1 都非常快。但无论如何，很难进行微基准测试，因为在某些 ISA 上，弱排序的原子增量（如 std::memory_order_relaxed）避免了内存屏障，其成本取决于可能有多少 other 加载/存储正在飞行中，无法重新订购。
取决于锁的实现，也取决于系统。原子变量不能以与锁相同的方式真正受到竞争（即使您使用的是acquire-release semantics），这就是原子性的全部意义，它锁定总线以传播存储（取决于内存屏障模式），但这是一个实现细节。
但是，大多数用户模式锁只是封装了原子操作，请参阅 Intel 的 this 文章，了解有关在 x86 和 x64 下使用原子操作的高性能、可扩展锁的一些数据（不幸的是，与 Windows 的 CriticalSection 锁相比） ，找不到SWR 锁的统计信息，但应始终针对自己的系统/环境进行分析。
【讨论】：