[concurrency-interest] x86 NOOP memory barriers

Nitsan Wakart nitsanw at yahoo.com
Fri Aug 2 07:25:21 EDT 2013

Can the writes get re-ordered on the hardware level?

Don't volatile reads(LOAD/LOAD) also require reads to not get re-ordered to maintain happens-before/after relationships?

 From: Vitaly Davidovich <vitalyd at gmail.com>
To: Nitsan Wakart <nitsanw at yahoo.com> 
Cc: Concurrency Interest <concurrency-interest at cs.oswego.edu> 
Sent: Friday, August 2, 2013 12:46 PM
Subject: Re: [concurrency-interest] x86 NOOP memory barriers

I'm not an authority so take this for what it's worth...
Yes, volatile loads and lazySet do not cause any cpu fence/barrier instructions to be generated - in that sense, they're nop at the hardware level.  However, they are also compiler barriers, which is where the "cheap but aint free" phrase may apply.  The compiler cannot reorder these instructions in ways that violate their documented/spec'd memory ordering effects.  So for example, a plain store followed by lazySet cannot actually be moved after the lazySet; whereas if you have two plain stores, the compiler can technically reorder them as it sees fit (if we look at just them two and disregard other surrounding code).
So, it may happen that compiler cannot do certain code motion/optimizations due to these compiler fences and therefore you have some penalty vs using plain load and stores.  For volatile loads, compiler cannot enregister the value like it would with plain load, but even this may not have noticeable perf diff if the data is in L1 dcache, for example.
Sent from my phone
On Aug 2, 2013 5:55 AM, "Nitsan Wakart" <nitsanw at yahoo.com> wrote:

>For clarity's sake I'd like an official explanation for the often quoted "all barriers except STORE/LOAD are a no-op on x86" statement from the JMM cookbook.
>Can someone (of authority, so I can later say: "But Mr. Authority here says...") please confirm/expand on/deny that while a volatile read or an AtomicLong.lazySet are a CPU noop (in the sense that they are a MOV like any other), they are also compiler instructions. One cannot simply replace a lazySet with a plain write to get the same effect. They might be cheap but they ain't free... 
>I would appreciate some more careful wording on this topic.
>Many thanks,
>Concurrency-interest mailing list
>Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130802/30500d32/attachment.html>

More information about the Concurrency-interest mailing list