OS Lecture Real-time operating system

REAL-TIME SCHEDULING
Background
Real-time computing is becoming an increasingly important discipline. The operating system, and in particular the scheduler, is
perhaps the most important component of a real-time system. Examples of current applications of real-time systems include control
of laboratory experiments, process control in industrial plants, robotics, air traffic control, telecommunications, and military
command and control systems. Next-generation systems will include the autonomous land rover, controllers of robots with elastic
joints, systems found in intelligent manufacturing, the space station, and undersea exploration.
Real-time computing may be defined as that type of computing in which the correctness of the system depends not only on the logical
result of the computation, but also on the time at which the results are produced. We can define a real-time system by defining what
is meant by a real-time process, or task. In general, in a real-time system, some of the tasks are real-time tasks, and these have a
certain degree of urgency to them. Such tasks are attempting to control or react to events that take place in the outside world. Because
these events occur in “real time,” a real-time task must be able to keep up with the events with which it is concerned. Thus, it is
usually possible to associate a deadline with a particular task, where the deadline specifies either a start time or a completion time.
Such a task may be classified as hard or soft. A hard real-time task is one that must meet its deadline; otherwise it will cause
unacceptable damage or a fatal error to the system. A soft real-time task has an associated deadline that is desirable but not
mandatory; it still makes sense to schedule and complete the task even if it has passed its deadline. As usual, terminology poses a
problem, because various words are used in the literature with varying meanings. It is common for a particular process to operate
under real-time constraints of a repetitive nature. That is, the process lasts for a long time and, during that time, performs some
repetitive function in response to real-time events. Let us, for this section, refer to an individual function as a task. Thus, the process
can be viewed as progressing through a sequence of tasks. At any given time, the process is engaged in a single task, and it is the
process/task that must be scheduled.
Another characteristic of real-time tasks is whether they are periodic or aperiodic. An aperiodic task has a deadline by which it must
finish or start, or it may have a constraint on both start and finish time. In the case of a periodic task, the requirement may be stated as
“once per period T” or “exactly T units apart.”
RTOS
1. Hard Real-Time Operating System: These operating systems guarantee that critical tasks are completed within a range of
time.
For example, a robot is hired to weld a car body. If the robot welds too early or too late, the car cannot be sold, so it is a hard
real-time system that requires complete car welding by the robot hardly on time., scientific experiments, medical imaging
systems, industrial control systems, weapon systems, robots, air traffic control systems, etc.
2. Soft real-time operating system: This operating system provides some relaxation in the time limit.
For example – Multimedia systems, digital audio systems, etc. Explicit, programmer-defined, and controlled processes are
encountered in real-time systems. A separate process is changed by handling a single external event. The process is activated
upon the occurrence of the related event signaled by an interrupt.
Multitasking operation is accomplished by scheduling processes for execution independently of each other. Each process is
assigned a certain level of priority that corresponds to the relative importance of the event that it services. The processor is
allocated to the highest-priority processes. This type of schedule, called, priority-based preemptive scheduling is used by
real-time systems.
3. Firm Real-time Operating System: RTOS of this type have to follow deadlines as well. In spite of its small impact, missing
a deadline can have unintended consequences, including a reduction in the quality of the product. Example: Multimedia
applications.
4. Deterministic Real-time operating System: Consistency is the main key in this type of real-time operating system. It
ensures that all the task and processes execute with predictable timing all the time,which make it more suitable for
applications in which timing accuracy is very important. Examples: INTEGRITY, PikeOS.
Characteristics of Real-Time Operating Systems
Real-time operating systems can be characterized as having unique requirements in five general areas:
1. Determinism
2. Responsiveness
3. User control
4. Reliability
5. Fail-soft operation
An operating system is deterministic to the extent that it performs operations at fixed, predetermined times or within predetermined
time intervals. When multiple processes are competing for resources and processor time, no system will be fully deterministic. In a
real-time operating system, process requests for service are dictated by external events and timings. The extent to which an operating
system can deterministically satisfy requests depends first on the speed with which it can respond to interrupts and, second, on
whether the system has sufficient capacity to handle all requests within the required time.
One useful measure of the ability of an operating system to function deterministically is the maximum delay from the arrival of a
high-priority device interrupt to when servicing begins. In non-real-time operating systems, this delay may be in the range of tens to
hundreds of milliseconds, while in real-time operating systems that delay may have an upper bound of anywhere from a few
microseconds to a millisecond.
A related but distinct characteristic is responsiveness. Determinism is concerned with how long an operating system delays before
acknowledging an interrupt. Responsiveness is concerned with how long, after acknowledgment, it takes an operating system to
service the interrupt. Aspects of responsiveness include the following:
1. The amount of time required to initially handle the interrupt and begin execution of the interrupt service routine (ISR). If
execution of the ISR requires a process switch, then the delay will be longer than if the ISR can be executed within the
context of the current process.
1
 OS Lecture Real-time operating system
