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

Masaki Muranaka monamour @ monaka.org
2006年 6月 14日 (水) 11:43:17 JST


おはようございます.

On 2006/06/13, at 10:29, takaya_kakizaki @ gmx.yamaha.com wrote:
> しかし、受付待ちが解除されたら、自タスクは待ち状態に遷移するので
> wait_completeの戻り値如何に関わらずdispatchを行う必要が 
> あると思うのですが
>
実環境で挙動をみる時間が取れず,コードを目視した
だけでの意見ですが,ご指摘の通りだと思います.
ここは,待ちから別の待ちに遷移する,独特の処理ですので,
他の箇所で使っているイディオムを使ってはいけないはずです.
修正案も妥当だと思います.


以下,dispatch 繋がりの余談です.
すでにお気づきかもしれませんが,del_xxx でも,
ディスパッチのタイミングがおかしいというknown bugが
FI4にはあります.

例えば,semaphore.c / del_sem() では
▼
	/* 待ち行列の後片付け。削除に伴う待ち解除を行う。*/
	while (queue_empty(&(semcb->wait_queue)) == FALSE) {
		TCB *tcb;
		tcb = (TCB *)queue_delete_next(&(semcb->wait_queue));
		t_lock_cpu();
		if (wait_deleted(tcb)) {
			dispatch();
		}
		t_unlock_cpu();	
	}
▲
となっていますが,これでは複数優先度のタスクが待ちに
入っていたときに,解除の順序がおかしくなります.
また,サービスコールの不可分性も守れません.
dispatch_request |= wait_deleted(tcb);
などしておき,出口付近で
if (dispatch_request) dispatch();
と解決すべきです.
(さらにいうと,t_lock_cpu/t_unlock_cpu の位置もおかしい)

--
from もなか