[concurrency-interest] Semantics of compareAndSwapX

Stephan Diestelhorst stephan.diestelhorst at gmail.com
Thu Feb 27 16:43:40 EST 2014

Am Donnerstag, 27. Februar 2014, 08:53:47 schrieb Hans Boehm:
> As far as I know, the ARMv8 acquire/release operations were designed
> specifically to act as Java volatile or C++ memory_order_seq_cst load/store
> operations, without the kind of ordering overkill that we currently need on
> x86, i.e. they were designed to get us to the "better world".

I would agree (my personal view).

> My main remaining concern is that we don't have a complete, much less
> provably correct, mapping of either Java or C++ atomics to this ISA.  This
> leaves a risk that some corner cases, e.g. C++ explicit fences, will be
> difficult to implement correctly in this model.

Explicit fences should stay explicit fences (DMB) in ARM, I think.

> I am also not at all sure whether the traditional ARMv7 mappings mix
> and match with an acquire/release based mapping.  These mappings
> should really be specified in some kind of ABI addednsum.  (But there
> are already similar issues with ARMv7 by itself, and with some other
> architectures.)

Not quite sure what the worry is, here.  Proper fences (DMBs) behave as
they should (unless you consider TLBs, self- / cross-modifying code);
with ld.acq / st.rel being "fenced in" by them.  I am surely missing
something here (transitivity?), so: did you have a specific problematic
case in mind?


More information about the Concurrency-interest mailing list