To implement the process model, the operating system maintains a table (an array of structures), called the process table, with one entry per process. (Some authors call these entries process control blocks.) This entry includes important information about the process state, containing its program counter, stack pointer.
Implementation of Processes
Memory allocation, the status of its open files, its accounting and scheduling information, and everything else about the process that must be saved when the process is switched from running to ready or blocked state so that it can be restarted later as if it had never been stopped.
Figure (b) shows some of the key fields in a typical system. The fields in the first column relate to process management. The other two relate to memory management and file management, respectively. It should be noted that specifically which fields the process table has is highly system dependent, but this figure gives a general idea of the kinds of information required.
Now that we have looked at the process table, it is possible to explain a little more about how the illusion of multiple sequential processes is maintained on one (or each) CPU. Connected with each I/O class is a location (normally at a fixed location near the bottom of memory) called the interrupt vector. It includes the address of the interrupt service procedure. Assume that user process 3 is running when a disk interrupt occurs. User process 3’s program counter, program status word, and often one or more registers are pushed onto the (current) stack by the interrupt hardware. The computer then jumps to the address specified in the interrupt vector. That is all the hardware does. From here on, it is up to the software, particularly, the interrupt service procedure.
All interrupts start by saving the registers, sometimes in the process table entry for the current process. Then the information pushed onto the stack by the interrupt is removed and the stack pointer is set to point to a temporary stack used by the process handler. Actions such as saving the registers and setting the stack pointer cannot even be expressed in high-level languages such as C, so they are carried out by a small assembly language routine, generally the same one for all interrupts since the work of saving the registers is identical, no matter what the cause of the interrupt is.
When this routine is finished, it calls a C procedure to do the rest of the work for this particular interrupt type. (We assume the operating system is written in C, the common choice for all real operating systems.) When it has done its job, possibly making some process now ready, the scheduler is called to see who to run next. After that, control is passed back to the assembly language code to load up the registers and memory map for the now-current process and start it running. Interrupt handling and scheduling are summarized in Figure (c). It is worth noting that the details differ somewhat from system to system.