Read an Excerpt
Chapter 8: Process Management
Process management is concerned with the sharing of the processor and the main memory amongst the various processes, which can be seen as competitors for these resources.
Decisions to reallocate resources are made from time to time, either on the Initiative of the process which holds the resource, of for some other reason.
Process Switching
An active process may suspend itself i.e relinquish the processor, by calling "swtch" (2178) which calls "retu" (0740). This may be done for example if a process has reached a point beyond which it cannot proceed immediately. The process calls "sleep" (2066) which calls "swtch".
Alternatively a kernel process which is ready to revert to user mode will test the variable "runrun" and if this is non-zero, implying that a process with a higher precedence is ready to run, the kernel process will call "swtch".
"swtch" searches the "proc" table, for entries for which "p stat" equals "SRUN" and the "SLOAD" bit is set in "p_flag". From these it selects the process for which the value of "p_pri" is a minimum, and transfers control to it.
Values for "p_pri" are recalculated for each process from time to time by use of the procedure "setpri" (2156). Obviously the algorithm used by "setpri" has a significant influence.
A process which has called "sleep" and suspended itself may be returned to the "ready to run" state by another process. This often occurs during the handling of interrupts when the processhandling the interrupt calls "setrun" (2134) either directly or indirectly via a call on "wakeup" (2113).
Interrupts
It should be noted that a hardware interrupt (see Chapter Nine) does not directly cause a call on "swtch" or its equivalent. A hardware interrupt will cause a user process to revert to a kernel process, which as just noted, may call "swtch" as an alternative to reverting to user mode after the interrupt handling is complete.
If a kernel process is interrupted, then after the interrupt has been handled, the kernel process resumes where it had left off regardless. This point is important for understanding how UNIX avoids many of the pitfalls associated with "critical sections" of code, which are discussed at the end of this chapter.
Program Swapping
In general there will be insufficient main memory for all the process images at once, and the data segments for some of these will have to be 'swapped out* i.e. written to disk in a special area designated as the swap area.
While on disk the process images are relatively inaccessible and certainly unexecutable. The set of process images in main memory must therefore be changed regularly by swapping images in and out. Most decisions regarding swapping are made by the procedure "sched" (1940) which is considered in detail in Chapter Fourteen.
"sched" is executed by process #0, which after completing its initial tasks, spends its time in a double role: openly as the "scheduler" i.e.a normal kernel process; and surreptitiously as the intermediate process of "swtch" (discussed in Chapter Seven). Since the procedure "sched" never terminates, kernel process #0 never completes its task, and so the question of a user process #0 does not arise.
Jobs
There is no concept of "job" in UNIX, at least in the sense in which this term is understood in more conventional, batch processing oriented systems.
Any process may "fork" a new copy of itself at any time, essentially without delay, and hence create the equivalent of a new job. Hence job scheduling, job classes, etc. are non-events here. . . .
