[concurrency-interest] Synchronization of data read by multiplethreads

Boehm, Hans hans.boehm at hp.com
Wed Oct 26 13:37:38 EDT 2005


I think there is another related issue here, which came up in the JSR133
discussions.

Assume you have two threads (stopped initially true):

Thread 1:

while (stopped) {}

Thread 2:

...
stopped = false;

Even if the compiler doesn't "optimize" thread 1 into an infinite loop,
there is no guarantee that a uniprocessor scheduler would ever schedule
thread 2 after thread 1 gets a chance to run.  Indeed, a number of older
JVMs wouldn't ever run thread 2 again, and I think some current more
specialized JVMs still won't.  These two scenarios are not quite
indistinguishable in general, but they're close.  Thus, compiler
optimizations aside, code like this is a bit brittle, even if stopped is
declared volatile.

If you wanted to prevent the compiler optimization, things like this
make that tricky to specify (or to take advantage of).

Hans

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu 
> [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf 
> Of Gregg Wonderly
> Sent: Wednesday, October 26, 2005 7:56 AM
> To: concurrency-interest at altair.cs.oswego.edu
> Subject: Re: [concurrency-interest] Synchronization of data 
> read by multiplethreads
> 
> 
> Brian Goetz wrote:
> >  > I don't believe this is a valid optimization.  If the 
> visibility of  
> > > stopped is such that it can be referenced outside of the 
> context the  
> > > compiler is optimizing, then it can't possibly make this 
> change to 
> > the  > code.  In that code, it would be perfectly valid for 
> someone to 
> > code
> > 
> > You would be incorrect, then.
> > 
> > To put it in terms of the new JMM: the compiler can prove that the 
> > only
> > writes to a non-volatile 'stopped' that can happen-before 
> the next read 
> > to stopped occur in the body of the loop.  If it can prove 
> that there 
> > are no such writes in the body of the loop, it becomes 
> loop-invariant 
> > and can be hoisted.
> 
> I won't dispute that it can do this.  My argument is that 
> hoisting the loop 
> control as a loop invariant, is almost never what a user 
> wants, unless they are 
> specifying a constant for control.  Typically there is a 
> mistake in the 
> software, as we are discussing here, which needs to be fixed. 
>  People make 
> mistakes.  They are imperfect.  It's fun and challenging to 
> do the work to make 
> your optimizer this smart.  I just think JIT design should 
> take a safe approach 
> to considering the intent of a user, or allow the user to 
> turn it off (which we 
> can still in Sun's JVM).
> 
> If I decide that I want my software loop to be controlled by 
> a lazy read on an 
> unsynchornized/non-volatile value so that eventually, it 
> changes its behavior 
> based on that value, but I don't care when, there is no means 
> to do that given 
> what the JMM says.
> 
> I have to undergo the potential system impact of using 
> volatile/synchronized 
> access.  For highspeed, active application logic, where large 
> areas of memory 
> are touched, a user today, casually familar with typical 
> caching will guess that 
> they'll eventually see changes.  The JMM says that this can't 
> be guarenteed.
> 
> I am not sure that we are actually adding value to the Java 
> proposition by 
> creating the expectation from the JITs perspective that all 
> out optimizations 
> are possible now that volatile has a meaning.  I understand, 
> potentially, how 
> important that can be to performance.  I'm just frightened by 
> some of the 
> thoughts that go through my head based on some of the Java 
> software that I've 
> seen over the years.
> 
> I'm lamenting more about the state of things, then trying to 
> argue that my 
> thinking should somehow be right.
> 
> Thanks for putting down words and examples for others to read 
> here to help them 
> understand all the ins and outs that they need to consider.
> 
> Gregg Wonderly
> _______________________________________________
> 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