EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== 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


Replies:
Re: epicsMessageQueue Linux PREEMPT_RT Eric Norum
References:
epicsMessageQueue Linux PREEMPT_RT james.rowland
Re: epicsMessageQueue Linux PREEMPT_RT Andrew Johnson
RE: epicsMessageQueue Linux PREEMPT_RT james.rowland
Re: epicsMessageQueue Linux PREEMPT_RT Andrew Johnson

Navigate by Date:
Prev: Re: ca_create_channel memory management pthomas
Next: Re: ca_create_channel memory management Tim Mooney
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: epicsMessageQueue Linux PREEMPT_RT james.rowland
Next: Re: epicsMessageQueue Linux PREEMPT_RT Eric Norum
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·