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（）'来检查。知道了这一点，我们就可以解释这个标志带来的额外好处以及要设置和检查的额外数据的开销

锁定不必在构造中正确使用，您可以在构造期间传递标记std::defer_lock以在构造期间保持互斥锁解锁。
我们可以在函数结束之前解锁它，而不必等待析构函数释放它，这可能很方便。
您可以从函数中传递锁的所有权，它是可移动而不是可复制。
它可以与条件变量一起使用，因为它需要锁定互斥锁，在等待条件时进行条件检查和解锁。

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）

是boost::unique_lock和boost::mutex函数的类似方式，但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）。您必须进行基准测试以确认当前的数字，并且我确定它非常符合操作系统。

Answer 5

我认为当你需要强调独特锁和共享锁之间的区别时，也可以使用unique_lock。

boost :: unique_lock vs boost :: lock_guard

5 个答案: