进程调度

进程上下文和中断上下文

Besides executing code on behalf of a user program, the kernel can also be activated by asynchronous
hardware interrupts, and is then said to run in interrupt context. The main difference to running in process
context is that the userspace portion of the virtual address space must not be accessed. Because interrupts
occur at random times, a random userland process is active when an interrupt occurs, and since the
interrupt will most likely be unconnected with the cause of the interrupt, the kernel has no business
with the contents of the current userspace. When operating in interrupt context, the kernel must be more
cautious than normal; for instance, it must not go to sleep. This requires extra care when writing interrupt
handlers and is discussed in detail in Chapter 2. An overview of the different execution contexts is given
in Figure 1-5.

A second way of switching from user mode to kernel mode is by means of interrupts — switching is
then triggered automatically. Unlike system calls, which are invoked intentionally by user applications,
interrupts occur more or less arbitrarily. Generally, the actions needed to handle interrupts have nothing
to do with the process executing when the interrupt occurred. For example, an interrupt is raised when
an external block device has transferred data to RAM, although these data may be intended for any
process running on the system. Similarly, incoming network packages are announced by means of an
interrupt. Again, it is unlikely that the inbound package is intended for the process currently running.
For this reason, Linux performs these actions in such a way that the running process is totally unaware
of them.

The preemptive scheduling model of the kernel establishes a hierarchy that determines which process
states may be interrupted by which other states.
❑ Normal processes may always be interrupted — even by other processes. When an important
     process becomes runnable — for example, an editor receives long-awaited keyboard input — the
        scheduler can decide whether to execute the process immediately, even if the current process is
       still happily running. This kind of preemption makes an important contribution to good interac-
      tive behavior and low system latency.
❑ If the system is in kernel mode and is processing a system call, no other process in the system
   is able to cause withdrawal of CPU time. The scheduler is forced to wait until execution of the
  system call has terminated before it can select another process. However, the system call can be
 suspended by an interrupt.1
❑ Interrupts can suspend processes in user mode and in kernel mode. They have the highest prior-
   ity because it is essential to handle them as soon as possible after they are issued.

One option known as kernel preemption was added to the kernel during the development of kernel 2.5.
This option supports switches to another process, if this is urgently required, even during the execution
of system calls in kernel mode (but not during interrupts). Although the kernel attempts to execute
system calls as quickly as possible, the time needed may be too long for some applications that are reliant
on constant data streams. Kernel preemption can reduce such wait times and thus ensure ‘‘smoother‘‘
program execution. However, this is at the expense of increased kernel complexity because many data
structures then need to be protected against concurrent access even on single-processor systems. This
technique is discussed in Section 2.8.3.

A classical Unix process is an application that consists of binary code, a chronological thread (the com-
puter follows a single path through the code, no other paths run at the same time), and a set of resources
allocated to the application — for example, memory, files, and so on. New processes are generated using
the fork and exec system calls:
❑
fork generates an identical copy of the current process; this copy is known as a child process. All
resources of the original process are copied in a suitable way so that after the system call there
are two independent instances of the original process. These instances are not linked in any way
but have, for example, the same set of open files, the same working directory, the same data in
memory (each with its own copy of the data), and so on.3
❑
exec replaces a running process with another application loaded from an executable binary file.
In other words, a new program is loaded. Because exec does not create a new process, an old
program must first be duplicated using fork, and then exec must be called to generate an addi-
tional application on the system.
Linux also provides the clone system call in addition to the two calls above that are available in all Unix
flavors and date back to very early days. In principle, clone works in the same way as fork, but the new
process is not independent of its parent process and can share some resources with it. It is possible to
specify which resources are to be shared and which are to be copied — for example, data in memory,
open files, or the installed signal handlers of the parent process.
clone is used to implement threads. However, the system call alone is not enough to do this. Libraries are
also needed in userspace to complete implementation. Examples of such libraries are Linuxthreads and
Next Generation Posix Threads.