Fan-In / Fan-Out Inside a Pipeline — Professional Level¶

Table of Contents¶

1. Introduction
2. Prerequisites
3. Glossary
4. The Runtime's View of select
5. reflect.Select Internals
6. GMP Scheduler and Channel-Heavy Workloads
7. Cost Model
8. Memory Layout and Cache Effects
9. Latency Analysis
10. Runtime Tracing Deep Dive
11. Real-World Analogies
12. Mental Models
13. Pros & Cons
14. Use Cases
15. Code Examples
16. Coding Patterns
17. Clean Code
18. Product Use / Feature
19. Performance Tips
20. Best Practices
21. Edge Cases & Pitfalls
22. Common Mistakes
23. Common Misconceptions
24. Tricky Points
25. Test
26. Tricky Questions
27. Cheat Sheet
28. Self-Assessment Checklist
29. Summary
30. What You Can Build
31. Further Reading
32. Related Topics
33. Diagrams & Visual Aids

Introduction¶

Focus: "What does the runtime actually do when I select over four channels in a fan-in? Where do the nanoseconds go? When does the scheduler hurt my pipeline?"

Professional-level work on fan-out / fan-in means opening the runtime hood. You already know the patterns; what you need now is the mental model that lets you predict and explain microsecond-level behaviour.

This file covers:

• selectgo: the runtime function behind select, walked through step by step.
• reflect.Select: how the reflective variant differs in cost.
• GMP under load: how the scheduler handles thousands of goroutines parked on channels, and what M/P churn looks like.
• Cost model: approximate nanoseconds per channel op, per select, per goroutine wake, on modern hardware.
• Memory layout: how hchan looks in memory, cache effects, padding.
• Latency analysis: for a fan-in of 8 channels with 1ms work per item, what is the latency budget? Where does it go?
• runtime/trace: reading the trace, identifying contention, finding the sources of latency.

We will refer to specific files in the Go runtime: runtime/chan.go, runtime/select.go, reflect/value.go. The line numbers move between versions; the structures and concepts do not.

By the end of this file you should be able to:

• Read selectgo source and follow the path of a select from compilation to runtime to wakeup.
• Estimate the cost of a fan-out / fan-in topology in nanoseconds before measuring.
• Explain why one channel send is fast and ten million per second is sustainable.
• Identify when GMP scheduling, not your code, is the bottleneck.
• Use runtime/trace and runtime/metrics to verify your model.
• Design pipelines for the cost model, not against it.

We will not become Go runtime contributors; that requires more than one file. But we will gain the literacy needed to read the runtime when a hard problem demands it.

Prerequisites¶

• Required: All previous files internalised, especially senior.
• Required: Comfort reading runtime source code (Go standard library).
• Required: Experience with pprof (CPU, heap, goroutine, block, mutex profiles).
• Required: Experience with go tool trace.
• Required: Mental model of GMP (M = OS thread, P = processor / scheduler, G = goroutine). If unfamiliar, read the GMP overview first.
• Helpful: Some assembly knowledge for reading Go's runtime assembly stubs.
• Helpful: Familiarity with Linux performance tools (perf, top, strace).

Glossary¶

The Runtime's View of select¶

Compilation of a select¶

When you write:

select {
case v := <-a:
    handle(v)
case b <- x:
    done()
case <-time.After(time.Second):
    timeout()
}

The compiler does not generate three runtime calls — it generates one call to runtime.selectgo with a []scase array describing all three cases.

Each scase is:

type scase struct {
    c    *hchan         // channel
    elem unsafe.Pointer // data element
}

The compiler also generates an ordersel array (the order in which to test cases for a fair pseudo-random pick) and an order array (the order in which to lock channels to avoid deadlock).

The generated code roughly:

1. Build the scase array.
2. Build the ordersel.
3. Call selectgo.
4. Based on the returned chosen index, jump to the corresponding case body.

Inside selectgo¶

The function (simplified):

func selectgo(cas0 *scase, order0 *uint16, pc0 *uintptr, nsends, nrecvs int, block bool) (int, bool) {
    cas1 := (*[1 << 16]scase)(unsafe.Pointer(cas0))
    order1 := (*[1 << 17]uint16)(unsafe.Pointer(order0))
    ncases := nsends + nrecvs
    scases := cas1[:ncases:ncases]
    pollorder := order1[:ncases:ncases]
    lockorder := order1[ncases:][:ncases:ncases]

    // Generate permutation for pseudo-random selection
    norder := 0
    for i := range scases {
        // ...
    }

    // Sort channels by address for lock ordering
    for i := range lockorder {
        // ...
    }

    // Lock all channels
    sellock(scases, lockorder)

    // Pass 1: look for a case that can proceed immediately
    var casi int
    var cas *scase
    var caseSuccess bool
    var recvOK bool
    for _, casei := range pollorder {
        // try non-blocking send or receive
        // ...
    }

    if !block {
        // unlock, return default
        selunlock(scases, lockorder)
        return -1, false
    }

    // Pass 2: park on all channels
    gp := getg()
    nextp := &gp.waiting
    for _, casei := range lockorder {
        // build sudog, add to wait queue
        // ...
    }

    // unlock all channels and park
    gp.param = nil
    gopark(selparkcommit, nil, waitReasonSelect, traceEvGoBlockSelect, 1)
    // We are now parked. When we wake, gp.param tells us which case fired.

    // Pass 3: unpark — clean up other wait queues
    // ...
    return casi, recvOK
}

Key insights:

• Multi-channel locking is sorted by address. This prevents deadlock when two goroutines select over the same set of channels in different orders.
• Pass 1 is non-blocking. It checks every case once. If any is ready, take that one. Pseudo-random order across many calls.
• If no case is ready and block, park. The goroutine adds a sudog to every channel's wait queue and parks via gopark.
• On wake, the runtime knows which case fired. It cleans up the sudogs on other channels.

gopark and goready¶

gopark suspends the current goroutine. It releases the current P (the OS thread M is freed to run other goroutines). The goroutine is moved off the runqueue and into a parked state.

goready is the inverse: marks a parked goroutine as runnable. The runtime adds it back to a runqueue (typically the P of the goroutine that called goready).

In a fan-out scenario:

• Workers receive <-in. If in is empty, each worker calls gopark and ends up on in's recvq.
• The producer sends in <- v. chansend checks recvq, finds parked workers, and goreadys one of them.
• The G is now runnable. It is added to some P's runqueue. Eventually it runs.

This is the dance of fan-out at the runtime level. Every send wakes one receiver. Every receive may park.

Direct send (handoff)¶

If a sender finds a parked receiver on chansend, it copies the value directly to the receiver's destination memory and wakes the receiver. The channel's buffer is bypassed entirely. This is called handoff and is the fastest path:

