メモリモデルとhappens-before関係

なぜ「モデル」が必要なのか

単一スレッドのプログラムは、ソースに書いた順番どおりに実行されたかのように振る舞います。しかし実際には、コンパイラは依存のない命令を入れ替え、CPUはストアバッファや投機実行で書き込みを遅延・先行させます。単一スレッドでは結果が変わらない限りこれらは「見えない」のですが、別スレッドがそのメモリを同時に観測する瞬間、並び替えと可視性の遅延が一気に表面化します。

メモリモデルとは、こうした最適化を許しつつ「あるスレッドの書き込みが、いつ、どの順序で、他のスレッドから観測されうるか」を厳密に定める契約です。プログラマは「この同期操作を入れればこの可視性が保証される」と推論でき、処理系は「この保証を壊さない範囲なら自由に並び替えてよい」と最適化できます。Java の JMM（Java Memory Model, JSR-133）と C++11 のメモリモデルは、いずれもこの契約を happens-before 関係という抽象で記述します。

happens-before 関係の定義

happens-before（→ と書きます）は、プログラム中のアクション間に定義される半順序です。半順序なので、任意の2アクションが必ず順序づけられるわけではありません。順序づかないペアこそが問題の核心になります。

この関係は2つの源から組み立てられます。

• プログラム順序（program order）：同一スレッド内で先に書いたアクションは、後のアクションに happens-before する。
• 同期順序（synchronizes-with）：あるスレッドの解放操作（ロック解除、release ストア）が、別スレッドの取得操作（ロック取得、acquire ロード）に「観測される」とき、解放は取得に synchronizes-with する。

この2つを推移的に閉じたものが happens-before です。つまり A → B かつ B → C なら A → C。同期はスレッドをまたぐ「橋」を架け、プログラム順序が橋の両岸を伸ばす、という構図です。

スレッド1            スレッド2
data = 42;   (A)
flag = true; (B, release ストア)
                    while(!flag);   (C, acquire ロード)
                    use(data);      (D)

A → B (プログラム順序)
B → C (synchronizes-with: CがBの書き込みを観測)
C → D (プログラム順序)
∴ A → D  ⇒ Dからdataはちゃんと42に見える

ここで重要なのは、A → D が成立するからこそ data = 42 が D から確実に見える点です。同期がなければ B と C の間に橋が架からず、data の書き込みは D から見えるとは限りません（古い値や未初期化を読みうる）。

データ競合の正体

両モデルは**データ競合（data race）**を厳密に定義します。すなわち——

2つのアクセスが、(1) 同じメモリ位置に触れ、(2) 少なくとも一方が書き込みで、(3) どちらも同期操作（atomic/volatile）でなく、(4) happens-before で順序づけられていない——とき、それらはデータ競合をなす。

ここが上級者の落とし穴です。「読み書きが同時に起きた」のが競合なのではなく、happens-before で順序づけられていない普通のアクセスの組が競合なのです。同時に走っていても、間に同期があって順序づけられていれば競合ではありません。

C++ ではデータ競合は 未定義動作（UB） です。「古い値が見える」程度では済まず、最適化の前提が崩れてプログラム全体の意味が壊れます。Java はメモリ安全性のため UB にはせず、代わりに「out-of-thin-air（どこからともなく現れる値）を除き、何らかの並び替え結果が観測されうる」という弱い保証に留めます。いずれにせよ、競合のあるコードの結果を推論してはいけないという結論は同じです。可変状態の共有を減らす設計が根本対策になる理由はここにあり、イミュータビリティ（不変性）が並行処理で強い所以でもあります。

メモリオーダーとバリアの原理

C++11 は同期の「強さ」を memory_order で段階的に選べます。これが happens-before を実装レベルで実現する**メモリバリア（フェンス）**に対応します。

肝は release/acquire のペアリングです。スレッド1の release ストアを、スレッド2の acquire ロードが観測したとき、synchronizes-with が成立し、release より前の全書き込みが、acquire より後の読み出しから見えるようになります。release は「片方向の壁」——壁の上（前）の操作が壁を越えて下へ漏れるのを禁じ、acquire は逆に下の操作が上へ漏れるのを禁じます。この非対称な一方向バリアが、最小限のコストで「橋」を架ける仕組みです。

// 生産者（スレッド1）
data = compute();                          // 通常書き込み
ready.store(true, std::memory_order_release); // releaseの壁：上の書き込みを下に漏らさない

// 消費者（スレッド2）
while (!ready.load(std::memory_order_acquire)) {} // acquireの壁：下の読みを上に漏らさない
use(data);                                 // dataは確実にcompute()の結果

ハードウェアでは、これらは具体的なバリア命令やキャッシュコヒーレンス制御に落ちます。x86 は比較的強いメモリモデル（TSO, Total Store Order）を持ち、StoreLoad 以外の並び替えをそもそも行わないため acquire/release はほぼ無コストですが、ARM や POWER は弱順序で、dmb などの明示的バリアが挿入されます。同じソースでも CPU によって生成されるバリアの量が違うのは、ハードウェアのメモリモデルの強弱を吸収しているためです。

seq_cst と Java volatile

C++ のデフォルト seq_cst と Java の volatile（JSR-133 以降）は、acquire/release に加えて全 seq_cst 操作にまたがる単一の全順序を保証します。これにより、複数の独立した atomic 変数の間でも一貫した順序が観測でき、有名な「ストアバッファ問題」（2スレッドが互いの変数を書いてから相手を読むと両方が古い値を見る）を防げます。

Java の volatile 書き込みは release、読み出しは acquire として働き、加えて全 volatile アクセスに全順序が付くため、実質 seq_cst 相当です。Java の synchronized は、あるモニタの unlock が、同じモニタの後続 lock に synchronizes-with するルールで happens-before を作ります。final フィールドには特別規定があり、コンストラクタ完了後はデータ競合があっても初期値が見える保証が与えられます——これは安全な公開（safe publication）の土台です。

まとめと実務指針

メモリモデルの核心は3点に集約できます。第一に、並び替えと可視性遅延は最適化の正当な帰結であり、それを前提に「許される結果の範囲」を定めるのがモデルの役割。第二に、happens-before という半順序が「この書き込みはあの読み出しから見える／見えない」を決め、順序づかない普通アクセスの組がデータ競合として未定義（C++）または弱保証（Java）の領域に落ちる。第三に、同期は release/acquire の一方向バリアとして実装され、seq_cst/volatile がさらに全順序を足す。

実務では、まずそもそも共有可変状態を避ける（不変データ、メッセージパッシング）のが最善で、これは並行性モデル（CSP・アクター・STM）が示す方向です。共有が避けられないなら、ロックか seq_cst の atomic で安全側に倒し、relaxed や acquire/release はプロファイルで本当に効くと確認できた箇所に限定します。並行処理の入口にあたる待ち合わせの考え方は同期処理と非同期処理も参照してください。