Context Switch
The Atlas Supervisor at Manchester ran several programs on one machine in 1962, and every one of them was written as though it owned the place. It works because a program's active state inside the processor is its registers: save them, put somebody else's back, and later put these back exactly as they were. What follows does that a register at a time, and lets you drop one to see what a program that loses one actually experiences.
New to how a processor works? Start here
What a processor actually does
A processor fetches an instruction, works out what it says, carries out the operation, and chooses the next instruction. Add these numbers. Read this address. If this value is zero, branch there. Then the cycle repeats.
Caches, pipelines and schedulers arrange work around that cycle. They can change when an operation runs or how long it waits for data. The instruction cycle is the starting point; each machine explains which arrangement it models.
The machine for this idea on its own is Stored Program, if you would rather press it than read about it.
Nothing appears to have happened
1 A program running, with registers that are its whole world
A program is running. These are its registers, and as far as it can tell they are the machine. It is part-way through adding a column of numbers, so the accumulator and the loop counter are both mid-flight.
2 An interrupt, and the registers saved somewhere
An interrupt arrives. Every register is copied somewhere the program cannot see and does not know about. Every one, here. A real kernel also has floating-point and vector state, often bigger than all of these together, and whether it saves that at every switch or waits until the next program touches it is a policy that kernels have set both ways. The count of them is what this page charges for the switch. A real one also pays for entering the trap, for the scheduler deciding who runs next, and for changing address space.
3 Another program restored into the same registers
The other program's registers go into the same physical places. It runs, changes them, and has no way of knowing anyone else was here. The machine is not shared in any sense the program can detect; it is handed over and handed back.
4 Back again, and whether anything at all was lost
Now put the first program back. The switch is correct only if every register returns to the value it had, bit for bit. Compare them one at a time: one wrong register is not a small error, it is a program that computes the wrong answer and never finds out why.
| register | before | after | same |
|---|
These ran in this browser when the page loaded. Each claim, whether it held, and the number behind it.
| claim | held | measured |
|---|---|---|
| a program that loses the processor gets every register back | yes | 8 of 8 identical |
| and the first program came back in a single restore | yes | 1 restore(s), 16 register copies |
| and forgetting one on the way out is caught, by comparing every register | yes | index 3 -> 4 |
| the switch costs the same however much work the program had done | yes | 8 registers saved either time |
| a register nobody saved keeps whatever the other program left in it | yes | acc came back as 12345, the value written into it while the program was away |
What is real here, and what is not
Eight registers, and a real machine has more to lose
Atlas had its own arrangement and nothing here is a model of it. Eight named registers is enough to show that the count of them is the cost, and a switch on anything modern also has to think about floating-point and vector state, and about what the caches and the address translation buffers lose afterwards, which is usually the larger half and is invisible in a register count.
The dropped register is a fault this page can create, not one Atlas had
Forgetting a register on the way out is a bug, not a design. It is here because the failure is the clearest way to say what the switch is for: everything else on the page looks the same whether or not the restore is correct, and only comparing every register catches it.
No memory protection, no address translation, no privilege
A real supervisor also has to stop the two programs seeing each other's memory, and Atlas is on the chronology at all because of the paging that did it. None of that is here. This page is about the registers only, which is the part a program experiences as its own continuity.
The date is the machine, and the month is only a sort key
The Atlas Supervisor is dated 1962, and the machine was inaugurated at Manchester on 7 December of that year by Sir John Cockcroft. The Supervisor itself came up over a period rather than on a day, so the page prints the year: the December in the chronology is there to order it against the other 1962 machines, not to claim the software was finished that week. Nor does 1962 mean the context switch begins here. CTSS was demonstrated at MIT in November 1961 and was already interleaving three users on one IBM 709, which it could not have done without saving and restoring their state. Atlas is on the chronology for the paging, and this page borrows its date because the registers are easiest to show there.
No sound
Nothing here has a duration to hear.