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: Till Straumann <strauman@SLAC.Stanford.EDU>
To: Eric Norum <eric.norum@usask.ca>
Cc: Marty Kraimer <mrk@aps.anl.gov>, "Johnson, Andrew N." <anj@aps.anl.gov>, Jeff Hill <johill@lanl.gov>
Date: Tue, 26 Nov 2002 14:49:10 -0800
Eric Norum wrote:

On Tuesday, November 26, 2002, at 04:03  PM, Till Straumann wrote:


Correct - but this could only happen if the insane task had a priority > 91. However, if the user were to spawn a task with this high a priority, he/she probably knew what he/she was doing: that task was probably hard-rt critical and it was not tolerable to have it wait for whatever
was going on at the console.

IMO, clamping everyghing to < 91 with the shell running at 91 is safe
- no runaway (base) task can lock the console. However, the user still has the option of doing really critical work at a higher priority, if necessary - at the risk of having a locked-up system should such a > task
run away, of course.
The benefit of leaving a range of priorities to the user IMO far outweighs the possible damage.


Yes, running the shell at EPICS priority 91 seems reasonable.
Now another question. RTEMS, and I expect vxWorks as well, have system tasks handling things like network I/O. What priority should these run at? At the moment I've got the RTEMS network tasks at higher than the highest EPICS task priority. From the above discussions it would seem that running the network tasks at an RTEMS priority equivalent to EPICS task priority 91 would be the right thing to do.
Comments?


Hmm - a very good point. There might also be other RTEMS system/driver tasks. I'm just wondering whether confining the epics accessible priority range to a subrange of the RTEMS/vxWorks priorities is a good solution? Having this restriction, a RT critical task may still not
be able to use the EPICS OSI thread API to obtain the priority it needs...

BTW - Eric, I believe that the RTEMS interrupt message logger also runs
at the highest EPICS priority which is probably not really necessary.

-- Till


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

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