[ECOS] correct handling of condition variables from DSRs

[ECOS] correct handling of condition variables from DSRs

[Neundorf, Alexander]

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:

cyg_mutex_lock(&condition_mutex)
// ... modify the data
cyg_cond_signal(&condition_var);
cyg_mutex_unlock(&condition_mutex);


When doing this from a DSR, the mutex can't be locked, so I only can do:

cyg_cond_signal(&condition_var);


In order to receive the signal, usually I would:

cyg_mutex_lock(...);
cyg_cond_wait(...);
...
cyg_mutex_unlock();


Now this isn't synchronized with the DSR. The mutex docs say that cyg_scheduler_lock() has to be used, so it becomes:

cyg_scheduler_lock();
cyg_mutex_lock(...);
cyg_cond_wait(...);
...
cyg_mutex_unlock();
cyg_scheduler_unlock();

But the same protection has to be used when signalling from a thread, since otherwise the DSR could modify the data which are only protected by the mutex, right ?
So in order to signal the condition correctly from a thread I have to do the following:

cyg_scheduler_lock();
cyg_mutex_lock(&condition_mutex)
// ... modify the data
cyg_cond_signal(&condition_var);
cyg_mutex_unlock(&condition_mutex);
cyg_scheduler_unlock();


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 ?

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

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

[Sergei Organov]

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

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

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

[Fabian Scheler]

Hello,

> This is pure overhead in the case of DSR-to-thread synchronization.

so, why don't you use a semaphore?

Ciao, Fabian

--
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: [ECOS] Re: correct handling of condition variables from DSRs

[Sergei Organov]

"Fabian Scheler" <fabian.scheler@gmail.com> writes:

> Hello,
>
>> This is pure overhead in the case of DSR-to-thread synchronization.
>
> so, why don't you use a semaphore?

Did I say I don't? Though semaphore is a poor man replacement for an
optimized primitive with exact semantics required for particular purpose
that is currently missing in eCos. Please notice that semaphore's
internal counter is pure overhead as well, though admittedly it's less
than those of mutex having both state variable and a wait queue.

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

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

[Fabian Scheler]

> Did I say I don't? Though semaphore is a poor man replacement for an
> optimized primitive with exact semantics required for particular purpose
> that is currently missing in eCos. Please notice that semaphore's
> internal counter is pure overhead as well, though admittedly it's less
> than those of mutex having both state variable and a wait queue.

ok, I agree - something like OSEK events is missing in eCos

Ciao, Fabian

--
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: [ECOS] Re: correct handling of condition variables from DSRs

[Sergei Organov]

"Fabian Scheler" <fabian.scheler@gmail.com> writes:

>> Did I say I don't? Though semaphore is a poor man replacement for an
>> optimized primitive with exact semantics required for particular purpose
>> that is currently missing in eCos. Please notice that semaphore's
>> internal counter is pure overhead as well, though admittedly it's less
>> than those of mutex having both state variable and a wait queue.
>
> ok, I agree - something like OSEK events is missing in eCos

Sorry, I don't believe events are suitable replacement for condvars:

1. To avoid race conditions between event signalling, condition change,
   and condition check, one will need to disable scheduling anyway, and
   events aren't designed to be used only while scheduler is disabled,
   so they will do scheduler lock/unlock themselves anyway that is pure
   overhead once again.

2. Events are to be sent to particular thread, -- this could decrease
   decoupling as well as increase overhead and complexity. For example,
   should you need to signal a condition to multiple threads, you will
   need to have a thread that will receive event from DSR and then
   signal condition variable to the rest of the world.

Once again, kind of condvar expecting scheduler lock instead of mutex
lock seems to be the best abstraction one can get for DSR-to-thread(s)
synchronization.

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