AW: [ECOS] Re: correct handling of condition variables from DSRs

["Neundorf, Alexander" <Alexander dot Neundorf at jenoptik dot com>]

Hi,

> Von: ecos-discuss-owner@ecos.sourceware.org
> 
> "Neundorf, Alexander" <Alexander.Neundorf@jenoptik.com> writes:
> 
> > Hi,
> >
> > the eCos docs say that condition variables can be signalled 
> also from
> > DSRs. Usually, in order to signal a change, the following code is
> > required:
> >
> 
> [...]
> 
> > But since now all three participants (sender from DSR, sender from
> > thread, receiver) are all synchronized using 
> cyg_scheduler_lock(), do
> > I actually still need the mutex at all ? Or can I simply ignore it ?
> 
> No, you can't ignore the mutex as cyg_cond_wait() will unlock 
> the mutex before going to sleep and lock it back after wakeup. This is pure


Ignoring the mutex as in:

Signalling from DSR:

{
   // modify the data
   ...
   cyg_cond_signal(...);
}


Signalling from thread:

{
   cyg_scheduler_lock();
   // modify the data
   ...
   cyg_cond_signal(...);
   cyg_scheduler_unlock();
}


Waiting for the signal:

{
   // lock the mutex once in the beginning so that it can be unlocked and locked again 
   // by the condition variable, although nobody else cares
   cyg_mutex_lock(); 

   // and now the actual mainloop:
   while (1)
   {
      cyg_scheduler_lock();
      cyg_cond_wait(...);
      // check the data
      ...
      cyg_scheduler_unlock();
      // do something more...
   }
}


> overhead in the case of DSR-to-thread synchronization. Special
> simplified version of condition variable that will expect scheduler
> instead of mutex to be locked at wait() could be implemented 
> in eCos to get rid of this overhead, though I've already suggested 
> to do it and didn't receive much interest.

Do you have a patch available ? :-)
Maybe already some tests for Cyg_Condition_Variable::mutex==0 would be good enough ?

Bye
Alex