代码改变世界

内存屏障保证缓存一致性

2017-12-24 15:37  v_ZSW  阅读(2811)  评论(2)  编辑  收藏  举报
 在前面内存系统重排序提到，*“写缓存没有及时刷新到内存，导致不同处理器缓存的值不一样”*，出现这种情况是糟糕的，所幸处理器遵循**缓存一致性协议**能够保证足够的可见性又不过多的损失性能。

 缓存一致性协议给缓存行（通常为64字节）定义了个状态：独占（exclusive）、共享（share）、修改（modified）、失效（invalid），用来描述该缓存行是否被多处理器共享、是否修改。所以缓存一致性协议也称MESI协议。

  • 独占（exclusive）：仅当前处理器拥有该缓存行，并且没有修改过，是最新的值。
  • 共享（share）：有多个处理器拥有该缓存行，每个处理器都没有修改过缓存，是最新的值。
  • 修改（modified）：缓存行被修改过了，需要写回主存，并通知其他拥有者 “该缓存已失效”。
  • 失效（invalid）：缓存行被其他处理器修改过，该值不是最新的值，需要读取主存上最新的值。

优化

 处理修改状态是比较耗时的操作，既要发送失效消息给其他拥有者并写回主存，还要等待其他拥有者处理失效信息，直到收到失效消息的响应。如果在这一段时间，处理器都处于空等，那是奢侈的。所以引入缓存和失效缓存来让处理器不再“等”。

存储缓存

 存储缓存（Store Buffers），也就是常说的写缓存，当处理器修改缓存时，把新值放到存储缓存中，处理器就可以去干别的事了，把剩下的事交给存储缓存。

失效队列

 处理失效的缓存也不是简单的，需要读取主存。并且存储缓存也不是无限大的，那么当存储缓存满的时候，处理器还是要等待失效响应的。为了解决上面两个问题，引进了失效队列（invalidate queue0）。

 处理失效的工作如下：

  1. 收到失效消息时，放到失效队列中去。
  2. 为了不让处理器久等失效响应，收到失效消息需要马上回复失效响应。
  3. 为了不频繁阻塞处理器，不会马上读主存以及设置缓存为invlid，合适的时候再一块处理失效队列。

引发内存重排序

 下面是处理器A、B，依次写、读内存a的时序图。A、B都缓存了a。

 可以看到即使遵守缓存一致性协议，也会有一段时间缓存不一致（①-⑥）。

 要是读取a的操作在这段时间内，那么处理器B看到的a将是0。处理器执行顺序为写a>读a，而在内存上的顺序为读a>写a，造成了重排序。重排序可能会导致不可见性，要是此时线程A、B分别在处理器A、B上执行，那么线程A执行了写操作后，线程B看不到线程A执行的结果，共享内存a不可见，改变了程序运行结果。

避免内存重排序

 引发重排序是糟糕的，可能造成共享内存不可见，改变程序结果。那么该怎么办，不进行MESI优化吗？既不能追求性能，造成重排序，也不能追求可见性（非共享数据可见是不需要的），降低性能。

 处理器还是使用提供了个武器——内存屏障指令（Memory Barrier）：

  1. 写内存屏障（Store Memory Barrier）：处理器将当前存储缓存的值写回主存，以阻塞的方式。
  2. 读内存屏障（Load Memory Barrier）：处理器处理失效队列，以阻塞的方式。

 可以看到内存屏障可以阻止内存系统重排序，保证可见性。但其开销也很大，处理器需要阻塞等待，一般应用在锁的获取和释放中。

上面那段处理器A、B，依次写、读内存a，加了内存屏障后，就不会被重排序了。

boolean finish = false;
int a = 0;

//处理器A:
a = 1;
storeMemoryBarrer(); //保证a一定在主存中，且处理器B中a为invlid
finish = true;

//处理器B:
while(!finish);
loadMemoryBarrier(); //保证缓存到a最新的值，执行后a为share
assert a == 1;

JMM中抽象内存屏障

 为了更好的理解如何实现同步的可见性，JMM抽象出了内存屏障Memory Barrier。
内存屏障