C++のフェンス is 何 in Practice

C++メモリモデルにおけるフェンス(fence) とハードウェア・メモリバリア命令との対応関係についてメモ。

まとめ：

atomic_thread_fence＝コンパイル時の並び替え禁止＋メモリバリア命令発行（実行時の並び替え禁止）
atomic_signal_fence＝コンパイル時の並び替え禁止のみ
C++標準ライブラリ提供のフェンス関数と、発行すべきメモリバリア命令セマンティクスとの対応は下表の通り。コンパイラによる並び替え禁止では、各メモリバリア命令と同じ制約をソースコードレベルで適用する。

memory_order	#LoadStore	#LoadLoad	#StoreStore	#StoreLoad
relaxed
acquire*1	○	○
release	○		○
acq_rel	○	○	○
seq_cst	○	○	○	○

例）acquireフェンスは#LoadStore＋#LoadLoad並び替えを禁止、つまり該当フェンスに先行するload操作と同フェンスに続くload/store操作との並び替えを禁止する。*2

ノート：この対応表は、該当フェンスが要請するセマンティクスを満足するために、少なくとも禁止すべき並び替えを表している。対象プロセッサのハードウェア・メモリモデルによっては、追加操作なしに並び替え禁止が暗黙保証されるケース（例：x86 のような “強い” メモリモデル）や、命令セット・アーキテクチャ(ISA)設計によっては、細分化かつ直交したメモリバリア命令を提供しないケース（例：PowerPC では lwsync, hwsync(sync) 命令の2段階）もある。アーキテクチャ別の対応表は "C/C++11 mappings to processors" 参照。

現行C++11メモリモデルのフェンス・プリミティブはN2633で提案され、その後N2731で関数名が現行のものに変更された。これ以前のDraftでは、フェンス操作＝特殊なグローバルオブジェクトに対するatomic操作*3と定義していた。

The motivation for having fence primitives in C++ is fourfold:

It's hard to port existing code that is written for a specific fence-based architecture to the C++ acquire/release memory model. We want C++ to provide a way for rewriting such code in a manner that increases portability without sacrificing efficiency.

Some programmers may be familiar with a fence-based memory model and, ideally, we want to help them be immediately productive in C++.

In many real-world cases, the programmer knows exactly what sequence of instructions he wants to produce on the target hardware. We want to enable these programmers to achieve their goals while still writing portable code. (Stated simply, we want the programmer to be able to emit a lwsync instruction without sacrificing portability and theoretical correctness.)

There are situations in which a fence-based formulation on the source level leads to more efficient code.

N2633 Improved support for bidirectional fences

Changes from N2633

Renamed atomic_memory_fence to atomic_thread_fence.

Renamed atomic_compiler_fence to atomic_signal_fence.

(snip)

N2731 Proposed Text for Bidirectional Fences

理論と実践のギャップ

C++メモリモデルとハードウェア・メモリモデルとでは、ルールの適用対象・構成要素・表現方法が異なる。

C++メモリモデル: C++ソースコードのコンパイル時と実行時に対して、メモリアクセス間の「順序性」によってルールを定義する。この順序性は、atomic変数のacquire操作／release操作ペアまたは relaxed操作＋フェンス関数のペア*4 により表現する。
ハードウェア・メモリモデル: 機械語命令列の実行時に対して、メモリアクセス操作順入れ替えの “許容度合い” によってルールを定義する*5。メモリバリア命令の発行により、メモリアクセス入れ替えの禁止を表現する。*6

C++11標準ライブラリが提供するstd::atomic_thread_fence関数は、atomic変数アクセスに対してのみ意味をもつ。通常の非atomic変数には直接的な影響を与えない（間接的には影響を与えうる）。

C++の文脈における「フェンス(fence)」は、言語仕様を記述する仮想機械(abstract machine)上の同期プリミティブにすぎない。フェンス同士またはフェンス＋atomic変数操作間で「happens before関係」が定義され、直接的にはそれ以上の効果を持たない。

上記より、具体的なアーキテクチャ／コンパイラが提供するメモリバリア(memory barrier)とは解釈が異なる（ことが一般的なはず）。

C++のフェンス is 何

C++標準ライブラリのフェンス関数は、既存アーキテクチャのメモリバリア命令で制御されるハードウェア・メモリモデルを、acquire−release関係*7に基づき定義されるC++メモリモデルに統合*8する目的で導入された。特定ハードウェア上の双方向フェンス（メモリバリア命令）を用いて記述された既存コードから、C++標準ライブラリ／非seq_cstなatomic変数へのソースコード移植性を考慮し、特定のオブジェクトに紐付かない非メンバ関数として定義される。このためフェンス・プリミティブの動作セマンティクスは、メモリアクセス＋双方向フェンスに基づくハードウェア・メモリモデルでの定義から、C++メモリモデル／仮想機械上のacquire−release関係へとマッピングしたものとなる（はず）。

yohhoyの日記

技術的メモをしていきたい日記

C++のフェンス is 何 in Practice

理論と実践のギャップ