2016年12月
2016年12月09日(金) #00 Essenやりたい
- アドベントカレンダじゃなくて、Essenを作りたい。
- しかしそれにしてもOSの自作ってどうしてこんなに人気があるんだろう。ハードウェアをいじるから？
- EssenにはOSっぽい要素がいくつかある。
- (1) Essenはタスクスケジューリングをする
- (2) Essenはファイルシステムの代わりをする（変数の内容が永続化されるから）
- (3) Essenは機種依存を吸収して、異機種間での互換性を提供できる
- っていうか、そもそもOSと言語処理系ってよく似ていると思う。特に私にとっては、OSなんて「アプリを実行するためのプログラム」でしかなく、言語は「プログラムを実行するためのプログラム」でしかない。アプリは機械語やバイナリで書かれていて、言語のソースコードはテキストかもしれないけど、でもそれは大した差じゃないと私は思う。
- OSも言語も、何が正しくて何が正しくないかを開発者が自由に決められる。
- (1)に関して：
- Essenのタスクスケジューリングは、基本的にはプログラムが「ここで一区切り」って書いたタイミングでしか切り替わらない。また、マルチコアCPUであっても同時に2つ以上が動作することはない（そういうこともできるけど、その場合はアクセス競合をEssenは管理しない）。
- だからマルチスレッドプログラムは非常に書きやすい。まあミスして「一区切り」命令を書き忘れるといつまでもスイッチしないという問題はある。・・・これを検出しやすくするため、あるスレッドが一定時間以上（たとえば3秒間とか）ずっと「一区切り」命令を実行しないでいると、警告が表示される。
- [Q]どうしてもっと普通の（＝勝手に切り替わるタイプの）マルチスレッドにしないんですか？・・・っていうか切り替わるタイミングを指示って、つまりイベントドリブンってことですよね？おいおい、いつの時代の話ですか？？
- [A]マルチスレッドで競合問題が生じると、解決はかなり難しい。それは結局は意図せぬタイミングで中途半端になっているデータを読み書きしたせいであり、これを何度か経験するとマルチスレッドプログラミングが嫌になる。ロックとかも学ばねばならない。・・・しかしロック・アンロックを繰り返すくらいなら、「ここで一区切り」な命令を実行させてもいいじゃないか。ここで必ず切り替わるという保証はない。もしまだ自分の実行時間が残っていれば、一区切り命令を実行してもそのまま継続する。・・・ロックし忘れは深刻なバグの温床だけど、「一区切り」のやり忘れはマルチスレッドの切り替えがまずいだけで、発見もデバッグもとても簡単である。だからこのパラダイムでやりたい。・・・まあマルチコアCPUを活用したいとかになるとこんな方法ではダメなんだけど、それはEssenを継行した人が別のプロセスでやって、その結果をEssenで受け取らせて処理する、みたいな感じになればいいと思っている。
- (2)に関して：
- 変数の永続化について、全部の変数を保存じていたら遅くてたまらないのではないかという指摘がときどきあります。・・・まあそう思うのは無理ないのですが、基本的には、処理系が起動したときにメモリに読み込んで、処理系が終了した時にディスクに書き込むような動作を考えています。だからディスクアクセスはたまにしかありません。メモリに収まらないほどの巨大変数はどうするのさ、ってことになるわけですが、そういうのはやっぱり仮想記憶的なことをやるしか・・・ないですよね。そういうことまでやるようになったら、起動時に読むのはやらなくて、最初のアクセスがあった時に読む、みたいな方式になると思います。
- しかし仮想記憶って・・・つまりスワップですよね。うわー、ますますOSっぽくなってきました！！
- (3)に関して：
- たとえばPythonプログラムはWindowsでもLinuxでもラズベリーパイでも同じように動いてくれるので、互換性を提供できているわけです。同じようなことをEssenでも目指しているだけです。この点に関しては特により優れた機能とかはないです。
- Essenがタスクスケジューリングをして、ファイルシステムの代わりになるものも提供して、互換性レイヤも提供するとなれば、もはやEssenはOSといってもいいかもと思いませんか？というかEssenの下のOSってどんな仕事が残っているのか？・・・シングルタスクで良くて、ファイルシステムもものすごく簡素なものだけで十分で・・・。
こめんと欄
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
