0006: Sometimes You Need Locks — sync, atomic & the Race Detector

Date: 2026-06-14 Status: Accepted

Insight #

Channels are the Go way, but they're not always the right tool. When you have a simple shared counter, a sync.Mutex is clearer than a channel. When you need to wait for N goroutines to finish, sync.WaitGroup is the standard tool. When you need a lazy one-time initialization, sync.Once. And when performance matters for simple counters, atomic operations avoid lock overhead entirely.

The race detector (go test -race) is Go's superpower — it instruments the binary to detect data races at runtime. Every cloud-native project runs CI with -race. Understanding what it catches and the false positives it can produce is essential.

This lesson should be taught as "when channels aren't the answer" — it complements Lesson 0005 rather than contradicting it. The mental model: channels for coordination and data flow, sync primitives for protecting shared state.

Consequences #

• Lesson 0006: sync.Mutex, sync.RWMutex, sync.WaitGroup, sync.Once, atomic operations, and the race detector
• The concurrency cheat sheet from Lesson 0005 already covers sync primitives — this lesson adds context
• Exercises should include: benchmark mutex vs atomic, use WaitGroup for fan-in, use sync.Once for lazy init
• Must emphasize the race detector as a tool that should be run on every test invocation