boost -- scoped_lock V.S. mutex lock/unlock —— why scoped_lock is recommanded?

why scoped_lock is recommanded?

 

其实，这和RAII idiom变流行是同样的缘由：由于你能够确保任何状况下离开执行范围都会解锁mutex。

注意，这不单单是说你可能忘记调用unlock()：而且，在你的mutex被锁定以后，程序还有可能抛出异常，你写的unlock调用语句有可能永远没有机会执行，即便在lock()和unlock()之间没有返回语句也同样。 

 

m.lock() // m 是一个 mutex
// ...
foo(); // 若是这函数里面throw up了, 你的mutex 就会永远锁住了
// ...
m.unlock()

 

像下面这样你的scoped_lock 的析构函数总会在栈展开的时候自动调用，这样就能确保关联的mutex老是被释放了。

{
    boost::scoped_lock lock(m); // m 是一mutex
    // ...
    foo(); // 若是throw up了，你的 RAII wrapper会解锁 mutex
    // ...
}

 

除此以外这样还能增长你的代码的可读性。你不须要在每一个返回语句前面加一句unlock。

 

==============

当你要锁的函数是递归函数时，你能够用boost::recursive_mutex + boost::recursive_mutex::scoped_lock 

void foo() {
   ... mutex_acquire();
   ... foo();
   ... mutex_release();
}

 

不用 recursive mutex的话就得这样:

void foo_entry() {
   mutex_acquire(); 
   foo(); 
   mutex_release(); 
}

void foo() { ... foo(); ... }