C# と VB.NET の質問掲示板

ツリー一括表示
Thread.Abortの代替 /森永 (25/03/06(Thu) 21:25) #103584
`└` Re[1]: Thread.Abortの代替 /Azulean (25/03/06(Thu) 21:43) #103585
`└` Re[2]: Thread.Abortの代替 /森永 (25/03/08(Sat) 10:58) #103586 解決済み
`└` Re[3]: Thread.Abortの代替 /Azulean (25/03/08(Sat) 20:10) #103588 解決済み
`└` Re[4]: Thread.Abortの代替 /森永 (25/03/08(Sat) 20:12) #103589 解決済み

分類:[.NET 全般]　

VB.NETを使っていて、
.NET Frameworkから.NET8に移行しようとしております。

一つ問題は、このページにありますように、

https://learn.microsoft.com/ja-jp/dotnet/core/compatibility/core-libraries/5.0/thread-abort-obsolete

Thread.Abortが廃止されてしまったようです。

代わりに、CancellationToken が推奨されているようです。

CancellationToken の使い方に関してですが
今、バックグラウンドスレッドではDoループが複数ある状態なのですが、
全てのDoループで

if (cancellationToken.IsCancellationRequested)
をチェックする必要があるのでしょうか？

もしそうだとすると、二つ問題があります。

一つはできる限り計算スピードを上げたい場合には、
何度もcancellationToken.IsCancellationRequestedが実行されると
わずかですが計算速度が落ちてしまうことです。

もう一つは、あるAPIを実行中にフリーズしてしまった場合に、
Thread.Abort
だと強制終了することができたのですが、
cancellationToken.IsCancellationRequestedだと、強制終了できないという点です。

できれば、Thread.AbortのようなAPIがあれば一番なのですが
他に良い方法はないでしょうか？

■No103584 (森永さん) に返信
> 全てのDoループで
>
> if (cancellationToken.IsCancellationRequested)
> をチェックする必要があるのでしょうか？

すべてというより、時間のかかる箇所でしょうね。
例外を投げても良いのなら、cancellationToken.ThrowIfCancellationRequestedを使うのも良いでしょう。

> 一つはできる限り計算スピードを上げたい場合には、
> 何度もcancellationToken.IsCancellationRequestedが実行されると
> わずかですが計算速度が落ちてしまうことです。

些末かと思いますが、最内周のループでやると効率が悪化する可能性はあります。
カウンタで10回に一度、100回に一度チェックするとか、ご自身で調整すれば良いことです。

> もう一つは、あるAPIを実行中にフリーズしてしまった場合に、
> Thread.Abort
> だと強制終了することができたのですが、
> cancellationToken.IsCancellationRequestedだと、強制終了できないという点です。

そうですね。
元々、Thread.Abortの安全は保証されていなかった（中止位置によっては変数・メモリが破壊されうる）わけですので、過去のことは忘れ、欠陥のあるAPIの利用をやめるとか、いろいろと見直すべきでしょう。
それができないなら、.NET Frameworkを継続利用すれば良いだけです。

ありがとうございます。

うううう、そうですか・・・
極希にフリーズするAPIを使っていて、
Thread.Abortを使えば、ソフトを落とさずに
フリーズを回避することができていたので
重宝していたのですが、もう代替案はございませんでしょうか？

■No103586 (森永さん) に返信
> 極希にフリーズするAPIを使っていて、
> Thread.Abortを使えば、ソフトを落とさずに
> フリーズを回避することができていたので
> 重宝していたのですが、もう代替案はございませんでしょうか？　

フリーズを回避できたとしても不安定な状態に陥る、その後落ちる、不正動作するなどを引き起こす問題の大きいメソッドだから廃止されたのですから、それを前提とするようなプログレラムは諦めましょう。
.NET 8などの未来を目指したいならレガシーな存在に依存しない決断も必要です。

そうでしたかどうもありがとうございます。

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト