問題タブ [thread-abort]

GUI の更新に時間がかかるアプリケーションがあります。これをバックグラウンド スレッドで実行することはできません。これは、メイン スレッドでのみ実行できる GUI コンポーネントの更新に長い処理が関連付けられているためです。

したがって、GUI の更新が完了するまでバックグラウンド スレッドで WaitDialog フォームを作成して表示するヘルパー クラスを作成しました。

私のヘルパークラスは次のようになります。

メイン GUI ウィンドウでヘルパー クラスを呼び出すコードは次のようになります。

これはうまく動作しているようで、GUI で私が望むのとまったく同じように見えます。WaitDialog フォームはモーダルであり、更新が完了するまでメイン GUI フォームへのアクセスをブロックします。長時間実行されている GUI タスクが完了するとすぐに、Using ブロックから脱落し、ヘルパー クラスで Dispose メソッドが呼び出され、スレッドで Abort が呼び出されます。

私の質問は、スレッドを終了するためのより適切な方法、または同じ動作を達成するためのより良い方法はありますか?

こんにちは、次のテスト コードがあります。

毎回、中止が発生すると、 Thread.ResetAbort() が実行されます。この ResetAbort は何をするのだろうか。実行すると、次の出力が表示されたからです。I will come back! 戻ってきます！戻ってきます！そして、出力「End」が表示されませんでした。このプログラムはまったく終了していないようです。なぜなのかご存知ですか？ありがとう！

各スレッドがスレッド検索マネージャーから（プロデューサー/コンシューマーモジュールを使用して）検索タスクを取得するスレッド配列があり、それが完了すると、検索マネージャースレッドからの次のシグナルまで待機します。検索はWeb経由で実行され、かなりの時間がかかります（主にhtmlデータ部分の取得）。私の問題は、ユーザーが現在の検索を停止して新しい検索セットを開始することを選択した場合、前のWeb検索中にすべての検索がビジーであるため、現在、ユーザーは関連性のない検索がタスクを終了するまで待機し、新しいものを開始します。

私の質問は、新しい関連タスクをすぐに開始するにはどうすればよいですか？get httpメソッドの待機時間が長いため、フラグ（検索をスキップするスレッドを示すため）を使用できませんでした。メソッドを積極的に停止し、最初から開始する方法はありますか？（私は新しいスレッドを使用したくない...）

前もって感謝します、

シュムエル。

このような振る舞いは起こらないはずだと思います。シナリオは次のとおりです。

1. 長時間実行されるSQLトランザクションを開始します。

2. sqlコマンドを実行したスレッドは中止されます（コードではありません！）

3. スレッドがマネージコードに戻ると、SqlConnectionの状態は「Closed」になりますが、トランザクションはSQLサーバーで開いたままです。

4. SQLConnectionを再度開くことができ、トランザクションでロールバックを呼び出そうとすることはできますが、効果はありません（この動作を期待するわけではありません。要点は、データベース上のトランザクションにアクセスしてロールする方法がないということです。戻る。）

問題は、スレッドが異常終了したときにトランザクションが適切にクリーンアップされないことです。これは、.Net 1.1、2.0、および2.0SP1の問題でした。.Net3.5SP1を実行しています。

これは、問題を説明するサンプルプログラムです。

これに対処するはずの.Net2.0SP1を対象としたMicrosoftHotfixがありますが、この修正プログラムに記載されているバージョン番号と一致しない新しいDLL（.Net 3.5 SP1）があることは明らかです。

誰かがこの動作を説明できますか、そしてなぜThreadAbortがまだSQLトランザクションを適切にクリーンアップしていないのですか？.Net 3.5 SP1にはこの修正プログラムが含まれていませんか、それともこの動作は技術的に正しいですか？

リモート コンピューターで wmi クエリを起動するコード。このコードは、同時に複数のスレッドで実行されます。

メインスレッドで実行されるコード:

2 つの質問:

最初のスレッドを停止するには?

最初のスレッドを停止し、デッドロックを作成しない方法は?

