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  Index <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: base max thread priority
From: Eric Norum <eric.norum@sasktel.net>
To: Marty Kraimer <mrk@aps.anl.gov>
Cc: Till Straumann <strauman@SLAC.Stanford.EDU>, Jeff Hill <johill@lanl.gov>, "'Johnson, Andrew N.'" <anj@aps.anl.gov>
Date: Mon, 02 Dec 2002 09:45:45 -0600

On Monday, December 2, 2002, at 09:11  AM, Marty Kraimer wrote:


I have mixed feelings. Again in the past when we created tasks with higher priority than netTask we got failures.

I'm confident that RTEMS has no problems (other than possible CPU starvation) with running application tasks at an equal or higher priority than the network tasks.


I do see that it is impossible on vxWorks to create a thread with a priority < 100. Thus it is not possible to create a thread with priority > tNetTask.

What to do????

If user really wants a thread with higher priority than tNetTask he/she could do what Eric suggests and change the priority of > tNetTask.

In fact I plan to commit a change today to run the network tasks at a priority just less than the lowest-priority scan task. This will make the scan times much more deterministic.


Could we just define

static const unsigned epicsThreadPriorityIocsh = 91;

And then state that nothing in base has a priority higher than epicsThreadPriorityIocsh?

I'm not sure that the side issue has been dealt with. I would argue , and I think Till would agree, that the IOC shell should also run at a priority less than the scan tasks to ensure the determinism of the scan tasks.


If this is not OK I can't think of a better name than
epicsThreadPriorityBaseMax

I'd rather use that name, as poor as it is, than assign any particular priority to epicsThreadPriorityIocsh.


I dont see any reason to define epicsThreadPriorityNetworkDaemons. The only operating system that will currently use it is RTEMS.

I agree.
I plan to set the RTEMS network tasks priority to: epicsThreadGetOssPriorityValue(epicsThreadHighestPriorityBelow(epicsThre adPriorityScanLow))
unless the application developer specifies otherwise.

--
Eric Norum <eric.norum@usask.ca>
Department of Electrical Engineering
University of Saskatchewan
Saskatoon, Canada.
Phone: (306) 966-5394   FAX:   (306) 966-5407


Replies:
Re: base max thread priority Andrew Johnson
Re: base max thread priority Marty Kraimer
References:
Re: base max thread priority Marty Kraimer

Navigate by Date:
Prev: Re: base max thread priority Marty Kraimer
Next: CROSS_COMPILER_TARGET_ARCHS default change Janet Anderson
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: base max thread priority Marty Kraimer
Next: Re: base max thread priority Andrew Johnson
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
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 ·