[concurrency-interest] x86 NOOP memory barriers
vitalyd at gmail.com
Fri Aug 2 06:46:08 EDT 2013
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
> 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...
More information about the Concurrency-interest