thank you for your replies to my question.
Thanks to Andrew's explanation I now know the motivation why the EPICS
doesn't allow to use *all* priorities on vxWorks and RTEMS.
I think I will add some operating system dependent code to our device
support in order to
set the priorities.
We recently had a discussion on why we need such high priorities and it
wasn't quite clear
if we really need them. But when we port our CAN bus device support to
RTEMS I don't want
to take the risk introducing additional bugs by changing the task
priorities. Maybe, if the
device support runs on both operating systems we will have a review on
Unfortunately the port of our CAN bus device support to RTEMS is
currently only number
three on my own priority list so I won't have time to extend the
software developed at
ITER for this problem right now.
On 02/25/2012 02:51 AM, Klemen Zagar wrote:
Andrew has an interesting suggestion that maybe solves your problem
(at least for vxWorks) even without the patch we have proposed:
Note that on vxWorks the target shell gives full access to the
API, so you can alter task priorities by name very easily:
I believe the shell can even look up task names directly, so as long
name is a valid C identifier you can probably do this as well:
taskPrioritySet myThread, 67
On 23.2.2012 22:18, Andrew Johnson wrote:
On 2012-02-23 you wrote:
If I recall Franck Di Maio's report from ICALEPCS correctly, our patch
has to be adapted so that the API is no longer POSIX specific (e.g.,
this particular function should be epicsThreadSetPriority, accepting
EPICS priority level, and not epicsThreadSetPosixPriority). Andrew, is
this correct or is there anything else?
We already provide that routine, see epicsThread.h, which is implemented
separately for each OS class in its osdThread.c file:
epicsShareFunc void epicsShareAPI epicsThreadSetPriority(
epicsThreadId id,unsigned int priority);
One change that went into the Base 188.8.131.52 release modified the
maps OSI priorities to Posix priorities. At startup (and if Posix
Priority Scheduling was included at build-time) we now discover the
range that the process is allowed to use (which might have been
limited by the
user to less than the Posix min-max range) and map the OSI range to
Then I think the patch would be applicable for inclusion in EPICS base.
Please take a look at the 184.108.40.206 Posix implementation; if there's
missing or wrong with that implementation then we should discuss it.
I was interested in the section of your document that discussed
LWP name from the thread name, and the related parts of the
enhancements. I would consider including a Linux-specific
the osdThread.c code that could provide these kinds of enhancements, but
ideally without duplicating the other Posix code unnecessarily; if it
refactored somehow that would be ideal.
Do you have an actual need to change the scheduling policy for some
I think I would prefer that such threads call the underlying posix
directly (like I suggested Goetz do to set vxWorks and RTEMS priority
outside of the range supported by the OSI API), but I'd like to see a
use-case before I deny that idea completely.
I'm not sure about the ability to set CPU affinity. Do you use a
or is it linux-specific? My current feeling is to say that until
demand for a cross-platform API for setting affinity I think the code
needs it should directly use the OS API, or you set it from outside the
Andrew, what is the procedure -- create a task branch in Bazaar and
publish it? Who of the EPICS core developers would be the right person
to ask to merge to the main trunk?
If you have changes that you want us to consider, create a branch in
and propose it for merging (there's a button on the launchpad branch
do that). Launchpad sends email to the right places when you do
don't have to name anyone specific to review the code.
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
- Re: Problems with priorities in epicsThreadCreate (part of the EPICS OSI software layer) Goetz Pfeiffer
- Navigate by Date:
RE: TDS 3000 on win32-x86 Mark Rivers
RE: BOY FAQ Chen, Xihui
- Navigate by Thread:
Re: Problems with priorities in epicsThreadCreate (part of the EPICS OSI software layer) Goetz Pfeiffer
Missing patch file? Phillip Sorensen