c++ - What formally guarantees that non-atomic variables can't see out-of-thin-air values and create a data race like atomic relaxed theoretically can?

Question

This is a question about the formal guarantees of the C++ standard.

The standard points out that the rules for std::memory_order_relaxed atomic variables allow "out of thin air" / "out of the blue" values to appear.

But for non-atomic variables, can this example have UB? Is r1 == r2 == 42 possible in the C++ abstract machine? Neither variable == 42 initially so you'd expect neither if body should execute, meaning no writes to the shared variables.

// Global state
int x = 0, y = 0;

// Thread 1:
r1 = x;
if (r1 == 42) y = r1;

// Thread 2:
r2 = y;
if (r2 == 42) x = 42;

The above example is adapted from the standard, which explicitly says such behavior is allowed by the specification for atomic objects:

[Note: The requirements do allow r1 == r2 == 42 in the following example, with x and y initially zero:

// Thread 1:
r1 = x.load(memory_order_relaxed);
if (r1 == 42) y.store(r1, memory_order_relaxed);
// Thread 2:
r2 = y.load(memory_order_relaxed);
if (r2 == 42) x.store(42, memory_order_relaxed);

However, implementations should not allow such behavior. – end note]

What part of the so called "memory model" protects non atomic objects from these interactions caused by reads seeing out-of-thin-air values?

---

When a race condition would exist with different values for x and y, what guarantees that read of a shared variable (normal, non atomic) cannot see such values?

Can not-executed if bodies create self-fulfilling conditions that lead to a data-race?

Answer 1

When a race condition potentially exists, what guarantees that a read of a shared variable (normal, non atomic) cannot see a write

There is no such guarantee.

When race condition exists, the behaviour of the program is undefined:

[intro.races]

Two actions are potentially concurrent if

• they are performed by different threads, or
• they are unsequenced, at least one is performed by a signal handler, and they are not both performed by the same signal handler invocation.

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. ...

The special case is not very relevant to the question, but I'll include it for completeness:

Two accesses to the same object of type volatile std::sig_-atomic_-t do not result in a data race if both occur in the same thread, even if one or more occurs in a signal handler. ...