Re: [ECOS] Blocking restricted in DSRs

Re: [ECOS] Blocking restricted in DSRs

[Neundorf, Alexander]

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

Re: [ECOS] Blocking restricted in DSRs

[Nick Garnett]

"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

Re: [ECOS] Blocking restricted in DSRs

[Gary Thomas]

On Mon, 2004-07-26 at 14:13, Bob Koninckx wrote:
> Things like waiting for a semaphore. Blocking is something you do at
> thread level. The thread "blocks" (or goes to sleep) until another
> thread or interrupt wakes it up again. Basically, this waking up is done
> by the scheduler, which explains why you should not block in a DSR,
> which is called _before_ the scheduler. 
> 

Actually, more importantly, DSR's can't be allowed to block because
they have no thread context of their own (they run anonymously without
any explicit context)

My definition of "blocking" would be any operation which requires 
the current thread to lose control over the CPU.  Examples would be
waiting for resources like semaphores, mutexes, etc.  Any time a thread
has to wait, its context needs to be saved so the CPU can be returned
to the thread when it becomes ready again.  Without a [thread] context,
such waiting is impossible.

> Hope this makes it a little bit clearer,
> 
> Bob
> 
> 
> On Mon, 2004-07-26 at 21:01, Miguel J. Vega wrote:
> > Hi everyone,
> > 
> > I have read that DSRs should not include calling functions that "block".
> > What exactly is meant by "blocking"?
> > 
> > Thanks,
> > 
> > Miguel J. Vega
> > FEGI C&DH Team
> > University of Michigan
-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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

Re: [ECOS] Blocking restricted in DSRs

[Bob Koninckx]

Things like waiting for a semaphore. Blocking is something you do at
thread level. The thread "blocks" (or goes to sleep) until another
thread or interrupt wakes it up again. Basically, this waking up is done
by the scheduler, which explains why you should not block in a DSR,
which is called _before_ the scheduler. 

Hope this makes it a little bit clearer,

Bob


On Mon, 2004-07-26 at 21:01, Miguel J. Vega wrote:
> Hi everyone,
> 
> I have read that DSRs should not include calling functions that "block".
> What exactly is meant by "blocking"?
> 
> Thanks,
> 
> Miguel J. Vega
> FEGI C&DH Team
> University of Michigan


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

[ECOS] Blocking restricted in DSRs

[Miguel J. Vega]

Hi everyone,

I have read that DSRs should not include calling functions that "block".
What exactly is meant by "blocking"?

Thanks,

Miguel J. Vega
FEGI C&DH Team
University of Michigan

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