[RTAI] Real time thread priority in user space

From: http://www.xenomai.org/documentation...deos-rev-B.pdf

The above behaviour is to be opposed to what happens with RTAI/LXRT for instance, where threads migrating to the Linux space actually lose their real*- time priority in the same move, by inheriting the lowest priority defined by the RTAI scheduler.

There must be some reason behind this design decision. I wish to understand what kind of advantages can it offer - I mean when the real time thread is shifted to userspace, it gets a low priority (and therefore can be preempted by a high priority real time thread running in kernel space). Are there some assumptions behind this design decision?

It is probably to guarantee that the kernel cannot be locked-out. If a malfunctioning or runaway real-time activity could supersede necessary kernel-related dispatching, the system cannot function.

I'll also be frank here: if you want to do "real-time" things, then get an operating system that is expressly designed to do that kind of work. Linux is not ... by design is not ... such a system. If you need to do real-time work with general controls, use an RTOS to do that work, and a general-purpose OS (such as Linux), on a separate box or board, to talk to the machine that is running the RTOS and to control it. (Neither "virtual machines" or "multiple cores" are suitable... the RTOS design goes straight to the specialized hardware itself.) In my humble, it is (by definition) impossible to do "real-time" properly, and "general-purpose" properly, in the same system: the design goals are mutually exclusive, and to achieve their respective intended purposes they need to be. From the hardware, to the software, to the app, all the way up.

Originally Posted by sundialsvcs It is probably to guarantee that the kernel cannot be locked-out. If a malfunctioning or runaway real-time activity could supersede necessary kernel-related dispatching, the system cannot function.

Hmmm, that's very helpful. Thanks.

Actually, I was confused because it is the Xenomai which does the quite opposite.
Their threads maintain the static priority, and therefore any other real time
thread running in kernel space won't be able to preempt it (unless it is actually
has a higher priority).

Doesn't this non preemptive design result in higher scheduling
latencies?
Then what can be Xenomai's reason for deliberately letting it happen? Xenomai is a
framework for hard real time activities!

Originally Posted by sundialsvcs In my humble, it is (by definition) impossible to do "real-time" properly, and "general-purpose" properly, in the same system: the design goals are mutually exclusive, and to achieve their respective intended purposes they need to be.

I know that. We have a software here of which most of the activities we would like
to have in real time. So, the hard real time and the lower latencies are actually
most important for this project.

I don't know much about the hardware in this case, btw.

I trust of course that you do "know that" ... sorry for pontificating ...

It's a tough problem, though, and I'm really not persuaded that any of these strategies will prove to be much more than an an awkward compromise. For instance, notice how the Xenomai web-site spends nearly all of its time talking about how great their release #3 is gonna be, and of course how different it's gonna be, and not much time at all talking about what's out there now (this apparently being the second time that it has rather-radically "evolved" in this way). That's just not much consolation when you've got a commercial app to support.

You see, the compromise is that "real time" processing is really all about getting interrupt-latencies that are consistent and minimal. Which means that the interrupt gets serviced promptly, but necessarily "at the expense of everything else that it is pre-empting." Yet, many of the things that you are trying to make the device in question do, are absolutely dependent upon those "everything else's that you are pre-empting." Preparing the work-to-do. Disposing of the incoming data. And so forth. You could easily starve those processes, with the consequent result that either (a) the system is overrun with incoming data, or (b) the device starves for meaningful work to do. Either way, it is effectively a "denial of service" problem, albeit not an "attack." The customers are getting their orders taken right away, but there's nothing to feed them. The packages are being taken out of their hands timely, but there's nowhere to put them down.

Originally Posted by sundialsvcs I trust of course that you do "know that" ... sorry for pontificating ...

I was NOT being sarcastic there. You don't have to say sorry for anything.
It is becoming difficult for me day by day to write English without offending
the English men!

Originally Posted by sundialsvcs It's a tough problem, though, and I'm really not persuaded that any of these strategies will prove to be much more than an an awkward compromise.

Not sure about your point here. As you said that if we want the "hard real
time", we "will" have to preempt the other non real time tasks.
So, isn't this going to be the case with "every" RTOS?
Am I missing some point?

Originally Posted by sundialsvcs For instance, notice how the Xenomai web-site spends nearly all of its time talking about how great their release #3 is gonna be, and of course how different it's gonna be, and not much time at all talking about what's out there now (this apparently being the second time that it has rather-radically "evolved" in this way). That's just not much consolation when you've got a commercial app to support.

It seems those people talked about it many years back that too in mailing
conversations.
I diged up those mails and have produced the following comparison:

Differences between RTAI and Xenomai
	Real time thread priorities in user space
		- RTAI:
			The real time threads of RTAI running in the user space do not maintain
their static priority. They get a lower priority as soon as they shift to the user space. This 
means that any real time thread of higher priority can preempt other real time thread (with lower 
priority) running in the user space. Due to this way if the real time thread running in user space 
gets currupt somehow, it won't be able to lock out the kernel. This results in lower scheduling 
latency and harder real time but with the drawback of lower throughput.
			RTAI though has a configuration option for disabling this behavior.
			
		- Xenomai:
			Xenomai*threads*maintain their static priority when they are running in the 
secondary domain (Linux). This means that any other real time thread running in primary domain 
(Xenomai) won't be able to preempt it (unless it is actually has a higher priority). This non 
preemptive design does result in higher*scheduling*latencies but with the increased throughput.


	Latency
		An OLD test (done by someone else) showed that RTAI produces somewhat lower 
latencies than Xenomai.
		Tested on a Pentium D 4 (real dual core) CPU.
		RTAI was said to have shown a latency of about 26 miliseconds.
		Xenomai was said to have shown a latency of about 40 miliseconds.
		
		Source: http://www.mail-archive.com/xenomai-help@gna.org/msg02576.html
		
	Architecture support
		- RTAI:
		Source - https://www.rtai.org/
		
		- Xenomai:
		Source - http://www.xenomai.org/index.php/Embedded_Device_Support
		
		
	API support
		- RTAI:
			Supports only its custom API. 
			Source - https://www.rtai.org/documentation/magma/html/api/
		
		- Xenomai 
			Supports the APIs listed as follows:
			POSIX 1003.1b, VxWorks, pSOS+, VRTX and uITRON.
			Source - http://www.xenomai.org/index.php/Getting_Started#What_is_Xenomai.3F
		
	
	HAL
		- RTAI:
			RTAI uses a hardware abstraction layer to get the interrupts from the 
hardware. A pure HAL supports only one OS on the top of it, and directly offers it the interrupts. 
			This kind of direct interaction with the hardware contributes to the lower 
latencies.
			
			So, with RTAI and Linux together, the picture looks like this: 
			Hardware -> HAL -> RTAI -> Linux
			
		- Xenomai:
			Xenomai gets hardware interrupts through Adeos (Adaptive Domain Environment 
For Operating Systems) which besides playing the role of a HAL also supports multiple domains (A 
domain is a kernel based software, and can also be full blown up operating system) on the top of it. 
			It decides which domain to provide the interrupt first by organizing the 
domains in the form of a pipeline on the basis of priority. 
			Domains can even ask Adeos to prevent itself from offering more interrupts 
to them for a period of time (Domains use this feature to protect their own critical sections from 
unwanted preemptions by their own interrupt handlers.). 
			These additional features of Adeos contribute to somewhat higher latencies 
as compared to a pure HAL.
			
			So, with Xenomai and Linux together, the picture looks like this:
			Hardware -> Adeos -> Xenomai -> Linux
                   
                   Source: http://www.mail-archive.com/xenomai-help@gna.org/msg02576.html