(toppers-users 3888) Re: DEF_RPRIを無くすご提案

[内山 敏和]

皆様、初めまして

新潟通信機の内山と申します。


起動時優先度と実行時優先度が設定できれば有り難いと思うケースを考えて見ました。
余談ですが、
私はμITRINはVer2とVer4を良く使ってて、TOPPERSにも興味がありMLを拝見させて頂いております。
普段からメモリリソースに厳しい環境下で開発しているので省メモリなSSPに期待があります。
TOPPERSはド素人なので、突っ込みどころ満載かもしれませんが、こんな風に使えるのかなぁ
と思い、送っております。


・システム条件
 [タスクＡ]
　システム的に最も早急に処理しなければならない処理で、
　他タスクの実行をプリエンプトしてでも実行開始しなければならない。
　１回の起動でのタスク処理時間は短い。

 [タスクＢ]
　アプリケーション的な処理を行うタスク
　１回の起動でのタスク処理時間は長いが、最長でも100ms程度で終了する。
　４タスク中、最も低優先度での実行で構わない。
　タスクＤにプリエンプトされると問題発生する。

 [タスクＣ]
　デバイスドライバを利用するタスク
　１回の起動でのタスク処理時間は中程度で、最長でも十数msで終了する。
　タスクＢより高優先度で処理する必要がある。
　タスクＤにプリエンプトされると問題発生する。

 [タスクＤ]
　表示ハードウェアデバイスドライバのタスク
　タスクＢ及びＣからの要求を受けて処理が開始するが、起動の遅延は数百ミリ秒程度許される。
　ハードウェアデバイスの特性として、一旦アクセスを開始したら完結するまで走りきる必要がある。
　１回の起動でのタスク処理時間は短く、最長でも数msで終了する。
　タスクＢ及びタスクＣにプリエンプトされると問題発生する。
　使用するスタック容量は、タスクＢとタスクＣが使用するスタック容量を足したものより少ない。

 [その他]
　メモリ資源が乏しく、できるだけスタック領域として使用するRAMも最小限にしたい。

・条件に基づくタスクの優先度割当て
 [タスクＡ]
　起動時優先度1
　実行時優先度1

 [タスクＢ]
　起動時優先度4
　実行時優先度4

 [タスクＣ]
　起動時優先度3
　実行時優先度3

 [タスクＤ]
　起動時優先度5
　実行時優先度2

・動作の確認
　タスクＤの起動時優先度は5なので、タスクＡ、Ｂ、Ｃ全て終了するまで起動できない。
　一旦タスクＤが起動し実行開始すると、タスクＢ及びタスクＣは起動できない。
　（タスクＤは、Ｂ及びＣと排他で起動）

タスクで使用する総スタック容量
　タスクＡ使用量＋タスクＢ使用量＋タスクＣ使用量　となる。
　但し、タスクＤ使用量　＜（タスクＢ使用量＋タスクＣ使用量）
　よって、タスクＤ使用量分、スタック容量を節約できる


同一優先度による排他制御では、この様なシステムは難しいと考えます。
優先度を２つ持つことは、システム全体を設計することを複雑にし、
それによるリスクもあると思いますが、
メモリリソースが厳しい環境下では有効だと思います。


また、ML内での話題の流れについて行けない部分もあり、
皆様にとって、邪魔なメールになってしまわないか心配ではありますが、
その節は、ご容赦のほどお願い致します。



>こいさんさん　おはようございます。
>
>On Sun, 5 Feb 2012 12:23:01 +0900
>koizumi yoshiyuki <koizumiyoshiyuki ＠ gmail.com> wrote:
>
>>  こいさんです
>> 
>> 横槍になってしまいますが。
>> 
>> 当初、SSPで採用されたディパッチの仕組と意図がよくわからず、変な質問をしましたが、皆様の議論を読ませていただき、今ではこれも有りだと思うようになりました。
>> SSPはASPとはタスク起動や優先度考え方が異なっていますが、システム規模が考慮されたもので、従来と比べると満足できないこともあるとは思いますが、極めてシンプルな仕組みです。問題点を理解した上でなら、使えるケースは有ると考えています。
>> SSPで採用され、従来とは異なる点の説明を付加して、現在のディスパッチアルゴリズムを存続させて欲しいと思うようになりました。
>> 
>> 一つのディパッチアルゴリズムで全ての組み込みをカバーできると思われません。TOPPERSとしては従来との互換性も必要だと思いますが、現在検討されている方式に加え、両方とも使えるような方向もあるのではないかと思っています。
>> その分、開発側は大変だとは思います。
>> 
>> 以上
>
>
>再度ポイントを以下に引用します。
>------------------------------------------------
>> 使えるケースは有ると考えています。
>------------------------------------------------
>これが、DEF_EPRIを無くそうという議論での話ですので、その上でのコメントを書きます。
>使えるケースが無いのです。　だからその機能は削除すべき　というのが私の主張です。
>
>使えるケースは、あれは例示してくださいと言って全く返答がありません。理由は簡単です無いからです。
>
>杉本様とのやりとりですが、以下のことと同じことです
>DEF_EPRIは、
>> 同一（実行時）優先度以外でプリエンプトできない関係のタスクの設定しかできないからです。
>> ポイントは「しかできない」ことです。
>> 「デメリットですが、同一優先度以外でプリエンプトできない関係のタスクの設定ができてしまうことです」
>> というのは違います。
>> いわゆる「場合がある」とか「可能である」ということではなく「しかできない」ことがポイントです。
>
>
>---
>アライブビジョンソフトウエア株式会社
>高橋和浩
>673-0005兵庫県明石市小久保2-2-7幹線ビル4F
>Email:takahashi_kazuhiro ＠ nifty.com
>http://homepage3.nifty.com/ALVS/
>