Are you suggesting that we require priority-based queueing for multiple readers? At the moment the appDevGuide does not specify this requirement, though as you point out, non-priority queueing can lead to priority inversion. The current vxWorks and RTEMS implementations provide FIFO queueing but it would be a one-word change to get them provide priority queueing. Not sure about windows, but since priority inversion is a major issue only for systems with strict priority-based scheduling I'm not sure that it's that big a deal there anyhow.
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. 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.