質問への答え-C＃Generic Timeoutの実装は、スレッドプールスレッドの中止を伴うソリューションを提供します。明示的に作成されたスレッドを中止した場合の結果を知っています。スレッドプールスレッドを中止した場合の結果は、明示的なスレッドを中止した場合よりも多くなると思います。私は疑問に思う：

1. スレッドプールスレッドが中止されるとどうなりますか？
2. スレッドは完全に使用できなくなりますか？
3. 中止されたスレッドのスタックメモリは解放されていますか？
4. 多くのスレッドプールスレッドが中止されるとどうなりますか？スレッドプールはこのような状況にどのように対処しますか？

ありがとう。

私は c++ visualstudio2008 でスレッドを使用しています。フォームを閉じてもスレッドはアクティブなままなので、フォームを閉じるときにスレッド::中止を試みましたが、スレッドについて呼び出した後もまだ生きています。そのため、例外ハンドラーをスレッドに配置し、アボート例外が到着するとスレッドは終了しますが、スレッドは例外ハンドラーに入りません。どうすればスレッドを閉じることができますか? oThread は、グローバル オブジェクト スレッドです。

Windows サービスでホストされている WCF サービスがあります。このサービスのクライアントは、closeTimeout、receiveTimeout、openTimeout、sentTimeout を 5 分に設定しています。サービスも同様です。特定の状況では、WCF サービスがタスクを処理するのに 5 分以上かかる場合があります。この場合、クライアントは呼び出しを中止しますが、サービス プロセスはジョブが完了するまで実行を続けます。

さて、問題は...クライアントが切断またはタイムアウトしたこと（または他の何か？）を検出して、WCFサービスがタスクを中止できるようにする構成/手法はありますか？

I have a set of threaded classes that print different types of documents. The classes use inheritance to share common code. The class constructor requires file name and printer name arguments. A Print() method creates a new worker thread, waits for the worker thread to complete using Thread.Join(timeout) and calls Thread.Abort() on the worker thread if the Join times out. The worker thread starts an application that can open the specified file, causes the file to be sent to printer synchronously (usually using application's Print method) and exits. The worker thread's code is wrapped in a try{} ... catch{} block to deal with any unforeseen crashes of the external application. The catch block contains minimal cleanup and logging.

I found my application non-responsive, with the main thread in a Sleep/Wait/Join at the Thread.Abort() line. I do not recall the status of the worker thread, but the logging that was supposed to be performed in the catch{} block did not take place. (I Attached to my process with VS2010 after I found it non-responsive).

I refer to the following Note from the Thread.Abort Method:

The thread that calls Abort might block if the thread that is being aborted is in a protected region of code, such as a catch block, finally block, or constrained execution region. If the thread that calls Abort holds a lock that the aborted thread requires, a deadlock can occur.

I believe I have a dead-locking issue because (1) it does not always happen, and (2) because of the Note on MSDN (above).

1. The Note appears to suggest that using try{} ... catch{} is NEVER safe inside a thread if the thread can be Abort()'ed. Is this true?
2. I do not see how I can avoid using Abort() in my scenario. Will using Thread.Interrupt() instead make any difference?
3. How to I fix the dead-locking issue I have?

BackgroundWorker does not work for me because I do not need progress reporting and, more importantly, it is possible that my worker thread will block indefinitely when it executes third party applications. For the same reason, I cannot ask my thread to terminate, but have one option only - to ruthlessly Abort() the worker thread.

ファイル転送アプリケーション（サーバークライアント）を持っています...ファイルの送信中にキャンセルを有効にしたいです。
クライアントは、backgroundworkerによって機能するSendFileメソッドをキャンセルしてから、受信スレッドをキャンセルするコマンドをサーバーに送信します。
サーバーがこのコマンドを受信すると、Stopメソッドを呼び出しますが、その行でスタックします。network.Read（data、0、data.Length）;

どうすればこのスレッドを中止して、network.Read（..）にとらわれることなく 最終的に進むことができますか？
前もって感謝します。