我所理解的JMM--3 内存屏障

Dear 丶 2023-02-28 04:07 2阅读 0赞

### 内存屏障概述（Memory Barriers） ###

内存屏障可以说是一些指令集，作用于`cpu`和`编译器`大致作用：  
防止屏障指令前后代码乱序，乱序包括`内存顺序`，和`执行顺序`。

理解内存屏障对于理解理解`JMM`至关重要。因为不管是`volatile`和`happer-before`都需底层插入内存屏障实现。文本以`x86`架构说明。

### 现代化`cpu`结构 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70]  
**读取流程：**  
`cpu`从内存读取数据，然后放入`L1,L2`缓存区,然后从`L1 L2`存缓存区放入`Load Buffer`，最后由`Cpu`寄存器读取，二次读取的时候从`Load Buffer`读取即可，如果`Load Buffer`满时，清空`Load Buffer`在进行`L1 L2`缓存区读取。

**存储流程：**  
`Cpu`寄存器的数值 放入 `Store Buffer`中，然后`Store Buffer`满时刷回`L1 L2`缓存区。

**可见性问题：**  
那么在多线程运行下，如果`Cpu1`和`Cpu2`同时读取的`变量A`放入`L1,L2`缓存区，此时`Cpu1`修改`L1`缓存区`变量A`，但是没有刷回主内存中，这将导致`Cpu2`无法看见最新值。

**x86 MESI协议**

网上有一堆的轮子文章可以参考：  
[wikipedia相关介绍][wikipedia]

这里简单再次说明下，x86处理为了解决可见性问题，提供了`MESI`协议  
即每个`cpu`对于每个缓存做了一个表，表中有四个标识符：  
`Modified (M)`  
当前缓存被修改,并且该变量只有自己这个`cpu`使用。  
`Exclusive (E)`  
当前缓存的变量自有自身拥有。  
`Shared (S)`  
当前缓存变量在多个cpu中存在。  
`Invalid (I)`  
当前cpu缓存的变量是脏数据需要更新

当某个cpu读取缓存变量的时候发现标识为`I`那么会从主内存拉取最新的.

**既然有了 MESI 为何还需要内存屏障？**

1.  `cpu`和缓存之间还存在 `Load Buffer`和`Store Buffer`,只有变量从`cpu`寄存器刷新`L1`等才会触发`MESI`。
2.  内存屏障 还有禁止运行重排序功能，这对于多线程开发至关重要。

### 什么是内存重顺序 ###

请看如下例子：

public class Main {
        
    
    
        static int a, b, c, d;
    
        public static void main(String[] args) throws InterruptedException {
        
    
    
            Thread childThread = new Thread(new Runnable() {
        
                @Override
                public void run() {
        
                    a = 1;
                    b = c;
                }
            });
            Thread childThread2 = new Thread(new Runnable() {
        
                @Override
                public void run() {
        
                    c = 1;
                    d = a;
                }
            });
            childThread.start();
            childThread2.start();
        }
    }

上面的例子在两个线程结束时 可能会输出 `d =0,b=0`。  
原因（1）：  
编译器或者`CPU` 打乱了执行顺序。此处不讨论这种情况

原因（2）：  
`childThread`执行`c=1`时并没有把更新后的数值刷新会主内存，而是保存在单个`cpu`里，而继续运行`b = c;`时有可能才把 `b和c`更新的数值刷新回主内存。正常情况应该先`c=1`刷新回主内存，但此时却要等到`b`运行完成后才一起刷新，这就是内存重排序。这种重拍序会引起`d =0,b=0`情况

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 1]  
箭头表示内存操作顺序。  
`a=1`之后并没有立马刷新回主内存，而是在`b=c`之后。在内存角度看来这便是内存上的重排序。

### 执行顺序 ###

#### 1）前向替换 ####

> 案例来自JSR133

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 2]

左图是原始代码，右图是编译器或者cpu实际执行后的代码。  
可以观察的结果可能是`r2 == r5 == 0, r4 ==3`.

其中一个原因`前向替换`:即 `r5 = r1.x`替换为`r5 = r2`。

在`线程1`第一次读取`r1.x` 与读取`r3.x` 之间，`线程 2` 对 `r6.x`  
进行了赋值。如果编译器决定在 `r5` 处重用 `r2` 的值，那么 `r2` 和`r5`的值都是`0`，`r4`的。

#### 2）执行乱序 ####

> 案例来自JSR133

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 3]  
上述例子可能由于 编译器/Cpu 乱序执行引起，由于比较简单不做讲解

### 内存屏障分类 ###

为了解决上述问题，在硬件层面提供了内存屏障指令解决`Cpu`层面 执行乱序，内存乱序等。  
我们把内存屏障大致分为四类（转载自`https://gorden5566.com/post/1020.html`）：

