問題タブ [thread-abort]

スレッド名を使用してスレッドを中止 (汚い方法) できるかどうか疑問に思っていましたか? ここにいくつかのコード例があります:

だから今、私はスレッドを作成しました。プログラムの後半で、ユーザーがスレッドを終了する可能性があります。ここで私の質問が入ります。名前を介してスレッドを終了するにはどうすればよいですか? またはおそらくそれを終了する別の方法ですか？バックラウンド ワーカーを使用したくありません。

例：myThead[4].Abort();

ありがとう

Steve Marx から借りたコードがいくつかあります。メイン ブロックは、Azure ワーカー ロール スレッドで使用され、Azure BLOB のリースを取得します。これにより、一度に 1 つのインスタンスだけでジョブを処理したい場合に、複数のワーカー インスタンス間で同期するためのロック メカニズムが提供されます。ただし、BLOB リースのタイムアウトよりも完了するまでに時間がかかるジョブがある可能性があるため、BLOB リースを頻繁に更新するために新しいスレッドが生成されます。

この更新スレッドはスリープ状態になり、無限ループで更新されます。メイン スレッドが (Disposeクラスのコンシューマーを介して)終了するrenewalThread.Abort()と、呼び出されます。これにより、すべての種類のThreadAbortExceptionが worker ロールでスローされます。

私は疑問に思っています、これはこれを処理するためのより良い方法ですか？私が気に入らないのは、それらを生成したコンシューマーが破棄された後も、いくつかの更新スレッドがスリープ状態のままになる可能性があることです。以下のコードに何か悪い点はありますか? もしそうなら、より良い方法はありますか？それともThread.Abort()ここで適切ですか？

アップデート

2 つ以上のインスタンスでデプロイされた Azure ワーカー ロールがあるとします。また、両方のインスタンスが処理できるジョブがあるとします。ワーカー ロールRunメソッドの実行中は、次のようになります。

ロールは毎秒、特定のジョブの実行がスケジュールされているかどうかを確認し、スケジュールされている場合はそれらを処理します。ただし、両方のロール インスタンスが同じジョブを処理することを避けるために、最初に BLOB のリースを取得します。そうすることで、他のインスタンスは BLOB にアクセスできなくなるため、最初のインスタンスの処理が完了するまで効果的にブロックされます。(注: 新しいリースの取得は、上記の .Perform メソッド内で行われます。)

ここで、ジョブが完了するまでに 1 ～ 100 秒かかるとします。BLOB リースには組み込みのタイムアウトがあるため、プロセスが終了するまで他のロールをブロックしたままにする場合は、そのリースを定期的に更新して、タイムアウトが発生しないようにする必要があります。それが上記のクラスがカプセル化するもので、消費者として破棄するまでリースを自動的に更新します。

私の質問は主に、renewalThread のスリープ タイムアウトに関するものです。ジョブが 2 秒で完了したとします。更新スレッドは正常に終了しますが (私はそう思います)、さらに 38 秒間は終了しません。それが私の質問の不確実性の本質です。元のコードは、renewalThread.Abort() を呼び出したため、すぐに停止しました。そうする方が良いですか、それともスリープ状態にして後で正常に終了しますか? ロールのRunメソッドを 1 秒に 1 回ハートビートしている場合、正常に終了するために最大 40 の更新スレッドが待機する可能性があります。異なる BLOB で異なるジョブがブロックされている場合、その数は、リースされている BLOB の数で乗算されます。ただし、Thread.Abort() を使用してこれを行うと、同じ数の ThreadAbortExceptions がスタック上で発生します。

これで、filesystemWatcher を使用してイベントをトリガーするアプリケーションを作成できました。FSW は、非常に近い回数でトリガーします。FSW が最後にトリガーされてから 1 時間後にトリガーする関数を作成したいと考えています。

私は最初にバックグラウンドワーカーを使用してみました: (すべてのコードはわかりやすくするために短縮されています)

への呼び出しにもかかわらず、2 回目bw.RunWorkerAsync()の呼び出しが明らかにビジーであったため、これは機能しませんでしたbw.CancelAsync()。

私の次の試みには、SO のどこかで読んだ通常のスレッドが含まれていました (今はリンクが見つかりません)。

スレッドの試行はほぼ同じですが、通常のスレッドには存在しない backgroundWorker 内にいくつかの制約がある可能性があるため、試してみると思いました。と思いました。

しかし、これは私に同じエラーを与えました。への 2 番目のコールPWC_counter_thread.Start()はビジーでした。

2 番目のスレッドがこの例では 3 分間待機し、最初の FSW メソッドの実行に 1 秒ほどかかるため、競合状態は存在しないと想定しています。したがって、.Abort() の呼び出しと.CancelAsync() 両方とも、それぞれのメソッドが完了する前に実行されます。

質問は次のとおりです。

私が試みている方法でスレッドを再起動することは可能ですか? もしそうなら、私は何を間違っていますか？

別の方法でメソッド呼び出しを遅らせる必要がありますか? もしそうなら、ヒントは？

編集/更新/解決策

スレッドを開始および停止して思い通りに動作させることができなかったので、状況に対する別の解決策を見つけました。

状況は、一定時間後にメソッドを呼び出す一種のタイマーとして機能する 2 番目のスレッドを持っていたということでした。私の最初のスレッドはいくつかの作業を行い、終了すると2番目のスレッドが開始されました。タイマースレッドが終了する前に最初のスレッドが再び起動された場合、スレッドを強制終了して再起動することになっていました。これは、私が望んでいた方法を実現するのが難しいことを証明しました。そのため、代わりに、希望する最終結果に向けて別のアプローチを取りました。スレッドを再起動する代わりに、2 番目のスレッドがカウンターとして使用していたストップウォッチを再起動しました。これにより、私が望んでいた結果が得られました。おそらく悪い習慣ですが、うまくいきます。

Web サービスにアクセスして値を返す一連のスレッドを作成しています。各スレッドに threading.timer を追加し、threading.timer のタイムアウト タイマーが超過した場合に、スレッドが使用するリソースの割り当てを解除しようとしました。

ここで私がそれをした方法。

それがどのように機能するかを確認するために、webservcieclient がタイムアウト時間を超えているようにしました。その後、タイマーが起動し、スレッドを中止します。

しかし、私が見たのは、webservcieclient がネットワーク/http 例外の後に返され、実行され、スレッドが中止されたことを示す別の例外をスローすることです。また、UpdateDB() が 2 回実行されました。スレッドがすでに中止されたためにどのように実行されたか。Web サービスのメソッドにアクセスしているときに別のスレッドが開始されたためですか?