What is POSIX Shared Memory?
POSIX Shared Memory lets two or more unrelated processes share a region of memory — without creating a file on disk. Think of it as a shared whiteboard in RAM that any process can write to or read from, as long as it knows the name of that whiteboard.
The key difference from other IPC methods: data lives directly in RAM, making it the fastest IPC mechanism available. Processes map the same physical memory into their own virtual address space and communicate at memory speed — no kernel copy, no socket overhead.
Linux provides multiple ways to share memory between processes. POSIX shared memory is the modern, recommended approach. Here is how it fits in the IPC landscape:
| Mechanism | Naming | Disk File? | Speed | Persists? |
|---|---|---|---|---|
| System V Shared Memory | Integer Key | No | Fast | Until reboot |
| Shared File Mapping | File path | Yes | Fast | Survives reboot |
| POSIX Shared Memory ✓ | String name | No (RAM only) | Fastest | Until reboot |
| Pipes / FIFOs | File path (FIFO) | Yes (FIFO) | Medium | No |
The key idea: a POSIX shared memory object is stored in a memory-based filesystem (usually mounted at /dev/shm on Linux). It has no real disk backing. The workflow in every program is always the same four steps:
shared object
(creator only)
address space
(cleanup)
Once step 3 is done, both processes see the same bytes at their respective mapped addresses. Writing to the region in one process is immediately visible in the other — no system calls needed for actual data transfer.
Each process has its own virtual address space, but both map to the same physical pages in RAM. The kernel maintains this mapping via the page table.
/dev/shm/myobj
shared pages
Important: The virtual addresses are different in each process (0x7f000000 vs 0x7e800000), but they point to the same physical pages. This is why you must use offsets, not absolute pointers, when storing references inside shared memory.
POSIX shared memory requires one header and a linker flag:
#include <sys/mman.h> /* shm_open, shm_unlink, mmap, munmap */
#include <sys/stat.h> /* mode constants like S_IRUSR */
#include <fcntl.h> /* O_CREAT, O_RDWR, O_RDONLY */
#include <unistd.h> /* ftruncate, close */
Compile with -lrt to link the POSIX realtime library:
gcc writer.c -o writer -lrt
gcc reader.c -o reader -lrt
On modern Linux (glibc 2.17+), -lrt is sometimes optional, but always include it for portability.
On Linux, POSIX shared memory objects are created under /dev/shm/. This directory is backed by a tmpfs filesystem — a RAM-based virtual filesystem. You can actually see your shared memory objects:
# After creating a shared memory object named "/mydata":
ls -la /dev/shm/
# Output:
# -rw------- 1 ravi ravi 4096 Jun 12 10:00 mydata
# Check size
stat /dev/shm/mydata
The leading / in the name "/mydata" is required by POSIX. On Linux, this maps to /dev/shm/mydata. Some implementations put it under a different path, but the API hides that detail from you.
Tip: If your program crashes without calling shm_unlink(), the object stays in /dev/shm/ until manually removed or the system reboots. Always clean up!
Key Terms in This Chapter
Q1. What is the key advantage of shared memory over pipes or message queues for IPC?
Shared memory avoids data copying. With pipes, data is copied from user space to kernel space and then to the reading process. With shared memory, both processes directly access the same physical RAM — zero copies, maximum speed.
Q2. What is the difference between POSIX shared memory and System V shared memory?
POSIX shared memory uses string names and file descriptors, integrating naturally with the UNIX I/O model. System V uses integer keys and identifiers with its own set of system calls (shmget, shmat, shmctl). POSIX shared memory objects can be inspected with standard tools like ls, stat, fchmod.
Q3. Why are POSIX shared memory objects said to be “not backed by a disk file”?
They live in tmpfs, a RAM-based filesystem at /dev/shm. The data never gets written to a physical disk. This means it is faster than file-backed mappings but the data is lost on reboot.
Q4. Why should you use offsets instead of pointers inside a shared memory region?
Different processes map the same shared memory object at different virtual addresses. An absolute pointer valid in Process A points to meaningless memory in Process B. An offset from the start of the mapped region is the same in both processes.
Q5. What happens to a POSIX shared memory object if the creating process crashes before calling shm_unlink()?
The object persists in /dev/shm/ until explicitly removed with shm_unlink() or the system reboots. This is a potential resource leak and security concern.