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

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

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

Re[7]: Formイベントが呼ばれるスレッドについて

(過去ログ 33 を表示中)

[トピック内 15 記事 (1 - 15 表示)]　 << 0 >>

■16452 / inTopicNo.1)

　Formイベントが呼ばれるスレッドについて

▼■

□投稿者/ dai (8回)-(2008/04/06(Sun) 14:03:54)

分類:[.NET 全般]　

VC# 2008 .NET Framework3.5

フォーム毎にスレッドを起動して表示しています。
Application.Exit()で全てのフォームを閉じる時、各フォームのFormClosing、FormClosedイベントが呼ばれるのですが
そのイベントの中でThread.CurrentThread.ManagedThreadIdの値を調べてみると
フォームが所属するスレッドではなく、Application.Exit()を呼び出したスレッドになってました。

Win32ではウィンドウプロシージャはそのウィンドウが所属するスレッドで呼び出される事が保証されてましたが
.NET Frameworkでは違うのでしょうか?
複数のスレッドから同時にイベントが呼び出される事を意識して書かなければならないのでしょうか?

引用返信 編集キー/

■16453 / inTopicNo.2)

　Re[1]: Formイベントが呼ばれるスレッドについて

▲▼■

□投稿者/ ネタ好き (38回)-(2008/04/06(Sun) 14:46:41)

2008/04/06(Sun) 14:47:17 編集(投稿者)

■No16452 (dai さん) に返信
.NET Frameworkは必ずしも論理スレッド（.NET）と物理的スレッド（OSリソース）が一対一で対応しておりません。
これはパフォーマンスをあげるための工夫であり、
マルチプロセッサを意識した方向へヴァージョンアップしていくでしょうから、
複数のスレッドから同時にイベントが呼び出される事を意識して書く必要があると思います。

引用返信 編集キー/

■16455 / inTopicNo.3)

　Re[1]: Formイベントが呼ばれるスレッドについて

▲▼■

□投稿者/ Azulean (60回)-(2008/04/06(Sun) 15:16:54)

> フォームが所属するスレッドではなく、Application.Exit()を呼び出したスレッドになってました。
Application.Exitの実装が、直接に各フォームのClosing、Closedイベントを呼び出す独自の実装になっているので、Application.Exitを呼び出したスレッドで実行されるのは自然です。
（ウィンドウプロシージャを使いません）

> Win32ではウィンドウプロシージャはそのウィンドウが所属するスレッドで呼び出される事が保証されてましたが
> .NET Frameworkでは違うのでしょうか?
Application.ExitがWM_CLOSEを投げる実装ではないからです。
よって、ウィンドウプロシージャに処理が渡りませんので、このルールとは関係ありません。

ウィンドウプロシージャとイベント（ハンドラ）は異なるものです。

> 複数のスレッドから同時にイベントが呼び出される事を意識して書かなければならないのでしょうか?
FileSystemWatcherもそうですが、イベントによってはそういった考慮が必要です。

-----
> .NET Frameworkは必ずしも論理スレッド（.NET）と物理的スレッド（OSリソース）が一対一で対応しておりません。
ファイバーの話でしょうか？
通常のWindowsフォームアプリケーションでは無縁なような気がします。
詳細には調べていないので全てにおいてそういえるわけではありませんが、頻繁に気にしないと行けないほどでもないと考えています。

詳しい方の突っ込み歓迎。

引用返信 編集キー/

■16457 / inTopicNo.4)

　Re[2]: Formイベントが呼ばれるスレッドについて

▲▼■

□投稿者/ 渋木宏明(ひどり) (691回)-(2008/04/06(Sun) 15:30:33)

>>.NET Frameworkは必ずしも論理スレッド（.NET）と物理的スレッド（OSリソース）が一対一で対応しておりません。
> ファイバーの話でしょうか？

違います。

.NET の Thread は、ごく単純な Win32 Thread のラッパではない、という系統の話です。

