他のゴルーチンから見えるとは

Goのメモリモデルは、他のゴルーチンの書き込みが、いつ自分の読み取りから見えるかを定めます。次の例では、別ゴルーチンがreadyに書いたあとでも、読み取り側でtrueとは限りません。

var ready bool
go func() {
    ready = true
}()
_ = ready // readyがtrueとは限らない

ソースに書いた文の順どおりに、他のゴルーチンからも見えるとは限りません。コンパイラやCPUは速度のために、1つのゴルーチン内の読み書きの実行順を入れ替えることがあり（並べ替え）、書き込みの一部だけが先に観測されることがあります。

次の例では、書き込み側はaのあとにbを更新しています。それでも読み取り側が先にb == 2を見ても、その時点でa == 1とは限りません。2のあとに0と表示されることがあります。

var a, b int

go func() {
    a = 1
    b = 2
}()

fmt.Print(b)
fmt.Print(a) // 「20」や「00」などになりうる。「21」とは限らない

書き込みを確実に見せるには、チャネルの送受信やsync.WaitGroupで相手の完了を待つか、sync.Mutexで同じ変数へのアクセスを排他します。こうした、ゴルーチン同士の順序や排他をランタイムが保証する操作を同期と呼びます。

データ競合

2つ以上のゴルーチンが、同期を挟まずに同じ変数へアクセスし、少なくとも1つが書き込みであるとき、データ競合が起きます。競合するアクセスの結果は保証されません。boolへの1回の代入でも、他ゴルーチンからの可視性は保証されません。

var n int
go func() { n = 1 }()
fmt.Println(n) // 0とも1とも限らない（データ競合）

go test -raceで検出できます。検出器は実行したパスに依存するため、通らなかった経路の競合は残る可能性があります。

チャネルで見えるようにする

バッファの有無を問わず、チャネルへの送信は、対応する受信の完了より先に起きたとみなされます。送信より前の書き込みは、受信が終わったあとの読み取りから見えます。

var ready bool
ch := make(chan struct{})

go func() {
    ready = true
    ch <- struct{}{}
}()

<-ch
// この時点でready == trueが見える

値を送る代わりにclose(ch)しても同じです。閉じる前に書いた内容は、相手が受信で「閉じた」と分かったあとに見えます。

var ready bool
ch := make(chan struct{})

go func() {
    ready = true
    close(ch) // 送信の代わりに閉じる
}()

<-ch // 閉じたチャネルからの受信
// この時点でもready == trueが見える

チャネルを使わずreadyだけを読むと、上の保証は付きません。

バッファ付きチャネルでは、送信が受信を待たずに進むことがあります。その場合でも、「対応する受信が完了したあと」であれば、その送信より前の書き込みは受信側から見えます。

逆に、受信する側が書いた値を、送信が終わっただけで読もうとすると、バッファ付きでは見え方が保証されません。次の例では別ゴルーチンが先に受信し、mainが送信しています。バッファに空きがあるためch <- struct{}{}は相手の受信を待たずに進められ、その直後のreadyの読み取りでtrueとは限りません。

var ready bool
ch := make(chan struct{}, 1) // バッファ付き

go func() {
    ready = true
    <-ch // 受信側の書き込みのあとで受信
}()

ch <- struct{}{}
_ = ready // readyがtrueとは限らない（バッファ付きのため）

バッファなし（make(chan struct{})）なら、受信が先に待っていても送信が後から来ても、送受信は対になって同期します。受信が完了した時点で、対応する送信より前の書き込み（ここではready = true）が見えます。

Mutexで同じ変数を守る

複数のゴルーチンが同じ変数を同時に読み書きすると、データ競合になります。同時に触らせないようにする道具がsync.Mutexです。

Mutexは通行証1枚だと考えます。Lockに成功したゴルーチンだけが通行証を持ち、そのあいだに共有変数を更新します。他のゴルーチンが同じMutexへLockすると、前のゴルーチンがUnlockするまで待ちます。

var (
    mu sync.Mutex
    n  int
)

mu.Lock()
n++
mu.Unlock()

守りたい変数へ触るすべての経路で、同じmuを先にLockします。Lockせずにnを触るゴルーチンがいれば、そのアクセスは待ち行列に入らず、排他になりません。muは「どの変数を守るか」を覚えておらず、同じ通行証を使う処理どうしが順番待ちになる、という仕組みです。

データとロックをまとめて扱うときは、構造体のフィールドに置くことも多いです。置き場所が変わっても手順は同じで、t.nに触る前にt.mu.Lockします。

type Tally struct {
    mu sync.Mutex
    n  int
}

func (t *Tally) Inc() {
    t.mu.Lock()
    t.n++
    t.mu.Unlock()
}

func (t *Tally) Value() int {
    t.mu.Lock()
    defer t.mu.Unlock()
    return t.n
}

あるゴルーチンのUnlockのあと、別ゴルーチンが同じミューテックスでLockに成功した時点から、そのUnlockより前の書き込みが見えます。Incで増やしたnは、後続のValueから読めます。

LockとUnlockのペアを崩すと、排他も可視性の保証も壊れます。Unlockを忘れないよう、関数を抜ける経路が複数あるときはdefer t.mu.Unlock()が使われます。