内存屏障

编译器屏障 Compiler barrier

/* The "volatile" is due to gcc bugs */
#define barrier() __asm__ __volatile__("": : :"memory") 
阻止编译器重排，保证编译程序时在优化屏障之前的指令不会在优化屏障之后执行。

 CPU屏障 CPU barrier
CPU级别内存屏障其作用有两个：
防止指令之间的重排序
保证数据的可见性
指令重排中Load和Store两种操作会有Load-Store、Store-Load、Load-Load、Store-Store这四种可能的乱序结果。

Intel为此提供三种内存屏障指令：

sfence ，实现Store Barrior 会将store buffer中缓存的修改刷入L1 cache中，使得其他cpu核可以观察到这些修改，而且之后的写操作不会被调度到之前，即sfence之前的写操作一定在sfence完成且全局可见；
lfence ，实现Load Barrior 会将invalidate queue失效，强制读取入L1 cache中，而且lfence之后的读操作不会被调度到之前，即lfence之前的读操作一定在lfence完成（并未规定全局可见性）；
mfence ，实现Full Barrior 同时刷新store buffer和invalidate queue，保证了mfence前后的读写操作的顺序，同时要求mfence之后写操作结果全局可见之前，mfence之前写操作结果全局可见；
lock 用来修饰当前指令操作的内存只能由当前CPU使用，若指令不操作内存仍然由用，因为这个修饰会让指令操作本身原子化，而且自带Full Barrior效果；还有指令比如IO操作的指令、exch等原子交换的指令，任何带有lock前缀的指令以及CPUID等指令都有内存屏障的作用。
X86-64下仅支持一种指令重排：Store-Load ，即读操作可能会重排到写操作前面，同时不同线程的写操作并没有保证全局可见，例子见《Intel® 64 and IA-32 Architectures Software Developer’s Manual》手册8.6.1、8.2.3.7节。要注意的是这个问题只能用mfence解决，不能靠组合sfence和lfence解决。（用sfence+lfence组合仅可以解决重排问题，但不能解决全局可见性问题，简单理解不如视为sfence和lfence本身也能乱序重拍）

X86-64一般情况根本不会需要使用lfence与sfence这两个指令，除非操作Write-Through内存或使用 non-temporal 指令（NT指令，属于SSE指令集），比如movntdq, movnti, maskmovq，这些指令也使用Write-Through内存策略，通常使用在图形学或视频处理，Linux编程里就需要使用GNC提供的专门的函数（例子见参考资料13：Memory part 5: What programmers can do）。

下面是GNU中的三种内存屏障定义方法，结合了编译器屏障和三种CPU屏障指令

#define lfence() __asm__ __volatile__("lfence": : :"memory") 
#define sfence() __asm__ __volatile__("sfence": : :"memory") 
#define mfence() __asm__ __volatile__("mfence": : :"memory") 
代码中仍然使用lfence()与sfence()这两个内存屏障应该也是一种长远的考虑。按照Interface写代码是最保险的，万一Intel以后出一个采用弱一致模型的CPU，遗留代码出问题就不好了。目前在X86下面视为编译器屏障即可。

GCC 4以后的版本也提供了Built-in的屏障函数__sync_synchronize()，这个屏障函数既是编译屏障又是内存屏障，代码插入这个函数的地方会被安插一条mfence指令。

GCC 内置__sync_synchronize函数：屏障（内置同步）将简单地转换为硬件屏障，如果您使用的是 x86，则可能是栅栏（mfence/sfence）操作，或者其他架构中的等效物。CPU 也可能在运行时做各种优化，最重要的是实际上是乱序执行操作——这条指令告诉它确保加载或存储不能通过这一点，必须在正确的一侧观察同步点。

C++11为内存屏障提供了专门的函数std::atomic_thread_fence，方便移植统一行为而且可以配合内存模型进行设置，比如实现Acquire-release语义：

#include <atomic>
std::atomic_thread_fence(std::memory_order_acquire);
std::atomic_thread_fence(std::memory_order_release);

摘自：https://zhuanlan.zhihu.com/p/43526907，有删改。

参考：

1. C/C++ Volatile关键词深度剖析
2. java的并发关键字volatile
3. 指令重排序
4. 多处理器编程：从缓存一致性到内存模型
5. 聊聊原子变量、锁、内存屏障那点事
6. Why Memory Barriers？中文翻译（上）
7. LINUX内核内存屏障
8. Memory Model: 从多处理器到高级语言
9. 高并发编程--多处理器编程中的一致性问题(上)
10. 高并发编程--多处理器编程中的一致性问题(下)
11. 如何理解C++11中的六种内存模型
12. C/C++11 mappings to processors
13. When should I use _mm_sfence _mm_lfence and _mm_mfence
14. Why is (or isn't?) SFENCE + LFENCE equivalent to MFENCE?
15. Memory part 5: What programmers can do
16. Memory Reordering Caught in the Act
17. C++ and the Perils of Double-Checked Locking
18. 内存模型
19. UNIX多线程环境下屏障功能（barrier）浅析