(toppers-users 3797) Re: ２つの優先度の最適な利用方法は？

[杉本明加]

高橋様、みなさま

杉本です。

議論に完全についていっていけているわけではなく、横槍になってしまいますが、、、

> 実際にSSPの省メモリ（省スタック）でタスク設計を行う場合に
> 従来のITRONの考え方での設計だけでは、不十分で新しい手順が必要になると考えています。

これはその通りだと思います。
省メモリを第一にタスク設計を行おうとすると、従来にない設計制約が
生まれることは同意します。

> つまり、起動されるパターンが一定のタスク群の条件によらない場合、たとえば
> 割り込みハンドラからの起動の場合には、どちらのタスクが優先的に動くか不定
> ではないかと思います。　これが何か誤解があれば指摘いただければ
> 幸いですが、そのとおりなら、これを「美しくない」と思うのは同意できます。

美しい美しくないは主観も入るので立ち入らないことにしますが、
逆に言えばどの同一の実行優先度に割り当てられたタスクがどの
順番で動いてもよいものにしか適用できないということになります。
# 諦め口調ですが、その理由は後述します

> 実行時優先度は、最低の16とし、起動時優先度はタスクa,b,cそれぞれ、5,6,7 とします。
> さらに上位のタスクが4つあるものとします。起動時優先度と実行時優先度が同じでそれぞれ1〜4の優先度
> をもちます。

この点ですが、実行時優先度は初期優先度（CRE_TSKで指定する優先度）より
高くなくてはならない仕様にしています。
（議論に際しては特に影響を与えないと思いますが）

> だいたい、過負荷のタスクが複数あることが問題ですが、普通の設計なら
> a,b,c優先度つけて、bやcが走りきらないことをあきらめるという設計になると思います。

リアルタイム性を優先にするならば（そういったケースが多いように思いますが）、
そういう設計になるのはある程度許容せざるを得ないかと考えていますが、
いかがでしょうか？


少し議論の前提に語弊が生じているような気がしていまして、SSPは
省メモリを支援するためのOSというわけではありません。
もちろん小規模なシステムを適用対象にしていますので、省メモリに
配慮してタスク共有の仕組みや機能の絞り込みをしておりますが、
最も優先しているのはリアルタイム性の確保です。その上でOS適用時に
問題となるメモリの問題に対する多少の解決手段を提供したいという認識です。

さらに言えば、SSPカーネルの仕様を決める際、OSが
既に使われている規模のアプリケーションに適用することは考えずに
検討を行いました。ごく簡単なスケジューラを自作していたりもしくは
OSを使用していないような規模のシステムにおいて、優先度ベースの
処理を提供する、ハードウェアの割込みを抽象化するといった本当に
シンプルな利用を想定して開発しています。
# いろいろとアプリケーションを考えていくと結局ASPの仕様になってしまったりします

非常に用途が限られるということは念頭においていて、しかし
それでいてまだOSが適用されていない規模のアプリケーションに
OSがどのように適用できるのかのトライかと思っています。

ですので、SSPカーネル自体はシンプルに多くの場合に
有用な機能だけを標準としてしつつどのようなつくりのアプリケーションなら
適用できるのか、今いろいろ議論いただいている不足がちな機能を
アプリケーション側の工夫で代替できるかといった例、またその境界線は
どこなのかという基準は提供していく必要性は感じています。

非常に未成熟な部分は多く、みなさまからの意見を
踏まえて今後検討していきたいと思います。

直接の回答ではありませんが、参考になれば幸いです。


2012年1月19日23:16 kazuhiro takahashi <takahashi_kazuhiro ＠ nifty.com>:
> こんばんは、アライブビジョンソフトウエアの高橋です。
>
> 厳しい回答がされているようなのですが、「美しい」とか「でたらめ」など
> なかなか伝わりにくい表現をされているようですが、自分はこいさんさんの
> ご意見はなんとなくわかる気がします。
>
> 実際にSSPの省メモリ（省スタック）でタスク設計を行う場合に
> 従来のITRONの考え方での設計だけでは、不十分で新しい手順が必要になると考えています。
>
> 考え方が難しいのは、2つのタスクの2種類の優先度が挟まったような状態
> のときですね。　2パターンあり、含まれるケースと互い違いになるケースかと思います。
> 結局、いずれのパターンも両方の実行時優先度は両方の起動時優先度より優先度が高く
> なります。　つまり、お互いにプリエンプトされないものになります。
> どちらのタスクが実行されるかは、起動時優先度が絶対ではなく、起動の順番と、どこ
> （どのタスク）から起動されるかによって変わると思います。
> つまり、起動されるパターンが一定のタスク群の条件によらない場合、たとえば
> 割り込みハンドラからの起動の場合には、どちらのタスクが優先的に動くか不定
> ではないかと思います。　これが何か誤解があれば指摘いただければ
> 幸いですが、そのとおりなら、これを「美しくない」と思うのは同意できます。
>
> ただこういったテレコの優先度の場合は、プリエンプトされない関係にあるので
> スタックサイズをどちらかの最大値にできるので省メモリには有効になり、
> いつどれだけ動くかについては、同一優先度のものと考えたら考えやすいように
> 思いますが、ただこれには落とし穴があると思います。
>
> 例をあげてみます。
>
> タスクの優先度の低いものの3つのタスクがあり、これは割り込みハンドラ
> からそれぞれ、フラグとFIFOとタスク起動されるタスクa,タスクb,タスクcがあるとします。
> タスクa,b,cの実行時優先度を同一にします。同一にする理由は同一スタックを利用するためです。
> だいたい満遍なく実行される取りこぼししてもいい処理を行うタスクとします。
> （同一実行時優先度以外でもスタック同一化は可能ではありますが、とりあえず例はそうします。）
>
> 実行時優先度は、最低の16とし、起動時優先度はタスクa,b,cそれぞれ、5,6,7 とします。
> さらに上位のタスクが4つあるものとします。起動時優先度と実行時優先度が同じでそれぞれ1〜4の優先度
> をもちます。
>
> タスクa,b,cの負荷は、上位タスクがまったく動かなければ問題ないが、
> 上位タスクが動いた場合は、過負荷になり、FIFOキューがかなり溜まるようなシステム
> となっていたとします。
>
> こういった場合、これが期待通りに動いてくれないと思います。
> FIFOが溜まりだしたら、タスクa,b,cのうちどれかばかり動く可能性があります。
> なにかVisualBasicのDoEventsのような協調的マルチタスクまがい
> の動作になるように思います。
>
> だいたい、過負荷のタスクが複数あることが問題ですが、普通の設計なら
> a,b,c優先度つけて、bやcが走りきらないことをあきらめるという設計になると思います。
> つまり、プリエンプトされる関係にすることになります。
> 最も省メモリにはこのケースは使えないことになります。
>
>
> それでは、SSPの省スタックにするためには同一実行時優先度が使えるケースとはどんな
> ケースがあるのかということを考えると上記のようにCPUの稼働率が高い場合には
> どれだけ動くか予測が難しく利用できないように思います。
> なので、省メモリとCPUの負荷のバランスがとる必要があると思います。
> リアルタイムシステムにおいて負荷は変動するので、安易に利用すると思わぬ
> 不具合になると思います。
>
> 思い違いをしていれば、ご指摘いただければ幸いです。
>
>