(toppers-users 3816) Re: SSPの DEF_EPRI とは何でしょうか。

[yasuo kominami(nifty)]

小南です。

こいさんの追伸にコメントします。

1.タスクスケジュールの仕様

SSPに限らず、TOPPERSのカーネルのタスクスケジュールの仕様は、優先度だけでは
説明しにくいです。

優先度を基にした優先順位というものを定義し、実行できる状態(runnable)のタスク
の集まりのうち、優先順位が最も高いものを実行状態にするとしています。

（実行できる状態のタスク=実行状態のタスクと実行可能状態のタスクの集まり）


ここでは話を簡単にするため、タスクの優先順位に話を絞ります。
（仕様書では、タスクに限らず広く処理単位-タスクや割込みハンドラなど-に対して
優先順位が定義されています）

なぜ優先順位を持ち出すかというと、同一優先度のタスクがあった場合にどうするか
とか（並び順も時間がたつと変わりえます）、待ち状態に入ったり、終了したりなど
して、次に実行状態にすべきタスクを選び出すときに、その対象となるタスクの集ま
りが増減するからなどです。

このように、対象の集まりが変化しても、その時々で一意に決まるように優先順位を
定義しておけば、常に同じアルゴリズムで最も高い優先順位のタスクを選び出すこと
が出来ます。

そうはいっても、優先順位の定義自体は単純です。

#以下は私の言葉での説明です。仕様書の記述そのままではありません。
#また、現在のカーネルのソースコードと照らし合わせていません。
#こういうアイデアを実装しているというぐらいの話です。

実行可能状態であるタスクに対して、優先度ごとにキューをつくります。このキュー
はタスクが実行可能状態になった順(FCFS)につくられます。
優先度が高いキューにあるタスクの方が優先順位が高く、同じキューの中では、先頭
にあるほうが優先順位が高いとします。

その時々に存在する、実行可能状態であるタスクのうち、最も高い優先度のキューの
先頭のタスクと、実行状態のタスクの現在優先度を比較し、高い方を次の実行状態
のタスクとします。実行状態から実行可能状態になったタスクはキューにつながれま
す。

(正確な定義は「統合仕様書　2.6.3　タスクのスケジューリング規則」を参照してく
ださい)


この優先順位からみると、タスクスケジューリングは（その基本的なアイデアは）、
TOPPERS/SSPもTOPPERS/ASPと変わらないと思います。

上記のアイデアを図示して（優先度の高いキューを上に、キューの左側の方が優先度が
高いとします）、優先順位の順にタスクを線でつないでいくと、一筆書きに出来ます。
ちょうどアルファベットのZを上下にくっつけた図になると思います。

これを、その優先順序を保ったまま、ぐいっと引っ張って、縦に一直線にすると、優先
順位にしたがって、上からタスクが並んでいます。

そして、この線がゴムでできているとして、一直線に並べたタスクが、（ゴムが縮んで）
出来るだけそのタスクの優先度と同じキューの位置になろうとするとします。ただし、
もともと属していたキューの位置よりも高くはならないとします。
また、もともとキューに複数のタスクが存在すれば、先頭より後ろのタスクは、より
低い優先度のキューの位置にまでしかくることが出来ません。



この一直線にしたときの各タスクが存在する位置にあるキューの優先度が、各タスクの
起動時優先度であり、一直線になる前の、タスクがつながっていたキューの優先度が
実行時優先度にあたるのではないでしょうか。
こうであれば、優先度ごとにタスクは1個のみ存在します。

#TOPPERS/SSPにおける優先順位について、ドキュメントやMLでの発言で確認がとれない
ため断言は避けます。



私も、静的APIの新設とか、2つの優先度があるという説明から、難しいとか、仕様が
（大きく）変わったような印象を受けました。
しかしSSP開発者の方の発言からは「当たり前」という雰囲気しか感じられませんでした。

このギャップはどうして生じるのかと思っていたのですが、今回こいさんの追伸に対して
「優先順位」のことを書こうとしていて、「あれ、優先順位そのものはSSPでも変わらな
いのではないか。逆に変えないためにSSPの仕様を決めたのではないか」と思うように
なりました。

#本当はどうなのかは、今後公開されるSSPのドキュメントを読んで確認したいです。


#SSPで「問題が発生するのではないかという懸念されるケース」などは、2つの優先度
#が原因というよりは、もともとASPなどでも発生する可能性があるものか、「広義の待ち」
#がないことの影響から顕在化しやすいものではないかと(現在は)思っています。



*参照先
統合仕様書の中で、優先順位に関わる記述は以下のところにあります。


「TOPPERS新世代カーネル統合仕様書(Release 1.3.0)」

**2.3.2 サービスコールとパラメータ

	(1) 優先順位と優先度
	
