blocks|key|3268263|text|在进行无锁并发编程时，应该注意程序指令的重新排序。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3268264|程序指令的重新排序可以在以下几个阶段发生：|3268265|optimizations|3268266|JIT编译器optimizations|unordered-list-item|3268267|
|3268268|CPU+optimizations.|3268269|
+|3268270|C#/VB.NET/F#编译器|ordered-list-item|3268271|3268272|内存栅栏是确保程序指令特定顺序的唯一方法。基本上，内存围栏是一类使CPU强制执行排序约束的指令。记忆栅栏可以分为三类：|3268273|3268274|加载栅栏-确保没有加载CPU指令跨越栅栏|3268275|存储栅栏-确保没有存储CPU指令跨越栅栏|3268276|全栅栏-确保没有加载或存储CPU指令跨越栅栏|3268277|3268278|在.NET框架中，有很多种方法可以发射栅栏:互锁、监视器、ReaderWriterLockSlim等。|3268279|Thread.MemoryBarrier在即时编译器和处理器级别上都是完全隔离的。|offset|length|style|BOLD|3268280|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|15|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1D|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1E|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|1F|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|1G|8|@]|9|@]|A|$]]|$1|K|3|L|5|H|7|1H|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1I|8|@]|9|@]|A|$]]|$1|O|3|P|5|Q|7|1J|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1L|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|V|3|W|5|Q|7|1N|8|@]|9|@]|A|$]]|$1|X|3|Y|5|Q|7|1O|8|@]|9|@]|A|$]]|$1|Z|3|10|5|Q|7|1P|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1R|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|1S|8|@$16|1T|17|1U|18|19]]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]]|1B|$]]

While doing lock-free concurrent programming one should care about program instructions reordering.

Program instructions reordering can occur at several stages:

<ol>
<li>C#/VB.NET/F# compiler optimizations</li>
<li>JIT compiler optimizations</li>
<li>CPU optimizations.</li>
</ol>

Memory fences are the only way to ensure particular order of your program instructions. 
Basically, memory fence is a class of instructions which causes CPU to enforce an ordering constraint. Memory fences can be put into three categories:

<ol>
<li>Load fences - ensure no load CPU instructions move across the fences</li>
<li>Store fences - ensure no store CPU instructions move across the fences</li>
<li>Full fences - ensure no load or store CPU instructions move across the fences</li>
</ol>

In .NET Framework there are plenty of ways to emit fences: Interlock, Monitor, ReaderWriterLockSlim etc.

Thread.MemoryBarrier emits a full fence on both JIT compiler and processor level.

