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.
