In the std::condition_variable example in cppreference.com,
it manually unlocks the mutex before calling cv.notify_one():
// Manual unlocking is done before notifying, to avoid waking up
// the waiting thread only to block again (see notify_one for details)
lk.unlock();
cv.notify_one();
From the notes on notify_one in cppreference.com: (emphasis mine)
(Not sure if I understood these notes correctly though. Maybe I should post another question on this.)
The notifying thread does not need to hold the lock on the same mutex as the one held by the waiting thread(s); in fact doing so is a pessimization, since the notified thread would immediately block again, waiting for the notifying thread to release the lock. However, some implementations (in particular many implementations of pthreads) recognize this situation and avoid this "hurry up and wait" scenario by transferring the waiting thread from the condition variable's queue directly to the queue of the mutex within the notify call, without waking it up.
Notifying while under the lock may nevertheless be necessary when precise scheduling of events is required, e.g. if the waiting thread would exit the program if the condition is satisfied, causing destruction of the notifying thread's condition variable. A spurious wakeup after mutex unlock but before notify would result in notify called on a destroyed object.
As far as I understand, this and this answers say it's better (at least not worse) to unlock before notifying. But @MaximEgorushkin and @DavidSchwartz's comments in this answer and DavidSchwartz's answer say that notifying before unlocking is better.
Does it depend on the situation or is it personal preference? When should I manually unlock the mutex before notifying?