が、まぁ大ざっぱには

> 通常のWindowsフォームアプリケーションでは無縁なような気がします。

と言えます。

引用返信 編集キー/

■16459 / inTopicNo.5)

　Re[3]: Formイベントが呼ばれるスレッドについて

▲▼■

□投稿者/ ネタ好き (40回)-(2008/04/06(Sun) 16:35:21)

■No16457 (渋木宏明(ひどり) さん) に返信
> >>.NET Frameworkは必ずしも論理スレッド（.NET）と物理的スレッド（OSリソース）が一対一で対応しておりません。
>>ファイバーの話でしょうか？
>
> 違います。
>
> .NET の Thread は、ごく単純な Win32 Thread のラッパではない、という系統の話です。
>
> が、まぁ大ざっぱには
>
>>通常のWindowsフォームアプリケーションでは無縁なような気がします。
>
> と言えます。
>

その通りですね。

引用返信 編集キー/

■16461 / inTopicNo.6)

　Re[3]: Formイベントが呼ばれるスレッドについて

▲▼■

□投稿者/ dai (9回)-(2008/04/06(Sun) 18:07:19)

PaintやMouseDown等のイベントも、同時呼び出しや他スレッドからの呼び出しを考慮しないといけないのでしょうか?
そうなると、例えばMouseDownイベントでラベルの文字列を更新するためにForm.Invokeを介して…と
ものすごく面倒になりそうなんですが…

> > 複数のスレッドから同時にイベントが呼び出される事を意識して書かなければならないのでしょうか?
> FileSystemWatcherもそうですが、イベントによってはそういった考慮が必要です。

どのイベントが該当するかはどうやって判断するのでしょうか?
MSDNのFormClosingやFormClosedにはそれらしい説明は無かったのですが…

引用返信 編集キー/

■16463 / inTopicNo.7)

　Re[4]: Formイベントが呼ばれるスレッドについて

▲▼■

□投稿者/ Azulean (61回)-(2008/04/06(Sun) 18:50:55)

> どのイベントが該当するかはどうやって判断するのでしょうか?
> MSDNのFormClosingやFormClosedにはそれらしい説明は無かったのですが…
Application.Exitにはイベントを発生させるとしかありませんね。
http://msdn2.microsoft.com/ja-jp/library/ms157894.aspx

情報を得るために？
・イベント側のドキュメントを読む。（受ける側）
・メソッド側のドキュメントを読む。（送る側）
・実際に動かして確かめる。あるいはVS2008でソースを読む。
・ネット上で似たような問題がないか探してみる。

今回のパターンは非常に分かりにくいと感じます。
MSDNフォーラムのドキュメントフィードバックに寄せてはいかがでしょうか。

引用返信 編集キー/

■16464 / inTopicNo.8)

　Re[3]: Formイベントが呼ばれるスレッドについて

▲▼■

□投稿者/ NyaRuRu (35回)-(2008/04/06(Sun) 19:10:05)

■No16453 (ネタ好きさん) に返信
> 2008/04/06(Sun) 14:47:17 編集(投稿者)
>
> ■No16452 (dai さん) に返信
> .NET Frameworkは必ずしも論理スレッド（.NET）と物理的スレッド（OSリソース）が一対一で対応しておりません。
> これはパフォーマンスをあげるための工夫であり、
> マルチプロセッサを意識した方向へヴァージョンアップしていくでしょうから、
> 複数のスレッドから同時にイベントが呼び出される事を意識して書く必要があると思います。

Win32 Fiber のようなユーザモードスレッド切り替えでパフォーマンス (スループット) が向上するのは，MSSQL Server のような調停者を置いて大規模並列計算を行うときだと理解しています．
スレッドが重要というのは同意ですが，少なくとも現時点において，N:M スレッド対応でパフォーマンス的な恩恵を受けている .NET アプリケーションは皆無だと思います．(むしろパフォーマンスは若干落ちているはず)

