When Two Machine Actions Happened in the Wrong Order

The Therac-25 was a radiation therapy machine that could deliver either electron-beam treatment or X-rays. Those modes required different physical configurations: for X-rays, an electron beam had to strike a metal target first; for direct electron treatment, that target was moved out of the beam’s path. If the machine’s settings and physical setup did not match, the patient could receive a dangerously intense dose.

A key failure involved a race condition: a timing problem in which two operations overlap, and the result depends on which one finishes first. An operator could quickly change a treatment setting while the machine was preparing to deliver radiation. Under certain circumstances, the software’s checks and commands could occur in an unsafe order. The machine could proceed with a configuration that did not match the selected treatment.

Why Software Had to Catch Its Own Mistake

Earlier Therac designs used hardware safeguards as well as software. In the Therac-25, more of the safety responsibility rested on software, while some physical interlocks—devices that prevent a machine from operating in an unsafe state—were removed. That made the control program responsible not only for choosing the treatment configuration but also for detecting when the configuration was wrong.

This is a hazardous arrangement: a software failure can defeat both the action that creates danger and the check meant to stop it. A program may appear to validate a setting, yet a timing gap can make that validation stale by the time the machine acts on it. The issue is not simply that software can contain bugs; it is that a single failure can affect multiple layers of protection when those layers depend on the same control system.

The Value of an Independent Barrier

A physical interlock can provide a separate line of defense. Rather than relying on the same software to recognize every dangerous combination, it can block operation unless the machine’s components are actually in the required positions. Such barriers do not make software unnecessary, but they can keep one software error from becoming an uncontrolled physical event.

The broader engineering lesson is to design safety so that the system controlling a hazard cannot be its only judge. When a treatment machine can deliver radiation, a safeguard that independently prevents the wrong configuration from producing a beam is more than backup—it is a boundary between a recoverable software mistake and a patient exposed to harm.