The crux of what I'm saying is that just because something is said to be undefined in the standard doesn't make it undefined on a particular implementation. In this hypothetical implementation accesses to volatile variables are documented to be atomic, so [intro.race] p17 does not apply and thus the behaviour is well-defined. A behaviour being defined by an implementation is different from something being implementation-defined, if that helps.

On 9 October 2026 08:55:52 BST, jim x <xmh970252187_at_[hidden]> wrote:
>So, what behavior of the program do you think? If you think the program
>should be undefined behavior because the program contains a data race,
>let's step-by-step to go through the rules in [intro.race] p17. It's true
>that `#1` and `#2` are two potentially concurrent conflicting actions, and
>neither happens before the other. The crux is whether they satisfy the
>condition: at least one of which is not atomic. If one of them is
>non-atomic, then the condition is satisfied; therefore, the program
>contains a data race. If they are both atomic operations, the condition is
>false; no data race is contained. As I commented above, since the standard
>lets implementations define the semantics of the access, and a hypothetical
>implementation can define `#1` as `std::atomic_ref<int>(value).load()` and
>`#2` as `std::atomic_ref<int>(value).store(1)`; i.e., they're atomic
>operations, I don't think the crux condition in [intro.race] p17 is true.
>So, the program under this specified semantics shouldn't be UB. How do you
>explain this point?
>
>On Fri, Oct 9, 2026 at 3:39 PM David Brown <david.brown_at_[hidden]> wrote:
>
>>
>>
>> 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.
>>
>>
>>