C++11:为什么 std::condition_variable 使用 std::unique_lock?

标签 c++ multithreading c++11 mutex

在使用 std::condition_variable 时,我对 std::unique_lock 的作用有点困惑。据我了解documentation , std::unique_lock 基本上是一个臃肿的锁守卫,可以在两个锁之间交换状态。

到目前为止,我已经为此使用了 pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex) (我猜这就是 STL 在 posix 上使用的)。它需要一个互斥体,而不是一个锁。

这里有什么不同? std::condition_variable 处理 std::unique_lock 的事实是优化吗?如果是这样,它到底有多快?

最佳答案

so there is no technical reason?

我赞成 cmeerw 的回答,因为我相信他给出了技术原因。让我们来看看它。让我们假设委员会决定让 condition_variable等待 mutex .这是使用该设计的代码:

void foo()
{
    mut.lock();
    // mut locked by this thread here
    while (not_ready)
        cv.wait(mut);
    // mut locked by this thread here
    mut.unlock();
}

这正是不应该使用condition_variable的方式.在标有:

的地区
// mut locked by this thread here

存在异常安全问题,而且很严重。如果在这些区域(或由 cv.wait 本身)引发异常,则互斥锁的锁定状态会泄漏,除非在某个地方也放置了 try/catch 来捕获异常并解锁它。但这只是您要求程序员编写的更多代码。

假设程序员知道如何编写异常安全代码,并且知道如何使用 unique_lock实现它。现在代码如下所示:

void foo()
{
    unique_lock<mutex> lk(mut);
    // mut locked by this thread here
    while (not_ready)
        cv.wait(*lk.mutex());
    // mut locked by this thread here
}

这好多了,但仍然不是一个很好的情况。 condition_variable界面使程序员不遗余力地让事情发挥作用。如果 lk 存在可能的空指针取消引用意外没有引用互斥锁。也没有办法condition_variable::wait检查该线程是否拥有 mut 上的锁.

哦,刚刚记住了,还有程序员可能选错的危险unique_lock公开互斥锁的成员函数。 *lk.release()在这里会是灾难性的。

现在让我们看看代码是如何用实际的 condition_variable 编写的采用 unique_lock<mutex> 的 API :

void foo()
{
    unique_lock<mutex> lk(mut);
    // mut locked by this thread here
    while (not_ready)
        cv.wait(lk);
    // mut locked by this thread here
}
  1. 此代码尽可能简单。
  2. 这是异常安全的。
  3. wait功能可以查看lk.owns_lock()如果是 false 则抛出异常.

这些是插入 condition_variable 的 API 设计的技术原因。 .

此外,condition_variable::wait不需要 lock_guard<mutex>因为lock_guard<mutex>你是怎么说的:我拥有这个互斥锁的锁,直到 lock_guard<mutex>破坏。但是当您调用 condition_variable::wait ,您隐式释放互斥锁上的锁。因此该 Action 与 lock_guard 不一致。用例/语句。

我们需要 unique_lock无论如何,这样人们就可以从函数返回锁,将它们放入容器中,并以一种异常安全的方式锁定/解锁非作用域模式中的互斥锁,所以 unique_lockcondition_variable::wait 的自然选择.

更新

bamboon 在下面的评论中建议我对比 condition_variable_any ,所以这里是:

问题:为什么不是 condition_variable::wait模板化以便我可以通过任何 Lockable输入它?

答案:

这是一个非常酷的功能。例如 this paper演示等待 shared_lock 的代码(rwlock) 在条件变量的共享模式下(在 posix 世界中闻所未闻,但非常有用)。但是功能更昂贵。

因此委员会推出了具有此功能的新类型:

`condition_variable_any`

有了这个condition_variable 适配器可以等待任何可锁定类型。如果有成员lock()unlock() , 你已准备好出发。 condition_variable_any 的正确实现需要 condition_variable数据成员和 shared_ptr<mutex>数据成员。

因为这个新功能比基本的condition_variable::wait 更昂贵。 , 因为 condition_variable是一个如此低级的工具,这个非常有用但更昂贵的功能被放在一个单独的类中,这样你只需在使用时付费。

关于C++11:为什么 std::condition_variable 使用 std::unique_lock?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13099660/

相关文章:

c++ - 如何使用eclipse构建C++应用程序

c++ - 数组索引和地址返回相同的值

python - 使用python建立队列

c++ - 使用 std::find 查找从二进制文件读取的字符并转换为 std::vector<string> 中的 std::string 会产生这种不可预测的行为吗?

c++ - 带有 std::future 的 VS 11 - 这是一个错误吗?

c++ - 算法函数:将其设为模板还是采用 std::function 参数?

c++ - Perl 的 Tie::IxHash(索引关联数组)的 C++ 等价物?

c++ - 简单的代码,看似随机的结果 - 这是由于过时的引用吗?

c++ - 如何使用 boost::statecart 在固定数量的线程上多路复用多个异步状态机?

java - Java中的中断线程