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

[ykominami]

小南と申します。

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