Data Race Is Not Race Condition

1// DATA RACE — undefined behaviour under the C++ memory model.
2int   data  = 0;
3bool  ready = false;
4 
5void producer() { data = 42; ready = true; }          // two plain writes
6void consumer() { while (!ready) {} print(data); }    // plain reads, unsynchronized
7 
8// The standard says: conflicting non-atomic accesses with no happens-before
9// relation => undefined behaviour. Legal outcomes include printing 0, hanging
10// forever because the compiler hoisted the load of 'ready' out of the loop,
11// or working perfectly at -O0 and failing at -O2.
12 
13// FIXED — atomics create the happens-before edge the model requires.
14std::atomic<int>  data{0};
15std::atomic<bool> ready{false};
16void producer() { data.store(42, std::memory_order_relaxed);
17                  ready.store(true, std::memory_order_release); }
18void consumer() { while (!ready.load(std::memory_order_acquire)) {}
19                  print(data.load(std::memory_order_relaxed)); }   // prints 42

A data race is undefined behaviour, full stop. The fix is not "add a delay" or "make it volatile" — volatile is about device memory and gives no ordering. The fix is an atomic or a mutex, which establishes happens-before.

1// Within one isolate: NO data race is possible on ordinary objects.
2let data = 0, ready = false
3async function producer() { data = 42; ready = true }
4async function consumer() { if (ready) console.log(data) }
5// Only one task runs at a time; nothing interleaves mid-statement.
6// A RACE CONDITION is still easy:
7async function consumer2() {
8  if (ready) { await audit(); console.log(data) }   // data may have changed
9}
10 
11// Across workers sharing a SharedArrayBuffer: data races ARE possible,
12// and Atomics is the only correct tool.
13const buf = new Int32Array(new SharedArrayBuffer(8))
14Atomics.store(buf, 0, 42)         // ordered
15Atomics.store(buf, 1, 1)          // release-ish; pair with Atomics.load

Two regimes in one language. Ordinary objects in one isolate cannot data-race because there is no simultaneity. SharedArrayBuffer between workers is real shared memory with a real memory model, and only Atomics operations are ordered.

1// TypeScript adds no runtime concurrency semantics whatsoever.
2// The type system cannot express "this field is only read under lock L".
3interface Promo { remaining: number }
4const promo: Promo = { remaining: 1 }
5 
6async function redeem(p: Promo) {
7  if (p.remaining > 0) {        // check
8    await load()                //   <- the type checker is perfectly happy
9    p.remaining -= 1            // act on a stale fact: RACE CONDITION
10  }
11}
12// readonly / Readonly<T> are compile-time only and are erased at runtime;
13// they document intent and enforce nothing about concurrent access.

The same runtime as JavaScript, therefore the same answer: no data races within an isolate, and no help at all with race conditions. Type-level readonly is erased and must not be read as a concurrency guarantee.

1# CPython 3.12, threading module.
2data, ready = 0, False
3def producer(): 
4    global data, ready
5    data = 42
6    ready = True                 # each STORE_NAME is one bytecode: not torn
7 
8def consumer():
9    if ready: print(data)        # may print 0 if scheduled between the two stores
10 
11# No torn values: the interpreter lock serialises bytecode execution, so you
12# never observe a half-written object reference. That is NOT the same as
13# atomicity of a statement:
14counter = 0
15def inc():
16    global counter
17    counter += 1                 # LOAD_NAME, LOAD_CONST, BINARY_OP, STORE_NAME
18                                 # -> a switch between them loses updates.
19 
20# Free-threaded builds (PEP 703, 3.13+ experimental, GIL disabled) change the
21# first guarantee: without the interpreter lock, ordinary attribute access
22# from multiple threads needs real synchronization.

CPython gives no torn reads or writes because bytecode execution is serialised, which removes the low-level data race on ordinary objects. Multi-bytecode statements are not atomic, so race conditions are as available as anywhere else — and the free-threaded build removes even the first guarantee.