Message Passing §

A channel is a typed pipe. In Go:

• Unbuffered: send blocks until a receiver is ready (synchronous handoff).
• Buffered (make(chan T, n)): send blocks only when the buffer is full.

Channel operations are the synchronization points: a send happens-before the corresponding receive. This gives you the happens-before guarantee without explicit locks (see Parallelism for the memory model).

CSP vs Actor: in CSP, a channel is a shared object that both sender and receiver reference; the send and receive are synchronous (or buffered). In the actor model, a message is sent to an actor’s address (mailbox); the sender does not block on delivery. CSP has a single communication primitive (channel); actors have a richer message-passing model (reply, supervision, forwarding).

Formal semantics: CSP is defined as an algebra of processes with four core operators:

• Prefix ($a.P$): perform action a, then behave as P.
• Choice ($P \sqcap Q$): behave as P or Q (nondeterministic).
• Parallel ($P \parallel Q$): run P and Q concurrently, synchronizing on shared actions.
• Hiding ($P \backslash H$): make actions in set H internal (unsynchronizable).

The full algebra (refinement, traces, failures-divergences) is in Hoare’s 1985 book. The practical Go channel model is a restricted instance: channels are typed, and the only operators are send, receive, and close.

Deadlock hazard: with unbuffered channels, two goroutines can each block on a send to the other’s channel, creating a circular wait. This is the classic deadlock pattern in CSP: the channel operation is the “resource,” and the circular wait arises when P1 waits for P2 to receive while P2 waits for P1 to receive. The general Coffman conditions (mutual exclusion, hold-and-wait, no preemption, circular wait) apply here. See Parallelism for the full treatment of deadlock conditions and prevention strategies.

The actor model provides fault containment: if one actor crashes, only its parent’s supervision tree is affected. This is why Erlang/OTP is used in telecom systems (99.999% availability) and why Akka is popular for microservices.

Supervision strategies:

• One-for-one: restart only the failed child.
• One-for-all: restart all siblings when one fails.
• Rest-for-one: restart the failed child and all children created after it.

The mailbox is the actor’s queue. Messages are processed sequentially, so the actor’s internal state is never concurrent. This eliminates race conditions by construction.

In practice, most message queues (Kafka, RabbitMQ, NATS) provide at-least-once delivery by default. The consumer achieves effective exactly-once by being idempotent: processing the same event twice has the same effect as processing it once. This is the standard pattern in event-sourced and stream-processing systems.

For a full treatment of delivery guarantees, ordering, and their interaction with consistency, see Consensus and Consistency.

func main() {
    ch := make(chan int, 100) // buffered channel, capacity 100
    var wg sync.WaitGroup

    // Producer
    go func() {
        for i := 0; i < 10000; i++ {
            ch <- i // blocks if buffer is full
        }
        close(ch)
    }()

    // 4 consumers
    for w := 0; w < 4; w++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            for item := range ch {
                process(item)
            }
        }()
    }
    wg.Wait()
}

Without a buffer (unbuffered channel): the producer blocks on every send until a consumer is ready. This is natural backpressure: the producer cannot outpace the consumers.

With a buffer (capacity 100): the producer can get 100 items ahead before blocking. This smooths out bursts but uses memory.

Unbounded growth is prevented by the channel’s capacity. If you need truly unbounded buffering, use a queue with a size limit and a policy (drop oldest, drop newest, block producer).

The key insight: the channel is the synchronization. No locks, no shared state. The happens-before guarantee (send hb receive) ensures the consumer sees the item in the state the producer left it.

First crash: The supervisor catches the badarg exception from Worker B. Because the strategy is one_for_one, only Worker B is restarted. Workers A and C continue running. The restart counter for Worker B increments to 1.

11th crash in 5 seconds: The restart intensity limit (10 in 5 s) is exceeded. The supervisor itself terminates (its own restart type is temporary by default, so it does not restart). The entire supervision tree shuts down: Workers A and C are also terminated. The parent of this supervisor is notified.

Key insight: The supervision tree is the fault-containment boundary. A single actor’s failure is isolated to its subtree unless the restart intensity is exceeded, in which case the failure propagates upward. This is the “let it crash” philosophy: you do not try to prevent the crash; you design the supervision tree so that the blast radius is bounded.