値の可視性

1つのゴルーチン内では、コードに記述された順序どおりに処理が実行されます。しかし複数のゴルーチンが共有メモリを読み書きする場合、同期を行わない限り、あるゴルーチンが行った書き込みがいつ別のゴルーチンから見えるかは保証されません。これは、コンパイラやCPUが実行性能を高めるために、プログラムの意味を変えない範囲で命令の並べ替えを行ったり、レジスタやCPUキャッシュに値を保持したりするためです。

次の例では、書き込み側のゴルーチンがmessageに値を設定したあとにreadyをtrueに更新しています。

var message string
var ready bool

go func() {
    message = "done"
    ready = true
}()

for !ready {
    // readyがtrueになるのを待つ
}
fmt.Println(message) // 空文字列が表示される可能性がある

直感的には、ループを抜けてready == trueが確認できたなら、その前に書かれたmessageも"done"になっていると期待されます。しかし同期が行われていない場合、コンパイラやCPUによる並べ替えによって、読み取り側から見るとready = trueの反映がmessage = "done"より先に見えることがあります。また、readyの更新自体がキャッシュからメモリへ反映されず、ループが終了しない可能性もあります。

happens-before関係

メモリモデルでは、プログラム内のメモリ操作の順序と可視性を規定するためにhappens-beforeという概念を用います。操作Aが操作Bに対してhappens-beforeである、つまり操作Aが操作Bより前のとき、操作Aによるメモリの書き込みは、操作Bから確実に読み取れることが言語仕様として保証されます。単一のゴルーチン内では、プログラムの記述順序に従ってhappens-before関係が成り立ちます。

go func() {
    name := ""
    name = "gopher"
    fmt.Println(name) // 同じゴルーチン内なので必ずgopher
}()

go文によるゴルーチンの起動は、そのゴルーチンの開始に対してhappens-beforeとなります。そのため、go文より前に行われた書き込みは、起動されたゴルーチンから確実に読み取ることができます。

name := "gopher"
go func() {
    fmt.Println(name) // 必ずgopher
}()

一方で、ゴルーチンの終了自体は他のいかなる操作に対してもhappens-before関係を持ちません。そのため、起動されたゴルーチン内で行われた書き込みは、チャネルやミューテックスなどで明示的に同期しない限り、起動元のゴルーチンから読み取れる保証はありません。

var name string
go func() {
    name = "gopher"
}()
fmt.Println(name) // 空文字列のことがある

このようにチャネルの送受信で同期を明示的に行うと、送信前の書き込みが受信後に必ず読み取れます。

var name string
done := make(chan struct{})
go func() {
    name = "gopher"
    done <- struct{}{}
}()
<-done
fmt.Println(name) // 必ずgopher

closeは、送信と同じ向きの順序付けができます。閉じるより前の書き込みは、閉じたチャネルからの受信後に必ず読み取れます。

var name string
done := make(chan struct{})
go func() {
    name = "gopher"
    close(done)
}()
<-done
fmt.Println(name) // 必ずgopher

バッファなしチャネルmake(chan T)では、送信側と受信側が揃って初めて通信が成立します。そのため送信の完了が受信の完了に対してhappens-beforeとなるだけでなく、受信の完了も送信の完了に対してhappens-beforeとなります。

一方、バッファ付きチャネルmake(chan T, n)では、バッファに空きがある限り、受信側を待たずに送信が即座に完了します。容量がnのバッファ付きチャネルで仕様上保証されるのは、k回目の受信完了は、k+n回目の送信完了に対してhappens-beforeとなるという規則です。

var name string
done := make(chan struct{}, 1)
go func() {
    name = "gopher"
    <-done
}()
done <- struct{}{}
fmt.Println(name) // 空文字列のことがある

nが1のとき、1回目の受信は2回目の送信の完了に対してhappens-beforeになります。2回目の送信はバッファが空くまで待つので、その完了後には受信より前の書き込みが見えます。

var name string
done := make(chan struct{}, 1)
go func() {
    name = "gopher"
    <-done
}()
done <- struct{}{}
done <- struct{}{}
fmt.Println(name) // 必ずgopher

空きバッファへの送信は相手の受信を待たずに進むため、送信完了だけでは受信側の書き込みを読み取れる保証にはなりません。一方的な通知ではなく双方向の同期が必要な場合は、バッファなしチャネルを使うか、完了通知用のチャネルを別途設けます。

データ競合

2つ以上のゴルーチンがメモリ上の同じ位置へ同時にアクセスし、少なくとも1つが書き込みであり、かつそれらのアクセス間にhappens-before関係がない状態をデータ競合と呼びます。データ競合が起きると、意図した値が読めなくなるだけでなく、内部で複数の情報（ポインタや長さなど）を管理するstringやスライスでは値の破損やクラッシュにつながります。bool1つの代入であっても、同期のない並行アクセスはデータ競合になります。

var counter int

go func() {
    counter++
}()

fmt.Println(counter) // データ競合: 0か1かは決まらない

Go言語にはデータ競合を検出するレースディテクタが標準で備わっています。実行時やテスト時に-raceフラグを付与します。

go test -race ./...
go run -race main.go

レースディテクタは実行時のメモリアクセスを監視して競合を報告します。テストで実行されなかったコードパスの競合は検出できないため、並行処理を行うすべての経路をテストで動かす必要があります。

sync.Mutexによる排他制御とhappens-before

複数のゴルーチンが共有メモリを読み書きする場合、sync.Mutexによるロックを使ってアクセスを排他制御します。sync.Mutexは同時に1つのゴルーチンしか保護区間に入れないようにするだけでなく、メモリの可視性に関するhappens-before関係も保証します。

あるゴルーチンによるUnlockの呼び出し完了は、その後に成功する任意のゴルーチンによるLockの呼び出しに対してhappens-beforeとなります。したがって、あるゴルーチンがUnlockを呼ぶ前に行ったすべてのメモリ書き込みは、次にLockの取得に成功したゴルーチンから確実に読み取れます。

var (
    mu sync.Mutex
    n  int
)

mu.Lock()
go func() {
    defer mu.Unlock()
    n++
}()
mu.Lock()
fmt.Println(n) // 必ず1
mu.Unlock()