CPU缓存一致性原理解释MESI协议

　　一些常识
　　CPU CL
　　CPU不能直接访问内存（write-back内存模型，也是主流模型），必须通过L1-L3才能访问到内存（具体执行是L3环形总线）; CPU访问内存的粒度（write-back模型）——cacheline，是以64字节为一块来访问的，跟os中页的概念类似，为了节约带宽；（原因参考CPU的时空局部性原理解释） L3 cache实际上兼有总线的功能——可以用来传递 数据  与消息  ——叫做环形互联——MESI——x86_64的缓存一致性协议就是在这个层面实现；同一个CL在CPU中会有多分拷贝，不同层与不同核都有多个副本；如图中 C1  会存在在L3-L1每层中，而不同核心因为多线程访问也会有副本；但尽管有这么多副本，他们都代表同一块虚拟内存空间；这篇文章要讨论的缓存一致性协议在X86_64构架下叫做 MESI  协议。什么是MESIMESI是4个单词的缩写： M-modified  （修改的），E-exclusive  （独占的），S-shared  （共享的）以及I-invalid  （失效的）。而对于MESI需要了解的头等大事是：MESI是用来控制CL 同步  的协议。我们从上图可以看到，在SMP多核多线程访问共享变量的情况下，同一块虚拟内存地址映射的CL会存在在不同CPU core中，那么它们的读写必然会产生同步问题，就跟高级语言中的多线程同步一样。 public class shutDownThread implements Runnable {     volatile int shutDownRequested;     volatile int counter;     public void shutDown(){         shutDownRequested = true;     }     @Override     public void run() {         while (!shutDownRequested) {             System.out.println(counter++);         }     } }   public class Demo01 {     public static void main(String[] args) throws InterruptedException {         Thread[] th = new Thread[10];         shutDownThread t = new shutDownThread();         for(int i=0;i<=9;i++){             th[i] = new Thread(t);             th[i].start();         }         Thread.sleep(1000);         t.shutDown();     } }
　　借用一下这段经典的程序说明下为什么缓存行存在同步问题： Thread1将共享变量 counter  从内存加载进入core1核心的C1缓存行；然后Thread2也将 counter  从内存加载进入core2核心的C1缓存行；Thread1对 counter  加1，然后将C1写回；此时内存中counter  为1；Thread2也对 counter  加1，接着写回C1，此时内存counter  还是1；而我们想让Thread1与Thread2合作，将 counter  加到2改怎么做？对，进行同步才行，所以CPU也会有这个同步的问题，事实上只要是对共享变量有多个计算单元进行操作，都会产生同步问题，JVM的锁工作在高层，粒度更粗；而CPU的多核同步机制工作在底层，粒度更小而已机制都是一样的。多说一点，上面这段代码在有MESI的情况下也不能实现线程同步，原因是 counter++  这条语句看上去只有一句，但是对于CPU至少有三条：mov [counter] eax; //加载counter从内存到寄存器（这条mov还会继续分解成操作CL的微指令） add 1 eax  //+1 mov eax [counter] //写回操作
　　可见 counter++  在执行的过程中，可能会被打断（比如时钟中断）造成不可能是原子的。这时，你可能会问MESI  的作用是啥？如果java可以写汇编，只要将 counter++  改成lock inc [counter]  就能立马变成原子操作了，这就是MESI协议在做影响。有兴趣的朋友可以试试看（intel x86 cpu哦)这里给个C++的实现，没有用到C++的任何锁，但是用汇编调起CPU原子锁来做同步： #include  #include  #include   const int TC = 4; int count = 0; bool flag = true; void inc_count() {     asm(＂movl   $1, %eax＂);     asm(＂LOCK addl %eax,count(%rip)＂); //count是个寄存器相对寻址。lock prefix是CPU原子指令。 } void testRun() {     for(int i=0; i<10000;i++)     {         inc_count();     } }  int main() {     std::thread threads[TC]; // 默认构造线程     for (int i = 0; i < TC; ++i)     {         threads[i] = std::thread(testRun); // move-assign threads     }      std::this_thread::sleep_for(std::chrono::seconds(1));     std::cout << ＂main thread id:＂ << std::this_thread::get_id() << std::endl;     flag = false;     for (auto &thread : threads)     {         thread.join();     }      std::cout << ＂All threads joined!＂               << ＂ count:＂ << count<同步->flush  的任务都委托给store buffer  ，自己就可以异步地执行下一条指令了；提高了系统的吞吐量；当core2接收到 busWr  后，不会直接到处理引擎，而是先将消息缓存到invalidate queue  里面，紧接着就发送ack  给core1，提高吞吐量；此时core2的CL还没有变成I  状态，但是等invalidate queue  处理完成，最终会变成I  ，中间会有个延迟。缺点Store buffer：导致数据实际更新时间比数据更新到内存要早；也就是 内存数据更新出现了延迟 ； Invalidation queue：core实际感受到数据失效的时间延迟了，也就是 数据可见性延迟了 。 当然，在大部分时间不会有什么问题，只会感觉到系统性能提高了，但是在某些极端情况，比如：多线程，高并发的场景下因为延迟加大，所以就不能忽略了。要修正这个bug又要获得效率就是大名鼎鼎的——内存屏障干的事了。 总结MESI是缓存行一致性协议，有了这个协议，多核CPU可以实现核间高速的 原子指令  与数据共享  ；理论上一份内存数据只要load到CPU一次，即可通过MESI协议实现多核数据共享，提高了吞吐量； 缓存行  在高并发、高性能程序设计中影响巨大，后面通过单独章节详细聊聊缓存行的结构与原理；Store buffer  与Invalidate Queues  是MESI协议的副作用——导致内存屏障技术出现的根本原因。后面章节会单独讨论CPU中的原子指令与内存屏障  。原子指令  是实现高层锁机制的基础，它的性能直接影响到了操作系统与用户程序的性能，在并发激烈或者对性能要求非常苛刻的操作系统中尤其突出。例如著名的spinlock自旋锁的性能问题，x86就因为MESI  协议在core的数量不断增大的情况下，通过L3环形互联发送的消息指数增长，而修改单个CL会导致大量的同步消息发布到互联总线，产生了著名的惊群  问题，性能也会急剧下降。这直接使得Linux这种非常看重扩展性  的操作系统非常不满  ，RCU这种真正的无锁  黑科技正式诞生，成为linux一个重要的子系统。后面在讲述Linux的同步机制  章节详细展开讨论。参考「链接」——MESI又叫做伊利诺伊同步协议 头条专栏：简一说道的《高性能编程必备计算机硬件知识》 补充重排序
　　CPU为了提高执行效率与指令的吞吐量，发明了很多黑科技其中 指令重排序  就是一个，而指令重排序中有一个就是Store buffer与Invalid queue  的副作用导致的。store buffer  会导致当前的store指令（修改CL的指令）延后执行，相当于这条store指令往后挪了；invalidation queue  会导致读取到老的值，也就是load指令前移了。
　　还有哪些重排序？ 分支预测 编译器重排序
　　这里给我们了一个重要的启示：任何优化都是双刃剑，有好的一面就一定有副作用，做工程最重要的工作就是做好平衡，只要平衡得好就是好的产品，不要什么都想要，结果一塌糊涂。
　　比如：MESI协议因为有了 Store buffer  与Invalidation Queue  加快了速度，但是在大并发的多线程程序下可能出现指令重排序的bug，造成程序状态紊乱；这时就要开发屏障指令来弥补。但是屏障指令的弥补肯定会抵消掉一部分Store buffer  带来的提升。但是这种平衡是可取的，因为多核多线程的目的就是提高CPU的并行  能力，这部分的收益足以承担屏障指令带来的损耗，整体来看是个好的设计。同样的道理也可以适用于分支预测与编译器重排序这两种提高性能的方式。 好了，完毕！