qt - MinGW 64(posix 线程版本)中 std::mutex 和 QMutex 的性能

Question

我试图更换 QMutex在我的应用程序(蒙特卡罗模拟)中 std::mutex ，令人惊讶的是，计算速度被除以 3。互斥锁/解锁性能成本从可以忽略不计上升到线程时间的 66% 左右。

我深入研究了实现来源。我最初认为两者都是 Win32 线程的包装器(对于 std::thread 有一个额外的 pthread 层)，但实际上 Qt 没有为互斥体使用任何内核函数，并且有自己的基于原子变量的内部实现。这个好像快多了。

真的有可能完全实现只有原子变量的互斥锁吗？它有限制吗？

为什么这不在 STL 中使用？

在我的情况下，完全避免互斥锁的指导方针是什么？我在多个线程之间共享的浮点缓冲区上累积(加法运算)值

谢谢

Answer 1

Qt is not using any kernel functions for the mutexes, and has its own internal implementation based on atomic variables

当然，如果互斥锁已经锁定，Qt 会调用操作系统让线程等待 .

这里的想法是，在好的多线程代码中，等待已经锁定的互斥锁的机会极低；优化的常见情况是无竞争的互斥锁，它必须尽可能快地保持。

因此，QMutex 是围绕 Linux futex 设计的。系统调用，并使用原子和无锁编程。在无竞争的情况下，不需要系统调用，只需要一些巧妙的原子编程；在有争议的情况下，系统调用是必要的(等待/唤醒线程)，实际上这就是 Qt 使用的:

pthread_mutex_* / pthread_cond_*在通用 Unix 上

futex在 Linux

WaitForSingleObjectEx在 Windows 上

semaphore_*在 Mac 上

有关 QMutex 设计背后的更多信息，请参阅 here .

为什么 STL 不使用类似的方法？我不知道。可能是因为有 native_handle在所有情况下都应该返回“东西”的函数，即使互斥锁被解锁或锁定但没有竞争，所以它总是使用系统调用。

(无论如何，我对 Qt 的表现优于 std::mutex 并不感到惊讶。如果不是，QMutex 将成为 std::mutex 的包装器。)