■No16457 (渋木宏明(ひどり) さん) に返信
> >>.NET Frameworkは必ずしも論理スレッド（.NET）と物理的スレッド（OSリソース）が一対一で対応しておりません。
>>ファイバーの話でしょうか？
>
> 違います。
>
> .NET の Thread は、ごく単純な Win32 Thread のラッパではない、という系統の話です。

んー，表向きのところは別物ですけど，実際のところは正解かなぁという気も．
CLR が N:M スレッド対応にこだわっていたのは，まさに Win32 Fiber のサポートを念頭においていたからで正解じゃないでしょうか．
もっとも，CLR 2.0 でこの計画がぽしゃったため，近い将来 N:M スレッド対応が出てくるとは思えませんけど．

ちなみに，.NET 2.0 以降の流行としては，COM が自動的にアパートメント越えをやるのと似た方向の仕組みが用意されてきているので，フレームワーク屋さんがそれを使って，フレームワーク利用者はロジックだけを書けば自動的にスレッド越えをやってくれる方向に進んでいるような気がします．
BackgroundWorker を使うと Invoke が見た目なくせるのは，裏で SynchronizationContext を使ってディスパッチしてくれているからとかでしたかね．

引用返信 編集キー/

■16468 / inTopicNo.9)

　Re[4]: Formイベントが呼ばれるスレッドについて

▲▼■

□投稿者/ ネタ好き (41回)-(2008/04/06(Sun) 20:31:49)

2008/04/06(Sun) 20:47:00 編集(投稿者)
2008/04/06(Sun) 20:35:23 編集(投稿者)
2008/04/06(Sun) 20:33:44 編集(投稿者)

> ちなみに，.NET 2.0 以降の流行としては，COM が自動的にアパートメント越えをやるのと似た方向の仕組みが用意されてきているので，フレームワーク屋さんがそれを使って，フレームワーク利用者はロジックだけを書けば自動的にスレッド越えをやってくれる方向に進んでいるような気がします．
> BackgroundWorker を使うと Invoke が見た目なくせるのは，裏で SynchronizationContext を使ってディスパッチしてくれているからとかでしたかね．

マイクロソフトは関数言語にも力を入れているからErlangの取り込みもありえますよね。
マルチスレッドはデバッグが大変なので、そうしてくれると多くの人が喜ぶと思いますし、
商売上手なマイクロソフトならばきっとそれを売り文句にするはず。
ただ、その実装もオープンソースにしてもらわないと違う方面で困りそうです。
知的好奇心が満たせないとか、ある特殊な状況で再現不可能なバグが発生するとか・・・

引用返信 編集キー/

■16469 / inTopicNo.10)

　Re[4]: Formイベントが呼ばれるスレッドについて

▲▼■

□投稿者/ 渋木宏明(ひどり) (692回)-(2008/04/06(Sun) 20:39:12)

> Win32 Fiber のようなユーザモードスレッド切り替えでパフォーマンス (スループット) が向上するのは，MSSQL Server のような調停者を置いて大規模並列計算を行うときだと理解しています．

理屈の上ではそうだけど、効果を実感できる局面は限られてると見ていいでしょう。

SQL Server が Fiber をサポートして久しいけど、「Fiber を有効にしたらパフォーマンスが劇的に改善された」という話題を目にした記憶は、僕には今のところありません。

> スレッドが重要というのは同意ですが，少なくとも現時点において，N:M スレッド対応でパフォーマンス的な恩恵を受けている .NET アプリケーションは皆無だと思います．(むしろパフォーマンスは若干落ちているはず)

まぁ無いでしょうね。でも損失もそれほど大きなものではないでしょう。

Windows Forms に関して言うと、ダイナミックに物理スレッド/論理スレッドの切り替えが発生することはまずあり得ないし。

