Experimental Physics and
Industrial Control System

Till Straumann <[email protected]> · Mon, 31 Jan 2011 09:30:48 -0600

On 01/31/2011 03:16 AM, [email protected] 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: [email protected] [mailto:tech-talk-
[email protected]] 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System