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

[高橋和浩@nifty]

杉本様　MLの皆様　おはようございます。
アライブビジョンソフトウエアの高橋です。

> 美しい美しくないは主観も入るので立ち入らないことにしますが、
たぶんやんわり、表現しているので「美しい」ということを書いていますが、
文脈から、「使い物にならない」と言い換えれば立ち入れますか？

サブジェクトを変えさせていただいています。2つの優先度が有用に使えるケースが
無いように思うのです。

> > だいたい、過負荷のタスクが複数あることが問題ですが、普通の設計なら
> > a,b,c優先度つけて、bやcが走りきらないことをあきらめるという設計になると思います。
> 
> リアルタイム性を優先にするならば（そういったケースが多いように思いますが）、
> そういう設計になるのはある程度許容せざるを得ないかと考えていますが、
> いかがでしょうか？

そういう設計とは、優先度を分ける設計のことと理解したうえで、これが多いということを
おっしゃっていますが、それでは少ない場合でもそうでない設計がある　ということですね。
自分は、2つの優先度を使ったケースではその少ないケースそのものが無いと思っています。ですので使い物に
ならないのではないかと思っています。

あくまで2つの優先度によってプリエンプトをしないタスクが複数ある場合、つまりスタックの
省メモリが有効になるケースではその複数のタスクがどれだけ動くか予測不能であると思えるので
予測不能な上で使えるリアルタイムシステムは想像できないと思っています。

それから議論は具体的に例示をしてダメなケースを示していますが、自分はこれはレアケースではなく
すべてのケースで起こる問題かと思っています。　なので反対意見は一般論ではなく、
OKなケースを例示すると理解しやすく、議論にも入ってこれる人が増えると思います。

>順番で動いてもよいものにしか適用できないということになります。
># 諦め口調ですが、その理由は後述します
後述がどの部分かがわかりませんでしたが、その順番に動いてよいケースというものはどういうものが
あるのかそれが自分には思い浮かびません。

さらに危険性について考えていますが、ミドルウエアやドライバ層を別ファイルでコンフュギュレーションファイルに
して実装することが可能かと思いますが、この場合にコンフュギュレーションファイルをインクルードすることや
そのコンフュギュレーションファイルの作成者の担当が違う場合などがあり、たまたま2つの優先度がテレコになるケース
が発生すると思います。そうすると単体では動作するのに組み合わせると動作しない場合が起こります。
普通に考えるとミドルやドライバ層はSSPの守備範囲外なので、そういう設計をしなければよいと思います。
ただそのことをユーザーに周知するか、機能的にできなくするかの対応が必要になると思います


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

SSPそのもののターゲットはよく理解しているつもりですが、今議論しているのは2つの優先度が
問題となるメモリの問題に対する多少の解決手段にならないのではないかと思うことです。


最後に基本的な質問ですが
> この点ですが、実行時優先度は初期優先度（CRE_TSKで指定する優先度）より
> 高くなくてはならない仕様にしています。
> （議論に際しては特に影響を与えないと思いますが）
等しいものはダメということですね。　起動時優先度は2-16 実行時優先度は1-15
ということなんでしょうか？


よろしくお願いします。


On Fri, 20 Jan 2012 00:46:21 +0900
杉本明加 <asuka.choronos ＠ gmail.com> wrote:

> 高橋様、みなさま
> 
> 杉本です。
> 
> 議論に完全についていっていけているわけではなく、横槍になってしまいますが、、、
> 
> > 実際に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の負荷のバランスがとる必要があると思います。
> > リアルタイムシステムにおいて負荷は変動するので、安易に利用すると思わぬ
> > 不具合になると思います。
> >
> > 思い違いをしていれば、ご指摘いただければ幸いです。
> >
> >