AW: AW: AW: [ECOS] Blocking restricted in DSRs

[Neundorf, Alexander]

...
> > Ok, and what to do with the variables which are modified and which
> > should be protected by the mutex ?  E.g. if I have a queue which is
> > filled by the DSR, and which is checked by the thread which waits
> > for the signal. Actually I have to ensure that the "take element out
> > of queue" by the thread is protected against the "put element into
> > queue" by the DSR.  Do I have to use cyg_scheduler_lock() in the
> > thread to achieve this ?
> 
> Yes. Take a look at the generic serial driver for an example of how to
> do this.

Ok, I had a look. The generic serial driver doesn't use cyg_sched_lock() (at least I didn't find it). The ipaq kbd driver uses it. It seems I simply have to replace the cyg_mutex_lock()/unlock() functions with cyg_scheduler_lock()/unlock() around the cyg_cond_wait() call.

while (1)                     //thread main loop
{
  cyg_scheduler_lock();
  while (queue.isEmpty())
    cyg_cond_timed_wait(condition);
  Item *i=queue.pop();        //access here or later after cyg_scheduler_unlock() ?
  cyg_scheduler_unlock();     //do I have to call this here or directly before  
                              //cyg_cond_timed_wait() ? but then the event could happen 
                              //between cyg_scheduler_unlock() and cyg_cond_timed_wait() and 
                              //the cyg_cond_timed_wait() would miss the signal ?
  cyg_mutex_unlock(mutex);    //this one should be locked here from looking at the code
  //do something with i
}


But... I had a look at CygCond::wait_inner().
It calls CygSched::lock(), and later CygSched::unlock_reschedule(), and at the end mutex->unlock().
So if I call cyg_scheduler_lock() before cyg_cond_timed_wait(), the scheduler is locked twice but unlocked only once -> still locked. So there must be a point I missed.

Bye
Alex

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