Note that on vxWorks the target shell gives full access to the
vxWorks task
API, so you can alter task priorities by name very easily:
taskPrioritySet(taskNameToId("myThread"), 67)
I believe the shell can even look up task names directly, so as long
as the
name is a valid C identifier you can probably do this as well:
taskPrioritySet myThread, 67
Hi Klemen,
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 3.14.12.2 release modified the
code that
maps OSI priorities to Posix priorities. At startup (and if Posix
Thread
Priority Scheduling was included at build-time) we now discover the
priority
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
that.
Then I think the patch would be applicable for inclusion in EPICS base.
Please take a look at the 3.14.12.2 Posix implementation; if there's
anything
missing or wrong with that implementation then we should discuss it.
I was interested in the section of your document that discussed
setting the
LWP name from the thread name, and the related parts of the
epicsThreadShow
enhancements. I would consider including a Linux-specific
implementation of
the osdThread.c code that could provide these kinds of enhancements, but
ideally without duplicating the other Posix code unnecessarily; if it
could be
refactored somehow that would be ideal.
Do you have an actual need to change the scheduling policy for some
threads?
I think I would prefer that such threads call the underlying posix
routines
directly (like I suggested Goetz do to set vxWorks and RTEMS priority
values
outside of the range supported by the OSI API), but I'd like to see a
real
use-case before I deny that idea completely.
I'm not sure about the ability to set CPU affinity. Do you use a
Posix API,
or is it linux-specific? My current feeling is to say that until
there's a
demand for a cross-platform API for setting affinity I think the code
that
needs it should directly use the OS API, or you set it from outside the
process.
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
Bazaar
and propose it for merging (there's a button on the launchpad branch
page to
do that). Launchpad sends email to the right places when you do
that, you
don't have to name anyone specific to review the code.
- Andrew
