Race Conditions

1Definition — A Property of Timing, Not of Code Reading Wrong

A race condition is a bug where the correctness of a result depends on the relative timing or interleaving of operations that access shared, mutable state — not on any operation individually being wrong. Every step in the buggy execution is individually correct; the bug only appears from a specific ordering of otherwise-correct steps happening across concurrent tasks.

This makes race conditions uniquely nasty: they are non-deterministic (the same code can run correctly a thousand times and fail on the thousand-and-first, depending on scheduling), they often disappear under a debugger (adding a breakpoint changes timing enough to hide the interleaving that triggers the bug), and they require genuine concurrent execution — a topic this stack now assumes from Concurrency vs Parallelism — over shared mutable state to exist at all.

2The Classic Example: counter++ Is Three Operations, Not One

counter++ looks like a single atomic step in source code. It is not — it compiles to (at least) three distinct machine-level operations: read the current value, modify it (add 1), write the new value back. Any of those three steps can be interrupted by another thread doing the same three steps on the same memory location.

Thread A: local_A = counter        // read:  local_A = 0
Thread B:                          local_B = counter        // read:  local_B = 0  (BEFORE A writes back!)
Thread A: local_A = local_A + 1    // modify: local_A = 1
Thread A: counter = local_A        // write: counter = 1
Thread B:                          local_B = local_B + 1    // modify: local_B = 1  (using the STALE 0 it read)
Thread B:                          counter = local_B        // write: counter = 1  (clobbers A's update!)

Two increments happened. counter ends at 1, not 2. One update is LOST.

This is called a lost update, and it is the canonical race condition: nothing crashed, no exception was thrown, every individual line executed exactly as written — the bug exists purely in the interleaving of steps 2 and 3 above. Note this requires genuine simultaneity or preemption between the read and write of at least one thread — exactly the parallel or preemptively-scheduled execution described in the previous topic's Under the Hood section.

3Data Race vs. Race Condition — Related but Distinct

These terms are often used interchangeably but mean different things:

• A data race is a specific, narrower condition: two or more threads access the same memory location concurrently, at least one access is a write, and there is no synchronization ordering the accesses. In languages with a formal memory model (C++, Rust, Java), an unsynchronized data race is technically undefined behavior — the compiler and CPU are allowed to reorder, cache, or tear the access in ways that produce results stranger than "just" a lost update.
• A race condition is the broader, higher-level bug: the outcome depends on timing. A race condition can exist without a technical data race — the classic example is a TOCTOU (time-of-check to time-of-use) bug, where a check and a later action are individually safe and even properly synchronized in isolation, but another process can act in the gap between them:

// TOCTOU race — no shared-memory data race, still a race condition:
if (!fileExists(path)) {   // CHECK: file doesn't exist
  // <-- another process creates the file HERE, in the gap -->
  createFile(path);          // USE: overwrites the file that now exists
}

Every concurrency-safety technique in section 5 addresses race conditions in general; only some of them (locks, atomics) specifically target true data races on shared memory.

4Where Race Conditions Hide in Real Systems

• Check-then-act: checking a condition, then acting on it, with a gap where another task can invalidate the check (the TOCTOU pattern above; also "check if a row exists, then insert it" without a unique constraint).
• Read-modify-write on shared counters/balances: the counter++ pattern generalized — account balance updates, inventory decrements, rate-limit counters.
• Double-submit / duplicate processing: a user double-clicks "Pay," or a network retry resends a request, and two concurrent handlers both act on it before either has recorded that it happened (this is exactly what idempotency, covered in the Failure Handling topic, is designed to prevent).
• Cache stampede / thundering herd on cache-miss: many concurrent requests all miss a cold cache simultaneously, all check "is it cached?", all get "no," and all proceed to regenerate the same expensive result at once.
• Lazy initialization without guarding: two threads both check "has the singleton been created?", both see "no," and both construct it — producing two instances where the code assumed exactly one.

5Fixing Race Conditions

6Race Conditions Still Happen in Single-Threaded Runtimes

A common misconception is that a single-threaded model (like JavaScript's — see languages/javascript/34-concurrency) is immune to race conditions because "only one thing runs at a time." That protects against races within a single synchronous block of code (nothing can interrupt you mid-expression), but it does not protect against races across await boundaries, because control genuinely returns to the event loop at each await and another task can run — including one that mutates the same state:

// Async TOCTOU race — single thread, still racy:
async function reserveSeat(seatId) {
  const seat = await db.getSeat(seatId);   // CHECK — control yields here; another
                                            // call to reserveSeat can now run fully
  if (seat.available) {
    await db.markReserved(seatId);           // USE — may double-book if two calls
  }                                             // both passed the check before either wrote
}

Two concurrent calls to reserveSeat can both read available: true before either writes reserved, double-booking the seat — on a single thread, with no true data race, purely because of await-boundary interleaving (see languages/javascript/29-promises and 27-event_loop for exactly how the event loop schedules the resumption of each await).

CAS(address, expected, new_value):
  atomically:
    if *address == expected:
        *address = new_value
        return true   // success — no one else touched it in between
    else:
        return false   // someone else changed it first — caller must retry

atomicIncrement(address):
  loop:
    old = *address                       // read current value
    new = old + 1
    if CAS(address, old, new): return new  // succeeds only if nothing changed it since the read
    // else: someone else updated it between our read and our CAS — retry with the fresh value

⚠️ Common Pitfalls

1. Assuming an operation is atomic because it looks like one line — counter++, x += 1, and even some higher-level "atomic-looking" library calls can hide multiple steps; verify explicitly rather than assuming.
2. Believing single-threaded (JS-style) code can't have race conditions — true within one synchronous block, false across await/callback boundaries where another task can interleave (section 6).
3. Fixing the symptom by adding a delay ("it works if I sleep here") — this doesn't fix the race, it only makes the buggy interleaving less likely, which reappears under different load, hardware, or timing (and is famously hard to reproduce and debug once it does).
4. Locking too narrowly, protecting only part of a multi-step invariant — e.g., locking around the read and separately around the write of a check-then-act sequence, leaving the gap between them unprotected; the lock must span the entire read-decide-write sequence.
5. Using a data race fix (an atomic/lock) for a problem that isn't a data race — a TOCTOU race across separate systems (e.g., two microservices) can't be fixed with a local mutex; it needs a distributed coordination mechanism (a unique constraint, distributed lock, or idempotency key — see Failure Handling and Resilience topics).

📋 Quick Reference

Race condition: outcome depends on TIMING of access to shared mutable state
Data race: race condition ON THE SAME MEMORY LOCATION, unsynchronized, ≥1 write — undefined behavior in most memory models
Lost update: classic race — read-modify-write interleaves, one update silently overwritten

Fixes: mutex (mutual exclusion) | atomics/CAS (single-variable) | immutability (eliminates it) | message passing | DB unique constraint

CAS(address, expected, new): atomically swap only if unchanged since read — retry loop if it fails
Mutex ⊂ built on CAS; futex = fast path in userspace, kernel only on real contention
Semaphore = mutex generalized to N permits (bulkhead pattern uses this)
Atomicity ≠ ordering guarantee for OTHER variables — that needs memory barriers / a lock spanning the whole invariant

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: adv_race_conditions_theory.md · generated by tools/build_lessons.py