c++ - 是否将 unique_lock 用于可以由 lock_guard 完成的任务较慢？

Question

我对存在的原因感到困惑lock_guard。是吗：

1. 比 ? 更简单的界面unique_lock？
2. 性能比unique_lock?
3. 还有什么？

Answer 1

lock_guard可以用一个状态单元来实现：指针或指向Mutex它已锁定的类型的引用。

unique_lock必须保持该状态，并知道它当前是否已锁定，因为 aunique_lock可以有Mutex未锁定的。这意味着它必须至少有一个bool额外的状态。

lock_guard围绕获取和释放Mutex. 基本上这lock_guard意味着没有理由避免使用 RAII 来处理Mutex.

unique_lock如果可以说服编译器注意到您仅以可以使用的方式使用它lock_guard（即构造它，然后销毁它，而不摆弄它），则只能达到零开销。

除了这些效率参数之外，看到 a 的程序员lock_guard知道它将持续到范围结束，而无需检查范围内的代码。unique_lock看到必须检查变量的所有使用以了解是否是这种情况的程序员。

但以上只是一半的原因。

另一半的原因是因为 C++11 的大部分线程库是基于boost库的，这些库已经实现了一个主要独立于平台的线程库。Boost 同时具有lock_guard和unique_lock，其语义与 C++11 版本几乎相同。

所以当boost线程库标准化的时候，都被带进去了，没有人把它们淘汰掉。

Answer 2

您几乎在这里回答了您自己的问题 - 1) 和 2) 都是很好的理由。std::lock_guard是一个简单的作用域锁定对象。互斥体获取超时等特性增加了互斥体原语的复杂性，增加了执行操作所需的时间和互斥体争用的可能性。那么，为什么要为不需要的东西付费呢？

带有或不带有超时的“try_locking”是否是好的设计是另一个问题；就像线程取消一样，C++11 没有实现的破坏设计。