// runtime/chan.go simplified
func chansend(c *hchan, ep unsafe.Pointer, block bool) bool {
    lock(&c.lock)
    if sg := c.recvq.dequeue(); sg != nil {
        // direct copy
        send(c, sg, ep, ...)
        unlock(&c.lock)
        return true
    }
    // ...
}

For unbuffered channels with one receiver waiting, this is the fast path: ~50-100 ns per send-receive pair.

Buffered send¶

If no receiver is waiting but the buffer has space:

if c.qcount < c.dataqsiz {
    qp := chanbuf(c, c.sendx)
    typedmemmove(c.elemtype, qp, ep)
    c.sendx++
    if c.sendx == c.dataqsiz {
        c.sendx = 0
    }
    c.qcount++
    unlock(&c.lock)
    return true
}

A memcopy into the ring buffer. Slightly slower than direct handoff: ~60-120 ns.

Blocked send¶

If buffer is full or unbuffered with no receiver:

gp := getg()
mysg := acquireSudog()
mysg.elem = ep
mysg.g = gp
mysg.c = c
gp.waiting = mysg
c.sendq.enqueue(mysg)
gopark(chanparkcommit, unsafe.Pointer(&c.lock), waitReasonChanSend, traceEvGoBlockSend, 2)
// woken later

The sender parks on the channel's sendq. Wakeup costs ~200-1000 ns due to scheduler involvement.

reflect.Select Internals¶

reflect.Select is implemented in reflect/value.go. Boiled down:

func Select(cases []SelectCase) (chosen int, recv Value, recvOK bool) {
    runcases := make([]runtimeSelect, len(cases))
    haveDefault := false
    for i, c := range cases {
        rc := &runcases[i]
        rc.dir = c.Dir
        ch := c.Chan.pointer()
        rc.ch = (*hchan)(ch)
        // ... copy direction-specific data
    }
    chosen, recvOK = rselect(runcases)
    // ... build return value
    return
}

func rselect(cases []runtimeSelect) (int, bool) // implemented in runtime

rselect is a runtime function that takes a []runtimeSelect and calls into the same selectgo mechanism. The reflect wrapper:

1. Allocates a slice of runtimeSelect (heap allocation).
2. For each case, boxes channel and value pointers.
3. Calls into the runtime.
4. Unboxes the result.

The overhead:

• Allocation per call. The runcases slice and any boxed values allocate.
• Type assertion on return. The received value's type is reconstructed.
• No compiler optimisations. Static select is sometimes optimised; reflect.Select is opaque.

Concretely: a static 4-case select takes ~150-300 ns. A reflect.Select over 4 cases takes ~2-5 µs. The difference is the allocation, reflection, and the bridge into the runtime.

For 64 cases:

• Static select: not possible (you cannot write a 64-case select); cascaded merge takes ~1-2 µs per receive.
• reflect.Select: ~10-50 µs per receive.

10-50x is the standard difference. For low-rate channels (< 1000 ops/sec), it does not matter. For high-rate (> 100 000 ops/sec), it matters.

Why reflect.Select allocates¶

The runcases slice is heap-allocated because it escapes to the runtime call. The compiler cannot prove that the runtime does not retain it. Each call allocates and the GC eventually collects.

For an extreme case, profile shows a hot path with reflect.Select:

20.41% 20.41% runtime.mallocgc
12.30% 12.30% reflect.Select
...

The malloc is the reflect-induced allocation.

Workarounds:

• Reuse the runcases slice. Not directly supported by the standard library; some libraries (e.g., cespare/xxhash) ship custom wrappers.
• Avoid reflect.Select in hot paths.

GMP Scheduler and Channel-Heavy Workloads¶

The triangle¶

• G (goroutine): the unit of work. Holds stack, PC, local state.
• M (machine / OS thread): the executor. Runs Gs.
• P (processor): the scheduling context. There are GOMAXPROCS of them.

An M needs a P to run a G. Without a P, the M is idle (or blocked in a syscall). Without a G, the P is idle (looking for work).

Scheduling decisions in fan-out¶

Fan-out: N goroutines all reading from one channel.

When the producer sends: 1. chansend wakes one receiver via goready. 2. goready places the G on the current P's runqueue. 3. The current P, after the send returns, has both the producer G and the woken G on its runqueue. It runs whichever the scheduler picks. 4. Other Ps see no new work unless work-stealing kicks in.

For a single-channel fan-out, the work tends to stay on one P. If the work is short, it stays serial-ish. If the work is long, other Ps eventually steal.

To get true parallelism on a single-channel fan-out, the work per item must be large enough to overcome the producer's bias toward one P. In practice, this happens naturally: a long-running worker holds the P, scheduler decides to run the producer on another P, and the system spreads out.

Scheduling decisions in fan-in¶

Fan-in: many channels, one merge.

The merge has N forwarder goroutines, each on the recvq of one channel. When a value arrives on channel i, goready wakes forwarder i. Forwarder i sends on the merged output. If the consumer is parked on the merged output, chansend direct-hands-off.

The wake chain is: worker (G_w) → forwarder (G_f) → consumer (G_c). Each step may park and unpark; the scheduler must run each G in turn.

In low load (sparse messages), this is fast: ~500-1000 ns end-to-end. In high load (many messages back-to-back), the scheduler keeps each G runnable; latency is dominated by scheduler overhead.

Scheduler latency¶

Wakeup latency (time from goready to G running) is dominated by:

