This document defines the interprocess communication (IPC) and is applicable to AIX versions 3.2.x 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
open the resource, use it and close it. Like real files, the
resources have an owner, a group, and permissions. Until you remove the
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 do not 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 details 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, that is, all zeros (0) when the segment has been marked for removal but still has attached processes.
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, by default, the system will 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, or 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, indicating that the resource is in use, or 1, indicating that the resource is available. A counting semaphore increments and decrements a counter, a 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. This method is the fastest to coordinate but not necessarily the easiest 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, or 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 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 without deleting. 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 interprocess 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.
[ Doc Ref: 90605205814708 Publish Date: Apr. 12, 2000 4FAX Ref: 8249 ]