What is a Thread?
A thread is a unit of execution within a process. If a process is a restaurant, threads are the individual employees — the chef, the waiter, the cashier. They all work within the same restaurant (process), share the same kitchen (memory), and coordinate to get the job done.
Every process has at least one thread — the main thread. But a process can have multiple threads, all running concurrently within the same address space. This is different from having multiple processes, which each have their own separate memory.
Process vs. Thread
The key difference between processes and threads comes down to what they share:
PROCESS THREADS
┌─────────────────────┐ ┌─────────────────────┐
│ Process 1 │ │ Process 1 │
│ ┌─────────────────┐ │ │ ┌─────────────────┐ │
│ │ Thread 1 │ │ │ │ Code │ Data │ │
│ │ Thread 2 │ │ │ ├───────┼────────┤ │
│ │ Thread 3 │ │ │ │ T1 │ T2 T3 │ │
│ └─────────────────┘ │ │ │ Stack │ Stack │ │
│ Code Data Heap │ │ │ Regs │ Regs │ │
└─────────────────────┘ │ └───────┴────────┘ │
│ Shared: Code, Data, │
Each process has its own: │ Heap, Files │
• Memory space └─────────────────────┘
• Files
• State Each thread has its own:
• Stack
• Registers
• Program counter
- Processes are isolated. Each has its own memory space, its own files, its own everything. Communication between processes requires special mechanisms (pipes, sockets, shared memory).
- Threads share the same memory, the same files, and the same address space. They can read and write to the same variables directly. But they each have their own stack, registers, and program counter.
This makes threads much lighter than processes. Creating a thread is faster, switching between threads is faster, and communication between threads is simpler. The trade-off is that threads can accidentally interfere with each other — one thread can overwrite a variable that another thread is reading.
Why Use Multiple Threads?
Threads solve several practical problems:
- Responsiveness — A web browser can load a page in one thread while keeping the user interface responsive in another. If loading froze the entire browser, users would think it crashed.
- Resource Sharing — Threads naturally share memory, making it easy to divide work without copying data between address spaces.
- Economy — Creating and switching between threads is much cheaper than creating and switching between processes.
- Scalability — On multi-core processors, multiple threads can truly run in parallel — one per core — dramatically speeding up computation.
User Threads vs. Kernel Threads
There's an important distinction in where threads are managed:
- User-level threads — Managed by a thread library in user space, without the OS knowing about them. They're fast to create and switch, but if one thread makes a blocking system call, the entire process blocks — even the other threads.
- Kernel-level threads — Managed by the OS itself. The kernel is aware of each thread and can schedule them independently. If one thread blocks, others can continue running.
Modern operating systems use kernel threads. Linux, Windows, and macOS all manage threads at the kernel level, giving the OS full control over scheduling and resource allocation.
The Multithreading Model
Different operating systems map user threads to kernel threads differently:
- Many-to-One — Many user threads map to one kernel thread. Simple but limiting — if one thread blocks, all block.
- One-to-One — Each user thread maps to a kernel thread. Most flexible — threads can run in parallel and block independently. Used by Linux and Windows.
- Many-to-Many — Many user threads map to many kernel threads. Allows multiplexing — you can have more user threads than kernel threads. Used by some older systems.
The one-to-one model dominates today because it gives the best balance of flexibility and performance.