[翻譯] go memory model

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

Introduction

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

Go記憶體模型限定了一些條件 滿足這些條件 才能讓變數 安全地在不同的goroutine之間讀寫

Happens Before

Within a single goroutine, reads and writes must behave as if they executed in the order specified by the program. That is, compilers and processors may reorder the reads and writes executed within a single goroutine only when the reordering does not change the behavior within that goroutine as defined by the language specification. Because of this reordering, the execution order observed by one goroutine may 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.

a = 1; b = 2;

如果只有一個goroutine 讀寫行為和它們在程式中的位置一致 就是說 編譯器和處理器只能在保證讀寫在程式中的正確行為時 比如讀寫順序 才有可能對讀寫進行最佳化  舉例來說 在一個goroutine中執行 另一個goroutine中可能會在a之前察覺到b的更新操作

To specify the requirements of reads and writes, we define happens before, a partial order on the execution of memory operations in a Go program. If event e1happens before event e2, then we say that e2 happens after e1. Also, if e1 does not happen before e2 and does not happen after e2, then we say that e1 and e2happen concurrently.

為了定義讀寫的需求 我們給Go程式的記憶體操作 定義了一個偏序“發生在X之前”  如果時間e1發生在e2之前 那麼我們認為e2事件出現在e1後 同樣的 如果e1不出現在e2之前 並且又不出現在e2之後 那麼我們認為e1和e2是並行的

Within a single goroutine, the happens-before order is the order expressed by the program.

在同一個goroutine中 “發生在X之前”這個次序和程式中表達出來的次序是一致的

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

對v的寫操作w 如果想被v的讀操作r觀察到 需要滿足下面兩個條件：

1. r does not happen before w.  r不發生在w之前
2. There is no other write w' to v that happens after w but before r. 沒有其它的寫操作w` 發生在w之後 r之前

To guarantee that a read r of a variable v observes a particular write w to v, ensure that w is the only write r is allowed to observe. That is, r is guaranteed to observe w if both of the following hold:

想要保證讀操作r 可以觀察到特定的w寫操作 需要確保w是r唯一可以觀察到的寫操作 也就是說 只有滿足下麵條件後 才得以保證r觀察到w 

1. w happens before r.  w發生在r之前
2. Any other write to the shared variable v either happens before w or after r. 任何其它對v的寫 要麼發生在w之前 要麼在r之後

This pair of conditions is stronger than the first pair; it requires that there are no other writes happening concurrently with w or r.

這兩個條件要比之前的兩個條件更加嚴苛 它需要沒有其它的寫操作和w或者r是並行發生的

Within a single goroutine, there is no concurrency, so the two definitions are equivalent: a read r observes the value written by the most recent write w to 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.

在單一goroutine環境下 沒有並行的說法 所以上面兩對條件是相同的 讀操作觀察到對變數v的最近一次寫 當多個goroutine同時訪問共用變數v時 它們需要利用同步事件來建立“發生在X之前”這個條件 來確保讀可以觀察到寫

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

v變數用對應類型的零值初始化行為 在記憶體模型中 和寫變數v是類似的

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

如果讀寫的值大於一個機器字 它們的行為和 多機器字操作類似 次序不確定

Synchronization

Initialization

Program initialization runs in a single goroutine, but that goroutine may create other goroutines, which run concurrently.

程式初始化 是在單一的goroutine環境進行的 但是 這個goroutine可以再建立其它的goroutine 它們之間並存執行

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

如果包p匯入了包q q的init函數在q的初始化之前執行

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

main.main函數在所有的初始化函數init結束後才會執行

Goroutine creation

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

go語句會開啟一個新的goroutine 並且在這個goroutine執行前就建立好了

For example, in this program:

舉例來說：

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

calling hello will print "hello, world" at some point in the future (perhaps after hello has returned).

在某個場合下調用hello函數 會列印“hello，world” （可能是在hello函數已經返回的情況下）

Goroutine destruction

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

我們確定不了goroutine在退出的次序 比如在事件e之前它必須退出 舉例來說：

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

the assignment to a is not followed by any synchronization event, so it is not guaranteed to be observed by any other goroutine. In fact, an aggressive compiler might delete the entire go statement.

上面這段代碼 a的賦值操作並沒有跟在任何的同步事件之後 所以並不能保證它會被其它的goroutine觀察到 事實上 激進一點的編譯器會把這段代碼（go func(){a=fasd})刪掉

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

