(toppers-users 3747) Re: SSPの制約タスクの待ちについて

Hiroaki TAKADA hiro @ ertl.jp
2012年 1月 17日 (火) 23:14:46 JST


小南さん

> 私があげた1,2,3を守ったとしても、たとえば現在公開されているSSPの
> sample1において、
> MAIN_TASKが(ASPなどでの無限ルール内での待ちを伴うサービスコールの呼び
> 出しに代えて)、
> 周期ハンドラで定期的にタスク起動されますが(ループしていないのですぐ終
> 了してしまい
> ますが)、このMAIN_TASKが、他のTASK1などとスタックを共有していて、
> TASK1が実行状態
> であった場合でも、カーネルがTASK1をプリエンプトして、MAIN_TASKを実行状
> 態にすると
> 危ないのではないかと考えました。

これは危なくありません。

「スタックを共有する」と言うのは、優先度が異なるタスクの間では、一連の
スタックを使うことを意味しています。上のケースでは、TASK1のスタックの
続きの領域をMAIN_TASKが使いますので、問題ありません。

高田広章
名古屋大学

(12/01/17 15:46), yasuo kominami(nifty) wrote:
> 高田先生
> 
> 小南です。
> 
> 2012年1月17日15:31 Hiroaki TAKADA<hiro @ ertl.jp>:
>> 小南さん wrote:
>>> # rot_rdqが制約タスクを扱う場合のカーネルの振る舞いは、カーネルの実装
>>> 依存です。仕様として規定
>>> # されていません。
>>
>> ご指摘の通り、μITRON4.0仕様では規定していませんが、TOPPERS新世代カーネ
>> ル統合仕様では、rot_rdqの機能説明の中で以下のように規定しています。
>>
>> ----------
>> 対象優先度を持つ実行できる状態のタスクの中で,最も優先順位が高いタスク
>> が制約タスクの場合には,E_NOSPTエラーとなる.
>> ----------
>>
>>> こういう仕様とすることで、スタックを共有する場合でも、優先度の高いタス
>>> クが実行状態になれば、
>>> そのタスクが終了するまで、それよりも優先度の低いタスクは実行状態になら
>>> ないようにしています。
>>>
>>> ただし、この仕様でもスタックを共有するのが危ない場合もありますが、それ
>>> に対しては、uITRON仕様と
>>> しては、アプリが制約タスクの使い方を誤っているとして、仕様として振る舞
>>> いを規定しないという立場を
>>> とっています。
>>
>> どういう場合に危ないか、お知らせ下さると幸いです。
>>
> 
> 私の書き方で、「危ない」としたのが「rot_rdq」の仕様を指していると受け取られてしまった
> かもしれません。
> その意図はありません。
> 
> 私があげた1,2,3を守ったとしても、たとえば現在公開されているSSPのsample1において、
> MAIN_TASKが(ASPなどでの無限ルール内での待ちを伴うサービスコールの呼び出しに代えて)、
> 周期ハンドラで定期的にタスク起動されますが(ループしていないのですぐ終了してしまい
> ますが)、このMAIN_TASKが、他のTASK1などとスタックを共有していて、TASK1が実行状態
> であった場合でも、カーネルがTASK1をプリエンプトして、MAIN_TASKを実行状態にすると
> 危ないのではないかと考えました。