靜態(tài)分析工具構(gòu)建模型實(shí)現(xiàn)多核處理器的高質(zhì)量

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

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

數(shù)據(jù)競爭是一種特殊類型的競爭條件，它涉及對(duì)多線程程序中內(nèi)存位置的并發(fā)訪問。當(dāng)有兩個(gè)或多個(gè)執(zhí)行線程訪問共享內(nèi)存位置，至少一個(gè)線程正在更改該位置的數(shù)據(jù)，并且沒有明確的協(xié)調(diào)訪問機(jī)制時(shí)，就會(huì)出現(xiàn)此缺陷。如果發(fā)生數(shù)據(jù)競爭，它會(huì)使程序處于不一致的狀態(tài)。

數(shù)據(jù)競爭的陰險(xiǎn)本質(zhì)

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

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

if （！initialized） {

object = create（）;

initialized = true;

}

。.. object 。..

這段代碼完全適合單線程程序，但它不是線程安全的，因?yàn)樗诿麨閕nitialized的變量上存在數(shù)據(jù)競爭。如果由兩個(gè)不同的線程調(diào)用，則存在兩個(gè)線程幾乎同時(shí)觀察到初始化為 false 的風(fēng)險(xiǎn)，并且都將調(diào)用create（），從而違反了單例屬性。

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

if （！initialized） {

lock（）;

if （！initialized） {

object = create（）;

initialized = true;

}

unlock（）;

}

。.. object 。..

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

優(yōu)化編譯器是不可思議的野獸。那些優(yōu)化速度的人會(huì)考慮許多深?yuàn)W的考慮，其中很少有對(duì)程序員來說是顯而易見的。它們通常會(huì)生成明顯無序的指令，因?yàn)檫@樣做可能會(huì)導(dǎo)致更少的高速緩存未命中，或者因?yàn)樾枰俚闹噶睢?/p>

假設(shè)因?yàn)橹匦屡判蛟谇懊娴氖纠幸肓烁偁帡l件，所以認(rèn)為編譯器有問題是錯(cuò)誤的。編譯器正在做它被允許做的事情。語言規(guī)范對(duì)此非常清楚和明確：允許編譯器假設(shè)程序中沒有數(shù)據(jù)競爭。

實(shí)際上，規(guī)范更廣泛：允許編譯器在存在未定義行為的情況下做任何事情。這有時(shí)被開玩笑地稱為著火語義；如果程序具有未定義的行為，該規(guī)范允許編譯器將計(jì)算機(jī)置于火上。除了數(shù)據(jù)競爭之外，緩沖區(qū)溢出、無效地址的取消引用等許多傳統(tǒng)錯(cuò)誤也構(gòu)成了未定義的行為。因?yàn)榫幾g器可以自由地做任何事情，而不是燒毀建筑物，他們通常會(huì)做明智的事情，即假設(shè)未定義的行為永遠(yuǎn)不會(huì)發(fā)生并相應(yīng)地進(jìn)行優(yōu)化。

即使對(duì)于并發(fā)和編譯器方面的專家來說，這樣做的后果有時(shí)也會(huì)令人驚訝。很難讓程序員相信看起來完全正確的代碼可以編譯成有嚴(yán)重錯(cuò)誤的代碼。

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

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

生成錯(cuò)誤代碼的第二種方式更為微妙。假設(shè)讀者做了以下事情，其中??數(shù)據(jù)競爭在名為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 變量的本地副本并引用該值兩次?？梢院侠淼仄谕麅蓚€(gè)地方的值相同，但同樣，優(yōu)化編譯器可以生成未滿足期望的代碼。如果將local分配給一個(gè)寄存器，那么它將有一個(gè)值用于第一次比較，但如果兩個(gè)條件之間的代碼足夠重要，那么該寄存器可能會(huì)溢出——換句話說，為了不同的目的而重用。在這種情況下，在第二個(gè)條件下，local的值將從全局變量重新加載到寄存器中，此時(shí)編寫器可能已將其更改為不同的值。

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

發(fā)現(xiàn)風(fēng)險(xiǎn)缺陷的技術(shù)

在發(fā)現(xiàn)并發(fā)缺陷時(shí)，傳統(tǒng)的動(dòng)態(tài)測試技術(shù)可能不夠用。一個(gè)通過一百次測試的程序并不能保證下一次通過，即使是相同的輸入和相同的環(huán)境。這些錯(cuò)誤是否出現(xiàn)對(duì)時(shí)間非常敏感，線程中的操作交錯(cuò)的順序本質(zhì)上是不確定的。

用于發(fā)現(xiàn)數(shù)據(jù)競爭的新動(dòng)態(tài)測試技術(shù)正在出現(xiàn)。這些技術(shù)通過在應(yīng)用程序執(zhí)行時(shí)監(jiān)視它們并觀察每個(gè)線程持有的鎖以及這些線程正在訪問的內(nèi)存位置來工作。如果發(fā)現(xiàn)異常，則發(fā)出診斷。其他工具有助于診斷可能導(dǎo)致故障的數(shù)據(jù)競爭。一些公司現(xiàn)在提供工具來促進(jìn)數(shù)據(jù)競爭的診斷，從而允許重播導(dǎo)致異常的事件。

靜態(tài)分析工具也可用于查找數(shù)據(jù)競爭和其他并發(fā)錯(cuò)誤。動(dòng)態(tài)測試工具會(huì)發(fā)現(xiàn)針對(duì)具有固定輸入集的程序的特定執(zhí)行出現(xiàn)的缺陷，而靜態(tài)分析工具會(huì)檢查所有可能的執(zhí)行和所有可能的輸入。出于性能原因，工具可能會(huì)限制進(jìn)行多少探索，因此可能并不完全詳盡；即便如此，它們可以涵蓋的范圍遠(yuǎn)遠(yuǎn)超過動(dòng)態(tài)測試所能實(shí)現(xiàn)的范圍。靜態(tài)分析的優(yōu)點(diǎn)是不需要測試用例，因?yàn)槌绦驈奈凑嬲龍?zhí)行過。

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

一旦發(fā)現(xiàn)，數(shù)據(jù)競爭通常很容易修復(fù)，盡管這樣做會(huì)導(dǎo)致性能損失。在某些情況下，可能會(huì)嘗試使用 C 中的 volatile 關(guān)鍵字來糾正數(shù)據(jù)爭用，但不建議這樣做，因?yàn)?volatile 并非旨在解決并發(fā)問題，并且在任何情況下都是一個(gè)難以理解的構(gòu)造，經(jīng)常被錯(cuò)誤編譯。最新版本的 C 和 C++ 包含并發(fā)并支持原子操作。對(duì)這些操作的編譯器支持正在慢慢出現(xiàn)，在它變得可用之前，最好的方法是使用鎖。

為了實(shí)現(xiàn)多核處理器的高質(zhì)量軟件，建議對(duì)數(shù)據(jù)競爭采取零容忍政策。使用靜態(tài)和動(dòng)態(tài)技術(shù)的組合來查找它們，并注意不要過度依賴深?yuàn)W的編譯器技術(shù)來修復(fù)它們。這些缺陷是如此危險(xiǎn)和不可預(yù)測，因此系統(tǒng)地消除它們是確保它們不會(huì)造成傷害的唯一安全方法。