Chapter 11 Synchronization Primitives and Patterns on Go: Under the Hood

11.1 Shared-Memory Synchronization Patterns

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

11.1 Shared-Memory Synchronization Patterns

The fact that programs can be constructed from simpler basic primitives is a strong guarantee: what these primitives contain stays logically consistent with the rest of the programming language. – C. A. R. Hoare

The whole difficulty of concurrent programming can be distilled into a single sentence: multiple units of execution must cooperate over the same shared state, and the order in which each of them makes progress cannot be predicted. How to make that cooperation both correct and efficient has, over more than half a century, split into two great traditions. This chapter is about one of them, shared memory. Before we take apart the concrete primitives in Go’s standard library sync and sync/atomic, this section first lays the two traditions side by side to tell them apart, explains why they are dual to each other, and then states where Go stands between them. Once you understand this layer of trade-offs, the sections from 11.2 through 11.9 are no longer isolated APIs but the same design philosophy landing on different scenarios.

11.2 Mutex

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

11.2 Mutex

sync.Mutex is the most basic synchronization primitive: it lets only one goroutine enter the critical section at a time. Beneath that plain interface, it keeps weighing two goals that pull against each other, throughput (hand the lock to someone as quickly as possible, do not let the CPU sit idle) and fairness (do not let some unlucky waiter wait in line forever). The two cannot both be maxed out: handing the lock off in strict arrival order is the fairest, but pays a context switch on every handoff; letting a just-woken waiter compete freely with whoever is running is the fastest, but can leave some waiter losing out again and again. This section first lays out the theory and the hardware foundations of the old problem of mutual exclusion, then looks at how Go’s mutex walks this tightrope.

11.3 Atomic Operations

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

11.3 Atomic Operations

sync/atomic is the layer of Go’s synchronization primitives that sits closest to the hardware. Higher-level tools such as the mutex (11.1) and channels (8) are all built on top of atomic operations internally. It provides “indivisible” reads, writes, and read-modify-writes: an atomic operation either happens in full or not at all, and no other goroutine ever sees it half-finished. But the meaning of atomic operations goes far beyond “no tearing.” It is the foundation of lock-free programming, and behind lock-free programming lies a profound theory about “which primitives can do what.” That theory is what this section really wants to make clear.

11.4 Condition Variables

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

11.4 Condition Variables

The mutex (11.2) answers the question of “who may enter the critical section.” A condition variable answers a different one: “a Goroutine has already entered the critical section, but finds it cannot do its work yet; how does it wait until the moment it can, while yielding the critical section to others.” The producer and consumer is the most common example. When the queue is full, the producer can neither write nor keep spinning while holding the lock, otherwise the consumer can never acquire the lock to free up space, and both sides deadlock together. The condition variable sync.Cond offers this way out: let the producer “sleep with the lock,” atomically hand off the lock and block, and once the consumer frees up space, wake it back up, with the lock back in its hands on waking.

11.5 Wait Groups

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

11.5 Wait Groups

The mutex (11.2) and the condition variable (11.4) from the previous sections solve the problem of “multiple Goroutines contending for the same shared state.” This section turns to sync.WaitGroup, which solves a different class of problem: one Goroutine spawns several subtasks, then waits for all of them to finish before continuing. The former is contention, the latter is rendezvous. This is one of the most common structures in concurrent programming, called fork-join, and WaitGroup is exactly the Go standard library’s answer to it.

11.6 Object Pool

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

11.6 Object Pool

Allocating and then discarding the same kind of temporary object over and over puts heavy pressure on the garbage collector (13). sync.Pool offers a way out: stash a used object and reuse it next time instead of allocating fresh every time. Its typical use is for temporary objects like buffers and serializers that are “discarded after one use, yet needed again and again”.

1
2
3
4
5
6


var bufPool = sync.Pool{New: func() any { return new(bytes.Buffer) }}

b := bufPool.Get().(*bytes.Buffer)
b.Reset() // the object you get back may be dirty, so reset it first
// ... use b ...
bufPool.Put(b) // put it back when done, for others to reuse

New is the only field the user needs to supply: when the pool has no object to hand out, it falls back to New to make one. So what Get returns is either an old object someone just put back, or a new one freshly made by New, and the caller has no way, and no need, to tell the two apart. This section first covers the ancient idea of reusing objects that the pool rests on, then unpacks the three layers it builds for concurrency and GC: per-P sharding, the victim cache, and cooperation with the runtime’s GC.

11.7 Concurrency-Safe Hash Table

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

11.7 Concurrency-Safe Hash Table

sync.Map went through a complete internal rewrite in Go 1.24: the original read/dirty two-map design was replaced by a concurrent hash-trie. This section first makes the origin of each of these two generations of design clear, then places them back into the solution lineage of concurrent hash tables.

The language’s built-in map is not concurrency-safe. When multiple goroutines read and write the same map simultaneously without synchronization, the runtime actively detects the concurrent access and terminates the process with fatal error: concurrent map read and map write (5.2 introduced this detection mechanism; it is unrecoverable, and recover cannot intercept it). For services with availability requirements, this is a design question that must be answered head-on: when multiple goroutines need to share one table, what structure should be used.

11.8 Context

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

11.8 Context

A request entering a server seldom runs to completion inside a single goroutine. It fans out into a tree of goroutines: one queries the database, one calls a downstream RPC, one reads the cache, and each of these spawns smaller units of work in turn. Once the originator of the request no longer needs the result, say the client has disconnected, or the upstream has already timed out, all the work still running across that tree becomes pure waste, holding connections, locks, and memory while no one will ever read what it produces. The problem then becomes: how do we propagate the signal “stop here” from the root of the tree out to every leaf, so each of them can stop on its own.

11.9 Memory Consistency Models

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

11.9 Memory Consistency Models

Go’s memory model went through an important revision in 2022 with Go 1.19. After laying out the current model, this section devotes space to the background of that revision (see 11.9.8).

The reader may have noticed that in the earlier discussion of the Go runtime and compiler we kept steering clear of one topic: Go’s memory model. The avoidance was not without reason. To explain it properly requires groundwork in concurrency, synchronization primitives, and even the hardware layer, and only now is that groundwork in place. As the close of this chapter, and as the book’s summary of Go’s synchronization primitives and patterns, we take up the topic here and answer the question still unresolved in the reader’s mind: when two Goroutines read and write the same variable at once, under what conditions is one side’s write guaranteed to be seen by the other.