[concurrency-interest] Semantics of compareAndSwapX
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
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