Re: epicsEvent (posix implementation) bug ?

[Till Straumann <strauman@slac.stanford.edu>]

On 01/31/2011 03:16 AM, james.rowland@diamond.ac.uk wrote:
> Removing the thread wakeup FIFO and sharing the wakeup event is
> essential for correct scheduling behaviour otherwise a low priority
> thread can block a high priority thread on a message queue read even
> with priority inheritance enabled.

Of course. But that would change the current semantics (which I
don't necessarily like) from a FIFO to a priority based policy  -
which I also think would be preferable - in addition you need
less resources and do away with the issue that started this
thread. So it's kind of a 'win-win' situation.

t.

EpicsEvent will also need patching to
> enable PTHREAD_PRIO_INHERIT, the code is present in EpicsMutex but
> EpicsEvent initializes a pthread_mutex directly. I'll nominate this as a
> job for the codeathon.
>
> > -----Original Message-----
> > From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-
> > bounces@aps.anl.gov] On Behalf Of Till Straumann
> > Sent: 29 January 2011 01:57
> > To: EPICS Techtalk
> > Subject: epicsEvent (posix implementation) bug ?
> >
> > If multiple threads block on the same event then the current
> > implementation (posix) may spuriously wake up more than one thread as
> a
> > result of epicsEventSignal().
> >
> > This is because the underlying
> > pthread_cond_signal()/pthread_cond_wait()
> > explicitly have these same semantics.
> >
> > IMO it would be a good idea to change epicsEventWait and
> > epicsEventWaitWithTimeout so that they handle this possible case (and
> > yield the same semantics as the RTEMS and vxWorks variants).
> >
> > -- Till