[concurrency-interest] spurious wakeups semantics
tim at peierls.net
Wed Nov 2 13:16:37 EST 2005
>> [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
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
> 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