valgrindはマルチスレッドソケットプログラムで停止します

Question

私はvalgrindでマルチスレッドソケットプログラムを実行しています。クライアントはTCP経由でサーバーに要求を送信し、ブール値でビジー状態を待機します。ブール値は、サーバーからの応答を処理するコールバック関数が呼び出されたときに設定されます。応答が受信されると（ブーリアンフラグが設定されると）、サーバーは要求を再度送信し、これをループで繰り返し実行します。

共有変数（ブール値）への非暗号化アクセスがスレッドの問題を引き起こす可能性があることに気づきましたが、pthread mutexを使用しようとしましたが、プログラムの速度は約20％遅くなります。私は共有ブール変数への書き込みは、1回のサイクルで行うことができるので大丈夫だと確信しています。

プログラムは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でアクセスします。ビジー状態のスレッドがビジー・ループから起きて、共有データ構造がではなく、が実際に更新されていることがわかります。

一貫性のあるのプログラムを、一度に1回だけ実行することを強くお勧めします。