调用condition_variable的notify_*()系列函数前是否必须锁定互斥锁？

Great question—this is a super common point of confusion when working with condition variables, so let's break this down clearly.

Short Answer #

No, you do NOT need to hold a mutex when calling notify_one() or notify_all()—both patterns you saw (holding the lock vs. releasing it first) are completely valid. The key rule is about protecting the shared state, not the notify call itself.

Let's Break Down the Examples #

First, let's look at the two code snippets you referenced:

1. Releasing the lock before notify

{ std::lock_guard lk(m); ready = true; std::cout << "main() signals data ready for processing\n"; }
cv.notify_one();

Here, the shared variable ready is modified while holding the lock (which is mandatory!), then the lock is released before calling notify_one().

This approach has a performance advantage: when the waiting thread wakes up, it can immediately grab the mutex instead of waiting for the notifying thread to release it. This cuts down on unnecessary context switching and latency.

2. Holding the lock during notify

std::unique_lock<std::mutex> lck(mtx); ready = true; cv.notify_all();

This is also valid. The shared state is still protected by the lock (critical!), and calling notify while holding the lock can help avoid a rare edge case called "wakeup loss" (though modern condition variable implementations have largely mitigated this risk).

The tradeoff here is that the waiting thread will wake up but have to wait for the notifying thread to release the mutex before it can check the shared state.

The Critical Rule to Remember #

The non-negotiable part is always modifying the shared state (like ready = true) while holding the mutex. The notify operation itself doesn't require the lock because it's just sending a signal to waiting threads—those threads will still re-check the shared state (in a while loop, not an if!) once they acquire the mutex, which guards against false wakes and ensures they only proceed when the state is actually ready.

Best Practices #

• If performance is a priority, go with the first pattern: modify state under lock, release lock, then notify. This minimizes wakeup latency for waiting threads.
• If you want to keep your code simple or are working with older condition variable implementations, holding the lock during notify is totally safe and won't cause issues.
• Never skip the while loop in waiting threads. Even if you notify correctly, threads can wake up spuriously, so you must re-verify the shared state each time.

内容的提问来源于stack exchange，提问作者Felix F Xu