Shared memory is a region of memory that two or more processors or programs can access simultaneously. It’s one of the fastest ways for different parts of a computer system to exchange data, because instead of sending messages back and forth, they simply read from and write to the same block of memory. The concept applies at two levels: hardware (where multiple CPU cores share physical RAM) and software (where separate programs on the same machine share a mapped memory segment).
How Shared Memory Works in Hardware
Modern computers have multiple processor cores, and those cores need to work with the same pool of memory. The two main designs for this are symmetric multiprocessing (SMP) and non-uniform memory access (NUMA).
In an SMP system, every CPU core connects to memory through a shared link, giving each core equal access to all system memory. This is the simpler design, and it’s what you’ll find in most consumer laptops and desktops. No core has a speed advantage over another when reading or writing data.
NUMA builds on SMP but divides memory into sections, or “nodes,” each physically closer to a particular CPU socket. A processor can still access memory attached to a different socket, but it has to go through a shared bus to get there. That bus has limited bandwidth, so when multiple processors compete for it, performance drops. NUMA is common in multi-socket servers where dozens of cores need to share terabytes of RAM, and the tradeoff of uneven access times is worth the ability to scale up.
The Cache Coherency Problem
Sharing memory sounds straightforward until you realize that each CPU core keeps its own small, fast copy of recently used data in a local cache. If core A updates a value in its cache but core B still has the old version, you get incorrect results. This is the cache coherency problem, and every shared memory system needs a solution for it.
The most widely used solution is the MESI protocol, named after the four states a cached copy of data can be in: Modified (this core changed the value and it hasn’t been written back to main memory yet), Exclusive (this is the only cached copy and it matches main memory), Shared (multiple cores have identical copies), and Invalid (this copy is stale and shouldn’t be used).
Here’s what happens in practice. When core A wants to write to data that core B also has cached, core A broadcasts an “invalidate” signal on the system bus. Core B sees this signal, marks its copy as Invalid, and core A proceeds with the write, changing its local state to Modified. If core B later needs that data, it will have to fetch the updated version. This snooping process happens automatically in hardware, invisible to the programmer, and it’s what makes shared memory reliable even when multiple cores are modifying data at the same time.
Shared Memory Between Programs
At the operating system level, shared memory is a method of inter-process communication (IPC). Normally, each program runs in its own isolated memory space, unable to see or touch another program’s data. Shared memory creates an exception: a designated segment that multiple programs can map into their own address space.
The typical sequence works like this. One process creates a shared memory segment, setting its size and access permissions. That process then “attaches” the segment, which maps it into the process’s own memory so it can read and write to it like any other variable. Other processes that know the segment’s name (and have the right permissions) can then open the same segment and map it into their own memory space. At that point, a write by one process is immediately visible to all others sharing that segment.
On Windows, this is done by creating a named file mapping object, then calling a function that returns a pointer into that shared region. A second process opens the same named mapping and gets its own pointer to the same underlying data. On Linux and other Unix-like systems, POSIX provides equivalent calls that work on the same principle: create a named shared object, set its size, and map it into your address space.
Shared memory is the fastest form of IPC because the data never needs to be copied between processes. With pipes or sockets, the operating system copies data from one process’s buffer into kernel space and then out to the other process. With shared memory, both processes are reading the exact same bytes in RAM. The tradeoff is that programs sharing memory must coordinate their access carefully to avoid corrupting data, typically using locks or semaphores.
Shared Memory in GPU Programming
Graphics processors take shared memory to another level. A modern GPU has thousands of small cores organized into groups (called blocks in NVIDIA’s CUDA framework), and each block gets its own pool of fast, on-chip shared memory. This is a different tier of memory from the GPU’s main “global” memory, and the speed difference is dramatic: shared memory has roughly 5 nanoseconds of latency, while global memory can take around 300 nanoseconds or more. That makes global memory potentially 150 times slower.
GPU programmers use shared memory as a kind of manually managed cache. The common pattern is to load a chunk of data from slow global memory into fast shared memory, let all the threads in a block work on it there, and then write the results back. Any thread within the same block can access the shared memory, but threads in different blocks cannot see each other’s shared memory. The shared memory only exists for as long as that block of threads is running, while global memory persists for the entire application.
How Programming Languages Handle It
When multiple threads within a single program share memory (as opposed to separate programs sharing an OS-level segment), the programming language needs to provide tools to keep things orderly. The core challenge is that modern compilers and processors reorder instructions for performance, which can cause one thread to see another thread’s writes in an unexpected order.
Languages like C++ address this with atomic operations: special instructions guaranteed to complete as a single, indivisible step that all threads see consistently. C++ has continued expanding these tools, with recent standards adding atomic operations for floating-point types and new mechanisms for safely reclaiming memory that multiple threads might still be reading. These features let programmers write lock-free data structures, which avoid the performance cost of traditional locks by carefully controlling the order in which memory writes become visible.
Higher-level languages abstract much of this away. Java’s volatile keyword and synchronized blocks, Python’s multiprocessing shared memory module, and Go’s channels all provide safer (if sometimes slower) ways to share data between concurrent tasks. The underlying hardware mechanism is the same, but the language runtime handles the coordination details that C++ programmers manage manually.
Why Shared Memory Matters
Shared memory is the foundation of nearly all parallel computing. Every time your computer runs a multi-threaded application, renders a video frame on a GPU, or lets two programs exchange data without writing to disk, shared memory is doing the work. Its main advantage is raw speed: no copying, no serialization, no network overhead. Its main cost is complexity, because any time two entities can modify the same data, you need careful coordination to prevent corrupted or inconsistent results. The hardware handles some of that coordination automatically through protocols like MESI, but software developers still carry significant responsibility for getting concurrent access right.