Information Technology Reference
In-Depth Information
User-level resource allocation policy. One of the tasks of an operating
system is resource allocation | deciding which users or which processes
get how much CPU time, how much memory, and so forth. In turn, many
applications are resource adaptive | able to optimize their behavior to
differing amounts of CPU time or memory. An example is a garbage
collected system like the Java runtime. Within limits, a Java process can
adapt to different amounts of available memory by changing the frequency
of how often it runs its garbage collector. The more memory, the less time
Java needs to run its collector, speeding up execution. This only works
if the operating system somehow is able to inform the process when its
allocation needs to change, e.g., because some other process needs more
memory or less at the moment.
We should note that upcalls from kernels to user processes are not always
needed. Many applications are more simply structured around an event loop
that polls for events, and then processes each event in turn. In this model, the
kernel can pass data to the process by sending it events, provided they do not
need to be handled immediately. In fact, until recently, Windows lacked support
for the immediate delivery of upcalls to user-level programs.
We next describe UNIX signals as a concrete example of kernel support for
upcalls. As shown in Figure 2.15 and Figure 2.16, most of the features in UNIX
signals have a direct analogue with hardware interrupts:
Types of signals. In place of hardware-defined interrupts and excep-
tions, the kernel defines a limited number of types of signals that can be
received by a process.
Handlers. Each process defines its own handlers for each signal type,
much as the kernel defines its own interrupt vector table. If a process
does not define a handler for a specific signal, then the kernel calls a
default handler instead.
Signal stack. Applications have the option to run UNIX signal handlers
either on the process's normal execution stack or on a special signal stack
allocated by the user process in user memory. Running signal handlers
on the normal stack can reduce the flexibility of the signal handler in
manipulating the stack, e.g., to cause a language-level exception to be
raised.
Signal masking. A UNIX signal handler automatically masks further
delivery of that type of signal until the handler returns. The program can
mask other signals, either all together or individually, as needed.
Processor state. The kernel provides the UNIX signal handler a data
structure containing the saved state of the program counter, stack pointer,
and general purpose registers when the program was interrupted. Nor-
mally, when the handler returns, the kernel reloads the saved state back
