[concurrency-interest] spurious wakeups semantics

Brian Goetz brian at quiotix.com
Wed Nov 2 14:52:26 EST 2005

>> - This can happen whenever notifyAll is used to wake up more than one 
>> thread, even if all threads are waiting for the same condition.  There 
>> are good engineering reasons why you might prefer notifyAll to single 
>> notify.
> what are these good engineering reasons ?
> and are these reasons can be applied to Condition.signal/signalAll too
> in case of fair Lock ?

In order for a design to be a candidate for notify() instead of 
notifyAll(), three conditions need to hold:

  - Uniform waiters.  All waiters must be waiting for the same 
condition.  This rules out a bounded buffer design which uses an 
intrinsic condition queue, because there are separate "notEmpty" and 
"notFull" conditions.

  - One in, one-out.  A notification must release exactly one waiter. 
This rules out blocking classes like latches and barriers, which must 
use notifyAll().

  - Subclass safety.  This one is a little trickier.  The class must be 
structured so that if the class is subclassed, the above requirements 
still hold.  It is very difficult to design a blocking class so that it 
can be subclassed arbitrarily.

Any class which uses an intrinsic condition queue / lock object and the 
queue/lock object is not hidden cannot meet the first requirement, 
because any old code could wait() on the condition queue and violate the 
uniform waiters requirement.  So the monitor-like pattern encouraged by 
Java does not play nicely with single notify.

More information about the Concurrency-interest mailing list