[concurrency-interest] spurious wakeups semantics
dl at cs.oswego.edu
Wed Nov 2 14:33:21 EST 2005
It's nice (honestly!) to get your usual balance on the perennial
spurious wakeup issue.
A couple of notes on it:
1. As it turns out, the current implementation
locks.ReentrantLock.Condition.await() do not spuriously
wake up. We don't document or promise this though, for the kinds
of reasons Tim and Josh mentioned.
2. Conversely though, the underlying "primitive" operation
locks.LockSupport.park() is intentionally(!) very "leaky"
and will sometimes fail to block at all. Notice that if threads do
spuriously wake up on modern OSes, then it performance-neutral whether
the OS or the monitor implementation or application code puts
them back to sleep when necessary. However, because
blocking threads on modern multiprocessors and their operating
systems are relatively much more expensive in throughput cost
than, say, the uniprocessors of a decade ago, opportunistically
trying to proceed when you are awake anyway is often faster.
3. We hope that people will increasingly use the more convenient,
semantically cleaner, and often significantly more efficient
medium/higher level constructs that java.util.concurrent offers
rather use monitor/condition operations at all. In fact, whenever people
post on this list that they are using them, I often wonder to myself
what higher-level construct we might put in j.u.c. that they could use
More information about the Concurrency-interest