Race condition
A software defect in which the outcome of a system depends on the unpredictable timing or ordering of two or more processes accessing a shared resource, such as two processes both gaining write access to the same data structure at the same time. Race conditions are a common source of emergent, hard-to-reproduce interaction failures because they only manifest under specific, often rare, timing conditions. Standard mitigations include locking a shared resource so only one process can write to it at a time, using a deterministic message-ordering guarantee across distributed nodes, and adding tests specifically designed to force rare timing orderings rather than relying on ordinary functional tests, which tend to exercise only the most common ordering.
Defined in 2 GAGE programs, which carry 4 distinct definitions of it. The wording above is taught in Engineering Judgment and Professional Formation.
How each discipline defines it
The same term does different work depending on who is using it. These are the definitions as each program teaches them, unedited.
A software defect that manifests only when two or more processes accessing the same shared resource, such as a variable holding the machine's configuration state, complete in a specific, unlucky relative order or timing, making it difficult to detect through standard testing because most test runs do not happen to reproduce the exact triggering sequence. This kind of non-deterministic scheduling is what makes race conditions notoriously hard to catch: the same code can run correctly thousands of times and then fail once, not because anything changed in the code, but because the operating system or the hardware happened to interleave two operations in the unlucky order that particular time. The Therac-25's overdose-causing bug was a race condition triggered by rapid operator keystroke correction within a narrow time window.
A situation where two processes read the same starting state and write competing updates to the same record at close to the same time, with the later write silently overwriting the earlier, equally legitimate one.
A software defect in which the outcome of a system depends on the unpredictable timing or ordering of two or more processes accessing a shared resource, such as two processes both gaining write access to the same data structure at the same time. Race conditions are a common source of emergent, hard-to-reproduce interaction failures because they only manifest under specific, often rare, timing conditions. Standard mitigations include locking a shared resource so only one process can write to it at a time, using a deterministic message-ordering guarantee across distributed nodes, and adding tests specifically designed to force rare timing orderings rather than relying on ordinary functional tests, which tend to exercise only the most common ordering.
A software failure mode in which two or more processes access or modify shared data in an order that depends on unpredictable, precise timing, producing a result the programmer did not anticipate under a specific, often rare, timing coincidence.
Where it is taught
The exact lessons this term appears in. The first 7 topics of every program are free with a free account.
- Pipeline forensics: reconstructing what the data did when the logs disagree · Data Incidents, AI Data Governance: The Data Chair
Terms it appears with
Not an alphabetical neighbourhood: these are the terms taught in the same lessons, ranked by how often they appear together.