Introduction

The designers of UNIX found the types of interprocess communications that could be implemented using signals and pipes to be restrictive . To increase the flexibility and range of interprocess communication, supplementary communication facilities were added. These facilities, added with the release of System V in the 1970s, are grouped under the heading IPC (Interprocess Communication). In brief, these facilities are

Message queues Information to be communicated is placed in a predefined message structure. The process generating the message specifies its type and places the message in a system- maintained message queue. Processes accessing the message queue can use the message type to selectively read messages of specific types in a first in first out (FIFO) manner. Message queues provide the user with a means of asynchronously multiplexing data from multiple processes.

Semaphores Semaphores are system-implemented data structures used to communicate small amounts of data between processes. Most often, semaphores are used for process synchronization.

Shared memory Information is communicated by accessing shared process data space. This is the fastest method of interprocess communication. Shared memory allows participating processes to randomly access a shared memory segment. Semaphores are often used to synchronize the access to the shared memory segments.

All three of these facilities can be used by related and unrelated processes, but these processes must be on the same system (machine).

Like a file, an IPC resource [1] must be generated before it can be used. Each IPC resource has a creator, owner, and access permissions. These attributes, established when the IPC is created, can be modified using the proper system calls. At a system level, information about the IPC facilities supported by the system can be obtained with the ipcs command. For example, on our system the ipcs command produces the following output shown in Figure 6.1.

[1] In the context of IPC facilities, the term resource indicates an instance of the facility.

The ipcs utility supports a variety of options for specifying a specific resource and the format of its output. The meaning of each is shown in Table 6.1.

Additionally, -s , -q , or -m can be used to indicate semaphore, message queue, or shared memory, and can be followed by i and a valid decimal ID to display additional information about a specific IPC resource (Figure 6.2).

A comparison of this output with that of the ipcs -l (limits) command easily establishes the role of each valuefor example, kernel.msgmni is the maximum number of message queues systemwide .

IPC resources exist and maintain their contents even after the process that created them has terminated . An IPC resource can be removed by its owner , using the appropriate system call within a program or by using the system-level command ipcrm . The message queue, shown in the output of the previous ipcs command, could be removed by its owner issuing the command

linux$ ipcrm sem 65537

The sem [2] command-line option tells ipcrm that a semaphore is to be removed, and the argument 65537 is the ID number of the semaphore. As there are per-user and systemwide limits to the number of IPC resources available, users should make a conscientious effort to remove unneeded allocated IPCs. Note that as superuser, it is unwise to capriciously remove root owned IPC resources.

[2] Use shm to indicate a shared memory segment or msg for a message queue.