Implementation of Processes

Implementation of Processes

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,

The lowest layer of a process-structured operating system handles interrupts and scheduling. Above that layer are sequential 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.

Some of the fields of a typical process table entry

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.

Skeleton of what the lowest level of the operating system does when an interrupt occurs

When the process ends, the operating system displays a prompt character and waits for a new command. When it receives the command, it loads a new program into memory, overwriting the first one.


process management, memory management, file management