Difference between RTOS and GPOS (General Purpose Operating Systems)

Google directs to this page a lot. So I am rewriting this post so that most of you can benefit. I had read a lots of articles to compose this material. There is not short-cut for a good answer. If you want to really know the topic spend 10-20 mins to read and understand it. I have tried to go from layman terms to more technical stuff.

Are ROTSs really fast ?

Many Embedded interviewer ask this question. And most naive answer you could come up with is 'ROTS are fast'.
Well, never use these words. More appropriate answer would be ROTS are deterministic. RTOS gauratee you that particular operation would complete at the worst this much time. This is the very basic criteria of being a RTOS.



Why even bother for RTOS, have better hardware and use GPOS to gain Speed/determinism.
Its all about money, if you can save even 25 cents on one embedded device hardware, and embedded devices are sold in millions of units (say memory card) Companies can make millions of dollars.

Another  major criteria is QoS(Quality of service) If you are playing on video and video stream is not in order, the whole purpose of having video facility is spoiled. RTOS has QoS assurance.

Properties and services of RTOS
a) Task Scheduling
GPOS, the scheduler uses a fairness policy to dispatch threads and processes onto the CPU. This ensurers the fairness with which programs are executed. But it gives no gaurntee that the high priroirty thread will be given preference to the lower priority one.
In some cases the OS may decay the priority (or dyanamically adjust)of the thread in order to achive fairness.



b)Dispatch Latency :
It does not have any upper bound. In General, the more the number of threads the more time GPOS takes to schedule and start executing the the thread . In highly time constraints RTOS system this delay could be devise.In RTOS however if high priority process is ready to run it will start executing 'very soon'. All it tells is, the Algorithms of ROTS kernel should be deterministic and should be able to perform even if no of resources are more.

c) Preemptive Kernel
This is one big difference. For most of the GPOS, the OS kernel is not preemptive. Consequently, a high-priority user thread can never preempt a kernel call, but must wait for the entier call to complete, even if the call was invoked by the lowerest priority proecess.

In ROTS other hand, kernel opreations are preemptive. It means low priority task will be preemted even if its executing any system call.
There would be some delays some times, but a carefully designed RTOS will have those delays very small. And one more important point, even for these delatils the upper bound of delay time would be well defined.

To achieve this goal, the RTOS kernel must be simple and as elegant as possible.
Only services with a short execution path should be included in the kernel itself. Any operations that require significant work (for instance, process loading) must be assigned to external processes or threads.Such an approach helps ensure that there is an upper bound on the longest nonpreemptible code path through the kernel.In a few

GPOSs, such as Linux 2.6, some degree of preemptibility has been added to the kernel. However, the intervals during which preemption may not occur are still much longer than those in a typical RTOS,  the length of any such preemption interval will depend on the longest critical section of any modules incorporated into the kernel (for example,networking and file systems). Moreover, a preemptive kernel does not address other conditions that can impose unbounded latencies, such as the loss of priority information that occurs when a client invokes a driver or other system service

d) Priority Inversion Problem
This is problem which can arrive in preemptive priority based scheduling. RTOS must handle this. Google it, Mars Path finder robot has this problem.


How RTOS are deterministic?

As doctor in movie 'I, Robot' says to Will Smith "Now, that's the right question"

Preemption is very important criteria which I explained earlier, Kernel should have enough preemptive points from where it can return. GPOS are usually not preemptive. 

So from where other Latency Comes?

a) Non preemptive Kernel Latency

This is the way a thread/task executes


Low priority thread starts ---- calls a system call.
In between a high priority thread comes,
If your kernel is non-preemptive until system call finishes your high priority thread would not get to execute. So preemptive kernel is must. If kernel is preemptive you can determine the worst time where High priority thread would start execution.

b) Kernel Latency

This is how embedded system works. 'Something' in embedded system wants some task to be done. This something could be a 'sensor input' or a key press.Normally this 'something' is hardwired to processor with a line.
It means, say temperature sensor says, initiate the cooling process. It dump a signal to the processor. Normally, in OS terminology, we call this kind of signals interrupt.
After a interrupt occurs following action are taken by OS

a) Interrupt intiated
b) A interrupt handler is found
c) Interrupt is handled
d) Makes the task runnable
e)Task is scheduled
f) Task, yeah dears actual RTOS task runs here.

So here would be total kernel latency = Interrupt Latency(b) + handler duration(c) + Scheduler latency(d) +  Scheduler duration(e)

All above mentioned latencies should be deterministic and minimal

i) Interrupt Handler Latency : How fast is your interrupt handler.
Fast Interrupt Handler : In this type of interrupt handling all other interrupts are masked. This may cause jitters in RTOS env. Normally you can miss interrupts during this kind. So its kind of NO for RTOS.
Regular Interrupt Handling: Disable only current interrupt. That's kind of recommended approach.
To sum up interrupt latency comes from
1. Disabling of interrupts (spin lock etc)
2. Bad driver using Fast interrupt mode
3. Process the high priority interrupt first. i.e interrupt handling preemption. 
So RTOS interrupt handling mechanism should take of above points.

ii) Scheduler Duration
Scheduler should be able to pick and start executing a task in O(1) kind of mechanism. Many schedular algorithms are O(n)
Virtual memory is also kind of no to RTOS. Creation of new address space for each task and managing it takes time.
Memory allocation schemes : SLOB/SLOB allocator ???? :-). Its a different topic alltogether.



Please Note:
I am also scribing about RTOS called MQX. Those posts will tell more detailed concepts of RTOS.