(toppers-users 2446) Re: TOPPERS/FI4 のバグ
ykominami
ykominami @ nifty.com
2006年 6月 13日 (火) 13:00:56 JST
小南と申します。
On Tue, 13 Jun 2006 10:29:41 +0900
takaya_kakizaki @ gmx.yamaha.com wrote:
> 柿崎と申します。
> TOPPERS/FI4を評価していて以下のバグを発見しました。
>
> ランデブポートを
> タスクA:acp_por
> タスクB:cal_por
> の順に呼び出すと、cal_porの時点でエラーを吐くというものです。
こちらの方ですが、エラーコードは何だったのでしょうか。
「uITRON4.0仕様 3.5.6 ディスパッチ保留状態」では、以下のように規定さ
れています。
ディスパッチャよりも優先順位が高い処理が実行されている間、CPUロック状
態の間、およびディスパッチ禁止状態の間は、ディスパッチが起こらない。こ
の状態をディスパッチ保留状態と呼び、その間のタスク状態については次のよ
うに定める。
ディスパッチ保留状態では、実行中のタスクがプリエンプトされるべき状況と
なっても、新たに実行すべき状態となったタスクにはディスパッチされない。
実行すべきタスクへのディスパッチは、ディスパッチが起こる状態になるまで
保留される。ディスパッチが保留されている間は、それまで実行中であったタ
スクが実行状態であり、ディスパッチが起こる状態になった後に実行すべきタ
スクは実行可能状態である。
このため、ディスパッチ保留状態であれば、ディスパッチは発生しません。
ディスパッチが起こる状態で、かつディスパッチが必要である場合に、
wait_completeはTRUEを返します。
#TOPPERSのITRON仕様OSの実装では、タスクの状態変更を行う関数の返値は、
#その時点でディスパッチが必要か必要でないかを示しています。
どういう状態でcal_porが呼び出され、どういうエラーコードが返ってきたので
しょうか。
そこがはっきりしないとバグか否かははっきりしないと思います。
> もうひとつ、可変長メモリブロックを獲得するときに
> 待ち状態にはいるとメモリを獲得できなくなります。
(略)
> これは変数の初期化忘れですかね。
これは、待ちタスクが確保したいブロックを、rel_mpl()中で
((WINFO_MPL *)(tcb->winfo))->blkszとして参照して
いるのに、get_mpl()で設定していないということでしょうか。
それであるならば、以前FI4のバグデータベースが、TOPPERS
プロジェクトの会員でなくてもアクセスできたときに、そのバグ
が登録されているのをみた覚えがあります。
ただし、現在のリリースでは修正されていないようですね。
-----------------------------------
小南 ykominami @ nifty.com