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: Andrew Johnson <anj@aps.anl.gov>
Cc: Eric Norum <eric.norum@usask.ca>, Marty Kraimer <mrk@aps.anl.gov>, Jeff Hill <johill@lanl.gov>
Date: Tue, 26 Nov 2002 15:24:47 -0800
Andrew Johnson wrote:
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.


... or some other task runs away that owns a resource that the high priority task needs and has its priority raised through inheritance. This is still an issue that the application designer should know about (but beware if that semaphore is hidden behind some OS API...).


Yeah - (although theoretically possible), I consider this rather unlikely. A RT critical task should only share very 'fast' resources (i.e. objects that are mutexed for very few lines of code [low runaway error probability]) with a low priority task. A high priority, RT critical task who operates on/shares complex resources (doing things e.g. like printf, malloc or networking) is probably ill-designed.

It might seem prudent to have a control character in the console port's ISR that can raise the shell's priority in an emergency - I remember we discussed this idea round the table at JLAB anyway.

Sure - that would be nifty and doable under RTEMS - but what to do under vxWorks? Another problem is that such a solution is probably highly BSP specific.

OTOH - rather than building a generic solution into the console ISR [for
multiple OSes/BSPs] that burden could be off-loaded to the user who really needs the high priority task. For the particular board/OS he/she uses it's easy to use any IRQ (e.g. a serial line, an onboard switch or a watchdog) to suspend the critical task on request.


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.


From past experience with vxWorks, you probably do not want your console to be below the network tasks in case nasty things happen that can lock you out and prevent any chance of debugging.

That makes sense to me.

IIRC, in vxWorks the only tasks higher than tShell handle message logging and system callbacks from exceptions (things that can't be done in ISR context).

- Andrew



References:
Re: base max thread priority Eric Norum

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