[concurrency-interest] spurious wakeups semantics

P.H.Welch P.H.Welch at kent.ac.uk
Wed Nov 2 09:49:51 EST 2005


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

The idea of a spurious wakeup was (surely?) never part of the conceived
design for Java threads ... just something that crept in because of
some dodgy threading libraries on which early implementations depended??

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

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, :).

Humm ... maybe the "wait()" can't be a no-op since it must release
the monitor?  But it could be implemented as a release-monitor-lock
then "Thread.yield()" them spurious-wakeup then acquire-monitor-lock.
Actually, I think that's optimisable back to a no-op!  Either way ...

... all those waits-inside-while-condition loops become busy-polling,


which is actually what they really are anyway ... with no guarantees
of exit.  I suspect that many real systems running on many real JVMs
(even without spurious wakeups) are at risk from never exiting such
loops.  Isn't the *only* technical reason for programming such loops
... to cope with spurious wakeups?  The other reasons for them being
lazy (or erroneous) logic ... that's a conjecture ... suspect true.

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


More information about the Concurrency-interest mailing list