Process vs Thread
The Question
What is the difference between a process and a thread?
What a Strong Answer Covers
- process = own memory space
- "thread = shared memory
- "separate stacks
- "IPC vs shared memory
Senior-Level Answer
A process is an independent unit of execution with its own memory space, including its own heap, stack, code segment, and data segment. The operating system allocates separate resources to each process and enforces memory isolation between them. This means one process cannot directly read or write the memory of another process, which provides strong fault isolation — if one process crashes, others remain unaffected.
A thread, by contrast, is a lightweight unit of execution that exists within a process. Multiple threads in the same process share the same memory space — they can read and write the same heap, global variables, and file descriptors. However, each thread maintains its own stack and its own set of CPU registers, including its own program counter. This means each thread has an independent execution path but operates on shared data.
The key trade-offs between the two come down to isolation versus efficiency. Process creation is expensive because the OS must allocate a new address space, set up page tables, and copy or clone resources. Context switching between processes is also costlier because the CPU must flush the TLB and swap page tables. Thread creation and context switching are cheaper because threads share the same address space — the OS only needs to save and restore registers and the stack pointer.
Communication between processes requires explicit inter-process communication mechanisms such as pipes, message queues, shared memory segments, or sockets. These add complexity and overhead. Threads communicate by simply reading and writing shared memory, which is fast but introduces the risk of race conditions. You must use synchronization primitives like mutexes, semaphores, or condition variables to coordinate thread access to shared data safely.
In practice, you choose processes when you need fault isolation — for example, a web server like Nginx uses worker processes so that a crash in one worker does not bring down the server. You choose threads when you need high-performance concurrency with shared state — for example, a database engine might use threads to handle concurrent queries that access the same in-memory buffer pool. Many modern systems use a hybrid approach: multiple processes each running multiple threads, combining isolation at the process level with efficient concurrency at the thread level.
It is also worth noting that some languages impose constraints. Python's Global Interpreter Lock means CPU-bound work does not benefit from threads in CPython, pushing developers toward multiprocessing. Languages like Java and Go have rich threading or goroutine models that make concurrent programming within a single process more natural.
Key Differences
| Aspect | Process | Thread |
|---|---|---|
| Memory | Own isolated address space | Shared memory within process |
| Creation cost | Expensive (new address space, page tables) | Lightweight (shared address space) |
| Communication | IPC: pipes, sockets, shared memory segments | Direct shared memory access |
| Fault isolation | Strong — crash does not affect other processes | Weak — one thread crash can kill the process |
| Context switch cost | High (TLB flush, page table swap) | Low (register and stack pointer swap) |
| Synchronization | Not needed for memory (isolated) | Required (mutexes, semaphores) |
| Use cases | Web server workers, microservices | Database query handlers, UI + background work |
What Separates a 2/3 from a 3/3
2/3 — Passing but Incomplete
Candidate explains that processes have separate memory and threads share memory, mentions stacks are separate per thread, but does not clearly articulate IPC mechanisms or the trade-offs around context switching cost and fault isolation.
3/3 — Strong Answer
Candidate clearly contrasts memory isolation (process) vs shared memory (thread), explains separate stacks and registers per thread, names specific IPC mechanisms, discusses context switch cost differences, and gives concrete use-case examples for when to choose each.
Common Mistakes
- Saying threads have their own memory space — they share the heap and globals, only the stack is separate
- Forgetting to mention that threads still have separate stacks and registers
- Confusing IPC mechanisms with thread synchronization primitives
- Claiming threads are always better because they are lighter — ignoring fault isolation trade-offs
- Not mentioning that thread bugs (race conditions, deadlocks) are a direct consequence of shared memory
Follow-Up Questions
- What happens to other threads when one thread in a process crashes? — An unhandled exception or segfault in one thread typically kills the entire process and all its threads.
- How does the Linux kernel implement threads compared to processes? — Linux uses clone() for both; threads are tasks that share the same memory descriptor (mm_struct). The kernel treats them similarly.
- What is the difference between user-level threads and kernel-level threads? — User-level threads are managed by a runtime library without kernel awareness; kernel threads are scheduled by the OS.
- How does Python's GIL affect multithreading? — The GIL serializes bytecode execution, so CPU-bound threads do not run in parallel in CPython. I/O-bound threads still benefit.
- When would you use coroutines instead of threads? — Coroutines are ideal for I/O-bound concurrency with thousands of tasks — cooperative, avoid context switch overhead.
Related Questions
Can You Explain This Cold?
Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.
Get Graded — Free Assessment