• Whether a P is currently free.
• Whether the P that received the goready is busy with another G.
• Cache warmth (the G's stack and per-G data).

Best case: <1 µs. Typical: 1-10 µs. Worst case (all Ps busy, work-stealing required): 10-100 µs.

For pipelines with strict latency requirements, this matters.

sysmon¶

The sysmon goroutine runs continuously in the background. It:

• Preempts Gs that have been running too long (forced preemption every 10 ms in Go 1.14+).
• Wakes the netpoller for asynchronous I/O.
• Triggers GC.

In channel-heavy pipelines, sysmon's preemption is the safety net against G hogging. Older Go versions (pre-1.14) could deadlock with tight loops that never made function calls; newer versions preempt at safe points.

work-stealing¶

When a P's runqueue is empty, it tries to steal from another P. Specifically:

1. Look at the global runqueue.
2. Look at the netpoller.
3. Steal half the work from a random other P's runqueue.

For fan-out / fan-in, this means: a P that finished its current G looks for more work. The merge's forwarder goroutines are good candidates for stealing; they wake frequently, run briefly, and park again.

Work-stealing is fairness; without it, a busy P would hog work while idle Ps starve.

Cost Model¶

Approximate costs on modern x86-64 (Apple M-series or Intel late-2020s):

These are order-of-magnitude. Your hardware varies. Always benchmark.

What you can sustain¶

With these numbers:

• 10 million unbuffered sends/sec: 100 ns per op = 10M/s sustainable on one core.
• 1 million 8-case static selects/sec: 1 ms total CPU = 100% of one core.
• 100 000 reflect.Select of 32 cases/sec: 1.5 seconds total CPU = exhausts a core.
• 1 million goroutine creations/sec: 1-2 ms = uses a whole core just for spawning.

For a 1M-event/sec pipeline:

• 1M channel ops/sec is cheap (one core can handle 10M).
• Static select is cheap.
• reflect.Select is borderline; you need to use it sparingly or shard.
• Goroutine creation at this rate exhausts CPU. Use pools.

Memory Layout and Cache Effects¶

hchan layout¶

The channel struct fits in ~96 bytes on 64-bit (plus the buffer storage):

type hchan struct {
    qcount   uint           // 8 bytes
    dataqsiz uint           // 8 bytes
    buf      unsafe.Pointer // 8 bytes
    elemsize uint16         // 2 bytes
    closed   uint32         // 4 bytes
    elemtype *_type         // 8 bytes
    sendx    uint           // 8 bytes
    recvx    uint           // 8 bytes
    recvq    waitq          // 16 bytes
    sendq    waitq          // 16 bytes
    lock     mutex          // ~8 bytes
}

Fits in one cache line plus some. Channel operations touch this entire structure plus the buffer.

Cache line effects in fan-out¶

Fan-out: N goroutines on the same channel's recvq. Each send touches hchan and one G's per-G data. The contention is on hchan.lock.

For very high-rate channels (>10M ops/sec), the lock can become a bottleneck. Symptoms: scheduler shows lock contention; mutex profile points to chan.go.

Mitigations:

• Multiple channels (sharded fan-out).
• Batching (send slices instead of items).
• Lock-free queue (rare in Go).

Cache effects across goroutines¶

A goroutine's stack is allocated on demand. Initial stack is small (~2 KB). The runtime grows it as needed.

When a goroutine is parked and unparked, its stack may have been evicted from cache. Restart cost: a few microseconds of cache fill.

For high-frequency parking (channel ops in tight loops), this adds up. Mitigations:

• Reduce parking by batching.
• Reduce goroutine count via worker pools.
• Pin work to a worker that recently ran (caches are warm).

False sharing¶

If two atomic counters live in the same cache line, writes to one invalidate the other's cache. Common in fan-out with per-worker counters.

Fix: pad to 64-byte boundaries:

type paddedInt64 struct {
    _   [56]byte
    val int64
}

Or use one cache-line-padded atomic per worker, separately allocated.

Memory allocator effects¶

In a fan-out pipeline, each goroutine allocates from its own per-P allocator cache (mcache). This avoids global lock contention. But when goroutines move between Ps (via stealing or rescheduling), they hit different mcaches; cold caches mean slower allocations.

For very allocation-heavy pipelines, sync.Pool per worker reduces this churn.

Latency Analysis¶

A worked example¶

Pipeline:

producer -> fan-out 8 workers -> fan-in -> consumer

Per item, worker does 1 ms of work.

End-to-end latency (per item):

• Producer sends: ~100 ns.
• Worker wakes, processes: 1 ms (the work itself).
• Worker sends to its forwarder: ~100 ns.
• Forwarder sends to consumer: ~100 ns.
• Consumer receives: ~100 ns.

Total: 1 ms + 400 ns + scheduler latency.

Scheduler latency adds 1-10 µs typically. So latency per item ≈ 1.005 - 1.015 ms.

Where it grows¶

If you have 1000 workers (because the work is I/O-bound), the per-item latency is still about the same — each item touches the same number of scheduler events. The throughput is now 1000x higher (because of parallel I/O), but per-item latency is similar.

If the merge is reflect.Select over 1000 channels, the merge step alone adds ~50 µs per item. Now p99 latency is dominated by the merge.

If the consumer is slow and the merged channel fills, the forwarder blocks. The blocking itself is fast (one park), but the work waits. Latency at the worker's send: until the consumer catches up. This can be unbounded.

Latency in the long tail¶

p99 and p999 are usually much worse than p50 because:

• GC pauses (100-500 µs).
• Scheduler preemption.
• OS scheduler effects (Go's M is preempted by the kernel).
• Memory allocator slow path.

To bound the tail:

• GOMEMLIMIT to control GC pauses.
• Hedged requests for downstream latency.
• Smaller fan-out factors to reduce scheduler load.
• Pre-allocated buffers, sync.Pool.

p999 measurements are noisy; collect over millions of samples to be meaningful.

Runtime Tracing Deep Dive¶

runtime/trace records every scheduler event. Reading the trace reveals exactly what the pipeline is doing.

Capturing¶

import "runtime/trace"

f, _ := os.Create("trace.out")
defer f.Close()
trace.Start(f)
defer trace.Stop()

// run pipeline

go tool trace trace.out opens an interactive viewer.

What to look for¶

Goroutine timelines: Each G has a strip showing when it ran. Gaps are when it was parked.

For a fan-out / fan-in:

• Producer should run frequently, sending items.
• Each worker should run when an item is available.
• Workers should be roughly balanced (similar runtime per worker).
• Merge forwarders should run briefly after each worker output.

Imbalance: One worker much busier than others suggests skewed work or affinity issues.

Long parked intervals: A worker parked for milliseconds between items suggests starvation (producer slow) or contention (lock holding).

Sync events: Channel ops show as ticks. Concentrated ticks suggest hot channels (potential bottleneck).

A real read¶

You profile a pipeline and see:

• Producer G runs 80% of the time.
• 8 worker Gs each run 10% of the time.
• Merge forwarders run very briefly each.
• Consumer G is mostly parked.

Conclusion: the producer is the bottleneck. Workers are idle most of the time. Look for slow source.

Another read:

• Producer runs 10% of the time.
• Workers each run 80% of the time, full utilisation.
• Merge forwarders heavily active.
• Consumer mostly parked.

Conclusion: workers are saturated. Consumer is downstream bottleneck or merged channel is full. Look at channel buffer.

Sync block diagnosis¶

runtime.SetBlockProfileRate(1) records every block over 1 ns. The block profile shows:

flat  flat%   sum%        cum   cum%
20s   80%    80%         20s   80%   runtime.chansend1
3s    12%    92%         3s    12%   runtime.chanrecv1

If 80% of time is chansend1, the senders are waiting. Find which channel: enable block profile and run pprof with the source.

Mutex profile¶

runtime.SetMutexProfileFraction(1) records every contended mutex. For pipelines, this is uncommon (channels do not use mutexes externally), but shared state (e.g., a sync.Map) shows up here.

Real-World Analogies¶

selectgo as a multi-stage gate¶

Imagine a multi-stage entry gate at a venue. You can enter through any of three doors. Each door has a queue. You stand in all three lines simultaneously (placing a sudog in each queue). When any line moves, you go through that door (the case fires). The other lines move on without you.

reflect.Select as a customs declaration¶

Static select is the express lane: a few questions, fast pass-through. reflect.Select is the customs lane: every field declared, type-checked, more questions, slower. For most travellers, express is enough; for unusual goods, customs is required.

GMP scheduling as a kitchen brigade¶

Cooks (Ms) are the executors. Workstations (Ps) are the scheduling contexts. Dishes (Gs) are the units of work. A cook needs a workstation to prep a dish. When a dish goes into the oven (parked), the cook moves to another workstation (or another cook takes over). Work-stealing is one cook helping a busier station.

Cache lines as shared family devices¶

A cache line is like the family's tablet. If one person is using it (writing), the others can't access (read-write conflict). False sharing is two people each wanting their own thing on the same tablet — they keep handing it back and forth, slow.

Mental Models¶

Model 1: "Every channel operation is a state machine"¶

A chansend decides: hand off directly, place in buffer, or park. The decision tree is short. Each path has known cost. Reasoning about pipeline performance is composing these state machines.

Model 2: "The runtime is your concurrent library"¶

The runtime is not magic. It is a Go program (with assembly stubs) that you can read. When something is mysterious, open runtime/chan.go. You will find the answer.

Model 3: "GMP is about availability, not affinity"¶

The scheduler does not pin goroutines to threads. It pursues availability — keeping Ms busy with whatever Gs are runnable. Affinity is a happy side effect for cache warmth, not a design goal.

Model 4: "Cost is the sum of expected costs"¶

Pipeline throughput = 1 / (per-item cost). Per-item cost = sum of all operations per item. Each operation has a known cost. Multiply by item count to get total CPU. Compare to available CPU. Plan accordingly.

Model 5: "Latency is dominated by parking, not by computation"¶

For lightweight work, the time spent in gopark and goready exceeds the work itself. Batching, channel-free direct invocation, and goroutine pools all reduce parking.

Pros & Cons¶

Pros (of professional-level understanding)¶

• Predict performance before measuring.
• Diagnose deeply.
• Choose between patterns based on cost.
• Read runtime source confidently.
• Optimise rationally, not by guessing.

Cons¶

• Time investment is significant.
• Knowledge becomes outdated as runtime evolves.
• Diminishing returns for most everyday work.
• Easy to over-optimise.

Professional knowledge pays off in problems most engineers cannot solve.

Use Cases¶

Code Examples¶

Example 1: Benchmarking channel ops¶

package main

import (
    "fmt"
    "testing"
    "time"
)

func BenchmarkUnbufferedHandoff(b *testing.B) {
    ch := make(chan int)
    go func() {
        for i := 0; i < b.N; i++ {
            ch <- i
        }
    }()
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        <-ch
    }
}

func BenchmarkBufferedSend(b *testing.B) {
    ch := make(chan int, 1000)
    go func() {
        for i := 0; i < b.N; i++ {
            ch <- i
        }
        close(ch)
    }()
    b.ResetTimer()
    for range ch {
    }
}

func BenchmarkStaticSelect4(b *testing.B) {
    a, c, d := make(chan int), make(chan int), make(chan int)
    ch := make(chan int)
    go func() {
        for i := 0; i < b.N; i++ {
            ch <- i
        }
    }()
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        select {
        case <-ch:
        case <-a:
        case <-c:
        case <-d:
        }
    }
}

