For my particular application I do require priority scheduling of multiple writers on PREEMPT_RT Linux. As Till mentioned moving to a single pthread condition variable per queue empty/full would give this (depending on the scheduling policy) and also remove the need for dynamic memory allocation in the implementation, whether this is a desirable default semantics for Linux is another matter. I would say yes. From: Eric Norum [mailto:[email protected]] Sent: 31 January 2011 16:13 To: Rowland, James (DLSLtd,RAL,DIA) Cc: EPICS Tech Talk Subject: Re: epicsEvent (posix implementation) bug ? 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.
--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
|