boost::unique_lock vs boost::lock_guard

Question

I don't well understand the difference betweeen these two lock classes. In boost documentation it is said, boost::unique_lock doesn't realize lock automatically.

Does it mean that the main difference between unique_lock and lock_guard is that with unique_lock we must call explicitly the lock() function ?

Answer 1

First to answer your question. No you don't need to call lock on a unique_lock. See below:

The unique_lock is only a lock class with more features. In most cases the lock_guard will do what you want and will be sufficient.
The unique_lock has more features to offer to you. E.g a timed wait if you need a timeout or if you want to defer your lock to a later point than the construction of the object. So it highly depends on what you want to do. BTW: The following code snippets do the same thing.

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

boost::mutex mutex; boost::unique_lock<boost::mutex> lock(mutex); 

The first one can be used to synchronize access to data, but if you want to use condition variables you need to go for the second one.

Answer 2

The currently best voted answer is good, but it did not clarify my doubt till I dug a bit deeper so decided to share with people who might be in the same boat.

Firstly both lock_guard and unique_lock follows the RAII pattern, in the simplest use case the lock is acquired during construction and unlocked during destruction automatically. If that is your use case then you don't need the extra flexibility of unique_lock and lock_guard will be more efficient.

The key difference between both is a unique_lock instance doesn't need to always own the mutex it is associated with while in lock_guard it owns the mutex. This means unique_lock would need to have an extra flag indicating whether it owns the lock and another extra method 'owns_lock()' to check that. Knowing this we can explain all extra benefits this flags brings with the overhead of that extra data to be set and checked

1. Lock doesn't have to taken right at the construction, you can pass the flag std::defer_lock during its construction to keep the mutex unlocked during construction.
2. We can unlock it before the function ends and don't have to necessarily wait for destructor to release it, which can be handy.
3. You can pass the ownership of the lock from a function, it is movable and not copyable.
4. It can be used with conditional variables since that requires mutex to be locked, condition checked and unlocked while waiting for a condition.