This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Blocking restricted in DSRs
- From: "Neundorf, Alexander" <Alexander dot Neundorf at jenoptik dot com>
- To: "Nick Garnett" <nickg at ecoscentric dot com>, <ecos-discuss at sources dot redhat dot com>
- Date: Tue, 27 Jul 2004 17:20:15 +0200
- Subject: Re: [ECOS] Blocking restricted in DSRs
> > while (1) //thread main loop
> > {
> > cyg_drv_dsr_lock(); //does the order of the dsr_lock()
> and mutex_lock() calls matter ?
> > cyg_mutex_lock(mutex);
> > while (queue.isEmpty())
> > cyg_cond_timed_wait(condition);
> > Item *i=queue.pop();
> > cyg_mutex_unlock(mutex);
> > cyg_drv_dsr_unlock();
> > //do something with i
> > ...
> > }
>
> Yep, that's the sort of thing you need to do. In general the regions
> during which cyg_drv_dsr_lock() is used should be kept as small as
> possible. In the above example it makes little difference, but if
> there is work that can be done with just the mutex locked, then that
> should be done before calling cyg_drv_dsr_lock().
Ok, seems to work.
Nevertheless I had another look at the code.
For ecos with kernel cyg_drv_dsr_lock() is #defined to cyg_scheduler_lock().
So the scheduler should be locked.
I didn't find the line of code which unlocks the scheduler again, it must be in Cyg_Condition_Variable::wait_inner(), ain't it ?
Otherwise the scheduler would be locked as long as the thread is inside cyg_cond_timed_wait() and no other thread could ever send the signal.
I must be missing something..
Bye
Alex