Interviewers often distinguish a 'data race' from a 'race condition'. Define each precisely, and show that neither one implies the other.

## Two definitions that people blur together The words sound like synonyms; they are not, and the distinction matters because the two are found by different means and fixed at different levels. ### Data race — a memory-model term A program has a data race when all of these hold simultaneously: 1. two or more threads access the **same memory location**; 2. at least one of those accesses is a **write**; 3. the accesses are **not ordered by synchronization** — there is no happens-before relationship established by a lock, an atomic operation, a thread start/join, a channel send/receive, or similar; 4. the accesses are **not marked as atomic** in the language's memory model. That definition is entirely mechanical. It says nothing about whether the program produces the wrong answer; it is a property of the *accesses*, and a tool can check it. It is also the trigger for the memory model's escape clause: in most models a program containing a data race has undefined (or at minimum, wildly unconstrained) behaviour, and the guarantee you normally rely on — that a data-race-free program behaves as some interleaving of its threads' statements — no longer applies. ### Race condition — a correctness term A race condition exists when the correctness of the outcome depends on the relative timing or interleaving of operations. It is a statement about your **invariants**: some sequence of steps needed to appear indivisible, and it did not. This is a design-level property. It can exist at any granularity — between two instructions, between two service calls, between two database statements, between a filesystem check and a filesystem open. It exists in systems with no shared memory at all. ## Neither implies the other ### Race condition without a data race ``` withdraw(amount): lock(m); bal = balance; unlock(m) # synchronized read if bal >= amount: lock(m); balance = balance - amount; unlock(m) # synchronized write ``` Every access to `balance` is protected. A race detector reports nothing: there is no data race, because every pair of conflicting accesses is ordered by the mutex. The code is still broken — two threads can both read a balance of 100, both pass the check for 80, and both withdraw, leaving −60. The bug is that the atomic unit should have spanned the check *and* the act, and instead it covered each half separately. The same shape appears without any shared memory: check with a service that a username is free, then create the account; two clients pass the check and one creation fails or duplicates. No memory is shared between the machines at all, so "data race" is not even a meaningful term — but the race condition is real. ### Data race without observable misbehaviour An unsynchronized `hitCount++` used only for a rough log line, or an unsynchronized `stopRequested` flag, will typically produce values that look fine. It is nonetheless a data race by definition. The reason it still matters is that the memory model, not your test run, decides what is allowed: the compiler may hoist the flag read out of a loop (turning a terminating loop into an infinite one), keep the value in a register indefinitely, or transform the code in ways that only make sense under the assumption that no other thread touches that location. "It works" today is a statement about one compiler version on one machine. ## Why the distinction is operationally useful - **Different detection.** Dynamic race detectors (happens-before/lockset based) find data races and are very good at it. They will not tell you that your check-then-act sequence needed a wider lock — that requires knowing the invariant, which no tool knows. - **Different fixes.** Data races are fixed by adding synchronization or atomics to the accesses, or by not sharing. Race conditions are fixed by widening the atomic unit — one lock around the whole compound action, a conditional/compare-and-swap update, a transaction, a unique constraint, or moving the state under a single owner. - **Different reviewers' questions.** For a data race: "which lock or ordering edge covers this location?" For a race condition: "what must be true when this executes, and can another thread falsify it between these two lines?" ## The one-sentence version A data race is about **unsynchronized access to memory**; a race condition is about **timing-dependent correctness**. Removing all data races is necessary for a shared-memory program to be well-defined, but it is nowhere near sufficient for it to be correct.