__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 not defined on aarch64

[Andrew Haley]

On 28/06/17 15:55, Richard Earnshaw wrote:
> It's a consequence of 'const' on pointers (and references) in C and C++
> meaning "cannot be modified in this context" but not precluding being
> modifiable in another context.  I can have const and non-const pointers
> to the same object in different threads.
> 
> If something is marked const I have no idea in general whether the
> program will cause a fault if the object is written to, or if the write
> will succeed anyway (it might be in a page marked as write-disabled, for
> example in the program text).
>
> So pointers to const atomic objects cannot use an LDXP/STXP loop because
> that might cause a fatal memory error but must also deal with the
> underlying object not being really constant and thus might be partially
> modified when accessed.

I agree, they can't.  They can't use compare-and-swap at all, because
CAS writes to the object, and you can't do that with a pointer to const.

> The only solution to that is to have a secondary lock on the object.
> And, of course, this becomes ABI; so once you start doing it, it's
> pretty much impossible to change it later since that would require a
> complete rebuild of the world.

I think I get that, but I still don't see how the fact that you can't
atomically read a double-word affects whether double-word CAS should be
supported on its own.  Double-word CAS is very useful, regardless of
the other operations.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671