Process vs Thread

"Difference between a process and a thread" is an OS interview certainty. It underpins concurrency, so panels use it to gate deeper questions on synchronization and parallelism. Know exactly what is shared and what isn't.

Definitions

A process is a program in execution with its own address space (code, data, heap, stack) and OS resources. A thread is the smallest unit of execution within a process — a lightweight "thread of control" that shares the process's address space with sibling threads.

What's shared vs private

Threads of one process share code, data (globals), heap, and open files, but each thread has its own stack, registers, and program counter (PC). Processes share nothing by default — they are isolated.

Aspect	Process	Thread
Address space	own, isolated	shared with siblings
Owns	code/data/heap/stack	own stack + registers + PC
Creation cost	high	low
Communication	IPC (pipes, sockets, shared mem)	shared memory directly
Crash impact	isolated	can crash whole process

Exam Tricks & Tips

• 🎯 Threads share code/data/heap/open-files but each has its own stack, registers, and PC — this exact split is the key exam point.
• 🎯 Processes are isolated (need IPC to communicate); threads share memory directly, which is why they need synchronization.
• 🎯 Thread creation and context switching are cheaper than for processes (no address-space switch / TLB flush).
• 🎯 A crashing thread can bring down the whole process; a crashing process doesn't affect others — isolation trade-off.
• 🎯 Multithreading exploits multiple cores within one process; multiprocessing uses separate processes (no shared state, safer).
• 🎯 Context switching between threads of the same process is faster than between processes because the memory map stays.
• ❌ Common mistake: saying threads have separate address spaces — they share the process's address space; only stack/registers/PC are per-thread.

Expected pattern

"Process vs thread", "what do threads share?", "why is thread context switch cheaper?", "multithreading vs multiprocessing", and "why do threads need synchronization?".

Quick recap

Process = isolated program in execution with its own address space; Thread = lightweight unit inside a process sharing code/data/heap/files but with its own stack/registers/PC. Threads are cheaper to create/switch and communicate via shared memory (needing synchronization); processes need IPC and are isolated.

Cover the answer, recall, then check. 12 cards on process vs thread.

Q1. What is a process?
A1. A program in execution with its own isolated address space (code, data, heap, stack) and OS resources.

Q2. What is a thread?
A2. The smallest unit of execution within a process, sharing the process's address space with sibling threads.

Q3. What do threads of the same process share?
A3. Code, data (globals), heap, and open files — the process's address space and resources.

Q4. What does each thread have privately?
A4. Its own stack, CPU registers, and program counter (PC).

Q5. Why is thread creation cheaper than process creation?
A5. No new address space is allocated; threads reuse the parent process's memory and resources.

Q6. How do processes communicate?
A6. Via Inter-Process Communication (IPC): pipes, message queues, sockets, shared memory, etc.

Q7. How do threads communicate?
A7. Directly through shared memory (shared heap/globals), which is why they require synchronization.

Q8. What happens to a process if one of its threads crashes?
A8. The crash can bring down the entire process, since they share the same address space.

Q9. Why is a thread context switch faster than a process one?
A9. The memory map (address space) doesn't change, avoiding costs like a TLB flush.

Q10. Multithreading vs multiprocessing?
A10. Multithreading uses multiple threads in one process (shared memory); multiprocessing uses separate processes (isolated, no shared state).

Q11. Why do threads need synchronization but isolated processes don't?
A11. Threads share mutable memory, risking race conditions; isolated processes have no shared mutable state by default.

Q12. Do threads have separate address spaces?
A12. No — they share the process's address space; only their stack, registers, and PC are private.

"What is the difference between a process and a thread?" is perhaps the single most-asked OS interview question. The answer hinges on one idea: what memory is shared and what is private.

Core idea: a process is a program in execution with its own isolated address space (code, heap, data, stack). A thread is a unit of execution inside a process; threads of the same process share the address space (code, heap, globals) but each has its own stack and registers.

How it works

Beginner — the containment relationship

