Re: epicsEvent

[Ben Franksen <ben.franksen@online.de>]

On Freitag, 29. Oktober 2010, Ralph Lange wrote:
>   The RTEMS implementation does a "wake up one", consistent with the
> other implementations.
>
> Maybe the current set of OSI primitives is not sufficient?
>
> I definitely see Benjamin's point, and having a "wake up all" in
> addition to the current "wake up one", and/or making the "wake up
> one" configurable to select FIFO or priority behaviour could be
> useful.

This would be useful, but it was not my point :-)

I just need to know what I can expect from the interface. The wording in 
the docs was so that if I take it literally, I would have to make 
efforts to *avoid* more than one task waiting for the same event, 
because the behaviour in this case is completely unspecified. I doubt 
that this was the intention, and the answers so far seem to indicate 
that, indeed, an epicsEvent should behave as binary semaphore.

Regarding the choice of which task will get the semahore if more than 
one is waiting, I will for now assume that this is (intentionally) left 
unspecified. This means I will have to implement FIFO order on top of 
epicsEvent. The only other solution would be to extend the interface 
with another constructor and then implement FIFO order *inside* 
epicsEvent for those systems that do not support that natively (which 
is what you wrote above, so maybe you *did* get the point I was trying 
to make and I didn't get yours. Whatever ;-).

Cheers
Ben
-- 
"Never confuse what is natural with what is habitual."
                                   -- attributed to Mahatma Gandhi