Cur*_*ous 5 c++ multithreading mutex condition-variable c++11
我在很多地方都读到过与std::condition_variable_any. 只是想知道，这是什么开销？
我的猜测是，由于这是一个可以与任何类型的锁一起使用的通用条件变量，因此它需要手动滚动实现等待（可能使用另一个 condition_variable 和 mutex 或 futex 或类似的东西），因此额外的开销可能来自那？但不确定......而不是仅仅作为本机包装器pthread_cond_wait()（和其他系统上的等价物）等。
作为后续，如果我说实现一些等待的东西，比如共享互斥锁，那么由于性能开销，这种类型的条件变量是一个糟糕的选择吗？在这种情况下我还能做什么？
pthread_cond_wait()/ SleepConditionVariableSRW()，与普通的一样，std::condition_variable::wait()只需要一个原子系统调用来释放互斥锁，等待条件变量并重新获取互斥锁。该线程立即进入睡眠状态，另一个线程（理想情况下被互斥锁阻塞的线程）可以立即接管同一个内核。
使用std::condition_variable_any，解锁传递BasicLockable并开始等待本机事件/条件不仅仅是一个单一的系统调用，它unlock()在第BasicLockable一个调用方法，然后才发出等待的系统调用。因此，您至少有来自单独 的开销，而且unlock()您更有可能在操作系统端触发不太理想的调度决策。最坏的情况是，解锁甚至会导致等待线程在不同的内核上继续运行，并产生所有相关的开销。
反过来，例如在虚假唤醒时，在处理std::mutex不适用于泛型BasicLockable.
两者都涉及一些簿记，以提供notify_all()逻辑（它实际上是每个等待线程的一个事件/条件）以及关于所有方法都是原子的保证，因此无论如何它们都会带来很小的开销。
真正的开销来自操作系统对组合的信号-等待-锁定系统调用做出良好调度决策的能力。如果操作系统在调度方面不聪明，那么它几乎没有区别。