Three Things Every Programmer Should Know About RMA

by Michael Barr , TechOnline India - September 07, 2010

Real-time systems design and RMA (rate monotonic algorithms) go together like peanut butter and jelly. So why is it that wherever I go in the embedded community, engineers are developing real-time systems without applying RMA? This is a dangerous situation, but one that is easily remedied by ensuring every programmer knows three things about RMA.

Real-time systems design and RMA (rate monotonic algorithms) go together like peanut butter and jelly. So why is it that wherever I go in the embedded community, engineers are developing real-time systems without applying RMA? This is a dangerous situation, but one that is easily remedied by ensuring every programmer knows three things about RMA.

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:

1) All of the popular commercial real-time operating systems such as VxWorks, ThreadX, and MicroC/OS are built upon fixed-priority preemptive schedulers.

(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.

About Author

Comments

blog comments powered by Disqus