Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Wed, 22 Feb 2012 15:37:59 -0600

Hi Goetz,

On 2012-02-22 Goetz Pfeiffer wrote:
> 
> However, the intention of EPICS OSI is that I don't have to do that. If
> there was a possibility to
> specify the thread priority directly, I wouldn't have to include system
> headers or call system functions
> directly. 

We give you the ability to set thread priorities, but your problem is that the 
range of OS priorities we allow you to use is narrower than you want.  I'm not 
sure why you need to go outside of the standard range, but it has to be due to 
interaction with some other software which is not using the OSI APIs to set 
its thread priorities.  Our APIs provide an abstraction of the underlying OS 
API and as long as you stay within our model the abstraction is sufficient, 
but in your case the outside world is leaking into our model.

Adding an OS-specific thread priority argument to our API would make it easier 
for you to do what you need, but doing so pollutes our abstract model, and I 
prefer to try and preserve that model.

> If EPICS OSI was changed or extended, my code would look like
> this:
> 
> #if defined(vxWorks)
>    #define GPS_WRITER_PRIO 67
> #elif defined(RTEMS)
>    #define GPS_WRITER_PRIO 123
> #endif
> 
> epicsThreadCreate("mC Writer", GPS_WRITER_PRIO,
>                    epicsThreadGetStackSize(epicsThreadStackSmall),
>                    (EPICSTHREADFUNC) gps_writer, NULL))
> 
> Isn't this nicer than having to call taskPrioritySet or
> rtems_task_set_priority directly as
> in your quoted mail below ?

If you want the C source to look nice you could put this into a header file 
instead:

#if defined(vxWorks)
    #include <taskLib.h>
    #define setWriterThreadPriority taskPrioritySet(0, 67)
#elif defined(RTEMS)
    #include "rtems.h"
    #define setWriterThreadPriority do { \
        rtems_task_priority old; \
        rtems_task_set_priority(RTEMS_SELF, 123, &old); \
    } while (0)
#else
    #define setWriterThreadPriority (void) 0
#endif

Now your gps_writer function just has to add this line:

setWriterThreadPriority;

> The way epicsThreadCreate in EPICS OSI handles priorities at least in
> the vxWorks and RTEMS
> implementation seems to be a design flaw for me. Why not fix it ?

That is only true if you expect the API to be able to create threads at all of 
the underlying OS priority levels.  The OSI abstract model doesn't support 
that on vxWorks or RTEMS because we don't want our applications to use 
inappropriate task priorities — we have had problems here at APS in the past 
with tasks running above tNetTask for example, and this model was deliberately 
designed to make that harder to do.  If you want to go outside our supported 
priorities you can, but not using the epicsThread API.

Note that Klemen Zagar's issue about the mapping between OSI and Posix 
priority values was fixed in R3.14.12.2, and on Posix architectures we do now 
make the full OS priority range available since a single process can't crash 
the whole machine.  I am still interested in some of Klemen's changes, but not 
the epicsThreadSetPosixPriority...() functions.

- Andrew
-- 
Optimization is the process of taking something that works and
replacing it with something that almost works, but costs less.
-- Roger Needham

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System