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

[Naoki Saito]

高橋さま

斉藤です．
いろいろと貴重なご意見ありがとうございます．
適切なご回答ができておらず申し訳ありません．

> 2)わかっているものの例示できることが思いつかないので、反対意見の粗探し
とあくまで
> 一般論だけで、時間をおくことで議論を収束を待っている。

はい，仰る通りです（とうとうバレてしまいました:-P）

> 1.2.
>> 私の理解では実行時優先度の目的はあくまでも
>> 省メモリと排他制御であり，その目的に対しては
>> 依然として有効な手段だと思っています．
> だから、その有効な手段が使える一例をあげてみてくださいと言っているのです。
> 自分では思いつきません。後述の（2.2つの優先度が有効な事例）であげてい
ますが
> 結論的には意味のないケースです。

排他制御の一例としては，
ログ出力機能をタスクとして実現する場合を考えていました．
複数タスクがログ出力を行い，ログ出力タスクが一定周期で
それを回収・出力する．

優先度が低いとログタスクが始まらなくなる可能性があります．
割込みハンドラでもよいですが，同期手段はCPUロックか
割込み禁止となります．
タスクの場合，ディスパッチ禁止で排他制御してもよいです．
ただし全てのタスクが影響を受けます．

という時に，実行時優先度を使えば
ある特定範囲以下の優先度のみにブロック範囲をおさえ込む
ことが出来ます．
もちろん単純にライブラリ関数として，タスク実行時に処理してしまう，
という方法も考えられます(sample1 はこちらですね)ので，
絶対に実行時優先度でなければならない話ではないです．

> 4.タスクabcは実行時優先度が同一でなくても、同じケースがある。
>
> それでは　タスクa,b,c の実行時優先度9,8,6のケースでは
> なにか違いがありますか？　全く同じ挙動のはずです。
> 実行時優先度の大小は全く関係なくなります。これは個人の感覚かもしれませんが
> 美しくないですね。　さらに、タスクd が追加されて、起動時優先度7,実行時
優先度5
> にしてみるとどうでしょうか、abと、cdがスタック共有されるが、
> cが動いている場合は、abdプリエンプトできない。dが動くとabcプリエンプト
できない
> aが動くとbcがプリエンプトできない。
> 非常に難しいですね。これが使いこなせる人はとても頭のいい人のように思い
ます。

はい．仰る例はとても難しいですね．
（あえて難しくなさっているというのもあると思いますけれど）
私もシンプルなケースでは理解できますが，
複雑になりそうな時どのように折り合いをつけるかという点について，
まだ答えを持っておりません．これからの課題です．

お答えになってますでしょうか．
以上，よろしくお願いします．

(12/01/23 10:54), 高橋和浩@nifty wrote:
> 長くなってしまいましたが、もう飽きたという人もいるかもしれません。
> アライブビジョンソフトウエアの高橋です。
> 
> とりあえず着地点に向けて、結論めいたことを書いてみたいと思っています。
> 順番に項目を分けて記述します。（長文になります）
> 
> 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/