代码之家  ›  专栏  ›  技术社区  ›  Fantastic Mr Fox

为什么std::condition_变量使用唯一的锁而不是锁保护?[副本]

  •  5
  • Fantastic Mr Fox  · 技术社区  · 6 年前

    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;});
    

    而不是在 独特的锁 . 是否有技术上的原因 独特的锁 结束 锁具 为了一个 condition_variable ?

    2 回复  |  直到 6 年前
        1
  •  5
  •   Alan Birtles    6 年前

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

        2
  •  1
  •   rmm19433    6 年前

    lock_guard unique_lock 非常相似。然而 锁具 锁住建筑,打开破坏的锁。使用 condition_variable 互斥锁需要能够多次锁定和解锁。

    你基本上可以用 独特的锁 但是,它们比简单的 锁具 .

    std::condition_变量仅适用于std::unique_锁; 这种限制允许在某些平台上实现最大效率。 std::condition_variable_any提供一个可以工作的条件变量 任何基本时钟对象,如std::shared_lock。

    取自 cppreference