I am completely clueless about the inner workings of an operating system, but I can more or less guess the approximate behaviour of many functions. One thing that I am not able to figure out, though, is multitasking.
In theory, the operating system manages time, according the CPU for small intervals to the various programs running. But it is not clear how this really works.
Say the operating system wants to start my program. The machine code is loaded somewhere in RAM, starting at a certain address. I guess then a jump should be performed to that address, allowing my code to execute. But in this way, the OS cannot regain control until I jump back.
Basically, I can imagine just two ways of making this work, but neither seems really suitable:
-
The operating system could read the machine instructions I want to perform and emulate them instead of executing them directly. I am intentionally vague, since I do not know how this would work, but it seems like it would slow down the program considerably.
-
Alternatively, the operating system could wait until I make a system call. In that moment it regains control and can check how long I have been running and do its timesharing stuff. This may work, but it seems unreliable, as I could make a long calculation which does not involve system calls and hang everything for a while.
So, it seems neither mechanism would work very well. How is multitasking actually performed?
Best Answer
The OS programs a timer to kick in every few microseconds (or milliseconds, depending on system speed). This timer raises the hardware interrupt, which causes the CPU to stop whatever it is currently doing, dump all its contents onto the stack and process the interrupt routine indicated by the address provided by the interrupt controller. This routine can inspect the stack and various other variables to make a decision which running process should next be put back into action. If it's the same process, the interrupt routine simply returns. If it's a different one, the relevant parts of the stack are saved and then replaced with the contents of a previously interrupted process, so when the interrupt routine returns, that process continues. Other than the fact that some time has elapsed, that process is unaware of having been interrupted and/or paused for some time.
This is (for modern CPUs) a VERY VERY simplified version of what happens, but it explains the principle. In addition to these OS controlled interrupts, there are also interrupts caused by external events (mouse, keyboard, serial ports, network ports, etc.) which are process with separate interrupt routines, which are usually connected to event handlers.
Very often process/task/context switching is also based on availability of external resources. Typically a process that requires data from storage (i.e. not in RAM) will place the request on a queue, set an event handler for the hardware interrupt indicating that the request has been served and then relinquish control to the task scheduler (since there is no point in waiting). Again, a very simplified description of what actually goes on, but it should serve the purposes of this answer.