software-engineer-blog logoSoftware Engineer Blog

Module 2 · Operating systems

Unit 5 of 49

Unit 5 · Module 2 · Operating systems

Processes vs threads

Same program, two very different kinds of "at the same time".

Unit 5 of the free 49-unit computer-science course, in operating systems. 2 topics to watch or read, 3 interview questions answered in full and a short self-check.

Watch or read

2 topics make up this unit. Take each one whichever way suits you, then answer the questions below.

Concurrency vs parallelism

Concurrency and parallelism sound like synonyms but they're two independent ideas. Concurrency is structure — one worker interleaving many tasks, great for I/O-bound work that spends its time waiting. Parallelism is execution — many cores each running a task at the same instant, the only thing that actually speeds up CPU-bound work. Here's the difference, why they're orthogonal, and how it maps to serving LLMs (async request handling vs batched GPU compute).

ReelRead

Processes vs threads

A process is its own isolated house; threads are roommates sharing memory. Learn when to use each for crash safety, performance, and avoiding deadlocks.

ReelRead

Interview questions this unit unlocks

Asked out loud, answered out loud. Read the answer, then say it in your own words.

What is the difference between a process and a thread?

A process owns its own address space; a thread is a unit of scheduling inside one. Two threads in the same process share the heap, the globals and every open file descriptor, and each keeps only its own stack and registers. That sharing is the whole trade: threads talk to each other by writing memory, which is free and unsafe, while processes have to serialise through a pipe, a socket or shared memory, which costs a copy and cannot corrupt the other side.

The consequence people miss: one thread crashing takes the whole process with it, because the corrupted memory is shared. Chrome puts tabs in processes for exactly that reason.

When would you choose multiprocessing over multithreading?

When the work is CPU-bound and the runtime will not let threads run in parallel — CPython holds a global interpreter lock, so four threads doing arithmetic take as long as one. Multiprocessing gives each worker a real core at the cost of process startup and having to pickle everything that crosses the boundary. For I/O-bound work the calculation inverts: the threads are blocked on the network anyway, so the lock is not contended and processes are pure overhead.

Say the shape of the workload before you say the mechanism. "It depends on whether we are waiting on a CPU or on a socket" is the answer they are listening for.

What actually happens on a context switch?

The kernel saves the running thread's registers and program counter, picks another runnable thread, and restores its state. The direct cost is a microsecond or two. The cost that matters is indirect: the new thread arrives to a CPU cache full of someone else's data, and a switch between processes also flushes address translations. So the visible price is not the switch, it is the cache misses for thousands of instructions afterwards.

This is why a thread pool sized far above the core count gets slower, not faster — you buy more switching and no more parallelism.

Self-check — 3 questions

Answer alone, at 2am, with no interviewer in the room.

Part of Everything You Need to Know About Computer Science.