2. The amount of time required to perform the ISR. This generally is dependent on the hardware platform.
3. The effect of interrupt nesting. If an ISR can be interrupted by the arrival of another interrupt, then the service will be
delayed.
Determinism and responsiveness together make up the response time to external events. Response time requirements are critical for
real-time systems, because such systems must meet timing requirements imposed by individuals, devices, and data flows external to
the system.
User control is generally much broader in a real-time operating system than in ordinary operating systems. In a typical non-real-time
operating system, the user either has no control over the scheduling function of the operating system, or can only provide broad
guidance, such as grouping users into more than one priority class. In a real-time system, however, it is essential to allow the user
fine-grained control over task priority. The user should be able to distinguish between hard and soft tasks and to specify relative
priorities within each class. A real-time system may also allow the user to specify such characteristics as the use of paging or process
swapping, what processes must always be resident in main memory, what disk transfer algorithms are to be used, what rights the
processes in various priority bands have, and so on.
Reliability is typically far more important for real-time systems than non-real-time systems. A transient failure in a non-real-time
system may be solved by simply rebooting the system. A processor failure in a multiprocessor non-real-time system may result in a
reduced level of service until the failed processor is repaired or replaced. But a real-time system is responding to and controlling
events in real time. Loss or degradation of performance may have catastrophic consequences, ranging from financial loss to major
equipment damage and even loss of life.
As in other areas, the difference between a real-time and a non-real-time operating system is one of degree. Even a real-time system
must be designed to respond to various failure modes. Fail-soft operation is a characteristic that refers to the ability of a system to fail
in such a way as to preserve as much capability and data as possible. For example, a typical traditional UNIX system, when it detects
a corruption of data within the kernel, issues a failure message on the system console, dumps the memory contents to disk for later
failure analysis, and terminates execution of the system. In contrast, a real-time system will attempt either to correct the problem or
minimize its effects while continuing to run. Typically, the system notifies a user or user process that it should attempt corrective
action then continues operation perhaps at a reduced level of service. In the event a shutdown is necessary, an attempt is made to
maintain file and data consistency.
An important aspect of fail-soft operation is referred to as stability. A real-time system is stable if, in cases where it is impossible to
meet all task deadlines, the system will meet the deadlines of its most critical, highest-priority tasks, even if some less critical task
deadlines are not always met.
Although there is a wide variety of real-time OS designs to meet the wide variety of real-time applications, the following features are
common to most real-time OSs:
• A stricter use of priorities than in an ordinary OS, with preemptive scheduling that is designed to meet real-time requirements
• Interrupt latency (the amount of time between when a device generates an interrupt and when that device is serviced) is
bounded and relatively short
• More precise and predictable timing characteristics than general purpose OSs
The heart of a real-time system is the short-term task scheduler. In designing such a scheduler, fairness and minimizing average
response time are not paramount. What is important is that all hard real-time tasks complete (or start) by their deadline and that as
many as possible soft real-time tasks also complete (or start) by their deadline.
Most contemporary real-time operating systems are unable to deal directly with deadlines. Instead, they are designed to be as
responsive as possible to real-time tasks so when a deadline approaches, a task can be quickly scheduled. From this point of view,
real-time applications typically require deterministic response times in the several-millisecond to submillisecond span under a broad
set of conditions; leading-edge applications (in simulators for military aircraft, for example) often have constraints in the range
of 10−100 µs.
Figure 10.4 illustrates a spectrum of possibilities. In a preemptive scheduler that uses simple round-robin scheduling, a real-time task
would be added to the ready queue to await its next timeslice, as illustrated in Figure 10.4a. In this case, the scheduling time will
generally be unacceptable for real-time applications. Alternatively, in a nonpreemptive scheduler, we could use a priority scheduling
mechanism, giving real-time tasks higher priority. In this case, a real-time task that is ready would be scheduled as soon as the
current process blocks or runs to completion (see Figure 10.4b). This could lead to a delay of several seconds if a slow, low-priority
task were executing at a critical time. Again, this approach is not acceptable. A more promising approach is to combine priorities
with clock-based interrupts. Preemption points occur at regular intervals. When a preemption point occurs, the currently running task
is preempted if a higher-priority task is waiting. This would include the preemption of tasks that are part of the operating system
kernel. Such a delay may be on the order of several milliseconds (see Figure 10.4c). While this last approach may be adequate for
some real-time applications, it will not suffice for more demanding applications. In those cases, the approach that has been taken is
sometimes referred to as immediate preemption. In this case, the operating system responds to an interrupt almost immediately,
unless the system is in a critical-code lockout section. Scheduling delays for a real-time task can then be reduced to 100 µs or less.
Real-Time Scheduling
Real-time scheduling is one of the most active areas of research in computer science. In this subsection, we provide an overview of
the various approaches to real-time scheduling and look at two popular classes of scheduling algorithms.
In a survey of real-time scheduling algorithms, observes that the various scheduling approaches depend on (1) whether a system
performs schedulability analysis, (2) if it does, whether it is done statically or dynamically, and (3) whether the result of the analysis
itself produces a schedule or plan according to which tasks are dispatched at run time. Based on these considerations, the authors
identify the following classes of algorithms:
• Static table-driven approaches: These perform a static analysis of feasible schedules of dispatching. The result of the analysis
is a schedule that determines, at run time, when a task must begin execution.
• Static priority-driven preemptive approaches: Again, a static analysis is performed, but no schedule is drawn up. Rather, the
analysis is used to assign priorities to tasks, so a traditional priority-driven preemptive scheduler can be used.
2
 OS Lecture Real-time operating system
