POSIX IPC (Inter-Process Communication)

POSIX IPC is a collection of standardized C application programming interfaces (APIs) defined by IEEE Std 1003.1 to enable efficient, synchronized data exchange between distinct processes running on Unix-like operating systems (including Linux, macOS, and BSD).

POSIX IPC was designed to replace the legacy System V IPC facilities (shmget, semget, msgget), replacing obscure integer keys and separate kernel memory tables with clean, filesystem-like namespace identifiers, file descriptor integration, and standard POSIX permission models.

The Three Pillars of POSIX IPC

POSIX standardizes three primary IPC mechanisms:

Mechanism	Header	Primary APIs	Characteristics & Best Use Case
Shared Memory	`<sys/mman.h>`	`shm_open()`, `shm_unlink()`, `mmap()`	Highest throughput (nanosecond-scale access); zero kernel copying; requires separate synchronization primitive (semaphore/mutex).
Semaphores	`<semaphore.h>`	`sem_open()`, `sem_wait()`, `sem_post()`, `sem_init()`	Counting synchronization primitives; named (cross-process) and unnamed (threads or parent-child); async-signal-safe.
Message Queues	`<mqueue.h>`	`mq_open()`, `mq_send()`, `mq_receive()`, `mq_notify()`	Structured, prioritized message passing with asynchronous kernel event notifications (`SIGEV_SIGNAL`, `SIGEV_THREAD`).

POSIX IPC vs. System V IPC: Why POSIX Won

Before POSIX standardization, Unix systems relied on System V IPC (originating from AT&T Unix System V in 1983). While still present in modern kernels for backward compatibility, POSIX IPC resolved several fundamental design flaws of System V:

1. Naming and Namespace Integration

System V: Used integer keys generated via ftok(path, id). If two unrelated processes computed conflicting keys, collisions occurred silently. Removing abandoned resources required the external ipcrm utility.
POSIX: Uses human-readable path-like names starting with a forward slash (e.g., /my_shared_memory). In Linux, these names map directly to a memory-backed virtual filesystem (/dev/shm for shared memory, /dev/mqueue for message queues), allowing standard inspection with ls -l and cleanup with rm.

2. File Descriptor Unification

System V: Relied on separate, esoteric kernel identifiers completely decoupled from the process file descriptor table. They could not be integrated with select(), poll(), or close().
POSIX: shm_open() and mq_open() return standard integer file descriptors. Shared memory segments are mapped using the universal mmap() call and closed with standard close().

3. Resource Lifetime and Cleanup

System V: Kernel-persistent. If a process crashed without explicitly calling shmctl(..., IPC_RMID, ...) or semctl(), the memory segment or semaphore array remained allocated in RAM indefinitely until reboot or manual administrative deletion (ipcrm).
POSIX: Reference-counted unlinking. Calling shm_unlink() or mq_unlink() immediately removes the name from the system namespace, but the underlying kernel memory remains valid and accessible until every process that currently has it open calls close() or terminates.

Detailed POSIX IPC Guides

POSIX Shared Memory (shm_open, shm_unlink, mmap): Zero-copy high-throughput memory sharing, sizing with ftruncate(), and lifecycle management.
POSIX Semaphores (sem_open, sem_wait, sem_post): Named vs. unnamed semaphores, process synchronization, and async-signal safety.
POSIX Message Queues (mq_open, mq_send, mq_receive): Priority-based message passing, queue attributes, and non-blocking event loops with mq_notify().

Frequently Asked Questions (FAQ)

What is the difference between POSIX IPC and System V IPC?

POSIX IPC uses path-like names, integrates with standard file descriptors, and supports reference-counted unlinking, whereas System V IPC relies on integer keys (ftok), esoteric identifiers, and persistent kernel tables requiring manual administrative cleanup. In modern software development, POSIX IPC is strongly preferred across Linux, macOS, and BSD platforms for clarity, leak prevention, and seamless integration with standard file I/O tooling.

Are POSIX IPC objects persistent across system reboots?

No. POSIX IPC objects are kernel-persistent, meaning they remain allocated in memory as long as the operating system kernel is running, but are destroyed when the system reboots. If a process terminates without unlinking its shared memory or semaphore, the object remains accessible to other processes in /dev/shm until explicitly deleted via shm_unlink() or when the machine reboots.

How do you inspect and delete leaked POSIX IPC objects on Linux?

Inspect /dev/shm for shared memory and /dev/mqueue for message queues using standard commands like ls -l and rm. Unlike System V IPC which requires ipcs and ipcrm, POSIX IPC objects on Linux are exposed directly as memory-backed files in tmpfs filesystems, allowing developers to inspect sizes, permissions, and remove orphaned objects with standard shell commands.