A process is the "container"; threads are the "workers" inside it. Every process has at least one (the main) thread. Multiple threads let one process do several things at once — e.g. a browser tab rendering while another downloads.

Intermediate — what is shared vs private

Resource	Across processes	Across threads (same process)
Address space / heap	isolated	shared
Global/static data	isolated	shared
Open files, sockets	isolated	shared
Stack	separate	separate (one per thread)
Registers / program counter	separate	separate

Sharing the heap is the double-edged sword: threads communicate cheaply (just read/write shared memory) but require synchronisation (locks) to avoid races. Processes are isolated, so a crash in one cannot corrupt another — safer, but inter-process communication (IPC) is heavier.

Advanced — cost and communication

Creating a process is expensive (the OS allocates a new address space, often copying page tables via copy-on-write fork). Creating a thread is cheap (share the address space, allocate a stack). A context switch between threads of the same process is faster than between processes, because the memory map (page tables, TLB) need not be swapped.

// Threads share globals -> a race without a lock:
int counter = 0;
// thread A: counter++  |  thread B: counter++   -> may lose an update

IPC between processes uses pipes, sockets, shared memory or message queues; threads just share variables (with locks).

Worked example — why a shared counter needs a lock

Two threads each run counter++ 1,000,000 times on a shared counter starting at 0. You expect 2,000,000 but often get less. counter++ is really read → add → write; if both threads read the same old value before either writes, one increment is lost. Wrapping the increment in a mutex serialises it and restores the correct total. This "lost update" is the canonical illustration of why shared-memory threading needs synchronisation — and why isolated processes don't.

Interview & exam relevance

Guaranteed question: "process vs thread". Nail these points: separate vs shared address space; threads are lighter to create and switch; threads need synchronisation because they share memory; a process crash is isolated while a thread crash can take down the whole process. Follow-ups: "why are threads called lightweight?" and "multiprocessing vs multithreading trade-offs".

Tricks & gotchas

• All threads share the heap and globals but have private stacks — local variables are per-thread and safe; shared data is not.
• A segmentation fault in one thread typically kills the entire process (shared address space); one process crashing does not kill another.
• More threads ≠ more speed: contention on locks and context-switch overhead can make it slower (and GIL limits CPU-bound Python threads).
• Mnemonic: "Processes isolate, threads share — share means sync."

Worked Example

Problem: A program forks a child process AND, separately, spawns a thread. A global variable g = 0 is incremented in each. Explain what the parent sees in both cases and why, using the process/thread memory model.

int g = 0;
// Case 1: fork
pid_t pid = fork();
if (pid == 0) { g = 42; _exit(0); }   // child
wait(NULL);
printf("after fork: g=%d\n", g);      // (A)

// Case 2: pthread
void* worker(void* _) { g = 99; return NULL; }
pthread_t t; pthread_create(&t, NULL, worker, NULL);
pthread_join(t, NULL);
printf("after thread: g=%d\n", g);    // (B)

Solution:
A process owns a private address space; a thread is a unit of execution that shares its process's address space (code, heap, globals) but has its own stack and registers.

(A) fork() creates a new process with a copy of the parent's address space (copy-on-write). The child's g = 42 modifies the child's own copy of g. The parent's g is untouched, so after the child exits the parent still prints g=0.

(B) pthread_create makes a thread inside the SAME process. The thread shares the one global g, so g = 99 is visible to the parent thread. After join it prints g=99.

This is the core trade-off. Threads share memory → cheap communication and context switch, but you must synchronise access (race conditions). Processes are isolated → a crash or memory corruption in one does not affect another, and communication needs explicit IPC (pipes, shared memory, sockets). Creating a process is heavier (new page tables, address space); creating a thread is lighter (shared address space, only a new stack + registers).

Answer: (A) g=0 — fork copies the address space, so the child mutates its own copy. (B) g=99 — the thread shares the process's memory, so its write is visible. Processes are isolated (need IPC); threads share memory (need synchronisation).