<2002> 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | <2002> 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: base max thread priority |
From: | Till Straumann <[email protected]> |
To: | Eric Norum <[email protected]> |
Cc: | Marty Kraimer <[email protected]>, "Johnson, Andrew N." <[email protected]>, Jeff Hill <[email protected]> |
Date: | Tue, 26 Nov 2002 14:03:56 -0800 |
Eric Norum wrote:
On Tuesday, November 26, 2002, at 02:25 PM, Marty Kraimer wrote:(2) -- I think we did this to ensure that you could still get some response at the console even if some other task went insane and started gobbling CPU cycles. With a strict priority-based scheduler like RTEMS and vxWorks you'd have no possiblity of dealing with such tasks if the shell were at a lesser or equal priority.At the EPICS meeting last week Till asked: 1) Could we declare a maximum priority for any component of base? 2) Why does iocsh run at epicsThreadPriorityMax? Brief discussion. 1) sounds like a good request. How about epicsThreadPriorityBaseMax = 912) I will assume that this was done to be like vxWorks, which runs the vxWorks shell at highest priority. If iocsh runs at epicsThreadPriorityBaseMax it seems like it should be OK. If a very high prority application thread uses all the CPU time iocsh can't get control but this is the applications problem.
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.
-- Till