[concurrency-interest] spurious wakeups semantics

Brian Goetz brian at quiotix.com
Wed Nov 2 11:00:01 EST 2005


> Seeing the discussion on these spurious wakeups alarms (maybe depresses)
> me, :( ...

Short answer: Don't worry about it so much.

> There was never such a thing in Hoare monitors, from which the Java ones
> are slightly descended.

Hoare monitors are a mathematical abstraction.  Spurious wakeups are 
permitted in recognition of the fact that real life is messy.  You can 
build an OS / thread package that NEVER delivers spurious wakeups, but 
there is a real engineering cost.  It is far more practical and 
efficient to allow the odd spurious wakeup.

Its like the difference between fair and barging locks.  Nonfair locks 
seem disturbing to everyone at first, until they realize the true cost 
of fairness (~2 orders of magnitude performance cost), and then they 
realize that statistical fairness is a better deal.  Same with SW; 
allowing an OS to deliver a spurious wakeup once in a while (and it is 
infrequent) allows for other optimizations and engineering improvements 
in the implementation.

> As a design concept, it makes no sense.  If spurious unblocking from
> "wait()" invocations are legal, then JVMs could all simplify their
> implementations by implementing wait/notify/notifyAll as no-ops.  That
> looks perfectly legal!  In such JVMs, all "wait()"s are immediately
> spuriously notified and all "notify()"s have nothing to do - easy, :).

Yes, but no reasonable JVM would do this.  JVMs could also implement 
sleep() with spin-waits.  There is a market here -- and such a JVM would 
be rejected by the market.

> Isn't it time that spurious wakeups were removed from Java semantics?

 From the perspective of a software developer, spurious wakeups are 
totally irrelevant.  Why?  To deal with spurious wakeups, you need to 
wait in a loop and re-test the condition every time.  But a program 
which uses wait() must do this anyway in order to be correct!  So, if 
spurious wakeups were disallowed, it would have zero effect on program 
code.

Short answer: Don't worry about it so much.



More information about the Concurrency-interest mailing list