查了下MSDN的解释:

         MemoryBarrier is required only on multiprocessor systems with weak memory ordering (for example, a system employing multiple Intel Itanium processors).         Synchronizes memory access as follows: The processor executing the current thread cannot reorder instructions in such a way that memory accesses prior to the call to MemoryBarrier execute after memory accesses that follow the call to MemoryBarrier.        就是说多核处理器会对运行CPU指令顺序重排优化,MemoryBarrier可以阻止指令重排,调用Thread.MemoryBarrier()之后的代码中内存访问不能再这之前就完成了。也就是它可以限制指令重排和内存读写的缓存。     下面有段代码,在release编译情况下会死循环(debug应该是没做instructions reorder而不会有问题)        bool complete = false;        var t = new Thread(() =>        {            bool toggle = false;            while (!complete)                toggle = !toggle;        });        t.Start();        Thread.Sleep(1000);        complete = true;        t.Join();

问题原因:

1.编译器、CLR或者CPU可能重新排序了程序指令,以此提高效率。

2.编译器、CLR或者CPU引入缓存优化导致其他的线程不能马上看到变量值的更改。

尝试了下将Thread.MomoryBarrier加到while中,保证complete读到的最新的:

此例子中MomoryBarrier 应该时解决jit时过度优化,虽然两个核心cache line 不会及时同步,complete 值修改通过MSIE协议也很快的通知到其他核心。

出现死循环在于jit 任魏complete值一直是false,并没有执行load操作,而是直接判断true跳转。

        bool complete = false;        var t = new Thread(() =>        {            bool toggle = false;            while (!complete)            {               Thread.MemoryBarrier();                toggle = !toggle;            }        });        t.Start();        Thread.Sleep(1000);        complete = true;        t.Join();

在看一个例子:(来自《window 并发编程指南》内存模型部分) MyObject mo= ..; int f= mo.field; if(f==0) { 　　//same operation 　　Console.WriteLine(f); } 如果mo.field 在读取和Console.WriteLine相隔足够远,那么编译器可能会认为读mo.field 读取两遍会更有效,被编译成如下代码: MyObject mo= ..; if(mo.filed==0) { 　　//same operation 　　Console.WriteLine(mo.field); } 编译器可能判断,保留这个值是否给寄存器带来压力并导致栈空间的低效使用,并且之个分支是否很少被使用(因此f值就不需要多次) 这样带来多线程问题,将f值使用volatitle修饰,可禁止这种优化

我看:多线程才会出现吧!!

157894.html