__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 not defined on aarch64

[Richard Earnshaw]

On 28/06/17 08:27, Toebs Douglass wrote:
> On 28/06/17 00:45, Richard Earnshaw wrote:
>> On 27/06/17 22:58, Toebs Douglass wrote:
>>> On 27/06/17 23:53, Richard Earnshaw wrote:
>>>> This is correct.  AArch64 cannot do the 16-byte atomic compare and swap
>>>> and needs lock operations.
>>>
>>> I may be completely wrong, but I think it can.
>>>
>>> ARM (32-bit) supported double-word LL/SC from arm6k and armv8 I think
>>> had it from day one.  CAS is mapped onto LL/SC.
>>>
>>> I've written asm to do this, the key is the ldxp and stxp instruction,
>>> and it seems to work.
> 
>> Only *seems* to work.  The ldxp operation is *NOT* atomic and atomicity
>> is only guaranteed if a store back of the original read value completes.
> 
> Yes.  There's a loop, calling ldxp/stxp, which continues until either
> the compare fails or the store was successful.
> 
>> In general this makes ldxp not useful for atomic operations since we
>> cannot guarantee that the location is writable.
> 
> I'm not quite sure what this means.  I mean, I know what it means in a
> literal and straightforward sense, but not in a larger sense.  From my
> POV, writing user-mode code, aarch64 seems no different to any other
> platform.  I have memory, I write to it, it gets written to.
> Non-writeable memory would be ROM, no?  I wouldn't expect store returned
> by malloc or allocated on stack won't be placed in ROM, and that's how I
> get store to LL/SC on.
> 

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.  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.

R.