[concurrency-interest] question the about the JMM

Larry Riedel larryr at saturn.sdsu.edu
Thu Dec 6 18:29:43 EST 2007


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


> [p==q]
> Thread 1:
>     r1 = p.x;
>     r2 = q.x;
>     r3 = p.x;
> Thread 2:
>     q.x = 1;
> 
> This code reads and writes to memory locations, and
> therefore relies on a cache coherence protocol.  Its
> behavior under the Java memory model is different from
> its behavior under any sane cache coherence protocol.

The code is not utilizing any inter-thread relative
ordering constraint mechanisms of the protocol, so
I think the cache coherence protocol is agnostic
about whether Thread1 sees r1==r3==0 and r2==1.
If "x" is volatile though, I would expect the cache
coherence protocol to make sure r3==1 if r2==1.


> > What would be a good example where there is a
> > happens-before but still r1==r3==0 and r2==1?
> 
> If you are looking for an example where happens-before
> edges differ from explicit memory barriers,

An example where there is a happens-before but still
r1==r3==0 and r2==1, or something conceptually analogous.

> edges differ from explicit memory barriers, that's a
> different question.  It's also a question that doesn't
> really have an answer, because you really can't map
> anything to a "memory barrier" in Java, because the
> notion doesn't exist.

I did not say anything about "memory barrier", so I am
ok with the idea that the notion does not exist. (-:


> An example would be that this:
>    synchronized (new Object()) {
>       x = 1;
>    }
> Does not have the same memory semantics as this:
>    mfence;  // or whatever you want to use
>    x = 1;
>    sfence;
> 
> Because synchronization on an Object that can't be
> accessed by multiple threads can be removed entirely.

Guessing what role "mfence" and "sfence" are playing
there, I imagine I might want to use more like:

    Object o = new Object();
    mfence(o);
    x = 1;
    sfence(o);

Presuming no reference to "o" leaks out via [ms]fence,
I would not expect the cache coherence protocol to need
to impose any actual ordering constraints,


Larry



More information about the Concurrency-interest mailing list