Concurrency vs parallelism

Concurrency is about structure: a program has several tasks *in progress* whose steps can interleave — a request being parsed while another waits for the database. Parallelism is about execution: several instruction streams running *simultaneously* on separate cores. A single core gives you concurrency without parallelism by time-slicing; the tasks make progress in turns (Concurrency versus Parallelism).

Each exists without the other. An event loop is concurrent and not parallel: thousands of connections in flight, one thread executing. A SIMD instruction adding eight floats, or a GPU kernel, is parallel without being concurrent in the program-structure sense. Multi-threading on multiple cores is both.

The distinction decides where speedups come from. If a task is I/O-bound, concurrency alone helps — the waiting overlaps — and parallelism adds nothing because the CPU was idle anyway. If it is CPU-bound, only parallelism helps, and only the parallelisable fraction speeds up (Amdahl’s law); the serial 10% caps you at 10× no matter how many cores.

And it decides where bugs come from: race conditions are a property of concurrency. Two threads incrementing a counter can lose an update on a single core if the scheduler preempts between load and store. You do not need two cores to have a race; you need two interleavable tasks and shared state (Race Conditions). Parallelism adds a second class of problems — memory visibility and reordering across cores — on top.