Technology
What is A race condition?
A race condition is a bug where a program's result depends on the unpredictable timing of two or more operations running at once. When tasks 'race' to read and change shared data, they can interfere and produce wrong or inconsistent results.
See it, don’t just read it.
Watch a 2-minute lesson with voice + animation that explains a race condition.
Key things to understand
- 1It happens when concurrent threads or processes touch the same data without coordination.
- 2Classic example: two transactions read a balance, both subtract, and one update is silently lost.
- 3The bugs are intermittent and hard to reproduce because they depend on exact timing.
- 4Fixed with locks, atomic operations, or other synchronization so only one task changes the data at a time.
Frequently asked questions
- Why are race conditions so hard to debug?
- They appear only under specific timing, so they may vanish when you add logging or attach a debugger, making them frustratingly intermittent.
- How do you prevent a race condition?
- Coordinate access to shared data with locks, mutexes, atomic operations, or transactions so changes can't overlap.
- Are race conditions a security risk?
- Yes — 'time-of-check to time-of-use' races can let an attacker slip a change in between a check and the action that relies on it.