對多核處理器進行編程以利用其強大功能意味著編寫多線程代碼。C 和 C++ 不是為并發而設計的，因此開發人員必須為這些語言使用諸如 pthreads 之類的庫。由于全新類別的編程缺陷帶來的風險，多線程代碼比單線程代碼更難正確處理。

在流氓的并發錯誤庫中，競爭條件是臭名昭著的屢犯者。競爭條件發生在程序檢查資源屬性并假設該屬性沒有更改的情況下執行操作，即使外部參與者已經介入并更改了該屬性。

數據競爭是一種特殊類型的競爭條件，它涉及對多線程程序中內存位置的并發訪問。當有兩個或多個執行線程訪問共享內存位置，至少一個線程正在更改該位置的數據，并且沒有明確的協調訪問機制時，就會出現此缺陷。如果發生數據競爭，它會使程序處于不一致的狀態。

數據競爭的陰險本質

人們普遍認為，一些數據競爭是無害的，可以安全地忽略。不幸的是，這僅在極少數情況下是正確的。最好通過舉例說明原因。

單例模式是一種常見的習慣用法，其中程序維護對單個底層對象的引用，如果已初始化，則布爾變量對其進行編碼。這種模式也稱為延遲初始化。以下代碼是該模式的示例：

if （！initialized） {

object = create（）;

initialized = true;

}

。。. 目的 。。.

這段代碼完全適合單線程程序，但它不是線程安全的，因為它在名為initialized的變量上存在數據競爭。如果由兩個不同的線程調用，則存在兩個線程幾乎同時觀察到初始化為 false 的風險，并且都將調用create（），從而違反了單例屬性。

為了使這個線程安全，自然的方法是用鎖保護整個if語句。然而，獲取和釋放鎖的成本可能很高，因此程序員試圖通過使用雙重檢查鎖定習慣用法來避免這種成本——在鎖范圍之外進行檢查，在鎖范圍內進行檢查。內部檢查用于確認在獲得鎖后第一個檢查仍然有效：

if （！initialized） {

lock（）;

if （！initialized） {

object = create（）;

initialized = true;

}

unlock（）;

}

。。. 目的 。。.

從表面上看，這看起來就足夠了，實際上，只要保證語句按該順序執行就足夠了。但是，優化編譯器可能會生成實質上切換object = create（）和initialized = true順序的代碼。畢竟，這兩個語句之間沒有明確的依賴關系。在這種情況下，如果第二個線程在分配給initialized之后的任何時間進入此代碼，則該線程將在object被初始化之前使用它的值。

優化編譯器是不可思議的野獸。那些優化速度的人會考慮許多深奧的考慮，其中很少有對程序員來說是顯而易見的。他們通常會生成明顯無序的指令，因為這樣做可能會導致更少的高速緩存未命中，或者因為需要更少的指令。

假設因為重新排序在前面的示例中引入了競爭條件，所以認為編譯器有問題是錯誤的。編譯器正在做它被允許做的事情。語言規范對此非常清楚和明確：允許編譯器假設程序中沒有數據競爭。

實際上，規范更廣泛：允許編譯器在存在未定義行為的情況下做任何事情。這有時被開玩笑地稱為著火語義；如果程序具有未定義的行為，該規范允許編譯器將計算機置于火上。除了數據競爭之外，緩沖區溢出、無效地址的取消引用等許多傳統錯誤也構成了未定義的行為。因為編譯器可以自由地做任何事情，而不是燒毀建筑物，他們通常會做明智的事情，即假設未定義的行為永遠不會發生并相應地進行優化。

即使對于并發和編譯器方面的專家來說，這樣做的后果有時也會令人驚訝。很難讓程序員相信看起來完全正確的代碼可以編譯成有嚴重錯誤的代碼。

另一個例子是值得描述的。假設有兩個線程，一個讀取共享變量，另一個寫入共享變量。讓我們假設讀者在寫入者更改之前或之后看到該值并不重要（這不是一種不常見的模式）。如果這些訪問不受鎖保護，那么顯然存在數據競爭。然而，盡管著火規則，大多數程序員會得出結論，這是完全良性的。

