One of the grounds for your claim that the program exhibits undefined behavior is that you determined it contains a data race based on [intro.race] p17. But the very issue is: where does the standard state that an access to a volatile glvalue is non-atomic? The standard does not even define the semantics of such accesses and leaves them implementation-defined, making it even less possible to assert that accesses to a volatile glvalue are non-atomic. How, then, can you conclude based on [intro.race] that this program contains a data race?

On Sun, Oct 11, 2026 at 1:28 PM Peter C++ <peter.cpp_at_[hidden]> wrote:

without having looked at all the replies I judge this program to have undefined behavior because of the data race. 

what an implementation does in a concrete translation doesn't make the program well-defined. 

Regards

Peter. 

sent from a mobile device so please excuse strange words due to autocorrection. 

Peter Sommerlad

peter.cpp_at_[hidden]

+41-79-432 23 32

On 9 Oct 2026, at 14:11, jim x via Std-Discussion <std-discussion_at_[hidden]> wrote:



Consider this example:

````cpp

#include 

int main(){
  volatile int value = 0;
  std::jthread t1([&](){
    auto i = value; // #1
  });
  std::jthread t2([&](){
     value = 1; // #2
  });
}

````

People think this program should contain a data race because `#1` and `#2` are non-atomic operations, which satisfies the condition in [intro.races] p17

Two actions are potentially concurrent if

      they are performed by different threads, or

The execution of a program contains a data race if it contains two potentially concurrent conflicting actions, at least one of which is not atomic, and neither happens before the other, except for the special case for signal handlers described below. Any such data race results in undefined behavior ([ub:intro.races.data]). 

 However, this opinion is based on the premise that they consider the operations at `#1` and `#2` to be non-atomic operations in any way. However, [dcl.type.cv] p5 simultaneously states:

The semantics of an access through a volatile glvalue are implementation-defined.

How about if a hypothetical implementation specifies the semantics as follows:

An access to a volatile int glvalue value is defined to have the exact semantics of std::atomic_ref<int>(value).load() for reads, and std::atomic_ref<int>(value).store() for writes.

Under these specified semantics, `#1` and `#2` should be considered as atomic operations, which won't satisfy the condition in [intro.race] p17, therefore no data race. From this perspective, isn't the program implementation-defined behavior? That is, whether the program contains a data race depends on how the implementation specifies the semantics

--
Std-Discussion mailing list
Std-Discussion_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion