[concurrency-interest] On A Formal Definition of 'Data-Race'

Stanimir Simeonoff stanimir at riflexo.com
Tue Apr 16 19:31:42 EDT 2013

Technically, the JVM is free to ignore the write if it considers it may not
visible (according to JMM) to any other thread it's not being read by the
Now, on reading non-volatile it's where it comes tough: while(!stopped){}
can be transformed to if (!stopped) for(;;){}. The latter transformation
happens for real.

I seriously do not get the idea to skip volatiles. They are relatively
cheap in terms of performance and avoiding them can cause serious problems.
It may work on some JVM/CPU but fails on an updated JVM.
Overall unannotated/commented dataraces should be considered a bug.


On Wed, Apr 17, 2013 at 12:49 AM, thurstonn <thurston at nomagicsoftware.com>wrote:

> I'm wondering if the stopped-flag code were to run on a modern CPU (i.e.
> with
> cache coherency), would there be any practical difference between
> declaring:
> boolean stopped = false
> vs.
> volatile boolean stopped  = false
> /Note: I'm not advocating the non-volatile, 'broken' version; of course you
> should write to the JMM, that's its purpose. I really feel for engineers
> who
> have to write for multiple CPUs/MMs; I don't know how they manage./
> But given cache coherency, let's say you were to run the code a gazillion
> times and could count the # of loops after setting this.stopped = true.
> Should one expect some (even if negligible) difference between the two
> versions?  I suppose it would depend on a lot of things (is #stopped
> cached,
> false-sharing effects, etc), but due to cc, the run thread, even in the
> non-volatile version,  should eventually see this.stopped == true -- hmm
> unless the JIT were to do the kind of code 'optimization' that Greg showed
> (hoisting this.stopped out of the loop), which I guess is allowed.
> --
> View this message in context:
> http://jsr166-concurrency.10961.n7.nabble.com/On-A-Formal-Definition-of-Data-Race-tp9408p9454.html
> Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130417/436ee938/attachment.html>

More information about the Concurrency-interest mailing list