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

[杉本明加]

高橋様

杉本です．
返信が遅くなりました．

>> > A1.起動時実行時の優先度が入れ子の場合
>> >
>> > タスク1　起動時優先度14 実行時優先度11
>> > タスク2　起動時優先度13 実行時優先度12
>> > のようにタスク2がタスク1に挟まれています。こういうものを「起動時実行時の優先度が入れ子の場合」
>> > と書いています。これは同一優先度ではありません。さらにプリンプトしない関係にあります。
>> > これをレディキューを持つにしても持たないにしてもどのように処理するかが問題になると
>> > 考えています。
>>
>> 懸念されているのは、上記のような設定ができてしまうことに
>> 問題があるということでしょうか？
>
> そう思います。
> まず、現行のままである場合、つまりレディーキューを持たない場合には
> 負荷が予想できないと考えています。すでに議論つくされている例示出来ない具体例と同じと
> 考えています。
> 一方、レディーキューを導入した場合についてですが、起動時優先度ごとにレディーキューをもつことに
> なるのでしょうか？　ちょっとまだ考えが及びませんが、そうした場合に上記のようにタスク優先度が同じ
> ものが無い場合は全く機能しないのでレディーキューが無い場合と変わらない問題があるように
> 思います。

起動時優先度ごとにレディキューは用意されます．
これはASPなど他のカーネルでも同じです．

ちなみに，上記のような設定は個人的には不自然な感じがします．
排他をしたいのであれば実行時優先度を同一にするだけでよいので，
設定に制限を加える必要性は感じます．

>> > A2.ディスパッチ禁止との比較
>> >> >> DEF_EPRI自体は排他としての用途があり、SSPではタスク間同期機能がなく
>> >> >> 排他手段が限られるので廃止はしなくてよいかと思っています。
>> >> >>
>> >> >
>> >> > そこは、自分は考えが至らなかった部分かと気づきました。
>> >> > ただ、ディスパッチ禁止等で対応可能だと思うので絶対ではないように
>> >> > 思っています。
>> >>
>> >> ディスパッチ禁止だと全てのタスクに影響が及ぶのに対して、部分的な
>> >> 排他ができるのがDEF_EPRIですので、使い分けになるのではないかと
>> >> 考えていますがいかがでしょうか。
>> >
>> > 確かに、DEF_EPRIの方がディスパッチ禁止よりも有効な方法だと思います。
>> > なので絶対ではないという書き方をしました。
>> > ただ、DEF_EPRIがあることによるデメリットのほうが大きい場合が
>> > あるのでそうであれば無くてもよいのではないかと思っています。
>>
>> デメリットについてのお考えがあればお聞かせください。
>> A1とも関係するでしょうか？
>

> 再度よく考えていますが、DEF_EPRIによる排他とは、あるタスクが実行中に
> もう一方のタスクが動かないということで、あるタスクの実行時優先度が
> もう一方の起動時優先度と同じかそれ以下にすることですよね。
> それ以外もあれば、指摘してください。

排他の考え方はおっしゃるとおりですが，起動時優先度が低い側の
タスクの実行時優先度を，起動時優先度が高い側のタスクの実行時
優先度(実行時優先度を設定しない場合は起動時優先度と)を同じか
それ以上にすることで排他します．

排他目的ならそれ以上にする必要はなく，起動時優先度が高いタスクの
優先度（起動時or実行時)と同一にすれば問題ありません．

> であるならば、DEF_EPRIを無くす案の場合の同一（外部表現）起動時優先度のタスクは排他に
> なるし、未満の優先度のタスクも排他になります。DEF_EPRIは排他のために
> 必要無いと思います。
>
> デメリットですが、同一（実行時）優先度以外でプリエンプトできない関係のタスクの設定
> しかできないからです。
> たぶんここを誤解されている人が多いのだと思っています。
> 大事なことなのでもう一度書きますが
> 同一（実行時）優先度以外でプリエンプトできない関係のタスクの設定しかできないからです。
>
> 同一（実行時）優先度以外でプリエンプトできないと負荷が予測できません。
> 同一（実行時）優先度の場合は、レディーキューを持ついるなどの改造をすることで負荷の予測できる
> システムにすることができます。
>
> ポイントは「しかできない」ことです。
> 「デメリットですが、同一優先度以外でプリエンプトできない関係のタスクの設定ができてしまうことです」
> というのは違います。
> いわゆる「場合がある」とか「可能である」ということではなく「しかできない」ことがポイントです。
>
> なので、同一（実行時）優先度のみ狭義の省スタック化されるように内部表現としてユーザーが指定できないように
> するべきだと考えています。
>

この部分がうまく咀嚼できておりませんので，もう少し考えてから
回答します．

以上，よろしくお願いします．