Here are Mitch Bunnell's answers:

• What is real-time? — The ability of a system to respond to external or clock events within a bounded period of time.

• What is hard real-time? — The ability of a system to respond to external or clock events within a bounded period of time every time. This implies a real-time analysis can be performed before hand to prove that the system can respond in time every time.

• Who needs real-time? hard real-time? — Most systems that involve human interaction need real-time. Systems that do communication and rely on time-outs to handle faults as part of the protocol need real-time. Systems that do any sort of communication where flow control is not an option (data aquisition or writing to a laser engine for instance) need hard real-time. Any systems that cannot have occasional failures due to lack of timeliness need hard real-time. The bottom line is that most computer systems in the world need real-time. Whether it's hard real-time or not is a matter of how many failures of the system over any given time period will be tolerated.

• What is soft real-time? — Responding to external events within a bounded period of time most of the time. In an ideal case, a real-time analysis would show you statistically what percentage of the time your system is likely to respond in time. In reality this type of analsys is much harder than hard real-time analysis. So soft real-time systems are built and tested to gather these statistics. It is a judgment call how often “glitches” will be tolerated.

• How do you characterize real-time performance? (That is, what key specifications should RTOS vendors use to objectively characterize their offerings?) — An RTOS vendor should include sufficient information to allow a real-time analysis to be done by the customer. This information would include the execution times for interrupts and any system tasks that are higher priority than the customer's tasks. This information should also include the worst-case blocking time that would be incurred by user tasks. Blocking time is the time tasks are forced to wait for lower priority tasks to execute after the event that causes the higher priority task to run occurs.

• Additional comment — If an RTOS is aimed at the soft real-time market, the vendor can take the attitude that the customer will build and test to get statistics on timeliness. In this case, real-time performance numbers can just be marketing hype. The customer's only defense is to write the application to a standard interface [i.e. API]. If the system's real-time performance is not adequate, the selected RTOS can be switched out for a different one.

---

Author's bio: Mitch Bunnell is CTO and cofounder of LynuxWorks, which began life in 1986 as Digital Lynx, in Dallas, TX. In 1988, the company moved to California and became Lynx Real-Time Systems. Recently the company was renamed LynuxWorks. Mitch was the main designer of the LynxOS kernel and served as VP of Engineering. He is currently responsible for LynuxWorks' future technology strategies and development of key evolutionary enhancements to LynxOS. Prior to founding Digital Lynx, Mitch worked on real-time projects as a programmer and consultant, including oil pump control, petroleum distillation, high-speed data acquisition for wind tunnel testing, and video games. Mitch holds a BSEE Summa Cum Laude from the University of Houston.

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.