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

Subject: Re: base max thread priority
From: Eric Norum <[email protected]>
To: Marty Kraimer <[email protected]>
Cc: Till Straumann <[email protected]>, Jeff Hill <[email protected]>, "'Johnson, Andrew N.'" <[email protected]>
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 <[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 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  2021  2022 
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  2021  2022 
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 ·