func main() {
    for _, bench := range []func(*testing.B){BenchmarkUnbufferedHandoff, BenchmarkBufferedSend, BenchmarkStaticSelect4} {
        r := testing.Benchmark(bench)
        fmt.Println(r)
    }
    _ = time.Now()
}

Run with go test -bench .. Numbers will vary; report nanoseconds per op.

Example 2: Profiling fan-in with pprof¶

package main

import (
    "context"
    "fmt"
    "net/http"
    _ "net/http/pprof"
    "sync"
    "time"
)

func main() {
    go http.ListenAndServe("localhost:6060", nil)
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()

    const N = 8
    inputs := make([]chan int, N)
    for i := range inputs {
        inputs[i] = make(chan int)
        i := i
        go func() {
            for j := 0; ; j++ {
                select {
                case inputs[i] <- j:
                case <-ctx.Done():
                    close(inputs[i])
                    return
                }
            }
        }()
    }
    cs := make([]<-chan int, N)
    for i := range inputs {
        cs[i] = inputs[i]
    }
    merged := merge(ctx, cs...)
    var wg sync.WaitGroup
    wg.Add(1)
    go func() {
        defer wg.Done()
        for range merged {
        }
    }()
    time.Sleep(10 * time.Second)
    cancel()
    wg.Wait()
    fmt.Println("done")
}

func merge(ctx context.Context, cs ...<-chan int) <-chan int {
    out := make(chan int)
    var wg sync.WaitGroup
    wg.Add(len(cs))
    for _, c := range cs {
        c := c
        go func() {
            defer wg.Done()
            for v := range c {
                select {
                case out <- v:
                case <-ctx.Done():
                    return
                }
            }
        }()
    }
    go func() {
        wg.Wait()
        close(out)
    }()
    return out
}

While this runs, go tool pprof http://localhost:6060/debug/pprof/profile?seconds=5 captures a CPU profile. The output shows time in chansend, chanrecv, runtime.selectgo, etc. — exactly where the channel cost goes.

Example 3: Hierarchical static merge¶

func hMerge[T any](ctx context.Context, cs []<-chan T) <-chan T {
    const groupSize = 8
    for len(cs) > groupSize {
        var nextLevel []<-chan T
        for i := 0; i < len(cs); i += groupSize {
            end := i + groupSize
            if end > len(cs) {
                end = len(cs)
            }
            nextLevel = append(nextLevel, merge(ctx, cs[i:end]...))
        }
        cs = nextLevel
    }
    return merge(ctx, cs...)
}

For 64 inputs: 8 merges of 8, then 1 merge of 8. Each merge is a static for v := range c (no select). Total throughput: ~10x faster than reflect.Select of 64.

Example 4: Sharded fan-out for lock contention¶

const numShards = 16

type shardedPool[I, O any] struct {
    shards []chan I
    out    chan O
}

func newShardedPool[I, O any](fn func(I) O, workers int) *shardedPool[I, O] {
    p := &shardedPool[I, O]{
        shards: make([]chan I, numShards),
        out:    make(chan O),
    }
    for i := range p.shards {
        p.shards[i] = make(chan I)
    }
    for i := 0; i < workers; i++ {
        shardIdx := i % numShards
        go func() {
            for v := range p.shards[shardIdx] {
                p.out <- fn(v)
            }
        }()
    }
    return p
}

func (p *shardedPool[I, O]) Submit(key uint64, v I) {
    p.shards[key%numShards] <- v
}

Multiple workers per shard. Workers within a shard contend for that shard's channel; workers across shards do not. For very high rates, this reduces lock contention on hchan.lock.

