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

Nathan Reynolds nathan.reynolds at oracle.com
Tue Apr 16 18:01:52 EDT 2013


All things being equal, reading a volatile and non-volatile field from 
L1/2/3/4 cache/memory has no impact on performance.  The instructions 
are exactly the same (on x86).

Writing a volatile and non-volatile field to cache/memory has an impact 
on performance.  Writing to a volatile field requires a memory fence on 
x86 and many other processors.  This fence is going to take cycles.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Architect | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
On 4/16/2013 2:49 PM, thurstonn 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/20130416/c18e3ed8/attachment.html>


More information about the Concurrency-interest mailing list