単体テスト、デッドロック、および競合状態

Question

デッドロックや競合状態の影響を受けやすいコードの反復可能な単体テストの作成方法に関する提案はありますか？

今、私は単体テストをスキップし、ストレステストに集中しています。問題は、ストレステストを5回実行すると、5つの異なる結果が表示されることです。

編集：おそらく単なる夢を知っていますが、個々のスレッドを制御して一度に1つの命令を実行させる方法があれば、どこかに行くかもしれません。

Answer 1

TypeMock レーサー（ベータ版）

をご覧ください>

編集：実際にはアルファ

http://www.typemock.com/Typemock_software_development_tools.html

Answer 2

通常、ManualResetEventのようなものを使用して各スレッドを解放する前に予想される状態にすることにより、強制的に予測競合状態とデッドロックを発生させることができます。シグナル...スレッドBにロックを要求するなど...

ただし、通常、疑わしいバグを調査し、修正された時期と再浮上しないことを証明するために、このようなテストを作成します。通常は、競合状態を考慮して設計します（ただし、実用的な範囲でテストします）。

Answer 3

競合状態を探すことは、実際には単体テストの領域に入るとは思いません。定義により多かれ少なかれ、競合状態をテストする唯一の方法は擬似ランダムです。ロック戦略の正確性を正式に証明する努力をするつもりがない限り、ストレステストを行う必要があります。

ロック戦略ではなく、アルゴリズムの正確性を検証するために、ユニットテストを記述する必要があります。

マルチスレッドコードのストレステストを行う場合、スレッドごとに1つのCPUがあり、CPUを共有する複数のスレッドがあり、スレッドよりもCPUが多い（可能な場合）状況でテストする必要があります。

Answer 4

ロック操作の順序を調べることで、潜在的なデッドロックを検出するロッククラスを作成できます。これを行うには、すべてのロックが取得されたときに登録するスレッドコンテキストを使用します（DEBUGのみのオプションにすることができます）。

アイデアは、ノードがロックを表し、AとBの間の有向エッジが「ロックBが取得されたときにロックAが保持されていた」ことを示すグラフを作成することです。通常の負荷を使用してプログラムを実行し、グラフのサイクルを確認します。サイクルとは、コードがヒットしなくてもデッドロックが発生する可能性があることを意味します。

Answer 5

自動化された良い方法を考えることはできませんが、私がやってきた最も近い方法は、単体テストに加えてブレークポイントを使用することで、デッドロックを「暴露」する単体テストを書くことでした。ブレークポイントを追加する場所に関する指示を追加しただけです。いくつかの手作業が伴いますが、それらを使用すると、最悪の場合のスレッドスケジュールをいつでも公開できます。

おそらく、誰かがこのタイプの機能を自動化する良い方法を考え出したでしょうか？デバッガーを自動的に実行し、特定の行で1つのスレッドを中断し、特定の条件まで別のスレッドを実行させてから、単体テストをアサートすることを想像できます。

Answer 6

以前は、リクエスト内のいくつかのパラメーターによってトリガーされるコードで人為的な遅延を使用しました。たとえば、1つの要求は、2つの書き込みの間で書き込みを遅らせるようにサーバーに指示し、別の要求は、間に遅延なしでそれらを行うように指示します。

Mark Besseyは次のように書いています。これは問題の発見ではなく、再現の作成にのみ役立ちます。

Answer 7

Corensic Jinx を試しましたか？