The process vs thread split, one level down
In a fresher viva on operating systems, the panel wants the short answer first and then one level of detail. State which resources belong to the process and which belong to the thread, because that split explains everything else.
| Belongs to the process, shared by its threads | Private to each thread |
|---|
| Virtual address space: code, globals, heap | Stack |
| Open file descriptors and sockets | Registers and program counter |
| Process ID, user identity, current directory | Thread ID, scheduling state, thread-local storage |
In most modern operating systems the scheduler runs threads, not processes. A single-threaded process is simply a process with one thread. On Linux the kernel schedules tasks, and a thread and a process are both tasks created by clone. They differ only in which resources the new task shares with its creator.
One example that shows the difference
A web browser is the cleanest example, because it uses both deliberately. Chrome, with site isolation, runs sites in separate renderer processes. If one page crashes or is compromised, it cannot read another site's memory or bring down the other tabs, because each process has its own address space. Inside each renderer, the browser still uses multiple threads, because those threads need to share the page's data quickly.
A short program makes the memory point checkable rather than just stated.
#include <pthread.h>
#include <stdio.h>
#include <sys/wait.h>
#include <unistd.h>
int counter = 0;
void *bump(void *arg) { (void)arg; counter++; return NULL; }
int main(void) {
pid_t pid = fork();
if (pid == 0) { counter++; return 0; }
waitpid(pid, NULL, 0);
printf("after child process: %d\n", counter);
pthread_t t;
pthread_create(&t, NULL, bump, NULL);
pthread_join(t, NULL);
printf("after thread: %d\n", counter);
return 0;
}
After fork, the child has a copy of the parent's memory. The kernel implements it as copy-on-write, so pages are physically copied only when one side writes. The child's increment never reaches the parent. The thread increments the parent's variable directly.
Context switch cost, stated correctly
Switching between two threads is still a context switch. The kernel saves one thread's registers and stack pointer and restores another's. What makes a switch within one process cheaper is that the address space does not change. The kernel does not load a new page-table root, so the translation cache, the TLB, stays useful. A switch between processes changes address spaces. Modern processors soften this by tagging TLB entries per address space, but the incoming process still starts with less of its data cached. The fuller mechanics are in what happens during a context switch.
Creation follows the same logic. A new thread needs a stack and a kernel record. A new process needs its own address space and resource tables, even with copy-on-write.
Shared memory cuts both ways
The common process vs thread mistake is presenting shared memory as a pure advantage: threads are lightweight, so use threads. Sharing is exactly what makes threads dangerous. Two threads updating the same variable without a lock is a race condition, and the result depends on timing. A stray pointer in one thread can corrupt data another thread is using. By default, a segmentation fault in any thread terminates the whole process, every thread with it.
Processes pay for isolation with cost. They cannot read each other's variables, so they talk through inter-process communication: pipes, sockets, message queues or an explicitly shared memory region. That last option brings back the locking problem across processes, as in two processes sharing memory when one dies holding the lock.
So the honest summary is a trade. Choose threads when tasks need to share a lot of data quickly and you can afford careful synchronisation. Choose processes when one task failing or being compromised must not affect the others.
Fork, counters and user-level threads
Expect fork and what the child inherits, especially open file descriptors. The child gets duplicates that refer to the same open files, so parent and child share each file's offset. Expect a race-condition question with a counter. Operating systems panels also like user-level versus kernel-level threads. Answer it in terms of who schedules them, the kernel or a runtime library, and what happens when one blocks on I/O.
Say what each thread owns and what it shares, then give the cost of sharing as well as the benefit. Threads are cheap because they share an address space, and a bug in one of them is a bug in all of them for the same reason.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).