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

[koizumi yoshiyuki]

 杉本さん

こいさんです。

かなかなこの議論についていけず苦しんでいます。私なりに議論を整理して見ました。

SSPでは優先度の指定が2種に増えた、起動優先度と実行優先度です。（議論の中で単に優先度と書かれたとき、どちらの優先度か解りにくいことがあります）

タスクを生成するときの指定する優先度はSSPでは起動優先度として割り当てられる。同一起動優先度を持つタスクはCFGでエラーになります。実行優先度の指定は追加されたAPIで指定するが、APIによる指定がない場合（ディフォルト）は実行優先度は起動優先度と同じ優先度を割り付ける。APIで指定する実行優先度は起動優先度より高くなければならい（CFGでチェック）。

複数の同一起動優先タスクが実行待ちで、タスク切り替えが発生した場合、SP/JSPでは同一優先度タスクはキューを使ってFIFOによるラウンドロビン方式で優先度が定まるのでタスクは必ず起動されるが、SSPでは起動優先度でにより起動される（起動優先度による、最優先方式）。

SSPでは最優先方式に変更になったので、3つの以上の同一実行優先度のタスクが高付加で起動要求が発生すると起動されないタスクが発生する。（この話は一般論ですね）

との理解でよいでしょうか。

以上



2012年1月22日1:39 杉本明加 <asuka.choronos ＠ gmail.com>:

