(toppers-users 3737) Re: SSPの制約タスクの待ちについて
yasuo kominami(nifty)
ykominami @ nifty.com
2012年 1月 17日 (火) 15:20:52 JST
小南と申します。
2012年1月16日20:34 koizumi yoshiyuki <koizumiyoshiyuki @ gmail.com>:
> こいさんです
>
> SSPの制約タスクの仕様ですが、μITRON4.0仕様5.2.1 制約タスク が原典で良いのでしょうか。
>
> であるなら、制約タスクは
>
> * 待ち状態に入ることができない.
>
> と有ります。sample1でtask()が動作している時に、周期ハンドラのcyclic_handler()からmain_taskタスクが起動され、taskの動作中にmain_taskタスクが動作してます。これはtaskが待たされていることにはならないのでしょうか。(私は、待たされていると思います)
>
> 優先度の高いタスクが優先度低いタスク動作中に動作することになると、制約タスクのスタックは 【補足説明】 の
> 「各タスクのスタックサイズの最大値」ではスタック不足が発生してしまうと思いますが、如何でしょうか。
>
> SSPの仕様書の類がまだ非公開(?)なので、理解できずにいます。
>
> 何かヒントになる情報が入手できないでしょうか。
>
このメールでは、μITRON4.0仕様5.2.1 制約タスクについてのみコメントします。
私が仕様書を読んで理解した限り、「制約タスク」であれば、複数の制約タスク間でスタックを共有することが「可能」
ですが、「制約タスク」であれば、「すべての制約タスク間でスタックを共有する」わけではないです。
制約タスク間でスタックを共有するか、しないかは、あくまでもタスクを生成するときに指定したスタック領域の先頭
アドレスが同一であるか否かで決まることです。
μITRON4.0仕様では、「複数の制約タスク間でスタックを共有する」と規定しているわけではなく、そのことが「可能」
となるように制約タスクの仕様を、通常のタスクと比べて「制限」しています。
1.「広義の待ち状態」に入れない。
2.優先度を変更できない
3.「タスクの終了」は、そのタスクのメインルーチンからリターンするのみ。
1.によって、制約タスクが取りうる状態は「実行状態」、「実行可能状態」、「休止状態」になります。
#未登録状態も含めても良いかもしれません。
実行可能状態を抜けるのは、以下の二つの場合です。
A.タスクを終了させる
B.(より優先度の高いタスクが実行可能状態になったため)カーネルがプリエンプトして実行可能状態
にする(他のタスクを実行状態にする)
カーネルがプリエンプトした場合、次に再び、実行可能状態のなかで最も優先度が高いタスクになった
とき、以前プリエンプトされたタスクが、ふたたびカーネルによって実行状態にされます。
# もし、実行可能状態のタスクの中に、他にも同一優先度のタスクがあったとしてもです。
# 同一優先度の他のタスクに実行権を渡すには、rot_rdqというサービスコールを呼ぶ必要がありますが、
# 自動車制御用プロファイルでは含まれません。
# rot_rdqが制約タスクを扱う場合のカーネルの振る舞いは、カーネルの実装依存です。仕様として規定
# されていません。
こういう仕様とすることで、スタックを共有する場合でも、優先度の高いタスクが実行状態になれば、
そのタスクが終了するまで、それよりも優先度の低いタスクは実行状態にならないようにしています。
ただし、この仕様でもスタックを共有するのが危ない場合もありますが、それに対しては、uITRON仕様と
しては、アプリが制約タスクの使い方を誤っているとして、仕様として振る舞いを規定しないという立場を
とっています。
#公開されているSSPのsample1.cfgではスタック領域の先頭アドレスはNULLが指定されていますが、
#TOPPERS/ASPなどでは(より正確にはコンフィギュレータは)、指定サイズ分のスタックを(NULLが
#指定されたタスク間で)重複しないように割り当てます。
#SSPのusers.txtでは、「3.2. コンフィギュレータの構築」において、以下のように記述されています。
# SSPカーネルの開発においては
# TOPPERSプロジェクトのサイトで公開されているWindows環境用のバイナリを
# 使用している.
#
#sample1.cを読む限り、TASK1、TASK2、TASK3の間でスタックは共有できそうです。
#ただし、MAIN_TASKと他のタスクの間ではスタックを共有できないと思います。
#