内存屏障是什么_技术

　　内存屏障，也称内存栅栏，内存栅障，屏障指令等，是一类同步屏障指令，是CPU或编译器在对内存随机访问的 *** 作中的一个同步点，使得此点之前的所有读写 *** 作都执行后才可以开始执行此点之后的 *** 作。

　　大多数现代计算机为了提高性能而采取乱序执行，这使得内存屏障成为必须。

　　语义上，内存屏障之前的所有写 *** 作都要写入内存；内存屏障之后的读 *** 作都可以获得同步屏障之前的写 *** 作的结果。因此，对于敏感的程序块，写 *** 作之后、读 *** 作之前可以插入内存屏障。

　　内存屏障的分类：

　　1.编译器引起的内存屏障

　　2.缓存引起的内存屏障

　　3.乱序执行引起的内存屏障

　　1、编译器引起的内存屏障：

　　我们都知道，从寄存器里面取一个数要比从内存中取快的多，所以有时候编译器为了编译出优化度更高的程序，就会把一些常用变量放到寄存器中，下次使用该变量的时候就直接从寄存器中取，而不再访问内存，这就出现了问题，当其他线程把内存中的值改变了怎么办？也许你会想，编译器怎么会那么笨，犯这种低级错误呢！是的，编译器没你想象的那么聪明！让我们看下面的代码：（代码摘自《独辟蹊径品内核》）

　　int flag=0;

　　void wait（）{

　　while （ flag == 0 ）

　　sleep（1000）;

　　。。。。。。

　　}

　　void wakeup（）{

　　flag=1;

　　}

　　这段代码表示一个线程在循环等待另一个线程修改flag。 Gcc等编译器在编译的时候发现，sleep（）不会修改flag的值，所以，为了提高效率，它就会把某个寄存器分配给flag，于是编译后就生成了这样的伪汇编代码：

　　void wait（）{

　　movl flag， %eax;

　　while （ %eax == 0）

　　sleep（1000）;

　　}

　　这时，当wakeup函数修改了flag的值，wait函数还在傻乎乎的读寄存器的值而不知道其实flag已经改变了，线程就会死循环下去。由此可见，编译器的优化带来了相反的效果！

　　但是，你又不能说是让编译器放弃这种优化，因为在很多场合下，这种优化带来的性能是十分可观的！那我们该怎么办呢？有没有什么办法可以避免这种情况？答案必须是肯定的，我们可以使用关键字volaTIle来避免这种情况。

　　volaTIle int flag = 0;

　　这样，我们就能避免编译器把某个寄存器分配给flag了。

　　好，上面所描述这些，就叫做“编译器优化引起的内存屏障”，是不是懂了点什么？再回去看看概念？

　　2、缓存引起的内存屏障

　　好，既然寄存器能够引起这样的问题，那么缓存呢？我们都知道，CPU会把数据取到一个叫做cache的地方，然后下次取的时候直接访问cache，写入的时候，也先将值写入cache。

　　那么，先让我们考虑，在单核的情况下会不会出现问题呢？先想一下，单核情况下，除了CPU还会有什么会修改内存？对了，是外部设备的DMA！那么，DMA修改内存，会不会引起内存屏障的问题呢？答案是，在现在的体系结构中，不会。

　　当外部设备的DMA *** 作结束的时候，会有一种机制保证CPU知道他对应的缓存行已经失效了；而当CPU发动DMA *** 作时，在想外部设备发送启动命令前，需要把对应cache中的内容写回内存。在大多数RISC的架构中，这种机制是通过一写个特殊指令来实现的。在X86上，采用一种叫做总线监测技术的方法来实现。就是CPU和外部设备访问内存的时候都需要经过总线的仲裁，有一个专门的硬件模块用于记录cache中的内存区域，当外部设备对内存写入的时候，就通过这个硬件来判断下改内存区域是否在cache中，然后再进行相应的 *** 作。

　　那么，什么时候才能产生cache引起的内存屏障呢？多CPU？是的，在多CPU的系统里面，每个CPU都有自己的cache，当同一个内存区域同时存在于两个CPU的cache中时，CPU1改变了自己cache中的值，但是CPU2却仍然在自己的cache中读取那个旧值，这种结果是不是很杯具呢？因为没有访存 *** 作，总线也是没有办法监测的，这时候怎么办？

　　对阿，怎么办呢？我们需要在CPU2读取 *** 作之前使自己的cache失效，x86下，很多指令能做到这点，如lock前缀的指令，cpuid， iret等。内核中使用了一些函数来完成这个功能：mb（）， rmb（）， wmb（）。用的也是以上那些指令，感兴趣可以去看下内核代码。