考虑下面一段代码，假设我们实现了int的原子操作。两个函数分别在独立的线程运行（同一进程），那么打印的a值会是多少呢？
atomic<int> a;
atomic<int> b;
int thread_1(){
int t = 1;
a = t;
b = 2;
}
int thread_2{
while(b != 2);
cout << a << endl;
}
结论是打印a的值有时会为0.
所见并非所得
看不见的左手
对于上面的代码，或有类似的伪指令如下：
- Loadi reg3,1
- Move reg4,reg3
- Store reg4,a
- Loadi reg5,2
- Store reg5,b
按照通常的理解，CPU会按照1->2->3->4->5的顺序执行，也就是强顺序的内存模型，即strong ordered.在这种情况下，的确a的打印值永远是1。但现代CPU为了性能的提升，采用的流水线技术，为了进一步挖掘指令中的并行性，会打乱顺序执行。此例中，指令<1，2，3>和<4，5>使用了不同的寄存器和内存地址，一些处理器就有可能将指令执行的顺序打乱。比如1->4->2->5->3。如果是这个指令顺序的话，也就是弱顺序的内存模型，即weak ordered.
指令5提前于指令3，导致a的赋值落后与b等于2.
看不见的右手
当然，不仅仅是CPU会发现代码中的并行因素，编译器也是这方面的一把好手，它也会主动发现可以优化的地方，并将指令前后移动，已获得最佳的指令排列。
传统的解决方案
如何解决这种意外呢，答案就是使用内存栅栏(memory barrier)。比如上面的例子，可以在3和4中插入内存栅栏来保证代码的顺序执行。
在使用gcc编译的C++98项目中，部分高度优化的代码使用
asm volatile("" ::: "memory");来插入内存栅栏使得执行顺序按照程序员指定的顺序完成。
C++11的解决方案
在C++11中，设计者给出的解决方式是让程序员来指定内存顺序，共计6种
| 枚举值 | 规则 |
|---|---|
| memory_order_relaxed | 不对执行顺序做任何保证 |
| memory_order_consume | 本线程所有后续有关本操作的必须在本操作完成后执行 |
| memory_order_acquire | 本线程所有后续的读操作必须在本条操作完成才能执行 |
| memory_order_release | 本线程所有之前的写操作完成后才执行本操作 |
| memory_order_acq_rel | 同时包含acquire和release |
| memory_order_seq_cst | 全部顺序执行 |
按照原子操作的类型，可分为三种,每种可用的类型如下：
- 存储操作(store)
- relaxed
- release
- seq_cst
- 读取操作(load)
- relaxed
- consume
- acquire
- seq_cst
- RMW操作(read-modify-write)
- all
优化后的代码
通过让一部分操作松散，一部分顺序顺序约束，如果我们期望a的值永远是1，那么可以借用C++11中的机制来最大性能的优化：
int thread_1(){
int t = 1
a.store(t,memory_order_relaxed);
b.store(2,memory_order_release);
}
int thread_2(){
while(b.load(memory_order_acquire) != 2);
cout << a.load(memory_order_relaxed);
}
总结
C++11提供了很多内存顺序的设计，程序员可以用来最大限度的提高并发性，但对于并行编程来讲，最根本的还是思考如何将大量的计算按需分解成多个独立、能同时运行的部分，找出真正需要共享的数据，实现为原子类型。否则强行使用内存模型优化，可能收效甚微，甚至适得其反。
