这种开销是否仅在函数包装器调用和互斥锁函数需要“设置”futex (即基本上是为 pthread 互斥锁函数调用设置堆栈)时发生?或者 pthread 互斥锁中是否存在一些额外的内存屏障步骤?
Futexes是为了提高pthread mutexes的性能而创建的。NPTL使用futexes,而LinuxThreads早于futexes,这就是"较慢"考虑的原因所在。NPTL互斥锁可能会有一些额外开销,但不应该很大。
编辑: 实际开销主要包括:
因此,一些周期(典型情况)到几个周期 + 分支误判 + 附加缓存未命中(非常糟糕的情况)。
int
条件下)时,它真正有用的地方在于,它更加时间和空间有效,并且避免了 POSIX 的陷阱,即某人可以使用不同的 mutex 来等待条件。 - Jens Gustedt从技术上讲,pthread互斥锁与futex的速度没有快慢之分。pthread只是标准API,因此它们是快还是慢取决于该API的实现。
特别是在Linux中,pthread互斥锁是以futex的形式实现的,因此非常快速。实际上,您不希望直接使用futex API,因为它很难使用,在glibc中也没有适当的封装函数,并且需要编写汇编代码,这将使其不可移植。幸运的是,glibc维护者已经在pthread互斥锁API的底层为我们编写了所有这些内容。
现在,由于大多数操作系统没有实现futexes,因此程序员通常意味着pthread互斥锁是从常规pthread互斥锁实现中获得的性能,这是较慢的。
因此,统计事实上,在大多数符合POSIX标准的操作系统中,pthread互斥锁在内核空间中实现,并且比futex慢。在Linux中,它们的性能相同。可能有其他操作系统在用户空间(在未竞争情况下)中实现pthread互斥锁,因此具有更好的性能,但我目前只知道Linux。
futex
和当前macOS中的__psync_mutexdrop/wait
API是特殊的API,顺便说一句,但我没有看到你提出的任何论点阻止了在10.10之前的macOS中看到的方法。 - al45tair简单回答你的问题,即futex已知其实现尽可能高效,而pthread mutex可能会有或可能没有。 至少pthread mutex具有确定mutex类型的开销,而futex则没有。 因此,除非有人想出比futex更轻的结构,然后发布一个使用该结构作为默认mutex的pthread实现,否则futex几乎总是至少与pthread mutex一样有效。