Example 5: Allocation-free fan-out with sync.Pool¶

var resultPool = sync.Pool{
    New: func() any { return &result{} },
}

func worker(ctx context.Context, in <-chan Item, out chan<- *result) {
    for v := range in {
        r := resultPool.Get().(*result)
        r.process(v)
        select {
        case out <- r:
        case <-ctx.Done():
            resultPool.Put(r)
            return
        }
    }
}

func consumer(ctx context.Context, in <-chan *result) {
    for r := range in {
        // use r
        r.reset()
        resultPool.Put(r)
    }
}

Each result is reused. GC pressure drops dramatically. Useful for hot pipelines processing millions of items/sec.

Example 6: Lock-free counter with cache-line padding¶

type counter struct {
    _   [56]byte
    val int64
}

var counters [16]counter

func incr(shard int) {
    atomic.AddInt64(&counters[shard].val, 1)
}

func total() int64 {
    var t int64
    for _, c := range counters {
        t += atomic.LoadInt64(&c.val)
    }
    return t
}

Each counter sits on its own cache line. No false sharing between shards. Fast for high-rate increment.

Example 7: Reading the goroutine profile¶

import (
    "runtime/pprof"
    "os"
)

func dumpGoroutines() {
    f, _ := os.Create("goroutines.prof")
    defer f.Close()
    pprof.Lookup("goroutine").WriteTo(f, 1)
}

go tool pprof goroutines.prof shows the call stacks of all goroutines. For leak diagnosis: look for goroutines with the same stack repeated thousands of times.

Example 8: Custom scheduler hints with runtime.LockOSThread¶

import "runtime"

func cpuBoundWorker(in <-chan Item, out chan<- Result) {
    runtime.LockOSThread()
    defer runtime.UnlockOSThread()
    for v := range in {
        // CPU-intensive work; benefits from staying on same OS thread for cache warmth
        out <- compute(v)
    }
}

Locks the goroutine to its current OS thread. Useful for workers that do heavy CPU work and benefit from CPU cache locality, or for FFI calls that require thread affinity. Rare in pure Go pipelines.

Example 9: Custom polling for low-latency¶

For sub-microsecond latency, channel ops are too slow. Use atomic flags:

type signal struct {
    ready atomic.Bool
    value atomic.Pointer[Item]
}

func (s *signal) Send(item *Item) {
    s.value.Store(item)
    s.ready.Store(true)
}

func (s *signal) Receive() *Item {
    for !s.ready.Load() {
        runtime.Gosched()
    }
    v := s.value.Load()
    s.value.Store(nil)
    s.ready.Store(false)
    return v
}

Spin-poll instead of park. Costs CPU; saves latency. Useful only for very specific use cases.

Example 10: Measuring select fairness¶

func TestSelectFairness(t *testing.T) {
    a := make(chan int, 1)
    b := make(chan int, 1)
    a <- 1
    b <- 1
    counts := [2]int{}
    for i := 0; i < 10000; i++ {
        a <- 1
        b <- 1
        select {
        case <-a: counts[0]++
        case <-b: counts[1]++
        }
    }
    if counts[0] < 4500 || counts[0] > 5500 {
        t.Fatalf("expected ~5000, got %d", counts[0])
    }
}

Over 10 000 iterations, both cases should fire roughly equally. The pseudo-random pick is fair on average.

Coding Patterns¶

Pattern 1: Profile-driven optimisation¶

Step 1: Write the obvious code. Step 2: Benchmark. Step 3: Profile if too slow. Step 4: Optimise the hot spot identified by the profile. Step 5: Benchmark again. Repeat.

No optimisation without measurement. Professional engineers always benchmark.

Pattern 2: Static select cascade¶

For high-fan-in pipelines, replace reflect.Select with cascaded static merges. The pattern is the hMerge function above.

Pattern 3: Pre-allocation¶

For high-throughput pipelines, allocate once at startup and reuse:

var buf = make([]byte, 4096)

Or use sync.Pool for variable-size buffers.

Pattern 4: Atomic over mutex for counters¶

For hot counters, atomic ops are 10-100x faster than mutex acquire-release:

atomic.AddInt64(&count, 1)

is much faster than:

mu.Lock()
count++
mu.Unlock()

Pattern 5: Batching for throughput¶

Send batches instead of individual items:

type batch struct {
    items []Item
}

Channel overhead is amortised across the batch.

Pattern 6: Goroutine pool over goroutine-per-request¶

Spawning goroutines costs 500-2000 ns. For very high request rates, pre-spawned workers are faster.

Pattern 7: Tight inner loops¶

For hot inner loops, manually unroll, avoid interface calls, use generics over any.

Clean Code¶

• Document the cost model. Comment on hot paths: "this loop runs at 1M iterations/sec; each iteration is X ns."
• Use generics for type-safe hot paths. Avoid interface{} in performance-critical code.
• Inline tiny functions. Go's compiler inlines small functions automatically. Help it by keeping them simple.
• Avoid defer in hot loops. defer has overhead. In tight loops, manage cleanup explicitly.
• Use //go:linkname cautiously. Rare but useful for runtime tricks.

Product Use / Feature¶

Performance Tips¶

Tip 1: Choose static select over reflect.Select¶

Always, unless dynamism is required.

Tip 2: Bound fan-out at the bottleneck¶

More workers past the bottleneck wastes scheduler cycles.

Tip 3: Profile before optimising¶

Most "performance bugs" are not where you guess.

Tip 4: Use pprof's flame graph¶

Visualise the call stack. Tall narrow functions are usual; tall wide functions are hot.

Tip 5: Watch for GC pauses¶

GODEBUG=gctrace=1 prints GC info. Long pauses indicate heap pressure.

Tip 6: Use GOMEMLIMIT (Go 1.19+)¶

Caps GC's target heap. Prevents pathological behaviour.

Tip 7: Tune GOGC¶

Default 100. Lower for less heap; higher for less CPU spent on GC.

Tip 8: Use runtime.GC() sparingly¶

Only for benchmarks or known cleanup points.

Tip 9: Watch for goroutine creation overhead¶

500-2000 ns per goroutine. Pool aggressively.

Tip 10: Use -race in CI only¶

Race detector slows down 5-10x. Not for production builds.

Best Practices¶

1. Benchmark every hot pipeline.
2. Profile before any optimisation.
3. Use static select unless reflect.Select is required.
4. Pre-allocate per-worker buffers.
5. Bound goroutine count.
6. Atomic over mutex for hot counters.
7. Pad atomic counters to avoid false sharing.
8. sync.Pool for short-lived objects.
9. runtime/trace for latency investigation.
10. Document cost on hot paths.

Edge Cases & Pitfalls¶

reflect.Select allocation in hot path¶

Repeated allocation triggers GC pressure. Profile shows mallocgc. Fix: switch to static merge or reduce call frequency.

