- - PR -
クリティカルな処理の最中にGCが走ってしまう
1
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-04-13 05:36
いつもお世話になっております。
他の機械と協調して動く機械を作っています。時間をキーにして協調するしかない状態で、クリティカルな繰り返し処理をタイミングを合わせて行っている時に、GCが走ってしまうためにタイミングがずれてしまうという問題で悩んでいます。 処理を一定数終えたところで GC.Collect() を呼び出すことで想定外のGCの動作を無くそうとして見ましたが、GC.Collect()は予想以上に時間がかかり、全体のパフォーマンスを大幅に下げてしまうことが分かりました。 「ここからここまでの処理の間はGCが走らない」というようなことを保証する方法はないでしょうか?よろしくお願いいたします。 | ||||||||
|
投稿日時: 2006-04-13 07:11
そう思われている「構成」を教えてください。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||
|
投稿日時: 2006-04-13 10:04
無線通信の機器から出る信号を測定しようとしています。 信号発信と受信機器のデータ取得開始を一斉に行いますが、信号の方は一度スタートすると独自のプロトコルに沿って一通りのパターンを発信します。その途中で同期信号のようなものを出したりはしません。 その中でデータを取得したいポイントが多くありまして、そのポイントを逃さずに、かつスタートしてからの時間を計ることで、どの部分の信号を見ているのかを判断しています。数msずれる位ならばデータを長めに取ることで対応できるのですが、GCが起動すると話にならないぐらいのズレが起こってしまうのです。 というのが「構成」です。どうぞよろしくお願いします。 | ||||||||
|
投稿日時: 2006-04-13 10:43
すみません。少し疑問に感じたので一つ。
OS は何か特別なものをつかっているのでしょうか?リアルタイム OS でもないのに、そんなにクリティカルな処理が出来るのでしょうか。 .NET Framework が対応しているリアルタイム OS を私は知らないのです。 | ||||||||
|
投稿日時: 2006-04-13 10:45
Σ(;・Д・) これが当初より逃れられないものであれば、言語選択を誤っているような...
すぐ思いついたのは、GC.KeepAlive ですが、全部洗い出せるかどうか... 不要だから GC に回収されるわけで、不要にしなければ良いという意味では、 静的変数の嵐という手もありますが、どちらにしてもなんだかイヤですね。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||
|
投稿日時: 2006-04-13 10:54
「クリティカル」というより「リアルタイム」ですよね。 プラットフォームの選定を誤っているように思います。 その機器とPCとの間になにか別の機器が要るような気がします。 _________________ たつごろー codeseek こみゅぷらす | ||||||||
|
投稿日時: 2006-04-13 21:49
GC がどの様なときに動くのかを考えると、GC が動かないように工夫することも出来ると思います。
大きなメモリを確保して、参照から外す、、、という処理を何度か行うと、GC が回収に走ります。であれば、大きなメモリは再利用できるようにすれば、新たに確保しようとしないので、GC が回収に走らないということです。 また、GC のコストが高いのではなく、Finalize のコストが高いのですから(結局 GC なんだけどね)、ファイナライズの必要がないようにすることも、重要でしょう。 ん〜?通信の受信と処理ですよね?そんなに長時間やるんですか? 『「ここからここまでの処理の間はGCが走らない」というようなことを保証する方法はないでしょうか?』というところから、そんなに長い時間ではないと思うのですが。 短時間(せいぜい10分)という前提で、そんな期間で GC が回収に走るって、そっちの方が問題なような??? あと、GC だけじゃないですよね。その辺、大丈夫ですか? # ってか、大丈夫なら、GC が動いても大丈夫だろうに。。。 # ってのが、たつごろーさんらの指摘ですね 〆 written by Jitta@わんくま同盟 on 2006/04/13 □ Microsoft MVP for Visual Developer ASP/ASP.NET October, 2005 - September, 2006 | ||||||||
|
投稿日時: 2006-04-13 22:13
#設計からやり直し! Windows Kernelがスレッドを管理するときの時間分解能は10ms(マルチプロセッサの場合)ですよ。それより短い時間での制御なんて、充てになるわけ無いじゃないですか。Windowsを採用するなら数十msのずれが発生しても問題ないように設計する必要があります。 GCのときも固まるでしょうけど、メモリスワップなどでも同じぐらいの時間固まるはずです。コーディングの工夫で発生頻度を下げることは出来るかも知れないけど、なくす術はありません。一度でも遅れが発生することは許されないなら、設計からやり直す方が良いでしょうね。 ・・・・といいつつ、打開策を。 上記のような事情があるので、最近のADボードやDIボードってインテリジェントなものが多いんだけど、本当にタイムクリティカルな制御が必要なの?ハードウェアの機能を有効に活用すれば十分に対応できたりしません? |
1