3.1. Concurrency with IPC¶

Timeline of major CSF topics with Processes and IPC highlighted

“The fundamental problem of communication is that of reproducing at one point either exactly or approximately a message selected at another point.”
Claude Shannon

As soon as computers were able to run multiple processes concurrently, the natural next step was to make the processes communicate with each other. This chapter focuses on interprocess communication technologies, which emerged in the 1960s and 1970s. For instance, Douglas McIlroy, who had previously contributed to the Multics OS in the late 1960s, introduced the concept of pipes in UNIX (1973).

Chapter Objectives

In this chapter, we will address the following instructional objectives:

We will distinguish the properties of the two basic models for performing IPC.
We will compare and contrast the mechanics and uses of message passing IPC.
We will explore how shared memory techniques blur the lines of what constitutes a process.
We will examine code illustrating practical applications of IPC.

Processes are a robust mechanism for isolating programs from one another. In a multiprogramming environment with hundreds of processes running concurrently, the kernel ensures that a segmentation fault in one process (say, a web browser media plugin) cannot affect another (your email client). Similarly, once a process uses fork() to create a child process, the parent and child have distinct copies of every variable; changing the value of the variable in the child will not affect the parent, and vice versa.

In some circumstances, however, the isolation imposed by separate processes can be undesirable. For instance, all of the tabs in a modern web browser run in different processes but share the same overall browser configuration settings. If you add a new bookmark in one tab, it would be tedious to have to add that bookmark manually to all other open tabs. Similarly, it would be a waste of system resources for all of those processes to have duplicate copies of the browser source code.

As another example of why you might need to break the isolation guarantees of processes, consider a printer queue. While the kernel itself is responsible for controlling and accessing the printer, there are certain devoted system processes that provide the user with an interface to work with. With this process, you can find out if the printer is low on toner, what documents are queued up to be printed, and what printer errors might be occurring. This queue is running in a separate process. When you want to print the document in your word processor, the data must be transferred from one process to another.

This chapter focuses on the mechanics and uses of interprocess communication (IPC). IPC allows two or more processes to exchange data while maintaining most of the guarantees of isolation. Some IPC exchanges are transient and are established only at the time the data is needed; once the transfer is complete, the IPC connection is terminated and the processes return to complete isolation from one another. Other IPC exchanges involve a persistent connection that can last for long durations, even when the two processes are not explicitly communicating. In this case, since these are distinct processes, they retain some isolation guarantees; if one of the processes crashes, the other is unlikely to be affected, unless the crash actually affects the shared IPC connection. Our goal is to examine the different techniques that can be used and when each technique is most appropriate.