事實證明，至少有兩種合理的方式可以編譯這段代碼，讀者會看到錯誤的值。第一種方法很容易解釋：假設該值是一個只能讀取 32 位字的架構上的 64 位數量。那么讀者和作者都需要兩條指令，不幸的交錯可能意味著讀者看到舊值的前 32 位和新值的后 32 位，當它們組合時可能不是舊值也不是新的。

生成錯誤代碼的第二種方式更為微妙。假設讀者做了以下事情，其中??數據競爭在名為global的變量上：

int local = global; // Take a copy of

// the global

if （local == something） {

。..

}

。.. // Some non-trivial code that does

// not change global or local

if （local == something） {

。..

}

在這里，讀者正在制作 racy 變量的本地副本并引用該值兩次。可以合理地期望兩個地方的值相同，但同樣，優化編譯器可以生成未滿足期望的代碼。如果將local分配給一個寄存器，那么它將有一個值用于第一次比較，但如果兩個條件之間的代碼足夠重要，那么該寄存器可能會溢出——換句話說，為了不同的目的而重用。在這種情況下，在第二個條件下，local的值將從全局變量重新加載到寄存器中，此時編寫器可能已將其更改為不同的值。

程序員應該非常懷疑某些數據競爭是可以接受的，并且應該努力從他們的代碼中找到并刪除它們。

發現風險缺陷的技術

在發現并發缺陷時，傳統的動態測試技術可能不夠用。一個通過一百次測試的程序并不能保證下一次通過，即使是相同的輸入和相同的環境。這些錯誤是否出現對時間非常敏感，線程中的操作交錯的順序本質上是不確定的。

用于發現數據競爭的新動態測試技術正在出現。這些技術通過在應用程序執行時監視它們并觀察每個線程持有的鎖以及這些線程正在訪問的內存位置來工作。如果發現異常，則發出診斷。其他工具有助于診斷可能導致故障的數據競爭。一些公司現在提供工具來促進數據競爭的診斷，從而允許重播導致異常的事件。

靜態分析工具也可用于查找數據競爭和其他并發錯誤。動態測試工具會發現針對具有固定輸入集的程序的特定執行出現的缺陷，而靜態分析工具會檢查所有可能的執行和所有可能的輸入。出于性能原因，工具可能會限制進行多少探索，因此可能并不完全詳盡；即便如此，它們可以涵蓋的范圍遠遠超過動態測試所能實現的范圍。靜態分析的優點是不需要測試用例，因為程序從未真正執行過。

相反，這些工具通過創建程序模型然后以各種方式探索模型以發現異常來工作。GrammaTech 的 CodeSonar 通過創建表示每個線程持有的鎖集的模型并通過執行探索執行路徑的程序的符號執行來發現數據競爭。它記錄受鎖保護的變量集，并使用此信息來查找可能導致共享變量在沒有適當同步的情況下使用的交錯。類似的技術可用于發現其他并發缺陷，例如死鎖和鎖管理不善。

一旦發現，數據競爭通常很容易修復，盡管這樣做會導致性能損失。在某些情況下，可能會嘗試使用 C 中的 volatile 關鍵字來糾正數據爭用，但不建議這樣做，因為 volatile 并非旨在解決并發問題，并且在任何情況下都是一個難以理解的構造，經常被錯誤編譯。最新版本的 C 和 C++ 包含并發并支持原子操作。對這些操作的編譯器支持正在慢慢出現，在它變得可用之前，最好的方法是使用鎖。

為了實現多核處理器的高質量軟件，建議對數據競爭采取零容忍政策。使用靜態和動態技術的組合來查找它們，并注意不要過度依賴深奧的編譯器技術來修復它們。這些缺陷是如此危險和不可預測，因此系統地消除它們是確保它們不會造成傷害的唯一安全方法。

審核編輯：郭婷