Re: TechEd 2006 -- "parallelism is the new OO"

["Joe Bowbeer" <joe.bowbeer@xxxxxxxxx>]

On 9/2/06, P.H.Welch <P.H.Welch@xxxxxxxxxx> wrote:
> We can imagine the discussion amongst the Java threading designers:

There was a great discussion about this on concurrency-interest last
October.  Anyone interested in the inside story should search the
archives for the "spurious wakeup semantics" thread:
http://g.oswego.edu/dl/concurrency-interest/

I include Doug Lea's post below, but there's plenty more good stuff
where that came from.

Doug Lea writes:

1. As it turns out, the current implementation of
locks.ReentrantLock.Condition.await() does 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
than 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
instead.