[RTAI] Real time thread priority in user space
From: http://www.xenomai.org/documentation...deos-rev-B.pdf
Quote:
|
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.
:tisk: 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. |
Quote:
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! :confused: Quote:
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 :redface: ...
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. |
Quote:
It is becoming difficult for me day by day to write English without offending the English men! Quote:
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? Quote:
conversations. I diged up those mails and have produced the following comparison: Code:
Differences between RTAI and Xenomai |
All times are GMT -5. The time now is 12:52 AM. |