OS & Systems Fundamentals • Processes vs ThreadsEasy⏱️ ~2 min
Process vs Thread: Core Architecture and Isolation
A process is an execution environment with its own virtual address space, page tables, file descriptor table, and kernel accounting. It represents a complete, isolated program instance. Threads, in contrast, are schedulable execution contexts that live inside a process and share the process's address space and most resources. The operating system schedules threads, not processes directly. Process boundaries primarily exist for isolation, protection, and resource accounting.
The key architectural difference is resource ownership. When you switch between threads within the same process, the CPU avoids flushing the entire Translation Lookaside Buffer (TLB) and keeps the same page table base. Switching between processes requires loading a new page table base register and typically incurs larger TLB and cache penalties. Modern processors with Process Context Identifiers (PCID) help reduce these costs but don't eliminate them entirely.
Google Chrome demonstrates extreme process isolation: each browser tab runs in its own renderer process consuming roughly 50 to 150 MB RSS (Resident Set Size). A typical Chrome window spawns dozens of processes including renderer, GPU, network, and utility processes. This trades hundreds of megabytes of memory for crash containment. If one tab crashes, it doesn't take down your entire browser. Site Isolation pushed this further to defend against speculative execution attacks like Spectre.
💡 Key Takeaways
•Processes provide complete isolation with separate address spaces, page tables, and file descriptors. Context switching between processes incurs TLB flushes and page table changes, typically adding microseconds of overhead.
•Threads share the address space and resources of their parent process. Switching between threads of the same process is faster, avoiding page table changes and keeping TLB entries valid.
•Memory overhead differs dramatically: Each process carries kernel structures and page tables (50 to 150 MB typical for Chrome renderers), while threads add only stack space (0.5 to 8 MB reserved per thread).
•Chrome uses multi process architecture with dozens of processes per window for crash isolation. One renderer crash doesn't affect other tabs or the browser core.
•Android Zygote demonstrates process forking efficiency: preinitialized process forks app processes using copy on write, sharing initialized libraries and saving hundreds of milliseconds of cold start time.
📌 Examples
Google Chrome: 10 tabs open = 30+ processes (renderers, GPU, network, utilities). Each renderer process: 50-150 MB RSS. One tab crashes, others unaffected.
PostgreSQL: process per connection model. 2,000 connections = 2,000 backend processes consuming 10-20 GB memory just for backends (5-10 MB each at idle).
Android Zygote: Forks new app processes from preinitialized template. Copy on write sharing saves 200-300ms cold start vs starting from scratch.