SunOS 4.x

The older system design has been tweaked over a number of years and is quite stable and reliable. However, it was originally intended for a single-processor, timeshared system. The emphasis is on running lots of highly interactive user programs, switching back and forth to give everyone fairly even performance. CPU-bound (heavy processing) programs are deliberately placed in a lower-priority bracket to give interactive programs, like editors, a better response time. Processes that have not been active for a long time and have been off the CPU, or swapped out, are also given a boost in priority to get them back into the system.

Users (and administrators) of the system have very limited abilities to change this scheme. The nice command will essentially add a constant to the priority of the process and force it to be placed in a different level. Users can only lower their priority by using a positive nice value. Administrators ( super-users ) can use a negative nice value, causing their processes to be run sooner, perhaps even before some system daemons. Doing so, of course, makes the system administrator somewhat unpopular with the long-suffering user community who can't get any work done. (The answer, of course, is for the administrator to rename that game program to cc so nobody can tell.)

There are 32 different run queues, which are ordered by priority. If more than one process is in a run queue at a particular level, they are executed in round- robin fashion, that is, a process that exceeds its CPU-time allotment moves to the back of the list and must wait for everyone else at that level to have a chance before running again. In practice, this rarely happens. Most processes run into a blocking situation where they have to give up the CPU voluntarily and wait for something else to happen (I/O, for example) before they can continue running. In addition, since CPU-bound processes are penalized , they generally find themselves moving down to a lower-priority run queue rather quickly. A fairly complicated formula is used to compute the process priority (and eventual run queue), based on the amount of CPU time the process has used, its former priority value, the nice number, and the amount of memory the program is using, among other things.

The important kernel functions used to put processes on the run queues or take them off are:

• sleep() ” Voluntarily give up the CPU because there is nothing more to be done right now. This function calls swtch() to let another process run.

• wakeup () ” Put a process that was sleeping onto the appropriate run queue. If the newly readied process has a higher priority than the one currently executing, set a flag ( runrun ) and try to bump this other one off. The flag is checked as part of trap and interrupt processing to see if the original process should be allowed to continue running.

• setrq() ” Put the given process at the end of the appropriate run queue.

• remrq() ” Remove the first process from the head of the given run queue. This function is called by various kernel housekeeping functions as well as by the kernel code that prepares to run another process.

These functions all move processes around on the queues. The actual code to perform a context switch is contained in two routines, swtch() and resume() .

The first, swtch() , can be called (via sleep() ) by a process or by the scheduler if it decides that the current process needs to be bumped off the CPU. The function finds the next process that should be allowed to run. The second function, resume(), actually restores the state of a process and returns control to the process. The swtch() function will call the idle loop if there is nothing to run and will just spin around watching the CPU lights move, if there are any. (Actually, the LED bouncing-light pattern, on those systems that have the lights, is updated in the clock-tick interrupt code, but the pattern will be updated only if the clock tick happened to interrupt the idle loop.)

A substantial portion of the context switch code and queue manipulation is written in assembly language. It is quite complex. There was a very large descriptive comment in the old UNIX source code for the PDP-11, describing how a context switch was performed. The last line of the comment said, "You are not expected to understand this."