blocks|key|315751|text|在一个非常强大的内存模型中，不需要发出栅栏指令。所有内存访问将按顺序执行，并且所有存储将是全局可见的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|315752|因为当前的通用架构do+not+provide+a+strong+memory+model+-+x86/x64可以例如相对于写入对读取进行重新排序，所以需要存储器栅栏。(更彻底的来源是，8.2.2+P6和更新的处理器家族中的内存排序“)。作为一个来自gazillion的例子，Dekker's+algorithm+will+fail+on+x86/x64没有栅栏。|offset|length|315753|即使JIT生成的机器码中小心地放置了具有内存加载和存储的指令，如果CPU随后对这些加载和存储进行重新排序，那么JIT的努力也是徒劳的-它可以这样做，只要保持当前上下文/线程的顺序一致性的假象。|315754|冒着过于简单化的风险:它可能有助于将指令流产生的加载和存储可视化为一群雷鸣般的野生动物。当它们穿过一座狭窄的桥(你的CPU)时，你永远不能确定动物的顺序，因为它们中的一些会慢一些，一些会快一些，一些会超车，一些会落后。如果在开始时-当您发出机器代码时-通过在它们之间放置无限长的栅栏来将它们划分为组，您至少可以确保组A在组B之前。|315755|栅栏可确保读取和写入的顺序。措辞不准确，但：|315756|315757|a存储栅栏“等待”所有未完成的存储(写)操作完成，但不影响加载。|unordered-list-item|315758|加载栅栏“等待”所有未完成的加载(读取)操作，但不影响存储。|315759|a|315760|a+full栅栏“等待”所有存储和加载操作完成。它的效果是，在栅栏之前读取和写入将在“栅栏另一侧”(在栅栏之后)上的写入和加载之前执行。|315761|315762|JIT为完全隔离发出的内容取决于(CPU)体系结构以及它所提供的内存排序保证。因为JIT确切地知道它在什么架构上运行，所以它可以发出适当的指令。|315763|在我的安装了.NET+4.0RC的x64机器上，它恰好是一个lock+or。|style|CODE|315764|++++++++++++int+a+=+0;
00000000++sub+++++++++rsp,28h+
++++++++++++Thread.MemoryBarrier();
00000004++lock+or+++++dword+ptr+[rsp],0+
++++++++++++Console.WriteLine(a);
00000009++mov+++++++++ecx,1+
0000000e++call++++++++FFFFFFFFEFB45AB0+
00000013++nop+
00000014++add+++++++++rsp,28h+
00000018++ret+|code-block|syntax|javascript|315765|Intel®+64+and+IA-32+Architectures+Software+Developer’s+Manual第8.1.2章：|315766|锁定操作“|315767|"...locked操作序列化所有未完成的加载和存储操作(即等待它们完成)。”...“锁定操作相对于所有其他内存操作和所有外部可见事件是原子的。只有指令提取和页表访问才能传递锁定指令。锁定指令可用于同步由一个处理器写入的数据和由另一个can指令读取的数据，以满足这一特定需求。在上述情况下，MFENCE可以用作完全屏障(至少在理论上是这样的--一个是locked+operations+might+be+faster，两个是it+might+result+in+different+behavior)。MFENCE和它的朋友可以在8.2.5“加强或削弱记忆排序模型”一章中找到。|315768|315769|有更多的方法来序列化存储和加载，尽管它们要么不切实际，要么比上面的方法慢：|315770|315771|在8.3章中，你可以找到完整的序列化指令，比如CPUID。这些序列化指令流：“任何东西都不能传递序列化指令，而序列化指令不能传递任何其他指令(读、写、取指令或I/O)”。|315772|如果您将内存设置为强未缓存(UC)，则it+will+give+you+a+strong+memory+model：不允许任何推测性或乱序访问，并且所有访问都将出现在总线上，因此无需发出指令。:)当然，这会比平时慢一点。|315773|315774|..。|315775|所以这取决于。如果有一台具有强大排序保证的计算机，JIT很可能什么也不会发出。|315776|IA64和其他架构都有自己的内存模型--因此保证内存排序(或不保证内存排序)--以及它们自己的指令/方法来处理内存存储/加载排序。|315777|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Memory_ordering|1|http://msdn.microsoft.com/en-us/library/ee418650(VS.85).aspx|2|http://www.intel.com/Assets/PDF/manual/253668.pdf|3|http://blogs.oracle.com/dave/resource/NHM-Pipeline-Blog-V2.txt|4|http://blogs.oracle.com/dave/entry/java_memory_model_concerns_on|5|http://lkml.indiana.edu/hypermail/linux/kernel/9911.3/0137.html^0|0|9|10|0|3U|13|1|0|0|0|0|0|0|0|0|0|0|0|U|7|0|0|0|1P|2|0|0|41|6|6Z|6|4V|X|3|5Z|Y|4|0|0|0|0|N|5|0|J|12|5|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|2A|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|2B|8|@]|9|@$D|2C|E|2D|1|2E]|$D|2F|E|2G|1|2H]]|A|$]]|$1|F|3|G|5|6|7|2I|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|2J|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|2K|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|2L|8|@]|9|@]|A|$]]|$1|M|3|N|5|O|7|2M|8|@]|9|@]|A|$]]|$1|P|3|Q|5|O|7|2N|8|@]|9|@]|A|$]]|$1|R|3|S|5|O|7|2O|8|@]|9|@]|A|$]]|$1|T|3|U|5|O|7|2P|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|2Q|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|2R|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|2S|8|@$D|2T|E|2U|10|11]]|9|@]|A|$]]|$1|12|3|13|5|14|7|2V|8|@]|9|@]|A|$15|16]]|$1|17|3|18|5|6|7|2W|8|@]|9|@$D|2X|E|2Y|1|2Z]]|A|$]]|$1|19|3|1A|5|6|7|30|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|O|7|31|8|@$D|32|E|33|10|11]|$D|34|E|35|10|11]]|9|@$D|36|E|37|1|38]|$D|39|E|3A|1|3B]]|A|$]]|$1|1D|3|-4|5|6|7|3C|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|3D|8|@]|9|@]|A|$]]|$1|1G|3|-4|5|6|7|3E|8|@]|9|@]|A|$]]|$1|1H|3|1I|5|O|7|3F|8|@$D|3G|E|3H|10|11]]|9|@]|A|$]]|$1|1J|3|1K|5|O|7|3I|8|@]|9|@$D|3J|E|3K|1|3L]]|A|$]]|$1|1L|3|-4|5|6|7|3M|8|@]|9|@]|A|$]]|$1|1M|3|1N|5|6|7|3N|8|@]|9|@]|A|$]]|$1|1O|3|1P|5|6|7|3O|8|@]|9|@]|A|$]]|$1|1Q|3|1R|5|6|7|3P|8|@]|9|@]|A|$]]|$1|1S|3|-4|5|6|7|3Q|8|@]|9|@]|A|$]]]|1T|$1U|$5|1V|1W|1X|A|$1Y|1Z]]|20|$5|1V|1W|1X|A|$1Y|21]]|22|$5|1V|1W|1X|A|$1Y|23]]|24|$5|1V|1W|1X|A|$1Y|25]]|26|$5|1V|1W|1X|A|$1Y|27]]|28|$5|1V|1W|1X|A|$1Y|29]]]]

In a really strong memory model, emitting fence instructions would be unnecessary. All memory accesses would execute in order and all stores would be globally visible.

