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

[Sergei Organov <osv at javad dot com>]

"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