Processes and threads

Your program never talks to hardware directly. Between your code and the CPU, the disks, the network card, and the display sits the operating system — a piece of software that abstracts over the machine so that every program sees a clean, consistent interface regardless of which physical device it is running on. Understanding what the OS does explains a large fraction of the performance characteristics and failure modes you will encounter in real systems.

What an OS does

The OS has two fundamental jobs.

The first is hardware abstraction. A program reads from a file using the same read() system call whether the file lives on a USB stick, an NVMe SSD, a network share, or a RAM disk. The OS presents a unified virtual interface and translates it to the correct driver calls underneath. This is why code written on one machine can run on another with different hardware.

The second is resource management. Multiple programs run on the same machine simultaneously, competing for CPU time, memory, and I/O bandwidth. The OS is the arbiter: it decides which program runs when, how much memory each gets, and who gets to write to a shared file. Without this arbitration, programs would corrupt each other's memory and monopolise the CPU.

The part of the OS that handles these responsibilities directly is the kernel. The kernel runs in a privileged CPU mode (ring 0 on x86) that has unrestricted access to hardware. User programs run in an unprivileged mode (ring 3) and can only access hardware through the kernel — via system calls.

Processes and threads

A process is an instance of a running program. The OS gives each process the illusion that it owns the entire machine: its own address space (a private view of memory), its own open file descriptors, its own signal handlers, and its own program counter. Two processes cannot accidentally overwrite each other's memory because their address spaces are isolated by the hardware's memory management unit (MMU).

A thread is a unit of execution within a process. All threads in a process share the same address space and file descriptors, but each thread has its own:

• Program counter — where in the code this thread currently is.
• Stack — its own call stack and local variables.
• Register set — the CPU register values for this thread.

Because threads share memory, communication between threads is fast (just a shared variable) but dangerous (a data race can corrupt that shared variable). Communication between processes is safer (isolated address spaces prevent corruption) but slower (requires an OS-mediated channel like a pipe or socket).

Process A                    Process B
+------------------+         +------------------+
| Virtual memory   |         | Virtual memory   |  <- isolated
| Thread 1: PC, SP |         | Thread 1: PC, SP |
| Thread 2: PC, SP |         +------------------+
| Shared: heap,    |
|   file handles   |
+------------------+