Scribble at 2023-11-17 11:47:25 Last modified: unmodified

恐らく CPU の設計やドライバとカーネルの開発に匹敵するような、かなりシビアなプログラミングの話題と言えるのが、このリアルタイム Linux の話題だ（ちなみに "RTLinux" と Linux Foundation が手掛けている "Real-Time Linux" は無関係のプロジェクトだ）。まず初めて知るという方には、「リアルタイム」という概念について誤解される恐れがあるので説明しておく。real time operation system (RTOS) 開発における「リアルタイム」というのは、何か基準になるプロセルと同時平行に実行されるといった意味ではない。工学的な意味での「リアルタイム・システム」とは、或る定められた期限までに処理を終えることであり、そのために必要なプロセスを正確かつ確実に制御して目標時間までに完了するべきタスクを全て終えることを意味している。典型的なリアルタイム・システムを挙げると、たとえば自動車のエア・バッグやブレーキだとか、鉄道の ATS（自動列車停止装置）や信号伝送網がある。また、電気的な制御ではないがパラシュートもリアルタイム・システムの概念で設計されている装置の一つだと言える。これらは稼働させてから目標とする結果に至るまでの時間が定められている。リアルタイム・システムには、期限までに結果へ至らなければ破滅的な状況となるもの（パラシュートやブレーキなどはそうだろう）、期限を過ぎると少しずつ結果の価値が失われるもの（ゲームのレスポンスの遅延は、プレイヤーにとっては破滅的な結果だと思うかもしれないが、商業的にはそうではない）、あるいは期限を過ぎても破滅的な結果にはならないが結果の価値がなくなるもの（金融や天気の予測情報）という違いがあるけれど、いずれにしても期限が設定されていて、それまでに結果を保証するように動作するシステムがリアルタイム・システムである。

このように厳格な動作を保証するシステムを OS、とりわけ Linux で実現しようというのが real time Linux のプロジェクトだ。とは言っても、Linux で動作するあらゆるプロセスやアプリケーションの動作をリアルタイムに遂行するなんてことまで目標にしているわけではない（そんなのは無理である）。おおむね、カーネルの動作のみを対象としている。それでも、カーネルのソースコードですら頻繁に改変が行われている以上、リアルタイムであることを維持しながらソースを改良していくという品質管理は大きな負荷がかかるため、このような Linux カーネルを生み出したりメンテナンスするのは無理だとも言われてきた。

カーネルは色々なプロセスを制御しているため、リアルタイムで実行することが求められるプロセスには処理を最優先で実行するように優先順位が与えられる。このような優先順位の管理（スケジューリング）はカーネルの果たすべき機能の基本であり、ここには「先取り（preemption）」という概念がある。このようなレベルのプロセス制御は、いまでは大半の OS に組み込まれており、カーネルの動作を最優先にしてデッドロックが発生しにくいようにするということは、いまや特別な設計でも何でも無い。そうなると、今度はカーネル内での、コアとそれ以外との優先関係を厳密に制御するという問題になる。これで、かなりの時間が費やされてきたらしく、いまでも printk() というメッセージの制御において複雑な問題が残っているようだ。

そして、これらが Linux のカーネルに反映されるにあたっては、いくつものパッチとしてマージされるのであって、カーネルの設計を書き換えるようなものではない。したがって、今後もソースのメンテナンスには多大な努力が続けられる必要があり、それなりに大きなリソースを必要としていくように思える。正直なところ、開発の経緯や実情の報告を読むと、これはいかにも面倒臭い作業であり、設計からやり直したほうがいいような気もするのだが、もちろんそれは僕のような技術者がほぼ仕事の大半を単独で遂行しているという事情にあるからだ。Linux のカーネル開発を始めとする多くのプロジェクトでは、個人として暇潰しにやるならともかく、カーネルを一から設計し直すなんてことは、学生の演習レベルでしか実行できないものである。