Appendix E. Concurrent programming

Concurrency is presented as a way to structure programs so many tasks can make progress independently, distinct from parallelism, which is about running tasks simultaneously. Go does this with goroutines—lightweight, independently scheduled functions—starting with the main goroutine and extended via the go keyword. Because goroutines don’t automatically wait for each other, synchronization is explicit: sync.WaitGroup provides a counting semaphore pattern through Add, Done, and Wait. The text highlights common pitfalls (like calling Add inside a goroutine and racing with Wait) and shows how to encapsulate safe usage with a SafeGroup wrapper that increments before launching and defers Done, while also encouraging separation of work from synchronization and caution with closures that capture changing variables.

Channels are introduced as typed conduits that coordinate goroutines and reduce the need for locks. Unbuffered channels synchronize precisely by blocking both sender and receiver until an exchange occurs, enabling clear patterns such as fan-out/fan-in accumulation while emphasizing the need to match sends and receives to avoid deadlocks and goroutine leaks. Closing a channel is strictly a signaling mechanism owned by the sender: receivers can detect closure via the comma-ok idiom or by ranging over the channel to consume all values until completion. Closing can also coordinate groups of goroutines (e.g., barrier-style release), and using channels of empty structs communicates pure signaling intent without payload overhead.

The select statement lets a goroutine wait on multiple channel operations, fairly choosing among those ready and enabling cancellation, barrier releases, and timeouts. A default case provides non-blocking probes, but using it in a loop can cause busy spinning and points to design issues. Buffered channels act like concurrent queues, decoupling sender and receiver until the buffer fills, and are used to prevent leaks (e.g., with time.After-based timeouts) and to cap concurrency via a counting-semaphore pattern implemented with a token channel. Directional channel types (send-only, receive-only) help encode intent and catch misuse at compile time. Throughout, the guidance stresses picking channels or mutexes judiciously, planning exit strategies to avoid leaks, and resisting unnecessary concurrency when a direct call is faster and simpler.

Figure E.1 The channel synchronizes goroutines by blocking them until both are ready. Here, the sender waits until the receiver takes the value from the channel.

Figure E.2 A buffered channel with a buffer capacity of two blocks the sender until a receiver is ready to receive from the channel when the channel buffer is full.

1. Write a function that sends one hundred values to an unbuffered channel. The main goroutine receives these values as they come and prints them individually.
2. Write a function that receives an unknown number of values from an unbuffered channel. The function should stop receiving after a timeout. Use: select.
3. Write a function with multiple sender goroutines sending an unknown number of values to an unbuffered channel, and a separate receiver goroutine that collects these values. Once all values are received, the receiver goroutine sends the total result to the main goroutine, which prints it. Hint: Use WaitGroup and close.
4. In the "Limiting concurrency" example, use the same buffered channel instead of SafeGroup or WaitGroup to wait for goroutines to finish. Hints: The buffer is empty when they finish. Being able to fill the buffer fully indicates that all have finished.
5. Add a SetLimit method to syncx.SafeGroup to limit concurrency. The Go method should block when the limit is reached, while not calling SetLimit imposes no restriction. Hint: SetLimit sets the new channel field to a buffered channel. Hint 2: Check if the channel field is nil before sending and receiving to lift off the limit.

FAQ

type token struct{}
sem := make(chan token, 10) // allow up to 10 concurrent tasks

for i := 0; i < N; i++ {
    sem <- token{}          // acquire
    go func(i int) {
        defer func() { <-sem }() // release
        doWork(i)
    }(i)
}
// Wait for all goroutines via a WaitGroup or SafeGroup