久野です。

kono@ie.u-ryukyu.ac.jpさん:
> 一般的には、そっちの方がやさしいんじゃないかなぁ... プログラ
> ムの終了証明は難しいけど、scheduler の fairness を示すのは簡
> 単ですよね。

  fairならいいんですよ。hard realtimeだから「上限」を示す必要
があるんです。自動調整したら問題が複雑になるだけだと思うね。

> Hard Real-time で、GC あるいは Dynamic Allocation を使うってこと
> 自体、想定するのが難しいわけなんだけど...

  ええ? 動的メモリ管理、普段使いませんか。普段使うならそれを
realtimeでやりたいというニーズがあっても驚かないと思うな。頭から
「それは不可能」と信じ込んでいるんでない限り :-P

> ただ、Real-time 系の場合は「ゴミになった」とわかった時点で回
> 収しちゃうのが普通じゃないかなぁ。だから、GCしないんだよな、

  別に普通かどうかはどうでもよくてGCがあった方がいいかどうか、
可能かどうかを議論しております。

> 普通。ゴミになったかどうかを判定することが定数時間で出来れば、
> GC する必然性はないので。

  ゴミになったかどうかを判定するバグが心配な(複雑になったらかな
りそうでしょ?)プログラムをそのつど書くより、realtimeの保証がある
枯れたGCがあればその方が安心でしょ?

                だからGCがあった方がいいと思うね。         久野

P.S. 河野さん、確認ですけど「hard realtimeなGCは書けば書ける」と
     いう主張には同意頂けましたか。まだ3色塗りとかじゃ信用できない?