[concurrency-interest] Synchronization of data read by multiple threads

Gregg Wonderly gergg at cox.net
Wed Oct 26 10:56:22 EDT 2005


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


More information about the Concurrency-interest mailing list