boost scoped_lock vs plain lock/unlock

by

Why is it preferable to member functions ::lock() and ::unlock()?

For the same reason why the RAII idiom became 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.

Notice, that this is not just about forgetting to 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().

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 always gets released.

{
    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.

Leave a Comment