Scheduling and the Happens-Before Relation

A background refresher goroutine spins through a work slice while a request handler runs on the same box. Someone writes code that caches a value in a package-level variable keyed by "the current worker" and reads it back two calls later — it works for a week, then corrupts data on a machine with more cores.

The missing mental model is how goroutines are actually run. Go multiplexes goroutines (G) onto operating-system threads (M, for machine) through a set of logical processors (P), one per schedulable context — by default as many as CPUs, bounded by GOMAXPROCS:

 G1   G2   G3   G4   G5     <- goroutines (cheap, stackful)
 |    |    |          |
 [---P0---]        [---P1---]  <- logical processors (run queues)
 |                   |
 M0                  M1         <- OS threads (do the actual running)

Each P owns a local queue; when a P's queue empties it steals from another P's queue. A goroutine that makes a blocking syscall parks its P (another thread may take over the work) and migrates back to a queue when the call returns. Since Go 1.14, the runtime can preempt even a tight loop without a function call, so a goroutine with no channel or lock operations no longer starves its P.

Three consequences follow, and they explain most "how is this racy, it works fine" confusion:

• Goroutines migrate. A goroutine can run on M0 now and M1 next instruction. There is no goroutine-local storage, no thread affinity to depend on, and no "I am the thread that wrote this" reasoning from other languages.
• No ordering between independent goroutines. The runtime owes you nothing about which of two runnable goroutines runs first, how long a wait takes, or whether a goroutine runs at all before main exits. Priority is fairness machinery, not a contract.
• Concurrency is not parallelism. Two goroutines are concurrent (structured to interleave) whether or not GOMAXPROCS > 1 runs them simultaneously; runtime.GOMAXPROCS(0) reports the current setting, runtime.NumGoroutine() the live count — useful for debugging, useless as synchronization.

If execution order is unguaranteed, what makes shared memory correct? Not timing — the answer is a set of ordering edges the memory model defines. Sleeps, yields, and clock time create none of them.

The Go memory model says a read of a variable observes the write it is ordered after; the ordering relation is called happens-before. Without an edge between two accesses to the same variable, the compiler and CPU are free to reorder, cache, and delay — and the race detector will call the pair a race. The catalog is small, and each entry maps to code you have already written:

The complement matters as much: sleeps, runtime.Gosched(), elapsed time, and "it worked in testing" establish nothing. Here is the shape people write and then cannot explain:

var ready bool // set by the goroutine, read by main — no edge

func main() {
	go func() {
		data = load()
		ready = true
	}()
	time.Sleep(50 * time.Millisecond) // hopes for ordering; provides none
	if ready {
		use(data) // may still see stale data — data race
	}
}

The sleep masks the race on a fast machine and loses on a slow one, which is precisely why flaky tests cluster around timing-based "sync." Replace hope with an edge:

func main() {
	done := make(chan struct{})
	go func() {
		data = load()
		close(done)
	}()
	<-done      // receive of the close happens-before this returns
	use(data)   // safe: data's write is ordered before the receive
}

close happens-before a receive of the zero value returns — one line, and the publication is airtight on every machine and every run. The channel details arrive in Channel Fundamentals; the point now is that correctness came from naming the edge, not from waiting longer.

Reading concurrent Go well is a repeated audit: for every shared variable, name the edge that orders its writes and reads — or admit there is none. Three examples, from most to least obvious.

Example one: package-level lazy config. Two goroutines call config(); without coordination, both may run loadConfig and one overwrite the other. With sync.Once, the edge is built in:

var (
	cfgOnce sync.Once
	cfgVal  *Config
)

func config() *Config {
	cfgOnce.Do(func() { cfgVal = loadConfig() })
	return cfgVal
}

The audit answer: Do's initialization happens-before any Do returns — including the first caller's return after the function completes — so every caller sees a fully constructed cfgVal. No lock in sight, one edge, done. That guarantee is why init-style Once beats the double-checked-locking pattern other languages need.

Example two: a counter read outside its lock. Get() locks, but a hot path caches g.n "just to skip the lock":

if g.n > limit { return ErrBusy } // read with no edge to writers

Audit: the unlocked read shares memory with every Incr. There is no edge — this is a race, and -race proves it. The fix is not a narrower lock, it is taking the lock (or reading an atomic). The shortcut had no edge to give.

Example three: a WaitGroup result write. Goroutines write results[i], and Wait returns after the last Done:

wg.Wait()
return results // every results[i] write happens-before Wait returned

Edge: Done happens-before Wait returns, transitively ordering all goroutine writes before the read. This is why the pre-sized-slice fan-out from Coordinating with sync.WaitGroup is correct without a mutex — the synchronization is real, just spelled WaitGroup instead of Lock.

The audit checklist, in order: list every variable written by more than one goroutine; for each, ask which construct orders writer and reader — channel, same mutex, WaitGroup, Once, atomic; if the answer is "sleep, timing, or nothing," it is a race. Run The Race Detector as the machine-checked version of the same audit: it flags exactly the pairs where the model's edges are missing.

Once the edge catalog is in hand, the scheduler's remaining lessons are about not over-trusting runtime behavior — plus a few operational facts worth carrying.

No fairness or progress contract. A goroutine blocked on a channel does not burn CPU; a CPU-bound goroutine shares its P with others (and gets preempted since Go 1.14, but "eventually" is the strongest word available). Writing code that requires "my goroutine ran at least once by now" is writing a race with extra steps — the fix is always the same: replace the assumed progress with an observed edge. The same reasoning bans runtime.Gosched() as control flow: it is a hint to the scheduler, not a barrier.

Blocking changes the topology. Channel operations, lock contention, and syscalls park the goroutine and free its P for someone else. This is why a program with 10,000 blocked goroutines is fine and 10,000 spinning ones is not, and why channels give concurrency rather than parallelism while blocked. It also explains why a select waiting on many goroutines scales without threads — a topic the channel phase builds on.

The knobs are few and mostly automatic. GOMAXPROCS defaults to the machine's CPU count; containers have historically required manual tuning to match CPU quotas, and recent Go releases derive the limit from the cgroup automatically — check runtime.GOMAXPROCS(0) rather than assuming. Raising it does not fix races, and lowering it to "make tests deterministic" merely narrows the interleavings your tests see — the bug is still there, wearing a lab coat.

What to say in interviews, and mean it: shared memory requires an edge; the edge comes from a construct (channel, mutex, WaitGroup, Once, atomic), never from time; goroutines migrate across threads, so thread-based intuitions (thread-locals, ordering by creation) do not transfer; and the race detector mechanically checks the same property you are reasoning about by hand. Everything in this phase — spawning, waiting, detecting, locking — is a different spelling of one sentence: make the happens-before edge visible in the code, or accept that there is none. Channels are the most expressive spelling of all, and where the next phase begins with Channel Fundamentals.