What stops goroutines in Go's global run queue from starving behind the per-P local queues?

## Two ways the global run queue could starve, and two guards Go keeps runnable goroutines in three places: a one-goroutine `runnext` fast slot per P, a 256-entry local run queue per P, and one global run queue shared by every P. The scheduler *prefers* the local structures, because touching them needs no lock — and a strict preference is exactly how starvation happens. Goroutines land on the global queue when a local queue overflows (half of it, plus the new goroutine, move over in one batch), when there is no P available to take a newly readied goroutine, and when a P is retired and its queue is flushed. If a P with a permanently non-empty local queue never looked at the global one, those goroutines would wait forever. ### Guard one: the 61st tick Before consulting its own structures, the scheduler tests the P's schedule tick counter: on every 61st scheduling decision, if the global run queue is non-empty, it takes **one** goroutine from there and runs it. That is the whole guard — cheap, unconditional, and enough to bound how long a global-queue goroutine waits behind a busy local queue. Why 61? Because it needs to be a small prime: large enough that the extra global-lock acquisition is negligible (one in sixty-one scheduling decisions), and odd and prime so that the check does not resonate with any natural period in the program — a power of two would tend to line up with loop counts and batch sizes. A second, less-discussed part of the same guard: a P that empties its local queue drains a *batch* from the global queue rather than a single goroutine — about the global queue's length divided by the number of Ps, plus one, capped at half the local queue's capacity. That keeps the global lock cold while still moving a fair share. ### Guard two: the fast slot borrows the time slice The `runnext` slot is a separate starvation risk of its own shape. It holds the goroutine that this P most recently made runnable, and it is run ahead of the entire local queue. Two goroutines that hand off to each other — a channel ping-pong, a lock hand-off, a request/response pair — would each land in `runnext` as they wake the other, so the pair could run back and forth indefinitely with the local and global queues never getting a look. The runtime handles this by *not advancing the P's schedule tick* when it runs the `runnext` goroutine: that goroutine inherits the remaining time slice of the goroutine that readied it, so the whole hand-off chain counts as one slice rather than refreshing the clock on every hop. Notice the consequence, which is the sharp end of this question: because the tick does not advance, a pure `runnext` chain **never reaches its 61st tick either**. The 61-tick guard cannot break it. What breaks it is the runtime's monitor thread, which watches for a P that has been running the same time slice for about ten milliseconds and preempts it. Once that happens the P goes back through the normal scheduling path, the tick advances, and the global queue is consulted again. ## How to talk about it The clean way to present this is as a layered defence rather than a single rule: 1. A P that runs out of local work drains a share of the global queue immediately. 2. A P that never runs out is forced to take one global goroutine every 61st scheduling tick. 3. A P captured by a `runnext` hand-off chain — which does not tick — is preempted by the monitor thread after the time slice expires, dropping it back into case 2. 4. Meanwhile, idle Ps steal from the *oldest* end of a busy P's local queue, so the goroutines that have waited longest move first. ## Why it matters in practice You will not tune any of this — none of it is exposed. Its value is in reasoning about latency tails. It tells you that a runnable goroutine's worst-case wait is bounded by scheduling ticks and the ten-millisecond preemption interval rather than by application behaviour, and it tells you that "my goroutine never got scheduled" is almost never the correct diagnosis for a stall. The usual real causes are a goroutine that is blocked rather than runnable, a lock it cannot get, or a thread stuck in a long syscall or C call — not the run queues failing to be fair.