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

[koizumi yoshiyuki]

高橋さんへ

小生、実は高橋さんの議論についていけないでいます。(少々頭が固くなったと、苦笑中)
残念ながら、具体的にどんなケースがあるのかを、あげることは出来ません。が、
今回の話は単純にRTOSの機能として考え、起動優先度でタスクが起動し、直後(同時に)にchg_priで実行優先度の値に優先度が変化したしたものと考えています。
こんな使い方はアプリではしないといわれると反論は有りません。

議論についていけない一つに、SSPで起動優先度と実行優先度の2つを持っている場合、同一優先度は何を指すのか理解できずに居ります。小生の独自の考え方なのですが、_kernel_tinib_epriorityの隣同士が同じ値の場合、同一優先度と考えるのが良さそうとだと思っています。（SSPのディパッチアルゴリズムの実装のシンプルさには驚いています）

ポイントがあっているとは思っていません、基本的に、この議論についていけない者の発言である事をご理解願います。

以上
2012年2月6日10:54 高橋和浩@nifty <takahashi_kazuhiro ＠ nifty.com>:

> こいさんさん おはようございます。
>
> 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/
>
-------------- next part --------------
HTMLの添付ファイルを保管しました...
URL: <http://www.toppers.jp/pipermail/users/attachments/20120206/700ff97c/attachment.html>