11/08/21 19:54:14.23 .net
>676
なんだかなぁ、君の言うとおりのことを指摘しているんだけど。どうも言葉が伝わらないな。
そうですよ。 スピンロックは必然。 waitQの待ちは有限時間なので必然ではない。
だから、WaitQの待ちでも有限時間だけども、STDPROFよりも大きいものは問題なので
対応したいが、テストがかかるため天秤にかけた結果WaitQの待ちは見送った。
見送った理由は、開発期間、時間的な理由もちゃんとした理由としてできない理由としてそれは
それでそのときの判断としては正しいと思うよ。
一方、スピンロックは必然的に割り込みを空けなくてはならなくなった。
必要は発明の母という言葉があるようにそれでようやくTTSPを作ったわけ。
必要であれば作れたってことは、FMPの開発時で、waitQの問題に対処できるわけなんだな。
これも実は開発者自身に直接聞いて回答いただいている。
「WaitQの割り込みをあけることも可能だが、性能的に問題にならないので対応していない」
という回答。まぁさらに聞きたかったけど、あまりにその講義の範囲を超える話に
なりそうなのでそれまでしか聞かなかった（聞けなかった）です。
>whileループでぐるぐる回る[i]set_flg のほうは更に頑張るはずだよね．
>(あとはソースコード読みなおしてみて)
[i]set_flgを見ているからわざと、wai_flgを引用しているんだけどな。
ただこれはドキュメントに書いてある。
---------------------------------------------
ASPカーネルでは， 以下のシステムコールは待ち解除されるタスクの数に比例
して長くなる．
・init_xxx
・イベントフラグ set_flg()
FMPカーネルでは，ロックを取得する関係ため，実行時間の上限が定まらない．
------------------------------------------------
ちょっとこれってお粗末じゃないのと正直思うけどね。