> もっとも，CLR 2.0 でこの計画がぽしゃったため，近い将来 N:M スレッド対応が出てくるとは思えませんけど．

現時点で盛り込めてないってことは当分無いでしょうね。
将来的に盛り込むとしたら、もっと別な形になるような。

> 動的にスレッド越えをやってくれる方向に進んでいるような気がします．

「隠しちゃう」ってのも一つの方向性ではありますね。

引用返信 編集キー/

■16479 / inTopicNo.11)

　Re[5]: Formイベントが呼ばれるスレッドについて

▲▼■

□投稿者/ NyaRuRu (36回)-(2008/04/06(Sun) 22:14:05)

2008/04/06(Sun) 22:24:11 編集(投稿者)
2008/04/06(Sun) 22:14:56 編集(投稿者)

■No16469 (渋木宏明(ひどり) さん) に返信
>>Win32 Fiber のようなユーザモードスレッド切り替えでパフォーマンス (スループット) が向上するのは，MSSQL Server のような調停者を置いて大規模並列計算を行うときだと理解しています．
>
> 理屈の上ではそうだけど、効果を実感できる局面は限られてると見ていいでしょう。
>
> SQL Server が Fiber をサポートして久しいけど、「Fiber を有効にしたらパフォーマンスが劇的に改善された」という話題を目にした記憶は、僕には今のところありません。

言葉足らずですみません．大規模並列計算を行うときに Fiber で必ずスループットが向上すると言いたいのではなくて，仮にパフォーマンスが上がるとしてもそういうエクストリームな世界のみだろうというのが言いたかった話です．

>>スレッドが重要というのは同意ですが，少なくとも現時点において，N:M スレッド対応でパフォーマンス的な恩恵を受けている .NET アプリケーションは皆無だと思います．(むしろパフォーマンスは若干落ちているはず)
>
> まぁ無いでしょうね。でも損失もそれほど大きなものではないでしょう。
>
> Windows Forms に関して言うと、ダイナミックに物理スレッド/論理スレッドの切り替えが発生することはまずあり得ないし。

すみません，ここも言葉足らずでしたが，私の理解している範囲では現在の CLR ではダイナミックに物理スレッド/論理スレッドの切り替えは不可能なはずです．
んで，将来の N:M スレッド対応のために BCL の中に盲腸のようなメソッド呼び出しが残っている．そんな感じだったような．
Thread.BeginThreadAffinity とか EndThreadAffinity とかですね．あんまりちゃんと憶えてないですが，SSCLI のソースを読むとあちこちで使用されていて，だいぶソースを複雑にしていたという記憶があります．Silverlight VM だと消されているかもしれません．

ちょっと本題から離れすぎなので，興味がある方は続きは以下を読んだ上で別スレッドでどうぞという方向で．
http://www.bluebytesoftware.com/blog/PermaLink,guid,8c2fed10-75b2-416b-aabc-c18ce8fe2ed4.aspx
http://www.bluebytesoftware.com/blog/PermaLink,guid,2d0038b5-7ba5-421f-860b-d9282a1211d3.aspx

引用返信 編集キー/

■16482 / inTopicNo.12)

　Re[6]: Formイベントが呼ばれるスレッドについて

▲▼■

□投稿者/ 渋木宏明(ひどり) (693回)-(2008/04/06(Sun) 23:18:35)

> 言葉足らずですみません．大規模並列計算を行うときに Fiber で必ずスループットが向上すると言いたいのではなくて，仮にパフォーマンスが上がるとしてもそういうエクストリームな世界のみだろうというのが言いたかった話です．

それはもちろん分かってます。

マルチスレッドで十分に効果が実感できるようなケースであっても、さらに Fiber の導入によってもっと多くの効果が実感できるかというとそーでもないね、ってことです。

Fiber の利点はコンテキストスイッチが軽いことのはずですが、実行コードが複雑になればなるほど、ボトルネック全体に占めるコンテキストスイッチの比重は下がる傾向にあるからなんでしょうね。

