Real-time is a rather vague term which people interpret different and use in different contexts.

I think an important part of real-time, is the OS's scheduler. For example, qnx has a hard real-time priority preemption
 based scheduler. Where as most other operating systems implement a form of fair share scheduling. This allows high 
priority application thread's to preempt other low priority threads with minimal scheduling latency. It can also consume
 as many CPU cycles required to complete it's task without having to content for CPU with other theads in the system. 

To supplement and take advantage of the scheduler, we implement several mechanism which deals with floating and 
inherited priorities  which allows high priority tasks which may involve several processes to operate in such a way that
 can allow it to be completed in the most efficient sequence. So effectually "tasks" which don't need to be isolate to a
 particular thread can have the requester's priority propagated transparently to other threads for as long as needed to 
complete the task.

There's also a large number of mechanisms which help to prevent priority inversion and allows smart decisions to be 
taken without application developers having to solve them manually.

I'm not a kernel developers, and these are just a couple points off the top of my head. So to summarize, I think real-
time is more then just interrupt service routine latency, it's also thread preemption latency, and also more generally 
the ability to complete tasks which may include several threads, and possibly several processes a quickly as possible.  

Hi Matt,

Another thing to consider is that there's no free lunch.  Real-time scheduling allows time-critical tasks to respond as 
quickly as possible to external events (usually signaled via interrupts), but that scheduling can come at a price to 
other tasks.  Tasks which are less time-critical may be interrupted more frequently and partially "starved" for CPU time
, thus causing them to take a longer time (in wall-clock terms) to finish whatever they're doing.  Depending on the 
characteristics of the real-time tasks and the overall mix of work to be done, a real-time OS may spend somewhat more of
 the total available CPU time making scheduling decisions.  This is raw overhead in the operating system itself, thus it
 is CPU time that is unavailable to *any* application tasks.  It's like a CPU-cycle "tax" that you have pay for real-
time response.

In contrast, for something like a database server, what you probably want is maximum throughput.  You want your 
application to finish its query or sort or whatever as quickly as possible.  You want as little OS overhead as possible.
  So once a given task (e.g. your database server) has the CPU, you want it to keep the CPU and be interrupted as 
infrequently as possible.  You don't want the OS wasting time _thinking_ about which task to run next, you want the OS 
to give each task the maximum amount of CPU time possible while remaining fair.

Another way to look at is that your CPU hardware runs at some fixed speed X.  You can run a real-time OS on your CPU, or
 a desktop-tuned OS, or a server-tuned OS, or whatever.  None of those OS choices make the hardware itself any faster or
 slower.  Your particular OS choice merely makes different tradeoffs for how to utilize that raw speed X.


Cheers!

Walt


-----Original Message-----
From: Matthew Phillips [mailto:community-noreply@qnx.com] 
Sent: Monday, July 05, 2010 6:08 PM
To: qnx4-community
Subject: Re: RE: RE: So why isn't every OS real-time?

> 
> Hi Matt,
> 
>   Here is a couple of links you can read that might help you out ... 
> 
>     - http://en.wikipedia.org/wiki/Real-time_operating_system 

I read this before posting, it didn't answer my question.  Looking again I see that GPOS's don't allow user programs to 
disable interrupts, which might be a good idea in many cases, but is that it?

>     - http://en.wikipedia.org/wiki/Kernel_%28computing%29 
> 
>   Please note that there are many factors companies use to make a decision as 
> to what is the most appropriate OS for their particular software project 
> including:
>      - Standards (for example, POSIX to ensure portability)
>      - Certifications (for example, a project may have a requirement for SIL 3
>  certification for safety or EAL 4+ for security )
>      - Hardware Support (possibly multicore support)
>      - Software Ecosystem (for example, a project may need a database or a 
> specialized industrial protocol)
>      - Scalability, reliability, performance (based on project requirements)
>      - Real time constraints
>      - Overall OS architecture
>      - Tools
>      - Vendor reputation
>      - Support options
>      - Costs (including licensing costs and engineering costs)
>      - Licensing terms / IP issues (Linux comes with viral GPL licensing 
> constraints)
> 
> You can only determine what the best solution is for your project by 
> evaluating a good subset of these factors. 
> 
> Cheers,
> 
> Léo
> 
> -----Original Message-----
> From: Matthew Phillips [mailto:community-noreply@qnx.com] 
> Sent: July 5, 2010 11:56 AM
> To: qnx4-community
> Subject: Re: RE: So why isn't every OS real-time?
> 
> Hello,
> 
> Thanks, that was really useful, but I couldn't find an answer to my question 
> in it actually.  RTOSs are designed so as to maximize timing reliability and 
>...