[concurrency-interest] synchronized block expansion

Jeremy Manson jmanson at cs.purdue.edu
Wed Feb 8 18:49:12 EST 2006


Hi,

Although it is legal to expand a synchronized section, it is not legal 
to expand it over another lock acquisition.  That would be bad, for very 
obvious reasons.  You wouldn't, for example, want to introduce of 
deadlock where none previously existed.

Since CountDownLatch.await() is implemented as a lock acquisition, you 
have nothing to worry about.

Having said that, stay paranoid.  Paranoid is good.

					Jeremy

studdugie wrote:
> I'm not sure I will be breaking a concurrency-interest nettiquette by
> posting my question here but I could think of a better place to ask
> it, so if I am, scold me gently :)
> 
> Here is the code fragment in question:
> 
> long wait;
> synchronized( timeouts )
> {
>     if( timeouts.isEmpty() )
>         wait = 0;
>     else
>         timeouts.remove( wait = timeouts.firstLong() );
> }
> 
> if( 0 == wait )
>     semaphore.await();
> else
>     semaphore.await( wait, EnclosingClass.this.units );
> 
> WHERE:
> timeouts = long primitive java.util.SortedSet
> semaphore = java.util.concurrent.CountDownLatch w/ a count of 1
> EnclosingClass.this.units = java.util.concurrent.TimeUnit
> 
> I know that code w/i a synchronized block code is not allowed to be
> reordered but that doesn't mean that the scope of the synchronized
> block can't be expanded.  So my question is, what is the probablity
> that Sun's hotspot compiler would expand the synchronized block to
> include the semaphore.await() ? Or am I just being paranoid?
> 
> Dane
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list