Linux Kernel Architecture

(Jacob Rumans) #1

Chapter 5: Locking and Interprocess Communication


5.2 Kernel Locking Mechanisms


The kernel requires no explicit mechanisms to facilitate the distributed use of memory areas because
it has unrestricted access to the full address space. On multiprocessor systems (or similarly, on unipro-
cessor systems with enabled kernel preemption; see Chapter 2), this gives rise to a few problems. If
several processors are in kernel mode at the same time, they can access the same data structure simulta-
neously — and this is exactly what causes the problem described in the previous sections.

In the first SMP-capable version of the kernel, the solution to this problem was very simple. Only one
processor at a time was ever allowed to be in kernel mode. Consequently, uncoordinated parallel access
to data was automatically ruled out. Unfortunately, this method was obviously not very efficient and
was quickly dropped.

Nowadays, the kernel uses a fine-grained network of locks for the explicit protection of individual data
structures. If processor A is manipulating data structure X, processor B may perform any other kernel
actions — but it may not manipulate X.

The kernel provides various locking options for this purpose, each optimized for different kernel data
usage patterns.

❑ Atomic Operations— These are the simplest locking operations. They guarantee that simple
operations, such as incrementing a counter, are performed atomically without interruption even
if the operation is made up of several assembly language statements.
❑ Spinlocks— These are the most frequently used locking option. They are designed for the short-
term protection of sections against access by other processors. While the kernel is waiting for a
spinlock to be released, it repeatedly checks whether it can acquire the lock without going to
sleep in the meantime (busy waiting). Of course, this is not very efficient if waits are long.
❑ Semaphores— These are implemented in the classical way. While waiting for a semaphore to
be released, the kernel goes to sleep until it is woken. Only then does it attempt to acquire the
semaphore.Mutexesare a special case of semaphores — only one user at a time can be in the
critical region protected by them.
❑ Reader/Writer Locks— These are locks that distinguish between two types of access to data
structures. Any number of processors may perform concurrentreadaccess to a data structure,
but write access is restricted to a single CPU. Naturally, the data structure cannot be read while
it is being written.

The sections below discuss the implementation and usage of these options in detail. Their deployment is
omnipresent over all the kernel sources, and locking has become a very important aspect of kernel devel-
opment, both for fundamental core kernel code as well as for device drivers. Nevertheless, when I discuss
specific kernel code in this book, I will mostly omit locking operations except if locks are employed in
an unusual way, or if special locking requirements must be fulfilled. But why do we omit this aspect of
the kernel in other chapters if it is important? Most of you will certainly agree that this book does not
belong to the thinner specimen on your bookshelves, and adding a detailed discussion of locking in all
subsystems would certainly not be the ultimate diet for the book. More important, however, is that in
most cases a discussion of locking would obstruct and complicate the view on the essential working of a
particular mechanism. My main concern, however, is to provide exactly this to you.

Fully understanding the use of locks requires line-by-line familiarity with all kernel code affected by
the locks, and this is something a book cannot provide — in fact, something that itshould not even try:
Free download pdf