I admit that I'm not 100% perfect with the various memory models at play here. But my understanding is...

1. Seq-cst -- Strongest/slowest. (Aka: Java volatile)

2. Total Store order (aka: x86)

3. Acq-Release (aka: newer-ARM / newer-POWER)

4. Acq-Consume (aka: old-ARM / old-Power)

5. Relaxed -- Weakest/fastest, DEC Alpha.

That is to say, acquire-release is often compiled into no-op on x86, because x86 Total-store ordering is "stronger" than acquire-release.

Acquire-Consume was thought to be sufficient, but C++11 debate argued otherwise, and designed a stronger Acquire-release model. ARM/POWER designers then implemented acquire-release model.

--------

I understand that things aren't perfectly linear, and that at the lower level the discussion is about read/read, read/write, write/read, and write/write barriers. But my brain has never really grok'd this level of detail. (Instead, I think in terms of the simplified list above). So please correct me if I'm wrong with the above assumptions.

An acquire+release fence is equivalent to two indivisible acquire and release fences but can't be implemented by simply issuing the two fences in isolation, as they would be unordered with each other. x86 has no native acq+relase fence and it can't be simulated, for example, with a load plus a store (i.e. separate acquire and release fences), but you need an mfence or atomic rmw.

ARM and power do allow for indipendent reads of indipendent writes (or maybe only power) so in principle an acq+rel fence could be cheaper than a full seqctst one, although I don't know if it is in practice.

ARMv8.3-A added the new instruction LDAPR to allow acq_rel to be cheaper than seq_cst, so presumably it was worth adding.

This summarises (https://community.arm.com/arm-community-blogs/b/architecture...):

"The Armv8.0 support for release consistency is based around the “RCsc” (Release Consistency sequentially consistent) model described by Adve & Gharacholoo in [1], where the Acquire/Release instructions follow a sequentially consistent order with respect to each other. This is well aligned to the requirements of the C++11/C11 memory_order_seq_cst, which is the default ordering of atomics in C++11/C11."

"Instructions are added as part of Armv8.3-A to support the weaker RCpc (Release Consistent processor consistent) model where it is permissible that a Store-Release followed by a Load-Acquire to a different address can be re-ordered. This model is supported by the use of memory_order_release/ memory_order_acquire /memory_order_acqrel in C++11/C11."

right, but the point is, does ARM have acq-rel RMWs that are not sequentially consistent? I guess you could build one with separate acq/rel load and stores and ll/sc. edit: or not, as the store and load will still be unordered with each other and the ll/sc does nothing here.