Chapter 10 Channels and select on Go: Under the Hood

10.1 Channels and the Engineering of CSP

Mon, 01 Jan 0001 00:00:00 +0000

10.1 Channels and the Engineering of CSP

A recorded talk accompanies this section: online on YouTube, Google Slides deck.

CSP gives Go a claim: processes do not share state, they coordinate solely by passing messages (1.3). This section is concerned with a different question: for an engineering language to make this claim real, what shape must “communication” take so that an ordinary programmer can reach for it and get it right. Go’s answer is the channel, a first-class primitive that is at once synchronization and communication. We begin by laying out its model at the surface of the language, its type, its send and receive syntax, the two semantics of buffered versus unbuffered, directional restriction, and nil behavior, building the intuition that the later sections will need as they descend into the runtime implementation (10.2–10.7).

10.2 hchan: The Internal Structure of a Channel

Mon, 01 Jan 0001 00:00:00 +0000

10.2 hchan: The Internal Structure of a Channel

10.1 placed channels within the language from the angle of CSP: a channel is an explicit message conduit that fuses “communication” and “synchronization” into one. This section takes it apart. At runtime a channel is a struct called hchan, and its whole secret amounts to a single lock, a ring of buffered storage, plus two wait queues. The structure is small, yet every field exists for a specific design reason. Once you understand these few pieces, the entire logic of sending, receiving, and select that follows (10.3–10.6 The Memory Model and the Move Toward Lock-Free) is just “moving data, parking and waking goroutines on top of this one picture.”

10.3 Send, Receive, and Direct Handoff

Mon, 01 Jan 0001 00:00:00 +0000

10.3 Send, Receive, and Direct Handoff

10.2 laid out the skeleton of hchan: a lock, a ring buffer buf, plus a sender queue sendq and a receiver queue recvq. This section brings the skeleton to life and answers what actually happens inside the runtime during a single ch <- v and a single v := <-ch. Once you understand this send/receive path, the two most frequently asked properties of a channel, why an unbuffered channel is a single rendezvous, and why for it a receive happens before the corresponding send completes (11.9), both come down to the same mechanism: direct send / receive.

10.4 The Semantics of Closing

Mon, 01 Jan 0001 00:00:00 +0000

10.4 The Semantics of Closing

In the previous sections, both sending and receiving were “one-to-one” rendezvous: one send pairs with one receive, and the surplus side blocks and waits. Closing is the only “one-to-many” operation on a channel. close(ch) is issued by a single Goroutine, yet in an instant it wakes every receiver currently blocked on the channel and makes every blocked sender panic on the spot. This ability to “broadcast once and wake everyone” turns closing from a seemingly minor cleanup action into the most commonly used cancellation and wind-down mechanism in Go concurrency. The done channel pattern and context cancellation (11.8) both trace their roots back here.

10.5 The Implementation of select

Mon, 01 Jan 0001 00:00:00 +0000

10.5 The Implementation of select

The previous sections covered send and receive on a single channel (10.3) in full. In practice, though, a Goroutine rarely watches just one channel: it wants to react to whichever operation becomes ready first among several sends and receives, and it also wants to avoid blocking when none of them is ready. select exists exactly for this. Its semantics look simple, yet the implementation has to solve two thorny problems at once: how to choose fairly when several branches are ready, and how to avoid deadlock when locking several channels to run a single select. These two concerns shape the entire structure of selectgo, and this section is built around them.

10.6 The Memory Model and the Lock-Free Evolution

Mon, 01 Jan 0001 00:00:00 +0000

10.6 The Memory Model and the Lock-Free Evolution

The previous sections took the channel apart down to its parts: the direct handoff in 10.3 lets the sending and receiving ends pass a value directly, bypassing the ring buffer, and select in 10.5 makes a random choice among several ready branches. These mechanisms explain how a channel “runs”. This section answers two higher-level questions: what visibility guarantee a channel offers to a concurrent program, and an engineering mystery that is often raised, why a channel is still “a lock plus a queue” to this day rather than the supposedly faster lock-free structure. The former reconnects the channel to the memory model in 11.9; the latter is a real trade-off about “how correctness and maintainability win out over peak performance”.

10.7 Engineering Practice and Cross-Language Comparison

Mon, 01 Jan 0001 00:00:00 +0000

10.7 Engineering Practice and Cross-Language Comparison

The previous sections took the internal structure of a channel, the send and receive paths, and the implementation of select all the way down. Once we understand the mechanism, a harder and more engineering-flavored question follows: when should we use a channel, and when should we not. Go’s slogan, “Do not communicate by sharing memory; instead, share memory by communicating,” is easily read as “any shared state should go through a channel,” but that is not what its author meant. This section reduces that slogan to an actionable rule of thumb, sets it against the lighter tools in the chapter on synchronization primitives (Chapter 11), and then places Go’s choice within the lineage of the CSP family, so we can understand its specific coordinates in the design space.