Why Concurrency Isn’t the Same as Parallelism: A Simple Analogy

We often hear about designing parallel, high‑concurrency programs, yet many people think they clearly understand the difference between parallelism and concurrency. In fact, the distinction can be subtle.

Parallelism refers to multiple executions happening at the same time, typically requiring multiple cores. Concurrency is about structuring a program so that it can be divided into independent modules that can proceed without waiting for each other; it does not depend on multiple cores.

Consider the analogy of a person making tea: boiling water, washing cups, fetching tea leaves. Doing these steps concurrently can be achieved by having several people work simultaneously (parallelism) or by a single person overlapping the steps (concurrency).

Rob Pike’s story about ground‑hogs moving discarded manuals to a furnace illustrates the concept. Initially one ground‑hog uses a cart, which is slow. Adding a second ground‑hog does not help unless they share resources. Introducing a second cart creates a concurrent pipeline: one ground‑hog loads the cart, another transports, a third unloads. The pipeline can be further refined by adding more stages, such as a middle station or an extra cart, turning the pipeline into a parallelizable system.

Four concurrent steps are identified:

Load the books onto the cart;

Move the cart to the furnace;

Unload the books into the furnace;

Return the empty cart.

Each refinement splits the task into finer subtasks, naturally producing concurrency, which can later be parallelized.

In software terms, the books represent data, the ground‑hogs are CPUs, the carts are serialization/network mechanisms, and the furnace is the consumer (e.g., a web service). The described concurrent model maps to a scalable web‑service architecture.

The original talk is titled Concurrency is not Parallelism. Reference links:

Slides: https://talks.golang.org/2012/waza.slide

Video: https://www.youtube.com/watch?v=cN_DpYBzKso&t=550s