Processes vs. threads

A process is a running instance of a program, along with everything it needs to run independently: its own private virtual address space (lesson 6), its own open file handles, its own set of resources. Two processes cannot directly read or write each other's memory — the operating system enforces that isolation. This is exactly why one crashing browser tab doesn't take down the whole browser (modern browsers run tabs as separate processes) and why one crashed program doesn't corrupt another's data.

A thread is a sequence of instructions the CPU executes, and every process has at least one (the "main thread"). Multiple threads within the same process share that process's memory space — the same heap, the same global variables, the same open file handles — while each thread still gets its own stack (lesson 3) and its own set of CPU registers.

Shared memory between threads is simultaneously the entire reason multithreading is useful and the entire reason it's dangerous. Useful, because threads can cooperate on the same data without expensive copying or explicit communication — two threads can both read and update the same in-memory cache directly. Dangerous, because uncoordinated access to that same shared data from multiple threads is exactly what produces race conditions (lesson 8) — a category of bug that doesn't exist between separate processes, precisely because separate processes don't share memory by default.

Because threads share memory, communicating between them is often as simple as reading or writing a shared variable (with proper synchronization). Processes, being isolated by design, need an explicit mechanism to communicate at all — Inter-Process Communication (IPC): pipes, sockets, shared memory segments the OS explicitly sets up, or message queues. This extra step is the isolation's cost, paid in exchange for the safety of one process's mistake staying contained to itself.