The editor - along with many other people - seems to equate low latency with realtime. That is not how I view it as a realtime programmer. For me the important issue deterministic latencies. On a system based on fixed priorities, like the real-time priorities in Linux, it is important that the latency for a task running at a given priority only depends on what is running at equal or higher priority. If the OS offers that, you can use it to build a real-time system. How low the latencies are, is ofcourse important for the specific application.
Now some people at LKML claims that for a system to be hard real-time it has to be mathematically proved to be so. For me that is mixing up the issues. People can easily use Linux for other mission critical applications without having a mathematical proof it won't crash. They rely on observation and the fact that the coders consider all crashes as very important bugs. You can then also rely on Linux giving deterministic latencies by observation and if you know the coders have done what they can to avoid unbounded latencies.
The latter can be an issue. The first problem is that 95% of the Linux hackers do not care about real-time. Therefore they wont bother about making code with unbound execution inside spin-locks. The trick about turning spin-locks into mutexes helps that: The unbound code is suddenly preemptible and the higher priority real-time tasks does not have to worry. Sometimes per-cpu variables are used and protected with preempt_disable() or local_irq_disable(). All those places have to be looked at, when people want to use those subsystems in a real-time system.
The second problem is that not even all those coding on real-time systems agree on the rules! So the kernel can still get code from XYZ for real-time which turns out not to be if not properly reviewed. I have noticed stuff added to the preempt-realtime itself which is not entirely safe against Joe User. I.e. Joe User could make an evil program making the latencies very high.
Merging preempt-realtime into the main-line will be a good idea. Then Linux can compete with the dedicated RTOSes - which don't even have to care about Joe User because they typically are single user systems. But for Linux to be really successfull in doing that, someone has to specify the aims and the rules. And there has to be reviews of everything entering the kernel to see if it breaks the real-time behaviour - or at least mark it as unsafe for real-time perposes.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds