POSIX Shared Memory
POSIX shared memory is actually a variation of mapped memory (see "Creating and Using Mappings"). The major differences are:
You use shm_open(3RT) to open the shared memory object instead of calling open(2)
You use shm_unlink(3RT) to close and delete the object instead of calling close(2) which does not remove the object.
System V IPC
SunOS 5.9 and compatible operating environments also provide the System V inter process communication (IPC) package. System V IPC has effectively been replaced by POSIX IPC, but is maintained to support older applications.
See the ipcrm(1), ipcs(1), Intro(2), msgctl(2), msgget(2), msgrcv(2), msgsnd(2), semget(2), semctl(2), semop(2), shmget(2), shmctl(2), shmop(2), and ftok(3C) man pages for more information about System V IPC.
Permissions for Messages, Semaphores, and Shared Memory
Messages, semaphores, and shared memory have read and write permissions, but no execute permission, for the owner, group, and others, which is similar to ordinary files. Like files, the creating process identifies the default owner. Unlike files, the creating process can assign ownership of the facility to another user or revoke an ownership assignment.
IPC Interfaces, Key Arguments, and Creation Flags
Processes requesting access to an IPC facility must be able to identify the facility. To identify the facility to which the process requests access, interfaces that initialize or provide access to an IPC facility use a key_t key argument. The key is an arbitrary value or one that can be derived from a common seed at runtime. One way to derive such a key is by using ftok(3C), which converts a file name to a key value that is unique within the system.
Interfaces that initialize or get access to messages, semaphores, or shared memory return an ID number of type int. IPC Interfaces that perform read, write, and control operations use this ID.
If the key argument is specified as IPC_PRIVATE, the call initializes a new instance of an IPC facility that is private to the creating process.
When the IPC_CREAT flag is supplied in the flags argument appropriate to the call, the interface tries to create the facility if it does not exist already.
When called with both theIPC_CREAT and IPC_EXCL flags, the interface fails if the facility already exists. This behavior can be useful when more than one process might attempt to initialize the facility. One such case might involve several server processes having access to the same facility. If they all attempt to create the facility with IPC_EXCL in effect, only the first attempt succeeds.
If neither of these flags is given and the facility already exists, the interfaces return the ID of the facility to get access. If IPC_CREAT is omitted and the facility is not already initialized, the calls fail.
Using logical (bitwise) OR, IPC_CREAT and IPC_EXCL are combined with the octal permission modes to form the flags argument. For example, the statement below initializes a new message queue if the queue does not exist:
msqid = msgget(ftok("/tmp", 'A'), (IPC_CREAT | IPC_EXCL | 0400));
|
The first argument evaluates to a key ('A') based on the string ("/tmp"). The second argument evaluates to the combined permissions and control flags.
System V Messages
Before a process can send or receive a message, you must initialize the queue through msgget(2). The owner or creator of a queue can change its ownership or permissions using msgctl(2). Any process with permission can use msgctl(2) for control operations.
IPC messaging enables processes to send and receive messages and queue messages for processing in an arbitrary order. Unlike the file byte-stream data flow of pipes, each IPC message has an explicit length.
Messages can be assigned a specific type. A server process can thus direct message traffic between clients on its queue by using the client process PID as the message type. For single-message transactions, multiple server processes can work in parallel on transactions sent to a shared message queue.
Operations to send and receive messages are performed by msgsnd(2) and msgrcv(2), respectively. When a message is sent, its text is copied to the message queue. msgsnd(2) and msgrcv(2) can be performed as either blocking or non-blocking operations. A blocked message operation remains suspended until one of the following three conditions occurs:
The call succeeds.
The process receives a signal.
The queue is removed.
Initializing a Message Queue
msgget(2) initializes a new message queue. It can also return the message queue ID (msqid) of the queue corresponding to the key argument. The value passed as the msgflg argument must be an octal integer with settings for the queue's permissions and control flags.
The MSGMNI kernel configuration option determines the maximum number of unique message queues that the kernel supports. msgget(2) fails when this limit is exceeded.
The following code illustrates msgget(2).
#include <sys/ipc.h>
#include <sys/msg.h>
...
key_t key; /* key to be passed to msgget() */
int msgflg, /* msgflg to be passed to msgget() */
msqid; /* return value from msgget() */
...
key = ...
msgflg = ...
if ((msqid = msgget(key, msgflg)) == -1)
{
perror("msgget: msgget failed");
exit(1);
} else
(void) fprintf(stderr, "msgget succeeded");
...
|
Controlling Message Queues
msgctl(2) alters the permissions and other characteristics of a message queue. The msqid argument must be the ID of an existing message queue. The cmd argument is one of the following:
The following code illustrates msgctl(2) with all its various flags.
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/msg.h>
...
if (msgctl(msqid, IPC_STAT, &buf) == -1) {
perror("msgctl: msgctl failed");
exit(1);
}
...
if (msgctl(msqid, IPC_SET, &buf) == -1) {
perror("msgctl: msgctl failed");
exit(1);
}
...
|