提升 scoped_lock 与普通锁定/解锁答案

【问题标题】：boost scoped_lock vs plain lock/unlock提升 scoped_lock 与普通锁定/解锁
【发布时间】：2013-02-17 05:48:48
【问题描述】：

我将使用来自boost/thread/mutex.hpp 的boost::mutex。有几种方法可以锁定/解锁互斥锁：使用scoped_lock、unique_lock、lock_guard、互斥锁的成员函数::lock() 和::unlock() 以及非成员函数lock() 和unlock()。

我注意到，boost::scoped_mutex 是使用互斥锁的最流行的方式之一。为什么比成员函数::lock() 和::unlock() 更可取？

特别是为什么要使用

{
  boost::scoped_lock lock(mutex)
  // ...
  // read/output sharing memory.
  // ...
}

而不是

mutex.lock()
// ...
// read/output sharing memory.
// ...
mutex.unlock()

scoped_lock 是否更好，仅仅是因为某种样式编码的观点，还是::lock()/::unlock() 不够“线程安全”？

【问题讨论】：

标签： c++ boost thread-safety mutex

【解决方案1】：

为什么比成员函数 ::lock() 和 ::unlock() 更可取？

与RAII idiom 普遍流行的原因相同（这只是其无数实例之一）：因为您可以确保在不解锁互斥锁的情况下不会离开当前范围。

注意，这不仅仅是忘记调用unlock()：当您的互斥锁被锁定时可能会发生异常，并且您对unlock() 的调用可能永远无法到达，即使您在您对lock() 的调用和对unlock() 的调用之间没有任何return 语句。

m.lock() // m is a mutex
// ...
foo(); // If this throws, your mutex won't get unlocked
// ...
m.unlock()

在这种情况下，您的scoped_lock 守卫的析构函数将在堆栈展开期间被调用，确保相关联的互斥锁始终被释放。

{
    boost::scoped_lock lock(m); // m is a mutex
    // ...
    foo(); // If this throws, your RAII wrapper will unlock the mutex
    // ...
}

此外，在许多情况下，这将提高代码的可读性，因为您不必在每个 return 语句之前添加对 unlock() 的调用。

【讨论】：

【解决方案2】：

你可以使用

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

如果不想使用 boost 库。

【讨论】：