What special purpose does unique_lock have over using a mutex?

Question

I'm not quite sure why std::unique_lock<std::mutex> is useful over just using a normal lock. An example in the code I'm looking at is:

{//aquire lock

        std::unique_lock<std::mutex> lock(queue_mutex);

        //add task
        tasks.push_back(std::function<void()>(f));

}//release lock

why would this preferred over

queue_mutex.lock();

//add task
//...

queue_mutex.unlock();

do these snippets of code accomplish the same thing?

Answer 1

[Do] these snippets of code accomplish the same thing?

No.

The first one will release the lock at the end of the block, no matter what the block is. The second will not release the lock at the end if the critical section is exited with a break, continue, return, goto, exception, or any other kind of non-local jump that I'm forgetting about.

Answer 2

The use of unique_lock offers resiliency in the face of changes and errors.

• If you change the flow to add intermediate "jumps" (return for example)
• If an exception is thrown
• ...

in any case, the lock is automatically released.

On the other hand, if you attempt to do it manually, you may miss a case. And even if you don't right now, a later edit might.

---

Note: this is a usual idiom in C++, referred to as SBRM (Scoped Bound Resources Management) where you tie down a clean-up action to stack unwinding so you are assured that, unless crash/ungraceful exit, it is executed.

It also shows off RAII (Resources Acquisition is Initialization) since the very construction of unique_lock acquires the resource (here the mutex). Despite its name, this acronym is also colloquially used to refer to deterministic release at destruction time, which covers a broader scope than SBRM since it refers to all kind of deterministic releases, not only those based on stack unwinding.