On Mon, Feb 22, 2021, at 16:28, Paul M. Bendixen via SG14 wrote:
>
>
> If anyone can come up with a formulation of the "We don't know what we are getting.If it is possible to get atomicity we would love it, but we know that is rarely the case" sentence that doesn't sound completely idiotic, I'll credit whoever can come up with it with coauthor credits. :D
>
Seeing as nobody else has replied (at least not publicly) I'll make my poor stab at this:

"It shall be implementation defined what conditions are required for the memory modification to be an atomic operation. In all other situations, if the value in the memory changes between the read and write, then result of this operation is undefined. Note that there is no requirement for any atomic updates."

The implementation defined part is because as a user I want to know when I can depend on atomic updates. This is mostly of concern in embedded where we can get the required hardware changes made to support atomic operations, but we need to know exactly what is required from (both hardware and compiler configuration) to make it work. By making it defined we ensure there is some document to work with.

The undefined behavior part means that this needs to go to SG12, but I think they will agree that is an acceptable use of undefined behavior. This is what it implicitly was before anyway.

I carefully did not use the word thread above. The C++ virtual machine has a concept of thread that doesn't cover all of the race conditions that might happen. Both a different process modifying memory, and also the hardware itself may change the memory, and both are outside of the control of the virtual machine.

I'm sure somebody can do better, but maybe I inspired something.