「優先順位（precedence）とは，処理単位の実行順序を説明するための仕様上の
概念である．複数の処理単位が実行できる場合には，その中で最も優先順位の
高い処理単位が実行される．
	
優先度（priority）は，タスクなどの処理単位の優先順位や，メッセージなど
の配送順序を決定するために，アプリケーションが処理単位やメッセージなど
に与える値である．優先度は，符号付きの整数型であるPRI型で表し，1から連
続した正の値を用いるのを原則とする．優先度は，値が小さいほど優先度が高
い（すなわち，先に実行または配送される）ものとする．」


**2.4.2 処理単位の実行順序

**2.6 タスクの状態遷移とスケジューリング規則



2.「待ち」について

実行可能状態から実行状態になかなか移れない場合が発生すると、そのRTOS上でのアプリ
（OR システム）におけるリアルタイム制約が守られない可能性があります。

日常生活でも、たとえばレストラン、食堂などで満席になっていて、入り口からの行列
の中で待たされるような状態でしょうか。

時分割システムのように、タスクがある時間を過ぎたら、プリエンプトして他のタスクを
実行状態にするという方法もあります。
ただし、この場合でもスループットは向上するとはいえても、必ずリアルタイム制約を満
たすことができるとは言えません。
たとえば、その時間がかかっているタスク自体に対するリアルタイム制約があり、それが
守られないことが問題ならば、時分割システムの方式を持ち込んでも、何の解決にもなり
ません。
カーネル側の工夫でどうなることではなく、カーネルとしてはリアルタイム制約を満たす
ために役立つ手段を提供することぐらいしかできないです。


これは、TOPPERS/SSPに限らず、TOPPERS/ASPなどでも起こりうることです。
ただし、TOPPERS/ASPのように「広義の待ち」があるシステムでは、タスク自体が無限
ループを持ち、適宜待ち状態に入ることで、上記の問題が起こりにくくすることは出来ます。
「広義の待ち」がないTOPPERS/SSPではその手段が使えないです。
単純にタスクに無限ループを持たせると、そのタスクが実行状態のままになりやすいと
思います。
「広義の待ち」を持つことと似たような効果が得られる工夫が必要になります。
#もともと割込みに対する処理で事足りてタスクが必要ない、あるいは割込み処理からタスク
#を起動されるだけでよいとか、常に1個のタスクのみが動いていればよいとかなどという
#場合も含みます。


後、コミュニケーションの問題になるとは思いますが、TOPPERS新世代カーネル統合仕様書
や、μITRON4.0仕様書などでは、「実行可能状態」であるタスクに対しては「待ち状態」と
は云いません。

長く実行可能状態に留まり、実行状態になれないタスクが存在するとしたら、そのRTOS上の
アプリ（OR　システム）としては、（リアルタイム制約を守れていない可能性があるため）
問題でしょうが、カーネルの仕様としては、たとえば「TOPPERS新世代カーネル仕様書　2.6.3
タスクのスケジューリング規則」において、「実行できるタスクは優先順位の高いものから
順に実行される」としているだけです。

リアルタイム制約が守れていないタスクを見つけたりとか、それを終了させることは出来て
も（そういうRTOSの研究はあります）、カーネルがタスクにリアルタイム制約を守らせるこ
とは出来ません。出来ることとしては、守らせることに役立つ手段を設計者に提供すること
ぐらいです。

実行可能状態のタスクのうち、どれを実行状態のタスクとするかは、CPUという資源を排他
制御することともいえますが、これに関わって発生する（こいさんの言われる）「待ち」を、
仕様上は、「待ち」とは言いませんし、特に用語もありません。

仕様として「待ち」という概念、用語を定義しているのは、タスクが他の処理単位（タスク、
割込みハンドラなど）とCPUという資源以外のものを排他制御するための「待ち」です。
#slp_tskは例外とさせてください。

この「待ち」はタスクが待ちを伴うサービスコールを呼び出した時、そのサービスコールの
中で発生します。

実行状態のタスクが実行可能状態になるのは、割込みやCPU例外が発生して、実行中のタスク
のコンテキストを、割込みハンドラやCPU例外ハンドラの入口処理がカーネルのタスク管理
領域に書き込み、割込みハンドラやCPU例外ハンドラの出口処理において、カーネルが「実行
できる状態のタスクの中で優先順位が変更されたこと検知したときに起こります。


「広義の待ち」は、「実行可能状態に長く留まる」というこいさんの言われる「待ち」とは
概念もカーネルの処理としても異なります。


TOPPERSのRTOSカーネルやμITRON系ROTSカーネルで単に「待ち」というと、「広義の待ち」
を意味します。

こいさんの言われる「待ち」に該当する用語が無いため、どういう言い方をすればよいとは
言えないのですが。