Re: base max thread priority

[Marty Kraimer <mrk@aps.anl.gov>]

Eric Norum wrote:
> On Wednesday, November 27, 2002, at 03:17  PM, Till Straumann wrote:
>
> > Again: IMO, EPICS should have the _full_ range of OS priorities 
> > available.
> > Part of the job of porting EPICS to a particular OS would be assigning
> > the actual values of basic EPICS priorities (like 
> > epicsThreadPriorityIocsh, epicsThreadPriorityBaseMin, 
> > epicsThreadPriorityBaseMax...).
> > It's absurd: I use EPICS on a real-time OS but have no access to the
> > priorities needed to get real-time performance when I use the 
> > epicsThread API ;-)

I have mixed feelings. Again in the past when we created tasks with higher 
priority than netTask we got failures.

I do see that it is impossible on vxWorks to create a thread with a priority < 
100. Thus it is not possible to create a thread with priority > tNetTask.

What to do????

If user really wants a thread with higher priority than tNetTask he/she could do 
what Eric suggests and change the priority of tNetTask.


> Is 100 levels not enough?  If priorities 91-99 were reserved for 
> application threads only would it not be possible to do what you need?
>
> I think that it's better to coerce other system tasks into the EPICS 
> range if appropriate since it makes moving a given EPICS application 
> from one processor to another so much easier.

Sounds good to me.

> I think that the 'base max' (I'm still hoping that someone can come up 
> with a good name for this) priority level (90, right???) should be added 
> to epicsThread.h.

Could we just define

static const unsigned epicsThreadPriorityIocsh = 91;

And then state that nothing in base has a priority higher than 
epicsThreadPriorityIocsh?

If this is not OK I can't think of a better name than
epicsThreadPriorityBaseMax

I dont see any reason to define epicsThreadPriorityNetworkDaemons. The only 
operating system that will currently use it is RTEMS.


Marty