[concurrency-interest] question the about the JMM

Jeremy Manson jmanson at cs.umd.edu
Thu Dec 6 15:50:40 EST 2007


Larry Riedel wrote:
>> This isn't just about cache coherence.  It's also about
>> compiler optimization.  Consider the following example.
>> Initially, p == q, and they are some object with a field x.
>> Thread 1:
>>     r1 = p.x;
>>     r2 = q.x;
>>     r3 = p.x;
>> Thread 2:
>>     q.x = 1;
>>
>> This means that r1 and r3 can have the value 0 and r2 can
>> have the value 1, even though they are all reading from the
>> same memory location.  No sane cache coherence policy would
>> allow this when reading from the same variable (although I
>> may be misremembering some), but the JMM does.
> 
> I do not see that code using any constructs which bring
> cache coherence /or/ happens-before into the picture,
> unless x is "volatile", in which case I think ending up
> with (r2==1) and (r3==0) should not be valid.  What
> would be a good example where there is a happens-before
> but still r1==r3==0 and r2==1?

I think your definition of cache coherence and mine might be different. 
  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.  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.

If you are looking for an example where happens-before 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.   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.

					Jeremy


More information about the Concurrency-interest mailing list