valgrind在多線程套接字程序中失速

Question

我正在使用valgrind運行多線程套接字程序。客戶端將通過TCP向服務器發送請求，然後忙於等待布爾值。當調用服務於服務器響應的回調函數時，布爾值將被設置。一旦接收到響應（並設置了布爾標誌），服務器將再次發出請求，並在循環中重複執行此操作。我知道對共享變量（布爾值）的非同步訪問可能會導致線程問題，但我嘗試過使用pthread互斥體，並且程序減速了大約20％（這裏速度很重要）。我相信寫入共享布爾變量是好的，因爲它可以在一個週期內完成。

該程序在valgrind之外運行良好，但通常在使用valgrind運行時會停止運行。我離開程序在一夜之間運行..通常需要幾秒鐘才能完成，所以我不認爲這是一個等待程序完成的時間不夠的情況。線程由開源引擎框架（快速修復）管理，所以我認爲這不是線程創建/管理的問題。

有沒有人知道valgrind圍繞多線程程序/繁忙的等待循環/套接字通信（或這些組合）的任何問題？

Answer 1

雖然其他答案的重點是堅持採用標準同步方法（我完全同意這一點），但我認爲應該回答你關於Valgrind的問題。

據我所知，Valgrind在多線程環境下運行時沒有問題。我相信Valgrind強制應用程序在單核上運行，但除此之外它不應該影響你的線程。

Valgrind可能對您的應用程序做了什麼，正在改變線程之間的時序和交互方式，可能會暴露代碼中的錯誤和競態條件，您在單獨運行時通常不會看到這些錯誤和競爭條件。

您應用相同的邏輯來判斷您使用的開源代碼線程框架中的錯誤不適用於我認爲的Valgrind。我建議您將這些掛起視爲代碼中的錯誤並對其進行調試，因爲這很可能是它們的原因。

作爲一個方面說明，使用互斥對您描述的問題可能是過度的。您應該調查信號量或條件變量。

祝你好運。

Answer 2

讀取/寫入布爾值不是x86上的原子操作。

見我的問題在這裏：Is volatile a proper way to make a single byte atomic in C/C++?

Answer 3

即使寫你的布爾是一個原子操作，周圍的其他內存compiler and the CPU are free to re-order the update訪問。忙線等待線程可能會從繁忙循環中喚醒，並發現共享數據結構有而不是實際上已被更新。

我強烈建議堅持使用可用的線程原語來編寫一致的程序，這些程序每次都按照您的需要執行。