问是否将unique_lock用于lock_guard可以较慢地完成的任务？

EN

lock_guard可以用一个状态单位来实现:一个指针或对它锁定的Mutex类型的引用。

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

lock_guard为获取和释放Mutex提供了零开销的RAII锁/解锁包装器。基本上，lock_guard意味着没有理由避免使用RAII来处理Mutex上的锁。

只有当编译器确信您只使用lock_guard时才能达到零开销(即，构造它，然后销毁它，而不修改它)。

除了这些效率参数之外，一个看到lock_guard的程序员知道，它将持续到作用域的末尾，而不必检查范围中的代码。看到unique_lock的程序员必须检查变量的所有使用情况，以确定是否是这种情况。

但以上只是原因的一半。

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

因此，当boost线程库标准化时，无论是在哪里，都没有人消除它们。

你几乎在这里回答你自己的问题- 1)和2)都是很好的理由。守卫是一个简单的作用域锁定对象。互斥对象获取超时等特性增加了互斥元的复杂性，增加了执行操作所需的时间和互斥对象的争用概率。那为什么要付你不需要的钱呢？

“try_locking”是否有超时是一个好的设计是另一个问题；和线程取消一样，C++11没有实现一个失败的设计。