| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 <2011> 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 <2011> 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: epicsMessageQueue Linux PREEMPT_RT |
| From: | Till Straumann <[email protected]> |
| To: | [email protected] |
| Date: | Fri, 28 Jan 2011 12:22:49 -0600 |
On 01/28/2011 11:29 AM, Andrew Johnson wrote:
Hi James, On Friday 28 January 2011 10:16:45 you wrote:The PREEMPT_RT patch makes the kernel fully pre-emptive (leading to improved maximum latency) and adds support for priority inheritance mutexes. There are no user space API changes, the code to use _POSIX_THREAD_PRIORITY_SCHEDULING and _POSIX_THREAD_PRIO_INHERIT is already in libCom (if disabled by default). I'd like to use the epicsMessageQueue from a high priority thread but the send and receive functions may calloc an eventNode, and that might cause a page fault or block my thread on the malloc lock. I'd like to be able to pre-allocate the eventNodes because I know the maximum number of threads that may wait on the queue in advance.Thanks; after looking at the code I see that could be tricky. However it looks like if you could arrange for all your reading threads to wait for a message at startup (with the queue empty) they will each call getEventNode() and hence allocate the necessary number of eventNode objects. After they're all waiting on the queue you would release them all by sending the requisite number of messages through the queue from the initializing thread. I think that should work with the existing API, but I've not actually tried it.
Yes. But that's a hack (the user must know some implementation details of message queues). IMHO the default implementation (RTEMS and
probably vxWorks are OK) could be improved.
We probably should add a routine to the API to allow the eventFreeList to be pre-allocated, but you probably want to be able to run on existing versions of Base.
I'd consider such a routine a bit 'hackish'. I'd vote for improving the implementation. Of course, that would not be retroactive and your
recommendation above could be used as a work-around on older versions. - Till
Eric — unless you stole the code from someone else you were the author of all the *MessageQueue.* files, 'bzr log' does not lie... - Andrew