ChatGPT 探讨内存屏障的意内存
一、与 ChatGPT 探讨内存屏障的意内存
轻松的氛围，跟 ChatGPT 从内存屏障问题一直扯到CAP原理
我： 2023/4/14 17:48:09
那我可以理解为
{
shared_var = 1;
asm volatile ("sfence" ::: "memory");
asm volatile ("lfence" ::: "memory");
val = shared_var;
}
{
shared_var = 1;
asm volatile ("mfence" ::: "memory");
val = shared_var;
}
上面这两端代码等价吗
ChatGPT: 2023/4/14 17:48:41
这两段代码并不完全等价。
第一段代码是使用sfence和lfence指令来同步内存访问顺序。在写入共享变量shared_var后，sfence指令会将该写操作同步到主存中，避免缓存数据被重排或者过早地写回主存。而在读取共享变量时，lfence指令会确保所有之前的内存读取操作都已经完成，避免读取到脏数据。因此，这两个指令结合使用可以实现对共享变量的安全读写。
第二段代码则是使用mfence指令来同步内存访问顺序。mfence指令同时阻止CPU对读/写指令乱序执行，在写入共享变量和读取共享变量之间插入了一个屏障，确保写操作已经完成并写回内存后才能进行读操作。因此，这个指令可以实现对共享变量的安全读写。
虽然这两段代码的目的相同，都是为了实现对共享变量的安全读写，但它们的实现方式不同。使用sfence和lfence指令可以实现更细粒度的同步，避免了不必要的内存屏障，因此通常比mfence指令的执行效率更高。但需要注意的是，不同的CPU架构可能对这些指令的执行效果有所不同，因此在实际使用时需要进行测试和验证。
我：2023/4/14 17:50:05
从用户的角度看来一样的吧
ChatGPT:2023/4/14 17:50:22
从用户的角度来看，这两段代码确实可以实现相同的功能。它们都使用了不同的内存屏障指令来同步内存访问顺序，以避免出现并发访问共享变量时的问题。
然而，这两个指令的底层实现机制是不同的，并且在不同的CPU架构上可能会有所不同。使用sfence和lfence指令可以实现更细粒度的同步，并且在一些CPU架构上可能比mfence指令的执行效率更高。因此，在实际编程中需要根据具体情况来选择合适的内存屏障指令，以达到最优的性能和正确性。
以上是通过 ChatGPT 学习内存屏障的过程。
二、 解读与总结
也就说， asm volatile (“mfence” ::: “memory”); 这条内存读写屏障，之所以难以理解，是因为他把两种场景用到的两条指令合并成一条指令，从而导致晦涩难懂。
单独理解
asm volatile (“sfence” ::: “memory”);
或
asm volatile (“lfence” ::: “memory”);
就简单很多了。
首先，我们知道对于共享变量，线程用的内存包括，本地内存，主内存。
-
如果，希望数据马上写穿 write through 到主内存，
则写完之后执行asm volatile (“sfence” ::: “memory”);
-
如果，希望数据重新到主内存读取最新值，
则读之前执行asm volatile (“lfence” ::: “memory”);
-
如果又是读，又是写
{
shared_var = 1;
asm volatile ("sfence" ::: "memory");
asm volatile ("lfence" ::: "memory");
val = shared_var;
}
即，等价于
{
shared_var = 1;
asm volatile ("mfence" ::: "memory");
val = shared_var;
}
现在回头再理解内存屏障指令，再结合对Java内存模型(java memory model) 就清晰多了吧。
asm volatile (“mfence” ::: “memory”);
这条指令无非就是考察我们是否认识 ： “内存屏障”问题的本质就是“缓存同步”问题。
缓存同步，关注的是一致性与实时性之间的取舍（CAP原理）