Processes, Threads & the Kernel

Processes Threads and the Kernel · Open board

The one program standing between every other program and the real machine, handing out turns on the chip and private-looking slices of memory so a handful of real cores can serve hundreds of programs at once.

Before you start. The last lesson, How Code Becomes Execution (compilers, stack & heap), left one program’s instructions running as a single stream on the CPU, fetched and carried out one at a time, as if that program owned the chip outright. This lesson is about the hundreds of programs actually doing that on the same handful of cores at once, and the one piece of software that keeps them from reading or overwriting each other.

The idea in 30 seconds

The kernel is the one program with full access to the real hardware; everything else reaches the machine only through it.
A process is a running program with memory nothing else can read or write by accident; that wall is what keeps one crash from taking down everything else.
A thread is a worker inside a process that shares that process’s memory with the other threads in it, which makes talking between them fast and colliding with each other possible.
The address a program uses isn’t the real location in memory; the kernel and the chip translate it on every access, which is how two programs can use the same-looking address safely.
A scheduler gives each process or thread a short turn on a core and takes it back, thousands of times a second, which is what makes a handful of cores look like they’re running everything at once.
Every time a core switches from one thread to another it loses a little time, so piling on more threads than you have cores stops making a program faster.

Read the story · Skip to the numbers