为什么pthread mutex被认为比futex“慢”？

Question

为什么POSIX互斥量被认为比futex更重或更慢？ pthread互斥锁类型的开销来自哪里？我听说pthread互斥体基于互斥体，当无争议时，不要对内核进行任何调用。那时似乎pthread互斥体只是一个围绕futex的“包装”。

开销是否只是在函数包装调用中，并且需要互斥函数来“设置”futex（即，基本上是pthread互斥函数调用的堆栈设置）？或者使用pthread互斥锁进行一些额外的内存屏障步骤？

Answer 1

创建Futex以提高pthread互斥锁的性能。 NPTL使用futexes，LinuxThreads早于futexes，我认为这是“慢”考虑的地方。 NPTL互斥体可能会有一些额外的开销，但它不应该太多。

修改 实际开销基本上包括：

• 为互斥锁类型选择正确的算法（正常，递归，自适应，错误检查;正常，健壮，优先级继承，优先级保护），其中代码严重提示编译器我们可能使用正常互斥（因此它应该将其传达给CPU的分支预测逻辑），
• 并写一个互斥锁的当前所有者，如果我们设法接受它通常应该很快，因为它与我们刚刚采用的实际锁定位于同一个缓存行中，除非锁定很严重和其他一些CPU在我们接受它的时间和我们尝试编写所有者之间访问锁（对于普通的互斥锁，这个写操作是不需要的，但是需要用于错误检查和递归互斥锁）。

因此，几个周期（典型情况）到几个周期+分支错误预测+额外的缓存未命中（非常糟糕的情况）。

Answer 2

对您的问题的简短回答是，已知futexes尽可能高效地实现，而pthread互斥量可能是也可能不是。至少，pthread互斥锁具有与确定互斥锁类型相关的开销，而互斥锁则没有。因此，futex几乎总是至少与pthread互斥锁一样有效，除非有人认为某些结构比futex更轻，然后发布一个pthreads实现，将其用于默认的互斥锁。

Answer 3

因为它们尽可能地留在用户空间中，这意味着它们需要更少的系统调用，这本身就更快，因为用户和内核模式之间的上下文切换很昂贵。

当你谈到POSIX线程时，我假设你正在谈论内核线程。完全可能有一个POSIX线程的完全用户空间实现，它不需要系统调用，但有其他问题。

我的理解是，futex位于内核POSIX线程和用户空间POSIX线程之间。

Answer 4

从技术上讲，pthread互斥量并不比futex更慢或更快。 pthread只是一个标准API，因此它们是慢还是快取决于该API的实现。

特别是在Linux中，pthread互斥体实现为futexes，因此很快。实际上，您不想使用futex API本身，因为它很难使用，在glibc中没有适当的包装函数，并且需要在汇编中进行编码，这是不可移植的。幸运的是，glibc维护者已经在pthread互斥API的引擎下为我们编写了所有这些内容。

现在，因为大多数操作系统没有实现futexes ，所以程序员通常用pthread mutex来表示你从pthread互斥体的常规实现中获得的性能，这是较慢的。

因此，统计事实是，在大多数符合POSIX标准的操作系统中，pthread互斥锁在内核空间中实现，并且比futex慢。在Linux中，它们具有相同的性能。可能有其他操作系统在用户空间中实现了pthread互斥（在非竞争情况下），因此具有更好的性能，但我现在只知道Linux。

Answer 5

在AMD64上，futex是4个字节，而NPTL pthread_mutex_t是56个字节！是的，有很大的开销。