Store Buffer
当cpu需要的数据在其他cpu的cache内时，需要请求，并且等待响应，这显然是一个同步行为，优化的方案也很明显，采用异步。
思路大概是在cpu和cache之间加一个store buffer，cpu可以先将数据写到store buffer，同时给其他cpu发送消息，
然后继续做其它事情，等到收到其它cpu发过来的响应消息，再将数据从store buffer移到cache line。
该方案逻辑上有漏洞，需要细化，我们来看几个漏洞。比如有如下代码:
// 初始状态下，假设a，b值都为0，并且a存在cpu1的cache line中(Shared状态)， a = 1; b = a + 1; assert(b == 2);
cpu0 要写入a，将a=1写入store buffer，并发出Read Invalidate消息，继续其他指令。
cpu1 收到Read Invalidate，返回Read Response(包含a=0的cache line)和Invalidate ACK，cpu0 收到Read Response，更新cache line(a=0)。
cpu0 开始执行b=a+1，此时cache line中还没有加载b，于是发出Read Invalidate消息，从内存加载b=0，
同时cache line中已有a=0，于是得到b=1，状态为Modified状态。
cpu0 得到 b=1，断言失败。
cpu0 将store buffer中的a=1推送到cache line，然而为时已晚。
造成这个问题的根源在于对同一个cpu存在对a的两份拷贝，一份在cache，一份在store buffer，而cpu计算b=a+1时，a和b的值都来自cache。
仿佛代码的执行顺序变成了这个样子：
b = a + 1; a = 1; assert(b == 2);
Store Forwarding
store buffer可能导致破坏程序顺序的问题，硬件工程师在store buffer的基础上，又实现了”store forwarding”技术:，
cpu可以直接从store buffer中加载数据，即支持将cpu存入store buffer的数据传递(forwarding)给后续的加载操作，而不经由cache。
但是在高并发场景下仍然存在漏洞，示例如下:
// 初始状态下，假设a，b值都为0，a存在于cpu1的cache中，b存在于cpu0的cache中，均为Exclusive状态，cpu0执行foo函数，cpu1执行bar函数 void foo() { a = 1; b = 1; } void bar() { while (b == 0) continue; assert(a == 1) }
cpu1执行while(b == 0)，由于cpu1的Cache中没有b，发出Read b消息
cpu0执行a=1，由于cpu0的cache中没有a，因此它将a(当前值1)写入到store buffer并发出Read Invalidate a消息
cpu0执行b=1，由于b已经存在在cache中，且为Exclusive状态，因此可直接执行写入
cpu0收到Read b消息，将cache中的b(当前值1)返回给cpu1，将b写回到内存，并将cache Line状态改为Shared
cpu1收到包含b的cache line，结束while (b == 0)循环
cpu1执行assert(a == 1)，由于此时cpu1 cache line中的a仍然为0并且有效(Exclusive)，断言失败
cpu1收到Read Invalidate a消息，返回包含a的cache line，并将本地包含a的cache line置为Invalid，然而已经为时已晚。
cpu0收到cpu1传过来的cache line，然后将store buffer中的a(当前值1)刷新到cache line
出现这个问题的原因在于cpu不知道a, b之间的数据依赖，cpu0对a的写入需要和其他cpu通信，因此有延迟，
而对b的写入直接修改本地cache就行，因此b比a先在cache中生效，导致cpu1读到b=1时，a还存在于store buffer中。
从代码的角度来看，foo函数似乎变成了这个样子:
void foo() { b = 1; a = 1; }
foo函数的代码，即使是store forwarding也阻止不了它被cpu"重排"，虽然这并没有影响foo函数的正确性，但会影响到所有依赖foo函数赋值顺序的线程。