Summary

While not every real-time application needs the overhead of an RTOS, a good percentage of todays embedded applications are much easier to design and code if they are implemented as several independent threads or tasks . In this chapter, Ive tried to give you some idea of what an RTOS is and what it does. Ive explained, in the most general terms, what the scheduler does and what kinds of services one finds in the average RTOS. You should now understand the differnce between a task and a process, and the difference between being preempted and interrupted . Hopefully this overview will help you decide whether you want to seek more detailed information about RTOSs.

In the right hands, an RTOS can be a useful tool, but it is not a silver bullet for the nasties of real-time programming, nor is it a magic potion that turns application programmers into real-time programmers. A good RTOS will allow a talented real-time programmer to more clearly express the natural concurrency in a problem and will supply structures that encapsulate important real-time primitives (like semaphores, events, messages, etc.) It is important to note, though, that no RTOS can eliminate the intrinsic complexity of concurrent programming. Even when the application is to run on top of an RTOS, the programmer must fully understand the issues of mutual exclusion, reentrancy, deadlock, etc. If you are not already comfortable with these issues, you should begin your study of RTOSs by studying basic concurrency. Once you fully understand the issues, understanding how a particular RTOS addresses those issues will be relatively straight forward.