Process vs thread.
A process is a kitchen; threads are the cooks working inside it.
Your computer runs many programs at once. Each running program is a process: it has its own private memory and the operating system keeps it walled off from the others, so one crashing cannot scribble on another’s data.
Inside a process, threads are the workers actually doing things. A process is the kitchen with all its supplies; the threads are the cooks moving around it.
- My kitchen, my rules.1
Each process is its own walled-off kitchen, with its own private supplies.
- Two of us on this order.2
Inside one kitchen, threads are the cooks actually doing the work.
- 3
They share the same counter and shelves, so handing work back and forth is quick.
- I had it first!4
But two cooks reaching for the same pot at once is where it goes wrong (a race).
- Wait for the token.5
So they take turns: a lock means only one cook touches the shared pot at a time.
- 6
Separate kitchens are safe but heavy; cooks in one kitchen are fast but need care.
Why threads are both great and dangerous
Because threads share the same memory, they can divide one big job and work on it together, using all your CPU cores. That is how a program does several things at once quickly.
But sharing is risky: if two threads change the same piece of data at the same moment, the result depends on who got there first — a "race condition". These bugs are subtle, intermittent, and notoriously hard to reproduce, which is why concurrency has a fearsome reputation.
How programs keep it sane
To stay safe, threads use coordination tools — locks, queues, and the like — to take turns touching shared data. Many systems also reuse a fixed pool of threads rather than creating new ones constantly, since spinning up a thread is not free.