Problem is... "volatile" doesn't restrict code motion with respect to non-volatile access. It might do that in specific versions (especially older) of specific compilers, but that's technically out of spec. So while there will be only one read for a volatile read in source code, that read can be moved across any code that isn't qualified with volatile.The volatile type qualifier is supposed to make the compiler generate an instruction that loads the pointer from memory, rather than resorting to a copy that might be already in a register.
I've personally had code that relied on "volatile" back in the days (when compilers treated it basically as a full fence), it was the (kinda) the right thing to do back then, but if compiled with modern compilers, some of that code can produce wrong results.
You can make use of "volatile" in some cases, where it's only important to make sure reads/writes aren't duplicated.. but you need to be very careful that you aren't assuming too much.
Assuming I understand what you mean by this, I'm not sure how this could be violated without also losing single-threaded observationally sequential execution model.I think ARM also maintains data dependency ordering, i.e. writing pPointer->X in C/C++ will always load X that is at least as new as pPointer.
However the ARM model is basically that (looking from the point of view of memory) the CPU cannot reorder writes to the same bytes. So if you write one value at location X, then another value at location Y (with X!=Y), then as far as I can understand the specification another core might observe the write to Y before it observes the write to X. This alone effectively means that you'll need fences to reason anything about multi-threading whatsoever.
Statistics: Posted by mystran — Sat Aug 17, 2024 4:08 pm