Race Condition
Noun · Development
Definitions
A bug that occurs when the behavior of a system depends on the sequence or timing of uncontrollable events — when two operations 'race' and the outcome depends on which finishes first. Among the hardest bugs to reproduce and fix.
In plain English: A bug caused by two things happening at the same time when they shouldn't — like two people trying to edit the same document at the same moment and overwriting each other's changes.
Origin Story
When two processes race and your software loses
A **race condition** occurs when a system's behavior depends on the timing or order of uncontrollable events — when two or more processes "race" to access shared resources, and the outcome depends on who gets there first. The term comes from electronics, where it described competing signal paths in logic circuits as early as the 1950s.
In software, race conditions are among the most insidious bugs because they're non-deterministic: the code may work correctly 99 times out of 100, then fail on the 100th run when threads happen to interleave in an unlucky order. Classic examples include the **check-then-act** pattern: checking if a file exists, then creating it, with another process doing the same thing between your check and your create.
Race conditions have caused real-world disasters. The Therac-25 radiation therapy machine (1985-1987) killed patients due to a race condition between the operator interface and the beam configuration. Financial systems, voting machines, and spacecraft have all been affected. It's one of the few bug categories that can be genuinely dangerous.
Coined by: Electronics engineering community
Context: Electronics, 1950s; software adoption, 1960s
Fun fact: The Therac-25 race condition is one of the most studied cases in software engineering ethics. A race between two routines meant the machine could deliver 100 times the intended radiation dose. At least six patients were severely injured and three died.