比賽條件檢測工具

Question

我想測試一個大型複雜（超過130M LOC）的服務器應用程序的競賽條件。該應用程序使用C和C++編寫，並在64位Linux上運行。我做了一些研究並提出了一些動態工具（例如，Intel檢查員，Tsan，Helgrind & DRD）和一些靜態工具（例如RELAY，RacerX）。

動態工具應該更準確（誤報率更低），並且可以處理自定義同步機制，但是會施加顯着的運行時間開銷，從而觸發應用程序的超時。靜態工具的問題在於，它似乎主要是學術性的，而不是維護（例如，RELAY的最新版本是從2010年開始的）。

目前我正在考慮使用Tsan並擴展應用程序的計時器以適應額外的開銷。有沒有人面臨類似的挑戰，並有一些我可能錯過的見解？

Answer 1

不幸的是，我認爲這可能是過去的「基於意見的」問題，但我會嘗試一下。

如果不瞭解應用程序的任何內容，幾乎不可能說出使用tsan時可能需要考慮的內容。在我設計的一個較小的（103k LOC）項目中，專爲高吞吐量網絡設計，設計測試以運行各種代碼路徑並測試它們幾乎總是足夠的。我從來沒有需要拉伸計時器或超時。我想如果你有一些硬實時限制（我不這樣做），這可能會有問題。我沒有經歷過燦燦的開銷，而且過於龐大。

我會注意到的一件事是，tsan在併發數據結構（例如由concurrencykit等提供的那些結構）中表現不佳。這是因爲這些併發數據結構的實現通常依賴於檢測數據競爭來確定執行行爲。

例如，考慮具有兩個併發消費者的完整環形緩衝區。讀者可能會被標記爲正面競跑，因爲他們會這樣做。然而，消費者在原子comare-and-swap操作上線性化，以將遞增的讀取值設置爲環的下一個索引。如果交換失敗，操作將被重試。因此，雖然讀寫可以競賽，但是正確性是有保證的。

從tsan的角度來看，這些不被視爲誤報，因爲它們是實際的數據競賽。另一方面，它們對於所有實際目的都是誤報，因爲它們實際上不會導致任何錯誤或未定義的行爲。有些方法可以測試代碼以避免這種情況發生，但是當我嘗試它時，它的價值比它的價值更加麻煩。這取決於你的輸出有多嘈雜。

另請注意，如果您的應用程序調用未裝配的庫（libc，openssl，無論），您將錯過潛在的競賽。如果一場比賽發生併發呼叫到一個沒有文書的圖書館，你將錯過比賽。

如果使用燦，不要忘了使用-fno-omit-frame-pointer（不要忘了地方後任何-Olevel選項）。否則，你會在地獄addr2line，或被迫重建。

不幸的是，我沒有任何有關您列出的其他實用程序的經驗，但因爲您的問題似乎與特定的金融危機有關，所以我希望這會有所幫助。