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

[SHUKUGUCHI Masahiro]

宿口です。

既に バグ として認識されているようですが。

小南さん：
[CUT]
> 私としては個々のタスクの待ち解除にはディスパッチを含めず、すべてのタスクが
> 待ち解除された後にディスパッチされるべきだと思います。理由は上記の優先度逆
> 転の発生を防ぐためです。
[CUT]
> けれどもこの記述は、ある瞬間には一つのタスクの状態しか変化しないと言う前堤
> に立っているからだと思います。
> 複数のタスクが待ち解除される場合は、これらとは区別し、「3.5.6 ディス
> パッチ保留状態の間のタスク状態」のようにディスパッチ保留されるべきではない
> でしょうか。

待ちキューがプライオリティキューでなく、FIFOキューの場合のタスクスケジュ
ーリングの問題ですね。

要求仕様としては、小南さん仰せの通りだと思います。
実装としては、厄介そうかなぁ。

「ディスパッチ保留状態」をどのように実装するか？ですね。
# 適当にアイデアを書いてみます。

　「Readyキューにつながない」ので良いのか？
　　　→ del_xxx 実施中のディスパッチ対象外にはできる。
　　　　 del_xxx 終了時にReadyキューにつなぐ場合の処置に一工夫要る。
　　　　　　→ ・削除対象資源に保留キューを用意する。
　　　　　　　 ・この保留キューはプライオリティキューとする。
　　　　　　　 ・待ちタスクは、元の待ちキューから削除されると一旦保留キュー
　　　　　　 　につなぐ。
　　　　　　　 ・元の待ちキューの処理が終了した後に、保留キューにあるタスク
　　　　　　　 をReadyキューにつなぎなおす。（もちろん、 CPUロック状態はこま
　　　　　　　 めに切り替える）

　　　　保留キューはヘッダがあれば十分なので、スタック上にとればよい？
　　　　del_xxx 実施中のスタックを何処に取るか。。。

　「TCB に保留ビットを持たせる」ので良いのか？
　　　→ del_xxx で元の待ちキューからReadyキューにつなぎなおす際に保留ビット
　　　　を設定する。
　　　　 保留ビットが設定されている間はディスパッチ対象外。

　　　　 ？？？ でも 保留ビットをいつリセットするんだろうね？

　上記はどれも場当たり的はありますね。

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

とりとめもありませんが、とりあえず。

宿口雅弘