The condition variables Notify_all () and notify () ...

Having read a book about concurrency, there is a conclusion that using Notifyall is a safer procedure. Take the message queue as an example, assuming that the action put into the element is put, taking the action of the element as the last sentence of Take,put may be
if (count = = 1) {Notempty_cond.notify_all ();}
If you change the Notify_all to notify (), there are cases where concurrency is not sufficient: assuming that the queue is empty for several consecutive times, only the first put wakes up a take thread. If the queue remains non-empty after that, only one of the take threads is active at all times. It can also be worse if the thread that falls into the trap is critical, the system may be stuck in a live lock state.
On the weekend, read a good article: "Real-world Concurrency", the text mentions the other side of the problem: Notify_all () easy to lead to surprise group phenomenon. This can lead to degraded system performance: assuming a time period when the take frequency is higher than put, the queue always approaches null, but each put wakes up all the threads that are blocking the take, but only one thread can continue to run. Vice versa.
In short: notify_all more secure, less mental burden, but may lead to a significant decrease in efficiency.
So for most of the system module, Notify_all is enough, if it is an infrastructure module, you can consider using notify to optimize, but be careful.

Analyzing the Linkedblockingqueue implementation in Java concurrent, it is found that the algorithm is similar to (omitting the wait when not satisfied): Put when the queue is found to be not full, notify a blocked putter (if any), found the queue size after the put 1, Notify a blocked taker (if any), while take when the queue is found to be non-empty, notify a blocked taker (if any), if the queue size found after this take MAX-1, notify a blocked putter (if any).
Why not take a simpler algorithm: Notify a blocked taker (if any) after each execution of a put, and notify a blocked putter (if any) after each take. is due to efficiency considerations. Directly on the code note: "Also, to minimize need for puts to get takelock and Vice-versa, cascading notifies is used. When a put notices the IT has enabled at least one take, it signals taker. That taker in turn signals others if more items has been entered since the signal. "
Using a simple algorithm, the efficiency is lower than the use of notify_all when the Swarm is less frequent (the take and put frequencies are equal, the queue capacity is not extreme). So the use of notify to replace the Notify_all, it is a technical content of the matter ah.