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: Jeff Hill <johill@lanl.gov>
To: 'Marty Kraimer' <mrk@aps.anl.gov>, 'Eric Norum' <eric.norum@usask.ca>
Cc: 'Till Straumann' <strauman@SLAC.Stanford.EDU>, "'Johnson, Andrew N.'" <anj@aps.anl.gov>
Date: Wed, 27 Nov 2002 08:52:06 -0700
> On vxWorks I am really afraid of allowing any user thread to be
> higher priority than the network threads. This caused 
> failures in the past.

We have a new vxWorks IP kernel now so it is conceivable that this issue
has been resolved, but even after our regression tests pass I'm not sure
that we know for certain that the problem does not still exist. So the
challenge would be to find a way to test the new configuration on some
heavy loaded, but otherwise non-critical IOCs.

Jeff
 
> -----Original Message-----
> From: Marty Kraimer [mailto:mrk@aps.anl.gov]
> Sent: Wednesday, November 27, 2002 8:40 AM
> To: Eric Norum
> Cc: Jeff Hill; 'Till Straumann'; 'Johnson, Andrew N.'
> Subject: Re: base max thread priority
> 
> Eric Norum wrote:
> 
> > Maybe something like:
> > static const unsigned epicsThreadPriorityIocsh = 91;
> > static const unsigned epicsThreadPriorityNetworkDaemons = 95;
> > static const unsigned epicsThreadPriorityBaseMax = 91;
> <<<Still
> > waiting for you folks to come up with a better name... >>>
> >
> > Then EPICS applications could still have priorities higher
> than the
> > shell but lower than the network daemons, or even priorities
> higher than
> > the network daemons as necessary.
> >
> 
> Why not just have
> 
> 
> static const unsigned epicsThreadPriorityBaseMax = 91;
> 
> Then iocsh could just use this as it's priority.
> 
> epicsThreadPriorityNetworkDaemons doesn't sound like an epics
> base issue. It is
> an OS epecific issue, e.g. it is an RTEMS issue. If we add it
> it will, at least
> for now, be used only for RTEMS. Does it even make sense for
> systems where
> iocCore is running in user space? Thus at leats for now it will
> only apply to RTEMS.
> 
> On vxWorks I am really afraid of allowing any user thread to be
> higher priority
> than the network threads. This caused failures in the past.
> 
> 
> Marty


References:
Re: base max thread priority Marty Kraimer

Navigate by Date:
Prev: RE: base max thread priority 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 
Navigate by Thread:
Prev: Re: base max thread priority Marty Kraimer
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 ·