Operating Systems

A process has its own memory; threads live inside a process and share it.

That one difference explains the rest. Threads are cheap to create and to switch between, and can corrupt each other's data, which is why they need locks. Processes are isolated, so one crashing does not take the others down, but they have to go through the operating system to talk to each other.

What it is really testing. Whether you can derive the consequences from the one fact. If you can, every follow-up in this subject answers itself.

Saving one task's state and restoring another's - and the real cost is usually the cache it throws away, not the save itself.

Registers and the program counter get stored and swapped, which is microseconds. The expensive part is that the new task finds the CPU caches full of the old task's data, so it runs slowly until they refill. That is why spawning thousands of threads can make a program slower rather than faster.

What it is really testing. Whether you mention the cache. The register answer is the textbook one; the cache answer is the reason thread pools exist.

Two or more tasks each waiting for something the other holds - needing mutual exclusion, hold-and-wait, no preemption and circular wait, all at once.

The useful part is that breaking any one of the four prevents it. The practical lever is almost always circular wait: make every code path acquire locks in the same order and a cycle becomes impossible. Lock timeouts attack hold-and-wait and are the other common answer.

What it is really testing. Whether you can turn the four conditions into a fix. Listing them is memory; naming which one you would break is understanding.

Each process gets its own pretend address space, which the hardware maps onto real memory and disk.

It buys three things at once: isolation, because one process cannot name another's memory; simplicity, because every program can be compiled as though it owns the machine; and the ability to run programs larger than physical RAM by keeping some pages on disk.

What it is really testing. Whether you give more than one reason. Most answers mention only "more memory than you have", and isolation is the one the operating system cares most about.

Splitting memory into fixed-size pages so any virtual page can live in any physical frame, or on disk.

Fixed size is what makes it work: any page fits any frame, so there is no external fragmentation and no need to find a contiguous run. When a program touches a page that is not resident, the hardware raises a page fault and the operating system fetches it - which is slow enough to dominate the program's runtime if it happens often.

What it is really testing. Whether you can define a page fault, which is the inevitable next question, and whether you know it is not an error.

When a system spends more time moving pages between memory and disk than running the programs.

It happens when the pages actively in use exceed physical memory: every process faults, the fetch evicts a page another process needs immediately, and progress collapses. The symptom is a machine at low CPU usage that is nevertheless unusable - which is how you recognise it in practice.

What it is really testing. Whether you can describe the symptom. "Low CPU, disk at 100%, everything frozen" is the answer of somebody who has watched it happen.

A mutex is a lock owned by one thread at a time; a semaphore is a counter that admits N at a time.

Ownership is the real distinction. A mutex must be released by the thread that took it, which lets the system reason about priority and detect misuse. A semaphore has no owner and can be signalled by anyone, which makes it right for limiting concurrency - at most ten database connections - and for signalling between threads.

What it is really testing. Whether you say "ownership". A binary semaphore and a mutex look identical until you ask who is allowed to release it.

When the result depends on the order two threads happen to run in.

The classic is two threads incrementing a counter: each reads 5, each adds one, each writes 6, and one increment is lost - because read-modify-write is three steps, not one. The fix is to make it atomic, with a lock or an atomic instruction. What makes these expensive is that they are intermittent.

What it is really testing. Whether you have the lost-update example. It is the shortest way to show you understand the mechanism rather than the phrase.

A program asking the kernel to do something it is not allowed to do itself.

Reading a file, opening a socket, allocating memory - all of these cross from user mode into kernel mode, because letting a program touch the disk directly would end isolation. The crossing costs something, which is why reading a file byte by byte is so much slower than reading it in blocks.

What it is really testing. Whether you connect it to buffering. The "why is this I/O slow" question is usually what the interviewer is heading towards.

Preemptive means the operating system can take the CPU away mid-task; non-preemptive means a task runs until it yields.

Preemption is what stops one runaway loop freezing the machine, and it is what every general-purpose operating system does. Non-preemptive scheduling is simpler and avoids context-switch cost, which is why it survives in some embedded systems - and why one bad task there locks everything.

What it is really testing. Whether you can say where each is used. The trade is between fairness and overhead, and real systems pick sides for real reasons.

Concurrency is dealing with many things at once; parallelism is doing many things at once.

A single core running ten threads is concurrent and not parallel - it interleaves them. Four cores running four threads is parallel. The distinction matters because concurrency alone still helps when tasks are waiting on I/O, and helps not at all when they are CPU-bound.

What it is really testing. Whether you know when concurrency buys nothing. Adding threads to a CPU-bound task on one core is a mistake this question is checking for.

A process that has exited but whose exit status the parent has not collected yet.

The kernel keeps the entry so the parent can read how the child finished. If the parent never calls wait(), the entry stays, and a program that spawns children in a loop without reaping them will eventually exhaust the process table. An orphan is the opposite case - parent gone first - and gets adopted by init.

What it is really testing. Whether you know it is a bookkeeping entry rather than a running program. A zombie uses no CPU and no memory, which surprises people.