Hi Anton, I changed the post. This is a better response.
What are the merits of notifyAll which would make it a better choice, provided I do not specify priorities and all threads are of the same priority?
Concurrent Programming in
Java, Doug Lea, 3.2.4.2 Single notification page 191
However, in some other classes, you can reduce the context-switch overhead associated with notifications by using a single notify rather than notifyAll. Single notifications can be used to improve performance when you are sure that at most one
thread needs to be woken. This applies when:
1. All possible waiting threads are necessarily waiting for conditions relying on the same notifications, usually the exact same condition.
2. Each notification intrinsically enables at most a single thread to continue. Thus it would be useless to wake up others. 3. You can accomodate uncertainties surrounding the possibility that an interrupt and a notify may occur at about the same time. In this case, the one thread that was notified is about to terminate. You might want another thread to receive notification instead, but this is not automatically arranged. (The issue does not arise with notifyAll since all threads are woken.) ----
Java RMI, William Grosso, Chapter 11, Notify Versus NotifyAll
However, there are situations when notifyAll() is absolutely the correct choice.
One example, in a distributed chat room application, we might make the following design decisions:
There is a single centralized WhiteBoard object, which contains the transcript of the conversation. Every remote participant is assigned a thread that sends the new lines of text. Posting a new piece of text involves locking the whiteboard, adding the text to the whiteboard and then calling NotifyAll(). Each thread grabs the change and sends it out. Another example occurs when the same lock is used to signal more than one type of event (and different types of events are handled by different types of waiting threads). For example, in a stockticker application, we may not want lots of information to pile up, waiting to be sent. One possible design uses a fixed-length queue to control communication. This involves the following design decisions:
There is a fixed-length queue and two threads. One thread sends messages out to the recipient, pulling them off the queue. Another thread gets messages from the sender and puts them on the queue. Because the queue is fixed-length, however, both threads also need to wait on the queue when they get ahead. The client thread will wait for messages to come into the queue. The server thread will wait for messages to be sent, so that more space is available on the queue. There is only one lock, but there are two events (�messages put in the queue� and �messages removed from the queue�), each intended for a different thread. Therefore, notifyAll() must be used. [ August 29, 2004: Message edited by: Marlene Miller ]
