c++ - 为什么 std::mutex 在 OSX 上这么慢？

Question

我有以下基准:https://gist.github.com/leifwalsh/10010580

本质上，它启动了 k 个线程，然后每个线程执行大约 1600 万/k 锁定/增量/解锁周期，使用自旋锁和 std: :互斥锁。在 OSX 上，std::mutex 在竞争时比自旋锁慢得多，而在 Linux 上它具有竞争力或快一点。

操作系统:

spinlock 1:     334ms
spinlock 2:     3537ms
spinlock 3:     4815ms
spinlock 4:     5653ms
std::mutex 1:   813ms
std::mutex 2:   38464ms
std::mutex 3:   44254ms
std::mutex 4:   47418ms

Linux:

spinlock 1:     305ms
spinlock 2:     1590ms
spinlock 3:     1820ms
spinlock 4:     2300ms
std::mutex 1:   377ms
std::mutex 2:   1124ms
std::mutex 3:   1739ms
std::mutex 4:   2668ms

处理器不同，但不是不同(OSX 是 Intel(R) Core(TM) i7-2677M CPU @ 1.80GHz，Linux 是 Intel(R) Core(TM) i5- 2500K CPU @ 3.30GHz)，这似乎是一个库或内核问题。有人知道缓慢的根源吗？

为了澄清我的问题，我知道“有不同的互斥体实现可以针对不同的事物进行优化，这不是问题，这是意料之中的”。这个问题是:导致这种情况的实际实现差异是什么？或者，如果这是硬件问题(也许 macbook 上的缓存速度慢很多)，那也是可以接受的。

Answer 1

您只是在衡量图书馆为公平而牺牲吞吐量的选择。该基准在很大程度上是人为的，并且会惩罚任何提供任何公平性的尝试。

实现可以做两件事。它可以让同一个线程连续两次获得互斥锁，也可以改变哪个线程获得互斥锁。该基准测试严重惩罚线程中的更改，因为上下文切换需要时间，而且互斥锁和 val 从缓存到缓存需要时间。

很可能，这只是展示了实现必须做出的不同权衡。它会大力奖励更愿意将互斥锁还给最后持有它的线程的实现。基准测试甚至奖励浪费 CPU 的实现!它甚至奖励那些浪费 CPU 以避免上下文切换的实现，即使 CPU 可以做其他有用的工作!它也不会惩罚可能减慢其他不相关线程的核心间流量的实现。

此外，实现互斥锁的人通常认为无竞争情况下的性能比有竞争情况下的性能更重要。您可以在这些情况之间做出许多权衡，例如假设可能有一个线程在等待或专门检查是否有。基准测试仅(或至少，几乎仅)测试通常为了支持假设更常见的情况而权衡的情况。

说白了，这是一个没有意义的基准测试，无法识别问题。

具体解释几乎可以肯定，Linux实现是spinlock/futex混合体，而OSX实现是常规的，相当于锁定了一个内核对象。 Linux 实现的自旋锁部分倾向于允许刚刚释放互斥锁的同一个线程再次锁定它，您的基准测试对此给予了很大的返回。