Base CS from zero
Concurrency vs parallelism
The event loop from the last lesson handles many tasks — many callbacks, from many devices — and it makes a program feel like it is doing several things “at once.” A web server with an event loop serves thousands of users seemingly together.
But look closely at the trace from lesson 03. At every single step, exactly one thing was running: one synchronous line, or one callback, never two. The event loop juggles many tasks, but it runs them strictly one at a time, taking turns.
So “at once” hides two genuinely different ideas. One is many tasks taking turns on a single processor. The other is many tasks truly running together on several processors. They are easy to confuse and important to separate. This lesson — the last in the track — gives each its name: concurrency and parallelism.
After this lesson you can define a core and a thread, define concurrency as interleaving tasks on one core so they take turns, define parallelism as tasks running at the same instant on multiple cores, explain why a single-core machine can be concurrent but never parallel, and state the slogan “concurrency is structure, parallelism is execution.”
A core is one fetch–decode–execute engine. Recall the fetch–decode–execute cycle from Unit 03. A core is one complete copy of that machinery: one engine that fetches one instruction, decodes it, executes it, and repeats. A core does exactly one instruction at a time — that is its nature.
Early processors had a single core: one engine, so one instruction in flight, ever. Modern processors are multi-core: the chip contains several cores — four, eight, more — each a full fetch–decode–execute engine, each running its own stream of instructions independently of the others.
The number of cores is a hard physical fact about a machine. It is the ceiling on how many instructions can be physically executing in the same instant. One core: one instruction at a time, full stop. Eight cores: up to eight instructions in the same instant.
A thread is one stream of instructions. A thread is a single, ordered stream of instructions being executed — one program counter advancing through code, one call stack of frames (Unit 08). Everything traced so far in this track has been a single thread: one PC, one stack, one instruction after another.
The distinction that matters: a thread is a stream of work; a core is the hardware that runs a stream. A core runs one thread at a given instant. A program may have many threads — many separate streams of work — but they only physically advance when a core is running them.
So the picture has two layers. How many threads a program has is a software choice. How many cores the machine has is a hardware fact. The relationship between those two numbers is exactly what separates concurrency from parallelism.
Concurrency: many tasks interleaved on one core, taking turns. Concurrency is dealing with many tasks by interleaving them: the core runs a bit of task A, then a bit of task B, then back to A — switching between them fast enough that all of them make progress over time. At any single instant only one task is running; the tasks take turns.
This is exactly the event loop from lesson 03. One core, one thread, but many callbacks all “in progress.” The loop runs one callback to completion, then the next, then the next. The program makes progress on many tasks, yet only one runs at a time. That is concurrency: many tasks structured so they can be interleaved on a single core.
Concurrency does not require multiple cores. A single-core machine is fully concurrent: it just switches between tasks fast. Concurrency is about how the work is organised so that one core can keep many tasks moving — it is a property of the program’s structure.
Parallelism: many tasks at the same instant on multiple cores. Parallelism is many tasks literally running at the same instant — and that requires multiple cores. Core 1 executes an instruction of task A while, in the very same instant, core 2 executes an instruction of task B. Two instructions genuinely in flight together, because there are two engines.
Parallelism cannot be faked on one core. One core is one fetch–decode–execute engine; it physically executes one instruction at a time. No amount of fast switching changes that — switching gives you concurrency (taking turns), never parallelism (true simultaneity). Parallelism needs the hardware: as many instructions at one instant as there are cores.
Hence the slogan: concurrency is about structure; parallelism is about execution. Concurrency is how you organise tasks so they can be interleaved — a design choice in the program. Parallelism is whether they actually run at the same instant — a fact about the hardware doing the running. A program can be concurrent on one core; it is parallel only when multiple cores run its tasks together.
Classifying four situations.
1 — A single-core machine runs an event loop with 100 queued callbacks. One core, so one instruction at a time. The 100 callbacks take turns via the loop. This is concurrency, not parallelism: many tasks interleaved, one core, never two at the same instant.
2 — An 8-core machine runs 8 separate threads, one per core, all computing at once. Eight cores, eight instructions in the same instant. This is parallelism: tasks literally running together. (It is also concurrent — the work is structured as many tasks — but the defining new fact is the true simultaneity.)
3 — A single-core machine is asked to run 2 tasks “in parallel.” Impossible as stated. One core executes one instruction at a time. The machine can be concurrent (interleave the 2 tasks, taking turns) but it can never be parallel — that needs a second core.
4 — A program with just one task, one thread, running on an 8-core machine. One stream of work uses one core. The other 7 cores sit unused. This is neither concurrent nor parallel in any meaningful sense — there is only one task. Extra cores do nothing for a program that has not been structured into multiple tasks.
The pattern: concurrency is decided by the program’s structure (is the work split into interleavable tasks?); parallelism is decided by the hardware (are multiple cores running those tasks at the same instant?).
Common mistake
A common mistake is to treat “concurrent” and “parallel” as synonyms, or to assume more cores automatically make a program faster. They are different, and they do not. A program written as a single task with a single thread runs on exactly one core no matter how many the machine has — the extra cores stay idle. Parallelism only helps if the program is first structured concurrently into multiple tasks. Structure comes first; only then can the hardware run the pieces in parallel.
A single core executes how many instructions in one instant?
An event loop on a single-core machine interleaves 50 callbacks, taking turns. How many of those callbacks are running at the very same instant?
Parallelism means tasks running at the same instant. To run 4 tasks truly in parallel, at minimum how many cores does the machine need?
A single-core machine runs many interleaved tasks. Type 1 if this is concurrency, 2 if this is parallelism.
A program is one task with one thread, running on a 16-core machine. How many cores are actually doing this program's work?
What is the difference between concurrency and parallelism?
A core is one fetch–decode–execute engine; it runs exactly one instruction at a time. A thread is one ordered stream of instructions — one program counter, one call stack. Concurrency is dealing with many tasks by interleaving them on a single core: the tasks take turns, and only one runs at any instant — the event loop is concurrency. Parallelism is many tasks literally running at the same instant, which requires multiple cores, one instruction per core in flight together. A single-core machine can be fully concurrent but never parallel. The slogan: concurrency is about structure (how the work is organised into interleavable tasks) and parallelism is about execution (whether the hardware actually runs those tasks at the same instant).
This is the final lesson of the Base CS track. Trace the line you have walked. Unit 01: bits — everything is patterns of two symbols. Units 02–03: those bits sit in memory, and a processor runs the fetch–decode–execute cycle over them. Unit 04: that machine code is what your language compiles down to. Units 05–06: values, types, and variables — named cells holding state. Units 07–08: control flow steers the program counter, and functions stack up frames on the call stack. Units 09–10: data is laid out in memory, and abstraction lets you stop thinking about the layers below. Unit 11: when a program fails, the stack trace and undefined behaviour become readable, not mysterious. And Unit 12: because the CPU is fast and devices are slow, programs are arranged with async, callbacks, an event loop, and a clear-eyed grasp of concurrency versus parallelism. A computer is no longer a black box. It is a fast, simple machine running a fetch–decode–execute cycle over bits — and every layer above, all the way up to the program you write, is something you can now reason about, step by step.