> 高橋様
>
> 杉本です．
> # 回答を書いている間に斎藤さんからも返事がありましたが
> # 別の回答としてお読みください
>
> 確かに仰られているシチュエーションにおいては
> タスクに十分にCPU時間が割当てられないとは思います．
>
> 使える例とは何かということですが，比較的時間制約の
> 少ない場合になるかと思います．
>
> 優先度の低いタスクがいくつかあり，それらに厳密な優先度ベースの
> 制御が求められないこともあると思います．それぞれの周期が長く
> 起動時優先度が異なるために起動周期に多少のジッタがあっても
> 問題ないようなケースです．
>
> そういった状況でも，SSPでは同一優先度に一つのタスクしか
> 割当てられないので，システム全体の合計スタックサイズは
> 全てのタスクが自タスクより起動時優先度が高いタスクにプリエンプトされる
> 前提で算出することになります．
>
> そのような場合に実行時優先度を同一に設定することでスタックサイズを
> 少なくできることができるかと思います．
>
>
> ちなみに高橋様の挙げられた例をそれなりに処理できるようにすると，
> レディキューを必要とすることになり，ROM及びRAMに小さくない影響が出そうです．
>
> 最小セットがどの程度の機能であるべきかは議論の余地がまだまだあります．
> どこまでを標準的に提供し，どこからを拡張パッケージとするとよいのか
> ご意見いただけると幸いです．
>
>
> 以上，よろしくお願いします．
>
> 2012年1月21日19:59 Kazuhiro. Takahashi <takahashi_kazuhiro ＠ nifty.com>:
> > 斎藤さま
> >
> > 旅先のため十分お返事できないかもしれませんが
> > まず、私の例を誤解されているようです。sspがこの機能に
> > おいて使い物にならないと思える例です。
> >
> > 一方使える例を示していただけたら納得できます。
> >
> > 誤解のひとつはタスクabc は起動時優先度以外は同じものです。
> > 繰り返し書きますが実行時優先度は同じです。
> > Cpu ロック状態でフラグとfifo を使いタスク起動するものです。
> > タスクabc だけならcpu がかなりの稼働率で動作するものの例です。
> >
> > 割り込みハンドラからの要求を処理するタスクです。
> >
> > 通常のitronなら、上位タスクにより一時的に過負荷になった場合、同一優先度を前提なので、
> > 最初にレディになったタスクのfifo が処理されてから早いものがちでスケジュールされます。
> > ところがssp の場合、一時的にに上位タスクが過負荷の場合同様に最初に動いていたタスクがfifo
> > がなくなるまで処理し、その後同時にレディなら起動時優先度の高いものばかり
> > 実行されます。通常のitron なら同一優先度でもタスクcでもそれなりに仕事ができていますが
> > ssp では使えないと思います。つまりタスクcはほとんど動かないですね。
> >
> >
> 何度も書いていますが、同一実行時優先度タスクが複数あっても相当の実行時時間がわりあてられないケースが存在します。そういう設計はしないのなら同一優先度が使える設計が存在
> > するのかが知りたいです。私のなかでは存在しない。だとすれば使えない機能です。
> > 具体的にはタスクc も相当な時間cpu の時間を割り当てたくとも割り当てられないと
> > 思うからです。それなら結局使えないと思います。
> > --
> > Sent from my Android phone with K-9. Please excuse my brevity.
> >
> > Naoki Saito <nsaito.nmiri ＠ gmail.com> wrote:
> >>
> >> 高橋さん
> >>
> >> 斉藤です．
> >>
> >> > サブジェクトを変えさせていただいています。2つの優先度が有用に使えるケースが
> >> > 無いように思うのです。
> >>
> >> あくまでも「リアルタイム性を最優先する」場合の話と理解して
> >> よろしいでしょうか．
> >>
> >> > あくまで2つの優先度によってプリエンプトをしないタスクが複数ある場合、つまりスタックの
> >> > 省メモリが有効になるケースではその複数のタスクがどれだけ動くか予測不能であると思えるので
> >> > 予測不能な上で使えるリアルタイムシステムは想像できないと思っています。
> >>
> >> 実行時優先度の設定によりお互いにプリエンプトしない関係の
> >> タスクが複数あるようにした場合は，最悪の応答時間に
> >> 影響が出ます．
> >> つまりメモリとリアルタイム性との間にトレードオフの関係が
> >> 生じます．
> >> それが使い物になるかどうかは要件次第で，満たさなくなる
> >> 可能性が上がるだろうとは思います．
> >>
> >> 予測不能になる，とまで酷い状況になるのかなとも思いましたが
> >> 先の例(起動時優先度が高い順にa,b,cの3つのタスクが存在するケース)で，
> >> 前提としてタスクa が実行状態，タスクcが実行可能状態とします．
> >> そして，
> >> タスクa実行中にタスクbの起動要求発生
> >> タスクa実行終了→タスクb実行開始
> >> タスクb実行中にタスクaの起動要求発生
> >> タスクb実行終了→タスクa実行開始
> >> ・・・
> >> というようなことがあれば，タスクcの実行がいくらでも遅くなる
> >> ケースは考えることができます．
> >> しかしこの場合に限っていえばSSPに限った話ではないように思います．
> >>
> >> ミドルウェアを組み合わせた場合の問題なども仰るように
> >> 考慮しなければならない課題と思います．
> >> ただし，SSPだけの問題ではないかな，とも思いました．
> >>
> >> 以上，よろしくお願いします．
> >>
> >> 2012年1月20日9:15 高橋和浩@nifty <takahashi_kazuhiro ＠ nifty.com>:
> >> > 杉本様 MLの皆様 おはようございます。
> >> > アライブビジョンソフトウエアの高橋です。
> >> >
> >> >> 美しい美しくないは主観も入るので立ち入らないことにしますが、
> >> > たぶんやんわり、表現しているので「美しい」ということを書いていますが、!
> >>
> >> > 文脈から、「使い物にならない」と言い換えれば立ち入れますか？
> >> >
> >> > サブジェクトを変えさせていただいています。2つの優先度が有用に使えるケースが
> >> > 無いように思うのです。
> >> >
> >> >> > だいたい、過負荷のタスクが複数あることが問題ですが、普通の設計なら
> >> >> > a,b,c優先度つけて、bやcが走りきらないことをあきらめるという設計になると思います。
> >> >>
> >> >> リアルタイム性を優先にするならば（そういったケースが多いように思いますが）、
> >> >> そういう設計になるのはある程度許容せざるを得ないかと考えていますが、
> >> >> いかがでしょうか？
> >> >
> >> > そういう設計とは、優先度を分ける設計のことと理解したうえで、これが多いということを>
> >> おっしゃっていますが、それでは少ない場合でもそうでない設計がある ということですね。
> >> > 自分は、2つの優先度を使ったケースではその少ないケースそのものが無いと思っています。ですので使い物に
> >> > ならないのではないかと思っています。
> >> >
> >> > あくまで2つの優先度によってプリエンプトをしないタスクが複数ある場合、つまりスタックの
> >> > 省メモリが有効になるケースではその複数のタスクがどれだけ動くか予測不能であると思えるので
> >> > 予測不能な上で使えるリアルタイムシステムは想像できないと思っています。
> >> >
> >> > それから議論は具体的に例示をしてダメなケースを示していますが、自分はこれはレアケースではなく
> >> >
> >> すべてのケースで起こる問題かと思っています。 なので反対意見は一般論ではなく、
> >> > OKなケースを例示すると理解しやすく、議論にも入ってこれる人が増えると思います。
> >> >
> >> >>順番で動いてもよいものにしか適用できないということになります。
> >> >># 諦め口調ですが、その理由は後述します
> >> > 後述がどの部分かがわかりませんでしたが、その順番に動いてよいケースというものはどういうものが
> >> > あるのかそれが自分には思い浮かびません。
> >> >
> >> > さらに危険性について考えていますが、ミドルウエアやドライバ層を別ファイルでコンフュギュレーションファイルに
> >> >
> >> して実装することが可能かと思いますが、この場合にコンフュギュレーションファイルをインクルードすることや
> >> > そのコンフュギュレーションファイルの作成者の担当が違う場合などがあり、たまたま2つの優先度がテレコになるケース
> >> > が発生すると思います。そうすると単体では動作するのに組み合わせると動作しない場合が起こります。
> >> > 普通に考えるとミドルやドライバ層はSSPの守備範囲外なので、そういう設計をしなければよいと思います。
> >> > ただそのことをユーザーに周知するか、機能的にできなくするかの対応が必要になると思います
> >> >
> >> >
> >> >> 少し議論の前提に語弊が生じているような気がしていまして、SSPは
> >> >> 省メモリを支援するためのOSというわけではありませんã!
> >>  �‚
> >> >> もちろん小規模なシステムを適用対象にしていますので、省メモリに
> >> >> 配慮してタスク共有の仕組みや機能の絞り込みをしておりますが、
> >> >> 最も優先しているのはリアルタイム性の確保です。その上でOS適用時に
> >> >> 問題となるメモリの問題に対する多少の解決手段を提供したいという認識です。
> >> >
> >> > SSPそのもののターゲットはよく理解しているつもりですが、今議論しているのは2つの優先度が
> >> > 問題となるメモリの問題に対する多少の解決手段にならないのではないかと思うことです。
> >> >
> >> >
> >> > 最後に基本的な質問ですが
> >> >> この点ですが、実行時優先度は初期優先度（CRE_TSKで指定する優先度）より
> >> >> 高くなくてはならない仕様にしています。
> >> >&!
> >>  gt;
> >> （議論に際しては特に影響を与えないと思いますが）
> >> > 等しいものはダメということですね。 起動時優先度は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の負荷のバランスがとる必要があると思います。
> >> >> > リアルタイムシステムにおいて負荷は変動するので、安易に利用すると思わぬ
> >> >> > 不具合になると思います。
> >> >> >
> >> >> > 思い違いをしていれば、ご指摘いただければ幸いですã!
> >>  �‚
> >> >> >
> >> >> >
>
-------------- next part --------------
HTML$B$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B...
URL: <http://www.toppers.jp/pipermail/users/attachments/20120122/86e098fb/attachment.html>