Mental Models and the JMM

["Gordon Hutchison" <gordon_hutchison@xxxxxxxxxx>]

Friday musings...

Doug Lea wrote:

>                          Machines, especially SMPs, have gotten
> substantially more complicated over the past decade (caching,
> out-of-order execution, CPU-level parallelism, etc).  Unless you'd
> like concurrent programs to be well-defined only on the kinds of
> machines they made a decade ago, such rules appear necessary.  (Said
> differently: The notion that "sequential" computation is purely
> sequential is now false.)

Clearly, this is true.

Gerald wrote:

) I agree and I hope this (RT) JMM stuff is not meant for the average (RT)
) Java programmer.

(Big) Computers could be built with apparent single copy atomic storage, 
strict program
order execution, and a total ordering of all memory accesses by all 
processors-
but they are not. I think it was Lamport who coined the phrase 'sequential 

consistency' to stand for this model. This model has the great advantage 
that it 
is easy to understand but the also great disadvantage that it is now too 
simple (on big Unix servers). 
(It breaks the "as simple as possible but not too simple" test.) 

The changes in hardware architecture absolutely must filter up the stack 
all the way to 
the programmers mind. A programmer level model is necessary to displace 
the natural
and incorrect 'sequential consistency' model we all tend to start out 
with. Thus, 
the JMM stuff is a friend to java programmers, it helps them deal with the 
real world problems
that exist whether the JMM does or not. 

PS
The CSP model avoids the problems here not because of its many other good 
qualities
but due to the simple fact that threads do not passively share state data 
(memory).

PPS 
In the CSP model checking world the equivalent to making things faster may 
be to reduce the size of the
state space being model checked. Perhaps one can see a very clear analogy 
to the concept of
weakening program order to the virtual coarsening work of James Corbett 
whereby events are 
re-ordered up to the next 'significant' event (cf fence) in the combined 
trace. 
Event caching in rubber (but flushable) channels as a form of soft/temporary 
hiding anyone? ;-) 




Gordon Hutchison
IBM Java Technology Centre, 
IBM Hursley, UK.
Notes:   Gordon Hutchison/UK/IBM
Internet: gordon_hutchison@xxxxxxxxxx
Phone: (+44)/(0) 1962 815646 (Internal IBMUK-245646)