> > 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
useless.
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.
Jeff
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:31 EDT