blocks|key|1055094|text|这是我的理解，希望是准确和简单到有意义的：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1055095|(安腾)+IA64体系结构允许以任何顺序执行内存读取和写入，因此从另一个处理器的角度来看，内存更改的顺序是不可预测的，除非您使用栅栏以合理的顺序强制该写入完成。|1055096|从这里开始，我要说的是x86，x86是强有序的。|1055097|在x86上，英特尔不保证在另一处理器上完成的商店在此处理器上始终可见。有可能这个处理器推测性地执行加载(读取)的时间刚刚够早，以至于错过了另一个处理器的存储(写入)。它只保证写入对其他处理器可见的顺序是按程序顺序进行的。它不能保证无论您做什么，其他处理器都会立即看到任何更新。|1055098|锁定的读取/修改/写入指令完全顺序一致。因此，通常情况下，您已经处理了丢失的其他处理器的内存操作，因为锁定的xchg或cmpxchg将同步所有这些操作，您将立即获取相关的缓存线以获得所有权，并将自动更新它。如果另一个CPU正在与您的锁定操作竞争，要么您将赢得竞争，另一个CPU将错过高速缓存并在您的锁定操作之后将其取回，或者它们将赢得竞争，而您将错过高速缓存并从它们获得更新值。|offset|length|style|CODE|1055099|lfence会暂停指令发布，直到lfence之前的所有指令都完成。mfence专门等待所有先前的内存读取完全进入目标寄存器，并等待所有先前的写入变得全局可见，但不会像lfence那样停止所有进一步的指令。sfence仅对存储执行相同的操作，刷新写入组合器，并确保在允许sfence之后的任何存储开始执行之前，sfence之前的所有存储都是全局可见的。|1055100|在x86上几乎不需要任何类型的屏障，除非您正在使用写组合内存或非临时指令，否则不需要它们，如果您不是内核模式(驱动程序)开发人员，则很少这样做。通常，x86保证所有存储按程序顺序可见，但它不保证WC+(写组合)内存或执行显式弱有序存储的“非临时”指令，如movnti。|1055101|因此，总而言之，存储在程序顺序中总是可见的，除非您使用了特殊的弱有序存储或正在访问WC内存类型。使用锁定指令(如xchg、xadd或cmpxchg等)的算法将在没有栅栏的情况下工作，因为锁定指令是顺序一致的。|1055102|entityMap^0|0|0|0|0|1I|4|1N|7|0|0|6|G|6|X|6|2B|6|2U|6|3Q|6|4A|6|0|3J|6|0|1K|4|1P|4|1U|7|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@$J|10|K|11|L|M]|$J|12|K|13|L|M]]|9|@]|A|$]]|$1|N|3|O|5|6|7|14|8|@$J|15|K|16|L|M]|$J|17|K|18|L|M]|$J|19|K|1A|L|M]|$J|1B|K|1C|L|M]|$J|1D|K|1E|L|M]|$J|1F|K|1G|L|M]|$J|1H|K|1I|L|M]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1J|8|@$J|1K|K|1L|L|M]]|9|@]|A|$]]|$1|R|3|S|5|6|7|1M|8|@$J|1N|K|1O|L|M]|$J|1P|K|1Q|L|M]|$J|1R|K|1S|L|M]]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]]|U|$]]

Here is my understanding, hopefully accurate and simple enough to make sense:

(Itanium) IA64 architecture allows memory reads and writes to be executed in any order, so the order of memory changes from the point of view of another processor is not predictable unless you use fences to enforce that writes complete in a reasonable order.

From here on, I am talking about x86, x86 is strongly ordered. 

On x86, Intel does not guarantee that a store done on another processor will always be immediately visible on this processor. It is possible that this processor speculatively executed the load (read) just early enough to miss the other processor's store (write). It only guarantees the order that writes become visible to other processors is in program order. It does not guarantee that other processors will immediately see any update, no matter what you do.

Locked read/modify/write instructions are fully sequentially consistent. Because of this, in general you already handle missing the other processor's memory operations because a locked <code>xchg</code> or <code>cmpxchg</code> will sync it all up, you will acquire the relevant cache line for ownership immediately and will update it atomically. If another CPU is racing with your locked operation, either you will win the race and the other CPU will miss the cache and get it back after your locked operation, or they will win the race, and you will miss the cache and get the updated value from them.

<code>lfence</code> stalls instruction issue until all instructions before the <code>lfence</code> are completed. <code>mfence</code> specifically waits for all preceding memory reads to be brought fully into the destination register, and waits for all preceding writes to become globally visible, but does not stall all further instructions as <code>lfence</code> would. <code>sfence</code> does the same for only stores, flushes write combiner, and ensures that all stores preceding the <code>sfence</code> are globally visible before allowing any stores following the <code>sfence</code> to begin execution.

Fences of any kind are rarely needed on x86, they are not necessary unless you are using write-combining memory or non-temporal instructions, something you rarely do if you are not a kernel mode (driver) developer. Normally, x86 guarantees that all stores are visible in program order, but it does not make that guarantee for WC (write combining) memory or for "non-temporal" instructions that do explicit weakly ordered stores, such as <code>movnti</code>.

So, to summarize, stores are always visible in program order unless you have used special weakly ordered stores or are accessing WC memory type. Algorithms using locked instructions like <code>xchg</code>, or <code>xadd</code>, or <code>cmpxchg</code>, etc, will work without fences because locked instructions are sequentially consistent.

I read the "Intel Optimization guide Guide For Intel Architecture".

However, I still have no idea about when should I use 

<pre><code>_mm_sfence()
_mm_lfence()
_mm_mfence()
</code></pre>

Could anyone explain when these should be used when writing multi-threaded code?

When should I use _mm_sfence _mm_lfence and _mm_mfence

我阅读了《英特尔架构优化指南》。但是，我仍然不知道什么时候应该使用_mm_sfence()_mm_lfence()_mm_mfence()谁能解释一下，在编写多线程代码时，什么时候应该使用这些？

问什么时候应该使用_mm_sfence _mm_lfence和_mm_mfence
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么时候应该使用_mm_sfence _mm_lfence和_mm_mfenceEN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么时候应该使用_mm_sfence _mm_lfence和_mm_mfence
EN