利用者:ぺお/sandbox

ここはぺおさんの利用者サンドボックスです。編集を試したり下書きを置いておいたりするための場所であり、百科事典の記事ではありません。ただし、公開の場ですので、許諾されていない文章の転載はご遠慮ください。

登録利用者は自分用の利用者サンドボックスを作成できます（サンドボックスを作成する、解説）。

実行時メモリオーダリング

SMPにはいくつかのメモリ一貫性モデルが存在する：

逐次一貫性（すべての読み込みと書き込みは順番通りに実行される）
緩い一貫性（いくつかのリオーダリングが許される）
- 読み込みが他の読み込みの後に並び替えられる（キャッシュコヒーレンシやスケーラビリティのため）
- 読み込みが書き込みの後に並び替えられる
- 書き込みが他の書き込みの後に並び替えられる
- 書き込みが読み込みの後に並び替えられる
弱い一貫性（明示的なメモリバリアによる制限を除けば、読み込みと書き込みの任意の並び替えが可能）

いくつかのCPUでは、

読み書き命令があると不可分操作がリオーダするかもしれない。
一貫性のない命令キャッシュパイプラインがありえる。その場合、命令キャッシュのフラッシュ/再読み込みといった特殊な命令なしには自己書き換えコードが動かない。
依存関係のあるデータ読み込みもリオーダするかもしれない（Alpha固有）。プロセッサがあるデータへのポインタを読み込んだときでも、そのポインタが指す正しいデータではなく、すでにキャッシュされてまだ無効になっていない古いデータをフェッチするかもしれない。この緩いリオーダリングを許すことで、ハードウェアはシンプルで高速になるが、読み込み側と書き込み側の両方でメモリバリアが必要になる。^[1]

Memory ordering in some architectures^[2]^[3]
Type	Alpha	ARMv7	PA-RISC	POWER	SPARC RMO	SPARC PSO	SPARC TSO	x86	x86 oostore	AMD64	IA-64	zSeries
Loads reordered after loads	Template:Bad	Template:Bad	Template:Bad	Template:Bad	Template:Bad				Template:Bad		Template:Bad
Loads reordered after stores	Template:Bad	Template:Bad	Template:Bad	Template:Bad	Template:Bad				Template:Bad		Template:Bad
Stores reordered after stores	Template:Bad	Template:Bad	Template:Bad	Template:Bad	Template:Bad	Template:Bad			Template:Bad		Template:Bad
Stores reordered after loads	Template:Bad	Template:Bad	Template:Bad	Template:Bad	Template:Bad	Template:Bad	Template:Bad	Template:Bad	Template:Bad	Template:Bad	Template:Bad	Template:Bad
Atomic reordered with loads	Template:Bad	Template:Bad		Template:Bad	Template:Bad						Template:Bad
Atomic reordered with stores	Template:Bad	Template:Bad		Template:Bad	Template:Bad	Template:Bad					Template:Bad
Dependent loads reordered	Template:Bad
Incoherent instruction cache pipeline	Template:Bad	Template:Bad		Template:Bad	Template:Bad	Template:Bad	Template:Bad	Template:Bad	Template:Bad		Template:Bad	Template:Bad

Some older x86 and AMD systems have weaker memory ordering^[4]

SPARC memory ordering modes:

「Memory barrier」も参照

These barriers prevent a compiler from reordering instructions, they do not prevent reordering by CPU.

asm volatile("" ::: "memory");

or even

__asm__ __volatile__ ("" ::: "memory");

forbids GCC compiler to reorder read and write commands around it.^[5]

__memory_barrier()

intrinsics.^[6]^[7]

_ReadWriteBarrier()

Many architectures with SMP support have special hardware instruction for flushing reads and writes.

lfence (asm), void_mm_lfence(void)
sfence (asm), void_mm_sfence(void)^[9]
mfence (asm), void_mm_mfence(void)^[10]

sync (asm)

sync (asm)

mf (asm)

dcs (asm)

dmb (asm)
dsb (asm)
isb (asm)

Some compilers support builtins that emit hardware memory barrier instructions:

GCC,^[12] version 4.4.0 and later,^[13] has __sync_synchronize.
The Microsoft Visual C++ compiler^[14] has MemoryBarrier().
Sun Studio Compiler Suite^[15] has __machine_r_barrier, __machine_w_barrier and __machine_rw_barrier.