Shared Memory Multiprocessors: How Multicore Chips Actually Cooperate

Multicore processors are the most common form of parallel hardware today, but the way their cores actually share memory varies in important ways. This article explains the shared memory multiprocessor model, contrasts uniform and non-uniform memory access designs, and covers how the operating system and programmer coordinate work across cores.

Shared Memory MultiprocessorUMA and NUMAMulticore Coordination

~3 min read · Updated Sep 6, 2026

The Dominant Model: Shared Memory Multiprocessing

The multicore shift discussed earlier in this series, moving away from single fast cores due to the power wall, produced processors where multiple cores sit on the same chip and share access to the same main memory. This design is called a Shared Memory Multiprocessor, and it is by far the most common parallel architecture in consumer and server hardware today.

Why Shared Memory Simplifies Programming

In a shared memory system, any core can directly read or write any location in main memory, using the same address space every other core uses. This is a significant advantage for programmers compared to systems where each processor has entirely separate memory, since data can be shared between threads simply by having them access the same memory address, relying on the cache coherence mechanisms discussed earlier in this series to keep every core's view consistent.

Uniform Memory Access (UMA)

In a UMA (Uniform Memory Access) design, every core experiences the same access latency to any location in main memory, regardless of which specific core is making the request. This design is conceptually simple, but scaling it to a very large number of cores becomes difficult, since all cores compete for access to the same shared memory pathways.

Non-Uniform Memory Access (NUMA)

A NUMA (Non-Uniform Memory Access) design addresses this scaling problem by physically dividing memory into regions, each located closer to a specific group of cores. A core can access memory in its own nearby region faster than memory located near a different group of cores, even though the entire memory space still appears as one unified address space to software.

UMA:
All cores ↔ single shared memory,
same latency regardless of which core accesses it

NUMA:
Core Group A ↔ Local Memory A (fast access)
Core Group B ↔ Local Memory B (fast access)
Core Group A ↔ Memory B (slower, cross-region access)

NUMA designs scale to far larger numbers of cores than UMA, at the cost of requiring software, and sometimes the programmer explicitly, to be aware of which memory region is "closer" for best performance.

Coordinating Work Across Cores

Regardless of whether a system uses UMA or NUMA, the operating system plays a central role in coordinating parallel execution: assigning different threads to different cores, migrating threads between cores as needed for load balancing, and relying on the synchronization primitives discussed earlier in this series, such as atomic instructions and locks, to ensure threads correctly coordinate access to shared data.

Why Understanding This Distinction Matters

Software written without any awareness of memory locality can perform noticeably worse on NUMA systems if threads frequently access memory located far from the core they are running on. Operating systems and performance-conscious software increasingly take NUMA topology into account explicitly, placing a thread's data in memory physically close to the core most likely to access it.

Written & researched by Dr. Shahin Siami

Related Articles

Common Misconceptions About Parallel Computing and the Book's Final Lessons

After covering everything from thread-level parallelism to warehouse-scale computing, it is worth correcting persistent misconceptions about parallel systems that even experienced engineers sometimes hold. This article addresses common fallacies about scaling and parallel hardware, then closes out the parallel processing chapter by tying together the full journey from a single instruction to a building full of cooperating machines.

Continue

Real Stuff: Benchmarking CPUs Against GPUs and Multiprocessor Matrix Multiply

Comparing a CPU and a GPU fairly requires a model that accounts for both computational throughput and memory bandwidth limits together. This article introduces the roofline model used to compare real hardware like the Intel Core i7 and NVIDIA Tesla GPU, then shows how matrix multiplication is accelerated across multiple processors as the final practical application of this chapter's parallel concepts.

Continue

Benchmarking Multiprocessors and Modeling Parallel Performance

Measuring the performance of a parallel system requires different tools and metrics than measuring a single-core processor. This article covers the specialized benchmarks used to evaluate multiprocessor systems, explains how to model scaling behavior as more processors are added, and revisits Amdahl's Law in the context of real-world performance measurement.

Continue

Cluster Networking: Connecting to the World Outside

A cluster of machines is only useful if it can communicate efficiently both internally and with the outside world. This article covers the networking layers involved in cluster communication, the tradeoffs between latency and bandwidth at scale, and how clusters connect to external networks and users.

Continue

Clusters, Warehouse-Scale Computers, and Network Topologies

Beyond a single chip, parallelism extends to entire buildings full of independent computers working together. This article explains the shift from shared memory multiprocessing to clusters of separate machines, introduces the concept of warehouse-scale computing, and covers the network topologies that connect these independent machines efficiently.

Continue

An Introduction to GPUs: Massive Parallelism for Data-Heavy Workloads

A GPU takes the SIMD idea covered earlier in this series to an extreme scale, running thousands of lightweight threads simultaneously to process massive amounts of independent data. This article explains why GPUs are architecturally so different from CPUs, how their thread execution model works, and what kinds of workloads benefit most from this design.

Continue