メモリ整合性モデルとシーケンシャル一貫性

整合性モデルとは「許される全順序」の契約

マルチコアでの並行プログラムを論じるとき、まず分けるべきは2つの概念です。キャッシュコヒーレンシ は「1つのアドレスに対する複数コアの書き込みが、全コアで同じ1本の順序に見える」ことを保証します（詳しくは メモリ階層とキャッシュコヒーレンシ（MESIプロトコル））。一方 メモリ整合性モデル は「複数のアドレスにまたがる 読み書きが、どんな相対順序で他コアに見えてよいか」を取り決めます。コヒーレンシは1アドレス内、整合性モデルはアドレス間の話です。

整合性モデルは、ハードウェアやプログラミング言語が並行コードに与える 形式的な契約 だと考えると正確です。契約が強い（許す並べ替えが少ない）ほど直感どおりに動きますが、最適化の余地が減って遅くなります。弱いほど速いが、プログラマが同期点を明示しないと結果が定義されません。この強弱の段階こそ、本稿で扱う モデルの階層 です。

シーケンシャル一貫性（SC）──最強で最も直感的

階層の頂点が シーケンシャル一貫性（Sequential Consistency, SC） です。Lamport の定義はこうです。

すべてのコアの操作が、ある単一の全順序に並べられ、かつ各コア内ではプログラム順が保たれる。その全順序の通りに1つの共有メモリを逐次に操作した結果と、実行結果が一致する。

要は 「各スレッドの命令列を、プログラム順を崩さずにインターリーブ（交互配置）した、何らかの1本の列」 で説明できる、ということです。並べ替えは一切起きず、ただ複数スレッドの混ざり方だけが非決定的になります。

スレッド1: x = 1; r1 = y;
スレッド2: y = 1; r2 = x;

SC で「ありえる」インターリーブの一例:
  x=1 → y=1 → r1=y(=1) → r2=x(=1)
SC で「禁止される」結果:
  r1==0 かつ r2==0   ← どんなインターリーブでも作れない

r1==0 かつ r2==0（両者が相手の書き込み前の値を読む）は、SC では決して起こりません。どの順に混ぜても、どちらかのストアは必ず先行するからです。ところが実機の x86 でこのコードを回すと 0,0 が観測されます。 つまり現実のハードウェアは SC ではありません。SC は理解とデバッグには最高ですが、各ストアの大域可視化を待つ実装はコストが高く、現代CPUは採用していません。

TSO・PSO・弱順序──ストアバッファが緩める階層

SC が崩れる根本原因は ストアバッファ です。コアは書き込みをいったん手元のバッファに溜めて次へ進み、後からキャッシュへ流します。すると「自分の書き込みは即読めるが、他コアには遅れて見える」非対称が生まれ、SC の大域全順序が破れます。どの並べ替えを許すかで、緩和モデルが段階化されます。並べ替えの4方向（LoadLoad / LoadStore / StoreStore / StoreLoad）の基礎は メモリオーダリングとメモリバリア を土台にしてください。

階段を一段ずつ降りると、解禁される並べ替えが増えていくのが見て取れます。

• TSO は StoreLoad だけを許します。各コアに 1本のFIFOストアバッファ があり、ストアはその順（StoreStoreは保持）でキャッシュへ出るが、後続ロードはバッファを飛び越して先に走れる、というモデルです。x86 が該当します。
• PSO はさらに StoreStore も 許します。ストアバッファがアドレスごとに分かれFIFOでなくなるイメージで、書き込み同士の順序すら保証されません。だから生産者が data を書いてから flag を立てても、消費者には flag が先に見えうる。歴史的な SPARC PSO モードが代表です。
• 弱順序 は LoadLoad・LoadStore まで含め ほぼ全方向 を許します。唯一の歯止めは アドレス依存（あるロードの結果をアドレスに使う次のロードは順序保持）。ARM/POWER/RISC-V が該当し、アーキ別の詳細は メモリバリアの種類とアーキテクチャ別の振る舞い にまとめています。

x86(TSO) でも観測される「StoreLoad の追い越し」:
  コア1: x=1; r1=y;   ← x のストアがバッファに残る間に y を読む
  コア2: y=1; r2=x;   ← 同様
  → r1==0 かつ r2==0 が成立しうる（SCでは不可能）

リリース一貫性──「同期点だけ」順序を約束する

弱順序をそのまま使うのは過酷です。そこで実用モデルが リリース一貫性（Release Consistency, RC）。発想は「普通のメモリアクセスは好きに並べ替えてよい。ただし acquire／release と印を付けた同期操作の所だけ順序を守る」というものです。

• acquire（取得）：この後ろの読み書きが、acquire より前へ出るのを禁止（後ろを止める片側の蓋）。
• release（解放）：この前の読み書きが、release より後ろへ回るのを禁止（前を止める片側の蓋）。

スレッドB の release ストアを、スレッドA の acquire ロードが観測したなら、release 以前のBの全書き込みが acquire 以降のAから必ず見える。これが happens-before を確立する release-acquire の同期 で、ロックの取得が acquire、解放が release に対応します。重要なのは、片側だけ止める一方通行ゆえ全方向フェンスより軽く、弱順序機でも臨界区間の外側は自由に最適化できる 点です。

なぜ言語メモリモデルが要るのか

ここまではハードのモデルでした。しかしアプリ開発者がハードのモデルを直接相手にするのは破綻します。理由は3つ あり、これが C++11 や Java が独自の 言語メモリモデル を定めた動機です。

1. 移植性：x86・ARM・POWER でモデルが違う以上、ハードに直接書いたコードは移植できません。言語が共通の抽象（acquire/release/seq_cst）を与え、コンパイラが各アーキの実機命令へ展開することで、1つのソースが全機で正しく動きます。
2. コンパイラも並べ替える：CPUだけでなくコンパイラも最適化で命令を動かします。ハードのフェンスはCPUしか縛らないので、言語が「コンパイラとCPUの両方を縛る」契約点 を提供しないと、最適化で同期が壊れます。
3. データ競合の定義：そもそも「何が壊れた状態か」を定義する言語が要ります。C++/Java は データ競合（data race） を「同期されない、少なくとも一方が書き込みの並行アクセス」と定め、それを起こすプログラムを 未定義動作（UB） と規定します。

その上で言語が与える最重要の保証が DRF-SC 定理 です。

まとめ──弱いハードの上で、SC という直感を取り戻す道具