The Interprocess Communication (IPC) Overview


Contents

About this document
What is interprocess communication?
Reasons to use interprocess communication
Similarities and differences in IPC calls
How to see what is currently active
     Fields common to each of the IPC types
     The first two characters can be one of these: RSCD-
     IPCs need permissions for owner, group and other
     Headings that are special to message queues
     Headings that are special to semaphores
     Headings that are special to shared memory
Semaphores
Message queues
Shared memory
Understanding memory mapping
Mapping files with the shmat subroutine

About this document

This document defines the interprocess communication (IPC) and is applicable to AIX versions 3.2.x and 4.x.


What is interprocess communication?

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.


Reasons to use interprocess communication

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.


Similarities and differences in IPC calls

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:


How to see what is currently active

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)

Fields common to each of the IPC types

Some of the fields are common to each of the IPC types:

T
Type=   m (shared memory), s (semaphore) or q (message queues)
ID
This is the identifier for the entry similar to a file descriptor. It is used by the operations function calls to access the resource after a get is performed on it.
KEY
Similar to a file name, this is what the routine uses to get, or open, the resource. When you get this name, the return value is the ID. If the key is 0x00000000 (IPC_PRIVATE), this entry can only be used by related, parent/child processes.
MODE
Permissions and status. The meaning of the field is different for each of the IPC types.

The first two characters can be one of these: RSCD

R and S
These are for the message queues and indicate a process is waiting on a message send or receive call.
D
Indicates the shared memory segment has been deleted but will not disappear until the last process attached to it releases it.

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.

C
This shared memory segment will be cleared when the first process attaches to it.
Flag not set.
The next nine characters are permission bits with r indicating read access for this position; w indicating either write or alter access, depending upon the IPC facility it is attached to.
No permissions for this operation.

IPCs need permissions for owner, group and other.

OWNER
The login name of the owner
GROUP
The name of the group that owns the entry
CREATOR
The login name of the creator of the entry
CGROUP
The group of the creator of the entry
CTIME
The time when the associated entry was created or changed

Headings that are special to message queues

CBYTES
The current total byte count of all messages in the queue
QNUM
The number of messages currently in the queue
QBYTES
The maximum number of bytes allowed for all messages in the queue
LSPID
The ID of the last process that sent a message to the queue
LRPIC
The ID of the last process that received a message in the queue
STIME
The time the last message was sent to the queue
RTIME
The time the last message was received, or read, from the queue

Headings that are special to semaphores

NSEMS
The number of semaphores in the set for this entry
OTIME
The time the last operations was done for this semaphore entry

Headings that are special to shared memory

NATTCH
The current number of processes attached to this segment
SEGSZ
The size of the segment in bytes
CPID
The process ID of the creator of the segment
LPID
The process ID of the last process to either attach or detach from this segment
ATIME
The time of the last attach to the segment
DTIME
The time of the last detach from the segment

Semaphores

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.


Message queues

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

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.


Understanding memory mapping

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 files with the shmat subroutine

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 ]