Process vs thread
“What is the difference between a process and a thread? Go beyond "a thread is a lightweight process".”
What this tests
- Whether the candidate knows what a process owns and what threads share
- Isolation and the failure implications of sharing an address space
- Communication cost: shared memory vs IPC
- Creation and context-switch cost, and why they differ
- Runtime awareness: what "thread" means in C++, Node.js and CPython
Answers by level
Read the beginner answer first and notice what is missing.
A process is the unit of isolation: the kernel gives it its own virtual address space, its own descriptor table, credentials, signal dispositions, working directory, resource limits and a PID. A thread is the unit of execution *inside* that process. Every thread has its own stack, register set (including the program counter), scheduling state and thread-local storage — and shares everything else with its siblings: the heap, the code, global variables, the open descriptors, the signal handlers.
That sharing is the whole trade-off. Two threads communicate by writing to the same memory, which is as cheap as a store instruction but requires synchronization — a mutex, an atomic, a lock-free queue — because the CPU and the compiler give no ordering guarantees for free (see Race Conditions). Two processes cannot see each other’s memory at all; they talk through explicit kernel-mediated channels — pipes, sockets, shared-memory segments, signals — which costs system calls and copies but makes the boundary visible (IPC: Deliberate Holes in Process Isolation).
Isolation decides what happens when things go wrong. A wild pointer or an unhandled SIGSEGV in one thread kills the whole process, including the other 63 threads that were serving requests; a memory leak in one thread grows the shared heap for everyone. A crashing process takes only itself down and the kernel reclaims all its resources, which is why nginx, PostgreSQL, Chrome and gunicorn all put work in separate processes: a worker can die and be restarted individually.
Cost follows from what has to be created and switched. Creating a process (fork) copies the page tables and marks the pages copy-on-write; creating a thread allocates a stack and a kernel task and shares the page tables. Switching between two threads of the same process does not change the address space, so the TLB is not flushed; switching between processes does (or, with PCID/ASID tagging, has to re-warm it). The direct cost of a switch is on the order of a microsecond; the indirect cost — cold caches and TLB — is what you actually pay (Context Switching).
Green flags · Red flags
- Lists concretely what a thread owns (stack, registers, TLS) versus what it shares
- Says that a crash in one thread kills the whole process
- Contrasts shared-memory communication with explicit IPC and names the synchronization cost
- Explains why a same-process switch is cheaper (no address-space change, TLB kept)
- Mentions how a runtime (GIL, V8 isolates) changes what "thread" means
- "Threads are faster" with no mechanism behind it
- Believes threads have separate memory or processes share the heap
- Cannot say what a context switch between threads avoids
- Says "JavaScript is single-threaded" as if that settled the question