デッドロックをデバッグするときに何を探しますか？

最近、スレッドを多用するプロジェクトに取り組んでいます。私はそれらを設計してもいいと思います。ステートレス設計を可能な限り使用する、複数のスレッドが必要とするすべてのリソースへのアクセスをロックする、など。関数型プログラミングの私の経験は非常に役立ちました。

しかし、他の人のスレッドコードを読むと、混乱します。私は今、デッドロックをデバッグしています。コーディングスタイルとデザインは私の個人的なスタイルとは異なるため、潜在的なデッドロック状態を見つけるのは困難です。

デッドロックをデバッグするときに何を探しますか？

状況が実際のデッドロックである場合（つまり、2つのスレッドが2つの異なるロックを保持しているが、少なくとも1つのスレッドが他のスレッドが保持するロックを望んでいる場合）、まずスレッドがロックを順序付ける方法に関するすべての先入観を放棄する必要があります。何も想定しない。あなたが見ているコードからすべてのコメントを削除したいと思うかもしれません。それらのコメントはあなたに当てはまらない何かを信じさせるかもしれないからです。これを十分に強調することは困難です。何も仮定しないでください。

その後、スレッドが他の何かをロックしようとする間に保持されるロックを決定します。可能であれば、スレッドがロックとは逆の順序でロック解除されるようにします。さらに良いことに、スレッドが一度に1つのロックのみを保持するようにしてください。

スレッドの実行を綿密に処理し、すべてのロックイベントを調べます。各ロックで、スレッドが他のロックを保持しているかどうかを確認し、保持している場合、どのような状況で、同様の実行パスを実行する別のスレッドが考慮中のロックイベントに到達できるかを決定します。

時間やお金がなくなる前に問題を見つけられない可能性は確かにあります。

1. 他の人が言ったように...あなたがロギングのための有用な情報を得ることができるなら、それが最も簡単なことなので最初にそれを試してください。

2. 関係するロックを特定します。永久に待機するすべてのミューテックス/セマフォを、5分など途方もなく長い待機時間に変更します。タイムアウトしたらエラーをログに記録します。これにより、少なくとも、問題に関係するロックの1つの方向が示されます。タイミングのばらつきに応じて、運が良ければ数回実行すると両方のロックが見つかる場合があります。タイムアウト待機が最初の段階でどのように到達したかを特定できなかった後、関数失敗コード/条件を使用して擬似スタックトレースを記録します。これは、問題に関係するスレッドを識別するのに役立ちます。

3. もう1つ試すことができるのは、mutex /セマフォサービスのラッパーライブラリを構築することです。どのスレッドが各ミューテックスを持ち、どのスレッドがミューテックスを待機しているかを追跡します。スレッドがブロックされている時間をチェックするモニタースレッドを構築します。妥当な期間でトリガーし、追跡している状態情報をダンプします。

ある時点で、単純な古いコード検査が必要になるでしょう。

最初のステップ（ペーターが言うように）はロギングです。私の経験では、これにはしばしば問題があります。大量の並列処理では、これはしばしば不可能です。毎秒10万ノードのノードを処理するニューラルネットワークで、似たようなものを一度デバッグする必要がありました。エラーは数時間後にのみ発生し、1行の出力でさえ物事が非常に遅くなり、数日かかっていました。ロギングが可能な場合は、データに集中するのではなく、プログラムのフローに集中し、どの部分で発生するかを確認します。各関数の先頭にある簡単な行で、適切な関数が見つかったら、それを小さなチャンクに分割します。

別のオプションは、バグをローカライズするためにコードとデータの一部を削除することです。クラスの一部のみを取得し、最も基本的なテストのみを実行する小さなプログラムを作成することもできます（もちろん、いくつかのスレッドで実行します）。実際の処理状態に関する出力など、guiに関連するすべてを削除します。（ユーザーインターフェースがバグの原因であることがよくありました）

コードでは、ロックの初期化と解放の間の制御の完全な論理フローに従うようにしてください。一般的なエラーは、関数の開始時にロックし、終了時にロックを解除するが、その間に条件付きのreturnステートメントがあることです。例外もリリースを妨げる可能性があります。

私の親友は、コード内の興味深い場所での印刷/ログステートメントです。これらは通常、異なるスレッド間のタイミングを乱すことなく、アプリ内で実際に何が起こっているかをよりよく理解するのに役立ち、バグの再現を妨げる可能性があります。

それが失敗した場合、私の唯一の残りの方法はコードを見つめて、さまざまなスレッドと相互作用のメンタルモデルを構築しようとし、明らかに起こったことを達成するための可能なクレイジーな方法を考えようとしています:-)しかし、私はしません自分を非常に経験のあるデッドロックスレイヤーと考えてください。うまくいけば、他の人がより良いアイデアを提供できるようになり、そこから私も学ぶことができます:-)

まず、そのコードの作者を取得してみてください。彼はおそらく自分が書いたものを知っているでしょう。話しているだけでは問題を特定できない場合でも、少なくとも彼と一緒に座ってデッドロック部分を特定できます。これは、助けなしでコードを理解するよりもはるかに速くなります。

それに失敗すると、PéterTörökが言ったように、おそらくロギングが道です。私の知る限り、デバッガーはマルチスレッド環境で悪い仕事をしました。ロックがどこにあるのかを特定し、どのリソースが待機しているか、そしてどのような状態で競合状態が発生するかを把握してください。

この質問は私を魅了します;）まず第一に、あなたはすべての実行で一貫して問題を再現することができたので、自分自身を幸運だと考えてください。毎回同じスタックトレースで同じ例外を受け取った場合、それはかなり簡単です。そうでない場合、スタックトレースをそれほど信頼せず、代わりにグローバルオブジェクトへのアクセスと実行中の状態変化を監視するだけです。

デッドロックをデバッグする必要がある場合は、すでに問題が発生しています。原則として、可能な限り短い時間ロックを使用するか、可能であればまったく使用しないでください。ロックを取得した後、重要なコードに移行するような状況は避けてください。

もちろんプログラミング環境に依存しますが、単一のスレッドからのみリソースにアクセスできるシーケンシャルキューのようなものを調べる必要があります。

そして、古いが間違いのない戦略があります。レベル0から始まる各ロックに「レベル」を割り当てます。レベル0のロックを取得する場合、他のロックは許可されません。レベル1のロックを取得した後、レベル0のロックを取得できます。レベル10のロックを取得した後、レベル9以下でロックを取得できます。

これを実行できない場合、デッドロックに陥るのでコードを修正する必要があります。