The race condition that turned a healer into a killer
Between 1985 and 1987, the Therac-25 radiation therapy machine gave massive overdoses of radiation to several cancer patients, killing at least three. The cause was a software bug known as a race condition. If an operator corrected a mistake too quickly, the machine's software failed to configure the hardware safety shields before activating the high-energy electron beam, firing raw radiation directly into the patients.
A Departure from Physical Safety
In the early 1980s, Atomic Energy of Canada Limited developed the Therac-25, a medical linear accelerator designed to deliver radiation therapy to cancer patients. Previous models in the series, the Therac-6 and Therac-20, had been built in partnership with a French manufacturer and relied on electromechanical safety mechanisms. These older machines used physical microswitches, relays, and hardware interlocks to guarantee that the machine could not activate its radiation beam in a dangerous configuration, regardless of what signals the computer sent.
With the Therac-25, the manufacturer took a different design path. The hardware safety circuits and mechanical interlocks were eliminated, and their safety functions were transferred entirely to software. The machine ran on a single PDP-11 computer using custom real-time assembly code written by a single programmer. Because the software was adapted from code used in the Therac-6 and Therac-20, engineers assumed the underlying logic was already battle-tested, overlooking the fact that hardware switches had previously masked latent software bugs.
This software-only design was intended to reduce manufacturing costs and make clinical operations faster and more flexible. Without mechanical backup systems, however, the machine's safety depended entirely on the flawless execution of real-time control routines. If the computer instructed the hardware to fire the radiation beam under the wrong mechanical alignment, there was no physical barrier left to prevent a catastrophic overdose.
Two Modes and a Fatal Mismatch
The Therac-25 operated in two primary treatment modes: a low-energy electron therapy mode and a high-energy X-ray (or photon) therapy mode. In electron mode, a relatively low-current electron beam was directed at the patient at varying energy levels, shaped by magnetic fields. This mode treated shallow tissue without penetrating deeply into the body.
In X-ray mode, the physics required a vastly more intense radiation source. The machine fired an electron beam with an energy level of 25 million electron volts—roughly one hundred times the beam current used in direct electron mode—at a movable tungsten target placed between the beam source and the patient. When the high-power electron stream struck the tungsten target, it converted into high-energy X-rays, which were then smoothed by a flattening filter to ensure an even, safe dose.
The physical position of the turntable holding the target and filter was critical. If the machine generated the 25-megaelectronvolt beam while the turntable was positioned for electron mode—leaving the tungsten target out of the beam's path—the patient would be struck directly by raw, unshielded, high-current radiation. Instead of a diffused therapeutic dose, the machine would deliver a lethal, concentrated blast hundreds of times greater than prescribed.
The Eight-Second Race Condition
The primary flaw that caused several fatal overdoses was a race condition in the user interface software. A race condition occurs when a system's behavior depends on the uncontrolled timing or sequence of independent events, such as simultaneous user input and background processing. In the Therac-25, the user interface task and the machine control task shared common memory variables without adequate synchronization locks.
In clinical practice, experienced machine operators typed treatment parameters very quickly. If an operator mistakenly selected X-ray mode by typing 'x', realized the error, and used the up-arrow cursor key to return to the mode selection field and change it to 'e' for electron mode—all within an eight-second window—the software failed. During that eight-second interval, a background routine was calibrating the bending magnets for X-ray mode. The rapid edit caused the user interface to update the mode variable in one part of memory while skipping the routine that reset the beam energy and repositioned the turntable.
As a consequence, the machine prepared the high-intensity 25-megaelectronvolt power setting while the turntable remained set for low-energy electron delivery without the tungsten target in place. When the operator pressed the execute key, the system fired the maximum-intensity raw beam directly into the patient's body.
Cryptic Errors and Repeated Doses
When these massive overdoses occurred, the user interface gave operators misleading feedback. The machine did not report a catastrophic radiation event; instead, it halted and displayed obscure error codes such as 'Malfunction 54' or 'Malfunction 11'. The accompanying documentation did not explain what these numbered codes meant, nor did the system indicate that any radiation had actually been discharged.
Because the computer reported that the treatment had simply paused with no dose delivered, operators assumed the machine was suffering a harmless electronic glitch. In several incidents, operators pressed the pause-override key to restart the beam, subjecting the patient to second and third direct blasts of raw radiation within seconds. Patients described feeling an intense burning sensation, an electric shock, or hearing a loud buzzing noise, but their complaints were initially dismissed by staff who trusted the machine's readouts.
The manufacturer initially maintained that overdoses were physically impossible. When early complaints emerged from treatment centers, the company issued minor software patches and asserted that hardware redundancies were not needed. It took months of repeated accidents, independent investigation by hospital physicists, and regulatory intervention before the fundamental flaws in the software architecture were officially acknowledged.
A Second Flaw in Shared Memory
The interface race condition was not the only fatal bug in the Therac-25 codebase. Investigators uncovered a second race condition involving a one-byte shared counter used to verify that the collimator—the device that shapes the beam—was correctly positioned before allowing a treatment to proceed.
Every time the setup routine ran, the software incremented a shared variable called 'Class3'. If this variable held a non-zero value, the software interpreted it as a sign that the machine was still configuring its hardware, thereby keeping the safety check active. However, because 'Class3' was stored as a single byte, it held values only from 0 to 255. When incremented past 255, the counter rolled over to 0.
If a clinical operator pressed the 'set' command at the exact millisecond the counter rolled over to zero, the software bypassed the safety check entirely. The system assumed the zero value meant all hardware checks had completed successfully, even if the collimator was completely out of position. This arithmetic overflow bug caused additional severe overdoses and demonstrated the hazards of relying on shared variables across asynchronous real-time tasks without atomic operations.
The Legacy of the Therac-25
Between 1985 and 1987, at least six patients received massive radiation overdoses from Therac-25 units, leading directly to the deaths of at least three individuals and leaving others with permanent, debilitating injuries. The disaster led to an extensive investigation by software engineering researcher Nancy Leveson and university investigators, who documented the systemic failures in the machine's development lifecycle.
The Therac-25 accidents fundamentally changed how safety-critical systems are regulated and engineered. Regulatory agencies such as the United States Food and Drug Administration established strict requirements for medical software validation, requiring rigorous source code reviews, hazard analyses, and formal verification. The engineering community recognized that software cannot be proven safe simply because it ran without incident in an older hardware configuration.
The case remains a standard study in computer science, software safety, and systems engineering. It established a core principle of modern safety engineering: critical safety interlocks should never rely solely on complex software when simple, independent physical mechanisms can prevent catastrophic failure.
Key takeaways
•The Therac-25 replaced physical, electromechanical safety interlocks with software-only controls, removing the hardware barriers that had previously prevented fatal radiation overdoses.
•A race condition occurred when operators corrected mode inputs too quickly, causing the system to fire a high-current raw electron beam without placing the protective tungsten conversion target in the beam path.
•Cryptic error codes and incomplete user feedback led operators to believe no dose had been delivered, causing them to administer multiple lethal overdoses to patients.
•The disaster led to strict regulatory oversight of medical software and established the principle of defense-in-depth, ensuring software errors cannot bypass physical safety interlocks.