Start here
Threads vs processes (first principles)
Threads in one process typically share the virtual address space (heap, static data, code) and often the file descriptor table and signal dispositions. Each thread still has its own stack, register set, and kernel scheduling metadata.
That sharing makes communication cheap (pointer passing) but means one serious memory bug can kill every thread in the process. Separate processes trade isolation for IPC cost.
By the end of this page you should be able to
- Name at least four resources threads in one process usually share.
- Explain why context switches are often cheaper between threads than between processes.
- Relate `CLONE_VM` (conceptually) to “same address space.”
When threads help vs hurt
Threads help
Threads hurt
Interview anchor
mm vs per-thread stacks.Operating systems · Threads
Threads vs processes
Shared address space vs isolation
TL;DR
Threads are schedulable units sharing most process resources (VAS, open files, signal dispositions in POSIX) but have private stacks, registers, and TLS, processes isolate by default; threads cooperate in-memory with explicit synchronization.
Summary
Use threads when shared in-memory state wins over IPC cost; use processes when fault isolation or different trust domains matter. Interviews want crisp contrasts plus one failure mode (data race vs SIGKILL isolation).
Diagram
Read the diagram definition
flowchart TB
P[Process: mm + files]
T1[Thread 1 stack/regs]
T2[Thread 2 stack/regs]
P --> T1
P --> T2Deeper narrative
Threads share the hard state that is expensive to duplicate: page tables, some signal state, and (by default) file descriptors. That sharing is why parallel parsers are fast, and why one data race can corrupt the whole process.
Mechanism (step by step)
Clone flags decide sharing
`CLONE_VM` shares address space; without it you have a new process.
Scheduler sees threads
Each thread is a schedulable entity with its own kernel stack slice.
Synchronization replaces IPC
Mutexes protect shared heap instead of sending bytes across sockets.
Fault isolation
SIGSEGV in one thread tears down the entire process unless handled per-thread carefully.
Key insights
Shared heap, private stacks
File descriptor table sharing
Signal delivery model
Fork+threads
Did you know?
Common pitfalls
Default stack size × N
Thousands of threads can exhaust virtual memory, pools or fibers mitigate.
Hidden globals
errno is thread-local; other TLS must be explicit, globals bite under concurrency.
Comparison
Process vs thread (typical POSIX)
| Process | Thread | |
|---|---|---|
| Address space | Private by default | Shared with peers in process |
| Creation cost | Higher (new tables) | Lower (reuse mm) |
| IPC need | Higher for tight loops | Lower, use locks instead |
Glossary
1:1 model
M:N
TLS
Interview follow-ups
- Quantify context switch cost thread vs process on Linux.
- When would you still choose processes over threads for a worker pool?
- How does Go’s M:N model differ from 1:1 pthreads?
Callouts
Answer skeleton
“Threads share VAS and fds; processes default-private; threads cheaper communication, processes stronger crash isolation.”
Walkthrough & deep dive
Left: practical “how would I use this?” threads. Right: slower, code-leaning explanations, open one panel at a time so the page does not feel like a wall of sameness.
Walkthrough
Design
Deep dive
Green threads history
M:N user threads multiplexed on fewer kernel threads, blocking syscalls could stall many green threads; modern runtimes work around with thread pools and nonblocking I/O.
Thread count
grep -c ^processor /proc/cpuinfops -o nlwp= -p $
Self-check
1Threads in one process share…
2Processes isolate faults better than threads because…
3Concurrent unsynchronized writes to shared globals are…