![](https://secure.gravatar.com/avatar/d360ec751eb90bc963c5b03544d88cf5.jpg?s=120&d=mm&r=g)
On Wed, Jul 8, 2009 at 12:36 AM, Anton Vodonosov<avodonosov@gmail.com> wrote:
Note, btw, that "synchronized" in java is not only about locking, but also about memory synchronization: the code in the synchronized block is compiled so that other threads see the changes it has made to memory and it sees changes from other threads too. Compiler doesn't cache values in registers or other temporary places.
I just read http://java.sun.com/docs/books/tutorial/essential/concurrency/syncmeth.html Which says "Second, when a synchronized method exits, it automatically establishes a happens-before relationship with any subsequent invocation of a synchronized method for the same object. This guarantees that changes to the state of the object are visible to all threads. " The memory changes are committed (just) before a synch block exits. Not necessarily during the block. Thus I think the caching is allowed. That thought is further supported by http://java.sun.com/docs/books/tutorial/essential/concurrency/memconsist.htm... Of course I may be wrong - but I'd be somewhat surprised if all memory memory access is volatile (in the C sense) during a synchronized block. That would take an enormous perf hit on multi-cpu systems with IPIs and such.