C++ condition_variable的 notify_one()和notify_all() 区别

std::condition_variable::notify_one

https://en.cppreference.com/w/cpp/thread/condition_variable/notify_one

If any threads are waiting on *this, calling notify_one unblocks one of the waiting threads.

Notes
The effects of notify_one()/notify_all() and each of the three atomic parts of wait()/wait_for()/wait_until() (unlock+wait, wakeup, and lock) take place in a single total order that can be viewed as modification order of an atomic variable: the order is specific to this individual condition variable. This makes it impossible for notify_one() to, for example, be delayed and unblock a thread that started waiting just after the call to notify_one() was made.

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.

std::condition_variable::notify_all

https://en.cppreference.com/w/cpp/thread/condition_variable/notify_all

The effects of notify_one()/notify_all() and each of the three atomic parts of wait()/wait_for()/wait_until() (unlock+wait, wakeup, and lock) take place in a single total order that can be viewed as modification order of an atomic variable: the order is specific to this individual condition variable. This makes it impossible for notify_one() to, for example, be delayed and unblock a thread that started waiting just after the call to notify_one() was made.

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.

总结

notify_all对应linux下的pthread_cond_broadcast：通常表明状态变化，比如某一主线程的任务完成，通知其余子线程开始执行。会使得所有wait在条件变量上的子线程去竞争锁。因为wait()会原子地unlockmutex并进入等待，而被唤醒的线程会在wait()退出时自动重新加锁。
notify_one对应linux下的pthread_cond_signal：通常用于资源可用。如单一生产者，生产者一次生产一个产品的情况，最好每次只有一个消费者去消耗产品。只唤醒一个wait在条件变量上的子线程，不形成锁的竞争局面。

不论是notify_one还是notify_all，都有可能发生虚假唤醒。即在多核处理器下，pthread_cond_signal可能会激活多于一个线程（阻塞在条件变量上的线程）。结果是，当一个线程调用pthread_cond_signal()后，多个调用pthread_cond_wait()或pthread_cond_timedwait()的线程返回。返回后若是操作了已经被其他线程先行一步消费掉的产品，会产生iterator错误甚至是crash。解决方法是用while等待条件变量而不是if，以double check条件变量是否依然是自己想要的状态。