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

[高橋和浩@nifty]

杉本様

高橋です。

> 
> > A1.起動時実行時の優先度が入れ子の場合
> >> 「起動時実行時の優先度が入れ子の場合」というのが分からなかったのですが、
> >> どういったタスク生成のしかたを指すのかご教授いただけますでしょうか？
> >
> > タスク1　起動時優先度14 実行時優先度11
> > タスク2　起動時優先度13 実行時優先度12
> > のようにタスク2がタスク1に挟まれています。こういうものを「起動時実行時の優先度が入れ子の場合」
> > と書いています。これは同一優先度ではありません。さらにプリンプトしない関係にあります。
> > これをレディキューを持つにしても持たないにしてもどのように処理するかが問題になると
> > 考えています。
> 
> 懸念されているのは、上記のような設定ができてしまうことに
> 問題があるということでしょうか？

そう思います。
まず、現行のままである場合、つまりレディーキューを持たない場合には
負荷が予想できないと考えています。すでに議論つくされている例示出来ない具体例と同じと
考えています。
一方、レディーキューを導入した場合についてですが、起動時優先度ごとにレディーキューをもつことに
なるのでしょうか？　ちょっとまだ考えが及びませんが、そうした場合に上記のようにタスク優先度が同じ
ものが無い場合は全く機能しないのでレディーキューが無い場合と変わらない問題があるように
思います。

> 
> あと前提を確認しておきたいのですが、この指定はDEF_EPRIを
> 残すとした場合のことでしょうか？（DEF_EPRIの廃止についても
> 議論していますので、念のため）
起動時実行時優先度の入れ子はDEF_EPRIを使わなければできない設定ですよね。
ですので残す前提の話です。
私のDEF_EPRIを無くす提案は、内部表現の優先度として、入れ子にならないようにコンフュギュレーション
されることを想定しています。


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

再度よく考えていますが、DEF_EPRIによる排他とは、あるタスクが実行中に
もう一方のタスクが動かないということで、あるタスクの実行時優先度が
もう一方の起動時優先度と同じかそれ以下にすることですよね。
それ以外もあれば、指摘してください。
であるならば、DEF_EPRIを無くす案の場合の同一（外部表現）起動時優先度のタスクは排他に
なるし、未満の優先度のタスクも排他になります。DEF_EPRIは排他のために
必要無いと思います。

デメリットですが、同一（実行時）優先度以外でプリエンプトできない関係のタスクの設定
しかできないからです。
たぶんここを誤解されている人が多いのだと思っています。
大事なことなのでもう一度書きますが
同一（実行時）優先度以外でプリエンプトできない関係のタスクの設定しかできないからです。

同一（実行時）優先度以外でプリエンプトできないと負荷が予測できません。
同一（実行時）優先度の場合は、レディーキューを持ついるなどの改造をすることで負荷の予測できる
システムにすることができます。

ポイントは「しかできない」ことです。
「デメリットですが、同一優先度以外でプリエンプトできない関係のタスクの設定ができてしまうことです」
というのは違います。
いわゆる「場合がある」とか「可能である」ということではなく「しかできない」ことがポイントです。

なので、同一（実行時）優先度のみ狭義の省スタック化されるように内部表現としてユーザーが指定できないように
するべきだと考えています。

よろしくお願いします。

---
アライブビジョンソフトウエア株式会社
高橋和浩
673-0005兵庫県明石市小久保2-2-7幹線ビル4F
Email:takahashi_kazuhiro ＠ nifty.com
http://homepage3.nifty.com/ALVS/