If you do not lock the mutex in the codepath that changes the condition and signals, you can lose wakeups. Consider this pair of processes: Process A: pthread_mutex_lock(&mutex); while (condition == FALSE) pthread_cond_wait(&cond, &mutex); pthread_mutex_unlock(&mutex); Process B (incorrect): condition = TRUE; pthread_cond_signal(&cond); Then consider this possible interleaving of instructions, where condition starts out as FALSE: … Read more
You do not need to be holding a lock when calling condition_variable::notify_one(), but it’s not wrong in the sense that it’s still well defined behavior and not an error. However, it might be a “pessimization” since whatever waiting thread is made runnable (if any) will immediately try to acquire the lock that the notifying thread … Read more
It’s just the way that condition variables are (or were originally) implemented. The mutex is used to protect the condition variable itself. That’s why you need it locked before you do a wait. The wait will “atomically” unlock the mutex, allowing others access to the condition variable (for signalling). Then when the condition variable is … Read more