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

[Sergei Organov <osv at javad dot com>]

"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