[concurrency-interest] spurious wakeups semantics

David J. Biesack David.Biesack at sas.com
Wed Nov 2 11:19:12 EST 2005

> From: "P.H.Welch" <P.H.Welch at kent.ac.uk>
> Date: Wed, 02 Nov 2005 14:49:51 +0000
> Hi,
> Seeing the discussion on these spurious wakeups alarms (maybe depresses)
> me, :( ...

David Holmes' comments clarified the topic for me. (I think the Javadoc should be corrected so that it is clearer.)

When a thread gets a spurious wakeup, it does not simply resume. It merely exits the wait set for the lock. It must still request/obtain the lock, which means it is still blocked, waiting for the lock. IOW, "spurious wakeup" does not mean "return from wait()" and therefore calamity.

The reason the loop/condition test is necessary is that, because of a spurious wakeup, the thread can run even if notify{All}() was not called; i.e. if the second thread calls wait(), but only once it obtains the lock. Further, the thread may resume BEFORE the second thread changes the wait condition to true. Hence the loop is necessary. But it was always a good idea/necessary to begin with:. when notifyAll() is called, another thread may run first and reset the condition to false.

David J. Biesack     SAS Institute Inc.
(919) 531-7771       SAS Campus Drive
http://www.sas.com   Cary, NC 27513

More information about the Concurrency-interest mailing list