This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]