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

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

[Neundorf, Alexander]

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
	

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

[Sergei Organov]

"Neundorf, Alexander" <Alexander.Neundorf@jenoptik.com> writes:
> 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...
>    }
> }

Yes, I believe this will work as expected. Except that wait() and data
check should usually be put into a loop by themselves.

>> 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 ? :-)

No, though technically it's trivial. One thing is that I didn't come up
with a good name for the primitive :)

> Maybe already some tests for Cyg_Condition_Variable::mutex==0 would be
> good enough ?

Basically that's it, but I'm not sure it's a good idea to add overhead
of checking for 0 to every use of the condvar, so another primitive that
is Cyg_Condition_Variable with all the mutex stuff and scheduler
lock/unlock removed could be better idea.

-- 
Sergei.

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