Day 035 — メモリモデルとhappens-before関係

📚 背景知識（読んでから問題へ）

Day 034ではgo test -raceが「実際に起きたデータ競合」をどう検出するかを体験しました。しかし-raceは動的解析ツールであり、「そもそもなぜ同期なしのメモリアクセスが未定義動作になるのか」という理論的根拠までは教えてくれません。その理論的根拠を定義しているのが The Go Memory Model が規定するhappens-before関係です。

Go Memory Modelの核心は次の一文に集約されます。

ここで注意すべきは、happens-beforeは「実際に時間的に先に実行される」という意味ではないという点です。これはコンパイラやCPUが命令を並べ替えてよい範囲を制限し、可視性を保証する抽象的な順序関係です。単一goroutine内では、プログラムに書かれた順序（sequenced before）がそのままhappens-beforeになります。しかしgoroutineをまたぐ場合、happens-before関係は明示的な同期プリミティブを使わない限り一切成立しません。これが「goroutineを2つ起動して片方が書いた変数をもう片方が読むだけ」のコードが、たとえ-raceが偶然何も報告しなくても理論上は未定義動作である理由です。

Go 1.19（2022年）でメモリモデルはC/C++のメモリモデルに正式に整合する形で明文化され、sync/atomicパッケージの操作にも明確なhappens-before規則が定義されました。Day 035では、Go Memory Modelが保証する主要な同期プリミティブごとのhappens-beforeルールを正確に整理し、「-raceが黙っていても壊れているコード」を見分けられるようになることを目標にします。

📝 問題

以下は、2つのgoroutine（AとB）が共有変数dataと何らかの「合図」用の変数・プリミティブを使ってやり取りする7つのパターンです。goroutine Aがdataに書き込んだ後、goroutine Bがその書き込みを必ず観測できる（happens-before関係が成立している）かどうかを、それぞれ判定してください。

📋 コピーvar data int
var mu sync.Mutex
var once sync.Once
var wg sync.WaitGroup
var flagPlain bool
var flagAtomic atomic.Bool
ch := make(chan struct{})
chBuf := make(chan struct{}, 1)

// (A) goroutine起動のみ（同期なし）
data = 1
go func() {
    fmt.Println(data) // 観測できるか？
}()

// (B) 素朴なbool変数によるスピン待ち
go func() {
    data = 2
    flagPlain = true // 合図
}()
go func() {
    for !flagPlain { // スピン待ち
    }
    fmt.Println(data) // 観測できるか？
}()

// (C) atomic.Boolによるスピン待ち
go func() {
    data = 3
    flagAtomic.Store(true)
}()
go func() {
    for !flagAtomic.Load() {
    }
    fmt.Println(data) // 観測できるか？
}()

// (D) unbuffered channelの送受信
go func() {
    data = 4
    ch <- struct{}{}
}()
go func() {
    <-ch
    fmt.Println(data) // 観測できるか？
}()

// (E) sync.Mutex
go func() {
    mu.Lock()
    data = 5
    mu.Unlock()
}()
go func() {
    mu.Lock()
    fmt.Println(data) // 観測できるか？
    mu.Unlock()
}()

// (F) sync.WaitGroup
wg.Add(1)
go func() {
    data = 6
    wg.Done()
}()
go func() {
    wg.Wait()
    fmt.Println(data) // 観測できるか？
}()

// (G) goroutineの終了だけを待つ（同期プリミティブなし）
go func() {
    data = 7
    // goroutine終了、明示的な合図なし
}()
time.Sleep(1 * time.Second) // 「十分待てば終わっているはず」という期待
fmt.Println(data) // 観測できるか？

要件

1. (A)〜(G) それぞれについて「happens-before関係が成立するか（Yes/No）」と、成立する場合はGo Memory Modelのどのルールに基づくかを説明する
2. 特に(B)と(C)の違いを説明する。両者は見た目がほぼ同じ「スピン待ち」だが、一方は未定義動作でもう一方は正しい。何が違うのか？
3. (G)が危険な理由を、time.Sleepをどれだけ長くしても解決しない根本的な理由とともに説明する
4. (B)のパターンをgo test -raceで検出できるテストコードを書き、実際に競合が報告される条件を示す

🔍 ヒント（段階的開示）

📋 コピーfunc TestSpinWaitPlainBool_Race(t *testing.T) {
    for i := 0; i < 100; i++ {
        var data int
        var flagPlain bool
        done := make(chan struct{})
        go func() {
            data = 2
            flagPlain = true
            close(done)
        }()
        for !flagPlain { // ここが競合ポイント
        }
        _ = data
        <-done
    }
}

✅ 模範解答

1. 判定表

2. (B)と(C)の違い

見た目はどちらも「フラグ変数をスピンで待つ」という同じパターンですが、変数の型がメモリモデル上の同期プリミティブとして規定されているかどうかが決定的に異なります。

• bool型のプレーンな変数への読み書きは、コンパイラにとって「ただのメモリアクセス」でしかない。最適化（命令の並べ替え、レジスタへのキャッシュ、ループの除去）を妨げる理由が言語仕様上どこにもない
• atomic.Bool（やatomic.Int32等）のStore/Loadメソッドは、Go 1.19のメモリモデル改訂で明示的に「Release-Acquireセマンティクス」を持つと規定された。コンパイラはStoreの前にある書き込みをStoreより後に並べ替えることを禁止され、Loadが値を観測した側では、それ以前の書き込みがすべて可視になることが保証される

