Operating Systems Interview Questions and Answers

The Banker's algorithm grants a resource request only if the resulting state is safe, meaning some order exists in which all processes can finish.

Inputs are the maximum claim of each process, the current allocation and the available resources. To test safety, simulate: repeatedly find a process whose remaining need is no greater than the current available vector, assume it runs to completion and releases everything, add its allocation back, and repeat. If every process can eventually finish, the order is a safe sequence.

Avail = (3,3,2)
Need  = Max - Alloc
Find Need <= Avail -> run -> Avail += Alloc

If the requested allocation leaves no safe sequence, the request is denied and the process waits, even though resources are momentarily free. The costs are that processes must declare maximum needs up front, the check runs on every request, and it assumes resources are released promptly. It is mostly of theoretical interest; real systems prefer detection plus recovery.

A thread pool keeps a set of worker threads alive so tasks avoid per-request thread-creation cost. Core pieces:

• A task queue, typically bounded, holding runnable work.
• A set of workers, each looping: take a task, run it, repeat.
• A synchronisation primitive: a mutex plus condition variable, or a lock-free queue.
• Policies for core and maximum size, queue capacity, and rejection or backpressure when full.
• Lifecycle: graceful shutdown that drains the queue, plus a way to interrupt long tasks.
• Metrics: queue depth, active workers, task latency and rejection count.

submit -> [ queue ] -> worker1..workerN -> result

Sizing depends on the workload: CPU-bound pools near the core count, I/O-bound pools larger but bounded to avoid memory blow-up. Beware blocking tasks starving the pool, unbounded queues hiding overload, and thread-local state leaking between tasks. Dynamic sizing or async I/O often beats a huge fixed pool.