对锁定升压互斥锁的方法表示怀疑答案

【问题标题】：doubt about way to lock a boost mutex对锁定升压互斥锁的方法表示怀疑
【发布时间】：2011-07-17 13:24:37
【问题描述】：

boost::recursive_mutex m;
m.lock();

对

boost::lock_guard<boost::recursive_mutex> lock( mutex_ );

使用第一个表格有什么好处吗？第二种形式是只提供RAII机制，还是有其他优势？

【问题讨论】：

是的，它“仅”提供 RAII，但这已经足够了。不，第一种形式没有优势。
@Nemo：虽然 RAII 机制更安全、更干净，但它有一点限制。您可能希望在函数调用中锁定互斥体并在另一个函数调用中将其解锁。然后，您将不得不new lock_guard，感觉比.lock() 解决方案更脏。
@André：确实，严格来说。但是，如果您将其锁定在一个功能中并在另一个功能中解锁，那么您可能需要重新设计。 RAII 的全部意义在于它可以轻松证明没有资源泄漏。值得进行大量的设计工作以使使用这个惯用语 IMO 成为可能。
@André：那么锁应该是在更高级别获取的，它应该使用 RAII。
@Martin：假设您正在编写一个 GUI 应用程序。可以认为一个 GUI 回调将获取互斥锁，而另一个回调释放它（基于用户操作）。在这种情况下，您不能将锁推到更高级别（例如，退出事件循环），因为这会为整个应用程序锁定它，从而达不到目的。 @Nemo：我完全同意 RAII 值得 110%。但是，此限制旨在鼓励人们使用基于 RAII 的锁定。强迫客户在所有情况下使用它是短视的恕我直言。

标签： c++ boost mutex

【解决方案1】：

使用 lock_guard 的好处是它会在超出范围时释放锁。这消除了手动释放锁的需要，并减少了忘记这样做的机会。

boost::recursive_mutex mylock;

{
    boost::lock_guard<boost::recursive_mutex> lock( mylock );

    // do something

    if(false == do_something())
    {
        return; // "lock" goes out of scope and unlocks 'mylock' from it's destructor.
    }

}
// "lock" has gone out of scope and unlocked 'mylock' from it's destructor.

【讨论】：

+1。请注意，这正是有人可能在未来某个时候添加的那种代码。

【解决方案2】：

这两种形式至少是不等价的。以下是与第二种形式等价的*：

boost::recursive_mutex m;
m.lock();
try {
    // ...
} catch(...) {
    m.unlock();
    throw;
}
m.unlock();

这就是您所说的“仅”提供 RAII：避免可怕的样板以提供相同级别的正确性。

*：有警告；查看其他答案和 cmets

【讨论】：

即使不等价；请参阅@Chet 的“提前返回”示例。