The Interrupt
Every other machine here does one thing after another. This is the one that stops.
New to concurrency? Start here
Two things at once
A program you write reads top to bottom, one step after the last. Once two of them run at the same time, that stops being true of the pair: their steps interleave, in an order nobody chose and nothing wrote down.
The hard part is that the order is not random so much as unconstrained. Any interleaving the hardware permits is one you have to treat as possible, even if no test you ever run happens to produce it: nothing promises that a scheduler will eventually choose it, and nothing promises it will not, on someone else's machine, months later, on the run you were not watching. So the machines in this topic are not about making the right order happen. They are about which orders are possible, which of those are wrong, and what it costs to rule them out.
The machine for this idea on its own is Race, if you would rather press it than read about it.
What a processor actually does
A processor fetches an instruction, works out what it says, does that one small thing, and moves to the next. Add these two numbers. Put this number there. If that number is zero, carry on somewhere else. That is the job, and it repeats a few billion times a second.
Everything that looks like cleverness is arrangement around that loop: keeping the next instruction ready before it is asked for, keeping recently used numbers close by, letting a slow part and a fast part work at once. The machines here are those arrangements, and most of them exist because one part of the machine is thousands of times slower than another.
The machine for this idea on its own is Stored Program, if you would rather press it than read about it.
The processor
1 Raise: a line goes high while the processor is in the middle of something
2 Finish: the instruction in flight completes, because half an instruction is not a state
3 Save: the program counter and the flags go somewhere they can be found again
4 Vector: a fixed address says where to go, and the return is the part people get wrong
Uninterrupted, this program reports 18. Interrupt it and see whether it still does.
Checked when this page loaded: an interrupt was fired after each of 12 instruction boundaries. With the handler saving the accumulator, 0 of them changed the answer. With it not saving, 4 did.
Before this, a machine had to ask
A computer that cannot be interrupted has one way to find out whether anything has happened: ask. Ask the reader whether a card is ready, ask the printer whether it wants another line, ask again, forever, in between doing the work you actually wanted. Everything runs at the speed of the asking, and the asking never stops.
An interrupt turns that around. The device raises a line, and the processor leaves what it was doing and goes to deal with it. Nothing has to be asked, and nothing has to be anticipated.
Four things have to be true
Four things have to be true, of the kind of interrupt drawn here
What this page draws is a precise, maskable, vectored interrupt: one that lands on an instruction boundary, that the processor can be told to hold off, and that names where to go. Not all of them are. An imprecise interrupt does not name an instruction to come back to, which is why machines that allow them are hard to debug, and a non-maskable one cannot be held off at all. The four conditions below are what makes THIS kind resumable.
The first is that the instruction already running finishes. There is no stopping half way through one, because half an instruction is not a state anything could be restored to.
The second is that the address saved is the next instruction rather than the one that just ran, or the return would do the same work twice.
The third is that the hardware knows where the handler is without being told each time, which is what a vector is: one fixed address the processor jumps to, needing no agreement with the program about anything else.
The fourth is that everything the handler disturbs is put back. That is the one that gets missed, and the machine above lets you miss it.
The bug that does not look like one
Turn off the handler's save and interrupt the program. Nothing crashes. Nothing is flagged. The program runs to the end and reports a number, and the number is wrong, because the handler used the accumulator for its own work and never put back what was in it.
That is what makes interrupt bugs the shape they are. The interrupted program is correct, the handler is correct on its own, and the fault only exists in the moment where one is inside the other. The page fires an interrupt after every instruction boundary when it loads and reports how many of them change the answer, both ways, rather than asking you to take that paragraph on trust.
Who was first depends on what you mean
Interrupts are usually dated to 1953 and the UNIVAC 1103. That date does not survive being looked at: the 1953 machine's manual does not describe interrupts at all, and the interrupt system attached to one was built by Dick Turner and Joe Rawlings at NACA in late 1955, first working in February 1956.
The DYSEAC, delivered to the Army in 1954 and written up the same year, is the earliest machine that can fairly be said to have taken interrupts from input and output. So 1954 is the date on this page.
Though even that hides something. The first interrupts were not for devices at all. They were for exceptions: the UNIVAC I in 1951 could take an arithmetic overflow and jump somewhere, and the idea was only later pointed at I/O. An interrupt started life as a way of handling a mistake.
These ran in this browser when the page loaded. Each claim, whether it held, and the number behind it.
| claim | held | measured |
|---|---|---|
| interrupted after each of 12 instruction boundaries, a saving handler changes the answer 0 times | yes | the program prints 18 uninterrupted and 18 however many times it is interrupted, which is what invisible means |
| with the handler not saving the accumulator, 4 of those 12 boundaries produce a wrong answer | yes | the precaution has to be protecting against something, or the first check is describing a program that cannot be disturbed |
| the machine is only ever between instructions: after 6 steps the counter reads 1, 2, 3, 4, 5, 5 | yes | an interrupt is taken between instructions and never inside one, because half an instruction is not a state to restore |
| taking an interrupt at 2 pushes 2 and jumps to the vector at 8 | yes | the address saved is the instruction AFTER the one that just finished, not the one that was running |
| a masked processor refuses the interrupt, and one already in a handler refuses a second | yes | without the second refusal the return address would be pushed twice and the stack would grow for as long as the line stayed high |
What is real here, and what is not
This is not a processor
Eight opcodes, one accumulator, one stack, no pipeline, no cycles, no memory to speak of. A real machine has priorities, several vectors, nesting, and a great deal of argument about what happens when two lines go high at once. None of that is here.
The date is contested and the common one is wrong
1953 and the UNIVAC 1103 is the answer you will usually be given, and the 1953 manual does not mention interrupts. This page follows Mark Smotherman's account, which puts the 1103's interrupt system at February 1956 and gives the earliest I/O interrupts to the DYSEAC in 1954. If you want a single year, 1954 is the defensible one, and the honest answer is that it depends what you count.
Nothing here is timed
Interrupt latency is most of what matters about interrupts in practice, and there is none of it here: no cycle counts, no worst case, no measurement of how long the handler takes or what that costs the thing it interrupted.
Saving one register is a stand-in for saving the machine
The handler here disturbs the accumulator and puts it back. A real one has to preserve every register and every flag it touches, which on some machines is most of the processor and is why hardware often does part of it for you.