In Go's scheduler, what does a P own, and why must an M acquire one to run Go code?

## What a P actually contains A P — the runtime's `p` structure — is a *scheduling context*. Think of it as a permit plus a toolbox. The permit half says "the holder may execute Go code"; the toolbox half is the state that makes running goroutines fast: - **A local run queue** of goroutines that are ready to run. The P holding it can push and pop without coordinating with anyone else. - **A per-P memory-allocation cache.** Go's allocator gives each P its own `mcache`, so allocating a small object usually touches only P-private storage instead of a shared, locked structure. This is a large part of why allocation-heavy Go code scales at all. - **Per-P runtime bookkeeping** — GC-related state, reusable structures, counters — all kept per P for the same reason: no lock on the hot path. A P is deliberately *not* a thread and *not* a CPU core. It is an accounting object that exists only inside the Go runtime. ## Why an M must hold one Execution is the triple M + P + G. The M is the OS thread that actually executes instructions; the G is the goroutine's stack and saved state; the P is what says this thread is currently one of the program's Go-code execution slots, and supplies the queue that decides which G runs next. The requirement buys two properties that are hard to get any other way. **1. A parallelism budget that does not depend on the thread count.** There are exactly `GOMAXPROCS` Ps. Because Go code runs only while holding one, at most `GOMAXPROCS` goroutines execute Go code at the same instant — regardless of how many Ms the runtime happens to have created. If instead the thread count *were* the budget, the runtime would have to choose between hurting parallelism and letting the budget drift. Splitting permit from worker lets the two numbers be different numbers, chosen for different reasons. **2. Ownership instead of sharing.** Whatever state the scheduler and allocator need on the hot path can be hung off the P. Since only one M holds a given P at a time, that state is single-owner and needs no locking. A design without P has to keep this state either per-thread (and then it is stranded when a thread is idle, and it grows with the thread count) or global (and then every thread contends on it). Per-P is the compromise: bounded in number, always attached to something that is actively running Go code. ## What you can observe from it The P count is the number you actually control: `runtime.GOMAXPROCS(0)` reads it, `runtime.GOMAXPROCS(n)` changes it, and the `GOMAXPROCS` environment variable sets it before the program starts. Resizing the set of Ps is a global runtime operation, not a cheap toggle, so it belongs at startup or at a deliberate configuration change — not on a request path. Setting `GOMAXPROCS` to 1 is a useful thought experiment. There is then one P, so exactly one goroutine executes Go code at a time. Your program is still *concurrent* — goroutines still interleave, still block, still resume, and the scheduler still switches between them at safe points — but it has no Go-code *parallelism*. Crucially this does not make data races impossible: two goroutines that interleave without synchronisation still race, and the race detector will still flag them. "I set GOMAXPROCS to 1 so I don't need a mutex" is wrong, and it is wrong for a reason worth stating out loud: correctness comes from synchronisation, not from how many execution slots exist. ## How to answer this in an interview Lead with what a P holds — run queue plus per-P caches — then give the one-sentence reason for the permit: it separates *how many goroutines may run Go code at once* from *how many OS threads exist*. Finish by naming the knob: the number of Ps is `GOMAXPROCS`. If you can also say that the per-P allocation cache is why small allocations avoid a global lock, you have shown that you understand P as a memory-system object as well as a scheduling one, which is the part most candidates miss.