Hideki Kato <katoh@pop12.odn.ne.jp> writes:

> >「上限の保証がないと困る」と言われた時に、UnixやWindowsでは保証のしよ
> >うがないわけで…
> 
> α のホストは FSP，WS は Unix＋realtime 拡張 を使ってましたが，それ
> は兎も角，copying gc の場合，ヒープのサイズが決まれば，gc に掛かる時
> 間の上限は見積もれます（でしたよね？）から，大丈夫だったような．

えーっと、user CPU時間では見積もれても、実時間では難しいのでは。
(ページフォルトが起きて、プロセスが寝てしまうと…)
ページをロックして、スケジューリングも変えておくんでしょうかね。
で、ディスクI/Oはしないとか。

> >最適化のためのプランニングとかをLispでやって、それはリアルタイム性がな
> >くても良いと言うことなんでしょうかねえ。まあ、リアルタイム応用とは言え
> >ないような。
> 
> （オフラインの）プランニングではなく，実際の運用（スケジューリング）
> です．処理に許される時間はけっこう長いけど，仕様としてはハードです．
> ＃担当者も「100%」を満たすのに色々苦労してたような記憶が．．．
> ＃まぁ，駄目な確率がハードの故障確率より低ければ十分なわけですが．

なるほど。夜のバックアップと同じような話ですかね。

(少し引用の順番変えてます。)

> >(ケータイJavaも、実時間性の不要な対話的アプリにしか使ってないのでは。)
> 
> OS は TRON 系でしったか，確か．でも，仮名漢字変換辺りだと，0.1 秒を
> 超えたら０点って仕様もありそう．
> ＃要求仕様でいいんですよね？＜ハード/ソフトの区別

客観的に根拠のあるデッドライン(NTSC規格で決まっているコマ数だとか、工
場のラインの速度とか)じゃないと、うまくないと思います(後述) 。0.1秒っ
てのは別に101ms でも95msでもかまわない、恣意的な値ですよね。

> >ただ、そういうのは反応が遅くても仕様通りであることは違いないし、せいぜ
> >い「qualityが低い」という程度であって、エラーではないですよねえ。そこ
> >がハードリアルタイムな応用とは違うところで。
> 
> パソコン（情報/家電屋）とケータイ（通信屋）では要求仕様も違う可能性
> もあります．
> ＃私ならエラーにするだろうなぁ．．．でないと悪評が立ちそうだもん．

それを言い出すとバッチ処理だろうが対話処理だろうが何だろうが「速い方が
ユーザの評判は良い」わけですから、すべてのコンピュータプログラムはリア
ルタイム処理ということになって、「リアルタイム」という言葉の実体がなく
なっちゃうと思います。

たとえば「100msを越えなければ悪評が立つ可能性は0%」とかはっきり決まっ
ているものだけに使うのが良いのでは。

                                前田敦司