• Dynamic planning-based approaches: Feasibility is determined at run time (dynamically) rather than offline prior to the start
of execution (statically). An arriving task is accepted for execution only if it is feasible to meet its time constraints. One of
the results of the feasibility analysis is a schedule or plan that is used to decide when to dispatch this task.
• Dynamic best effort approaches: No feasibility analysis is performed. The system tries to meet all deadlines and aborts any
started process whose deadline is missed.
Static table-driven scheduling is applicable to tasks that are periodic. Input to the analysis consists of the periodic arrival time,
execution time, periodic ending deadline, and relative priority of each task. The scheduler attempts to develop a schedule that enables
it to meet the requirements of all periodic tasks. This is a predictable approach but one that is inflexible, because any change to any
task requirements requires that the schedule be redone. Earliest-deadline-first or other periodic deadline techniques (discussed
subsequently) are typical of this category of scheduling algorithms.
Static priority-driven preemptive scheduling makes use of the priority-driven preemptive scheduling mechanism common to most
non-real-time multiprogramming systems. In a non-real-time system, a variety of factors might be used to determine priority. For
example, in a time-sharing system, the priority of a process changes depending on whether it is processor bound or I/O bound. In a
real-time system, priority assignment is related to the time constraints associated with each task. One example of this approach is the
rate monotonic algorithm (discussed subsequently), which assigns static priorities to tasks based on the length of their periods.
With dynamic planning-based scheduling, after a task arrives, but before its execution begins, an attempt is made to create a schedule
that contains the previously scheduled tasks as well as the new arrival. If the new arrival can be scheduled in such a way that its
deadlines are satisfied and that no currently scheduled task misses a deadline, then the schedule is revised to accommodate the new
task.
Dynamic best effort scheduling is the approach used by many real-time systems that are currently commercially available. When a
task arrives, the system assigns a priority based on the characteristics of the task. Some form of deadline scheduling, such as earliest-
deadline scheduling, is typically used. Typically, the tasks are aperiodic, so no static scheduling analysis is possible. With this type of
scheduling, until a deadline arrives or until the task completes, we do not know whether a timing constraint will be met. This is the
major disadvantage of this form of scheduling. Its advantage is that it is easy to implement.

