(toppers-users 2449) Re: TOPPERS/FI4 のバグ

[ykominami]

小南です。

On Tue, 13 Jun 2006 13:57:22 +0900
takaya_kakizaki ＠ gmx.yamaha.com wrote:

> 柿崎です。
> 
> 前者の件について補足します。
> タスクAにおいて、acp_porを呼び出し、
> タスクAをランデブポートの受付待ち状態にします。
> その後タスクBで、同じランデブポートのcal_por(tcal_por)を呼び出しランデブを
> 成立させます。
> このときタスクAとタスクBの優先度は同じにしてあります。
> cal_porを呼び出したとき、CPUロック状態でもディスパッチ禁止状態でもありませ
> ん。
> 
> このとき
> unknown error reported by 
> `tcal_por(SAMPLE_POR,TEST_RDV,&rcvdata,sizeof(rcvdata)
> ,10000)' in line 254 of `sample1.c'.
> 
> といったログメッセージを出力します。

これは、include/t_services.hで定義されたsyscallマクロによる
出力だと思います。
その場合、同じt_services.hで定義された_t_perror関数を呼び出します。
この関数の中で、エラーコードが0より小さい場合、すなわちE_OK以外の
場合は、上記のメッセージを出力します。
このマクロは簡易的なもので、エラーコードがE_OKか、E_OK以外かしか
判断しません。
tcal_porの場合、指定時間内にランデブが成立しなければE_OKではなく、
E_TMOUTが返ってきます。

具体的な返値が知りたいです。
 
> >このため、ディスパッチ保留状態であれば、ディスパッチは発生しません。
> >ディスパッチが起こる状態で、かつディスパッチが必要である場合に、
> >wait_completeはTRUEを返します。
> 
> >#TOPPERSのITRON仕様OSの実装では、タスクの状態変更を行う関数の返値は、
> >#その時点でディスパッチが必要か必要でないかを示しています。
> 
> ディスパッチを発生させる要因はwait_completeではなく、
> その前のwobj_make_waitにあるのですが、それでも成り立ちますか。

はい。

ITRON仕様と実装に話を分けます。

ITRON仕様上は、ディスパッチを発生させる要因が存在すれば、ディスパッチ
をさせないといけません。
ただし、ディスパッチはディスパッチを行える状態の場合でないと行えません。
したがって、タイミングは要因の発生と同時ではなく、ずれることがあります。


ディスパッチ保留状態でない場合の処理に話をしぼると、実装の話になります。

実装上は、ディスパッチを発生させる要因が生じたら、その直後にディスパッチ
をするか、直後でなく他の処理も行ってから、ディスパッチをすべきかを判断し
て、ディスパッチをするかですが、ソースコード上の見通しの良さと処理速度の
トレードオフ範囲内の話だととらえています。
サービスコールの不可分性も守られているわけですし。

今回のような待ち解除もいろいろなサービスコールから呼び出される可能性が
あるため、待ち解除の直後にディスパッチを行うとしたら、どういう状態で待ち
解除を行ったかの条件判別が必要になる（それこそサービスコール毎に異なる処理
が必要になるかもしれません)と思います。

(略)

> >> これは変数の初期化忘れですかね。
> >これは、待ちタスクが確保したいブロックを、rel_mpl()中で
> >((WINFO_MPL *)(tcb->winfo))->blkszとして参照して
> >いるのに、get_mpl()で設定していないということでしょうか。
> 
> これはおっしゃるとおりです。
> 
> >それであるならば、以前FI4のバグデータベースが、TOPPERS
> >プロジェクトの会員でなくてもアクセスできたときに、そのバグ
> >が登録されているのをみた覚えがあります。
> 
> >ただし、現在のリリースでは修正されていないようですね。
> 
> だとすると、今のところは各自で修正を施すしか方法がないということでしょうか
> 。

修正されたリリースが出ていない状態では、そうなるかと思います。

----------------------------------- 
小南 ykominami ＠ nifty.com