10年前のミドルウエア

一昨日、確認したところ、一応動作していた。
しかし、Priority inversionで、出力タイミングに遅延が見えた。
致命的と言えるほどの遅延ではないので、そのままにする。
おそらく、12年前の実装の時点でそうだったのだろう。その時も同じ理由で放置した。

本当にPriority Inversionが原因なのかを一応色々工夫しながら確認した。
間違いないだろう。

製品に使っている組み込みOSはITRON準拠のリアルタイムOSと言っているが、実際には割り込みの扱いがひどく(割り込みマスクレベルがある機械でも、割り込みハンドラに入る際に、マスクレベルを最高にするため、割り込みの優先度がほぼ無意味になる)、高優先度の割り込みのリアルタイム性が著しく低い。
その他のミドルウエアとセットで使用するために、そのOSが選択されたが、12年前にまともに動作させるためにかなりのbugを自分たちで修正することになった。
10年以上前のものなので、その頃は品質の悪いミドルウエアも多かった(良いものが無かったわけではない)。結果的に、開発期間が半年ほど延びてしまった。
お客さんを助けるための開発だったのに、迷惑もかけた。
非常に辛い開発だった。その頃に「無理はいけない」、「ミドルウエアを使った開発は、そのミドルウエアを自分で作れるぐらいの技術力が必要である」という考えを持つようになった。

あまりにも不具合が多かったので、ミドルウエアの事をほとんど信用していない。
Priority Inversion(優先度逆転)が原因なら、Priority Inheritance(優先度継承)で対処すればよいということは、ITRON使いなら誰でもわかるだろう。
12年前なぜそうしなかったのか？おそらくミドルウエアのその部分にもbugがあった(ある)のだろう。
これについても確認した。
ソースコードをみるとやはりbugが発見された。致命的な不具合(システムの停止等)ではないが、優先度が継承されない可能性がある。
使っても使わなくても、最悪値は変わらない。そのため、使ってもいいのだが、ソースコード上で優先度継承をしているように見えて、実際にはそうではないというネジれた状態になる。ならばむしろ、堂々とソースコード上で「Priority inheritanceしていません」と見える方がいいだろう。
多分、12年前にも同じ結論に至ったのだろう。すっかり忘れているが。

実際に問題のSemaphoreのPriority Inheritance をEnableにして実験してみたが、発生頻度はやや減るものの、最悪値はほとんど変化なし。
RTOSに手を入れるのは、リスクがある。
はっきりと原因が特定されているが、とにかく元々Bugの多いものだ。
12年前の製品なので、今回もまた,そのままにすることにした。
「何とかしてくれ」と言われたらやることにする。

最近ではどのミドルウエアも枯れてきており、安定している。
さらに、チューニングもされている。
その製品の後継リニューアル版を作るときには、最新のミドルウエアにするだけで、限界性能が2倍ぐらい良くなるだろう。
ついでに12年動作実績のあるH/Wがある。これで最新ミドルウエアを評価すれば、問題の切り分け(H/W,ミドルウエア,ソフト)もかなり楽になる。