Scheduling Algorithms in Real-Time Operating Systems
CPU schedling for real-time Operating Systems involves certain special considerations. In general, there is a distinction to be made between soft real-time systems and hard real time systems. Soft real-time systems provide no guarantee as to when a critical real time process will be scheduled. They guarantee only that the process will be given priority over non-critical processes. Hard real-time systems have stricter requirements. A task must be serviced by its deadline. Service after a deadling has expired is the same as no service at all.
Real time systems are event-driven. The system is typically waiting for a real time event to occur. Events may arise either in software (e.g. a timer has expired) or in harware (e.g. a remote controlled vehicle detects that it is approaching an obstruction). When an event occurs, the system must respond to and service it as quickly as possible. Event latency is the amount of time that elapses from when an event occurs to when it is serviced. Two types of latency affect the performance of real-time systems: interrupt latency and dispatch latency. Interrupt latency refers to the time from the arrival of an interrupt at the CPU to the start of the routine that services the interrupt. When an interrupt occurs, the OS must first complete the instruction it is executing and determine the type of interrupt that occured. It must then save the state of the current process before servicing the interrupt using the specific Interrupt Service Routine (ISR). The total time required to carry out these tasks is the interrupt latency. It is obviously important for real-time operating systems to minimize interrupt latency to ensure that real time tasks receive immediate attention. In fact, for hard real-time systems, it's not only necessary to minimize latency, but latency must be bounded to meet the strict requirements of these systems.
The amount of time required for the schedling dispatcher to stop one process and start another is known as dispatch latency. The goal of giving processes immediate access to the CPU mandates minimizing this kind of latency as well. In sum, the most important feature of a real-time operating system is to respond as quickly as possible to a real-time process as soon as that process requires access to the CPU. As a consequence, the scheduler for a real-time operating system must support a priority based algorithm with preemption. But providing a preemptive, priority-based scheduler guarantees only soft real-time functionality. Hard real-time systems must further guarantee that real-time tasks wil be served in accordance with their deadline requirements, and making such guarantees requires additional scheduling features. From this point on, I will discuss only scheduling algorithms appropriate for hard real-time systems.
Before discussing the algorithms, we must define certain characteristics of the processes that are to be scheduled. First, the processes are considered periodic. They require the CPU at constant intervalls (periods). Once a periodic process has acquired the CPU, it has a fixed processing time t, a deadline d by which is must be serviced by the CPU, and a period p. The relationship among these quantities can be expressed as 0 <= t <= d <= p. The rate of a process is 1/p. What's unusual about this form of schedling is a process might have to announce its deadline requirements to the scheduler. Then, using a technique known as an "admission control" algorithm, the scheduler does one of two things. It either admits the process, guaranteeing that the process will comlete on time, or it rejects the request as impossible if it can't guarantee that the process will be serviced by its deadline.
Rate Monotonic Scheduling
The rate-monotonic scheduling algorithm schedules period tasks using a static priority-driven policy with preemption. If a lower-priority process is running and a higher-priority process becomes available to run, it will preempt the lower-priority process. Upon entering the system, each periodic task is assigned an priority inversely proportional to its period. The shorter the period, the higher the priority and viceversa. A set of processes can be scheduled only if they meet the following equation:
where n is the number of processes in the process set,
First we have to find out whether it's possible to schedule these tasks so that each meets its deadline. If we measure the CPU utilization of a process
Now suppose we use rate-monotonic schedling, in which we assign
Let's try another example with a set of processes that can't be scheduled using the rate-monotonic algorithm. Assume that process
Despite being optimal, rate-monotonic scheduling has a serios limitation. CPU utilization is bounded, and it is not always possible to maximize CPU resources fully. With one process in the system. CPU utilization is 100 percent but it falls to 69 precent as the number of proceses approaches infinity. With two processses, CPU utilization is bounded at about 83 percent. Combined CPU utilization for thr two processes in our first example is 75%. so the rate-monotice scheduing algorithm is guaranteed to schedule them so that they meet their deadlines. For the two processes in our second example, combined utilization is approximately 94 percent: therefore, rate monotonic scheduing cannot guarantee that they be scheduled to meet their deadlines.
Earliest Deadline First Scheduling
Earliest deadline first scheduing assigns priorities dynamically according to deadline. The earlier the deadline, the higher the priority; the later the deadline the lower the priority. Under the EDF policy, when a policy becomes runnable, it must announce its deadline requirements to the system. Priorities may have to be adjusted to reflect the deadlines of the newly runnable processes. Notice how this differs from rate-monotonic scheduling, where priorities are fixed. To illustrate EDF scheduling , we again schedule the processes of our last example, which failed to meet deadline requirements under rate-monotonic scheduing. Recall that
Unlike rate-monotonic scheduling, EDF scheduling does not require that processes be periodic, nor must a process require a constant amount of CPU time per burst. The only requirement is that a process announce its deadline to the scheduler whenever it becomes runnable. The appeal of EDF schedling is that it is theoretically optimal--theoretically it can schedule processes so that each process meets its deadline requirements and CPU utilization is at 100 percent. In practice, however, it is impossible to achieve this level of CPU utilization due to the cost of context switching between processes and interruopt handling.