Programming Interfaces Guide

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:

IPC_STAT: Place information about the status of the queue in the data structure pointed to by buf. The process must have read permission for this call to succeed.
IPC_SET: Set the owner's user and group ID, the permissions, and the size (in number of bytes) of the message queue. A process must have the effective user ID of the owner, creator, or superuser for this call to succeed.
IPC_RMID: Remove the message queue specified by the msqid argument.

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

Sending and Receiving Messages

msgsnd(2) and msgrcv(2) send and receive messages, respectively. The msqid argument must be the ID of an existing message queue. The msgp argument is a pointer to a structure that contains the type of the message and its text. The msgsz argument specifies the length of the message in bytes. The msgflg argument passes various control flags.

The following code illustrates msgsnd(2) and msgrcv(2).

#include <sys/types.h>
 #include <sys/ipc.h>
 #include <sys/msg.h>

 ...
 	int				msgflg;	/* message flags for the operation */
 	struct msgbuf 	*msgp;	/* pointer to the message buffer */
 	size_t			msgsz;	/* message size */
		size_t			maxmsgsize;
 	long				msgtyp;	/* desired message type */
 	int				msqid		/* message queue ID to be used */
 	...
 	msgp = malloc(sizeof(struct msgbuf) – sizeof (msgp–>mtext) 
							+ maxmsgsz);
 	if (msgp == NULL) {
 		(void) fprintf(stderr, "msgop: %s %ld byte messages.\n",
 				"could not allocate message buffer for", maxmsgsz);
 		exit(1);
 		...
 		msgsz = ...
 		msgflg = ...
 		if (msgsnd(msqid, msgp, msgsz, msgflg) == –1)
 			perror("msgop: msgsnd failed");
 		...
 		msgsz = ...
 		msgtyp = first_on_queue;
 		msgflg = ...
 		if (rtrn = msgrcv(msqid, msgp, msgsz, msgtyp, msgflg) == –1)
 			perror("msgop: msgrcv failed");
 		...

System V Semaphores

Semaphores enable processes to query or alter status information. They are often used to monitor and control the availability of system resources such as shared memory segments. Semaphores can be operated on as individual units or as elements in a set.

Because System V IPC semaphores can be in a large array, they are extremely heavy weight. Much lighter-weight semaphores are available in the threads library (see the semaphore(3THR) man page). Also, POSIX semaphores are the most current implementation of System V semaphores (see POSIX Semaphores). Threads library semaphores must be used with mapped memory (see Memory Management Interfaces).

A semaphore set consists of a control structure and an array of individual semaphores. A set of semaphores can contain up to 25 elements. The semaphore set must be initialized using semget(2). The semaphore creator can change its ownership or permissions using semctl(2). Any process with permission can use semctl(2) to do control operations.

Semaphore operations are performed by semop(2). This interface takes a pointer to an array of semaphore operation structures. Each structure in the array contains data about an operation to perform on a semaphore. Any process with read permission can test whether a semaphore has a zero value. Operations to increment or decrement a semaphore require write permission.

When an operation fails, none of the semaphores are altered. The process blocks unless the IPC_NOWAIT flag is set, and remains blocked until:

The semaphore operations can all finish, so the call succeeds.
The process receives a signal.
The semaphore set is removed.

Only one process at a time can update a semaphore. Simultaneous requests by different processes are performed in an arbitrary order. When an array of operations is given by a semop(2) call, no updates are done until all operations on the array can finish successfully.

If a process with exclusive use of a semaphore terminates abnormally and fails to undo the operation or free the semaphore, the semaphore stays locked in memory in the state the process left it. To prevent this occurrence, the SEM_UNDO control flag makes semop(2) allocate an undo structure for each semaphore operation, which contains the operation that returns the semaphore to its previous state. If the process dies, the system applies the operations in the undo structures. This prevents an aborted process from leaving a semaphore set in an inconsistent state.

If processes share access to a resource controlled by a semaphore, operations on the semaphore should not be made with SEM_UNDO in effect. If the process that currently has control of the resource terminates abnormally, the resource is presumed to be inconsistent. Another process must be able to recognize this to restore the resource to a consistent state.

When performing a semaphore operation with SEM_UNDO in effect, you must also have SEM_UNDO in effect for the call that performs the reversing operation. When the process runs normally, the reversing operation updates the undo structure with a complementary value. This ensures that, unless the process is aborted, the values applied to the undo structure are canceled to zero. When the undo structure reaches zero, it is removed.

Using SEM_UNDO inconsistently can lead to memory leaks because allocated undo structures might not be freed until the system is rebooted.

Initializing a Semaphore Set

semget(2) initializes or gains access to a semaphore. When the call succeeds, it returns the semaphore ID (semid). The key argument is a value associated with the semaphore ID. The nsems argument specifies the number of elements in a semaphore array. The call fails when nsems is greater than the number of elements in an existing array. When the correct count is not known, supplying 0 for this argument ensures that it will succeed. The semflg argument specifies the initial access permissions and creation control flags.

The SEMMNI system configuration option determines the maximum number of semaphore arrays allowed. The SEMMNS option determines the maximum possible number of individual semaphores across all semaphore sets. Because of fragmentation between semaphore sets, allocating all available semaphores might not be possible.

The following code illustrates semget(2).

#include			<sys/types.h>
#include			<sys/ipc.h>
#include			<sys/sem.h>
...
 	key_t		key;			/* key to pass to semget() */
 	int		semflg;			/* semflg to pass to semget() */
 	int		nsems;			/* nsems to pass to semget() */
 	int		semid;			/* return value from semget() */
		...
 	key = ...
 	nsems = ...
 	semflg = ...
 	...
 	if ((semid = semget(key, nsems, semflg)) == –1) {
 		perror("semget: semget failed");
 		exit(1);
 	} else
 		exit(0);
 ...

Controlling Semaphores

semctl(2) changes permissions and other characteristics of a semaphore set. It must be called with a valid semaphore ID. The semnum value selects a semaphore within an array by its index. The cmd argument is one of the following control flags.

GETVAL: Return the value of a single semaphore.
SETVAL: Set the value of a single semaphore. In this case, arg is taken as arg.val, an int.
GETPID: Return the PID of the process that performed the last operation on the semaphore or array.
GETNCNT: Return the number of processes waiting for the value of a semaphore to increase.
GETZCNT: Return the number of processes waiting for the value of a particular semaphore to reach zero.
GETALL: Return the values for all semaphores in a set. In this case, arg is taken as arg.array, a pointer to an array of unsigned short values.
SETALL: Set values for all semaphores in a set. In this case, arg is taken as arg.array, a pointer to an array of unsigned short values.
IPC_STAT: Return the status information from the control structure for the semaphore set and place it in the data structure pointed to by arg.buf, a pointer to a buffer of type semid_ds.
IPC_SET: Set the effective user and group identification and permissions. In this case, arg is taken as arg.buf.
IPC_RMID: Remove the specified semaphore set.

A process must have an effective user identification of owner, creator, or superuser to perform an IPC_SET or IPC_RMID command. Read and write permission is required, as for the other control commands.

The following code illustrates semctl(2).

#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>
...
 	register int				i;
 ...
 	i = semctl(semid, semnum, cmd, arg);
 	if (i == –1) {
 		perror("semctl: semctl failed");
 		exit(1);
...

Semaphore Operations

semop(2) performs operations on a semaphore set. The semid argument is the semaphore ID returned by a previous semget(2) call. The sops argument is a pointer to an array of structures, each containing the following information about a semaphore operation:

The semaphore number
The operation to be performed
Control flags, if any

The sembuf structure specifies a semaphore operation, as defined in sys/sem.h. The nsops argument specifies the length of the array, the maximum size of which is determined by the SEMOPM configuration option. This option determines the maximum number of operations allowed by a single semop(2) call, and is set to 10 by default.

The operation to be performed is determined as follows:

Positive integer increments the semaphore value by that amount.
Negative integer decrements the semaphore value by that amount. An attempt to set a semaphore to a value less than zero fails or blocks, depending on whether IPC_NOWAIT is in effect.
Value of zero means to wait for the semaphore value to reach zero.

The two control flags that can be used with semop(2) are IPC_NOWAIT and SEM_UNDO.

`IPC_NOWAIT`	Can be set for any operations in the array. Makes the interface return without changing any semaphore value if it cannot perform any of the operations for which `IPC_NOWAIT` is set. The interface fails if it tries to decrement a semaphore more than its current value, or tests a nonzero semaphore to be equal to zero.
`SEM_UNDO`	Allows individual operations in the array to be undone when the process exits.

The following code illustrates semop(2).

#include				<sys/types.h>
#include				<sys/ipc.h>
#include				<sys/sem.h>
...
 	int				i;			/* work area */
 	int				nsops;	/* number of operations to do */
 	int				semid;	/* semid of semaphore set */
 	struct sembuf	*sops;	/* ptr to operations to perform */
 	...
 	if ((i = semop(semid, sops, nsops)) == –1) {
 		perror("semop: semop failed");
 	} else
 		(void) fprintf(stderr, "semop: returned %d\n", i);
 ...

System V Shared Memory

In the SunOS 5.9 operating system, the most efficient way to implement shared memory applications is to rely on mmap(2) and on the system's native virtual memory facility. See Chapter 1, Memory Management for more information.

The SunOS 5.9 platform also supports System V shared memory, which is a less efficient way to enable the attachment of a segment of physical memory to the virtual address spaces of multiple processes. When write access is allowed for more than one process, an outside protocol or mechanism, such as a semaphore, can be used to prevent inconsistencies and collisions.

A process creates a shared memory segment using shmget(2). This call is also used to get the ID of an existing shared segment. The creating process sets the permissions and the size in bytes for the segment.

The original owner of a shared memory segment can assign ownership to another user with shmctl(2). The owner can also revoke this assignment. Other processes with proper permission can perform various control functions on the shared memory segment using shmctl(2).

Once created, you can attach a shared segment to a process address space using shmat(2). You can detach it using shmdt(2). The attaching process must have the appropriate permissions for shmat(2). Once attached, the process can read or write to the segment, as allowed by the permission requested in the attach operation. A shared segment can be attached multiple times by the same process.

A shared memory segment is described by a control structure with a unique ID that points to an area of physical memory. The identifier of the segment is called the shmid. The structure definition for the shared memory segment control structure can be found in sys/shm.h.

Accessing a Shared Memory Segment

shmget(2) is used to obtain access to a shared memory segment. When the call succeeds, it returns the shared memory segment ID (shmid). The following code illustrates shmget(2).

#include  <sys/types.h>
#include <sys/ipc.h>
#include <sys/shm.h>
...
 	key_t		key;			/* key to be passed to shmget() */
 	int		shmflg;		/* shmflg to be passed to shmget() */
 	int		shmid;		/* return value from shmget() */
 	size_t	size;			/* size to be passed to shmget() */
 	...
 	key = ...
 	size = ...
 	shmflg) = ...
 	if ((shmid = shmget (key, size, shmflg)) == –1) {
 		perror("shmget: shmget failed");
 		exit(1);
 	} else {
 		(void) fprintf(stderr,
 					"shmget: shmget returned %d\n", shmid);
 		exit(0);
 	}
 ...

Controlling a Shared Memory Segment

shmctl(2) is used to alter the permissions and other characteristics of a shared memory segment. The cmd argument is one of following control commands.

`SHM_LOCK`	Lock the specified shared memory segment in memory. The process must have the effective ID of superuser to perform this command.
`SHM_UNLOCK`	Unlock the shared memory segment. The process must have the effective ID of superuser to perform this command.
`IPC_STAT`	Return the status information contained in the control structure and place it in the buffer pointed to by `buf`. The process must have read permission on the segment to perform this command.
`IPC_SET`	Set the effective user and group identification and access permissions. The process must have an effective ID of owner, creator or superuser to perform this command.
`IPC_RMID`	Remove the shared memory segment. The process must have an effective ID of owner, creator, or superuser to perform this command.

The following code illustrates shmctl(2).

#include			<sys/types.h>
#include			<sys/ipc.h>
#include			<sys/shm.h>
...
 int		cmd;		/* command code for shmctl() */
 int		shmid;	/* segment ID */
 struct shmid_ds	shmid_ds; /* shared memory data structure to
 									hold results */
 	...
 	shmid = ...
 	cmd = ...
 	if ((rtrn = shmctl(shmid, cmd, shmid_ds)) == –1) {
 		perror("shmctl: shmctl failed");
 		exit(1);
 	...

Attaching and Detaching a Shared Memory Segment

shmat() and shmdt() are used to attach and detach shared memory segments (see the shmop(2) man page). shmat(2) returns a pointer to the head of the shared segment. shmdt(2) detaches the shared memory segment located at the address indicated by shmaddr. The following code illustrates calls to shmat(2) and shmdt(2)

#include			<sys/types.h>
#include			<sys/ipc.h>
#include			<sys/shm.h>

static struct state {	/* Internal record of attached segments. */
 	int		shmid;		/* shmid of attached segment */
 	char		*shmaddr;	/* attach point */
 	int		shmflg;		/* flags used on attach */
 	} ap[MAXnap];			/* State of current attached segments. */
 	int		nap;			/* Number of currently attached segments. */
 ...
 	char				*addr;			/* address work variable */
 	register int				i;			/* work area */
 	register struct state  *p;  /* ptr to current state entry */
 ...
 	p = &ap[nap++];
 	p–>shmid = ...
 	p–>shmaddr = ...
 	p–>shmflg = ...
 	p–>shmaddr = shmat(p->shmid, p->shmaddr, p->shmflg);
 	if(p–>shmaddr == (char *)-1) {
 		perror("shmat failed");
 		nap–-;
 	} else
 		 (void) fprintf(stderr, "shmop: shmat returned %p\n",
 					p–>shmaddr);
 	...
 	i = shmdt(addr);
 	if(i == –1) {
 		perror("shmdt failed");
 	} else {
 		(void) fprintf(stderr, "shmop: shmdt returned %d\n", i);
 		for (p = ap, i = nap; i–-; p++) {
 			if (p–>shmaddr == addr) *p = ap[–-nap];
 		}
 	}
 	...