Memory fences are needed because current common architectures <a href="http://en.wikipedia.org/wiki/Memory_ordering" rel="noreferrer">do not provide a strong memory model</a> - x86/x64 can for example reorder reads relative to writes. (A more thorough source is <a href="http://www.intel.com/Assets/PDF/manual/253668.pdf" rel="noreferrer">"Intel® 64 and IA-32 Architectures Software Developer’s Manual</a>, 8.2.2 Memory Ordering in P6 and More Recent Processor Families"). As an example from the gazillions, <a href="http://msdn.microsoft.com/en-us/library/ee418650(VS.85).aspx" rel="noreferrer">Dekker's algorithm will fail on x86/x64</a> without fences.

Even if the JIT produces machine code in which instructions with memory loads and stores are carefully placed, its efforts are useless if the CPU then reorders these loads and stores - which it can, as long as the illusion of sequential consistency is maintained for the current context/thread.

Risking oversimplification: it may help to visualize the loads and stores resulting from the instruction stream as a thundering herd of wild animals.
As they cross a narrow bridge (your CPU), you can never be sure about the order of the animals, since some of them will be slower, some faster, some overtake, some fall behind.
If at the start - when you emit the machine code - you partition them into groups by putting infinitely long fences between them, you can at least be sure that group A comes before group B.

Fences ensure the ordering of reads and writes. Wording is not exact, but:

<ul>
<li>a store fence "waits" for all outstanding store (write) operations to finish, but does not affect loads.</li>
<li>a load fence "waits" for all outstanding load (read) operations to finish, but does not affect stores.</li>
<li>a full fence "waits" for all store and load operations to finish. It has the effect that reads and writes before the fence will get executed before the writes and loads that are on the "other side of the fence" (come later than the fence).</li>
</ul>

What the JIT emits for a full fence, depends on the (CPU) architecture and what memory ordering guarantees it provides.
Since the JIT knows exactly what architecture it runs on, it can issue the proper instruction(s).

On my x64 machine, with .NET 4.0 RC, it happens to be a <code>lock or</code>.

<pre><code> int a = 0;
00000000 sub rsp,28h 
 Thread.MemoryBarrier();
00000004 lock or dword ptr [rsp],0 
 Console.WriteLine(a);
00000009 mov ecx,1 
0000000e call FFFFFFFFEFB45AB0 
00000013 nop 
00000014 add rsp,28h 
00000018 ret 
</code></pre>

<a href="http://www.intel.com/Assets/PDF/manual/253668.pdf" rel="noreferrer">Intel® 64 and IA-32 Architectures Software Developer’s Manual</a> Chapter 8.1.2:

<ul>
<li>"...locked operations serialize all outstanding load and store operations (that is, wait for them to complete)."
..."Locked operations are atomic with respect to all other memory operations and all
externally visible events. Only instruction fetch and page table accesses can pass
locked instructions. Locked instructions can be used to synchronize data written by
one processor and read by another processor."</li>
<li>memory-ordering instructions address this specific need. <code>MFENCE</code> could have been used as full barrier in the above case (at least in theory - for one, <a href="http://blogs.oracle.com/dave/resource/NHM-Pipeline-Blog-V2.txt" rel="noreferrer">locked operations might be faster</a>, for two it <a href="http://blogs.oracle.com/dave/entry/java_memory_model_concerns_on" rel="noreferrer">might result in different behavior</a>). <code>MFENCE</code> and its friends can be found in Chapter 8.2.5 "Strengthening or Weakening the Memory-Ordering Model". </li>
</ul>

There are some more ways to serialize stores and loads, though they are either impractical or slower than the above methods:

<ul>
<li>In chapter 8.3 you can find full serializing instructions like <code>CPUID</code>. These serialize instruction flow as well: "Nothing can pass a serializing instruction and
a serializing instruction cannot pass any other instruction (read, write, instruction
fetch, or I/O)".</li>
<li>If you set up memory as strong uncached (UC), <a href="http://lkml.indiana.edu/hypermail/linux/kernel/9911.3/0137.html" rel="noreferrer">it will give you a strong memory model</a>: no speculative or out-of order accesses will be allowed and all accesses will appear on the bus, therefore no need to emit an instruction. :) Of course, this will be a tad slower than usual.</li>
</ul>

...

So it depends on. If there was a computer with strong ordering guarantees, the JIT would probably emit nothing.

IA64 and other architectures have their own memory models - and thus guarantees of memory ordering (or lack of them) - and their own instructions/ways to deal with memory store/load ordering.

I'm clear on the usage of MemoryBarrier, but not on what happens behind the scenes in the runtime. Can anyone give a good explanation of what goes on?

Can someone provide an easy explanation of how 'Full Fences' are implemented in .Net using Threading.MemoryBarrier?

编译器

我很清楚MemoryBarrier的用法，但不清楚运行时幕后发生了什么。有没有人能给出一个很好的解释？

问有人能简单解释一下如何使用Threading.MemoryBarrier在.Net中实现“全围栏”吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问有人能简单解释一下如何使用Threading.MemoryBarrier在.Net中实现“全围栏”吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问有人能简单解释一下如何使用Threading.MemoryBarrier在.Net中实现“全围栏”吗？
EN