それに、あまりにも細かい単位でコンテキストスイッチすると、近代的なＣＰＵの実行時最適化を無駄にしてしまったりもするだろうし。

> すみません，ここも言葉足らずでしたが，私の理解している範囲では現在の CLR ではダイナミックに物理スレッド/論理スレッドの切り替えは不可能なはずです．
> んで，将来の N:M スレッド対応のために BCL の中に盲腸のようなメソッド呼び出しが残っている．そんな感じだったような．

やっぱり盲腸なのかな？

一応、建前は建前で守るべきってことで、真面目に

> Thread.BeginThreadAffinity とか EndThreadAffinity とかですね．

なんかも使ったこともあります (^^;

> Silverlight VM だと消されているかもしれません．

Silverlight では他にもいろいろ省略されてたりするしますしね。

引用返信 編集キー/

■16498 / inTopicNo.13)

　Re[5]: Formイベントが呼ばれるスレッドについて

▲▼■

□投稿者/ ネタ好き (44回)-(2008/04/07(Mon) 12:38:51)

＞それに、あまりにも細かい単位でコンテキストスイッチすると、近代的なＣＰＵの実行時最適化を無駄にしてしまったりもするだろうし。

私ハードウェアに詳しく無いので気になるのですが、
やはり、キャッシュやパイプラインについても悪影響を与えるのでしょうか？
マルチスレッドは命令のパイプラインがしずらいような気がします。

引用返信 編集キー/

■16513 / inTopicNo.14)

　Re[6]: Formイベントが呼ばれるスレッドについて

▲▼■

□投稿者/ 渋木宏明(ひどり) (696回)-(2008/04/07(Mon) 14:04:52)

> やはり、キャッシュやパイプラインについても悪影響を与えるのでしょうか？

無いことはないはずです。

> マルチスレッドは命令のパイプラインがしずらいような気がします。

影響があるとして、後はそれがどの程度のインパクトがあるかです。

スレッド切り替えやプロセス切り替えは、近代的なＣＰＵのパイプラインや分岐予測に影響を与え得ます。

ですが、切り替えが発生するまでにそれなりの量のコードが実行されるため、それくらいのペナルティならあきらめもつくでしょうという話だと思います。

Fiber を使う場合、スレッドよりも粒度が低くなるはずなので、その辺のペナルティが表面化してくるんじゃないかなぁと。

引用返信 編集キー/

■16518 / inTopicNo.15)

　Re[7]: Formイベントが呼ばれるスレッドについて

▲▼■

□投稿者/ ネタ好き (47回)-(2008/04/07(Mon) 17:24:18)

■No16513 (渋木宏明(ひどり) さん) に返信
>>やはり、キャッシュやパイプラインについても悪影響を与えるのでしょうか？
>
> 無いことはないはずです。
>
>>マルチスレッドは命令のパイプラインがしずらいような気がします。
>
> 影響があるとして、後はそれがどの程度のインパクトがあるかです。
>
> スレッド切り替えやプロセス切り替えは、近代的なＣＰＵのパイプラインや分岐予測に影響を与え得ます。
>
> ですが、切り替えが発生するまでにそれなりの量のコードが実行されるため、それくらいのペナルティならあきらめもつくでしょうという話だと思います。
>
> Fiber を使う場合、スレッドよりも粒度が低くなるはずなので、その辺のペナルティが表面化してくるんじゃないかなぁと。
>
>

うーん、私好みの難しい話題ですね。
マイクロソフトはスレッド切り替えやプロセス切り替えを減らすため論理化したはずですので、
System.AppDomain（プロセス）とSystem.Threadingを上手い事実装してくれれば、
何とかなる気もしますが、プロセッサはアセンブリレベルで最適化するはずですし・・・
さて、どうなる事やら。

引用返信 編集キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

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

- Child Tree -