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