Experimental Physics and
Industrial Control System

Till Straumann <[email protected]> · Tue, 26 Nov 2002 14:49:10 -0800

Eric Norum wrote:

On Tuesday, November 26, 2002, at 04:03  PM, Till Straumann wrote:

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.

Yes, running the shell at EPICS priority 91 seems reasonable.

Now another question. RTEMS, and I expect vxWorks as well, have system

tasks handling things like network I/O. What priority should these run

at? At the moment I've got the RTEMS network tasks at higher than the

highest EPICS task priority. From the above discussions it would seem

that running the network tasks at an RTEMS priority equivalent to EPICS

task priority 91 would be the right thing to do.

Comments?

Hmm - a very good point. There might also be other RTEMS system/driver

tasks. I'm just wondering whether confining the epics accessible

priority range to a subrange of the RTEMS/vxWorks priorities is a good

solution? Having this restriction, a RT critical task may still not

be able to use the EPICS OSI thread API to obtain the priority it needs...

BTW - Eric, I believe that the RTEMS interrupt message logger also runs
at the highest EPICS priority which is probably not really necessary.

-- Till

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System