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