以前我們說過在一些簡單的例子中，比如為一個字段賦值或遞增該字段，我們需要對線程進行同步，
雖然lock可以滿足我們的需要，但是一個競爭鎖一定會導致阻塞，然后忍受線程上下文切換和調度的開銷,在一些高并發(fā)和性能比較關鍵的地方，這些是不能忍受的。
.net framework 提供了非阻塞同步構造，為一些簡單的操作提高了性能，它甚至都沒有阻塞，暫停，和等待線程。
Memory Barriers and Volatility (內存柵欄和易失字段 )
考慮下下面的代碼：
int _answer;
bool _complete;
void A()
{
_answer = 123;
_complete = true;
}
void B()
{
if (_complete)
Console.WriteLine(_answer);
}
如果方法A和B都在不同的線程下并發(fā)的執(zhí)行，方法B可能輸出 “0” 嗎？回答是“yes”，基于以下原因：
編譯器，clr 或 cpu 可能會為了性能而重新為程序的指令進行排序,例如可能會將方法A中的兩句代碼的順序進行調整。
編譯器，clr 或 cpu 可能會為變量的賦值采用緩存策略，這樣這些變量就不會立即對其他變量可見了，例如方法A中的變量賦值，不會立即刷新到內存中，變量B看到的變量并不是最新的值。
C# 和運行時非常小心的保證這些優(yōu)化策略不會影響正常的單線程的代碼和在多線程環(huán)境下加鎖的代碼。
除此之外，你必須顯示的通過創(chuàng)建內存屏障(Memory fences) 來限制指令重新排序和讀寫緩存對程序造成的影響。
Full fences:
最簡單的完全柵欄的方法莫過于使用Thread.MemoryBarrier方法了。
以下是msdn的解釋：
Thread.MemoryBarrier: 按如下方式同步內存訪問：執(zhí)行當前線程的處理器在對指令重新排序時，不能采用先執(zhí)行 MemoryBarrier 調用之后的內存訪問，再執(zhí)行 MemoryBarrier 調用之前的內存訪問的方式。
按照我個人的理解：就是寫完數(shù)據(jù)之后，調用MemoryBarrier，數(shù)據(jù)就會立即刷新，另外在讀取數(shù)據(jù)之前調用MemoryBarrier可以確保讀取的數(shù)據(jù)是最新的，并且處理器對MemoryBarrier的優(yōu)化小心處理。
int _answer;
bool _complete;
void A()
{
_answer = 123;
Thread.MemoryBarrier(); //在寫完之后，創(chuàng)建內存柵欄
_complete = true;
Thread.MemoryBarrier();//在寫完之后，創(chuàng)建內存柵欄
}
void B()
{
Thread.MemoryBarrier();//在讀取之前，創(chuàng)建內存柵欄
if (_complete)
{
Thread.MemoryBarrier();//在讀取之前，創(chuàng)建內存柵欄
Console.WriteLine(_answer);
}
}
一個完全的柵欄在現(xiàn)代桌面應用程序中，大于需要花費10納秒。
下面的一些構造都隱式的生成完全柵欄。 C# Lock 語句(Monitor.Enter / Monitor.Exit)
在Interlocked類的所有方法。
使用線程池的異步回調，包括異步的委托，APM 回調，和 Task continuations.
在一個信號構造中的發(fā)送(Settings)和等待(waiting)
你不需要對每一個變量的讀寫都使用完全柵欄，假設你有三個answer 字段，我們仍然可以使用4個柵欄。例如:
int _answer1, _answer2, _answer3;
bool _complete;
void A()
{
_answer1 = 1; _answer2 = 2; _answer3 = 3;
Thread.MemoryBarrier(); //在寫完之后，創(chuàng)建內存柵欄
_complete = true;
Thread.MemoryBarrier(); //在寫完之后，創(chuàng)建內存柵欄
}
void B()
{
Thread.MemoryBarrier(); //在讀取之前，創(chuàng)建內存柵欄
if (_complete)
{
Thread.MemoryBarrier(); //在讀取之前，創(chuàng)建內存柵欄
Console.WriteLine(_answer1 + _answer2 + _answer3);
}
}
我們真的需要lock 和內存柵欄嗎？
在一個共享可寫的字段上不使用lock 或者柵欄 就是在自找麻煩，在msdn上有很多關于這方面的主題。
考慮下下面的代碼：
public static void Main()
{
bool complete = false;
var t = new Thread(() =>
{
bool toggle = false;
while (!complete) toggle = !toggle;
});
t.Start();
Thread.Sleep(1000);
complete = true;
t.Join();
}
如果你在Visual Studio中選擇發(fā)布模式，生成該應用程序，那么如果你直接運行應用程序，程序都不會中止。
因為CPU 寄存器把 complete 變量的值給緩存了。在寄存器中，complete永遠都是false。
通過在while循環(huán)中插入Thread.MemoryBarrier，或者是在讀取complete的時候加鎖 都可以解決這個問題。
volatile 關鍵字
為_complete字段加上volatile關鍵字也可以解決這個問題。
volatile bool _complete.
Volatile關鍵字會指導編譯器自動的為讀寫字段加屏障.以下是msdn的解釋：
volatile 關鍵字指示一個字段可以由多個同時執(zhí)行的線程修改。聲明為 volatile 的字段不受編譯器優(yōu)化（假定由單個線程訪問）的限制。這樣可以確保該字段在任何時間呈現(xiàn)的都是最新的值。
使用volatile字段可以被總結成下表：
第一條指令 | 第二條指令 | 可以被交換嗎？ |
Read | Read | No |
Read | Write | No |
Write | Write | No(CLR會確保寫和寫的操作不被交換，甚至不使用volatile關鍵字) |
Write | Read | Yes! |
注意到應用volatile關鍵字，并不能保證寫后面跟讀的操作不被交換，這有可能會造成莫名其妙的問題。例如：
volatile int x, y;
void Test1()
{
x = 1; //Volatile write
int a = y; //Volatile Read
}
void Test2()
{
y = 1; //Volatile write
int b = x; //Volatile Read
}
如果Test1和Test2在不同的線程中并發(fā)執(zhí)行，有可能a 和b 字段的值都是0,（盡管在x和y上應用了volatile 關鍵字）這是一個避免使用volatile關鍵字的好例子，甚至假設你徹底的明白了這段代碼，是不是其他在你的代碼上工作的人也全部明白呢？。
在Test1 和Test2方法中使用完全柵欄或者是lock都可以解決這個問題，
還有一個不使用volatile關鍵字的原因是性能問題，因為每次讀寫都創(chuàng)建了內存柵欄，例如
volatile m_amount
m_amount = m_amount + m_amount.
Volatile 關鍵字不支持引用傳遞的參數(shù)，和局部變量。在這樣的場景下，你必須使用VolatileRead和VolatileWrite方法。例如
volatile int m_amount;
Boolean success =int32.TryParse(“123”,out m_amount);
//生成如下警告信息：
//cs0420:對volatile字段的引用不被視為volatile.
VolatileRead 和VolatileWrite從技術上講，Thread類的靜態(tài)方法VolatileRead和VolatileWrite在讀取一個 變量上和volatile 關鍵字的作用一致。
他們的實現(xiàn)是一樣是低效率的，盡管事實上他們都創(chuàng)建了內存柵欄。下面是他們在integer類型上的實現(xiàn)。
public static void VolatileWrite(ref int address, int value)
{
Thread.MemoryBarrier(); address = value;
}
public static int VolatileRead(ref int address)
{
int num = address; Thread.MemoryBarrier(); return num;
}
你可以看到如果你在調用VolatileWrite之后調用VolatileRead，在中間沒有柵欄會被創(chuàng)建，這同樣會導致我們上面講到寫之后再讀順序可能變換的問題。
