Re: CSP, JMM and better processor architectures

[Richard Miller <miller@xxxxxxxxxxxxxxxxxxxx>]

> Right.  The problem with defining this JMM is that Java programmers have
> to be aware of it.  They can write code like "Example 1" above and need
> to be know what it means!  This is not right ... it's far too hard and
> will always lead to tears for all but the superhero concurrent programmers
> (and even they will be a little anxious).

More than a little anxious.  When the implementors of the Plan 9 operating
system at Bell Labs (who are genuine superheroes in my opinion) moved from
Pentium multiprocessors to Pentium Pro they uncovered a subtle flaw in
their sleep/wakeup algorithm, which contained a bit of shared variable code
somewhat like the cited "Example 1".

A posting to the Plan 9 mailing list at the time included this quote:

> We've fixed it by putting an interlock after 'r->p = u->p'.
> However, this has made us very scared.  We don't know of
> other places in the kernel where this applies but that
> doesn't mean there aren't any.

Fortunately, it turned out that they didn't need to be scared: all
the other shared variable accesses in the kernel were sensibly guarded
by semaphores.  It was only this one instance where, to avoid a problem
with nesting of locked regions, they had carefully reasoned that one
lock could safely be eliminated.  But the proof depended on implicit
assumptions about memory coherence which turned out to be too optimistic.

The moral: using shared variables is hard, and the cleverer you are
the harder it gets.

-- Richard Miller