关于C++memory_order的理解

看了c++并发编程实战的内存模型部分后，一直对memory_order不太懂，今天在知乎发现了百度的brpc，恰好有关于原子操作的文档，感觉解释的很好。为了加深理解，再次总结一遍。

在多核编程中，我们使用锁来避免多个线程修改同一个数据时产生的竞争条件。但是，锁会消耗系统资源，当锁成为性能瓶颈的时候，就需要使用另一种方法——原子指令。c++11中引入了原子类型atomic。

但仅靠原子指令实现不了对资源的访问控制。这造成的原因是编译器和cpu实施了重排指令，导致读写顺序会发生变化，只要不存在依赖，代码中后面的指令可能会被放在前面，从而先执行它。cpu这么做是为了尽量塞满每个时钟周期，在单位时间内尽量执行更多的指令，从而提高吞吐率。

下面看个例子：

// thread 1
// ready was initialized to false
p.init();
ready = true;

// thread 2
if(ready) {
  p.bar();
}

线程2在ready为true的时候会访问p，对线程1来说，如果按照正常的执行顺序，那么p先被初始化，然后在将ready赋为true。但对多核的机器而言，情况可能有所变化：

线程1中的ready = true可能会被cpu或编译器重排到p.init()的前面，从而优先执行ready = true这条指令。在线程2中，p.bar()中的一些代码可能被重排到if(ready)之前。
即使没有重排，ready和p的值也会独立地同步到线程2所在核心的cache，线程2仍然可能在看到ready为true时看到未初始化的p。

为了解决这个问题，cpu和编译器提供了memory fence，让用户可以声明访存指令的可见性关系，c++11总结为以下memory order：

有了memoryorder，我们可以这么改上面的例子：

// Thread1
// ready was initialized to false
p.init();
ready.store(true, std::memory_order_release);

// Thread2
if (ready.load(std::memory_order_acquire)) {
    p.bar();
}

线程2中的acquire和线程1的release配对，确保线程2在看到ready==true时能看到线程1 release之前所有的访存操作。

注意，memory fence不等于可见性，即使线程2恰好在线程1在把ready设置为true后读取了ready也不意味着它能看到true，因为同步cache是有延时的。memory fence保证的是可见性的顺序：“假如我看到了a的最新值，那么我一定也得看到b的最新值”。

关于c++11 memory order的理解