[E-Lang] Speaking of Community Process: Memory Model & Threads

[Doug Lea]

Sorry for the delay!

> Doug, I know you've been interested in understanding E in the past, and in 
> particular its concurrency control model.  Between the informal 
> http://www.skyhunter.com/marcs/ewalnut.html#SEC18 and the semi-formal 
> http://www.erights.org/elib/concurrency/index.html you may find it to now be 
> adequately explained.  

I've been reading through these, and, as suspected, I cannot see
anything in revised memory model that should be a negative concern.

Here's a very quick summary of revisions
  * It changes some details of "synchronized", basically
    saying that one thread can reliably read the changes to
    fields made by another thread only if it synchronizes on
    the SAME lock as that thread. (Essentially all programs that don't
    rely on this are racy anyway.) 
  * It actually gives a memory spec to "final" fields. The original 
    spec didn't, which opened up lots of scary things that could happen
    in principle (but probably not in practice).
  * It changes rules for "volatile" in a way that actually makes them
    useful -- reading a volatile has same memory semantics as entering
    a synch block and writing of exiting, but without the actual locking.
  * A couple of other minor things.

By clarifying things all around, the new spec reveals how many common
idioms (such as "double-check") were always broken, but now shows how
to fix them. Conversely, it clarifies just how much modern
out-of-order supersclar processors (as well as compilers) are allowed
to (and do!)  mangle unprotected code.  Getting all of the details of
all this right turns out to be challenging, which accounts for our
huge archives on JMM list.  For a random example, it takes a lot of
care to say how synchronized blocks may or may not be reordered with
unsynchronized code. For another, we need some special rules to cover
for the fact that you cannot declare the elements of arrays to be
final or volatile.

Probably the only thing to be worried about is whether you actually
use any of those idioms that were always broken. If you always had my
books in hand while writing concurrent programs, then you probably
didn't :-)

Hope this helps! 

-- 
Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA
dl@cs.oswego.edu 315-312-2688 FAX:315-312-5424 http://gee.cs.oswego.edu/