为什么 std::condition_variable 采用 unique_lock 而不是 lock_guard？ [复制]答案

【问题标题】：Why does std::condition_variable take a unique_lock instead of a lock_guard? [duplicate]为什么 std::condition_variable 采用 unique_lock 而不是 lock_guard？ [复制]
【发布时间】：2018-08-10 07:06:46
【问题描述】：

std::condition_variable 使用如下：

std::condition_variable cv;
...
std::unique_lock<std::mutex> lk(m);
cv.wait(lk, []{return processed;});

在我看来有一个有趣的问题。 unique_lock 可以推迟，它可以被交换掉。通过代码设计，它可能有许多其他原因，不一定是它实际上没有被锁定的严重错误。例如。

std::unique_lock<std::mutex> lk(m, std::try_to_lock_t); // or  std::defer_lock_t
// Try to lock fails.
cv.wait(lk, []{return processed;});

为什么不通过使std::conditional_variable 与lock_guard 一起工作来强制锁定情况呢？那么你将很难进入这种情况。事实上，唯一的方法就是这样做：

// m is not already locked
std::lock_gaurd<std::mutex> lk(m, std::adopt_lock);
cv.wait(lk, []{return processed;});

而不是unique_lock 提供的多种方式。 在condition_variable 上使用unique_lock 而不是lock_guard 是否有技术原因？

【问题讨论】：

问题标题正是这里提出的问题。接受的答案涵盖了所有基础（甚至比这里的当前答案还要多）。 OP 确实做到了 mutex 与 unique_lock，但投票率最高的答案涵盖了更多内容，包括关于为什么不 lock_guard 的专门段落。
@rubenvb 你是绝对正确的。当我阅读答案时，我一定错过了那段。感谢您的帮助。
没问题。重复项主要用于引导用户和访问者获得良好的综合答案。这不是手腕上的一记耳光或任何东西。只是一个303 See other。

标签： c++ multithreading thread-safety

【解决方案1】：

条件变量需要能够锁定和解锁互斥体，lock_guard 不允许这样做。 lock_guard 也不允许访问大多数条件变量实现可能需要的互斥锁本身。

【讨论】：

【解决方案2】：

lock_guard 和 unique_lock 非常相似。然而，lock_guard 锁定构造并解锁破坏。使用condition_variable，互斥锁需要可以多次锁定和解锁。

您基本上可以在任何地方使用unique_locks，但它们比简单的lock_guard 产生更多开销。

std::condition_variable 仅适用于 std::unique_lock；此限制允许在某些平台上实现最大效率。 std::condition_variable_any 提供了一个有效的条件变量与任何 BasicLockable 对象，例如 std::shared_lock。

取自cppreference

【讨论】：