Re: __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 not defined on aarch64

[Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>]

On 28/06/17 16:08, Toebs Douglass wrote:
> On 28/06/17 16:55, Richard Earnshaw wrote:
>> On 28/06/17 08:27, Toebs Douglass wrote:
> 
>>> 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.
> 
> Yes.
> 
>> 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).
> 
> Yes.  But if I write to something I marked const, I've blundered.  It
> seems no different to writing to store I have say already freed.
> 

the difference is that for an atomic object I can only tell if the read
was successful by forcing a write.  The program doesn't conceptually
write to the location, but the hardware requires it.  I can't use such a
sequence on a const object because it might really be non-writable.

>> 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.
> 
> Wouldn't this just be considered undefined behaviour?
> 
> I may be wrong, but wouldn't the points made here also apply to normal
> writes?
> 
> 

A normal write to a const object is plain forbidden by the language -
this is a layer below that.

R.