AW: [ECOS] Re: correct handling of condition variables from DSRs
Sergei Organov
osv@javad.com
Tue May 23 10:39:00 GMT 2006
"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
More information about the Ecos-discuss
mailing list