This document defines the interprocess communication (IPC) and is applicable to AIX versions 3.2x and 4.x.
Official definition:
Interprocess communication (IPC) is used for programs to communicate data to
each other and to synchronize their activities. Semaphores, shared memory, and
internal message queues are common methods of interprocess communication.
What it means:
IPC is a method
for two or more separate programs or processes to communicate with
each other. This avoids using real disk-based files (and the associated I/O
overhead) to pass information. Like a file, you must first create (or if it
exists) open the file (resource), use it and close it. Like real files, the
resources have an owner, a group, and permissions. Until you remove the
file (resource) it continues to exist. Unlike real disk-based files, semaphores,
message queues and shared memory do not persist across reboots.
Use IPCs when you need to talk between programs, you want the talking to be fast, and you don't want to write the code to manage the low-level details of communication between the processes. Since these are kernel routines, the kernel will take care of the "hard part" of the communication. For example, when you are waiting for a resource that is protected by a semaphore to become available, if you request access and the resource is currently in use, the kernel will place you in a waiting queue. When the resource becomes available, the kernel unblocks your process and you can continue. The kernel also ensures that operations are atomic, which means that a test and increment operation to set a semaphore cannot be interrupted.
All of the resources in the interprocess communication routines act in a similar manner and the function calls used are very similar:
Functionally Message System Call Shared
Queue Semaphore Memory
-------------------------------------------------------------------
Allocate an IPC, msgget semget shmget
gain access to an
IPC.
control an IPC, obtain/ msgctl semctl shmctl
modify status info,
remove an IPC.
IPC operations; send/ msgsnd shmat
receive messages. msgrcv semop shmdt
Perform semaphore
operations. Attach/free
a shared memory segment
IPC routines differ in the amount of data that is manipulated:
Two command line utilities are available:
ipcrm - removes semaphores, message queues and shared memory
areas from the system.
ipcs - shows status of semaphores, message queues and shared memory
The ipcrm command is a front end for the shmctl, semctl, and msgctl system calls. Depending upon what flags are passed to the command and if the caller has proper permissions, this will mark the proper resource for deletion. As with disk based files, if someone is currently using the resource, it will remain available to that process until they detach from it.
The ipcs command is used to view current status:
ipcs -am (shared memory)
ipcs -aq (message queues)
ipcs -as (semaphores)
Some of the fields are common to each of the IPC types:
NOTE: The key will be changed to ipc_private (all 0's) when the segment has been marked for removal but still has attached processes.
- Flag not set
The next 9 characters are permission bits with
r - meaning read access for this position.
w - OR a meaning either write or alter access (depends upon
the IPC facility its attached to)
- no permissions for this operation.
Semaphores are specialized data structures used to coordinate access to a non-sharable resource. Cooperating (or possibly competing) processes use semaphores to determine if a specific resource is available. If a resource is unavailable, the system will by default place the requesting process in an associated queue. The system will notify the waiting process when the resource is available. This alleviates the process from using polling to determine the availability of the resource.
Most often, semaphores are used for process synchronization. (software lock). Semaphores are normally of either type BINARY or COUNTING, depending upon how they are used. A binary semaphore controls a single resource and it is either 0 (resource is in use) or 1 (resource is available). A counting semaphore increments and decrements a counter (non-negative integer) to determine if an instance of the controlled resource is currently available.
The system assures that the test and increment operation is atomic, which means it cannot be divided or interrupted.
A message queue is used for passing small amounts of information between processes in a structured manner. Information to be communicated is placed in a predefined message structure. The process generating the message specifies its type (user defined) 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 manner. Message queues provide the user with a means of multiplexing data from multiple producers. Non-related processes, executing at different times, can use a message queue to pass information.
Shared memory allows multiple processes to share virtual memory space. Coordination-wise, this is the fastest but not necessarily the easiest way for processes to communicate with one another. In general, one process creates/allocates the shared memory segment. The size and access permissions for the segment are set when it is created. The process then attaches (opens) the shared segment, causing it to be mapped into its current data space. If needed, the creating process then initializes the shared memory. Once created, and if permissions permit, other processes can gain access to the shared memory and map (open) it into their data space.
Ordinarily, semaphores are used to coordinate access to a shared memory segment. When a process is finished with the shared memory segment, it can detach from it (this does not delete it). The creator of the segment may grant ownership of the segment to another process. When all processes are finished with the shared memory segment, the process that created the segment is usually responsible for removing it.
Information is communicated by accessing shared process data space. This is the fastest method of inter-process communication. Shared memory allows participating processes to randomly access the shared memory segment.
The speed in which application instructions are processed on a system is proportionate to the number of access operations required to obtain data outside of program-addressable memory. The system provides two methods for reducing the transactional overhead associated with these external read and write operations. You can map file data into the process address space. You can also map processes to anonymous memory regions that may be shared by cooperating processes.
Memory-mapped files provide a mechanism for a process to access files by directly incorporating file data into the process address space. The use of mapped files can significantly reduce I/O data movement since the file data does not have to be copied into process data buffers, as is done by the read and write subroutines. When more than one process maps the same file, its contents are shared among them, providing a low-overhead mechanism by which processes can synchronize and communicate.
Mapped memory regions, also called shared memory areas, can serve as a large pool for exchanging data among processes. The available subroutines do not provide locks or access control among the processes. Therefore, processes using shared memory areas must set up a signal or semaphore control method to prevent access conflicts and to keep one process from changing data that another is using. Shared memory areas can be most beneficial when the amount of data to be exchanged between processes is too large to transfer with messages, or when many processes maintain a common large database.
Mapping can be used to reduce the overhead involved in writing and reading the contents of files. Once the contents of a file are mapped to an area of user memory, the file may be manipulated as if it were data in memory, using pointers to that data instead of input/output calls. The copy of the file on disk also serves as the paging area for that file, which saves paging space.
A program can use any regular file as a mapped data file. You can also extend the features of mapped data files to files containing compiled and executable object code. Because mapped files can be accessed more quickly than regular files, the system can load a program more quickly if its executable object file is mapped to a file.
For more information on using any regular file as a mapped data file See "Creating a Mapped Data File with the shmat Subroutine" in your online documentation.