memory-management - 为什么我们不在用户空间使用屏障

Question

我正在阅读有关内存屏障的内容，我可以总结的是它们会阻止编译器对指令进行重新排序。

所以在用户空间内存中可以说我有

b = 0;
main(){

a = 10;
b = 20;
c = add(a,b);

}

编译器能否重新排序此代码，以便 b = 20 赋值发生在调用 c = add() 之后。

为什么我们在这种情况下不使用障碍？我在这里是否遗漏了一些基本知识。

虚拟内存是否免于任何重新排序？

进一步扩展问题:

在网络驱动中:

1742         /*
1743          * Writing to TxStatus triggers a DMA transfer of the data
1744          * copied to tp->tx_buf[entry] above. Use a memory barrier
1745          * to make sure that the device sees the updated data.
1746          */
1747         wmb();
1748         RTL_W32_F (TxStatus0 + (entry * sizeof (u32)),
1749                    tp->tx_flag | max(len, (unsigned int)ETH_ZLEN));
1750 

当他说设备看到更新的数据时...如何将其与使用屏障的多线程理论联系起来。

Answer 1

简答

内存屏障在用户模式代码中的使用频率低于内核模式代码，因为用户模式代码倾向于使用更高级别的抽象(例如 pthread 同步操作)。

其他详细信息

在分析可能的操作顺序时需要考虑两件事:

1. 执行代码的线程将看到中的操作的顺序是什么
2. 其他 线程将以什么顺序看到操作

在您的示例中，编译器无法重新排序 b=20在 c=add(a,b) 之后发生因为c=add(a,b)操作使用 b=20 的结果.但是，编译器可能会重新排序这些操作，以便其他线程看到与 c 关联的内存位置。在与 b 关联的内存位置之前更改变化。

这是否会实际发生取决于硬件实现的内存一致性模型。

至于编译器何时可能进行重新排序，您可以想象如下添加另一个变量:

b = 0;
main(){

a = 10;
b = 20;
d = 30;
c = add(a,b);

}

在这种情况下，编译器可以自由移动 d=30分配发生在 c=add(a,b) 之后.

但是，整个示例过于简单。该程序什么都不做，编译器可以消除所有操作，不需要向内存写入任何内容。

附录:内存重新排序示例

在多处理器环境中，多个线程可以看到以不同顺序发生的内存操作。 Intel Software Developer's Manual在第 3 卷第 8.2.3 节中有一些示例。我在下面复制了一个屏幕截图，其中显示了一个可以重新排序加载和存储的示例。还有一个good blog post提供了有关此示例的更多详细信息。