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

[高橋和浩@nifty]

杉本様　みなさま　おはようございます。　アライブビジョンソフトウエアの高橋です。

On Sat, 4 Feb 2012 22:16:32 +0900
杉本明加 <asuka.choronos ＠ gmail.com> wrote:

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

ASPなどは、優先度ごとにレディキューを持つという認識で書いています。
SSPは起動時優先度ごとにレディーキューを持つということになるのか？　と聞いているのですが、
優先度の記載については注意を払って書いているのですが、どうも誤解されているようです。
あくまでも起動時優先度ごとにレディキューなんだということならば、上記タスク2は、プリエンプトされても
起動時優先度13にキューを並べるということになると思いますが、ちゃんと動くとは思えません。

これも一つに弊害です。わかりにくいという点は開発者ですら、幾度となく認識を間違えるようなことですよね。
そういう意味でもこのような優先度が2つあるというのはやめるべきだと思っています。


> ちなみに，上記のような設定は個人的には不自然な感じがします．
> 排他をしたいのであれば実行時優先度を同一にするだけでよいので，
> 設定に制限を加える必要性は感じます．
> 
> >> > A2.ディスパッチ禁止との比較
> >> >> >> DEF_EPRI自体は排他としての用途があり、SSPではタスク間同期機能がなく
> >> >> >> 排他手段が限られるので廃止はしなくてよいかと思っています。
> >> >> >>
> >> >> >
> >> >> > そこは、自分は考えが至らなかった部分かと気づきました。
> >> >> > ただ、ディスパッチ禁止等で対応可能だと思うので絶対ではないように
> >> >> > 思っています。
> >> >>
> >> >> ディスパッチ禁止だと全てのタスクに影響が及ぶのに対して、部分的な
> >> >> 排他ができるのがDEF_EPRIですので、使い分けになるのではないかと
> >> >> 考えていますがいかがでしょうか。
> >> >
> >> > 確かに、DEF_EPRIの方がディスパッチ禁止よりも有効な方法だと思います。
> >> > なので絶対ではないという書き方をしました。
> >> > ただ、DEF_EPRIがあることによるデメリットのほうが大きい場合が
> >> > あるのでそうであれば無くてもよいのではないかと思っています。
> >>
> >> デメリットについてのお考えがあればお聞かせください。
> >> A1とも関係するでしょうか？
> >
> 
> > 再度よく考えていますが、DEF_EPRIによる排他とは、あるタスクが実行中に
> > もう一方のタスクが動かないということで、あるタスクの実行時優先度が
> > もう一方の起動時優先度と同じかそれ以下にすることですよね。
> > それ以外もあれば、指摘してください。
> 
> 排他の考え方はおっしゃるとおりですが，起動時優先度が低い側の
> タスクの実行時優先度を，起動時優先度が高い側のタスクの実行時
> 優先度(実行時優先度を設定しない場合は起動時優先度と)を同じか
> それ以上にすることで排他します．

すいません。上記のうち以下を再度引用しますので、詳しく説明いただけますか？
--------------------------------------------------------------
> 排他の考え方はおっしゃるとおりですが，起動時優先度が低い側の
> タスクの実行時優先度を，起動時優先度が高い側のタスクの実行時
> 優先度(実行時優先度を設定しない場合は起動時優先度と)を同じか
> それ以上にすることで排他します．
--------------------------------------------------------------
ひとつには、誤字だと思いますが、どっちを同じかそれ以上か書いていません。

2つの優先度を使うから従来の一つの優先度を使う場合と比べて有効に働くケース
を書いていただけたらよいかと思います。

回答途中なもので、推測して考えていますが、上記の場合は入れ子の例のことを言っている
ように思います。入れ子の場合は、排他以前に問題があるので使い物にならない
利用方法なので意味がないように思います。


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

これについては、(toppers-users 3882) のレスにわかりやすく書きます。

> 以上，よろしくお願いします．
---
アライブビジョンソフトウエア株式会社
高橋和浩
673-0005兵庫県明石市小久保2-2-7幹線ビル4F
Email:takahashi_kazuhiro ＠ nifty.com
http://homepage3.nifty.com/ALVS/