POSIX Interprocess Communication

POSIX interprocess communication (IPC) is a variation of System V interprocess communication. It was introduced in the Solaris 7 release. Like System V objects, POSIX IPC objects have read and write, but not execute, permissions for the owner, the owner's group, and for others. There is no way for the owner of a POSIX IPC object to assign a different owner. POSIX IPC includes the following features:

• Messages allow processes to send formatted data streams to arbitrary processes.

• Semaphores allow processes to synchronize execution.

• Shared memory allows processes to share parts of their virtual address space.

Unlike the System V IPC interfaces, the POSIX IPC interfaces are all multithread safe.

POSIX Messages

The POSIX message queue interfaces are listed in the following table.

Table 7-2 POSIX Message Queue Interfaces

POSIX Semaphores

POSIX semaphores are much lighter weight than are System V semaphores. A POSIX semaphore structure defines a single semaphore, not an array of up to 25 semaphores.

The POSIX semaphore interfaces are shown below.

sem_open(3RT)

Connects to, and optionally creates, a named semaphore

sem_init(3RT)

Initializes a semaphore structure (internal to the calling program, so not a named semaphore)

sem_close(3RT)

Ends the connection to an open semaphore

sem_unlink(3RT)

Ends the connection to an open semaphore and causes the semaphore to be removed when the last process closes it

sem_destroy(3RT)

Initializes a semaphore structure (internal to the calling program, so not a named semaphore)

sem_getvalue(3RT)

Copies the value of the semaphore into the specified integer

sem_wait(3RT), sem_trywait(3RT)

Blocks while the semaphore is held by other processes or returns an error if the semaphore is held by another process

sem_post(3RT)

Increments the count of the semaphore

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.

The options in shm_open(3RT) are substantially fewer than the number of options provided in open(2).