**LoadLoad 屏障**

指令 Load1; LoadLoad; Load2 保证了 Load1 先于 Load2 和后续所有的 load 指令加载数据。通常情况下，在执行预测读（speculative loads）和/或乱序处理（out-of-order processing）的处理器上需要显式的 LoadLoad 屏障，其中等待读（load）指令可以绕过等待写（sotre）指令。在始终保证读顺序（load ordering）的处理器上，这些屏障相当于无操作（no-ops）。

**StoreStore 屏障**

指令 Store1; StoreStore; Store2 保证了 Store1 的数据先于 Store2 及后续 store 指令的数据对其他处理器可见（刷新到内存）。通常情况下，在不保证严格按照顺序从写缓冲区（write buffers）和/或者缓存（caches）刷新到其他处理器或者主内存的处理器上，需要使用 StoreStore 屏障。

**LoadStore 屏障**

指令 Load1; LoadStore; Store2 保证了 Load1 的加载数据先于 Store2 及后续 store 指令刷新数据到主内存。只有在乱序（out-of-order）处理器上，等待写指令（waiting store instructions）可以绕过读指令（loads）的情况下，才会需要使用 LoadStore 屏障。

**StoreLoad 屏障**

指令 Store1; StoreLoad; Load2 保证了 Store1 的数据对其他处理器可见（刷新数据到主内存）先于 Load2 及后续的 load 指令加载数据。StoreLoad 屏障可以防止后续的读操作（load）错误地使用了 Store1 写的数据，而不是使用来自另一个处理器的更近（more recent）的对同一位置（same location）的写。因此，在下面讨论的处理器上，只有需要将对同一个位置的写操作（stores）和随后的读操作（loads）分开时，才严格需要 StoreLoad 屏障。StoreLoad 屏障通常是开销最大的屏障，几乎所有的现代处理器都需要该屏障。之所以开销大，部分原因是它需要禁用绕过缓存（cache）从写缓冲区读取数据（loads from write-buffers）的机制。这可以通过让缓冲区完全刷新，外加暂停其他操作来实现。

在下面讨论的所有处理器中（具体哪些处理器可以看链接原文，反正基本你能见到的都是x86 arm mips等都是），事实证明，执行 StoreLoad 指令同时也获得了其他三个屏障的效果，因此，StoreLoad 可以作为一个通用目的（但是通常开销比较大）的屏障（Fence），这是一个经验上的事实，而不是必须这么做。这种组合反之则不成立，通过组合其他屏障通常不能获得与 StoreLoad 屏障相同的效果。

简单来说`Store`表示写入（如`a=2`），`Load`表示读取`int d=a`.  
在c11中你可以用以下代码获取内存屏障（参考`https://preshing.com/20130922/acquire-and-release-fences/`）

#include  <atomic>
    std :: atomic_thread_fence（std :: memory_order_acquire）;
    std :: atomic_thread_fence（std :: memory_order_release）;

个人理解的屏障：

**LoadLoad 屏障**

(1)两个读取指令在编译器层面禁止乱序：

int a=c;
    // insert LoadLoad instruction
    int d=c;

禁止编译成如下代码

int d=c;
    // insert LoadLoad instruction
    int a=c;

(2) 在cpu执行时禁止乱序执行

int a=c;
    // insert LoadLoad instruction
    int d=c;

禁止cpu先执行`d=c`

int d=c;
    // insert LoadLoad instruction
    int a=c;

(3) 禁止编译器`优化前向替`换等.

int a=c;
    // insert LoadLoad instruction
    int d=c;

以下代码是被禁止的

int a=c;
    // insert LoadLoad instruction
    int d=a;

(4） LoadLoad屏障后的读取指令之前强制刷出`LoadBuffer`迫使第二个读取指令一定最新的内存数值。（当然不同处理器处理方式可能不一样，目的都是强制屏障后的第一个load一定是主内存的数值）

int a=c;
    // insert LoadLoad instruction
    //此时c的数值一定是最新可见
    int d=c;

其他屏障由于类似不做理解说明。

上述的四种类型屏障在不同的`Cpu`架构不一定都存在具体请看如下表格（参见http://gee.cs.oswego.edu/dl/jmm/cookbook.html）：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 4]

在这里特别提示一点：在x86下 `lock`指令前缀除了本身具有强制缓存一致性效果外，还同时具备`StoreLoad`功能。参见（https://stackoverflow.com/questions/27772910/where-is-the-load-barrier-for-the-volatile-statement)

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70]: /images/20230209/8fcba11d2ae94b2b91e25fe61cae875d.png
[wikipedia]: https://en.wikipedia.org/wiki/MESI_protocol
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 1]: /images/20230209/3e7093967e5d43f9a4735a06aa2357d4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200726194046315.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200726194602671.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20200726224601917.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70