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

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

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

Re[4]: スレッドのAbort()とJoin()について

分類:[C# (Windows)]　

お世話になっていますれれれです

早速質問なんですが
スレッドの処理について

あるプログラム（このプログラムは正しく動作しています）を読んでいたら
foreach(string key in tmpkeys)
{
　　if(((Thread)extThreadHolder[key])!=null))//スレッドが動いている状態かどうか
　　　{
　　　　((Thread)extThreadHolder[key]).Abort();
　　　　((Thread)extThreadHolder[key]).Join();
　　　　extThreadHolder.Remove(key);
　　　}
}

//extThreadHolderはハッシュテーブル型です。

というのがあるんですが
Abortはスレッドを強制終了してJoinはスレッド終了まで待つと、ググッてわかりましたが
強制終了した後そのスレッドが終わるのを待つという感覚（？）がよくわかりません。
このJoin()はどう解釈すればいいのでしょうか

私的にはJoin()はいらないんじゃないかと思うのですが・・・
よろしくお願いします

2007/07/06(Fri) 19:02:51 編集(投稿者)

■No5216 (れれれさん) に返信
> ググッてわかりましたが

細かい挙動について言えば，MSDN Library のリファレンスもあたってみたほうが良いかと思います．
http://msdn2.microsoft.com/ja-jp/library/ty8d3wta(VS.80).aspx
http://msdn2.microsoft.com/ja-jp/library/cyayh29d(VS.80).aspx

> スレッドがすぐに確実に中止されるかどうかは保証できません。
> この状況は、アボートプロシージャの一部として呼び出される finally ブロックでスレッドが無制限に計算を実行した結果、無制限に中止が遅れる場合に発生することがあります。
> スレッドが中止されるまで待機するには、Abort メソッドを呼び出した後にスレッドで Join メソッドを呼び出します。
> ただし、待機が確実に終了するとは限りません。

というわけで，Abort -> Join の並びはそれほど珍しいものではありません．
ただし，一般論としての Abort は，永遠に処理が戻らないことがある厄介なメソッドですので，そういう部分を含めてどういう前提でこのコードが書かれているかは，書いた人に直接聞いてみた方が良いかもしれませんね．
http://d.hatena.ne.jp/NyaRuRu/20060531/p1
http://d.hatena.ne.jp/NyaRuRu/20060602/p1

たまに止まっても手動で何とかすればよいアプリケーションなのか，何があっても自動復帰が必要なアプリケーションなのかで，コードの読み方も変わってくるかと思います．

> というわけで，Abort -> Join の並びはそれほど珍しいものではありません．

個人的にはあまり感心しません。

Thread.Abort() はスレッドの状態をまるで考慮せずにスレッドを強制終了します。

純粋に計算しかしないようなスレッドなら特に問題ないかもしれませんが、例えばスレッドがファイル操作を行っている途中で Thread.Abort() した場合、処理対象となっていたファイルが正常にクローズされないまま放置されることになってしまいます。

■No5223 (渋木宏明(ひどり) さん) に返信
>>というわけで，Abort -> Join の並びはそれほど珍しいものではありません．
>
> 個人的にはあまり感心しません。
>
> Thread.Abort() はスレッドの状態をまるで考慮せずにスレッドを強制終了します。
>
> 純粋に計算しかしないようなスレッドなら特に問題ないかもしれませんが、例えばスレッドがファイル操作を行っている途中で Thread.Abort() した場合、処理対象となっていたファイルが正常にクローズされないまま放置されることになってしまいます。

確かに推奨されるかどうかは別問題ですね．
なんとなく，ですが，Abort を使っているプログラムは「あまり深く考えていない」か「相当に深い読みの元に書かれているか」のどちらかじゃないかと思っています．
まあ私も利用者の立場としては，暴走したプロセスをあまり深く考えずに kill することが多いので，この辺りの判断はケースバイケースかと．

サーバサイドのフレームワークで，リソース利用の自動化や，プロセス再起動無しでの障害復帰を突き詰めたい場合などは，それなりに興味深いテーマだと思います．実際，SQLCLR や IIS ではそういうことが行われていますしね．
CLR はスレッド強制終了時に対象スレッドの Constrained Execution Regions や ReliabilityContractAttribute を考慮するので，操作先のスレッドの状態を一切考慮しないわけではないですし，日記で書いたように finally ブロックへの配慮といった効果もあります．また，OS リソースに関しては CriticalFinalizerObject でそれなりに網は張れると．
一方で，Transactional NTFS などを使えば，ファイルシステムに中途半端な中間状態を残すのを防げますし，結局のところアイディア次第じゃないでしょうかね．
それらを含めて，「Abort が最善と思って Abort を使っている」のか，「なんとなく Abort」なのかの，どっちだったのかで回答は違ってくるのではないでしょうか？

>サーバサイドのフレームワークで，リソース利用の自動化や，プロセス再起動無しでの障害復帰を突き詰めたい場合などは，それなりに興味深いテーマだと思います．

「プロセス再起動ナシで障害復帰」で思い出した。

前にブログでちょことだけ書きましたが、FastCGI ってば、特別に FastCGI 用に書いたでもないごく普通の .exe を使って CGI リクエストに対して「プロセス再利用」で対応しているらしいんだけど、一体どうやっているんだろう？？？

> CLR はスレッド強制終了時に対象スレッドの Constrained Execution Regions や ReliabilityContractAttribute を考慮するので，操作先のスレッドの状態を一切考慮しないわけではないですし，日記で書いたように finally ブロックへの配慮といった効果もあります．また，OS リソースに関しては CriticalFinalizerObject でそれなりに網は張れると．

.NET 2.0 で安全度が高まったとはいえ、その辺の仕組みが有効に働くためには finally 節書いておくとか最小限の準備は必要だったりするので、やっぱり無条件には勧められないなぁ。（マネージドなメモリ資源に対するＧＣ位に「任せて安心」になれば、どっぷり頼るんだけど）

> 一方で，Transactional NTFS などを使えば，ファイルシステムに中途半端な中間状態を残すのを防げますし，結局のところアイディア次第じゃないでしょうかね．
> それらを含めて，「Abort が最善と思って Abort を使っている」のか，「なんとなく Abort」なのかの，どっちだったのかで回答は違ってくるのではないでしょうか？

「分かってて」やっているなら「ナシ」までは言わないとしても、往々にしてこの手のコードは「（危険性とかそういう保面について）何も考えてない」場合に書かれるのが（まぁ）世の常なので。

よっぽど深い理由でもない限り、同期オブジェクト使ってきちんと制御するのを推奨します。

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

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

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

Re[4]: スレッドのAbort()とJoin()について

過去ログには書き込み不可