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: Jeff Hill <johill@lanl.gov>, 'Marty Kraimer' <mrk@aps.anl.gov>, "'Johnson, Andrew N.'" <anj@aps.anl.gov>
Date: Tue, 26 Nov 2002 19:54:52 -0800
Eric Norum wrote:

On Tuesday, November 26, 2002, at 06:09  PM, Till Straumann wrote:

Here's yet another idea how the runaway-task problem could be solved.

AFAIK, most OS provide a hook into the system timer ISR but not
into the console ISR [which makes what we discussed at JLAB less portable] - these hooks are vxWorks' watchdog timers, RTEMS' rtems_timers.

1) The shell task periodically resets (pets) a 'watchdog' counter.


How would this mesh with libtecla/libreadline? The shell task spends most of its time blocked in these libraries waiting for input. How could it reset the watchdog timer? (First person that says 'select' gets a big raspberry from me!!!!)

It was only a _sketch_ not an implementation proposal.

In a real implementation you would have a dedicated task doing the petting rather than hacking the shell.
That task would get its priority raised by the ISR and it would
in turn propagate its new priority to the shell. (Again, this is not
a real/detailed implementation design [e.g. it's not documented whether it is safe for RTEMS ISRs to change task priorities].)

Anyways, the hi-priority task runaway protection business is IMO unnecessary. These specialized tasks should be fairly simple and
runaway programming errors rare and easy to find.

What about this other issue: what was the reason for not making the
OS' full range of priorities available to EpicsThreads? After all,
having the 92..100 window available doesn't really help if there
are system tasks out there at 150... Handling priorities in a
hard-RT-OSI way is not entirely trivial, it seems.

-- Till



2) A timer ISR increments 'watchdog'. Should 'watchdog' reach a critical
   'limit', this implies that the shell had no chance to pet.
   In this case, the ISR increments the task's priority and resets
   'watchdog'.

If a task with a priority > shell runs away, 2) will eventually raise
the shell's priority above the runaway task's and the user will regain control.






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 Marty Kraimer
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 Marty Kraimer
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 ·