On 09/10/2026 09:16, jim x via Std-Discussion wrote:
> If the implementation defines that accesses to volatile variables
> are atomic, then they are atomic.
>
>
> In this case, does the program contain a data race as per [intro.race]
> p17? If not, since the behavior depends on how the implementation define
> the semantics, does that mean the behavior of the program should be
> implementation-defined?
>

"Implementation-defined" in the standards does not just mean that the
implementation has to treat the construct in some particular way. It
means that the standard gives a range of options of how the
implementation should handle the construct, and that the implementation
must document how it handles them.

If an implementation's manual says that volatile accesses are atomic
(not unreasonable on single-core non-superscaler targets like most
microcontrollers), then the programmer can rely on the volatile accesses
being atomic. But that does not mean unsynchronised volatile accesses
to the same address in different threads is implementation-defined
behaviour, or should be called such in the C++ standards.