Goroutine starvation under high contention¶

If one G monopolises a P (tight loop, no preemption point), other Gs starve. Sysmon eventually preempts, but the window can be 10 ms. Add runtime.Gosched() or a function call to break the loop.

Buffer wraparound¶

A channel's ring buffer wraps around (sendx, recvx). If you over-buffer, the wraparound logic is more code per op. Keep buffers small.

Scheduler preemption mid-send¶

In Go 1.14+, sysmon can preempt during a channel send. The send is atomic at the runtime level, but the surrounding code can be preempted. Don't assume "between operations" is atomic.

Stack growth in goroutines¶

A goroutine's stack starts at 2 KB and grows up. Stack growth involves copying the entire stack to a larger buffer. For hot, deep call chains, the first invocation pays the cost. Subsequent invocations are cheap (stack stays grown).

For very stack-heavy pipelines, you can see stack-growth costs in profiles.

unsafe.Pointer and channel internals¶

Some libraries reach into the runtime to read channel internals (e.g., cap(ch) and len(ch)). These are safe but undocumented. Do not depend on them in critical paths; the runtime may change.

Memory model corner cases¶

select does not introduce a happens-before edge between cases. Two channels touched in the same select have no relative ordering guarantee. Use additional synchronisation if you need it.

Common Mistakes¶

Common Misconceptions¶

"All channel ops are 100 ns." — Roughly true for handoff; parked sends are slower.

"select is fair." — Pseudo-random per call, fair across many calls.

"GMP guarantees parallelism." — Only up to GOMAXPROCS. After that, time-share.

"reflect.Select is just a slower static select." — Mostly true, but the allocation pattern is also different (heap allocs vs stack).

"runtime.Gosched() does nothing in modern Go." — Almost true. Useful only in very specific tight loops without function calls.

"sync.Pool always speeds things up." — Only if you have allocation pressure. For light workloads, no benefit.

"GC is fast." — Garbage collection is fast in steady state. Compaction and concurrent marking still cause µs-level pauses.

Tricky Points¶

chan T size depends on T¶

A make(chan T, n) allocates unsafe.Sizeof(T) * n bytes for the buffer. Large T means large channels.

Send-on-closed panics, receive-from-closed returns zero¶

Asymmetric. Pretty fundamental for shutdown protocols.

nil channel ops block forever¶

A select case with a nil channel never fires. Useful trick for disabling cases dynamically (the reflect.Select "disable case" pattern).

chansend1 vs chansend¶

The runtime has multiple internal entry points. chansend1 is for ch <- v; chansend is the worker function. Profiles show both.

selectgo returns multiple values¶

(chosen int, recvOK bool). The caller jumps based on chosen. recvOK is meaningful only for recv cases.

Stack copying¶

Goroutine stacks grow by copying. The runtime adjusts pointers in the stack to the new location. This is mostly transparent, but for very tight performance work, stack-growth pauses can show up.

lock in hchan¶

hchan.lock is a runtime spinlock, not a mutex. Acquire is fast; contended acquire is also fast (in cycles, not ns). But heavy contention pegs a core.

Test¶

package fanin_test

import (
    "context"
    "testing"

    "go.uber.org/goleak"
)

func BenchmarkMergeReflect(b *testing.B) {
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()
    const N = 16
    cs := makeChans(N, b.N)
    out := reflectMerge(ctx, cs...)
    b.ResetTimer()
    for range out {
    }
}

func BenchmarkMergeStatic(b *testing.B) {
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()
    const N = 16
    cs := makeChans(N, b.N)
    out := merge(ctx, cs...)
    b.ResetTimer()
    for range out {
    }
}

func BenchmarkMergeHierarchical(b *testing.B) {
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()
    const N = 64
    cs := makeChans(N, b.N)
    out := hMerge(ctx, cs)
    b.ResetTimer()
    for range out {
    }
}

func TestNoLeak(t *testing.T) {
    defer goleak.VerifyNone(t)
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()
    cs := makeChans(8, 100)
    out := merge(ctx, cs...)
    for range out {
    }
}

Compare BenchmarkMergeReflect, BenchmarkMergeStatic, and BenchmarkMergeHierarchical. Hierarchical should be fastest for N=64.

Tricky Questions¶

Q. What is the cost of select { case <-ctx.Done(): } in a tight loop?

A. The select case includes a check on the Done channel. The cost is one channel non-blocking check (~10-20 ns). Cheaper than a function call to check ctx.Err(). In a tight loop, ctx.Done() check costs negligible compared to actual work.

Q. Why does reflect.Select allocate?

A. It must build a []runtimeSelect slice, which the runtime treats as opaque. The compiler cannot prove the slice does not escape, so it heap-allocates. Each call to reflect.Select allocates fresh.

Q. A pipeline with 32 channels merges via reflect.Select at 100k items/sec. Profile shows 40% CPU in reflect.Select. Optimisation strategy?

A. Replace with hierarchical static merge: 4 merges of 8 then 1 merge of 4. Static select cost drops 10-20x. Expected: total CPU on merge drops from 40% to ~4%. Verify with profile.

Q. How does GMP handle 10 000 parked goroutines on the same channel's recvq?

A. They are linked-listed in the channel's recvq, sorted by queue order (FIFO). Each is a sudog (~80 bytes). 10 000 sudogs is ~800 KB plus the parked Gs themselves (~20 MB total stack). Each receive operation dequeues one sudog, marks one G runnable. Scheduler distributes runnable Gs to Ps.

Q. What is the cost of goready?

A. ~200-500 ns. It acquires the G's lock, updates its state to runnable, places it on the current P's runqueue. The G is not running yet — it is just queued. Actually running happens when a P picks it up.

Q. Does runtime.GOMAXPROCS(N) change at runtime?

A. Yes. runtime.GOMAXPROCS(N) sets the number of Ps. Increasing creates Ps; decreasing parks them. The change takes effect immediately. Useful for tuning at runtime based on observed load.

Q. What is the difference between gopark and gosched?

A. gopark parks the current G in a waiting state; it can only be resumed by goready from elsewhere. gosched yields the current G — moves it from running to runnable, places back on runqueue. gopark is sleep; gosched is voluntary yield.

Q. Can a goroutine see another goroutine's stack?

A. Only via unsafe pointers. The runtime keeps each G's stack in private memory. Sharing pointers is your responsibility; the runtime does not check.

Q. How does the netpoller interact with channel-heavy code?

A. Netpoller handles network I/O independently. When network I/O completes, the netpoller wakes the waiting G via goready. The waking G might be part of a fan-in (e.g., an HTTP fetcher). Channel ops and netpoller ops are independent paths in the runtime.

Q. What's the cost of defer wg.Done() in a hot worker loop?

A. defer allocates a defer record (~100 ns) and runs at function exit. For a long-running loop, the cost is per-iteration zero (the defer is per-function, not per-iteration). For very short functions called millions of times, the per-call defer overhead matters.

