You could think of the kernel as a server that answers requests; these requests can come either from a process running on a CPU or an external device issuing an interrupt request. We make this analogy to underscore that parts of the kernel are not run serially, but in an interleaved way. Thus, they can give rise to race conditions, which must be controlled through proper synchronization techniques. A general introduction to these topics can be found in Section 1.6.
We start this chapter by reviewing when, and to what extent, kernel requests are executed in an interleaved fashion. We then introduce the basic synchronization primitives implemented by the kernel and describe how they are applied in the most common cases. Finally we illustrate a few practical examples.
In Section 4.3, a kernel control path was defined as a sequence of instructions executed by the kernel to handle interrupts of different kinds.
Each kernel request is handled by a different kernel control path,
which usually executes several different kernel functions. For
example, when a User Mode process issues a system call request, the
system_call( ) function (see Chapter 9) begins this particular kernel control path
ret_from_sys_call( ) function ends it (see
As we said, kernel requests may be issued in several possible ways:
A process executing in User Mode causes an exception — for
instance, by executing an
int 0x80 assembly language instruction. ...