What is a race condition

A race condition is a concurrency defect that appears when multiple execution contexts read and write the same memory location without proper coordination. The program’s state becomes dependent on the exact timing of each context, which the operating system does not guarantee. Because the scheduler may interleave operations in many ways, the same input can produce different outputs on different runs.

Why race conditions happen

Modern CPUs execute instructions out of order and operating systems preempt threads at arbitrary points. When a shared variable is accessed, each thread typically performs a read, modifies the value in a register, then writes it back. If another thread reads the original value before the first thread writes its result, the modification is lost. This lack of atomicity in the read‑modify‑write sequence is the root cause of most race conditions.

Common symptoms of a race condition include:

• Intermittent crashes or hangs
• Incorrect calculation results that appear only under load
• Security breaches such as double‑spending or privilege escalation

Steps to reproduce a minimal race condition:

1. 1Create two threads that both increment a shared integer counter
2. 2Initialize the counter to 0
3. 3Start the threads simultaneously and let each perform 1,000 increments
4. 4Join the threads and print the final counter value

Consider a concrete example: a global variable counter starts at 0. Thread A reads counter (0), adds 1, and pauses before writing. Thread B reads the same counter value (0), adds 1, and writes 1. When Thread A resumes, it also writes 1, overwriting B’s update. After both threads finish, the counter is 1 instead of the expected 2, demonstrating a lost update caused by a race condition.

Possible interleavings and final counter values:

Preventing race conditions requires enforcing exclusive access or using atomic primitives. A mutex lock forces only one thread to execute the critical section at a time, guaranteeing a consistent result. Lock‑free techniques such as compare‑and‑swap or language‑provided atomic types also serialize updates without a heavyweight lock. Always identify shared mutable state and protect it with the appropriate synchronization mechanism before testing under concurrency.