Cheat Sheet¶

// Static select cost: ~150-450 ns for 2-8 cases
// reflect.Select cost: ~2-50 µs for 4-32 cases
// Channel send (handoff): ~60-100 ns
// Channel send (parked): ~200-1000 ns
// goready: ~200-500 ns
// gopark: ~200-500 ns
// Mutex: ~10-20 ns uncontended

// hierarchical merge for many inputs
func hMerge[T any](ctx context.Context, cs []<-chan T) <-chan T {
    const g = 8
    for len(cs) > g {
        var next []<-chan T
        for i := 0; i < len(cs); i += g {
            end := i + g
            if end > len(cs) { end = len(cs) }
            next = append(next, merge(ctx, cs[i:end]...))
        }
        cs = next
    }
    return merge(ctx, cs...)
}

// padded counter to avoid false sharing
type padded struct {
    _   [56]byte
    val int64
}

// sync.Pool for hot allocations
var p = sync.Pool{New: func() any { return &Item{} }}

// runtime profile
import _ "net/http/pprof"
go http.ListenAndServe(":6060", nil)

Self-Assessment Checklist¶

• I can describe what selectgo does step by step.
• I know why reflect.Select is slower than static select.
• I understand gopark and goready.
• I can interpret pprof's block, mutex, goroutine, and CPU profiles.
• I can use go tool trace to find scheduling issues.
• I know rough nanosecond costs for the channel ops I use.
• I can predict fan-out / fan-in throughput from a cost model.
• I know when to choose static merge cascade over reflect.Select.
• I have used sync.Pool to reduce allocation in a real pipeline.
• I can read runtime/chan.go and runtime/select.go and understand the flow.

Summary¶

Professional-level fan-out / fan-in is about understanding the runtime cost model. You know what selectgo does, where reflect.Select costs you, and how the GMP scheduler routes goroutines through channel ops. You can predict throughput before measuring, diagnose latency by reading traces, and choose patterns from a cost-aware menu.

The runtime's behaviour is a finite set of state machines: chansend, chanrecv, selectgo, gopark, goready. Each has a cost in nanoseconds. A pipeline's performance is the sum of these costs times their frequencies.

reflect.Select is the dynamic but expensive variant. Static merges, possibly cascaded for high fan-in, are the high-throughput choice. Cache effects (false sharing, stack growth) and GC interaction shape the long-tail latency.

Tools: pprof for CPU, block, mutex, heap, goroutine profiles. go tool trace for scheduler-level visibility. testing.B for microbenchmarks. runtime/metrics for runtime telemetry.

With these tools and this model, you can design pipelines that run at the limits of the hardware, diagnose problems that elude lesser engineers, and contribute confidently to performance-critical Go codebases.

What You Can Build¶

• A sub-millisecond latency message broker.
• A multi-million events/sec ingest pipeline.
• A high-frequency trading order matcher.
• A real-time analytics service competitive with native code.
• A diagnostic tool that reads other services' runtime profiles.
• A contribution to the Go runtime or standard library.

Further Reading¶

• Go runtime source: src/runtime/chan.go, src/runtime/select.go, src/runtime/proc.go
• Dmitry Vyukov's runtime presentations
• Go internals talks at GopherCon
• Concurrency in Go runtime appendix
• Russ Cox blog: https://research.swtch.com/
• The Go Memory Model — https://go.dev/ref/mem
• runtime/metrics — https://pkg.go.dev/runtime/metrics

Related Topics¶

• GMP scheduler architecture
• Network poller and async I/O
• Garbage collector internals
• Memory allocator (TCMalloc-derived)
• Stack growth and goroutine stacks
• Lock-free data structures

Diagrams & Visual Aids¶

selectgo flow¶

            +--------------+
            | enter        |
            +------+-------+
                   |
                   v
            +--------------+
            | lock all     |
            | channels     |
            +------+-------+
                   |
                   v
            +--------------+
            | pass 1: any  |
            | case ready?  |
            +------+-------+
                   |
              yes  |  no
            +-----+----+
            |          |
            v          v
        +-------+  +--------+
        | run   |  | park   |
        | case  |  | on all |
        +---+---+  +---+----+
            |          |
            +----+-----+
                 |
                 v
            +--------+
            | exit   |
            +--------+

Channel send state machine¶

ch <- v:
    if recvq not empty:
        direct handoff to waiting receiver  (~60-100 ns)
    elif buf not full:
        copy to buffer                       (~70-120 ns)
    elif !block:
        return false                         (~10 ns)
    else:
        park on sendq                        (~200-1000 ns)

GMP under fan-out¶

P0 -- M0 -- G_producer
P1 -- M1 -- G_worker_1
P2 -- M2 -- G_worker_2
P3 -- M3 -- G_worker_3

Other Gs parked:
   G_worker_4, G_worker_5, G_worker_6, G_worker_7 (on recvq of input chan)
   G_merge_1, ..., G_merge_8 (on recvq of per-worker chans)
   G_consumer (on recvq of merged chan)

When producer sends, one worker wakes; when worker outputs, one forwarder wakes; when forwarder forwards, consumer wakes. Each wake = 200-500 ns.

Cost stack-up for 1M items/sec at 8 workers¶

producer sends:  1M * 100 ns = 100 ms / sec    (10% of one core)
worker work:     1M * 1 ms = 1000 sec total    (saturates 1000 worker-cores)
worker sends:    1M * 100 ns = 100 ms / sec    (10% of one core)
merge sends:     1M * 100 ns = 100 ms / sec    (10% of one core)
consumer recv:   1M * 100 ns = 100 ms / sec    (10% of one core)

Total non-work CPU: 400 ms / sec = 40% of one core
Work CPU: 1000 worker-cores = at 8 cores, item rate ~ 8K/sec, not 1M

Conclusion: at 8 cores with 1 ms work per item, max throughput ~8K items/sec.
For 1M items/sec, need work ~1 µs per item (rare).

Static merge vs reflect.Select cost¶

Static 8-case select:  ~250-450 ns per receive
reflect.Select 8:      ~2-5 µs per receive  (10-20x slower)
reflect.Select 64:     ~5-50 µs per receive (50-100x slower than equivalent static)

Hierarchical static merge for 64 inputs:
  ~250-450 ns per receive (same as 8-case)
  + linear pass-through overhead

Conclusion: cascaded static is ~50-100x faster than reflect.Select for high N.

Tracing a single item through the pipeline¶

Deep Dive: runtime/chan.go Walkthrough¶

Let us walk chansend and chanrecv in the Go runtime. The code is in src/runtime/chan.go. Versions evolve, but the structure is stable.

chansend step by step¶

