Can someone please explain me what the statement (under precondition) means in below text and what significance it has in threading?
This text is available at boost threading tutorial page
unique_lock(Lockable & m,boost::adopt_lock_t)
Precondition:
**The current thread owns an exclusive lock on m.**
Effects:
**Stores a reference to m. Takes ownership of the lock state of m.**
Postcondition:
owns_lock() returns true. mutex() returns &m.
Throws:
Nothing.
A pre (before) condition: a condition that must be true before calling the function.
In this case the Lockable object "m" must be already locked by the current thread.
What this particular constructor does is adopt the lock. It takes ownership of it away from another owner. The unique_lock object will unlock the Lockable when it is destroyed.
Your question really is about the semantics of Boost's "unique_lock()".
Here's a good explanation:
boost::unique_lock vs boost::lock_guard
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.
