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