Experimental Physics and
Industrial Control System

Dear Klemen,
dear Andrew

thank you for your replies to my question.

Thanks to Andrew's explanation I now know the motivation why the EPICS
OSI library
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
the priorities.

Dear Klemen:
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.

Many greetings

  Goetz Pfeiffer

On 02/25/2012 02:51 AM, Klemen Zagar wrote:

Dear Goetz.

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
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

Cheers,
  Klemen.

On 23.2.2012 22:18, Andrew Johnson wrote:

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

________________________________

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

References:

Re: Problems with priorities in epicsThreadCreate (part of the EPICS OSI software layer) Goetz Pfeiffer

Navigate by Date:

Prev: RE: TDS 3000 on win32-x86 Mark Rivers

Next: RE: BOY FAQ Chen, Xihui

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 

Navigate by Thread:

Prev: Re: Problems with priorities in epicsThreadCreate (part of the EPICS OSI software layer) Goetz Pfeiffer

Next: Missing patch file? Phillip Sorensen

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