[concurrency-interest] spurious wakeups semantics
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
> 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
- One in, one-out. A notification must release exactly one waiter.
This rules out blocking classes like latches and barriers, which must
- 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