Figure 10.4 Scheduling of Real-Time Process

Examples of Real-time Operating System (RTOS)
Some popular real-life examples of RTOS are:
• PCOS: RTOS is widely used in embedded applications and PCOS is one example of embedded RTOS.
• RT Linux: RT Linux stands for Real-time Linux. It operates on a Linux system. The real-time operating system is used
between the Linux system and the hardware.
• Lynx: Lynx is a microkernel-based RTOS that is fully Linux-compatible, a Linux program’s binary image can be effectively
run on Lynx.
Features of Real-Time Operating System (RTOS)
The important features of RTOS are:
• The response time of RTOS is highly predictable. That is we can guess the time system will take to complete the task.
• All the interrupt requests go to the Kernel. The kernel is responsible for making all the decisions.
• Kernel saves the state of each task and decides which task to execute next. Task management and task scheduling are done
by the kernel.
3
 OS Lecture Real-time operating system
• After the interrupt task is executed, the kernel gives control back to the CPU. Then CPU carries on with other processes.
• RTOS occupies very little space. Since the size of programs used in RTOS is small.
• RTOS consumes very less resources. Since maximum utilization of resources (memory, registers, clocks, etc.) happens in
RTOS, we can also start our system with fewer resources.
Components of Real-Time Operating System (RTOS)
An RTOS may have the following components:
• Scheduler: Scheduler guarantees the highest priority process
that is executing.
• Critical Region: Used for context switching using Mutexes,
Locks, etc.
• Timer: Time of process execution is maintained with the
help of Clocks, Timers, etc.
• Power Management: The RTOS system has multiple
devices of varying power requirements thus their
management is very important.
• Communication Process: With the help of Semaphores,
Queues, etc. the process order is decided.
• Memory Management: Memory management is used by the
real-time operating system to use virtual memory. Using
techniques like paging etc., we can save hardware space by
keeping the process that is not in use outside the RAM.
• Peripheral Drivers: As we know in real time system, the
system is connected to external events, and in order to send
the interrupt from the external system to the operating system we need device drivers.
• Device Management: RTOS system contains multiple devices including the internal system as well as many peripheral
devices and they need to be in sync with each other in order to make the system perform its task. Thus their management is
essential.
Rate Monotonic
Rate Monotonic and Earliest Deadline First are both algorithms desiged for real time operating systems (RTOS). The idea behind a
RTOS is that given a set of processes that they can and will be scheduled. Failure to schedule a given process in its given period is
the equivalent of the RTOS failing.
I will say that Rate Monotonic and Earliest Deadline First can be confusing due to the lack of information out there but I think the
content in this book will help you.
Before you even attempt to schedule Rate Monotonic you can apply a formula to determine if the set of schedules can be scheduled
with Rate Monotonic.
It is important to point out that if the formula passes - then the set of processes can be scheduled with Rate Monotonic. If it fails - it is
not a guarantee that it cannot be scheduled. In order words it’s a way to prove it can be scheduled rather than can’t.
That formula is expressed as the following:

It’s simply the sum of the burst times divided by the periods less than or equal to n times (21/2 - 1).
Processes may be preempted in either algorithm (though it is rare). In RTOS we don’t care about average wait time, the only thing we
care about is if the set of processes can actually be scheduled or not.
One important note is that unlike the previous algorithms a real time algorithm will continue forever. Even though the processes have
a fixed burst time - their period indicates that they will run again.
In rate Monotonic the shorter the period the higher the “priority”.
Note: Sometimes the period is referenced as it’s deadline
Example 1
Process Burst Time (ms) Period (ms)
P1 20 50
P2 35 100
In this example we only have 2 processes - P1 has a burst time of 20 and runs every 50 ms and P2 has a burst time of 35 ms and a
period of 100 ms.
That means that P1 needs to run for a total of 20 ms every 50 ms and P2 needs to run for 35 ms every 100 ms.
Let’s apply the formula to determine if we can schedule this set of processes using Rate Monotonic (keeping in mind that if the
formula fails that it may still be schedulable).

Or
.75 ≤ .828
So yes this should be schedulable. So lets take a look at the gantt chart starting with P1. P1 has a burst time of 20 ms.
4
 OS Lecture Real-time operating system
