Concurrency vs. Parallelism

Why this matters

Concurrency and parallelism describe fundamentally different things, and conflating them leads to architecture decisions that are impossible to reason about. Concurrency is a structural property: work arranged so multiple tasks can make progress in overlapping time windows. Parallelism is an execution property: two instructions literally running simultaneously on separate hardware. A single-core event loop is concurrent but not parallel; a GPU multiplying matrices runs thousands of threads in parallel. The distinction matters because the bugs they introduce and the fixes they require are completely different — a race condition is a concurrency problem, a serial bottleneck is a parallelism problem.

Demo

Concurrency is a structure: you arrange work so progress can overlap in time. Parallelism is an execution: two instructions literally run at the same wall-clock instant on two cores.

You can be concurrent without being parallel (one core, alternating tasks via an event loop). You cannot be parallel without being concurrent — parallelism is a special case where the scheduler chose to use more than one core.

Try it yourself

1. Find three real systems (e.g. Node.js event loop, Go runtime on one core, a GPU shader) and classify each as: concurrent-not-parallel, parallel-not-concurrent, or both. Write one sentence justifying each.
2. Read Rob Pike's 'Concurrency is not Parallelism' talk notes (linked in references). Find the slide where he shows a single-core gopher sorting books and explain why that is concurrent.
3. Predict: if you run a Go program with GOMAXPROCS=1 on a quad-core machine, is it concurrent? Is it parallel? Verify by checking how many OS threads runtime.NumCPU() vs. runtime.GOMAXPROCS(0) report.

References

• Go Blog — Concurrency is not Parallelism (Rob Pike)
• Communicating Sequential Processes (Hoare, 1978)
• The Free Lunch Is Over (Herb Sutter, 2005)