Chapter One: Introduction

1.1: Overview

IPC is the abbreviation for interprocess communication (interprocess communication). Traditionally, the term describes a variety of messaging (message passing) between processes running on an operating system.

In the evolution of the UNIX operating system over the past 30 years, message passing has undergone several stages of development.

• Pipe, the problem with pipelines is that they can only be used between processes with a common ancestor, but the problem has been solved with the introduction of a well-known pipeline (FIFO).
• System V Message Queuing was added to the System V kernel in the early the 1980s.
• POSIX Message Queuing is a POSIX real-time standard added.
• The remote procedure call appears in the mid 1980s.

Take a look at the evolution of the various forms of synchronization provided by UNIX as well:

• Early programs that require some form of synchronization (often for simultaneous modification of the same file for multiple processes) Use the secretive nature of the file system.
• The record lock was added to the Unix kernel in the early 20 's 80, and then posix.1 standardized in 1988.
• System V semaphores are joined with the System V shared memory area while System V Message Queuing joins the System V core (early the 1980s).
• POSIX semaphores and POSIX shared memory areas are also added by POSIX real-time standards.
• Mutexes (mutexes) and condition variables (condition variable) are two synchronization forms defined by the POSIX threading standard. Although often used for synchronization between threads, they can also provide synchronization between different processes.
• Read-write locks are another form of synchronization. They have not yet been standardized by POSIX.

1.2: Process, thread, and information sharing

Note: There is nothing to limit the use of any IPC technology to only two processes.

Persistence of the 1.3:IPC object

We can define the persistence of any type of IPC (persistence) as the length of time that an object of that type persists.

(1) The IPC object that continues with the process (process-persistent) persists until the last process that opened the object closes the object. For example, pipelines and FIFO are such objects.

(2) The Kernel-persistent IPC object that persists with the kernel persists until the kernel re-bootstrap or shows that the object is deleted. For example, the message queue, semaphore, and shared memory area of System V are such objects. POSIX message queues, semaphores, and shared memory areas must be at least persistent with the kernel. But it can also be consistent with the file system, depending on the implementation.

(3) The IPC object that persists with the file system (filesystem-persistent) persists until the object is deleted. The object retains its value even if the kernel is re-raised. POSIX Message Queuing, semaphores, and shared memory are persisted with the file system if they are implemented using a mapping file (not a required condition).

1.4: Name Space

When two or more unrelated processes use some type of IPC object to exchange information with each other, the IPC object must have a name or identifier of some sort, so that one of the processes (often the server) can create the IPC alignment, and the remaining processes can specify the same IPC object.

We will use a different naming convention in the later chapters to specifically describe some form of IPC. For a given IPC type, the set of possible names is collectively known as its namespace. namespaces are important because, for all forms of IPC except ordinary pipes, the name is the means by which the client and the server are connected to each other to exchange messages.

Summarizes the naming conventions used by different forms of IPC:

effects of 1.5:fork, exec, and exit on IPC objects

We need to understand the effects of the fork, exec, and _exit functions on the various forms of IPC discussed. A summary of this is made:

1.6: Error Handling: Wrap function

These error-handling functions are the authors in the actual call to encapsulate a layer of the function, added to the error of judgment, and print error messages and other operations, look at the source code to understand what is going on.

1.7:unix Standard

These are the things about UNIX standardization, and it's enough to know about it.

1.8: The IPC example index table in the book

In order to analyze various characteristics, the book mainly uses three kinds of interactive modes:

(1) File server: Client-server application, the client sends a path name to the server, and the server returns the contents of the file to the client.

(2) Producer-Consumer: one or more threads or processes (producers) put the data into a shared buffer, and one or more threads or processes (consumers) operate on the data of that shared buffer.

(3) Serial number continues to increase by 1: one or more threads or processes to a shared serial number continues to increase by 1. The serial number is sometimes in a shared file, sometimes in shared memory.

The first example analyzes various forms of message passing, and two other examples analyze various types of synchronization and shared memory areas.

1.9: Summary

IPC has traditionally been a cluttered field in UNIX. Although there are a variety of solutions, none of them is perfect. Our discussion is divided into 4 main areas:

(1) Message delivery (pipeline, FIFO, Message Queuing)

(2) Synchronization (mutex, condition variable, read-write lock, Semaphore)

(3) Shared memory area (anonymous shared memory area, named shared memory area)

(4) Procedure call (Solaris Gate, Sun RPC)

The persistence of various types of IPC objects can be process-persistent, kernel-persistent, and file-system-persistent.

Another feature of various types of IPC objects is the namespace, which is the process by which the IPC object is used, and how the threads identify each IPC object.

Chapter One: Introduction