lock-free  編程實在讓人又愛又恨。博主以前曾經(jīng)寫過幾篇關(guān)于 lock-free 編程的文章。比如關(guān)于無鎖編程、并發(fā)數(shù)據(jù)結(jié)構(gòu):迷人的原子。如果想更加深入的了解和實踐 lock-free 編程，可以參考CLR 2.0 Memory Model、并發(fā)數(shù)據(jù)結(jié)構(gòu):Stack。這篇文章并不打算繼續(xù)闡述如何使用 lock-free 技術(shù)，而是談一下它的負(fù)面影響。從而讓大家對 lock-free 有個更加全面的認(rèn)識。

　　說到 lock-free 編程，現(xiàn)實中經(jīng)常使用 CAS 原語。CAS 是英文 Compare and Swap 的簡寫。在 Windows 和 .NET 平臺，由于歷史原因，它被寫做 Interlocked API。原子操作在 x86 架構(gòu) CPU 對應(yīng)的匯編指令有 XCHG、CMPXCHG、INC 等，當(dāng)然還得加上 LOCK 作為前綴(更多信息請看 并發(fā)數(shù)據(jù)結(jié)構(gòu):迷人的原子)。

　　CAS 原語在輕度和中度爭用情況下確實可以大幅度提高程序性能。但凡事有利必有弊，CAS 原語極度扼殺了程序的可伸縮性(其他缺點請看關(guān)于無鎖編程)。各位看官可能覺得這種觀點有點偏激，但事實如此。請容博主細(xì)細(xì)道來：

• CAS 的原子性完全取決于硬件實現(xiàn)。大多數(shù) Intel 和 AMD 的 CPU 采用了一種叫做 MOSEI 緩存一致性協(xié)議來管理緩存。這種架構(gòu)下，處理器緩存內(nèi) CAS 操作相對成本低廉。但一旦資源爭用，就會引起緩存失效和總線占用。緩存越失效，總線越被占用，完成 CAS 操作也越被延遲。緩存爭用是程序可伸縮性殺手。當(dāng)然對于非 CAS 內(nèi)存操作來說也是如此，但 CAS 情況更加槽糕。
• CAS 操作要比普通內(nèi)存操作花費更多 CPU 周期。這歸功于緩存分級的額外負(fù)擔(dān)、刷新寫緩沖區(qū)與穿越內(nèi)存柵欄限制和需求以及編譯器對 CAS 操作優(yōu)化的能力。
• CAS 經(jīng)常被用在優(yōu)化并行操作上。這意味著 CAS 操作失敗將導(dǎo)致重新嘗試某些指令(典型的回滾操作)。即便沒有任何爭用，它也會做一些無用功。不論成功或失敗都會增加爭用的風(fēng)險。

　　大多數(shù) CAS 操作發(fā)生在鎖進入和退出時。盡管鎖可由單一 CAS 操作構(gòu)建，但 .NET CLR Monitor 類卻使用了兩個(一個在 Enter 方法，另一個在 Exit 方法)。lock-free 算法也經(jīng)常使用 CAS 原語來代替使用鎖機制。但是由于內(nèi)存重組，這樣的算法也常常需要顯式的柵欄，即便使用了 CAS 指令。鎖機制非常邪惡，但大多數(shù)合格的開發(fā)人員都知道讓鎖持有盡量少的時間。因此，雖然鎖機制讓人非常討厭，且影響性能。但相對于大量，頻繁的 CAS 操作而言，它卻并不影響程序的可伸縮性。

　　舉個很簡單的例子，增加計數(shù) 100,000,000 次。要做到這樣，有幾種方式。如果僅運行在單核單處理器上，我們可以使用普通的內(nèi)存操作：

static volatile int counter = 0;static void BaselineCounter(){    for (int i = 0; i < Count; i++)    {        counter++;    }}

　　很明顯，上述代碼示例不是線程安全的，但給計數(shù)器提供了一個很好的時間基準(zhǔn)。下面我們使用 LOCK INC 來作為線程安全的第一種方式：

static volatile int counter = 0;static void LockIncCounter(){    for (int i = 0; i < Count; i++)    {        Interlocked.Increment(ref counter);    }}

　　現(xiàn)在代碼示例線程安全了。我們還可以采取另外一種方式來保證線程安全。如果需要執(zhí)行一些驗證(比如內(nèi)存溢出保護)，我們通常會使用這種方式。就是使用 CMPXCHG(即 CAS)：

static volatile int counter = 0;static void CASCounter(){    for (int i = 0; i < Count; i++)    {        int oldValue;        do        {            oldValue = counter;        }        while (Interlocked.CompareExchange(ref counter, oldValue + 1, oldValue) != oldValue);    }}

