内存屏障是如何工作的？答案

【问题标题】：How does memory barrier work?内存屏障是如何工作的？
【发布时间】：2013-01-28 22:03:55
【问题描述】：

在 Windows 下，有 3 个编译器内部函数来实现内存屏障：

1. _ReadBarrier;

2. _WriteBarrier;

3. _ReadWriteBarrier;

但是，我发现了一个奇怪的问题：_ReadBarrier 似乎是一个什么都不做的虚拟函数！以下是我用VC++ 2012生成的汇编代码。

我的问题是：如何在汇编指令中实现内存屏障功能？

int main()
{   
013EEE10  push        ebp  
013EEE11  mov         ebp,esp  
013EEE13  sub         esp,0CCh  
013EEE19  push        ebx  
013EEE1A  push        esi  
013EEE1B  push        edi  
013EEE1C  lea         edi,[ebp-0CCh]  
013EEE22  mov         ecx,33h  
013EEE27  mov         eax,0CCCCCCCCh  
013EEE2C  rep stos    dword ptr es:[edi]  
    int n = 0;
013EEE2E  mov         dword ptr [n],0  
    n = n + 1;
013EEE35  mov         eax,dword ptr [n]  
013EEE38  add         eax,1  
013EEE3B  mov         dword ptr [n],eax  
    _ReadBarrier();
    n = n + 1;
013EEE3E  mov         eax,dword ptr [n]  
013EEE41  add         eax,1  
013EEE44  mov         dword ptr [n],eax 
}
013EEE56  xor         eax,eax  
013EEE58  pop         edi  
013EEE59  pop         esi  
013EEE5A  pop         ebx  
013EEE5B  add         esp,0CCh  
013EEE61  cmp         ebp,esp  
013EEE63  call        __RTC_CheckEsp (013EC3B0h)  
013EEE68  mov         esp,ebp  
013EEE6A  pop         ebp  
013EEE6B  ret

【问题讨论】：

在 x86 上，所有加载都是获取，所有存储都是发布，因此您不需要任何显式代码。唯一必要的代码是完整的屏障。读屏障的概念比 x86 架构更通用，并且在内存模型较弱的机器上并不重要。
我猜这些只是改变编译器生成代码方式的编译器障碍，而不是汇编级障碍。
@KerrekSB 这是真的吗，即使对于最新的机器？这样做会大大减慢速度，并消除拥有多个内核的许多效用（至少对于某些类型的应用程序而言）。
@JamesKanze：嗯，至少据我所知。不过，我完全有可能搞错了。
对linux内核smpkernel.org/doc/Documentation/memory-barriers.txt987654321@的一个很好的解释

标签： c++ c assembly execution instructions

【解决方案1】：

_ReadBarrier、_WriteBarrier 和 _ReadWriteBarrier 是 intrinsics that affect how the compiler can reorder code；它们与 CPU 内存屏障完全无关，仅对特定类型的内存有效（请参阅“受影响的内存”here）。

MemoryBarrier() 是用于强制 CPU 内存屏障的内在函数。但是，Microsoft 的建议是在 VC++ 中使用std::atomic<T>。

【讨论】：

【解决方案2】：

现代处理器能够比它实际“完成”指令的位置提前很长的距离执行指令，因此当涉及某些类型的内存操作时，内存屏障用于防止它运行到很远的位置，其中需要严格的排序 - 对于大多数事情，实际上是在变量 b 之前写入变量 a 还是在 a 之前写入 b 实际上并不重要。但有时确实如此。

x86 指令集有lfence、sfence 和fence，它们分别是“围栏”加载、存储和所有内存操作的指令。关于“栅栏”或“屏障”指令的要点是确保屏障指令之前的所有指令在屏障之后的下一条指令可以继续之前完成它们的加载、存储或两者。

如果您正在实现例如信号量、互斥锁或类似指令，这一点很重要，因为在继续读取其他数据之前存储“我已锁定信号量”的值很重要。否则事情可能会出错，让我们说。

请注意，除非您真的知道自己在使用内存屏障做什么，否则最好不要使用它们 - 并依赖解决相同问题的现有代码 - std::atomic 是资助此类代码的一个地方。我写了很多“棘手”的代码，但只有一两次我的代码需要内存屏障。

有好几次，我需要让编译器不散布代码，你可以使用“无操作函数”来做到这一点，而且显然现在甚至有特殊的内在函数可以做到这一点。

【讨论】：

【解决方案3】：

有几个要点需要考虑。也许首先是障碍只在多线程中起作用代码，并且大多数编译器需要一个特殊的选项来生成多线程代码。而像_ReadBarrier 这样的东西几乎当然是编译器内置的，应该什么都不做，除非您已经给出了多线程代码的选项。

第二个是硬件要求，即使在一个多线程上下文，变化。在我用过的大多数机器上工作（超过四十年），这台机器从来不需要任何事物;仅当机器具有复杂的读写管道。（大多数早期的机器甚至没有栅栏或障碍指令，所以生成的代码必须为空。）

【讨论】：

内存屏障也与低级硬件访问有关。
@edgar.holleis 是的。当然，这不会影响用户进程，但真正的标准不是线程，而是两个实体访问内存的可能性。线程只是发生这种情况的最常见情况。