[concurrency-interest] concurrency puzzle

Jeremy Manson jmanson at cs.umd.edu
Mon Sep 11 12:20:02 EDT 2006


Oops!  I guess "off list" is a concept I am having trouble with today 
:).  Oh, well, if people are interested...

Peter Veentjer wrote:
> But what about the behaviour of the synchronized statement? If a lock
> is obtained, local memory (for that thread) is invalidated and the
> next read is going to access main memory.
> 
> That is why the assignment of x=20 could get lost. If the x=20 isn't
> written to main memory (and in this case there is no need to) but only
> to cache, the value is 'dropped' when the cache is invalidated.
> 
> Is this correct? I'm trying to understand the memory behaviour of the
> synchronized statement: that is the reason why I made this example.
> 

Peter,

First, the example again:

> public class A{
>     private int x = 10;
>     public static A a;
> 
>     public void foo(){
>        x = 20;
>        synchronized(this){
>           System.out.println( x );
>        }
>     }
> 
> }
> 
> Thread 1:
> A o = new A();
> A.a = o;
> 
> Thread 2:
> A r1 = A.a;
> assert r1 != null;
> r1.foo(); // can print out 10 or 20


You are still thinking about this in terms of local memory for a given 
thread, and invalidation.  A Java thread doesn't have local memory, and 
doesn't perform invalidation.  Processors have caches, and their caches 
can be invalidated.  However, if 20 was written out to x earlier in the 
same thread, there are no processors that will then allow this print 
statement to write the older value 0.  That's not how memory coherence 
works.

Even if it were how memory coherence worked in some processor (which it 
wouldn't be), it would be a violation of the Java memory model, which, 
as we have discussed, disallows a read of the value 0.  So a Java 
implementation would have to find a way around it.

					Jeremy


More information about the Concurrency-interest mailing list