1. “volatile” is not atomic, I don’t know where you got that idea.
2. Even with atomics there would be a data race, at least in the sense that running it multiple times will yield different results. Atomics only guarantee visibility of different types of side-effects (depending on the type of atomic operation)
they do not the synchronize the execution across different threads. This is not exactly UB, what it does is actually very well defined, but the outcome of the operation is dependent on a factor that you neither control or the language specifies.
From: Std-Discussion <std-discussion-bounces@lists.isocpp.org>
On Behalf Of jim x via Std-Discussion
Sent: Friday, October 9, 2026 08:28
To: Jennifier Burnett <jenni@jburnett.me.uk>
Cc: jim x <xmh970252187@gmail.com>; jim x via Std-Discussion <std-discussion@lists.isocpp.org>
Subject: Re: [std-discussion] Is this program undefined-behavior or implementation-defined behavior?
The issue is not whether an implementation can
guarantee a specific behavior for an operation that has UB. The issue is why the operations at `#1` and `#2` are still considered non-atomic under the concrete semantics: 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.
The premise you think the program is UB is that you think such two operations are non-atomic and therefore cause the program to contain a data race as per [intro.race] p17. My question is why such two operations are non-atomic under [intro.race]
p17 when their semantics are specified as: 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.
On Fri, Oct 9, 2026 at 2:16 PM Jennifier Burnett <jenni@jburnett.me.uk> wrote:
I'm not sure there's a conflict? Implementations are perfectly allowed to define undefined behaviour to have some specific behaviour. I'm allowed to create an implementation that has a defined behaviour for *all* data races, for example.
The standard says that anything can happen when undefined behaviour occurs, and implementation-defined behaviour does fall under the category of "anything".
On 9 October 2026 06:11:15 BST, jim x via Std-Discussion <std-discussion@lists.isocpp.org> 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