How multitasking works
In response to How do you think multitasking works on 80386? . In my opinion, none of the proposed answer options is correct, but this one is true:
The processor knows nothing about threads or processes. It simply executes instructions in sequence until an interruption occurs. Interrupt handling comes down to a procedure call not specified in the executable code. This procedure (which is part of the operating system), if necessary, switches processes and threads. Most often, the interrupt procedure simply exits and the interrupted thread continues its work without noticing anything.
The steps in this process are elegant and instructive.
Each thread has its own stack — a memory area for storing the status of the currently executing procedures. When the procedure is called, the state of the processor is written to the stack; after exiting the procedure, it is read from there back to the processor registers. The most important state element is the address of the executable command. An even more important state element is the stack pointer — the address at which state data is written or read. The stack pointer itself is not written to the stack.
Several wires lead to the processor from external devices (including the timer). A signal on any of these wires causes the processor to perform the interrupt procedure, whose starting address is specified in the interrupt table at the index equal to the number of the wire.
Switching stacks is done like this: the operating system procedure that decided to make a switch saves the contents of the register - the stack pointer in the header of the current stack, then it extracts the value of its pointer from the header of the other stack and writes it to the register, after which the usual exit command is executed. That is, changing the stack comes down to replacing the contents of the register - the stack pointer.
When switching processes, the virtual memory registers are additionally overloaded.
Many details in this presentation are omitted (for example, the priority of interrupts), they can be found in the relevant literature.
Soviet terminology was different from American. A stream was called a process, and a process was called a task, in accordance with Dijkstra's work. Interaction of sequential processes.
The processor knows nothing about threads or processes. It simply executes instructions in sequence until an interruption occurs. Interrupt handling comes down to a procedure call not specified in the executable code. This procedure (which is part of the operating system), if necessary, switches processes and threads. Most often, the interrupt procedure simply exits and the interrupted thread continues its work without noticing anything.
The steps in this process are elegant and instructive.
Each thread has its own stack — a memory area for storing the status of the currently executing procedures. When the procedure is called, the state of the processor is written to the stack; after exiting the procedure, it is read from there back to the processor registers. The most important state element is the address of the executable command. An even more important state element is the stack pointer — the address at which state data is written or read. The stack pointer itself is not written to the stack.
Several wires lead to the processor from external devices (including the timer). A signal on any of these wires causes the processor to perform the interrupt procedure, whose starting address is specified in the interrupt table at the index equal to the number of the wire.
Switching stacks is done like this: the operating system procedure that decided to make a switch saves the contents of the register - the stack pointer in the header of the current stack, then it extracts the value of its pointer from the header of the other stack and writes it to the register, after which the usual exit command is executed. That is, changing the stack comes down to replacing the contents of the register - the stack pointer.
When switching processes, the virtual memory registers are additionally overloaded.
Many details in this presentation are omitted (for example, the priority of interrupts), they can be found in the relevant literature.
Soviet terminology was different from American. A stream was called a process, and a process was called a task, in accordance with Dijkstra's work. Interaction of sequential processes.