RE: locks on X86

["Boehm, Hans" <hans_boehm at hp dot com>]

Bryce wrote:
> But as far as I can figure it would be perfectly reasonable 
> to do synchronization
> elimination when methods are inlined, or perhaps when calling 
> non-virtuals. Even if
> there are side-effects between, say, two synchronizations, it 
> doesn't seem to be
> problem to hold the lock across it because monitors are 
> recursive. We'd have to be a
> bit careful because there are possible performance 
> implications of holding a lock
> for longer than intended, but I don't think theres anything 
> illegal about it because
> there are no guarantees that a lock will actually be given to 
> a different waiting
> thread even if there is non-synchronized code between exiting 
> and re-entering a
> monitor?
> 
There was quite a bit of discussion of this on the Bill Pugh's Java memory
model mailing list.  Currently I believe the rules about completely removing
synchronizations are in general pretty restrictive, since synchronizing on a
thread-local object still has some memory barrier semantics.  I believe that
if x and y are globally visible, then

x = ...
synchronized(local){}
y = ...

still ensures that the assignment to x precedes that to y (for a suitable
definition of what that means), eventhough no useful mutual exclusion is
provided.  Still a memory barrier is likely to be much cheaper than a full
synchronization, especially on X86 where it may affect only reordering by
the compiler.

Hans