转自
https://www.cnblogs.com/the-tops/p/6347584.html
编译时memory moder：https://preshing.com/20120625/memory-ordering-at-compile-time/
强弱memory order：https://preshing.com/20120930/weak-vs-strong-memory-models/
https://preshing.com/20120710/memory-barriers-are-like-source-control-operations/
acquire/release: https://preshing.com/20120913/acquire-and-release-semantics/
看这篇文章：https://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
看这篇文章 ： https://preshing.com/20140709/the-purpose-of-memory_order_consume-in-cpp11/
https://preshing.com/20130823/the-synchronizes-with-relation/
https://preshing.com/20130618/atomic-vs-non-atomic-operations/
https://github.com/preshing/ConsumeDemo
编译时的：1. volatile关键字： volatile int counter;
2. __asm__ volatile("" : : : "memory");
关于memory_order这个概念，非常的令人困惑。其关键就是atomic能够保证单个的操作的原子性，但不能保证两个原子操作之间的顺序，这涉及到CPU对缓存刷新时进行的顺序重排。这里看两个简单的例子就可以理解
和我们平时的理解完全不一样，内存的修改顺序和实际的顺序居然可能不一致，这就是为什么会引入memory_order这个概念了。
作者：码农苍耳
链接：https://www.jianshu.com/p/83f75ce281a2
2.1 Sequentially Consistent
该模型是最强的同步模式，参数表示为std::memory_order_seq_cst，同时也是默认的模型。
-Thread 1- -Thread2-
y = 1if(x.load() ==2)
x.store (2); assert (y ==1)
对于上面的例子，即使x和y是不相关的，通常情况下处理器或者编译器可能会对其访问进行重排，但是在seq_cst模式下，x.store(2)之前的所有memory accesses都会happens-before在这次store操作。
另外一个角度来说：对于seq_cst模式下的操作，所有memory accesses操作的重排不允许跨域这个操作，同时这个限制是双向的。
2.2 Acquire/Release
查看下面的典型Acquire/Release的使用例子：
std::atomic<int> a{0};
intb =0;
-Thread 1-
b = 1;
a.store(1, memory_order_release);
-Thread 2-
while(a.load(memory_order_acquire) !=1)/*waiting*/;
std::cout<< b <<'
';
毫无疑问，如果是seq_cst，那么上面的操作一定是成功的(打印变量b显示为1)。
a. memory_order_release保证在这个操作之前的memory accesses不会重排到这个操作之后去，但是这个操作之后的memory accesses可能会重排到这个操作之前去。通常这个主要是用于之前准备某些资源后，通过store+memory_order_release的方式”Release”给别的线程；
b. memory_order_acquire保证在这个操作之后的memory accesses不会重排到这个操作之前去，但是这个操作之前的memory accesses可能会重排到这个操作之后去。通常通过load+memory_order_acquire判断或者等待某个资源，一旦满足某个条件后就可以安全的“Acquire”消费这些资源了。
2.3 Consume
这是一个相比Acquire/Release更加宽松的内存模型，对非依赖的变量也去除了happens-before的限制，减少了所需同步的数据量，可以加快执行的速度。
-Thread 1-
n = 1
m = 1
p.store (&n, memory_order_release)
-Thread 2-
t = p.load (memory_order_acquire);
assert( *t == 1&& m ==1);
-Thread 3-
t = p.load (memory_order_consume);
assert( *t == 1&& m ==1);
线程2的assert会pass，而线程3的assert可能会fail，因为n出现在了store表达式中，算是一个依赖变量，会确保对该变量的memory access会happends-before在这个store之前，但是m没有依赖关系，所以不会同步该变量，对其值不作保证。
Comsume模式因为降低了需要在硬件之间同步的数量，所以理论上其执行的速度会比之上面的内存模型块一些，尤其在共享内存大规模数据量情况下，应该会有较明显的差异表现出来。
在这里，Acquire/Consume~Release这种线程间同步协作的机制就被完全暴露了，通常会形成Acquired/Consume来等待Release的某个状态更新。需要注意的是这样的通信需要两个线程间成对的使用才有意义，同时对于没有使用这个内存模型的第三方线程没有任何作用效果。
2.4 Relaxed
最宽松的模式，memory_order_relaxed没有happens-before的约束，编译器和处理器可以对memory access做任何的re-order，因此另外的线程不能对其做任何的假设，这种模式下能做的唯一保证，就是一旦线程读到了变量var的最新值，那么这个线程将再也见不到var修改之前的值了。
这种情况通常是在需要原子变量，但是不在线程间同步共享数据的时候会用，同时当relaxed存一个数据的时候，另外的线程将需要一个时间才能relaxed读到该值，在非缓存一致性的构架上需要刷新缓存。在开发的时候，如果你的上下文没有共享的变量需要在线程间同步，选用Relaxed就可以了。