Race conditions are properties of programs — the outcome depends on an interleaving the program cannot control. Shared Counter is one instance; the same shape recurs in bank-balance updates, lazy initialization, ticket booking, and event-driven trading systems.
Same read-compute-write race in three surfaces. Switch approach to see the pattern repeat.
shared.balance = 100. Both worker threads are idle, waiting for a withdraw call.
1account = {"balance": 100}
2
3def withdraw(amount):
4 balance = account["balance"] # read
5 new_balance = balance - amount # compute
6 account["balance"] = new_balance # writeA race condition is a bug whose presence depends on the order in which concurrent operations execute. Three ingredients are required and sufficient: (1) shared mutable state, (2) two or more concurrent operations touching it, (3) no contract that orders them. Remove any one ingredient and the race cannot exist.
Shared Counter is the smallest possible race: two threads, one int64_t, one +1 each. The read–compute–write window is the gap where the bug lives. The same gap exists at larger scales — anywhere a program reads a value, decides based on it, and writes back, another thread can interleave between the read and the write.
Bank balance. Thread A and thread B each withdraw $50 from an account starting at $100. Both read $100, both compute $50, both write $50. The account ends at $50; one withdrawal vanished.
Lazy initialization. A singleton's constructor runs twice because two threads each check if (instance == null), both see null, both allocate, both write. The second new is leaked. This is the bug that motivated double-checked locking — a pattern that itself has subtle memory-model bugs.
Ticket booking. Thread A and thread B each check whether seat 12C is free, both see free, both attempt to book. The first write succeeds; the second silently overwrites; two customers now hold a confirmation for the same seat.
# Two threads withdrawing from the same account, starting at $100.
# Each withdraws $50. Expected final balance: $0. Observed: $50.
def transfer(account, amount):
balance = account.read_balance() # T1 reads 100, T2 reads 100
new_balance = balance - amount # both compute 50
account.write_balance(new_balance) # both write 50; one withdrawal disappears
# The bank ate $50.
These are not synonyms.
Data race is a specific memory-model violation: two threads access the same memory location, at least one access is a write, and there is no synchronization between them. C++ labels this undefined behaviour. Rust rejects it at compile time.
Race condition is the broader bug class: the program's outcome depends on an uncontrolled interleaving. A program can have a race condition without a data race — e.g. two threads each call a properly-synchronized read_balance() and write_balance(), but the compound read; compute; write sequence is not atomic. Each individual access is race-free; the operation as a whole is not.
Fixing data races (atomics or mutexes around each access) does not automatically fix race conditions. The unit of correctness is the operation, not the access.
Three fix shapes account for the concurrency primitives Stage 1 introduces. Other shapes — lock-free CAS loops, transactional memory, single-threaded event loops — live in later stages and are not reducible to these three.
Serialize. Make the compound operation indivisible. Mutex holds a lock for the duration of the section. Atomic RMW collapses three instructions into one indivisible one. The cost is contention.
Immutable. Do not share mutable state. Pass copies, return new values instead of mutating. Functional-style concurrency. The cost is memory allocation and bookkeeping.
Own, don't share. Ownership transfer. Only one thread at a time has the right to mutate; transfer is explicit. Rust's Send model, Go's share by communicating, the actor model. The cost is a different mental model.
GIL is serialize at runtime scope (one giant mutex on all interpreter state). Mutex is serialize at section scope. Borrow checker is own, don't share enforced at compile time. The three Stage 1 primitives are three points in this design space.
Look at the bank-balance code above. Answer three questions in writing: (a) precisely which two steps the race window sits between; (b) which of the three fix shapes applies most naturally here; (c) why adding volatile to the balance variable would not help.
Expected: (a) Between `read_balance()` returning and `write_balance()` being called. (b) Serialize — wrap the entire transfer in a mutex held for the duration. (c) `volatile` constrains compiler caching of a single access; the bug is at the compound-operation level. Both threads still execute `read; compute; write` and can still interleave between the steps even with the variable marked volatile.
Evidence the learner produces, checks that confirm it.