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

Naoki Saito nsaito.nmiri @ gmail.com
2012年 1月 19日 (木) 19:39:19 JST


斉藤です。

>  2番目の文に対しては,当然でたらめになり得ます.
> しかしそれは使い方次第です.どんなむちゃくちゃなプロ グラムを書いても
> ちゃんと動けというのはそりゃムリです.

とはいいましても
できるだけ問題を検知出来るような、
OSやツールの機能が提供できれば
とも考えておりますので、
どのような心配事が有り得るか
御教示いただければとも思います。

以上、よろしくお願いします。
2012/01/19 18:58 "Naoki Saito" <nsaito.nmiri @ gmail.com>:

> 斉藤です.
> (toppers-users 3788) を確認したという前提の元で,お返事します.
>
> > TASK3が動作しているときはTASK4が動かず、
> (略)
> >  これが意図とでは優先度とは何よと思いたくなるのは、私だけでしょうかね。
>
> 逆に.優先度とはどのようなものと思われたのか,興味を持ちました.
>
> 例として仰られたようなケースは一つの使い方でして,
> そのような挙動をさせたいというケースもないとはいえないです.
> 例えば (toppers-users 3781) で高田先生が仰られた様な
> スタック領域が少なくて済むようにしたいというのもその一つかと思います.
> 排他制御のためにそうしたいという理由もあると思います.
>
> >
>  どちらのタスクが優先度が高いのかと一言で表現できないのは、美しくないと思います。やる人はいないと思うが、もっと複雑な(誤った?)設定をした場合、優先度がでたらめになりませんか。
>
> 最初の文に対して,
> 美しいかどうかは主観的な評価なのでなんとも申し上げることは出来ませんが
> 仰るような考え方によりますと,動的に優先度が変更し得るOSは皆美しくない
> ことになりますね.そういう理解で合ってますでしょうか?
> 現存するOSはそういうものも割と多いと思いますが,どう思われます?
>
> 2番目の文に対しては,当然でたらめになり得ます.
> しかしそれは使い方次第です.どんなむちゃくちゃなプログラムを書いても
> ちゃんと動けというのはそりゃムリです.
>
> 以上,適切なお答えになっているか心配ですが,よろしくお願いします.
>
> 2012年1月19日16:15 koizumi yoshiyuki <koizumiyoshiyuki @ gmail.com>:
> >  こいさんです
> >
> >  理屈としては解るのですが、この場合
> > TASK3が動作しているときはTASK4が動かず、
> > TASK3が動作しているときはTASK4が動きません。
> >  これが意図とでは優先度とは何よと思いたくなるのは、私だけでしょうかね。
> >
> >
>  どちらのタスクが優先度が高いのかと一言で表現できないのは、美しくないと思います。やる人はいないと思うが、もっと複雑な(誤った?)設定をした場合、優先度がでたらめになりませんか。
> >
> >  まあ、意図なら納得するしかありません。
> >
> >  以上
> >
> > 2012年1月19日15:39 Naoki Saito <nsaito.nmiri @ gmail.com>:
> >>
> >> こいさんさん
> >>
> >> 斉藤です.
> >>
> >> >  現行のSSPのCFGで以下の設定をすると、優先度反転が発生します。これは良いのでしょうか。
> >> >  TASK3が動作中にTASK4はTASK3より優先度が高いのに起動できません。
> >>
> >> TASK3 の実行時優先度は4で,TASK4の起動時優先度は6ですので
> >> TASK4 は TASK3 より優先度が低い(数値としては大きい)です.
> >> したがってTASK4 が起動出来ないのは仕様に沿っているように思います.
> >>
> >> >  CFGで生成されたkernel_cfg.cは以下のようになり、TASK3とTASK4の優先度の反転が発生しています。
> >> >
> >> > const uint_t   _kernel_tinib_epriority[TNUM_TSKID] =
> >> >
> >> >
> {INT_PRIORITY(1),INT_PRIORITY(2),INT_PRIORITY(3),INT_PRIORITY(4),INT_PRIORITY(4),INT_PRIORITY(3)};
> >>
> >> これは実行時優先度を格納する配列です.
> >> プリエンプトが発生するかどうかは
> >> 実行中タスクの実行時優先度と起動要求タスクの起動時優先度とを
> >> 比較します.従いまして,TASK4 の実行時優先度はこの場合参照されません.
> >>
> >> 以上,よろしくお願いします.
> >>
> >> 2012年1月19日10:59 koizumi yoshiyuki <koizumiyoshiyuki @ gmail.com>:
> >> >    高田先生
> >> >
> >> >  こいさんです。表現は色々有ると思いますが、私にはSSPは優先度を2つ持っているように見えています。
> >> >  2つの優先度は _PRIORITY >_EXEPRIORITY 設定されてる必要が有るでしょう。これは解りにくいケースもあると思います。
> >> >
> >>
> >> > >
>  同じようなケースが(私にはある意味、同じように見えています)Cortex-M3の割り込み優先度に見られます。ここでは優先度を上位/下位の2つに分け、上位側で横取り割り込み優先度とし、下位側は等優先度内(制約タスク相当)の優先度としています。外からは優先度は一つしかないので優先度設定の混乱を避けることができていると思います。
> >> >
> >> >  尚、
> >> >  現行のSSPのCFGで以下の設定をすると、優先度反転が発生します。これは良いのでしょうか。
> >> >  TASK3が動作中にTASK4はTASK3より優先度が高いのに起動できません。
> >> >
> >> >  テストタスクを3つから4つに増やし優先度を以下のように設定する
> >> >
> >> >  sample1.h
> >> > #define INIT_PRIORITY   (1)
> >> > #define MAIN_PRIORITY   (2)
> >> > #define TASK1_PRIORITY   (3)
> >> > #define TASK2_PRIORITY   (4)
> >> > #define TASK3_PRIORITY   (5)
> >> > #define TASK4_PRIORITY   (6)
> >> > #define TASK3_EXEPRIORITY  (4)
> >> > #define TASK4_EXEPRIORITY  (3)
> >> >
> >> >  sample1.cfgを以下のように記述
> >> > CRE_TSK(INIT_TASK , { TA_ACT , 0 , init_task , INIT_PRIORITY ,
> >> > STACK_SIZE ,
> >> > NULL });
> >> > CRE_TSK(MAIN_TASK , { TA_NULL , 0 , main_task , MAIN_PRIORITY ,
> >> > STACK_SIZE ,
> >> > NULL });
> >> > CRE_TSK(TASK1 , { TA_NULL , 1 , task , TASK1_PRIORITY , STACK_SIZE ,
> >> > NULL
> >> > });
> >> > CRE_TSK(TASK2 , { TA_NULL , 2 , task , TASK2_PRIORITY , STACK_SIZE ,
> >> > NULL
> >> > });
> >> > CRE_TSK(TASK3 , { TA_NULL , 3 , task , TASK3_PRIORITY , STACK_SIZE ,
> >> > NULL
> >> > });
> >> > CRE_TSK(TASK4 , { TA_NULL , 4 , task , TASK4_PRIORITY , STACK_SIZE ,
> >> > NULL
> >> > });
> >> > DEF_EPRI(TASK3 , { TASK3_EXEPRIORITY });
> >> > DEF_EPRI(TASK4 , { TASK4_EXEPRIORITY });
> >> >  CFGで生成されたkernel_cfg.cは以下のようになり、TASK3とTASK4の優先度の反転が発生しています。
> >> >
> >> > const uint_t   _kernel_tinib_epriority[TNUM_TSKID] =
> >> >
> >> >
> {INT_PRIORITY(1),INT_PRIORITY(2),INT_PRIORITY(3),INT_PRIORITY(4),INT_PRIORITY(4),INT_PRIORITY(3)};
> >> >  以上
> >
> >
>
-------------- next part --------------
HTMLの添付ファイルを保管しました...
URL: <http://www.toppers.jp/pipermail/users/attachments/20120119/917f6533/attachment.html>