Concurrency 101
The smallest mental model of concurrent programming — processes, threads, the scheduler, locks, deadlock — and why your multithreaded code keeps breaking in weird ways.
- Reading time
- ~26 min (+24 min optional)
- Level mix
- 1 beginner · 6 intermediate · 1 advanced
Most production bugs in multithreaded code come from misunderstanding a handful of concepts: how the OS schedules threads, how memory is shared (and isn’t) between them, what locks actually guarantee, and how deadlocks happen. This path walks through those concepts in order.
By the end you should know why “thread-safe” is a precise claim, why your fast lock is sometimes painfully slow, and why “just add another thread” usually doesn’t help.
Roadmap
Loading progress...
Units of execution
A running instance of a program, with its own memory, file handles, and CPU time — the unit the operating system schedules and isolates.
A single line of execution inside a process — the unit the CPU actually runs. A process can have many threads that share memory.
The part of the OS kernel that decides which thread runs on each CPU at any moment — balancing fairness, responsiveness, and throughput.
- Context SwitchOptional
The act of saving one thread's CPU state and loading another's so the same CPU core can run a different thread next.
Coordinating
A synchronization primitive that ensures only one thread at a time can hold it — the basic tool for protecting shared state from data races.
A state where two or more threads are each waiting for the other to release a lock — so none of them ever make progress.
Why it's so hard
- Cache CoherenceOptional
The set of protocols that keep multiple CPU caches in sync so all cores see a consistent view of memory.
- Memory HierarchyOptional
The layered set of storage in a computer — from registers to disk — trading size for speed.