与无争议的原子变量（例如std::atomic<T>C++）操作。
另外，有争议的原子变量相对于无争议的锁慢了多少？
我正在研究的架构是x86-64。
我碰巧有很多低级速度测试。然而，速度到底意味着什么是非常不确定的，因为它很大程度上取决于你到底在做什么（甚至与操作本身无关）。
以下是 AMD 64 位 Phenom II X6 3.2Ghz 的一些数据。我还在英特尔芯片上运行过这个程序，时间确实有很大差异（同样，具体取决于正在做什么）。
A GCC __sync_fetch_and_add，这将是一个完全隔离的原子添加，平均时间为 16 纳秒，最短时间为 4 纳秒。最短时间可能更接近事实（尽管即使如此我也有一些开销）。
无竞争的 pthread 互斥体（通过 boost）为 14ns（这也是其最小值）。请注意，这也有点太低了，因为如果其他东西锁定了互斥体，时间实际上会增加，但现在并非没有争议（因为它会导致缓存同步）。
失败的try_lock需要9ns。
我没有普通的旧原子公司，因为在 x86_64 上这只是一个正常的交换操作。可能接近最短可能时间，即 1-2ns。
在没有服务员的情况下对条件变量调用notify需要25ns（如果有东西正在等待大约304ns）。
然而，由于所有锁都会导致某些 CPU 顺序保证，因此您修改的内存量（无论适合存储缓冲区的内容）将改变此类操作所需的时间。显然，如果您对互斥锁发生争用，那是您最糟糕的时刻。即使实际上没有发生线程切换，任何返回 Linux 内核的时间也可能需要数百纳秒。这通常是原子锁表现优异的地方，因为它们不涉及任何内核调用：您的平均情况性能也是最坏的情况。如果有等待线程，互斥锁解锁也会产生开销，而原子则不会。
注意：进行此类测量充满了问题，因此结果总是值得怀疑的。我的测试尝试通过固定 CPU 速度、设置线程的 CPU 关联性、不运行其他进程以及对大型结果集进行平均来最小化变化。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
