C++ boost scoped_lock 与普通锁定/解锁
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/15179553/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
boost scoped_lock vs plain lock/unlock
提问by Max
I'm going to use boost::mutex
from boost/thread/mutex.hpp
.
There are several ways to lock/unlock mutex: with scoped_lock
, unique_lock
, lock_guard
, mutex's member functions ::lock()
and ::unlock()
and nonmember functions lock()
and unlock()
.
我将使用boost::mutex
from boost/thread/mutex.hpp
. 有几种方法来锁定/解锁互斥:有scoped_lock
,unique_lock
,lock_guard
,互斥的成员函数::lock()
和::unlock()
和非成员函数lock()
和unlock()
。
I noticed, that boost::scoped_mutex
is one of the most popular ways of using mutex. Why is it preferable to member functions ::lock()
and ::unlock()
?
我注意到,这boost::scoped_mutex
是使用互斥锁最流行的方法之一。为什么它比成员函数::lock()
和更可取::unlock()
?
Particularly, why should I use
特别是,我为什么要使用
{
boost::scoped_lock lock(mutex)
// ...
// read/output sharing memory.
// ...
}
rather than
而不是
mutex.lock()
// ...
// read/output sharing memory.
// ...
mutex.unlock()
is scoped_lock
better just because of some style-coding point of view or is ::lock()/::unlock()
not "thread safe enough"?
是scoped_lock
因为某种风格编码的观点还是::lock()/::unlock()
“线程不够安全”而更好?
回答by Andy Prowl
Why is it preferable to member functions ::lock() and ::unlock()?
为什么比成员函数 ::lock() 和 ::unlock() 更可取?
For the same reason why the RAII idiombecame popular in general (this is just one of its countless instances): because you can be sure you don' leave the current scope without unlocking the mutex.
出于与RAII 习惯用法普遍流行的相同原因(这只是其无数实例之一):因为您可以确定不会在不解锁互斥锁的情况下离开当前作用域。
Notice, that this is not just about forgettingto call unlock()
: an exception may occur while your mutex is locked, and your call to unlock()
may never be reached, even though you do not have any return
statement between your call to lock()
and your call to unlock()
.
请注意,这不仅仅是忘记调用unlock()
:当您的互斥锁被锁定时可能会发生异常,并且您的调用unlock()
可能永远不会到达,即使您return
在调用 tolock()
和调用 to之间没有任何语句unlock()
。
m.lock() // m is a mutex
// ...
foo(); // If this throws, your mutex won't get unlocked
// ...
m.unlock()
In this case, the destructor of your scoped_lock
guard will be invoked during stack unwinding, making sure the associated mutex alwaysgets released.
在这种情况下,您的scoped_lock
守卫的析构函数将在堆栈展开期间被调用,确保相关联的互斥锁始终被释放。
{
boost::scoped_lock lock(m); // m is a mutex
// ...
foo(); // If this throws, your RAII wrapper will unlock the mutex
// ...
}
Moreover, in many situations this will improve your code's readability, in that you won't have to add a call to unlock()
before every return
statement.
此外,在许多情况下,这将提高代码的可读性,因为您不必unlock()
在每个return
语句之前添加调用。
回答by niketan
you can use
您可以使用
std::lock_guard<std::mutex> lock(mutex);
std::lock_guard<std::mutex> lock(mutex);
if don't want to use boost library.
如果不想使用 boost 库。