Experimental Physics and Industrial Control System
It seems that you could discuss that, at least on RTEMS, the scan
threads might run above the RTEMS network threads in priority because
the EPICS scan threads do not call directly into the network stack, and
their periodicity should perhaps not be disturbed by network loading.
Jeff
> -----Original Message-----
> From: Eric Norum [mailto:[email protected]]
> Sent: Wednesday, November 27, 2002 8:00 AM
> To: Marty Kraimer
> Cc: Jeff Hill; 'Till Straumann'; 'Johnson, Andrew N.'
> Subject: Re: base max thread priority
>
>
> On Wednesday, November 27, 2002, at 06:36 AM, Marty Kraimer
> wrote:
>
> > This is a comment about vxWorks and a question about RTEMS.
> >
> > On vxWorks the following is done:
> >
> > /* Just map osi 0 to 99 into vx 100 to 199 */
> > /* remember that for vxWorks lower number means higher
> priority */
> > /* vx = 100 + (99 -osi) = 199 - osi*/
> > /* osi = 199 - vx */
> >
> >
> > Since the network tasks, etc all have vxWorks priorities <
> 100 there
> > is no chance an epics thread can be created with a priortity
> >
> > important vxWorks threads.
> >
> > What is the range of priorities for RTEMS?
>
> 1 to 255 (1 highest, 255 lowest). Just like vxWorks.
>
> >
> > Comment. It seem to me that a system with severe real time
> > requirements should not use BSD style networking. But I guess
> that the
> > key to implementing severe real time systems is to carefully
> decide
> > what it must do and don't let it do anything else.
>
> When I ported the BSD network stack to RTEMS I was very careful
> to
> ensure that the network routines would work properly even when
> called
> from, or used in the presence of, tasks at lower, equal, or
> higher
> priority. I think that it's entirely reasonable for an
> application to
> have tasks at a higher priority than the network tasks. As
> long as the
> higher priority tasks yield enough of the processor to get
> network work
> done and as long as the higher priority tasks make no network
> calls (or
> are aware that they may block when doing so) there will be no
> problems.
> I can think of lots of closed-loop feedback control
> applications that
> would work very well in this mode.
>
> 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.
>
> --
> Eric Norum <[email protected]>
> Department of Electrical Engineering
> University of Saskatchewan
> Saskatoon, Canada.
> Phone: (306) 966-5394 FAX: (306) 966-5407
- 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 Marty Kraimer
- Next:
RE: base max thread priority Jeff Hill
- Index:
<2002>
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: base max thread priority Jeff Hill
- Next:
Re: base max thread priority Eric Norum
- Index:
<2002>
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024