AW: [concurrency-interest] spurious wakeups semantics

Ernst, Matthias matthias.ernst at coremedia.com
Wed Nov 2 10:22:15 EST 2005


> 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.  

A trivial implementation of a concept does not render the concept
nonsensical.
The implementation is just not useful then.

I'm sure spurious wakeups have a raison d'etre (which would be
interesting to know the cause for).

But even if there were no spurious wakeups, the while loop is necessary
anyway in most cases
because the condition might have already changed back to false between
wakeup and the actual
acquisition of the monitor. Take the example of a threadpool thread:

...
  synchronized(jobs) {
    if(jobs.isEmpty()) wait();
    job = jobs.take();
  }
  job.run();
...

When this thread is woken up, but before it can actually re-acquire the
monitor, another
threadpool thread might have finished its work and grabbed the next job.
So it's necessary
to change 'if' to 'while'.

I've always explained spurious wakeups to myself as follows: "The while
loop is necessary
anyway because wait cannot atomically wakeup and acquire. So why pay a
penalty for removing
spurious wakeups in the threading library?"

Matthias



More information about the Concurrency-interest mailing list