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.

Figure 6.1 Some ipcs output.

linux$ ipcs ------ Shared Memory Segments ------ key shmid owner perms bytes nattch status <-- 1 0x00000000 25198594 root 666 247264 3 ------ Semaphore Arrays ------ key semid owner perms nsems status 0x00000000 65537 root 666 4 0x00000000 98306 root 666 16 <-- 2 0x00000000 131075 root 666 16 0x00000000 163844 root 666 16 ------ Message Queues ------ key msqid owner perms used-bytes messages <-- 3

(1) One shared memory segment attached (shared) by three processes.

(2) Four sets of semaphores all owned by root.

(3) No message queues are currently allocated.

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).

Table 6.1. ipcs Command Line Options.

Figure 6.2 Using ipcs to display the details on a specific resource.

linux$ ipcs -s -i 65537 Semaphore Array semid=65537 uid=0 gid=1002 cuid=0 cgid=1002 <-- 1 mode=0666, access_perms=0666 nsems = 4 otime = Wed Feb 27 23:00:00 2002 ctime = Fri Jan 4 13:18:00 2002 semnum value ncount zcount pid 0 1 0 0 0 1 1 0 0 20719 2 1 0 0 20797 3 1 0 0 0

(1) Specifics of the four-element semaphore.

The limits for each facility are established when the kernel is generated. The command

linux$ /sbin/sysctl -a

displays all the configurable kernel parameters. On our system, this command generates a large amount of output. The IPC related information from this command is as follows :

... kernel.sem = 250 32000 32 128 kernel.msgmnb = 16384 kernel.msgmni = 16 kernel.msgmax = 8192 kernel.shmmni = 4096 kernel.shmall = 2097152 kernel.shmmax = 33554432 ...

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.