ThreadのPriorityについて

Thread.Startで起したThreadとBeginInvokeで起したThreadを両方使っていますが、このように交え使う場合、何か不都合が生じるでしょうか？

また、何れのタイプのThreadも実行している間に止まったような感じがするので、Thread自体止まる要因として何が考えられるでしょうか？

例えば、ガベジコレクションが動作するとうまく行かないとか？

Hongliangさんの書き込み (2006-05-15 18:10) より:

止まったような感じというのがどんなのか分からないので答えようがないです。
// 「ような感じ」ってことは実際には止まってないのか？　とか。
もっと具体的に、どんな現象が発生しているのでしょうか。

これは新しくスレッドを立てているとかどうかとは無関係の話です。

ひょっとして高度なリアルタイム性を要求していますか？

本当は止まっています。確認の仕方として、該当Threadは段階的にLogを吐くはずなので、処理の途中でLogが途絶えて、先に進まないことで「止まった」と判断したわけです。

そうですね。リアルタイムで、MuiltiThreadで動作しないといけませんので、通信のやり取りは全てThreadでEvent通知を行っています。

OSのThreadPool自体が不透明がところが多く、やむ得ない限り自作のThread管理を行っています。リアルタイム性が強いと、何か気になることがありますか？

Hongliangさんの書き込み (2006-05-15 20:04) より:

引用:
本当は止まっています。確認の仕方として、該当Threadは段階的にLogを吐くはずなので、処理の途中でLogが途絶えて、先に進まないことで「止まった」と判断したわけです。

途絶えて先に進まない、ってのはそこで処理が滞ると言うことなのか、それともスレッドが終わっちゃうのかどっちでしょう？
発生頻度は？　どれくらいの時間？　複数のスレッドが同時に止まるのですか？

引用:
そうですね。リアルタイムで、MuiltiThreadで動作しないといけませんので、通信のやり取りは全てThreadでEvent通知を行っています。 OSのThreadPool自体が不透明がところが多く、やむ得ない限り自作のThread管理を行っています。リアルタイム性が強いと、何か気になることがありますか？

数ミリ秒を気にするようなリアルタイム性を Windows は持ってませんし、数十ミリ秒の間隔を取りこぼしたらいけないようなのは .NET Framework では実現不可能ですから。

ちなみに、 .NET の ThreadPool は OS(Windows) ではなく .NET Framework の実装です。

siaさんの書き込み (2006-05-15 23:35) より:
[準備]
各スレッドに名前を付ける。

[デバッグ]
1.デバッグ版を実行。（VSからではなく、直接起動）
2.問題となるスレッドの実行が停止したら、プロセスにアタッチでVSにデバッグプロセスをアタッチ
3.全て中断で全スレッドを停止。
4.デバッグウインドウのスレッドを表示
5.止まっているスレッドを「スレッド」ウインドウでクリックして、いろいろ調査。

因みに、Thread.Start後はThreadが勝手に止まることがないと思いますが、どこかでLockが発生しない限り、最後まで必ず実行すると認識してもよろしいでしょうか？

因みに、XPのThreadにてEventを通知する際、紛失を顧慮してイベントの再送する仕組みが必要でしょうか？

1.デバッグ版を実行。（VSからではなく、直接起動）

引用:
因みに、XPのThreadにてEventを通知する際、紛失を顧慮してイベントの再送する仕組みが必要でしょうか？

それと上記ですが、.Netのイベント（BeginInvokeで起こしたイベント？）
のことでしょうか？

数十ミリ秒の間隔を取りこぼしたらいけないようなのは