The Go Memory Model

This is a creation in Article, where the information may have evolved or changed.

Version of May 31, 2014

Https://golang.org/ref/mem

Introduction Advice Happens before Synchronization Initialization Goroutine creation Goroutine Destruction Channel Communication Locks Once Incorrect synchronization

Introduction

The Go memory model specifies the conditions under which reads of a variable in one goroutine can is guaranteed to observe Values produced by writes to the same variable in a different goroutine.

Advice

Programs that modify data being simultaneously accessed by multiple goroutines must serialize such access.

To serialize access, protect the data with channel operations or other synchronization primitives such as those in the and sync/atomic packages.

If you must read the rest of this document to understand the behavior of your program, you are being too clever.

Don ' t be clever.

Happens before

Within a goroutine, reads and writes must behave as if they executed in the order specified by the program. That's, compilers and processors may reorder the reads and writes executed within a single goroutine only when the Reorde Ring does not a change of the behavior within that goroutine as defined by the language specification. Because of this reordering, the execution order observed by one goroutine could differ from the order perceived by another. For example, if one goroutine executes  a = 1; b = 2; , another might observe the updated value of  b  before the updated value of  a .

To specify the requirements of reads and writes, we define happensbefore, a partial order on the execution of me Mory Operations in a Go program. If Event E1 happens before event E2, then we say the E2 happens after E1. Also, if E1 does not happen before E2 and does not happen after E2, then we say that E1 and E2 happen concurrently.

Within a single goroutine, the Happens-before order was the order expressed by the program.

A read r of a variable v is allowed to observe a write W to v if both of the following hold:

1. R does not happen before W.
2. There is no other write W ' to that v happens after W but before R.

To guarantee this a read R of a variable v observes a particular write W v to, ensure that w are the only write R i s allowed to observe. That's, R is guaranteed to observe w if both of the following hold:

1. W happens before R.
2. Any and write to the GKFX variable v either happens before W or after R.

This pair of conditions is stronger than the first pair; It requires that there is no other writes happening concurrently with W or R.

Within a single goroutine, there was no concurrency, so the other definitions is EQUIVALENT:A read R observes the value WRI Tten by the most recent write W v . When multiple goroutines access a shared variable v , they must use synchronization events to establish Happens-before Conditions that ensure reads observe the desired writes.

The initialization of variable with the v zero value for v ' s type behaves as a write in the memory model.

Reads and writes of values larger than a single machine word behave as multiple machine-word-sized operations in an unspec ified order.

Synchronization

Initialization

Program initialization runs with a single goroutine, but that Goroutine could create other goroutines, which run concurrently.

If A Package p imports package q , the completion of q ' s init functions happens before the start of any of the ' s.

The start of the function main.main happens after all init functions has finished.

Goroutine creation

The go statement that starts a new goroutine happens before the Goroutine ' s execution begins.

For example, the This program:

var a stringfunc f () {print (a)}func hello () {a = "Hello, world" Go f ()}

Calling would print at some point in the future hello "hello, world" (perhaps after have hello returned).

Goroutine Destruction

The exit of a goroutine is not guaranteed to happen before all event in the program. For example, the This program:

var a stringfunc hello () {go func () {a = "Hello"} () print (a)}

athe assignment to isn't followed by any synchronization event, so it's not guaranteed to being observed by any other Goroutine. In fact, an aggressive compiler might delete the entire go statement.

If the effects of a goroutine must be observed by another goroutine, use a synchronization mechanism such as a lock or Cha Nnel communication to establish a relative ordering.

Channel Communication

Channel communication is the main method of synchronization between Goroutines. Each send on a particular channel are matched to a corresponding receive from the channel, usually in a different goroutin E.

A Send on a channel happens before the corresponding receive from that channel completes.

This program:

var c = make (chan int, ten) var a stringfunc f () {a = "Hello, world" C <-0}func main () {go f () <-cprint (a)}

is guaranteed to print "hello, world" . athe write to happens before the send c in, which happens before the corresponding receive on c completes, WH Ich happens before the print .

The closing of a channel happens before a receive that returns a zero value because the channel is closed.

In the previous example, replacing and yields a program with the c <- 0 close(c) same guaranteed behavior.

