yas@is.tsukuba.ac.jp (Yasushi Shinjo) writes:

> > Cでも、同じプロセスでページフォルトとかディスクI/Oとかが起きちゃったら、
> > リアルタイム性はなくなっちゃいますよね。1つのプロセスにunboundな部分と
> > boundな部分を混ぜて書くのは無理でしょう?
> 
> C 言語というか、OS の機能になりますが、１つのプロセスでペー
> ジ・フォールト起さないようにすることは、できます。Unix 系で
> は、mlock()。

ええ。実メモリの範囲内(boundなデータ量)で、リアルタイムにやることはで
きますよね。でも、同じプロセスでunboundな(仮想記憶に依存せざるを得ない)
部分を混ぜちゃったら、全体がリアルタイムでなくなってしまうでしょう、と
いう話です。

> C では、malloc() して、その番地付近を mlock() 
> するか、malloc() は使わないで /dev/zero を mmap() してとった
> 領域を mlock() するかでしょうか。

最初にmlockして、その領域だけ使うなら(そして、他のプロセスや割り込み
処理より優先して走るなら)リアルタイムでしょうね。でも、処理の途中で
mallocやmmapするとリアルタイムとは言えなくなるでしょう。(mallocから
mmapを呼び出すのは割と普通です。GNU libcのmallocはsbrkに加えてmmapも使
います。)

> ディスクＩ／Ｏについても、ファイルのディスク・ブロックを並べ
> 替えたりするようなＯＳはあります。そうするとシーク時間とか回
> 転待ち時間まで計算すると上限がわかります。このあたり、言語の
> 問題ではないのですが。

ソフトリアルタイムな(メディアサーバ用の)ファイルシステムの論文は読んだ
ことがあります。まあ、言語の問題ではないですね。

> C で、mlock() を使うに相当するのは、Lisp で cons する時に、
> ページングされない領域にセルを取る、では足りないんですよね。

# mlockはCの機能じゃなくてOSの機能ですから「Cで」という言い方は少し
# 変ですが。

Lispで、プロセスのメモリ領域全体をmlockできれば、メモリ割り付け処理自
体はリアルタイムに行なえます。

# 「足りない」とは?

> > じゃあ、なぜリアルタイムGCを持っている処理系がないんだと言うことになり
> > ますが… それはUnixやWindowsでGCだけリアルタイムにしても無意味だから。
> > リアルタイムGCの数%のオーバーヘッドの分だけ損してしまう。
> 
> 実時間ＯＳではないくせに、けっこう実時間のアプリケーション
> （音楽とか動画の再生など）が、そこそこ走ってしまうという話も
> あります。その「そこそこ」には涙ぐましい努力があるのでしょう。
> 本来ならＯＳがやるようなファイル入出力のバッファの管理を自分
> でやるとか。

ソフトリアルタイムのプログラムはなかなかうまく動いていますね。大量のメ
モリにバッファリングして、デッドラインミスの確率を減らしているんでしょ
うね。でも、ハードがもっと非力な頃でも、BeOSではうまく動いていたことを
考えると、OS の機能がやっぱり重要なんじゃないでしょうか。

> > # GCを止めたり、特別なアロケータを使ったりしないでOSを書いて見せればデ
> > # モンストレーションになりますかね。
> 
> トータルのメモリが節約になるということも言えるかも。つまり、
> 静的に確保すると安全策でついつい多め、長めに確保して実は同時
> には使わないという話も多いのかも。人間が考えて「ついつい」を
> 削除すればいいんですが、それは高度な話なので、自動化できれば
> その方がいいでしょう。

うーん、ポインタ追跡型のGCが効率的に働くには、何割かの「空き領域」が必
須なので、節約になるとは必ずしも言えないんですが…

サイクルさえなければ参照カウント式GCは最小限のメモリですみますね。
同じように、「参照カウントをつねに1に制限する」という言語を
Henry G. Bakerが提案したことがあって、
http://home.pipeline.com/~hbaker1/LinearLisp.html
問題によっては、メモリ使用量を大幅に削減できるという報告をしています。
http://home.pipeline.com/~hbaker1/LFrpoly.html
# Concurrent Cleanのuniqueness typesにこの考え方は残ってます。

                                前田敦司