Critical Section and Race Condition

A critical section is any span of code that reads and then writes shared state, relying on the value it read still being true at the moment it writes — and a race condition is what happens when a second thread slips in between that read and that write, so the first thread's write is computed from a value that is already stale. The hazard is not the sharing itself; it is the gap between observe and update, during which an invariant the code assumes ("nobody else has touched this yet") quietly becomes false.

The mechanism: one line of source is three machine steps

The reason a critical section can be "entered" by two threads at once is that the statement you wrote is not what the CPU executes. A hardware core cannot add to a memory location in a single indivisible step; it must pull the value into a register, change the register, and push it back. So balance += 1 compiles to a read-modify-write triple:

1. LOAD — copy balance from memory into a register
2. ADD — add 1 to the register (memory is untouched)
3. STORE — write the register back to balance

The OS scheduler (or another core) can interrupt the thread between any two of these. The window from LOAD to STORE is the critical section. While one thread sits inside it, the invariant it is counting on — "the value I LOADed is still the current value" — is true only until some other thread STOREs. If that happens, the first thread's later STORE writes a number computed from a value that no longer exists in memory. That overwrite is called a lost update.

A worked example: four threads, +1 each, with real register values

Start with a shared cell balance = 20. Four threads each run balance += 1 once. If their critical sections ran one-at-a-time the answer is 24. Here is one concrete interleaving that produces 21 — each row shows what each thread holds in its private register and what is actually in memory.

All four LOADed 20 before anyone STOREd, so all four computed 21, and the four STOREs all wrote the same 21 — three increments vanished. This is the worst-case interleaving; in practice you usually get some increments through (say 22 or 23), which is exactly what makes the bug so dangerous: it is non-deterministic and often almost right. Note the result depends only on scheduling, not on the arithmetic — this is why a race is defined by the ordering of accesses affecting the outcome, with at least one access being a write.

The fix: make the critical section indivisible

Correctness needs three guarantees on the critical section. A lock provides mutual exclusion (at most one thread inside at a time) and progress (if nobody holds the lock, some waiter gets in). Bounded waiting — no thread waits forever — is only guaranteed by a fair lock such as ReentrantLock(true); the default synchronized monitor or an unfair ReentrantLock may allow a freshly arriving thread to barge ahead of a parked waiter and, under extreme contention, starve it. Acquiring a lock forces the LOAD, ADD, and STORE to happen as one uninterruptible unit and publishes the new value before the next thread reads — so each thread reads the latest value and the four increments cannot collapse onto each other.

Java — synchronized guards the critical section

class Account {
    private long balance = 20;
    private final Object lock = new Object();

    // The lock makes LOAD-ADD-STORE one atomic, visible step.
    void deposit() {
        synchronized (lock) {   // enter critical section
            balance += 1;       // read-modify-write, now indivisible
        }                       // exit + publish (happens-before next acquire)
    }
    long get() {
        synchronized (lock) { return balance; }
    }
}

// Driver: 4 threads each deposit once -> always 24
Account a = new Account();
Thread[] ts = new Thread[4];
for (int i = 0; i < 4; i++) { ts[i] = new Thread(a::deposit); ts[i].start(); }
for (Thread t : ts) t.join();
System.out.println(a.get());   // 24, every run

Why the naive version is wrong: drop the synchronized and write a bare balance += 1 on a plain long field, and you reproduce the table above — the field has no atomicity (the three steps interleave) and no visibility guarantee (a thread may keep reading a cached stale value indefinitely). The output drifts below 24 and varies run to run.

Go — a sync.Mutex does the same job

package main

import (
	"fmt"
	"sync"
)

type Account struct {
	mu      sync.Mutex
	balance int64
}

func (a *Account) Deposit() {
	a.mu.Lock()         // enter critical section
	a.balance += 1      // read-modify-write, now indivisible
	a.mu.Unlock()       // exit + publish
}

func main() {
	a := &Account{balance: 20}
	var wg sync.WaitGroup
	for i := 0; i < 4; i++ {
		wg.Add(1)
		go func() { defer wg.Done(); a.Deposit() }()
	}
	wg.Wait()
	fmt.Println(a.balance) // 24, every run
}

How the two runtimes differ: Java's Thread maps to an OS thread the kernel schedules; a Go goroutine is a cheap user-space task multiplexed by the Go runtime onto a small pool of OS threads (the M:N scheduler), so spawning thousands is normal. But the data hazard is identical — a goroutine can be preempted mid read-modify-write just like a thread. Go's idiomatic alternative is to not share the cell at all: hand it to one owner goroutine and have others send deltas over a channel ("share memory by communicating"), which removes the critical section instead of guarding it. Java's nearest analogue is structuring work so only one thread touches the state, or using wait/notify on a monitor; Go has no wait/notify — it uses channels and sync.Cond for that role. Run either unguarded version under go run -race / a Java race detector and the tool will flag the unsynchronized access directly.

Pitfalls

• "It passed on my machine" is not evidence. A race often only loses an update under load, on more cores, or with a different scheduler. Passing once means nothing; you need a stress loop or a race detector.
• Guarding the write but not the read. If one thread reads balance without the lock while another writes under it, you still get a torn or stale read. Every access in the race — reads included — must use the same lock.
• Different locks for the same data. Two methods that each synchronize on a different object provide zero mutual exclusion against each other. The lock identity, not the keyword, is what serializes.
• Assuming a single statement is atomic. x++, x += y, lazy-init (if (f == null) f = ...), and even some 64-bit reads are multi-step. "One line" says nothing about indivisibility.
• Holding the lock too long. The correctness fix has a cost: a critical section that does I/O or sleeps while holding the lock serializes everything and can tank throughput or deadlock. Keep critical sections short and CPU-only.

Takeaways

• A critical section is the read-to-write window where a thread assumes the value it read is still current; a race is another thread invalidating that assumption mid-window.
• The mechanism is real hardware: one source line is LOAD–ADD–STORE, and the scheduler can interrupt between any two — so increments computed from the same stale read collapse into one (a lost update).
• The fix needs mutual exclusion, progress, and bounded waiting; a lock gives all three by making the section indivisible and publishing the result before the next reader.
• Java threads are OS threads; Go goroutines are user-space tasks on an M:N scheduler — the hazard is identical, but Go often dissolves the critical section entirely by passing data through channels rather than guarding shared memory.

Re-authored and deepened for this guide. Sources: Silberschatz, Galvin & Gagne, Operating System Concepts (critical-section problem; mutual exclusion, progress, bounded waiting); Brian Goetz et al., Java Concurrency in Practice (read-modify-write, atomicity and visibility, intrinsic locks); Donovan & Kernighan, The Go Programming Language, ch. 9, and Effective Go ("share memory by communicating", sync.Mutex, the race detector). The full register-level two-thread counter++ interleaving is traced on the next page, “Race Conditions — A Traced Interleaving of counter++”.