RE: JavaMemoryModel: Re: JMM problems with latch or copy-on-write?

From: Jeff Bogda (
Date: Fri Mar 30 2001 - 12:43:01 EST

> > Specifically, transmission is guaranteed if the initializing thread
> > subsequently releases a lock or writes to a volatile variable *and* the
> > reading thread subsequently acquires the same lock or reads the same
> > volatile variable.
> >
> > Example, in sequence:
> >
> > thread 1: initialized = true
> > thread 1: synchronized(obj) { }
> > thread 2: synchronized(obj) { }
> > thread 2: assert(initialized == true)
> Eep! That won't work, because in our model (again, can't speak for CRF),
> useless synchronization can be optimized away. Plus, oh, your next point.

One may argue that this synchronization is not useless because it makes the
value "true" for "initialized" visible to thread 2. However, I agree with
Jeremy (although I am not sure where in his paper he states this) and feel
that these synchronized blocks (like all empty synchronized blocks) are

As it stands now, there is nothing that prevents thread 2 from executing
before thread 1, regardless of "initialized"'s being volatile or not. Thus,
in some executions the assertion will fail. If the programmer wants thread 2
to always execute after thread 1, then he needs additional thread control
(such as wait/notify, Thread.start(), or spinning on a volatile). And if he
has that, then the value "true" will propagate to thread 2 without the empty
synchronized blocks.

In short, I'd say that a program that relies on the synchronization of obj
to see values has a programming error.


JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:31 EDT