Originally Published: Wednesday, 15 August 2001 Author: Subhasish Ghosh
Published to: develop_articles/Development Articles Page: 2/4 - [Printable]

Understanding Re-entrant Kernels

Undertanding the details of the Linux kernel may seem beyond the reach of many people, but at Linux.com we don't believe in "beyond the reach". In this article Ghosh begins his exploration down into the depths of the machine with a look at how a multi-threaded program can help illustrate re-entrancy, and vica versa.

Re-Entrant Kernels  << Page 2 of 4  >>

Re-entrant Kernels

All Unix Kernels are re-entrant. This means that: "several processes may be executing in the Kernel Mode at the same time." Of course on uniprocessor systems only one process can progress at one instant in time, but the others are blocked in Kernel Mode waiting for the CPU time. For example, suppose a process issues a read to a disk. After issuing the read, the Kernel will let the disk controller handle it and in the mean while resume executing the other waiting processes. After the read from the disk has completed, an interrupt notifies the Kernel that the device has satisfied the read, and thus the former process resumes the execution. This feature in Unix Kernels(Linux Kernel) is referred to as "re-entrancy". It's like seeing the kernel as a massive and very fast switch.

Now the question that comes up is: Okay, now we know what re-entrancy means, but how is it implemented in reality? Well, one way to provide re-entrancy is to write functions so that they modify only local variables and do not alter global data structures. Such functions are referred to as "Re-entrant functions". A Kernel that implements "re-entrant routines" are referred to as "Re-entrant Kernels". Other than using "re-entrant functions", a Kernel can also use "Locking" methods to ensure that only one process can execute a non-re-entrant function at a time.

But one very significant point to keep in mind is: In Kernel Mode, every single process acts on its own set of memory locations and thus cannot interfere with the others.

On a "Re-entrant Kernel", when a hardware interrupt occurs, it is able to suspend the current running process, even if the process is in Kernel Mode. This improves the throughput of the device controllers that issue interrupts. What exactly happens is this: When a device issues an interrupt, it waits for the CPU to acknowledge. If the Kernel answers quickly, the device controller will be able to perform other tasks while the CPU handles the interrupt.

A Kernel Control Path

Soon we'll look into Kernel re-entrancy in more detail. But first, let's understand what a "kernel control path" means. A kernel control path denotes the sequence of instructions that the Kernel executes to handle a system call, an exception or an interrupt. If we consider the simplest case, the CPU executes a kernel control path sequentially from the first instruction to the last. But, this does not always happen. There are events which the CPU interleaves with the kernel control paths. Some of these events include:

  1. If a process executing in User Mode invokes a system call and the corresponding kernel control path verifies that the request cannot be satisfied immediately.

  2. The CPU detects an "exception". It can be of many types, for example, an access to a page not present in RAM - while running a kernel control path.

  3. Hardware interrupts enabled. If a hardware interrupt occurs while the CPU is running a kernel control path. In such a case, the first kernel control path is left unfinished and the CPU starts processing another kernel control path for handling the interrupt.

Theoretically speaking, this is all that we can say about re-entrancy issues in a Unix/Linux Kernel. But as mentioned earlier, the real fun of learning this stuff begins when we create a program, and see the "re-entrant routines" in action. So, let's move on to the next section and get our hands dirty with some raw Linux Kernel programming.

Re-Entrant Kernels  << Page 2 of 4  >>