1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 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 <2012> 2013 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. IntroductionIn 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 epicsThreadCreateThis 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 ProblemAs 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 fixAs a temporary solution I have added the functionepicsThreadCreateOSPrio 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. DiscussionThe 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 |