(toppers-users 3820) Re: 2つの優先度の有効な利用方法は？(長文 改造案)

[高橋和浩@nifty]

こいさんさん
こんにちは、高橋です。

> 私も高橋さんと同様にSSPで採用された起動優先度、実行優先度が作り出す、従来とは異なるアルゴリズムの優勢を認識できずにいます。
>これで不味い訳ではないよね、のレベルから、なるほどね、に移れずにいます。

処理方式は理解しているつもりではいますよ。　ただ設計上は使えるケースが思いつかないということだけです。
というより無いと思っています。
(toppers-users 3811)の優先度がイコールでもOKな点だけ以外は全部あっていると思いますよ。

> 制約タスクの概念は、タスクにモードをもって、モードによって定められた機能をタスク内で切り替える事で実現するより、
>別なタスクだといってしまう方が解りやすさの点で優れているでしょうし、スタックサイズ削減の効果は大きいと思います。

このスレッドは制約タスクのことを議論しているのではなく、SSPの2つの優先度を持ってスタックを節約する機能についてのみ
取り上げています。
ある意味、2つのタスク優先度を使うのはまずいことのほうが多いと思っています。
今ドキュメントが未整備であることや、開発者からの明確な利用要領が提示されない（2日ぐらいかかる、というか回答義務は無い）
状況ですので、優先度を入れ子にしてスタック共有する使い方をさけて検証されたほうがいいと思います。

> もう少しすっきりして締めたい気はしています。
諦める必要は無いと思います。DEF_EPRIを使わなければ問題ないと思います。


On Mon, 23 Jan 2012 14:42:44 +0900
koizumi yoshiyuki <koizumiyoshiyuki ＠ gmail.com> wrote:

