英特尔内存模型保证：
商店将不会与其他商店重新订购
负载不会与其他负载重新排序
http://bartoszmilewski.com/2008/11/05/who-ordered-memory-fences-on-an-x86/
我已经看到由于Intel内存模型，SFENCE在x86-64上是多余的，但从未出现过LFENCE。上述内存模型规则是否会使其中一条指令冗余？
最佳答案
正确，LFENCE和SFENCE在普通代码中没有用，因为x86的常规存储区的获/释放语义使它们变得多余，除非您使用其他特殊指令或内存类型。
对于普通的无锁代码而言，唯一重要的屏障是来自lock指令的完整屏障（包括StoreLoad）或较慢的MFENCE。对于xchg + mov上的顺序一致性存储，优选mfence。 Are loads and stores the only instructions that gets reordered?，因为它更快。
Does `xchg` encompass `mfence` assuming no non-temporal instructions?（是的，即使没有NT指令，只要没有WC内存即可。）
杰夫·普雷辛（Jeff Preshing）的Memory Reordering Caught in the Act文章是Bartosz帖子所谈到的同一案例的易于理解的描述，在该案例中您需要诸如MFENCE之类的StoreLoad障碍。只有MFENCE才能做到；您无法通过SFENCE + LFENCE构建MFENCE。 （Why is (or isn't?) SFENCE + LFENCE equivalent to MFENCE?）
如果您在阅读发布的链接后有疑问，请阅读Jeff Preshing的其他博客文章。他们使我对该主题有了很好的理解。 :)尽管我认为我在Doug Lea的页面上发现关于SFENCE / LFENCE的常识通常是无人问津的。 Jeff的帖子没有考虑NT加载/存储。
相关：When should I use _mm_sfence _mm_lfence and _mm_mfence（我的答案和@BeeOnRope的答案都很好。我早于该答案就写了这个答案，所以几年前这个答案的部分内容显示出我的经验不足。我的答案考虑到了C ++内在函数和C ++编译-时间内存顺序，这与x86 asm运行时内存顺序完全不同。但是您仍然不希望_mm_lfence()。）
SFENCE仅在使用movnt（非临时）流存储或使用类型设置为普通回写以外的内存区域时才有意义。或使用clflushopt，这有点像一个无序的商店。 NT存储绕过缓存以及被弱排序。 x86's normal memory model is strongly ordered，除了NT存储，WC（写合并）内存和ERMSB字符串操作（请参见下文）以外。
LFENCE仅对很少排序的负载的内存排序有用。 （或者对于在NT存储之前以常规负载订购LoadStore可能吗？）
即使在假设的将来不会忽略NT提示的CPU上，WB内存中的NT负载（movntdqa）也是still strongly ordered。在x86上执行弱排序加载的唯一方法是从弱排序内存（WC）读取时，然后我认为仅使用movntdqa。在“正常”程序中不会偶然发生这种情况，因此，如果您映射了视频RAM或其他东西，则只需担心这一点。
（lfence的主要用例根本不是存储器排序，它是用于序列化指令执行的，例如用于减轻Spectre或与RDTSC一起使用。有关此问题，请参见Is LFENCE serializing on AMD processors?和“链接的问题”侧边栏。）
C ++中的内存排序及其如何映射到x86 asm
几周前，我对此感到很好奇，并针对最近的问题发布了相当详细的答案：
Atomic operations, std::atomic<> and ordering of writes。我提供了许多有关C ++内存模型与硬件内存模型的内容的链接。
如果您使用C ++编写，则使用std::atomic<>是一种很好的方式来告诉编译器您有什么排序要求，因此不会在编译时对内存操作进行重新排序。您可以并且应该在适当的地方使用较弱的版本或获取语义，而不是使用默认的顺序一致性，因此编译器完全不必在x86上发出任何屏障指令。它只需要按源顺序保持操作。
在ARM，PPC或movnt的x86等弱有序的体系结构上，需要在写缓冲区和设置标志以指示数据就绪之间使用StoreStore屏障指令。此外，阅读器在检查标志和读取缓冲区之间还需要LoadLoad屏障指令。
不算movnt，x86在每个负载之间已经具有LoadLoad障碍，在每个商店之间都具有StoreStore障碍。 （也保证了LoadStore的订购）。 MFENCE是所有四种屏障，包括StoreLoad，这是x86默认情况下唯一不执行的屏障。 MFENCE确保加载不会使用其他线程看到您的存储之前并可能使用自己的存储之前的旧预取值。 （这也是NT存储订购和负载订购的障碍。）
有趣的事实：x86 lock前缀的指令也是完整的内存障碍。它们可以在不支持它的CPU上运行的旧32位代码中替代MFENCE。 lock add [esp], 0否则为空操作，并且对可能在L1缓存中很热并且已经处于MESI一致性协议的M状态的内存执行读取/修改/写入周期。
SFENCE是StoreStore的障碍。在NT存储区之后，为后续存储区创建发布语义非常有用。
LFENCE几乎总是无关紧要的，因为唯一的弱排序负载
一个LoadLoad和also a LoadStore barrier。 （loadNT / LFENCE / storeNT防止存储在加载之前在全局范围内可见。我认为，如果加载地址是长依赖链的结果，或者是另一个未在高速缓存中加载的结果，则在实践中可能会发生这种情况。）
ERMSB字符串操作
有趣的事实2（感谢@EOF）：来自ERMSB (Enhanced rep movsb/rep stosb on IvyBridge and later)的存储是弱排序的（但不能绕过缓存）。 ERMSB基于常规的快速字符串操作（自PPro以来就存在的rep stos/movsb的微代码实现的广泛存储）。
英特尔在其软件开发人员手册vol1的7.3.9.3节中记录了ERMSB存储“可能似乎执行不正确”的事实。他们还说
“与订单有关的代码应写入离散的信号量变量
在进行任何字符串操作后，可以看到正确排序的数据
所有处理器”
他们没有在rep movsb标志和data_ready标志之间提及在rep stosb / rep movsb和存储之间必要的任何屏障说明。
我的阅读方式是，在movNT之后有一个隐式SFENCE（至少是字符串数据的栅栏，可能不是其他正在进行中的，有序的NT存储）。无论如何，该措辞暗示着在所有字符串移动写操作之后，对标志/信号量的写操作变得全局可见，因此在用快速字符串op填充缓冲区然后写入标志的代码中不需要SFENCE / LFENCE。在读取它的代码中。
（总是执行LoadLoad排序，因此您总是以其他CPU使其在全局可见的顺序查看数据。即，使用弱排序的存储来写入缓冲区不会改变其他线程中的负载仍然严格排序的事实。）
摘要：使用普通存储来写一个标志，指示缓冲区已准备就绪。没有读者只是检查用memset / memcpy编写的块的最后一个字节。
我也认为ERMSB存储阻止以后的任何存储传递它们，因此，如果您使用的是rep stosb，则仍然只需要SFENCE。即rep stosb总体上具有发布语义wrt。先前的说明。
为了使新服务器需要运行旧的二进制文件，可以清除MSR位以禁用ERMSB，新服务器需要运行旧的二进制文件，并在rep movsb或
关于assembly - 英特尔内存模型是否会使SFENCE和LFENCE冗余？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32705169/