There should be no problem in releasing anything I build, into the EPICS
Thanks for the note about Priority Inheritance being "nice but not
mandatory". I may hold you to this.... ;-)
Rescheduling Variables in Redhawk are used to prevent the kernel from
preempting a process (or thread). Basically, a running real-time process can
"register" a memory location with the kernel via a Redhawk system call.
Macros are provided which allow the running process to set/change the value
of the registered variable. Whenever the kernel wants to reschedule/preempt
the running process, it checks if the current process has a registered
rescheduling variable, and if so, what the value of the variable is (e.g.
non-zero). Depending on the value of the variable, the kernel may or may not
reschedule the running process. Thus, a rescheduling variable is intended
for use where a running process wants to prevent the kernel from
rescheduling/preempting it for a short period of time. Rescheduling
variables are not intended to be held for extended periods, and there are
restrictions about performing system calls while holding a rescheduling
variable set. In a nutshell, they are a low-overhead method of preventing
the currently running real-time process from being preempted for short
periods of time.
usermap and /proc enhancments .... Hmmm ... I don't believe these can be
done by user code. The additional usermap features allow things like mapping
I/O address space into a process address space, and also allowing the
address space of a "foreign" process to be mapped into the address space of
the current process. (Some of Concurrent's tools, such as the real-time
debugger/analyser map the address space of a target process into their own
address space, so that they can play around with data and instructions in
the target process's address space.)
fast block/wake services... Sorry, I don't know how the existing Redhawk
features compare to whatever is coming in the 2.6 kernel...
Re "must run as root"... yes, I agree, a "nice" solution is important. Will
see what can be done....
From: Marty Kraimer [mailto:email@example.com]
Sent: Thursday, 11 December 2003 12:39 AM
To: David Kelly
Cc: firstname.lastname@example.org; 'Andrew Johnson'; 'Eric Norum'; 'Jeff Hill'
Subject: Re: Novice EPICS questions re yet another port
When you are done with your redhawk port it can be put into base if a
responsible person from your company provides a signed release form stating
your contribution can be subject to the EPICS Base License.
David Kelly wrote:
> Thanks Marty.
> I've read all the follow-up correspondence, especially those from
> Jeff Hill, Andrew Johnson, and Eric Norum. If I may reply to some of the
> points raised:
> 1) I still intend to create a Redhawk-specific version of osdMutex and
> osdThread, etc. This seems to be the most easily understandable and most
> maintainable solution...though I'm open to better ideas. I intend that the
> Redhawk-specific version of osdMutex will only contain one implementation
> a mutex.
A agree with this solution. I also want the same thing for the Linux 2.6
It is on my TODO list but I have been waiting until an official 2.6 release
available from one of the major Linux distributions.
Ulimately ALL supported platforms should support thread priorities. Perhaps
all support platforms have had time to develop a good and complete
implementation of pthreads then we can go back to a common pthreads
inplementation. For now I think it is better provide a separate
of osdThread for each platform in order to implement thread priorities. A
separate implementation of osdMutex may also be desirable.
> 2) Having read the discussion about mutexes and spinlocks, etc, I'm
> convinced that the osdMutex code that I've built already, needs to be
> revised. At present, the code is based on "true" spinlocks (i.e.
> an atomic memory operation instruction, followed by spinning using a
> "standard" memory read operation and then retrying the atomic lock when
> "read" indicates that the lock is available), although it is cognisant of
> whether it is running on a system which has 1 CPU active, or >1 CPU active
> (including logical CPUs enabled by Hyperthreading). The present code only
> spins if it's running on a multi-CPU system, otherwise it calls
> "sched_yield()" to give up the CPU as after it tries once, and fails, to
> acquire the lock.
But this only yields to threads that have the same or higher priority.
> At present I do nothing special to cope with the Priority
> Inheritance problem - I confess that I don't know enough about the EPICS
> code to understand if Priority Inheritance is really required, or if the
> code can never exhibit such problems. However, having said that, I suspect
> that the code should somehow be made to cater for PI. (A forthcoming
> of Redhawk will provide kernel support for PI on mutexes, so in that case
> could spin for a while and then use a kernel mutex - but I don't want to
> have to wait for it...) I'll let you know what I wind up building.
For IOCs recursive mutexes are mandatory. Priority Inheritance is nice but
> 3) Re the difference between Redhawk and the new Linux 2.6 (presumably the
> "3.6" in your email was a typo) kernel... My understanding (not gospel)
> that the following Redhawk features will come as standard to all Linux
> systems in the 2.6 kernel:
> - kernel preemption
> - low-latency kernel patches (though these are only a subset of what's
> - the real-time scheduler
> - Posix timers (though only "low" resolution, not close to Redhawk's
> res timers)
> This means that (at least) the following existing Redhawk features will
> be present in the standard Linux 2.6 kernel:
> - rescheduling variables
What is a rescheduling variable?
> - fast block/wake services
I will guess that these will be tricky to make more efficient than what the
regular 2.6 kernel provides.
> - usermap and /proc enhancements
Couldn't these be done by user level code on top of standard Linux
> - processor shielding and affinity
> - frequency-based scheduler
> Then there are new features planned for future releases of Redhawk and, as
> mentioned, one of these is support for Priority Inheritance.
> 5) I'm not sure what to do about the "must run as root" problem. I can't
> a wrapper as Eric suggested, because (for example) I can't set the
> scheduling policy and priority for all threads once - at program
> commencement - because this must be done as each thread is created or
> a thread is created. I'm not sure how to handle this problem - I *might*
> have to really run stuff as root. I know Redhawk supports Pluggable
> Authentication Modules (PAMs), but I've never looked at them in detail, so
> I'm not sure if they provide the functionality required. Will have to take
> look... As always, other suggestions are welcome...
This is really important. It is a problem that must be solved in a nice way.
know that at APS if we don't have a good solution our Network Administrators
will not be happy.
- Navigate by Date:
Re: Novice EPICS questions re yet another port Marty Kraimer
Spurious link alarms generated? J. Frederick Bartlett
- Navigate by Thread:
Re: Novice EPICS questions re yet another port Marty Kraimer
CA FLNK Steven Hunt