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: Marty Kraimer <mrk@aps.anl.gov>
To: Eric Norum <eric.norum@sasktel.net>
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:11:44 -0600
Eric Norum wrote:

On Wednesday, November 27, 2002, at 03:17  PM, Till Straumann wrote:


Again: IMO, EPICS should have the _full_ range of OS priorities available.
Part of the job of porting EPICS to a particular OS would be assigning
the actual values of basic EPICS priorities (like epicsThreadPriorityIocsh, epicsThreadPriorityBaseMin, epicsThreadPriorityBaseMax...).
It's absurd: I use EPICS on a real-time OS but have no access to the
priorities needed to get real-time performance when I use the epicsThread API ;-)


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

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.



Is 100 levels not enough? If priorities 91-99 were reserved for application threads only would it not be possible to do what you need?

I think that it's better to coerce other system tasks into the EPICS range if appropriate since it makes moving a given EPICS application from one processor to another so much easier.

Sounds good to me.

I think that the 'base max' (I'm still hoping that someone can come up with a good name for this) priority level (90, right???) should be added to epicsThread.h.

Could we just define

static const unsigned epicsThreadPriorityIocsh = 91;

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

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

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


Marty


Replies:
Re: base max thread priority Eric Norum
References:
Re: base max thread priority Eric Norum

Navigate by Date:
Prev: [no subject] Jeff Hill
Next: Re: base max thread priority Eric Norum
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 Eric Norum
Next: Re: base max thread priority Eric Norum
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 ·