boost scoped_lock vs普通锁定/解锁

Max*_*Max 41 c++ boost mutex thread-safety

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

我注意到,这boost::scoped_mutex是使用互斥锁的最流行的方法之一.为什么是最好的成员函数::lock()::unlock()

特别是,我为什么要使用

{
  boost::scoped_lock lock(mutex)
  // ...
  // read/output sharing memory.
  // ...
}
Run Code Online (Sandbox Code Playgroud)

而不是

mutex.lock()
// ...
// read/output sharing memory.
// ...
mutex.unlock()
Run Code Online (Sandbox Code Playgroud)

scoped_lock因为某些样式编码的观点还是::lock()/::unlock()"线程安全不够" 而更好?

And*_*owl 70

为什么它更适合成员函数:: lock()和:: unlock()?

出于同样的原因,为什么RAII成语在一般情况下变得流行(这只是其无数例中的一个):因为你可以确定你不会在不解锁互斥锁的情况下离开当前范围.

请注意,这不仅仅是忘记呼叫unlock():当您的互斥锁被锁定时可能会发生异常,并且您的呼叫unlock()可能永远不会到达,即使return您的呼叫lock()与您的呼叫之间没有任何声明unlock().

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

在这种情况下,scoped_lock将在堆栈展开期间调用防护的析构函数,确保相关的互斥锁始终被释放.

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

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


nik*_*tan 7

您可以使用

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

如果不想使用 boost 库。