Shared Memory: Zero Copies, Zero Protection

Virtual memory (The Virtual Address Space, Page Tables) already maps virtual pages in each process to physical frames. Nothing stops the kernel from mapping one physical frame into *two* page tables. Once it does, a store by process A at its virtual address 0x7f3a… lands in a frame that process B sees at its own virtual address 0x7e11…. No copy happens because there was never a second copy; the two processes are literally looking at the same RAM.

On Unix-style systems the modern API is POSIX shared memory: shm_open("/frames", O_CREAT | O_RDWR, 0600) creates a named object (on Linux it is a file in the /dev/shm tmpfs), ftruncate() sets its size, and mmap(…, MAP_SHARED, fd, 0) maps it. Any other process that opens the same name and maps it sees the same bytes. Linux also offers memfd_create() for anonymous shared objects passed by descriptor, and the older System V shmget/shmat family that ipcs still lists. Windows does the same thing with CreateFileMapping and MapViewOfFile; the mechanism is identical because the hardware is.

Shared memory is also what MAP_SHARED file mappings give you: two processes that mmap the same file share the page-cache pages, which is how a writer’s changes are visible to a reader without a write(). See Memory Mapping — a shared mapping of /dev/shm and a shared mapping of a regular file are the same kernel path with different backing.

A pipe transfer of a 4 MB frame is a write() that copies 4 MB into the kernel, a read() that copies it back out, and at least two context switches (Context Switching). Shared memory is a store by A and a load by B. On the same core the data may not even leave L2. A copy runs at perhaps 10 GB/s, so 4 MB is ~400 µs per copy — meaningful at 60 frames per second — while a mapped write-and-notify costs whatever the notification costs.

And there is the catch: notify. Shared memory moves data but carries no event. B does not know that A has finished writing a frame unless something tells it. So real shared-memory designs pair the segment with a control channel — a pipe, a Unix socket, an eventfd, a semaphore — that carries “frame 17 is ready” while the frame itself never moves. The control channel is small and slow; the data channel is huge and free.

The deeper cost is that the kernel has stepped out. With a pipe, A cannot write while B is reading — the kernel serialises them. With shared memory, A and B run truly in parallel on separate cores and nothing stops A from overwriting the frame B is halfway through reading. Every Race Conditions lesson from the concurrency module applies again, except now the two parties are processes that may be written in different languages by different teams, and a crash in one can leave the shared state half-updated with the lock held.

A normal Mutexes lives in one process’s memory and is meaningless to another. For shared memory you need locks whose state *is in the shared segment* and whose wait/wake mechanism the kernel understands across processes. POSIX gives pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED) for mutexes and condition variables placed inside the mapping, and named semaphores (sem_open("/frames-ready", …)) that any process can open by name (Semaphores and Condition Variables). On Linux both are built on futex, which takes the *physical* address into account, so two processes contending on the same shared word block and wake correctly.

For the common producer/consumer case the best-known structure is a ring buffer in the segment: a fixed array of slots plus a head index owned by the producer and a tail index owned by the consumer. With a single producer and a single consumer, each index is written by exactly one side, so Atomic Operations with acquire/release ordering are enough — no lock at all. The producer writes the slot, then publishes the new head with a release store; the consumer reads the head with an acquire load, then reads the slot. That is the design behind high-frequency trading feeds, DPDK and every serious logging shim.

What a lock cannot fix is a peer dying while holding it. A process-shared mutex left locked by a crashed process hangs everyone else forever unless it was created with PTHREAD_MUTEX_ROBUST, in which case the next locker gets EOWNERDEAD and must repair the state. Designs that want to survive peer crashes usually avoid locks in the data path and use the single-writer ring above, where a dead producer simply stops publishing.

PostgreSQL is a process-per-connection server (Creating Processes: fork, exec, wait): the postmaster forks a backend for each client. Every backend must see the same cached pages, the same lock table and the same WAL buffers, so all of that lives in one shared memory segment created at startup — shared_buffers (128 MB by default, often gigabytes in production) plus the lock manager, the commit log and more. Postgres uses anonymous mmap(MAP_SHARED|MAP_ANONYMOUS) mappings inherited across fork() for the bulk and a small System V segment for locking, and its LWLocks and spinlocks are exactly the process-shared primitives above, one per buffer, one per hash partition.

Browsers are the other canonical example. Chromium runs the renderer, GPU and browser as separate processes for isolation (VM vs Container: Where the Boundary Is explains why they went further and sandbox them). A rendered tile or a decoded video frame is far too large to send over the Mojo IPC channel, so the renderer draws into a shared-memory buffer and sends the GPU process a *handle* to it. The pixels never cross the channel. The same pattern — small control messages over a socket, bulk data in shared pages — appears in Wayland compositors, Android’s Binder and audio servers such as PipeWire.