An Operating Systems Vade Mecum

The kernel and processes 19Service calls are like subroutine calls from the point of view of the calling process.Arguments are first placed in a standard place (on a stack, in registers, right after the call,or in a communication area), and then the service-call instruction is executed. Whencontrol is returned by the kernel to the process, the process is ready to execute the nextinstruction. Results passed back from the kernel are stored in registers, on the stack, or ina communication area.Sometimes service calls are simple matters that should not cause the process makingthe request to wait. For example, a process might request the current time of day.This information is readily available, so the kernel just switches context back to the callingprocess, giving it the information it wanted. If the process must wait before the serviceit requested can be provided, process switching is involved. We will see that storemanagement introduces extra costs for process switching.Interrupts caused by a transput device also cause context to switch from the currentprocess to the kernel. The same sequence of actions (saving old context, loading newcontext, changing state) occurs for interrupts as for traps. The interrupt might indicatecompletion of an operation that some other process was waiting for, in which case thekernel might place that process on the ready list. A policy decision could switch to thatprocess, at the expense of the former process. We will discuss devices in Chapter 5.One very important interrupt is generated by a device called the clock. Clocks canbe designed to interrupt periodically (every 60th of a second, for example) or to accept aninterval from the computer and interrupt when that time has expired. If it were not forclock interrupts, a running process could sit in an accidental infinite loop that performsno service calls, and the kernel would never be able to wrest control from it. The kerneltherefore depends on the clock to force a context switch back to the kernel so that it canmake new policy decisions.The fact that processes belong to lists points to an important insight into operatingsystem structure:Level PrincipleActive entities are data structures when viewed from a lower level.The Level Principle applies to processes in this way: A process considers itself an activeentity that executes instructions and makes service calls on the kernel. From the kernel’spoint of view, however, the process is just a data structure (largely contained in the contextblock, but also including all the store used by the process) that can be manipulated.Manipulations include moving the process from list to list and causing the process to execute.Even an executing program like the kernel is subject to the Level Principle. Eachinstruction appears to be an active entity that moves information from one place toanother. However, instructions are just data to the hardware, which interprets thoseinstructions and causes the information to move.The converse of the Level Principle sometimes sheds new light as well. Objectsthat appear as data can occasionally be seen as active objects in some sense. For example,adding two numbers can be seen either as an action taken by some external agent oras an action taken by the first of the numbers on the second. Such a novel approach doesmake sense (the Smalltalk language is implemented this way!) and can lead to a useful