IGINブルネイ/syasudaの日記(MT版)

さっき読み返した、ちょっと古い本の紹介です。

すでに解決されたような雰囲気のある諸問題も、表面化しないだけでしぶとく生き残っていることがあります。

RTOSのハードリアルタイム性もそういう問題だと思っています。

この本は隅から隅まで読んで損はないと思いますが、たとえば優先度について以下のような記述があります。

たとえば,どちらのOS*1もタスクをプライオリティレベルだけで単純に特徴づけている。そもそも,このプライオリティという概念はCPUにとっては単純な概念だが,リアルタイムシステム設計者にとってはあいまいな｢主観的複合概念｣である。

私は優先度はリアルタイムアプリケーションにおいては、「くその役にも立たないもの」だと考えています。

良く見かけるのが、システムが高負荷時に、「大事なタスクにCPUが回らない」というときです。安易に「じゃぁタスクのプライオリティをあげてみよう」という対策が提案され実行されます。しかし多くの場合は副作用が後で露見して元に戻すことになるのです。

次のページには、「●ハードリアルタイムに必要な技術とは」という項目に以下のような記述があります。

.ハードリアルタイムのためには,次のような特徴(技術)が必要となる.

A)タスク属性としてデッドラインを指定できる

現状では,タスクに関するパラメータはプライオリティしかないが,時間領域の正確さを管理するためにはデッドライン,つまり締切時間をタスク属性として加え,RTOSが管理する必要がある.

B)スケジュール可能性について予測する.RTOSがタスクをスケジュールした段階で実行可能でなければ警報を出せるかどうか

C)障害時でも上記2項目を保証できる.つまりフォールトトレランス性はあるかどうか

D)システムを稼動させたままでメンテナンスやバージョンアップができる

これらの項目を満足させなければ,ハードリアルタイムシステムを構築することは困難である.上記の項目をすべてクリアしている商用RTOSは,いまのところない

デッドラインつまり締め切りを指定できないというとことはそのタスクは処理をいつ終えるかわかったものではないということです。RTOSのスケジューラは締め切りを知りませんから。

リアルタイムアプリの開発者の皆さまに聞いてみたいものです。『あなたのプログラムに処理の締め切りは指定してありますか？』と。

おそらく明示的でない指定をしているわけですが、RTOSは締め切りを知らないのですから、締め切りを守りようがありません。

指定された締め切りを満たすスケジューリングが常にできるかどうかも、スケジューラにとっては『しったこっちゃない』わけですな。

私は「リアルタイム性のためにRTOSを採用」という文言を見るたびに眉に唾をつけるようになってしまいました。この本のおかげです。

この本を読めばリアルタイム性の担保のためにはシステム設計が必要であり、プログラムの実装技術だけではどうにもならない側面があると思い知らされると思います。

ほとんどのばあい、後付けではどうにもなりませんわな。