Therac-25: The Race Condition That Turned a Medical Accelerator Deadly
Therac-25 became the canonical software-safety case because lethal overdoses emerged from race conditions, removed hardware interlocks, opaque errors, and weak incident learning.
Therac-25 was supposed to replace hardware complexity with software control
The Therac-25 medical linear accelerator was designed to deliver high-energy electron or photon radiation for cancer treatment. Its manufacturer, Atomic Energy of Canada Limited, reused software concepts from earlier Therac machines but removed some independent hardware interlocks, relying more heavily on software to prevent unsafe configurations. Nancy Leveson and Clark Turner documented six known massive overdoses between 1985 and 1987, with deaths and severe injuries.[1] The machine became a landmark case not because software alone was uniquely defective, but because software had quietly become part of the safety architecture without being engineered or regulated with corresponding rigor.
Software inherited duties that hardware had once enforced
When independent physical interlocks disappear, the code that replaces them is no longer merely operational software. It becomes a safety barrier whose failure can expose patients directly to hazardous energy.
A fast editing sequence exposed a race condition in the operator interface
One important failure mode appeared when an experienced operator entered treatment data, noticed an incorrect mode, moved the cursor back, and rapidly corrected the entry. Under particular timing conditions, the software failed to update an internal flag consistently. The display showed the corrected treatment while other state remained associated with the prior mode. Leveson and Turner’s reconstruction showed how operator speed could trigger a race condition that slower testing might never reveal.[2] This is a classic concurrency lesson: a user interface may appear sequential even when shared internal state is updated through timing-sensitive tasks.
The machine produced cryptic error messages instead of actionable safety information
Operators sometimes saw messages such as “Malfunction 54” rather than an explanation that a hazardous configuration had been detected. The machine could pause, accept a reset, and permit repeated attempts. The Online Ethics case summary emphasizes that operators had been trained to treat many machine errors as recoverable and that overconfidence in software contributed to the accidents.[3] A safety-critical interface must communicate severity, not merely report that something unusual happened. If the same workflow is used for harmless glitches and potentially lethal states, the user cannot calibrate response appropriately.
Alarm design is part of the safety case
An error code that is technically accurate but operationally meaningless can be equivalent to no warning at all when the operator must decide whether to continue treatment.
Reused software carried assumptions from earlier machines into a changed architecture
Software reuse often reduces development effort, but it also preserves hidden assumptions. Earlier Therac systems had hardware mechanisms that could mask or contain some software defects. In the Therac-25, greater reliance on software meant those same defects could have more severe consequences. Leveson’s later discussion of medical-device safety argues that the accidents cannot be understood as a single coding mistake; design, testing, hazard analysis, operator interaction, and organizational response all mattered.[4] Reuse is safe only when engineers reassess which protections still exist in the new system context.
Testing did not reproduce the real combination of speed, state, and workflow
The failure mode depended on particular editing sequences and timing, which is precisely the kind of interaction ordinary functional testing can miss. Testing a menu option once is not equivalent to testing the system as expert operators will use it under routine pressure. The Therac experience helped popularize the idea that safety testing must include abnormal sequences, rapid actions, stale state, resets, and repeated recovery attempts. It also illustrated why software testing cannot prove safety merely by accumulating successful runs: rare state combinations may remain unvisited.
Real users can be faster and more repetitive than test scripts
Expertise changes timing. A novice pauses between keystrokes; an experienced operator may trigger concurrency behavior that never appears during scripted acceptance testing.
Incident learning failed because early reports were treated as isolated anomalies
After initial accidents, the manufacturer did not immediately recognize a common systemic cause. Hospitals also lacked a complete view of incidents occurring elsewhere. The eScholarship version of Leveson and Turner’s investigation stresses that accident descriptions were initially incomplete and misleading, and that learning required reconstructing technical and organizational evidence across sites.[5] Safety improves only when unusual events are treated as signals that may reveal a shared hazard. Fragmented reporting allows a recurrent defect to masquerade as unrelated operator error or equipment oddity.
The regulatory response pushed software into medical-device safety thinking
Therac-25 occurred during a period when software was becoming central to medical equipment faster than assurance practice was adapting. The accidents strengthened arguments for hazard analysis, independent protection layers, traceable requirements, disciplined configuration management, and clearer reporting obligations. The key lesson was not that software should never control dangerous machinery. It was that software must be treated as an engineered component whose failure modes interact with hardware, operators, maintenance, and organizational processes.[1][4]
Safety is a property of the whole system
No single module can be declared safe in isolation when the outcome depends on sensors, software, actuators, displays, procedures, and human interpretation.
Why Therac-25 still matters to software engineering
Therac-25 remains one of the clearest demonstrations that a small software defect can become catastrophic only when the surrounding system permits it. The race condition mattered, but so did the removal of hardware interlocks, the cryptic interface, inadequate hazard analysis, limited testing, and weak cross-site incident learning.[2][3] Modern developers encounter the same pattern in autonomous systems, industrial controls, medical devices, and infrastructure: software increasingly mediates hazardous physical processes.
The durable lesson is architectural. Safety should not depend on one opaque software path being flawless. Independent constraints, strong diagnostics, conservative recovery behavior, realistic operational testing, and rapid incident reporting turn inevitable defects into contained faults rather than disasters. Therac-25 is remembered because it showed what happens when those defenses are missing at the same time.
Works Cited
- 01
- 02Leveson and Turner — Therac-25 Investigation, eScholarship escholarship.org
- 03Online Ethics Center — Therac-25 Investigation Abstract onlineethics.virginia.edu
- 04CERIAS — Medical Devices: The Therac-25 cerias.purdue.edu
- 05eScholarship — Therac-25 Accident Paper PDF escholarship.org
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.