func chansend(c *hchan, ep unsafe.Pointer, block bool, callerpc uintptr) bool {
    if c == nil {
        if !block {
            return false
        }
        gopark(nil, nil, waitReasonChanSendNilChan, traceEvGoStop, 2)
        throw("unreachable")
    }
    ...
}

Step 1: nil channel handling. A send on a nil channel is "block forever." This is by design and is the basis of the "disable case" pattern.

    if !block && c.closed == 0 && full(c) {
        return false
    }

Step 2: non-blocking send to a full or closed channel. Return false (the default case in select).

    lock(&c.lock)
    if c.closed != 0 {
        unlock(&c.lock)
        panic(plainError("send on closed channel"))
    }

Step 3: acquire the channel's lock. If closed, panic.

    if sg := c.recvq.dequeue(); sg != nil {
        send(c, sg, ep, func() { unlock(&c.lock) }, 3)
        return true
    }

Step 4: a receiver is parked. Direct handoff. send does the value copy and wakes the receiver. The lock is released inside send (via the closure).

    if c.qcount < c.dataqsiz {
        qp := chanbuf(c, c.sendx)
        ...
        typedmemmove(c.elemtype, qp, ep)
        c.sendx++
        if c.sendx == c.dataqsiz {
            c.sendx = 0
        }
        c.qcount++
        unlock(&c.lock)
        return true
    }

Step 5: buffered channel with space. Copy value into the ring buffer. Update sendx and qcount. Release lock.

    if !block {
        unlock(&c.lock)
        return false
    }

Step 6: non-blocking and no room. Return false.

    gp := getg()
    mysg := acquireSudog()
    mysg.releasetime = 0
    if t0 != 0 {
        mysg.releasetime = -1
    }
    mysg.elem = ep
    mysg.waitlink = nil
    mysg.g = gp
    mysg.isSelect = false
    mysg.c = c
    gp.waiting = mysg
    gp.param = nil
    c.sendq.enqueue(mysg)
    gopark(chanparkcommit, unsafe.Pointer(&c.lock), waitReasonChanSend, traceEvGoBlockSend, 2)

Step 7: park. Acquire a sudog from the pool. Link it into the channel's sendq. Park the goroutine. The gopark releases the channel lock atomically with the park (via chanparkcommit).

When the goroutine wakes (because a receiver dequeued it):

    KeepAlive(ep)
    ...
    closed := !mysg.success
    gp.param = nil
    if mysg.releasetime > 0 {
        blockevent(mysg.releasetime-t0, 2)
    }
    mysg.c = nil
    releaseSudog(mysg)
    if closed {
        panic(plainError("send on closed channel"))
    }
    return true

Step 8: wake-up handling. Check success flag. Release the sudog. Return.

chanrecv mirror¶

chanrecv is structurally identical:

1. Nil channel: block forever.
2. Non-blocking and empty closed: return zero, false.
3. Lock.
4. Sender parked: direct handoff (sender's value to receiver's slot).
5. Buffer has data: dequeue from buffer.
6. Closed channel with empty buffer: unlock and return zero with ok = false.
7. Non-blocking: return zero, false.
8. Park on recvq.

The symmetry is intentional. Both send and receive are state machines with the same overall structure.

close¶

func closechan(c *hchan) {
    if c == nil {
        panic(plainError("close of nil channel"))
    }
    lock(&c.lock)
    if c.closed != 0 {
        unlock(&c.lock)
        panic(plainError("close of closed channel"))
    }
    c.closed = 1

    var glist gList
    // release all receivers
    for {
        sg := c.recvq.dequeue()
        if sg == nil {
            break
        }
        if sg.elem != nil {
            typedmemclr(c.elemtype, sg.elem)
            sg.elem = nil
        }
        if sg.releasetime != 0 {
            sg.releasetime = cputicks()
        }
        gp := sg.g
        gp.param = unsafe.Pointer(sg)
        sg.success = false
        glist.push(gp)
    }
    // release all senders (will panic)
    for {
        sg := c.sendq.dequeue()
        if sg == nil {
            break
        }
        sg.elem = nil
        if sg.releasetime != 0 {
            sg.releasetime = cputicks()
        }
        gp := sg.g
        gp.param = unsafe.Pointer(sg)
        sg.success = false
        glist.push(gp)
    }
    unlock(&c.lock)
    for !glist.empty() {
        gp := glist.pop()
        gp.schedlink = 0
        goready(gp, 3)
    }
}

Close is broadcast: wake every receiver and every sender. Receivers get the zero value with ok = false; senders panic with "send on closed channel."

Cost: O(N) where N is the number of waiters. For a channel with many parked senders, closing is expensive. Rarely a practical concern.

Deep Dive: runtime/select.go Walkthrough¶

selectgo is more involved. Walk through.

Setup¶

func selectgo(cas0 *scase, order0 *uint16, pc0 *uintptr, nsends, nrecvs int, block bool) (int, bool) {
    cas1 := (*[1 << 16]scase)(unsafe.Pointer(cas0))
    order1 := (*[1 << 17]uint16)(unsafe.Pointer(order0))
    ncases := nsends + nrecvs
    scases := cas1[:ncases:ncases]
    pollorder := order1[:ncases:ncases]
    lockorder := order1[ncases:][:ncases:ncases]

The compiler generated cas0 and order0 on the stack. selectgo reinterprets them as slices.

Polling order¶

    norder := 0
    for i := range scases {
        cas := &scases[i]
        if cas.c == nil {
            cas.elem = nil
            continue
        }
        j := fastrandn(uint32(norder + 1))
        pollorder[norder] = pollorder[j]
        pollorder[j] = uint16(i)
        norder++
    }
    pollorder = pollorder[:norder]

Fisher-Yates shuffle to randomise the order. This is what makes select fair (pseudo-random per call).

Lock order¶

    for i := range lockorder {
        lockorder[i] = pollorder[i] // initial: copy poll order
    }
    // sort by channel address
    for i := 1; i < norder; i++ {
        j := i
        for ; j > 0; j-- {
            ...
        }
    }

Sort channels by address. This canonical order prevents deadlock when two goroutines select over the same channels.

Acquire all locks¶

    sellock(scases, lockorder)

Acquire each channel's lock in address order. With sorted order, no two goroutines lock in opposite orders, so no deadlock.

Pass 1: any case ready?¶

    var casi int
    var cas *scase
    ...
    for _, casei := range pollorder {
        casi = int(casei)
        cas = &scases[casi]
        c := cas.c

        if casi >= nsends {
            // receive case
            sg = c.sendq.dequeue()
            if sg != nil {
                goto recv
            }
            if c.qcount > 0 {
                goto bufrecv
            }
            if c.closed != 0 {
                goto rclose
            }
        } else {
            // send case
            if c.closed != 0 {
                goto sclose
            }
            sg = c.recvq.dequeue()
            if sg != nil {
                goto send
            }
            if c.qcount < c.dataqsiz {
                goto bufsend
            }
        }
    }