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

[koizumi yoshiyuki]

 高橋さま

優先度の変更を可能にする件は、詳細をつめるにはもう少し検討が必要でしょう。ただし、自由に優先度値を変えるのではなく、事前に指定した範囲(静的APIで)と限定することで、スタッサイズも事前に定まる様にします。
又、実行中のタスクの優先度の変更には制限があると思っています。この場合は優先度の変更は処理終了まで遅延させれば処理が容易に成ると思います。タスクの優先度の変更はタスクの処理結果によって必要になると思われるので多少の制限があっても構わないでしょう。(遅延になる場合はAPIを実行したら直に終了する？、タスク起動のキューが必要に成りますかね)

小生の案はSSPには優先度の変更を制限つきでも可変にできたほうが応用範囲が広がるのではないかとの提案で、全てのケースを考え抜いたわけでは有りません。（むちゃくちゃ複雑ではない範囲で実現できるとは思っていますが）


またまた別な話です。
（別なタイトルにしたほうがよいかも知れません）
SSPで何ができるのか考えています。SSPの概要がつかめたので改めて、sampl1を見直して次のような考えに至りました。SSPの範囲を超えてしまいますかね。

１）
*SSP
は制約タスクがベースになっており、タスクとしては待ちの状態はありません。組み込み処理を考えると待ちの状態がなくても良いわけではないと思います。そんな視点から、
SSPのsample1とASPのsample1を比べて見るとASPのmain_task()の機能はSSPではinit_task()と
main_task()の2つのタスクに分けて実現しているように見えます。であるなら、タスクの名称はmain_task_front()と
main_task_body()のように関連した名前にし、実行優先度を同一にしたほうがsampleとしては相応しい気がします。*
*イベント駆動のステートマシンを作って複数のタスクを組み合わせて機能を実現するのは、SSPの範囲を超えてしまいますかね。（一つのステートマシンで動作させるタスクは多分同一実行優先度になるでしょう）
*
２）
上記とは矛盾しますが、init_task()はタスクで動作させる必要があるのでしょうか。 SSPはタスクの数が１６と結構制限がきついので、
init_task()の処理は割り込み許可、ディパッチ禁止で実行するならSSPのタスク実行前に動作させてもよさそうです。RTOSではシステムの初期化を行なうタスクを作りますが、SSPの場合特別な初期化ルーチンを予め決めてしまっても良いと思いました。
SSPのプロセッサが32bitならタスクの最大を32に増やすコンフィギュレーションが欲しい気もします。

以上

2012年2月9日10:57 高橋和浩@nifty <takahashi_kazuhiro ＠ nifty.com>:

> こいさんさん 皆様 アライブビジョンソフトウエアの高橋です。
>
> > 「vmask_pri(優先度)で指定した起動時優先度以下のディスパッチを
> > 抑止します」と有りますが、この機能、逆に見ると、動作しているタスク(自タスク)の優先度を引き上げる事と同じだと思います。chg_pri(優先度)
> > 私もSSPに優先度を変更する機能を追加は、有効だと思っています。
> > 他タスクの優先度変更は考えないのでchg_priを使うと混乱しますね。
>
> 賛同いただきありがとうございます。
> 動作としては優先度を引き上げるのと同じになると思います。
> 基本的には chg_ipm や chg_ims のタスク優先度版ですね。
> たぶん、chg_ipmや chg_imsも現在の割り込みマスクレベルを上げる処理をすると考えているので
> vmask_priも優先度があがると考えても間違いないと思います。
>
> > 余分な話ですが、
> >
> 優先度の変更は制限をつけて起動優先度、実行優先度共に変更できるようにするのはどうでしょうか。考え方として、タスクの数より起動優先度テーブルの数を大きくして於き、同一タスクを複数の
> > 起動優先度テーブルに割り当て、この範囲で優先度を変更可能にする。
> > タスクIDから起動優先度変換と起動優先度からタスクIDの変換があれば実現できそうです。
>
> たぶん自分がその内容を理解できていないせいだと思うということを前提にコメントします。
> 可能な部分と可能でない部分があるように思います。まずそれが結論です。
>
> 以下詳細
> 実行時優先度の優先度切り替えは大変そうです。プリエンプト関係（変な用語ですが）を変えるような
> 実行時優先度変更は実現可能かもしれませんが、スタック使用量の再算出が必要になるように思います。
> あまり現実的でないように思います。
> 起動時優先度と実行時優先度がそろっている場合の優先度変更は、スタック使用量が変わらない範疇であれば
> 前述のpri_tblにさらに実行時優先度もそれに合わせれば実現可能と思います。
> ただ、制約条件のチェックが複雑になりそうです。つまりスタック使用量が変わらない変更かどうかの判断が
> 難しそうです。 今一度考えれば案はあるかもしれません。
> 起動時優先度の変更については、私の提案している方法で実装は容易です。ただ、プリエンプトしない関係の
> 起動優先度の間でかつ、さらに優先度の外部表現を含めたコンフュギュレーションが前提になります。
> つまり、起動時優先度があるグループ間にいくつかの起動時優先度を持った場合に、さらに他の
> 独立した起動時実行優先度が含まれる場合は問題があると思います。
> なのでそのようなコンフュグレーションができなくした場合に限られます。そうではなく手動で
> 設定した場合に以下の場合に問題があります。
>
> 具体的には
> タスク B 4-4
> タスク C 3-3
> タスク D 5-2
> の場合に2グループあります。 タスクDの起動時優先度を2に変えることはまずいということです。
>
> もともとタスクが休止から実行可能状態になるときに起動優先度をそのグループの中で最優先にするものです。
> そのグループの中での優先度変更は可能だと考えています。
>
> 具体的にできそうな機能：
> 制限付きの起動時優先度変更 vchg_pri(タスクID,内部表現起動時優先度）
> ただし内部表現の起動時優先度なので、タスクの現在の内部表現の起動時優先度の読み出しや
> 設定範囲も獲得するサービスコールも必要になるかと思います。
>
> よろしくお願いします。
>
>
> On Tue, 7 Feb 2012 21:08:04 +0900
> koizumi yoshiyuki <koizumiyoshiyuki ＠ gmail.com> wrote:
>
> >  高橋さま
> >
> > こいさんです。
> >
> > 「vmask_pri(優先度)で指定した起動時優先度以下のディスパッチを
> > 抑止します」と有りますが、この機能、逆に見ると、動作しているタスク(自タスク)の優先度を引き上げる事と同じだと思います。chg_pri(優先度)
> > 私もSSPに優先度を変更する機能を追加は、有効だと思っています。
> > 他タスクの優先度変更は考えないのでchg_priを使うと混乱しますね。
> >
> > 余分な話ですが、
> >
> 優先度の変更は制限をつけて起動優先度、実行優先度共に変更できるようにするのはどうでしょうか。考え方として、タスクの数より起動優先度テーブルの数を大きくして於き、同一タスクを複数の起動優先度テーブルに割り当て、この範囲で優先度を変更可能にする。
> > タスクIDから起動優先度変換と起動優先度からタスクIDの変換があれば実現できそうです。
> >
> > 以上
> >
> >
> ---
> アライブビジョンソフトウエア株式会社
> 高橋和浩
> 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/20120213/eb8c63ba/attachment.html>