Then we will schedule P2 with a burst time of 35 ms.

Hopefully you will notice that we stopped short at 50 ms. The reason for this is due to the fact that the period for P1 is 50 ms which is
less than P2’s period of 100 ms. This gives priority to P1. So we preempt P2 with a remaining burst time of 5 ms. So we schedule P1:

Then we schedule the rest of P2.

At this point P1 is the next process to run but it won’t run until 100 ms. So we have “dead time” until 100 ms. “Dead time” can be
represented in a number of ways - we will show it as black.

Then we will scheduled P1 again and the cycle will repeat.

Earliest Deadline First

Earliest Deadline First (or EDF) is a dynamic scheduling algorithm. Compared to RMS (or Rate Monotonic Scheduling) which is a
static scheduling algorithm.
Just like Rate Monotonic - EDF has a formula to determine if a set of processes can be scheduled. But in EDF is is a true test if it can
be scheduled. In order words if the formula fails then the processes cannot be scheduled with EDF.

It’s similar to the formula for Rate Monotonic where C is the burst times, t is the priod and n is the number of processes - but in this
case you are comparing against 1.
The technical difference between the two algorithms is that RMS will assign a priority based on the shortest period, EDF will
dynamically determine priority based on the earliest deadline.
Example 1
Process Burst Time (ms) Period (ms)
P1 1 8
P2 2 5
5
 OS Lecture Real-time operating system
Process Burst Time (ms) Period (ms)
P3 4 10
If we apply the formula to determine if we can schedule this using EDF:

.925 ≤ 1
The formula passes so we can schedule it using EDF.
The process that we will schedule first is P2 because its period is Next we will schedule P1:
the shortest among the 3 processes.

And finally P3. But, do take note that scheduling P3 will overlap the period for P2 (before we schedule P3 we are at time 3 ms -
scheduling P3 would put us at time 7 ms). The question should arise if we should preempt P3 for P2? At this time the answer is no.
Simply because P3 and P2 both have the same next periods so a tie occurs and the way we break ties in previous algorithms is to use
FCFS. In this case, P3 will not be preempted and run its full burst.

The next process that we will schedule would be P2. Its period was at 5 ms but P3 ran and was not preempted. P2 will run it’s full
burst and not be preempted.

At this point you should notice that P2 crosses over P1’s period. But P2 was not preempted because it’s deadline is closer than P1.
Next we will schedule P1.

After scheduling P1 this will put us at time 10 ms. Both P2 and P3 have the same period, however, P2’s period is shorter so we
schedule that first then P3.

6
Rate Monotonic
Example 2
Process Burst Time (ms) Period (ms)
P1 1 8
P2 2 5
P3 2 10
Again let’s apply the formula as a check to see if this can be scheduled:

Which will simplify to:

.725 ≤ .77976
Let’s see how the gantt chart will look like.
Starting with P2 because its period is the shortest. Then we schedule P1 because it has the second lowest period.

And finally P3. So far so good - we were able to schedule all 3 processes within in their periods. And no processes
were overlapping which would require us to determine if a process needs to be preempted.

It just happens that at time 5 ms is when P2 will begin its next period so we schedule that. P2 has a burst time of 2 ms
which puts us at 7 ms.

The next process that will run is P1 at time 8 ms (its period is 8 ms). But we are current at time 7 ms - so we have
“dead time” for 1 ms. After the “dead time” we can schedule P1.
Earliest Deadline First
Example 2
Process Burst Time (ms) Period (ms)
P1 25 50
P2 35 80
If we apply the formula:

.9375 ≤ 1
The formula check passes.
To start we will schedule P1 because it’s Next we will schedule P2. P2 will cross over into P1’s period but this
next period is sooner than P2. (50 vs 80) will not preempt P2. The reason is because P2’s next period is 80 vs
P1’s of 100. So P2 will run it’s full burst.

At this point we will schedule P1. It will cross into the deadline of P2 but it will not be preempted because P1’s next
deadline is 100 vs P2’s of 160.

Now we will schedule P2 but P2 crosses into P1’s deadline. P2 will be preempted because P1’s next deadline is 150
which is less than P2’s deadline of 160.

And finally we will end this example showing that after finishing the rest of the burst from the preempted P2 - there is
some dead time.