Rate-monotonic scheduling

From Wikipedia, the free encyclopedia

 This article or section is in need of attention from an expert on the subject.
Please help recruit one or improve this article yourself. See the talk page for details.
Please consider using {{Expert-subject}} to associate this request with a WikiProject

In computer science, rate-monotonic scheduling[1] is a scheduling algorithm used in real-time operating systems with a static-priority scheduling class.

These operating systems are generally preemptive and have deterministic guarantees with regard to response times. Rate monotonic analysis is used in conjunction with those systems to provide scheduling guarantees for a particular application.

Contents

[edit] Introduction

A simple version of rate-monotonic analysis assumes that threads have the following properties:

  • No resource sharing (processes do not share resources, e.g. a hardware resource, a queue, or any kind of semaphore blocking or non-blocking (busy-waits))
  • Deterministic deadlines are exactly equal to periods
  • Static priorities (the task with the highest static priority that is runnable immediately preempts all other tasks)
  • Static priorities assigned according to the rate monotonic conventions (tasks with shorter periods/deadlines are given higher priorities)
  • Context switch times and other thread operations are free and have no impact on the model

It is a mathematical model that contains a calculated simulation of periods in a closed system, where round robin and time share schedulers fail to meet the scheduling needs otherwise. Rate monotonic scheduling looks at a run modeling of all threads in the system and determines how much time is needed to meet the guarantees for the set of threads in question.

Liu & Layland (1973) proved that for a set of n periodic tasks with unique periods, a feasible schedule that will always meet deadlines exists if the CPU utilization is:

U = \sum_{i=1}^{n} \frac{C_i}{T_i} \leq n(\sqrt[n]{2} - 1)

where Ci is the computation time, and Ti is the release period (with deadline one period later). For example U ≤ 0.8284 for n = 2. When the number of processes tends towards infinity this expression will tend towards:

\lim_{n \rightarrow \infty} n(\sqrt[n]{2} - 1) = \ln 2 \approx 0.693147\ldots

So a rough estimate is that RMS in the general case can meet all the deadlines if CPU utilization is 69.3%. The other 30.7% of the CPU can be dedicated to lower-priority non real-time tasks. It is known that a randomly generated periodic task system will meet all deadlines when the utilization is 85% or less,[2] however this fact depends on knowing the exact task statistics (periods, deadlines) which cannot be guaranteed for all task sets.

The rate monotonic priority assignment is optimal meaning that if any static priority scheduling algorithm can meet all the deadlines, then the rate monotonic algorithm can too. The deadline-monotonic scheduling algorithm is also optimal with equal periods and deadlines, in fact in this case the algorithms are identical; in addition, deadline monotonic scheduling is optimal when deadlines are less than periods.[3]

An optimal static-priority scheduling algorithm when deadlines are greater than periods is an open problem.

[edit] Avoiding Priority Inversion

In many practical applications, resources are shared and the unmodified RMS will be subject to priority inversion and deadlock hazards. In practice, this is solved by introducing priority inheritance. Alternative methods are to use lock free algorithms or avoid the sharing of a mutex/semaphore across threads with different priorities. This is so that resource conflicts cannot result in the first place.

[edit] Disabling of Preemption

  • The OS_ENTER_CRITICAL() and OS_EXIT_CRITICAL() primitives that lock CPU interrupts in a real-time kernel (MicroC/OS-II (commonly written as uC/OS-II) kernel),
  • The splx() family of primitives which nest the locking of device interrupts (FreeBSD 5.x/6.x),

[edit] Priority Inheritance

Examples of priority inheritance algorithms include (from simplest to most complex):

  • http://rt.wiki.kernel.org/index.php/Main_Page contains an implementation of this algorithm which is a part of the in-kernel Linux real time effort to make the entire Linux kernel fully preemptive
  • The Basic Priority Inheritance Protocol[4] which waits until a high priority task requests a lock held by a low-priority task, and then boosts the low priority task priority up to the high priority level until the lock is released
  • The Highest Locker protocol which requires off-line analysis of all task conflicts to find a "ceiling priority"
  • The Priority ceiling protocol[5] which is an enhancement of Basic Priority Inheritance which assigns a "ceiling priority" to each semaphore, which is the priority of the highest job that will ever access that semaphore. A job then cannot preempt a lower priority critical section if its priority is lower than the ceiling priority for that section.

Priority inheritance algorithms can be characterized by two parameters. First, is the inheritance lazy (only when essential) or immediate (boost priority before there is a conflict). Second is the inheritance optimistic (boost a minimum amount) or pessimistic (boost by more than the minimum amount):

pessimistic optimistic
immediate OS_ENTER_CRITICAL() / OS_EXIT_CRITICAL() splx(), Highest Locker
lazy Priority Ceiling Protocol, Basic Priority Inheritance Protocol

In practice there is no mathematical difference (in terms of the Liu-Layland system utilization bound) between the lazy and immediate algorithms, and the immediate algorithms are more efficient to implement, and so they are the ones used by most practical systems.[citation needed]

The Basic Priority Inheritance protocol can produce chained blocking, i.e. an almost arbitrarily long delay from the time a high priority task requests a critical section, until it is served. The other protocols guarantee that at most one lower priority critical section must finish before the high priority task gets its critical section.

The Priority Ceiling Protocol is available in the VxWorks real-time kernel but is seldom enabled.

An example of usage of the Basic Priority Inheritance is related to the "Mars Pathfinder Bug" which was fixed on Mars by changing the creation flags for the semaphore so as to enable the priority inheritance.

[edit] Example

Process Execution Time Period
P1 1 8
P2 2 5
P3 2 10

The utilization will be:

\frac{1}{8} + \frac{2}{5} + \frac{2}{10} = 0.725

The sufficient condition for 3\, processes, under which we can conclude that the system is schedulable is:

U = 3(2^\frac{1}{3} - 1) = 0.77976\ldots

Since 0.725 < 0.77976\ldots the system is surely schedulable.

But remember, this condition is not a necessary one. So we cannot say that a system with higher utilization is not schedulable with this scheduling algorithm.

[edit] See also

[edit] References

  1. ^ Liu, C. L. & Layland, J. (1973), “Scheduling algorithms for multiprogramming in a hard real-time environment”, Journal of the ACM 20 (1): 46–61, DOI 10.1145/321738.321743 .
  2. ^ Lehoczky, J.; Sha, L. & Ding, Y. (1989), “The rate monotonic scheduling algorithm: exact characterization and average case behavior”, IEEE Real-Time Systems Symposium, pp. 166–171, DOI 10.1109/REAL.1989.63567 .
  3. ^ Leung, J. Y. & Whitehead, J. (1982), “On the complexity of fixed-priority scheduling of periodic, real-time tasks”, Performance Evaluation 2 (4): 237–250 .
  4. ^ Lampson, B. W. & Redell, D. D. (1980), “Experience with processes and monitors in Mesa”, Communications of the ACM 23 (2): 105–117, DOI 10.1145/358818.358824 .
  5. ^ Sha, L.; Rajkumar, R. & Lehoczky, J. P. (1990), “Priority inheritance protocols: an approach to real-time synchronization”, IEEE Transactions on Computers 39 (9): 1175–1185, DOI 10.1109/12.57058 .

[edit] Further reading

  • Joseph, M. & Pandya, P. (1986), “Finding response times in real-time systems”, BCS Computer Journal 29 (5): 390–395 .
  • Liu, Jane W.S. (2000), Real-time systems, Upper Saddle River, NJ: Prentice Hall , Chapter 6.

[edit] External links