EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Problems with priorities in epicsThreadCreate (part of the EPICS OSI software layer)
From: Goetz Pfeiffer <[email protected]>
To: <[email protected]>
Date: Mon, 20 Feb 2012 14:01:21 +0100
Hello everybody,

we have run into a problem with epicsThreadCreate: under vxWorks we cannot create a new thread with the priority we need. With the current implementation it's impossible.
We use EPICS 3.14.12.2.

Introduction

In our efforts to port our CAN bus device support from vxWorks to RTEMS we have had to replace all direct vxWorks calls with calls to the operating system independent EPICS OSI software layer.

In order to create a new thread (in vxWorks a task) we now have to call epicsThreadCreate. This function creates a new thread with a given priority and stack size.

In it's implementation epicsThreadCreate converts the priority parameter to a priority for the current operating system before it calls the system to actually create the new thread.

The problem is that the implementation of epicsThreadCreate for vxWorks and RTEMS doesn't cover all possible priorities vxWorks and RTEMS. For example in our application we need vxWorks task priority 67 and this simply isn't possible with the current implementation of epicsThreadCreate.

Here is what I found by looking into the EPICS base:

Overview of the implementations of epicsThreadCreate



This is the implementation of the used conversion in vxworks (file libCom/osi/os/vxWorks/osdThread.c):

static int getOssPriorityValue(unsigned int osiPriority)
{
    if ( osiPriority > 99 ) {
        return 100;
    }
    else {
        return ( 199 - (signed int) osiPriority );
    }
}

This is the implementation of the used conversion for RTEMS (file libCom/osi/os/RTEMS/osdThread.c):

int epicsThreadGetOssPriorityValue(unsigned int osiPriority)
{
    if (osiPriority > 99) {
        return 100;
    }
    else {
        return (199 - (signed int)osiPriority);
    }
}


The implementation for POSIX (file libCom/osi/os/posix/osdThread.c) is a bit longer and seems to leave the priority parameter unchanged.

The implementation for WIN32 (file libCom/osi/os/WIN32/osdThread.c) seems to do a conversion, but is much more complicated than the one for vxWorks and RTEMS.


The Problem

As you can see, it is impossible to get a vxWorks priority below 100. However, this is what we need for our application (we may also need it on RTEMS).

A temporary fix

As a temporary solution I have added the function

epicsThreadCreateOSPrio

to our EPICS base. It does the same as epicsThreadCreate and has the same prototype with the exception that the priority is a simple integer (int). It passes the priority parameter directly without any conversion to the operating system function that creates a new thread.

I added this function in the OSI layer implementation for vxWorks and RTEMS. For posix and WIN32 the function is currently not supported and just returns NULL.

Discussion

The problem with the current implementation of epicsThreadCreate is that it tries to implement thread priorities in an operating system independent way. But it does this by excluding some of the priorities vxWorks and RTEMS offer.

I think it is questionable anyway to have priority numbers independent of the operating system. You do not want to have absolute numbers but you really want to define the relation of the priority of your new thread compared to other threads on the system. You may have to fit the priority of your new thread among the existing ones very carefully and this has to be done again for every supported operating system.

Whatever the scheme is that maps operating system independent priorities to operating system priorities, you will probably end up with a different set of thread priorities for every operating system your software supports anyway.

So I would suggest to change EPICS base and to add the function epicsThreadCreateOSPrio to the EPICS OSI layer. If the OSI layer doesn't support this function for a specific operating system, the implementation should return NULL to indicate an error.

What are your opinions on this topic ?

Many greetings

  Goetz Pfeiffer




Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführerin: Prof. Dr. Anke Rita Kaysser-Pyzalla

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de

Replies:
Re: Problems with priorities in epicsThreadCreate (part of the EPICS OSI software layer) Eric Norum

Navigate by Date:
Prev: Obsolete code in configure/os/CONFIG.Common.linux-arm michael.abbott
Next: Re: Obsolete code in configure/os/CONFIG.Common.linux-arm Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Obsolete code in configure/os/CONFIG.Common.linux-arm Andrew Johnson
Next: Re: Problems with priorities in epicsThreadCreate (part of the EPICS OSI software layer) Eric Norum
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024