A receive from A unbuffered channel happens before the send to that channel completes.

This program (as above, but with the send and receive statements swapped and using a unbuffered channel):

var c = make (chan int) var a stringfunc f () {a = ' Hello, world ' <-c}

Func main () {go f () C <-0print (a)}

is also guaranteed to print "hello, world" . athe write to happens before the receive c in, which happens before the corresponding send on c completes, WH Ich happens before the print .

If the channel were buffered (e.g.,) then the program would isn't being c = make(chan int, 1) guaranteed to print "hello, world" . (It might print the empty string, crash, or do something else.)

The kth receive on a channel with capacity C happens before the K+cth send from that C Hannel completes.

This rule generalizes the previous rule to buffered channels. It allows a counting semaphore to being modeled by a buffered channel:the number of items in the channel corresponds to the Number of active uses, the capacity of the channel corresponds to the maximum number of simultaneous uses, sending an item Acquires the semaphore, and receiving an item releases the semaphore. This was a common idiom for limiting concurrency.

Starts a goroutine for every entry in the work list, and the goroutines coordinate using the channel to limit Ensure that at the most three is running work functions at a time.

var limit = make (chan int, 3) func main () {for _, W: = Range Work {go func (w func ()) {limit <-1w () <-limit} (W)}select {}}

Locks

syncThe package implements the data types, and sync.Mutex sync.RWMutex .

For any sync.Mutex or sync.RWMutex variable l and n < m, call n of l.Unlock() happens before call m of l.Lock() returns.

This program:

var l sync. Mutexvar a stringfunc f () {a = "Hello, World" l.unlock ()}func main () {l.lock () go f () L.lock () print (a)}

is guaranteed to print "hello, world" . The first call l.Unlock() f to (in) happens before the second call l.Lock() to ( main in) returns, which happens before the .

l.RLock sync.RWMutex l for variable, there are an n such that the l.RLock happens (returns) after call n to and the l.Unlock matching l.RUnlock happens before call n+1 to l.Lock .

Once

The package sync provides a safe mechanism for initialization in the presence of multiple goroutines through the use of T He Once type. Multiple threads can execute for once.Do(f) a particular f , but only one would run f() , and the other calls block until has returned.

A single Call of f() from once.Do(f) happens (returns) before any call of once.Do(f) returns.

In the program:

var a stringvar once sync. Oncefunc Setup () {a = "Hello, World"}func doprint () {once. Do (Setup) print (a)}func twoprint () {go doprint () Go Doprint ()}

Calling twoprint causes to be "hello, world" printed twice. The first call to doprint runs setup once.

Incorrect synchronization

Note that a read R is observe the value written by a write W, happens concurrently with R. Even if this occurs, the it does not imply the reads happening after R would observe writes that happened before W.

In the program:

var A, B intfunc f () {a = 1b = 2}func g () {print (b) print (a)}func main () {go f () g ()}

It can happen that g prints and then 2 0 .

This fact invalidates a few common idioms.

Double-checked locking is a attempt to avoid the overhead of synchronization. For example, the program twoprint might is incorrectly written as:

var a stringvar done Boolfunc setup () {a = ' Hello, world ' done = True}func Doprint () {if!done {once. Do (Setup)}print (a)}func twoprint () {go doprint () Go Doprint ()}

But there was no guarantee that, doprint in, observing the write to done implies observing the write to a . This version can (incorrectly) print an empty string instead of "hello, world" .

Another incorrect idiom is busy waiting for a value, as in:

var a stringvar done Boolfunc setup () {a = ' Hello, world ' done = True}func main () {go setup () for!done {}print (a)}

As before, there is no guarantee, in main , observing the write done to implies observing a the write to, so thi S program could print an empty string too. Worse, there is no guarantee then the write to would done ever be observed main by, since there is no synchronization ev Ents between the threads. The loop is not main guaranteed to finish.

There is subtler variants on this theme, such as this program.

Type T struct {msg string}var g *tfunc Setup () {t: = new (t) t.msg = "Hello, world" G = T}func main () {go setup () for g = = Nil {}print (g.msg)}

Even if main observes g != nil and exits its loop, there are no guarantee that it'll observe the initialized value for .

In all these examples, the solution is the Same:use explicit synchronization.