[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