In a runtime where lightweight threads are multiplexed over a small pool of host operating-system threads, certain operations "pin" a lightweight thread to its host so it cannot be unmounted. What causes pinning, how would you detect it in production, and what does it do to throughput?

## The mount/unmount model In an M:N runtime, a lightweight thread does not own a host operating-system thread; it is *mounted* on one while running. At a blocking point the runtime **unmounts** it: copies its live stack frames to the heap as a continuation, releases the host to run some other ready lightweight thread, and remounts the continuation on whatever host is free when the wait completes. This is the entire economic basis of the model — a small pool of hosts, usually near the core count, serving an enormous number of mostly-waiting lightweight threads. **Pinning** is any state in which the unmount is impossible, so the lightweight thread and its host stay welded together for the duration of the wait. ## What causes pinning **Frames the runtime cannot relocate.** Continuation capture requires the runtime to understand every frame on the stack precisely enough to copy it to the heap and restore it later, possibly at a different address. Frames belonging to native/foreign code compiled outside the runtime's control do not qualify. If such a frame is on the stack when the thread blocks, the runtime has no choice but to keep the host. **Blocking inside runtime-opaque synchronisation.** If a lock's ownership or wait state is recorded against the *host* thread's identity, moving the lightweight thread to another host would corrupt that record. Runtimes solve this by reimplementing their locks to be unmount-aware, but any construct they do not own — an OS mutex reached through a native library, for example — pins. **Blocking calls that bypass the runtime's I/O layer.** Sockets are usually fine: the runtime routes them through non-blocking I/O and an event notifier. Other operations often are not — file I/O on platforms without good asynchronous file interfaces, name resolution through the platform resolver, and anything inside a native driver. These are implemented by simply blocking, which blocks the host. **Long compute without yield points.** Strictly this is *starvation*, not pinning: nothing prevents unmounting, but the thread never reaches a point where the runtime can unmount it. If the scheduler is cooperative rather than preemptive, a tight loop occupies its host indefinitely, and the operational symptom is indistinguishable from pinning. ## What it does to throughput Effective parallelism becomes *hosts minus pinned hosts*. With eight hosts and six pinned on slow native calls, the runtime is executing two lightweight threads at a time, no matter that fifty thousand are ready. Throughput plateaus and queueing latency climbs sharply and non-linearly — a service that measured fine at 60% load falls apart at 80%. The worst case is **deadlock by pinning**: every host pinned on operations that can only complete if some other lightweight thread runs. Nothing can be scheduled, and the system is stopped with idle CPUs. Many runtimes mitigate with **compensation** — detecting that hosts are stuck and temporarily starting more. That preserves liveness but converts the problem into an OS-thread explosion: if the blocking surface is broad and load is high, the host pool grows toward one thread per blocked task, and you have re-created the memory profile the lightweight model was meant to escape, with worse locality. ## How to detect it **The signature:** throughput flat, latency rising, CPU utilisation *low*. That combination rules out compute saturation and points at blocked hosts or a downstream limit. **Host-pool utilisation.** Instrument or observe how many hosts are mounted-and-blocked versus running. Saturated hosts with idle CPU is the smoking gun. **Thread dumps.** Take a dump of the *operating-system* threads (not the lightweight ones — there may be a million of those). Hosts sitting in native frames, in a platform resolver, or in a synchronous file call name the offender directly. **Runtime tracing.** Most such runtimes emit a diagnostic event when a thread blocks while pinned, with a stack trace. Turning that on in a canary and counting events by stack is the fastest route to the culprit. **Scaling experiment.** Raise the lightweight-thread count and observe throughput. If it does not move but CPU stays low, you are bounded by hosts, not by work. ## Remedies 1. **Move unavoidable blocking off the shared pool.** Run native, synchronous or otherwise unmediated calls on a dedicated, explicitly bounded pool of ordinary OS threads and let the calling lightweight thread wait on the result through a runtime-aware handoff. This isolates the damage and makes the cost visible. 2. **Prefer runtime-aware synchronisation.** Use the locks and semaphores the runtime knows how to unmount from, rather than constructs whose state is tied to host identity. 3. **Bound concurrency at the resource, not the thread pool.** Since threads no longer limit anything, put an explicit semaphore in front of the scarce native resource. 4. **Insert yield points in long compute loops** if the scheduler is cooperative. 5. **Audit the dependency surface** before adopting the model: a library that blocks natively on the hot path invalidates the design's premise, and that is a procurement decision, not a tuning knob. The general principle worth stating in an interview: the lightweight-thread model is a bargain that holds only while the runtime mediates every wait. Pinning is the bill arriving for every wait it does not mediate.