　　現(xiàn)在問一個有意思的問題：當(dāng)緩存爭用時，哪一個方法更慢？結(jié)果可能會讓你大吃一驚哦。

　　在 Intel 4 核處理器下測試結(jié)果如下：

　　圖中，當(dāng) CPU 使用 2 個核時，BaselineCounter 方法是單核單路情況的 2.11 倍。其他情況類似。通過結(jié)果比對，我們可以得知：更多的并發(fā)性導(dǎo)致結(jié)果更加槽糕。這很大部分原因由內(nèi)存爭用所致。

　　當(dāng) CAS 操作失敗，通過旋轉(zhuǎn)等待可以改善 CASCounter 方法的在多核處理器上的性能(具體技巧可以參考夏天是個好季節(jié)兄的自己動手實現(xiàn)一個輕量級的信號量（一）、（二）)。這可以大大減少活鎖和關(guān)聯(lián)內(nèi)聯(lián)阻礙鎖耗費的時間。

　　當(dāng)然，這個示例非常極端。它頻繁反復(fù)修改同一個內(nèi)存地址。通過期間插入特定的函數(shù)調(diào)用，延遲訪問共享內(nèi)存可以極大緩解壓力。

　　比如插入 2 個函數(shù)調(diào)用，我們得到了如下數(shù)據(jù)：

　　插入 64 個函數(shù)調(diào)用之后，數(shù)據(jù)又變成了如下所示：

　　這個時候，我們看到多核所花費的時間少于單核了。這就是我們使用并行所帶來的加速。看到這里，我們可能會想，既然從 2 到 64 個函數(shù)調(diào)用使得結(jié)果越來越好，那么超過 64 個函數(shù)調(diào)用豈不是會變得更好？實際上，在插入 128 個函數(shù)調(diào)用之后，加速已經(jīng)達到極限。結(jié)果如下所示：

　　如何計算加速比，請參考并行思維 [II]。

　　天下沒有免費的午餐，CAS 也不例外。我們應(yīng)當(dāng)慎之又慎的將 lock-free CAS 代碼放到我們的代碼中，且必須清楚的知道線程執(zhí)行它們的頻繁程度。我們可以用下面這句話來作為總結(jié)：共享是魔鬼。它從根本上限制應(yīng)用程序可伸縮性，最好盡量避免。共享內(nèi)存需要并發(fā)控制，而并發(fā)控制需要 CAS。CAS 又非常昂貴，因此共享內(nèi)存也非常昂貴。有很多人提出 lock-free 技術(shù)，事務(wù)內(nèi)存，讀寫鎖等可以改善程序可伸縮性。但很遺憾，這種情況很少出現(xiàn)。CAS 往往比正確實現(xiàn)鎖機制的解決方案更加糟糕。很大原因要歸結(jié)于共享內(nèi)存、樂觀失敗嘗試、緩存失效等。

overred 兄在 review 這篇文章的時候，提了一個很好的問題：在使用 Interlocked API 的時候，共享變量不用 volatile 修飾。

　　為了更方便說明這個問題，俺寫個簡單點的代碼示例，如下所示：

using System;namespace Lucifer.CSharp.Sample{    class Program    {        static volatile int x;        static void Main(string[] args)        {            Foo(ref x);        }        static void Foo(ref int y)        {            while (y == 0) ;        }    }}

　　當(dāng)我們在 Visual Studio 中編譯這段代碼時，IDE 會給出編譯警告，如下所示：

　　通常來說，我們對于這樣的編譯警告應(yīng)該給予足夠重視。比如在上面的例子中，JIT 編譯器會認(rèn)為 y 一直未變，從而引起死循環(huán)。在 IA64 平臺上，這會被認(rèn)為普通內(nèi)存訪問代替了特殊的 load-acquire 訪問，這就可能導(dǎo)致 CPU 指令重組方面的一些 Bug。但是有一種情況例外，就是使用 Interlocked API 和 Thread.VolatileXXX 方法以及鎖。因為這些 API 內(nèi)部都會顯式要求內(nèi)存柵欄和硬件原子指令，而不管外部共享變量是否采用 volatile 修飾。因此，文中采用的測試方法還是很安全嘀。

　　如果你覺得這個編譯警告很煩人，可以使用 #pragma 指令禁掉這種警告，如下所示：

static volatile int x;static void Foo(){#pragma warning disable 0420    Interlocked.Exchange(ref x, 1);#pragma warning restore 0420}

　　當(dāng)然，也可以完全不用 volatile 修飾符。CLR 內(nèi)存模型保證了這一點。

　　如何正確使用 volatile ，請參考并發(fā)數(shù)據(jù)結(jié)構(gòu):談?wù)剉olatile變量。

NET技術(shù)：再說 lock-free 編程，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。