(toppers-users 1533) Re: Fi4の(i)set_flag、同期・通信関連del_系サービスコールでのdispatchについて

Kominami Yasuo NBC00224 @ nifty.com
2004年 7月 13日 (火) 06:22:48 JST


小南です。

On Mon, 12 Jul 2004 21:19:41 +0900
SHUKUGUCHI Masahiro <ms89019 @ mms.co.jp> wrote:

> 宿口です。
> 
> 既に バグ として認識されているようですが。
> 
> 小南さん:
> [CUT]
> > 私としては個々のタスクの待ち解除にはディスパッチを含めず、すべてのタスクが
> > 待ち解除された後にディスパッチされるべきだと思います。理由は上記の優先度逆
> > 転の発生を防ぐためです。
> [CUT]

** Cut quoted 8 lines by the mail filter. **
はい、そうです。問題にしたいのはFIFOの場合についてです。
 
> 要求仕様としては、小南さん仰せの通りだと思います。
> 実装としては、厄介そうかなぁ。
> 
 (略)

> 「ディスパッチ保留状態」をどのように実装するか?ですね。
> # 適当にアイデアを書いてみます。
> 
>  「Readyキューにつながない」ので良いのか?
>    → del_xxx 実施中のディスパッチ対象外にはできる。
>      del_xxx 終了時にReadyキューにつなぐ場合の処置に一工夫要る。
>       → ・削除対象資源に保留キューを用意する。
>         ・この保留キューはプライオリティキューとする。
>         ・待ちタスクは、元の待ちキューから削除されると一旦保留キュー
>         につなぐ。

** Cut quoted 16 lines by the mail filter. **
FIFO順の待ち行列以外に、優先度別のFIFOの待ち行列をもたせ、いちどに待ち解除する時は
優先度別待ち行列から待ち解除したらどうか(仕様そのままではないですが、レディキューでの優先
順位と、FIFO順待ち行列上での優先順位は変らないという効果はあります)などと考えたりしま
したが、道具立てが大きくなると通常の処理にも時間がかかりそうで、どういのがいいか私も考えが
まとまりません。


> この問題は、del_xxx を実行したときの待ち行列に存在するタスクの数の上限が
> 決定できない(最大 N 個 になる。)ことに起因しているように思います。
>  N個のタスクを処理する間、CPUロック状態に出来ない。ということですね。
> # 解っていいらっしゃると思いますが、念のため。

最初にこの問題に気がついたのは、set_flgを見たときです。
iset_flgが(いちいちディスパッチせずに)すべての待ち行列上のタスクを待ち解除す
るだけなのをみて(最終的にはしかるべき時にディスパッチされるので)、「CPUロック状態
にすることが出来ればなんとかなりそうだな」とは思いました。
しかし、μITRON4.0仕様ではこの場合にCPUロック状態にする根拠に乏しいと感じた
ため、「CPUロック状態なしで実現する方法を考えなければならないだろうな」と思っています。


----------- 
小南 靖雄
ykominami @ nifty.com
(NBC00224 @ nifty.com)