Difficulty: Beginner
What is the difference between a process and a thread? When would you use multiple threads versus multiple processes?
If you only prepare one OS question thoroughly, make it this one, because it shows up in almost every interview from service companies to Amazon and Microsoft. Let me give you an analogy first. A process is like a separate house with its own kitchen, furniture and locked front door. A thread is like a person living inside the house. Several people in the same house share the kitchen and the fridge, so cooperation is easy and cheap, but they can also get in each other's way, and if someone burns the house down, everyone inside is affected.
Technically, a process is an independent unit of execution with its own virtual address space, its own file descriptor table, and its own PCB. A thread, sometimes called a lightweight process, is a unit of CPU scheduling inside a process. All threads of a process share the code, the global data, the heap and the open files. What each thread has privately is its own program counter, register set, and stack (plus thread-local storage and its own thread ID). That last part is a favourite exam point: the stack is private, the heap is shared.
This sharing explains all the practical differences. Creating a thread is much cheaper than creating a process because the OS need not duplicate an address space or page tables. Switching between threads of the same process is cheaper because no address space switch occurs, so the TLB does not need flushing. Communication between threads is trivial: read and write shared variables. Communication between processes needs IPC such as pipes, sockets or shared memory, which is slower and more complex.
The flip side is safety. Because threads share memory, they need synchronization to avoid race conditions, and a single bad pointer write in one thread can corrupt data used by all the others. A crash of one thread (say a segmentation fault) typically kills the whole process. Processes are isolated: if one crashes, the others survive, and this is exactly why Chrome runs each tab in a separate process, trading memory for stability and security.
When should you use each? Use threads when the tasks are tightly coupled, share large data structures, and need low-overhead communication, for example a web server handling many requests with a worker pool or a GUI keeping the interface responsive while doing background work. Use processes when you need fault isolation, security boundaries, or want to use separate programs, for example a sandboxed renderer or a pre-fork web server such as classic Apache or Gunicorn workers.
Two edge cases interviewers may probe. First, in Python the Global Interpreter Lock means CPU-bound threads do not run truly in parallel, so people use multiprocessing instead. Second, on Linux both processes and threads are created via the clone() system call; threads are just tasks that share resources through flags, which shows that the kernel's view is more unified than textbooks suggest.
A good closing line is: threads improve responsiveness and resource sharing, but they trade isolation for speed, so you pay for it with synchronization complexity.
#include <pthread.h>
#include <stdio.h>
int shared = 0; /* shared by all threads */
void *work(void *arg) {
int local = *(int *)arg; /* private to this thread's stack */
shared += local; /* NOT safe in general - demo only */
printf("thread local=%d shared=%d\n", local, shared);
return NULL;
}
int main(void) {
pthread_t t1, t2;
int a = 1, b = 10;
pthread_create(&t1, NULL, work, &a);
pthread_join(t1, NULL);
pthread_create(&t2, NULL, work, &b);
pthread_join(t2, NULL);
return 0;
}The variable shared is the same memory location for both threads, while local lives on each thread's own stack. Compile with gcc -pthread.
thread, process, multithreading, shared memory