Linux Kernel Architecture

Chapter 5: Locking and Interprocess Communication

Chapter 5: Locking and InterprocessCommunication.......................

5.1 Control Mechanisms

Before describing the various interprocess communication (IPC) and data synchronization options of

the kernel, let’s briefly discuss the ways in which communicating processes can interfere with each

other — and how this can be prevented. Our discussionis restricted to basic and central aspects. For

detailed explanations and numerous examples of classic problems, see the general textbooks on operating

systems that are available on the market.

5.1.1 Race Conditions

Let us consider a system that reads data from an external device via two interfaces. Independent data

packets arrive via both interfaces at irregular intervals and are saved in separate files. To log the order of

arrival of the data packets, a number is added at the end of each filename to indicate the ‘‘serial number‘‘

of the packet. A typical sequence of filenames would beact1.fil,act2.fil,act3.fil,andsoon.A

separate variable is used to simplify the work of both processes. This variable is held in a memory page

shared by both processes and specifies the next unused serial number (for the sake of simplicity, I refer

to this variable ascounterbelow).

When a packet arrives, the process must perform a few actions to save the data correctly:

1. It reads the data from the interface.


2. It opens a file with the serial numbercount.


3. It increments the serial number by 1.


4. It writes the data to the file and closes it.

Why should errors occur with this system? If each process strictly observes the above procedure and

increments the status variable at the appropriate places, the procedure should obviously function cor-

rectly not just with two but with any number of processes.

As a matter of fact, itwillfunction correctly in most cases — and this is where the real difficulty lies

with distributed programming — but it won’t in certain circumstances. Let us set a trap by calling the

processes that read data from the interfacesprocess 1andprocess 2:

Our scenario begins with a number of files to which a serial number has been added, say, 12 files in all.

The value ofcounteris therefore 13. Obviously a bad omen...

Process 1 receives data from the interface as a new block has just arrived. Dutifully it opens a file with

the serial number 13 just at the moment when the scheduler is activated and decides that the process has

had enough CPU time and must be replaced with another process — in this case, process 2. Note that at

this time, process 1 has read but not yet incremented the value ofcounter.

Once process 2 has started to run, it too receives data from its interface and begins to perform the neces-

sary actions to save these data. It reads the value ofcounter, increments it to 14, opens a file with serial

number 13, writes the data to the file, and terminates.

Soon it’s the turn of process 1 again. It resumes where it left off and increments the value ofcounterby 1,

from 14 to 15. Then it writes its data to the previously opened file with serial number 13 — and, in doing

so, overwrites the existing data of process 2.

This is a double mishap — a data record is lost, and serial number 14 is not used.