マルチスレッド操作同期オブジェクトによるデッドロックの解決方法について(二)
前の記事では、デッドロックの発生を効果的に回避する場合、このファイルでは、デッドロックが発生したときにデッドロックが発生したことをどのように知って知ることができ、迅速に解決するかについて説明します.では、この文章は主に原理的なものを説明して、多くのコードを貼らないで、次は本題に入ります.
前のファイルで自動ロックセキュリティクラスを定義した後、いくつかの関数がリロードされているのを見ました.パラメータにはファイル名、関数名、コード行などのパラメータがあります.では、この情報はデッドロック時にコードがどの位置に実行されるかを特定するのに役立つ情報です.では、私たちはどのようにこれらのパラメータを入力しますか.これらのパラメータの問題をマクロで解決できます.マクロの定義は次のとおりです.
私たちが情報を保存するときは、私のこの臨界領域オブジェクトの操作がどのスレッドで呼び出されたのか、マルチスレッドの場合にのみデッドロックが発生するため、保存された情報をスレッドに関連付けなければならないという問題も考えなければなりません.保存された情報はどのようなデータ構造で保存されますか?最良のスキームはもちろんStackを使用してこれらの呼び出し情報を保存することであり、これは私たちの関数呼び出しスタックと一致します.ファイルを保存するときは、スレッドごとにスタックを呼び出して出力します.これにより、ログファイルには現在のスレッドの実行中の臨界領域オブジェクトがよく現れ、臨界領域オブジェクトが交差して使用されていることなどを発見すると、デッドロックの発生原因を迅速に知ることができます.他の場合は、少し分析するだけでデッドロックの問題点がすぐにわかります.私たちはいつこのログファイルを保存しますか?まず、保存した呼び出し情報スタックを監視するモニタリングスレッドを作成し、あるスレッドの呼び出し情報記録の時間と現在の時間が設定したしきい値を超えていることを発見した場合、ファイルを出力し、提示しなければなりません.
この方案の使用する地方はソフトウェアが発表する前のテストの段阶で、テストする时もしデッドロックの问题が现れたら、私达はログのファイルをコピーするだけで、ソフトウェアが安定して発表した后にこのシステムを闭めることができて、この方案は结局やはり少し性エネルギーの损失があるため(テストのプラットフォームはwinceで、PCのプラットフォームは基本的に性能の问题を无视することができます).
もちろん、このスキームは臨界領域を監視するだけでなく、他の関数の実行を監視することもできます.大きなシステムにサードパーティのApiがある可能性があります.呼び出しが必要です.これらのApiに問題が発生すると、中に閉じ込められて戻ってこないことがあります.では、このApiが戻ってこないことをブロックする可能性があるかどうかを疑う場合は、上記の形式で呼び出しスタック情報を加えることができます.
シナリオソースダウンロードアドレス(シナリオで使用される記憶方式は、リストを用いて上記のStackを採用していないが、何らかの理由でstack方式をキャンセルした):http://download.csdn.net/detail/flyound/4822457あ、何か問題があったら指摘してください.
前のファイルで自動ロックセキュリティクラスを定義した後、いくつかの関数がリロードされているのを見ました.パラメータにはファイル名、関数名、コード行などのパラメータがあります.では、この情報はデッドロック時にコードがどの位置に実行されるかを特定するのに役立つ情報です.では、私たちはどのようにこれらのパラメータを入力しますか.これらのパラメータの問題をマクロで解決できます.マクロの定義は次のとおりです.
//! ,
#define SafetyAutoLockEx(csLock) SafetyAutoLock al##_csLock(&csLock, __FILE__, __FUNCTION__, __LINE__)
#define SafetyAutoLockResetEx(csLock) al##_csLock.Reset(&csLock, __FILE__, __FUNCTION__, __LINE__)
私たちが情報を保存するときは、私のこの臨界領域オブジェクトの操作がどのスレッドで呼び出されたのか、マルチスレッドの場合にのみデッドロックが発生するため、保存された情報をスレッドに関連付けなければならないという問題も考えなければなりません.保存された情報はどのようなデータ構造で保存されますか?最良のスキームはもちろんStackを使用してこれらの呼び出し情報を保存することであり、これは私たちの関数呼び出しスタックと一致します.ファイルを保存するときは、スレッドごとにスタックを呼び出して出力します.これにより、ログファイルには現在のスレッドの実行中の臨界領域オブジェクトがよく現れ、臨界領域オブジェクトが交差して使用されていることなどを発見すると、デッドロックの発生原因を迅速に知ることができます.他の場合は、少し分析するだけでデッドロックの問題点がすぐにわかります.私たちはいつこのログファイルを保存しますか?まず、保存した呼び出し情報スタックを監視するモニタリングスレッドを作成し、あるスレッドの呼び出し情報記録の時間と現在の時間が設定したしきい値を超えていることを発見した場合、ファイルを出力し、提示しなければなりません.
この方案の使用する地方はソフトウェアが発表する前のテストの段阶で、テストする时もしデッドロックの问题が现れたら、私达はログのファイルをコピーするだけで、ソフトウェアが安定して発表した后にこのシステムを闭めることができて、この方案は结局やはり少し性エネルギーの损失があるため(テストのプラットフォームはwinceで、PCのプラットフォームは基本的に性能の问题を无视することができます).
もちろん、このスキームは臨界領域を監視するだけでなく、他の関数の実行を監視することもできます.大きなシステムにサードパーティのApiがある可能性があります.呼び出しが必要です.これらのApiに問題が発生すると、中に閉じ込められて戻ってこないことがあります.では、このApiが戻ってこないことをブロックする可能性があるかどうかを疑う場合は、上記の形式で呼び出しスタック情報を加えることができます.
シナリオソースダウンロードアドレス(シナリオで使用される記憶方式は、リストを用いて上記のStackを採用していないが、何らかの理由でstack方式をキャンセルした):http://download.csdn.net/detail/flyound/4822457あ、何か問題があったら指摘してください.