在使用 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
}
- 此代码尽可能简单。
- 这是异常安全的。
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_lock
是 condition_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/