3 ms·
First you said that the modern way is to use acquire/release instead of a barrier, then admitted that it is a barrier at the compiler level. The fact that it do
by notacoward 7y ago
First you said that the modern way is to use acquire/release instead of a barrier, then admitted that it is a barrier at the compiler level. The fact that it doesn't require a barrier instruction on the x86 is pretty much irrelevant. Not all the world's an x86, and even the x86 hasn't always been the same in this regard. So your rude "nope" is unwarranted. This attitude of "as it is (in my world) now, so it has ever been and ever will be (everywhere)" is exactly why these bugs occur.
- loeg 7y agoCompiler barriers and machine barriers are completely different things, despite having a similar name. In about the era you described, the Linux kernel community did go around throwing rmb()s and wmb()s everywhere, and those did translate to hardware fences. (And in general, it is not safe to elide a hardware fence on x86 despite relatively strong memory ordering.) This is what I believed you were talking about; maybe I misunderstood: apologies. Putting explicit compiler barriers in code is still not quite the modern model for relaxed atomic consumers. You use the abstract acquire/release load/store pseudo-functions, and they do the right thing depending on implementation. The compiler barriers in the relaxed atomics model are an internal implementation detail, not the API. x86 is just an example where the cheapest way to do a release-semantics store is a plain store. I never said all the world was x86 — if it were, abstract acquire/release relaxed atomics would be kind of pointless.