boost :: unique_lock vs boost :: lock_guard

Question

我不太清楚这两个锁类之间的区别.据说在boost文档中,boost::unique_lock没有实现自动锁定.

这是否意味着之间的主要区别unique_lock,并lock_guard是用unique_lock我们必须显式调用lock()功能？

Answer 1

首先回答你的问题.不,你不需要在unique_lock上调用lock.见下文:

unique_lock只是一个具有更多功能的锁类.在大多数情况下,lock_guard会做你想做的事情并且足够了.
unique_lock具有更多功能.例如,如果您需要超时,或者如果您希望将锁定延迟到比构造对象更晚的时间,则进行定时等待.所以它在很大程度上取决于你想做什么.顺便说一句:以下代码片段做同样的事情.

boost::mutex mutex;
boost::lock_guard<boost::mutex> lock(mutex);

boost::mutex mutex;
boost::unique_lock<boost::mutex> lock(mutex);

第一个可用于同步对数据的访问,但如果要使用条件变量,则需要选择第二个.

Answer 2

目前最好的投票答案是好的,但它没有澄清我的疑问,直到我挖得更深,所以决定与可能在同一条船上的人分享.

首先两者lock_guard并unique_lock遵循RAII图案,在锁被构造期间破坏过程中自动获取和解锁的最简单的使用情况.如果这是您的用例,那么您不需要额外的灵活性,unique_lock并且lock_guard会更有效率.

两者之间的关键区别是unique_lock实例不需要始终拥有与之关联的互斥锁,而在lock_guard其中拥有互斥锁.这意味着unique_lock需要有一个额外的标志,指示它是否拥有锁,还有另一个额外的方法'owns_lock()'来检查.知道了这一点,我们可以解释这个标志带来的所有额外好处,以及要设置和检查的额外数据的开销

1. 锁不必在施工时采取正确的方法,您可以std::defer_lock在施工期间通过旗帜,以便在施工期间保持互斥锁解锁.
2. 我们可以在函数结束之前解锁它,而不必等待析构函数释放它,这可能很方便.
3. 您可以从函数传递锁的所有权,它是可移动的而不是可复制的.
4. 它可以与条件变量一起使用,因为这需要在等待条件时锁定互斥锁,条件检查和解锁.

Answer 3

他们的实现可以在路径.../boost/thread/locks.hpp下找到 - 而且他们只是坐在另一个旁边:)总结一下:

lock_guard是一个简单的简单实用程序类,它在构造函数中锁定互斥锁并在析构函数中解锁,而不是关心细节.

unique_lock有点复杂,添加了很多功能 - 但它仍然在构造函数中自动锁定.它被称为unique_lock,因为它引入了"锁定所有权"概念(请参阅owns_lock()方法).

Answer 4

如果您习惯于pthreads(3):

• boost::mutex = pthread_mutex_*
• boost::unique_lock= pthread_rwlock_*用于获取写/独占锁(即pthread_rwlock_wrlock)
• boost::shared_lock= pthread_rwlock_*用于获取读/共享锁(即pthread_rwlock_rdlock)

是的a boost::unique_lock和boost::mutex函数以类似的方式,但a boost::mutex通常是一个较轻的互斥量来获取和释放.也就是说,shared_lock已经获得的锁更快(并允许并发),但获得一个锁的成本相对较高unique_lock.

你必须在封面下查看实现细节,但这是预期差异的要点.

说到性能:这里是一个适度有用的延迟比较:

http://www.eecs.berkeley.edu/%7Ercs/research/interactive_latency.html

如果我/某人能够对不同的pthread_*基元的相对成本进行基准测试会很好,但最后我看,pthread_mutex_*是〜25us,而是pthread_rwlock_*〜20-100us取决于是否已经获得了读锁(~10us) )或不(~20us)或作家(~100us).您将必须进行基准测试以确认当前数字,并且我确定它非常符合操作系统.