[concurrency-interest] question the about the JMM
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