デッドロックが疑われる場合は、ps aux | grep <exe name> を実行してください 、出力の場合は PROCESS STATE CODE D です @daijo が説明したように、2 つのスレッド T1 があるとします。 &T2 semaphores S1 & S2 で保護された 2 つのクリティカル セクション T1 の場合 S1 を取得 と T2 S2 を取得 その後、すでに保持されているロックを放棄する前に他のロックを取得しようとすると、デッドロックが発生し、ps aux | grep <exe name> が実行されます。 、process state code D になります (つまり、中断できないスリープ)。
ツール:
Valgrind、Lockdep (Linux カーネル ユーティリティ)
デッドロックの種類とその回避方法については、次のリンクを確認してください:http://cmdlinelinux.blogspot.com/2014/01/linux-kernel-deadlocks-and-how-to-avoid.html
編集:ps aux 出力 D 「could」は、プロセスがデッドロック状態であることを意味します。次の redhat doc から:
中断できないスリープ状態
割り込み不可のスリープ状態は、信号をすぐには処理しない状態です。待機中のリソースが使用可能になった結果として、またはその待機中にタイムアウトが発生した場合にのみ (プロセスがスリープ状態になるときにタイムアウトが指定されている場合)、ウェイクアップします。
Helgrind:スレッド エラー検出器をご覧になることをお勧めします。
<ブロック引用>このような問題の最も単純な例は次のとおりです。
なんらかの理由で、R にアクセスするときに両方とも保持する必要がある 2 つのロック L1 と L2 によって保護されている共有リソース R を想像してみてください。
スレッドが L1、次に L2 を取得し、R へのアクセスに進むとします。これは、プログラム内のすべてのスレッドが最初に L1、次に L2 の順序で 2 つのロックを取得する必要があることを意味します。そうしないと、デッドロックの危険があります。
T1 と T2 という 2 つのスレッドが両方とも R にアクセスしたい場合、デッドロックが発生する可能性があります。T1 が最初に L1 を取得し、T2 が最初に L2 を取得するとします。次に、T1 は L2 を取得しようとし、T2 は L1 を取得しようとしますが、これらのロックは両方とも既に保持されています。そのため、T1 と T2 はデッドロック状態になります。"