locks on X86

Wed Mar 14 17:25:00 GMT 2001

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