Goroutine Scheduler (GMP)
How goroutines actually get onto CPUs: the G-M-P model, the run queues and work stealing that feed it, preemption of goroutines that will not yield, and what happens when one blocks on a syscall or the network. Backend interviews reach for this the moment you claim goroutines are cheap.
part ofGo (Golang)overview, primer and where to startread it →on this pageshowhide
explore
- Parking and Waking Goroutines4 questions
- The G, M and P Model5 questions
- Run Queues and Work Stealing5 questions
- Runtime Timer Heaps4 questions
- Preemption and Safe Points4 questions
- Blocking Syscalls and the Netpoller4 questions
- schedtrace and Stack Dumps4 questions
- Threads, sysmon and LockOSThread5 questions
questions
page 2 of 2What is the Go runtime's sysmon thread, and why does it run without holding a P?
basics
~20 ssysmon is a monitoring thread the Go runtime starts at program start and runs for the process lifetime. It holds no P, so GOMAXPROCS does not bound it and it can still act when every P is busy: polling the network, retaking Ps and forcing a periodic collection.
Setting GODEBUG=asyncpreemptoff=1 makes a flaky failure disappear after a Go upgrade. What does that tell you?
basics
~20 sThat the failure depends on the runtime interrupting goroutines with a signal at arbitrary instructions, since asyncpreemptoff=1 leaves only function-call preemption. Treat the setting as a bisect that narrows the bug, not as a fix to ship.
What stops goroutines in Go's global run queue from starving behind the per-P local queues?
basics
~20 sOn every 61st scheduling tick a P takes one goroutine from the global run queue before looking at its own, and a P that empties its local queue drains a global batch. Without the periodic check, local work would win forever.
How does testing/synctest let a test of a one-hour backoff wait finish in milliseconds?
basics
~20 sIt runs the test in a bubble with its own fake clock. That clock moves only when every goroutine in the bubble is durably blocked, then jumps to the next timer deadline, so no real waiting happens.
Should a fleet pin GOMAXPROCS per service or rely on the container-aware default? How do you decide?
basics
~20 sDefault to the runtime-derived value fleet-wide and treat pins as documented exceptions. The default is only trustworthy if every service builds on a toolchain that reads the container CPU limit and every workload actually has such a limit; otherwise pin.
showing 31–35 of 35