The Go Memory Model

The Go memory model specifies when memory write operations become visible to other goroutines and, more importantly, when these visibility guarantees do not exist. As developers, we can skip over the details of the memory model by following a few guidelines when developing concurrent programs. Regardless, as mentioned before, obvious bugs are caught easily in QA, and bugs that happen in production usually cannot be reproduced in the development environment, and you may be forced to analyze the program behavior by reading code. A good knowledge of the memory model is helpful when this happens.

In this chapter, we will discuss the following:

• Why a memory model is necessary
• The happened-before relationship between memory operations
• Synchronization characteristics of Go concurrency primitives

Why a memory model is necessary

In 1965, Gordon Moore observed that the number of transistors in dense integrated circuits double every year. Later, in 1975, this was adjusted to doubling every 2 years. Because of these advancements, it quickly became possible to squeeze lots of components into a tiny chip, enabling the building of faster processors.

Modern processors use many advanced techniques, such as caching, branch prediction, and pipelining, to utilize the circuitry on a CPU to its maximum potential. However, in the 2000s, hardware engineers started to hit the limit of what could be optimized on a single chip. As a result, they created chips containing multiple cores. Nowadays, most performance considerations are about how fast a single core can execute instructions, as well as how many cores can run those instructions simultaneously.

The compiler technology did not stand still while these improvements were happening. Modern compilers can aggressively optimize programs...

The happened-before relationship between memory operations

It all comes down to how memory operations are ordered at runtime, and how the runtime guarantees when the effects of those memory operations are observable. To explain the Go memory model, we need to define three relationships that define different orderings of memory operations.

In any goroutine, the ordering of memory operations must correspond to the correct sequential execution of that goroutine as determined by the control flow statements and expression evaluation order. This ordering is the sequenced-before relationship. This, however, does not mean that the compiler has to execute a program in the order it is written. The compiler can rearrange the execution order of statements as long as a memory read operation of a variable reads the last value written to that variable.

Let’s refer to the following program:

1: x=1
2: y=2
3: z=x
4: y++
5: w=y

The z variable will always be set to 1, and the w variable...

Synchronization characteristics of Go concurrency primitives

Having defined a happened-before relationship, it is easy to lay the ground rules for the Go memory model.

Package initialization

If package A imports another package, B, then the completion of all init() functions in package B happens before the init() functions in package A begin.

The following program always prints B initializing before A initializing:

package B
import "fmt"
func init() {
   fmt.Println("B initializing")
}
---
package A
import (
   "fmt"
    "B"
)
func init() {
  fmt.Println("A initializing")
}

This extends to the main package as well: all packages directly or indirectly imported by the main package of a program complete their init() functions before main() starts. If an init() function creates a goroutine, there is no guarantee that the goroutine will finish before main() starts...

Summary

If you always serialize access to variables that are shared between multiple goroutines, you don’t need to know all the details of the Go memory model. However, as you read, write, analyze, and profile concurrent code, the Go memory model can provide the insight that guides you to create safe and efficient programs.

Next, we will start working on some interesting concurrent algorithms.

Further reading

• The Go Memory Model: https://go.dev/ref/mem
• Go’s Memory Model, a presentation by Russ Cox, February 25, 2016: http://nil.csail.mit.edu/6.824/2016/notes/gomem.pdf