>  高橋さま
> 
> こいさんです。
> 
> 私も文章だけでの議論は苦手です。色々書き込まれたことから、ASPとSSPでディパッチのアルゴリズムが異なることが理解できたところです。
> 
> 私も高橋さんと同様にSSPで採用された起動優先度、実行優先度が作り出す、従来とは異なるアルゴリズムの優勢を認識できずにいます。これで不味い訳ではないよね、のレベルから、なるほどね、に移れずにいます。
> 制約タスクの概念は、タスクにモードをもって、モードによって定められた機能をタスク内で切り替える事で実現するより、別なタスクだといってしまう方が解りやすさの点で優れているでしょうし、スタックサイズ削減の効果は大きいと思います。
> 
> しかしながら、μITRON4.0仕様の「仕様準拠の最低限の条件」の中に新たな起動優先度、実行優先度の概念を持ち込み、その優位性云々となるよくわからずにいます。
> 
> もう少しすっきりして締めたい気はしています。
> 
> 以上
> 
> 2012年1月23日10:54 高橋和浩@nifty <takahashi_kazuhiro ＠ nifty.com>:
> 
> > 長くなってしまいましたが、もう飽きたという人もいるかもしれません。
> > アライブビジョンソフトウエアの高橋です。
> >
> > とりあえず着地点に向けて、結論めいたことを書いてみたいと思っています。
> > 順番に項目を分けて記述します。（長文になります）
> >
> > 1.概要
> > 全体的なこのスレッドに関するコメント、杉本様、斎藤様から聞かれている疑問点
> > および、2名のコメントに対するコメントなどです。あまり重要でないと思っています。
> >
> > 2.2つの優先度が有効な事例
> > 自分が考えた、使えると思える事例
> >
> > 3.使える事例の本当の理由（意味がない）
> >
> > 4.タスクabcは実行時優先度が同一でなくても、同じケースがある。
> >
> > 5.先取り方式の提案
> >
> >
> > -----------------------------------
> > 1.概要
> > 1.0.
> > 技術について、できないと結論を出すことは難しく、できるというほうが簡単なはずです。
> > 理由は簡単できる例を一つあげたらできないことは消えてしまうからです。
> > なのでできる例をひとつあげていただければそれをみなさんで参考にできるし、こう使えば
> > いいのかということでこのスレッドは晴れてストップするはずです。
> > ところが、なぜが使い物になるという杉本様斎藤様はその一例を示していただけません。
> > 相当な時間が経過しているにも関わらずです。自分はリアルタイムOSをつかい続けてもう30年になりますが
> > その自分が使えないものがみなさんで使えるのか本当に疑問です。
> > 理由を考えました。
> > 1)2名の方がこのようなネットでのコミュニケーションに慣れていないため最適な回答ができない。
> > 2)わかっているものの例示できることが思いつかないので、反対意見の粗探しとあくまで
> > 一般論だけで、時間をおくことで議論を収束を待っている。
> >
> > たぶん1)であると信じていますので、以下、建設的なコメントを書いていきます。
> >
> > 1.1.
> > 例で優先度の設定の大小を間違えていたのでわかりやすくするために以下に訂正します。
> > タスク1〜4 は、起動時実行時ともに1,2,3,4 (訂正無）
> > タスクa,b,c は起動時16,14,12 実行時 8 (訂正）
> > とします。
> >
> >
> > 1.2.
> > >私の理解では実行時優先度の目的はあくまでも
> > >省メモリと排他制御であり，その目的に対しては
> > >依然として有効な手段だと思っています．
> > だから、その有効な手段が使える一例をあげてみてくださいと言っているのです。
> > 自分では思いつきません。後述の（2.2つの優先度が有効な事例）であげていますが
> > 結論的には意味のないケースです。
> >
> > 1.3.
> > >優先度の低いタスクがいくつかあり，それらに厳密な優先度ベースの
> > >制御が求められないこともあると思います．それぞれの周期が長く
> > >起動時優先度が異なるために起動周期に多少のジッタがあっても
> > >問題ないようなケースです．
> >
> > 結論を先に先に申し上げますと、そんなタスクは1つで十分で複数にする必要性が
> > 無いです。わざわざ複数タスクになぜか人的リソースの理由等で分ける場合ぐらい
> > しか利用理由がありません。 この例を後述(3.使える事例の本当の理由)で説明します。
> >
> > 1.4.
> > >ちなみに高橋様の挙げられた例をそれなりに処理できるようにすると，
> > >レディキューを必要とすることになり，ROM及びRAMに小さくない影響が出そうです．
> > たぶん先にレディになったタスクを起動する方式だと思います。
> > その実装があればそれは賛成です。これで重くなってしまうと元も子もありませんが
> > (5.先取り方式の提案）にアイデアを記載します。
> >
> >
> > 1.5.
> > >実行時優先度を同じ値に設定したとしても
> > >起動優先度が異なるということは実行の優先順位が
> > >異なるということであり，同一の優先度ではないですね．
> > >
> > >複数タスクを同一優先度として使うことを目的として
> > >実行時優先度を合わせるのは，本来の目的にはない事項と
> > >思います．
> > >(負荷が低い場合にはそこそこ動くと思いますが)
> > 実行時優先度を合わせたのは例示として考えやすいらそれにしただけです。
> > あくまでスタック共有できるケースならなんでもいいのですが、使える例に近いもの
> > を考える場合に実行時優先度が同じのほうがわかりやすいからです。
> > （4.タスクabcは実行時優先度が同一でなくても、同じケースがある。）
> > にそれを説明します。
> >
> > ---------------------------------------
> > 2.2つの優先度が有効な事例
> > 2.1.例その1
> > 薬液をパルス数で制御するポンプコントローラの制御タスクの場合になんとか使えそうです。
> > あくまでSIOでコントローラにコマンドを与えて、パルスの加速度と速度を与えます。いわゆる台形駆動で
> > 面積が薬液の量になります。ただし、ポンプからノズルまでの圧の変化なの配管長が等しくないため
> > フィードバックしないといけなくなっています。ノズルの先にビジョンセンサーを取り付け、ビジョンセンサー
> > で薬液が出た瞬間から台形の下りの位置を特定する仕組みです。
> > 薬液が3種類あってそれぞれ配管もSIOも独立しています。いまのところその薬液は同時動作しないため、
> > ノズルが塗布する位置に移動してからの制御でノズルは交代でしか使えないです。
> > この場合にタスクa,b,cは同時に呼び出されないため全く問題無く動きます。
> >
> > 2.2,例その2
> > タスクabcを割り込み駆動ではなく、一定周期で起動するものとする。
> > もうひとつの方法は、どうせfifoで処理があとからやればいいのであれば、一つ処理が終わったら
> > fifo待ちがあってもタスクを終了する。タスク起動は周期ハンドラで周期的にタスク状態を見ながら
> > まんべんなく起動する。
> >
> > ---------------------------------------------
> > 3.使える事例の本当の理由（意味がない）
> > お分かりかと思いますが、上記2の例では3つのタスクにする必要がありません。
> > タスク一個で、それぞれの役割のメイン関数を順番にコールするタスクで済むはずです。
> > タスクにする意味がありません。
> > ただ、管理上 タスクaは担当者aが作るというような役割分担や、異常時のタスクがa,b,cの
> > どこで起こっているかが多少わかりやすくなるケースがあるぐらいだと思います。
> > なので、いかにも省スタックできるというのは実態的には使えないようなタスクを増やすに
> > すぎないと考えています。
> > ------------------------------------------------
> > 4.タスクabcは実行時優先度が同一でなくても、同じケースがある。
> >
> > それでは タスクa,b,c の実行時優先度9,8,6のケースでは
> > なにか違いがありますか？ 全く同じ挙動のはずです。
> > 実行時優先度の大小は全く関係なくなります。これは個人の感覚かもしれませんが
> > 美しくないですね。 さらに、タスクd が追加されて、起動時優先度7,実行時優先度5
> > にしてみるとどうでしょうか、abと、cdがスタック共有されるが、
> > cが動いている場合は、abdプリエンプトできない。dが動くとabcプリエンプトできない
> > aが動くとbcがプリエンプトできない。
> > 非常に難しいですね。これが使いこなせる人はとても頭のいい人のように思います。
> > ----------------------------------------------
> > 5.先取り方式の提案
> > スタック共有のためには優先度が挟まったような関係のタスクがそれなり、その場合の
> > とらえ方は優先度がどっちが上かというよりどれだけ動くか状況によります。
> > 考え方としてくじ引きのようなもので起動時優先度はくじ引きを引く順番が違うという
> > ものに近いでしょうか？ ただ、先にもあったように先取り優先なら比較的使えるケースが
> > 出てくると思います。
> >
> > レディーQを持つのと対して変わらない提案かもしれませんが、起動時タスク優先度の
> > ビットマップからどの起動時タスクを選ぶことになっていますが、
> > 起動時優先度の16バイト長の変換テーブルを一つ用意して、起動時優先度の切り替えを可能
> > にすることができると思います。初期化時は、1-16の値が入っていて、タスクが起動された
> > ときに、スタック共有されたタスク間で自分だけがレディになった場合に変換テーブルを
> > 入れ替えます。
> > そうすれば、起動時優先度の高いものばかり起動されることの回避ができると思います。
> >
> > --------------------------------------------------
> >
> > 以上です。 長くなりましたが、さらに話が拡散しそうなら、サブジェクトを項目にかえられる
> > といいかと思います。
> >
> > ---
> > アライブビジョンソフトウエア株式会社
> > 高橋和浩
> > 673-0005兵庫県明石市小久保2-2-7幹線ビル4F
> > Email:takahashi_kazuhiro ＠ nifty.com
> > http://homepage3.nifty.com/ALVS/
> >