つまり(B)は「実装上たまたま動くことがある未定義動作」、(C)は「言語仕様が可視性を保証する正しいコード」という、見た目の類似性とは裏腹に本質的に別物です。

3. (G)がtime.Sleepで解決しない理由

根本的な理由は2つあります。

1. 理論的な理由: happens-beforeは「時間が経過したかどうか」ではなく「同期プリミティブによる明示的なやり取りがあったかどうか」で定義される。CPUのキャッシュコヒーレンシプロトコルが「たまたま」正しい値を見せてくれることはあっても、それは仕様が保証する動作ではない
2. 実務的な理由: 「1秒待てば終わっているはず」という前提はGCの一時停止、OSのスケジューリング遅延、CPU負荷の変動によって簡単に破られる。本番環境で低頻度にしか発生しない「たまに古い値が見える」バグの温床になる

正しい修正は、sync.WaitGroupやchannelのclose、contextのキャンセルなど、メモリモデルが定義する同期プリミティブでgoroutineの完了を待つことです。

4. (B)を検出するテストコード

ファイル構成: day035/go.mod + day035/main_test.go

📋 コピー// go.mod
module example.com/day035

go 1.22

📋 コピーpackage main

import (
	"sync/atomic"
	"testing"
)

// TestSpinWaitPlainBool_Race は、プレーンなbool変数によるスピン待ちが
// happens-before関係を持たないことを go test -race で検出するテスト。
// 100回繰り返し実行することで、コンパイラ・CPUの最適化・スケジューリング
// の揺らぎによってたまたま検出漏れになる確率を下げる。
func TestSpinWaitPlainBool_Race(t *testing.T) {
	for i := 0; i < 100; i++ {
		var data int
		var flagPlain bool
		done := make(chan struct{})

		go func() {
			data = 2
			flagPlain = true // (X) 書き込み側: dataとflagPlainの両方に非アトミックにアクセス
			close(done)
		}()

		for !flagPlain { // (Y) 読み込み側: flagPlainへの非同期な読み込みループ
		}
		_ = data
		<-done // テストのgoroutineリーク防止のためcloseを待つ
	}
}

// TestSpinWaitAtomicBool_NoRace は、対比としてatomic.Boolを使った
// 正しい実装が -race で警告を出さないことを確認するテスト。
func TestSpinWaitAtomicBool_NoRace(t *testing.T) {
	for i := 0; i < 100; i++ {
		var data int
		var flagAtomic atomic.Bool
		done := make(chan struct{})

		go func() {
			data = 3
			flagAtomic.Store(true)
			close(done)
		}()

		for !flagAtomic.Load() {
		}
		_ = data
		<-done
	}
}

mkdir day035 && cd day035
go mod init example.com/day035
# main_test.go を上記の内容で保存

go test -race -run TestSpinWaitPlainBool_Race -count=3 .
# => WARNING: DATA RACE
#    Write at 0x... by goroutine N:
#      example.com/day035.TestSpinWaitPlainBool_Race.func1()
#    Previous read at 0x... by goroutine M:
#      example.com/day035.TestSpinWaitPlainBool_Race()
#    のような報告が (X)/(Y) の間で出る

go test -race -run TestSpinWaitAtomicBool_NoRace -count=3 .
# => ok  example.com/day035  0.XXXs   (DATA RACEの報告なし)

🪜 Step-by-Step 解説

💡 設計思想・なぜこう書くのか

🌐 他言語との比較

🏆 実務での使いどころ

• 「動いているから正しい」を疑うコードレビュー: time.Sleepでgoroutineの完了を待つコードや、プレーンなbool/intを「合図」として使うコードを見たら、happens-beforeが成立しているかを機械的にチェックする
• パフォーマンスクリティカルな箇所でのMutex→atomicへの置き換え判断: 単純なカウンタ・フラグであればatomicはMutexより軽量。ただしatomicで守れるのは単一のスカラー値のみ（Day 034参照）という制約を踏まえた上での判断が必要
• クロスプラットフォーム移植時のリスク評価: x86中心の開発環境で「たまたま動いていた」並行処理コードをARMベースの環境（Apple Silicon、AWS Gravitonなど）に移植する際、happens-beforeが厳密に成立しているかの再点検が重要になる
• 障害調査での仮説形成: 「特定の環境・負荷でだけ稀に古い値が見える」という障害報告を受けた際、まず「同期プリミティブを使わず可視性に依存しているコードがないか」を疑う出発点になる

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: Go Memory Modelの原文（go.dev/ref/mem）を読み、sync.Onceが内部でatomicとMutexをどう組み合わせて実装しているか（標準ライブラリのソースコードsync/once.go）を確認してみましょう
• 次回予告: GC・エスケープ解析の理解 — Day 036では、happens-beforeとは異なる軸として、Goのランタイムが「どの変数をヒープに置き、どの変数をスタックに置くか」をどう判断しているかを理解します

🎯 自己評価

自分の回答

気づき・メモ