Hi,
I posted this question on qnx.rtos but didn’t get any answer.
Perhaps I get some response in this place.
Some time ago a colleague asked me why QNX is a realtime OS and what’s the difference to e.g. Linux.
Uhmm, well, It’s the microkernel, probably, or not? I started thinking about it but couldn’t come to an accurate answer.
So here are my thoughts on this topic, hopefully you can add some more or correct me.
First of all there is a micro-kernel.
Message passing
It’s POSIX.
The OS is fully preemptable.
Latency is kept short (any figures on this?).
Processes / Threads / Scheduling
…??
One more question:
I think I heard something that Interrupts can be disabled only for a certain period of time (i.e. they are enabled automagically after n msec). Is that true?
I think this is a difficult question to answer, there is no hard specs for what real time is. Some will say Windows is realtime enough, I think QNX is more realtime then windows but there are more real time os then QNX.
I define realtime as the ability to controle what happens when. I remember almost 15 years ago, working with PSos for the 68000CPU. Fonction like malloc() came with the spec of the number of CPU cycle it would take.
You can disable interrupt for as long as you want, but since thinks like network, HD, really on interrupts, strange things could happen.
I know of a designed that disable interrupt for .1 secondes 3 times a second (need to poll parallel port real fast) without any ill effect.
the propblem wasn’t what Realtime is but rather why QNX can act as RTOS where e.g. Windows couldn’t.
There where some nice readings mentioned above and I found more clues on how to anwser the question.
I thought about this once again, and it doesn’t really make sense because you disable interrupts with a certain purpose. So having them enabled before you finished would probably mess up even more.
I probably mixed this up with the short periods of disabled interrupts in QNX itself.
In my opinion, a hard realtime OS must fulfill this condition:
For any given platform, the longest possible time that elapses between the occurrence of an external event and the moment when the first line of code that does something about it can be calculated.
What that really boils down to is that the OS kernel must be written in a way that the longest code path with interrupts switched off is known and does not depend on the present value of any variable, i.e. is state-invariant. For instance, there must be no loops while interrupts switched off.
I think that QNX is very close to this but I found no official statement from QSSL about this, let alone figures. Anyone else did?
Anything else, like, Microkernel, POSIX, Message Passing, etc. is just a mere add-on to this, an implementation detail. For instance, a dumb realtime executive that you could code into a PIC on an afternoon is hard realtime, even if the response times are slow compared to what the hardware could do and they change if you add tasks. The question is: Does the fully-fledged POSIX-QNX with dynamic memory, unlimited number of processes/threads, GUI etc still meet the above condition?
I don’t think I agree with your opinion, You have to be able to prove that the entire task will be carried out (instead of being swapped out by another task) within a given time also (deadline). Your definition of “first line of code that does something about it” isn’t enough if that task is then swapped out by another task and you miss a deadline for something later on in your original task. Your definition wouldn’t even work in a single task system as you would have to still prove that your task completed before deadline (usually quite easy though, just a matter of counting clock cycles for the WCET worst case execution time).
This is the crux of realtime systems, it is the ability to control the scheduling in such a way as to always meet your deadlines for all given scenarios.
Very few applications come close to being true realtime, but i think that as QNX gives you control over which scheduling algorithms are used, and the toolset to support the development of “realtime” OS’s i think it goes a long way to being one.
This can be accomplished via task preemtion based on priorities, which I implied since we are talking about QNX here.
In QNX, you can achieve this only in an interrupt handler, and even here you can be preemted by a higher-priority interrupt. And there we go: The highest interrupt is always tied to the system tick since this is the heartbeat of everything. If you allowed a conceptually application-level task to preemt the system tick you would probably mess up everything. So, you need to be able to calculate the worst-case execution time of all interrupt handlers above you. This is impossible because:
Interrupt handlers can be user-written
Multiple Interrupt handlers can be tied to one HW interrupt and are executed serially
In that sense, QNX is not hard realtime. In a realtime executive you don’t have nasty interrupts, so if you run, you are guaranteed your slice of CPU time. That’s the reason why military devices used to explicitly prohibit the use of interrupts.
This shows that the designer has as much responsibility for the performance as the OS - he must get the task priorities right as well as the amount of work done at a particular priority level.
Fortunately so. You know, plants worth millions of dollars and even airports are sometimes controlled by Windows these days, so what are we fussing about …
Scares the life out of me sometimes I’ve worked in the space / nuclear and air traffic domain, and just now are we beginning to see windows OS’s trying to make an entry into so called ‘safety related’ markets, and it obviously is not suited in any way for it (including XP embedded and even CE).
