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

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

[Neundorf, Alexander]

> -----Ursprüngliche Nachricht-----
> Von: ecos-discuss-owner@ecos.sourceware.org
> [mailto:ecos-discuss-owner@ecos.sourceware.org]Im Auftrag von 
> Neundorf,
> Alexander
> Gesendet: Dienstag, 27. Juli 2004 12:44
> An: Nick Garnett; ecos-discuss@sources.redhat.com
> Betreff: AW: AW: AW: [ECOS] Blocking restricted in DSRs
> 
> 
> 
> ...
> > > 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). 

Well, it's not in devs/serial/generic, but in io/serial/current.
So I guess I finally found it:

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

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

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

[Nick Garnett]

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

> > -----Ursprüngliche Nachricht-----
> > Von: ecos-discuss-owner@ecos.sourceware.org
> > [mailto:ecos-discuss-owner@ecos.sourceware.org]Im Auftrag von 
> > Neundorf,
> > Alexander
> > Gesendet: Dienstag, 27. Juli 2004 12:44
> > An: Nick Garnett; ecos-discuss@sources.redhat.com
> > Betreff: AW: AW: AW: [ECOS] Blocking restricted in DSRs
> > 
> > 
> > 
> > ...
> > > > 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). 
> 
> Well, it's not in devs/serial/generic, but in io/serial/current.
> So I guess I finally found it:

Sorry, yes, I was a little unspecific there.

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


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

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