Walk through the states a thread passes through from creation to termination, and explain the difference between a thread blocked trying to acquire a lock and a thread waiting to be signalled.

## Why a state model exists at all A thread is a flow of control plus the bookkeeping a scheduler needs: a stack, a register set, and a *state*. The state answers one question — is this thread eligible to be put on a CPU right now, and if not, what event would make it eligible? Every runtime exposes some variation of the same five or six states, because those are the answers that exist. ## The states **New / created.** The thread's bookkeeping exists but no stack has begun executing. Nothing runs yet. In most runtimes this is the only state from which a start operation is legal, and starting twice is an error. **Runnable.** The thread can execute. Crucially, this usually *merges* two operating-system-level conditions: *ready* (in the scheduler's run queue, waiting for a core) and *running* (currently on a core). Runtimes merge them because the distinction flips thousands of times a second and any observation would be stale before you read it. A thread performing a blocking system call — a disk read, a socket receive — is often still reported as runnable even though the OS has descheduled it, because the runtime does not track kernel-internal states. **Blocked.** The thread attempted to enter a mutual-exclusion region and another thread holds the lock. This is *involuntary*: the thread did not ask to stop, it was stopped by contention, and it needs no signal to continue — when the owner releases the lock, one of the blocked contenders is made runnable again. **Waiting.** The thread called something that says "suspend me until told otherwise": awaiting a condition variable, joining another thread, or parking on a synchronizer. This is *voluntary* and *unbounded*. Nothing but an explicit signal, notification, target-thread termination, or an interrupt-style cancellation request will wake it. If the signal never comes, the thread waits forever — a lost-wakeup bug. **Timed waiting.** Identical to waiting except a deadline is registered, so the thread wakes on signal *or* on expiry. Sleep, timed condition-waits, and timed joins land here. Timed variants are strictly safer in production because a lost signal degrades to a delay instead of a permanent hang. **Terminated.** The entry function returned normally, or an exception escaped it. The thread's stack is gone. This state is *absorbing*: there is no restart. Reusing a "thread" therefore always means reusing a pooled worker whose entry function loops over tasks — the underlying thread never re-enters new. ## Blocked vs waiting — the interview crux They look identical from outside (both consume no CPU, both show as a stalled stack), so name the three differences: 1. **Cause.** Blocked = contention on a lock. Waiting = an explicit coordination call. 2. **Wake condition.** Blocked wakes when the lock becomes free, with no cooperation from anyone in particular. Waiting wakes only when a specific party signals, the deadline expires, or cancellation arrives. 3. **What it tells you when you see it.** A thread dump with dozens of threads blocked on one monitor identifies a serialization bottleneck: your critical section is too coarse or too slow, and throughput is capped by it. Dozens of threads waiting on a work queue is usually *healthy* — those are idle pool workers. Dozens waiting on a condition that no one signals is a lost-wakeup or a deadlock in disguise. A nuance interviewers like: a thread that *wakes* from a condition wait must re-acquire the associated lock before it can return, so it typically passes waiting → blocked → runnable. That is why a burst of notifications produces a thundering herd of blocked threads. ## Transitions worth naming ``` new --start--> runnable <--descheduled/scheduled--> (running) runnable --lock held by other--> blocked --lock released--> runnable runnable --await/join/park--> waiting --signal/target ends/cancel--> (re-acquire lock) --> runnable runnable --sleep/timed await--> timed-waiting --signal or deadline--> runnable runnable --entry fn returns or throws--> terminated [absorbing] ``` ## Why the model is only an approximation These are *runtime-level* states, not the OS scheduler's internal states, and they are sampled without stopping the world, so a dump is a slightly smeared picture. Two consequences for practice: (a) never write logic that branches on another thread's observed state — by the time you read it the state may have changed, which makes such checks inherently racy; (b) do use *repeated* samples for diagnosis, because the aggregate distribution across many threads is stable enough to be meaningful even when any single reading is not. Also note that on runtimes with lightweight/virtual threads scheduled in user space, a "blocking" operation may unmount the thread from its carrier rather than block a kernel thread; the reported state is about the logical thread, and the CPU-level cost of that stall can be radically lower. ## How to use this in practice Take several thread dumps a few seconds apart. Threads consistently *blocked* on the same lock → reduce the critical section, shard the lock, or replace it with an immutable/lock-free structure. Threads consistently *waiting* on the same external call → that dependency is your latency floor, and you should add timeouts and bulkheads. Threads consistently *runnable* while CPU is pinned → you are compute-bound and more threads will only add context switches.