如果想在不同的goroutine之間觀察到變數的更新操作 那麼需要使用一些同步的機制 比如使用鎖 或者通過channel來通訊 從而建立起相對的讀寫次序

Channel communication

Channel communication is the main method of synchronization between goroutines. Each send on a particular channel is matched to a corresponding receive from that channel, usually in a different goroutine.

使用channel進行通訊 是在不同的goroutine間同步的主要方法 每個對特定channel的send操作 通常都會對應於其它goroutine中的receive操作

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

channel的send操作 一定發生在對應的receive操作完成之前

This program: 下面這段代碼：

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

is guaranteed to print "hello, world". The write to a happens before the send on c, which happens before the corresponding receive on c completes, which happens before the print.

可以確保 列印“hello, world” 寫操作發生在channel c的send操作之前 send又發生在c的receive操作之前 receive發生在print之前

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

關閉channel發生在接受之前 因為channel已經關閉了 mai中go f() 開啟了另一個goroutine 在main中繼續執行的話 會執行到 <-c 然後在channel接收這阻塞 goroutine f() 開始執行 寫變數a 之後關閉channel 回到main 列印a channel在這裡純屬是用來同步的

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

上面那段代碼中 如果用close(c)來替換c<-0 它的行為是一樣的

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

從無緩衝channel中接收操作 發生在該channel的發送操作結束前

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

下面這段代碼 和上面代碼一樣 但是接收和發送操作掉了個 並且使用無緩衝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". The write to a happens before the receive on c, which happens before the corresponding send on c completes, which happens before the print.

這段代碼同樣可以保證列印出“hello world” 對a的寫操作 發生在channel c的接收操作之前 接收操作發生在相應的發送操作完成前 而發送操作則發送在列印之前

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

如果是有緩衝的channel 那麼上面那段代碼就無法保證會列印“hello world”了

Locks

The sync package implements two lock data types, sync.Mutex and sync.RWMutex.

sync包實現了兩種類型的鎖 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.

對任意的sync.Mutex或者sync.RWMutex變數l  n <m, 第N次調用l.Unlock 發生在 m次調用l.Lock返回前

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 to l.Unlock() (in f) happens before the second call to l.Lock() (in main) returns, which happens before the print.

上述代碼可以保證輸出“hello，world” 第一次調用l.Unlock 發生在第二次調用l.Lock之前 而其二次調用I.Lock發生在print操作之前

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

在sync.RWMutex變數l上的任何一次l.RLock操作  會存在一個n l.RLcok發生在調用第n次l.Unlock之後 對於的l.RUnlock發生在第n+1次l.Lock調用之前

Once

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

sync包為在多goroutine環境下初始化提供了一種安全的機制 需要使用sync包的Once類型 多個線程可以同時執行once.Do(f) 但是只有一個線程會調用f() 其它的線程會阻塞 直到f()返回

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

通過once.Do(f)調用f發生在任何其它的once.Do(f)返回之前

In this 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 "hello, world" to be printed twice. The first call to twoprint runs setup once.

調用兩次twoprint會輸出兩次“hello，world”  

Incorrect synchronization

Note that a read r may observe the value written by a write w that happens concurrently with r. Even if this occurs, it does not imply that reads happening after r will observe writes that happened before w.

注意 讀操作r可能會觀察到和r並行的寫操作w 即使出現這樣的情況 也不意味著r之後的讀會觀察到w之前的寫操作

In this 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 2 and then 0.

上面這段代碼可能會輸出2 然後 輸出0

This fact invalidates a few common idioms. 這個事實讓很多習以為常的事情作廢了

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

多檢查一次鎖 是避免同步問題的一種途徑 例如： twoprint程式可能被寫成下面這樣：

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 is no guarantee that, in doprint, observing the write to done implies observing the write to a. This version can (incorrectly) print an empty string instead of "hello, world".

但是 這樣寫並不能保證 doprint中觀察到對done的寫 就能觀察到對a的寫操作

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 that, in main, observing the write to done implies observing the write to a, so this program could print an empty string too. Worse, there is no guarantee that the write to done will ever be observed by main, since there are no synchronization events between the two threads. The loop in main is not guaranteed to finish.

這樣寫的結果和上面的情況一樣 這段代碼可能只會列印Null 字元串 更慘的是 並不能保證對done的寫 會在main中被觀察到 因為它們之間並沒有同步的事情 main中的loop並不能保證 能等到那個想要的值 

There are 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 is no guarantee that it will observe the initialized value for g.msg.

效果一樣

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

看的不太明白 哎。。。