Re: [ECOS] Blocking restricted in DSRs

[Nick Garnett <nickg at ecoscentric dot com>]

"Neundorf, Alexander" <Alexander.Neundorf@jenoptik.com> writes:

> > > 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..

Threads can call blocking functions with the scheduler locked. The
lock is essentially a per-thread variable so when the thread is
resumed the lock is returned to its former value.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss