Memory ordering

These barriers prevent a compiler from reordering instructions during compile time – they do not prevent reordering by CPU during runtime.

• The GNU inline assembler statement

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

or even

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

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

• The C11/C++11 function

atomic_signal_fence(memory_order_acq_rel);

forbids the compiler to reorder read and write commands around it.[2]

• Intel ICC compiler uses "full compiler fence"

__memory_barrier()

intrinsics.[3][4]

• Microsoft Visual C++ Compiler:[5]

_ReadWriteBarrier()

In many programming languages different types of barriers can be combined with other operations (like load, store, atomic increment, atomic compare and swap), so no extra memory barrier is needed before or after it (or both). Depending on a CPU architecture being targeted these language constructs will translate to either special instructions, to multiple instructions (i.e. barrier and load), or to normal instruction, depending on hardware memory ordering guarantees.

There are several memory-consistency models for SMP systems:

• Sequential consistency (all reads and all writes are in-order)
• Relaxed consistency (some types of reordering are allowed)
  • Loads can be reordered after loads (for better working of cache coherency, better scaling)
  • Loads can be reordered after stores
  • Stores can be reordered after stores
  • Stores can be reordered after loads
• Weak consistency (reads and writes are arbitrarily reordered, limited only by explicit memory barriers)

On some CPUs

• Atomic operations can be reordered with loads and stores.[6]
• There can be incoherent instruction cache pipeline, which prevents self-modifying code from being executed without special instruction cache flush/reload instructions.
• Dependent loads can be reordered (this is unique for Alpha). If the processor fetches a pointer to some data after this reordering, it might not fetch the data itself but use stale data which it has already cached and not yet invalidated. Allowing this relaxation makes cache hardware simpler and faster but leads to the requirement of memory barriers for readers and writers.[7]. On Alpha hardware (like multiprocessor Alpha 21264 systems) cache line invalidations sent to other processors are processed in lazy fashion by default, unless requested explicitly to be processed between dependent loads. The Alpha architecture specification also allows other forms of dependent loads reordering, for example using speculative data reads ahead of knowing the real pointer to be dereferenced.

RISC-V memory ordering models:

WMO

Weak memory Order (default)

TSO

Total store order (only supported with the Ztso extension)

SPARC memory ordering modes:

TSO

Total store order (default)

RMO

Relaxed-memory order (not supported on recent CPUs)

PSO

Partial store order (not supported on recent CPUs)

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

• x86, x86-64

lfence (asm), void _mm_lfence(void)
sfence (asm), void _mm_sfence(void)[11]
mfence (asm), void _mm_mfence(void)[12]

• PowerPC

sync (asm)

• MIPS

sync (asm)

• Itanium

mf (asm)

• POWER

dcs (asm)

• ARMv7[13]

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

Some compilers support builtins that emit hardware memory barrier instructions:

• GCC,[14] version 4.4.0 and later,[15] has __sync_synchronize.
• Since C11 and C++11 an atomic_thread_fence() command was added.
• The Microsoft Visual C++ compiler[16] has MemoryBarrier().
• Sun Studio Compiler Suite[17] has __machine_r_barrier, __machine_w_barrier and __machine_rw_barrier.