[concurrency-interest] question the about the JMM

Jeremy Manson jmanson at cs.umd.edu
Fri Dec 7 13:35:01 EST 2007

Larry Riedel wrote:
>>>> To me, cache coherence is a protocol used by a processor
>>>> to address the consistency of its caches.  It defines the
>>>> behavior of reads and writes to the same memory locations.
>>> That sounds like a pretty good description to me.  I
>>> think I might just change "a processor" to "a set of
>>> threads", and "memory locations" to "sets of objects".
>> Not really.  A cache coherence protocol is for hardware, not
>> a programming language.
> A cache is a container of local unshared snapshots of the states
> of non-local shared objects, and a cache coherence protocol is
> a mechanism for supporting the externally visible object state
> consistency model.  Cache coherence protocols are fundamental
> to contemporary network filesystems and relational databases,
> and are no more exclusive to hardware than content-addressable
> storage or myriad other abstract data types which happen to have
> implementations in hardware.  

That's perfectly fair in general, and perhaps I stated the case too 
broadly.  In this specific case, I was referring to things that are 
pertinent to this discussion and actually have a cache.  The hardware 
has a cache.  The semantics of the Java programming language describe 
nothing that resembles a cache, and the Java memory model allows 
behaviors that a reasonable hardware cache coherence policy would not allow.

> I agree though it seems better to
> say the memory consistency model is defined and provided by the
> runtime environment, not the Java language itself; I never meant
> to imply the latter; I think of constructs like "volatile" and
> "synchronized" as language-level mechanisms for interfacing with
> the memory consistency mechanism of the runtime environment.

The memory consistency model for a Java program is defined by the 
semantics of the Java programming language, not the runtime environment; 
if an implementation is compliant, it will only allow behaviors defined 
by the semantics, and if it is not compliant, it cannot be called Java. 
  Constructs like "volatile" and "synchronized" provide behaviors that 
are described by the semantics, and any effect they may have on caches 
is purely implementation-dependent.

There's a reason I'm hammering on this so hard.  If programmers are to 
be able to write correct programs without understanding all of the 
behaviors of the compiler and the processor, it is absolutely necessary 
for us to have a distinction between what the language allows and what a 
given implementation actually does.  With the first, there is only one 
thing to understand, it is relatively consistent, and can be explained 
relatively easily.  With the second, it can change from VM to VM and 
from one hardware implementation to another.

That's why C++ is adding a memory model.  Otherwise, it is simply 
impossible to write correct code.

That's also why I don't like to talk about this in terms of cache 
coherence -- it doesn't map well to what the JMM actually describes.


More information about the Concurrency-interest mailing list