[concurrency-interest] question the about the JMM

Larry Riedel larryr at saturn.sdsu.edu
Fri Dec 7 15:21:26 EST 2007


> In this specific case, I was referring to things that are
> pertinent to this discussion and actually have a cache.

I was referring, as I have been from the outset, to
a logical model for reasoning about the behavior of
the software, and the use of caches in that model.
Since that logical model "actually has a cache", it
is indubitably pertinent.


> > 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.

That sounds ok to me.  The runtime environment is the
mechanism of behavior and access to state information.
The memory consistency model imposes requirements and
constraints on the runtime environment.  Definition of
the the language itself, in the absence the definition
of a compliant environment, is not sufficient to ensure
behavior compliant with the memory consistency model.

I find it intuitively easier to think of the memory
consistency model as part of the runtime environment,
and the language as providing a means for interfacing
with and utilizing it.  But neither the JLS or JVMS
in isolation as solely defining it.


> Constructs like "volatile" and "synchronized" provide
> behaviors that are described by the semantics

Indeed, as I said at the outset:

    > I decided to get a more detailed answer to convince
    > him that reasoning in 'caches and invalidation' is not
    > the way to go with the new JMM.

    I think it should be ok to reason that way, as long as
    it is done in a way which is consistent with the actual
    semantics, which I think is viable.


> 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.

I do not think of Java as defining much about behavior
of compilers or of "processors", if "processors" means
what is used by the implementation of the runtime
environment.  I think of it as describing the relationship
between the input and output of compilers, and describing
the runtime environment provided by the machine which
interprets/executes the output of the compiler to produce
the behavior of the software.


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

In that context I tend to think of C++ as mostly adding a
memory model for the runtime environment, especially since
there is not something which seems comparable to "The Java
Virtual Machine Specification" to define it.  But by this
I am not suggesting the language will not have changed,


Larry



More information about the Concurrency-interest mailing list