EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

<20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: base max thread priority
From: Eric Norum <[email protected]>
To: Marty Kraimer <[email protected]>
Cc: Jeff Hill <[email protected]>, 'Till Straumann' <[email protected]>, "'Johnson, Andrew N.'" <[email protected]>
Date: Wed, 27 Nov 2002 08:59:46 -0600

On Wednesday, November 27, 2002, at 06:36  AM, Marty Kraimer wrote:

This is a comment about vxWorks and a question about RTEMS.

On vxWorks the following is done:

/* Just map osi 0 to 99 into vx 100 to 199 */
/* remember that for vxWorks lower number means higher priority */
/* vx = 100 + (99 -osi)  = 199 - osi*/
/* osi =  199 - vx */


Since the network tasks, etc all have vxWorks priorities < 100 there is no chance an epics thread can be created with a priortity > important vxWorks threads.

What is the range of priorities for RTEMS?

1 to 255  (1 highest, 255 lowest).  Just like vxWorks.


Comment. It seem to me that a system with severe real time requirements should not use BSD style networking. But I guess that the key to implementing severe real time systems is to carefully decide what it must do and don't let it do anything else.

When I ported the BSD network stack to RTEMS I was very careful to ensure that the network routines would work properly even when called from, or used in the presence of, tasks at lower, equal, or higher priority. I think that it's entirely reasonable for an application to have tasks at a higher priority than the network tasks. As long as the higher priority tasks yield enough of the processor to get network work done and as long as the higher priority tasks make no network calls (or are aware that they may block when doing so) there will be no problems. I can think of lots of closed-loop feedback control applications that would work very well in this mode.

Maybe something like:
static const unsigned epicsThreadPriorityIocsh = 91;
static const unsigned epicsThreadPriorityNetworkDaemons = 95;
static const unsigned epicsThreadPriorityBaseMax = 91; <<<Still waiting for you folks to come up with a better name... >>>

Then EPICS applications could still have priorities higher than the shell but lower than the network daemons, or even priorities higher than the network daemons as necessary.

--
Eric Norum <[email protected]>
Department of Electrical Engineering
University of Saskatchewan
Saskatoon, Canada.
Phone: (306) 966-5394   FAX:   (306) 966-5407


Replies:
Re: base max thread priority Marty Kraimer
RE: base max thread priority Jeff Hill
Re: base max thread priority Till Straumann
References:
Re: base max thread priority Marty Kraimer

Navigate by Date:
Prev: Gateway Marty Kraimer
Next: Re: Gateway Ned D. Arnold
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: base max thread priority Marty Kraimer
Next: Re: base max thread priority Marty Kraimer
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·