[concurrency-interest] spurious wakeups semantics

Tim Peierls tim at peierls.net
Wed Nov 2 13:16:37 EST 2005

P.H.Welch wrote:
>> [Tim:] Imagine what would happen if spurious wakeups were disallowed. First, programmers
>> (those who never really bought into the idea that premature optimization is evil) would rush
>> to turn this ... <description of while-wait-loop turned into if-wait>.
> It sounds like you're threatening us with spurious wakeups just to make us keep the 
> while-wait-loop, :).

Whatever works! :-)

> I would hope that - alongside converting while-wait-loop to if-wait - they would look very 
> carefully at the logic of their monitor methods to ensure that the condition can't be unset 
> between notification and re-acquisition.

This asks too much of the programmer, and it precludes practical designs that don't fit the 
theoretical ideal.

For example, until JDK 5.0, you were limited to one wait-set per monitor, so rechecking the 
condition was sometimes essential even you disregarded the possibility of spurious wakeups.

> It's the absence of clean mathematical abstractions that leads to real engineering costs (that 
> you mention).

There's also a cost if you pick an abstraction that is too restrictive or that doesn't map well to
engineering realities.

> I just don't believe that never delivering a spurious wakeup should impose such a cost 
> (assuming we're not trying to guard against hardware corruption).

Let me turn that around: Is there a realistic example of a setting where the cost of a single 
superfluous condition evaluation dominates the context switch overhead in an essential way?  If 
not, then there is no reason to avoid the "while (!cond) wait()" pattern and thus no reason to 
force JVM designers to do handstands to hide spurious wakeups from us.  (If there is such an 
example, then there's more to debate.)


More information about the Concurrency-interest mailing list