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 <+41%2079%20432%2023%2032>
>
> 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
> <https://eel.is/c++draft/intro.races#17>
>>
>> Two actions are *potentially concurrent*
>> <https://eel.is/c++draft/intro.races#def:potentially_concurrent> if
>
> they are performed by different threads, or
>> <https://eel.is/c++draft/intro.races#17>
>
> 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 <https://eel.is/c++draft/dcl.type.cv#5>
> 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
>
>