1

USB経由でハードウェアと通信するインターフェースDllを書いています。ハードウェアのタイミング要件を完全に満たすために (操作メッセージなどがない状態でタイムアウトしないようにするため)、「Open()」メソッドが呼び出されるとすぐに、遅延初期化ごとにワーカー スレッドを作成します。「close()」メソッドが呼び出されると、ワーカー スレッドによって監視される名前付きの「terminate」イベントを設定し、ワーカーが終了するのを待ちます。いくつかのメッセージをハードウェアと交換する必要があるため、終了には数百ミリ秒かかります。

これまでのところ、唯一の問題は、プログラムが "Close()" メソッドを呼び出さずに Dll をアンロードするときです... DllMain (PROCESS_DETATCH) で "terminate" イベントを設定することでこれを解決しました。 m が許可されていても、ベスト プラクティスを完全に満たすことができます。唯一の問題は、close を呼び出さずに Dll がアンロードされ、古いワーカー スレッドが終了する前に再度リロードされた場合です。古いワーカー スレッドが終了するのを待っているため、DLL をロードするプロセスでタイムアウトが発生します。

だからここに私の質問があります：たとえば500ミリ秒のタイムアウトでDllMain（PROCESS_DETATCH）で終了するワーカースレッドを待機しますか？プロセス全体が終了したときではなく、lpvReserved パラメータを調べてテストしますか?

また、私の問題を一般的に解決するより良い方法はありますか?

4

2 に答える 2

0

発生する唯一のことはFreeLibrary、モジュールがアンロードされている限り、呼び出したスレッド（FreeLibraryは非同期ではなく、戻り値を待機します）を待機させることです。

私はいくつかのDLLを作成しましたがwhile(!IsDebuggerAttached()){}、DLLMainのアタッチ/デタッチのようなループでさえも作成し、テストしたプログラムは必要な動作をします。

他の問題の解決策について：同じ機能を持つDLLMainアタッチ/デタッチ以外のものが必要なのはなぜですか？

于 2013-01-22T07:51:40.553 に答える
0

PROCESS_DETACH に待機を実装したところ、最初は機能しましたが、あるコーナー ケースで問題が発生しました。問題は、デバッグ出力セットアップが独自の DLL をロードして、デバッグ出力にバージョン情報を含めることでした。DLL のロードとアンロードが迅速に行われ、バックグラウンドでこのバージョン情報の読み取りが遅かった場合、プロセスが PROCESS_DETACH で待機している間にエラーが発生し、デッドロックが発生する可能性がありました。

将来的には、DllMin で何も待機しないことに決めました。これは、一部のケースで、または他の誰かがタッチされたクラスに機能を追加した後に、ローダー ロックでデッドロックを引き起こす可能性があるためです。

このアドバイスが将来誰かに役立つことを願っています。

于 2013-11-28T10:36:52.057 に答える