In case you are entirely unfamiliar with RMA, here’s a link to a handy primer on the technique. I’ve tried to write this column in a way that you can read those details before or after, at your option. I’ve also included a Glossary of Real Time Terminology at the end of this article.
#1: RMA is Not Just for Academics You have probably heard of RMA. Maybe you can even expand the acronym (consult the glossary at the end of this column if you can’t). Maybe you also know that the theoretical underpinnings of RMA were developed largely at Carnegie Mellon University’s Software Engineering Institute and/or that the technique has been known for about three decades.
If, however, you are like the vast majority of the thousands of firmware engineers I have communicated with on the subject during my years as a writer/editor, consultant, and trainer, you probably think RMA is just for academics. I also thought that way years ago—but here’s the straight dope:
(Schedulers that tweak task priorities dynamically, as desktop flavors of Windows and Linux do, may miss deadlines indiscriminately during transient overload periods. They should thus not be used in the design of safety-critical real-time systems. )
2) RMA is the optimal method of assigning fixed priorities to RTOS tasks. That is to say that if a set of tasks cannot be scheduled using RMA, it can’t be scheduled using any fixed-priority algorithm.
3) RMA provides convenient rules of thumb regarding the percentage of CPU you can safely use while still meeting all deadlines. If you don’t use RMA to assign priorities to your tasks, there is no rule of thumb that will ensure all of their deadlines will be met.
( For example, it is widely rumored that a system less than 50% loaded will always meet its deadlines. Unfortunately, there is no such rule of thumb that’s correct. By contrast, when you do use RMA there is a simple rule of thumb ranging from a high of 82.8% for 2 tasks to a low of 69.2% for N tasks. )
A key feature of RMA is the ability to prove a priori that a given set of tasks will always meet its deadlines—even during periods of transient overload. Dynamic-priority operating systems cannot make this guarantee. Nor can fixed-priority RTOSes running tasks prioritized in other ways.
Too many of today's real-time systems built with an RTOS are working by luck. Excess processing power may be masking design and analysis sins or the worst-case just hasn’t happened—yet.
Bottom line: You’re playing with fire if you don’t use RMA to assign priorities to critical tasks; it might be just a matter of time before your product’s users get burned.
(Perhaps your failure to use RMA to prioritize tasks and prove they’ll meet deadlines explains one or more of those “glitches” your customers have been complaining about?)
To read the rest of the article, click here.