MemoryBarrier[通俗易懂]

查了下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); } 編譯器可能判斷,保留這個值是否給寄存器帶來壓力并導致?？臻g的低效使用,并且之個分支是否很少被使用(因此f值就不需要多次) 這樣帶來多線程問題,將f值使用volatitle修飾,可禁止這種優化

我看:多線程才會出現吧!!

157894.html