c++ - 与 std::condition_variable_any 相关的开销是多少

Question

我在很多地方都读到过一些与 std::condition_variable_any 相关的开销。只是想知道，这是什么开销？

我的猜测是，由于这是一个通用的条件变量，可以与任何类型的锁一起使用，它需要手动滚动实现等待(可能与另一个 condition_variable 和 mutex 或 futex，或类似的东西)所以额外的开销可能来自于那个？但不确定......而不是仅仅作为 pthread_cond_wait()(以及其他系统上的等价物)等的原生包装器

---

作为后续，如果我说实现等待的东西，比如共享互斥锁，那么由于性能开销，这种类型的条件变量是不是一个糟糕的选择？在这种情况下我还能做什么？

Answer 1

pthread_cond_wait()/SleepConditionVariableSRW()，与普通的 std::condition_variable::wait() 一样，只需要一个，用于释放互斥量、等待条件变量和重新获取互斥量的原子系统调用。该线程立即进入休眠状态，而另一个线程(理想情况下被互斥体阻塞的线程)可以立即接管同一核心。

使用 std::condition_variable_any，解锁传递的 BasicLockable 并开始等待 native 事件/条件不仅仅是一个系统调用，它调用unlock() 方法首先在 BasicLockable 上执行，然后才发出等待的系统调用。所以你至少有来自单独的 unlock() 的开销，而且你更有可能在操作系统端触发一个不太理想的调度决策。最坏的情况是，解锁甚至会导致另一个内核上的等待线程继续运行，并产生所有相关的开销。

相反，例如在虚假唤醒上，在处理不适用于通用 BasicLockable 的 native 互斥锁(如 std::mutex 中所用)时，也可以进行操作系统端调度优化.

两者都涉及一些簿记，以提供 notify_all() 逻辑(它实际上是每个等待线程的一个事件/条件)以及所有方法都是原子的保证，所以它们都来了无论如何，开销很小。

真正的开销来自于操作系统对组合的信号-等待-锁定系统调用做出良好调度决策的程度。如果操作系统在调度方面不智能，那么它几乎没有任何区别。