> > > 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.
I did misspeak. I apologize for this. I am not sure that empty
synchronized blocks should be gotten rid of, because a) it would be
complicated and b) I am not sure it would be worth the effort to make it
comprehensible or to understand it, and c) I am not sure that an
experienced programmer shouldn't be able to use them for memory semantics.
Of course, there is d) no one who doesn't understand the semantics should
use it at all, which can always be tricky.
If a compiler is clever enough it might be able to have memory semantics
associated with empty synch blocks without actually performing a mutex
(that's off the top of my head, so I am not sure if it is right or not).
This could prevent the need for the marginally increased overhead from
performing a volatile write and a volatile read... Wouldn't buy much
though.
Jeremy
-------------------------------
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