Real time Scheduling in Operating System for Msc CS

3
Real-Time Systems
• Definition
– Systems whose correctness depends on their
temporal aspects as well as their functional aspects
• Performance measure
– Timeliness on timing constraints (deadlines)
– Speed/average case performance are less significant.
• Key property
– Predictability on timing constraints

4
Real-Time System Example
• Digital control systems
– periodically performs the following job:
senses the system status and
actuates the system according to its current status
Control-Law
Computation
Sensor
Actuator

What is real time computing?
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.

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.

Characteristics of Real-Time Operating Systems
• Determinism
• Responsiveness
• User control
• Reliability
• Fail-soft operation

An operating system is deterministic to the extent that it performs
operations at fixed, predetermined times or within predetermined
time intervals.
A related but distinct characteristic is responsiveness. Determinism is
con-cerned with how long an operating system delays before
acknowledging an interrupt.
Responsiveness is concerned with how long, after acknowledgment, it
takes an oper-ating 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.
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.

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

To meet the foregoing requirements, real-time operating
systems typically include the following features:
• Fast process or thread switch
• Small size (with its associated minimal functionality)
• Ability to respond to external interrupts quickly
• Multitasking with interprocess communication tools such as
semaphores, signals, and events
• Use of special sequential files that can accumulate data at a fast
rate
• Preemptive scheduling based on priority
• Minimization of intervals during which interrupts are disabled
• Primitives to delay tasks for a fixed amount of time and to
pause/resume tasks
• Special alarms and timeouts

A real-time scheduling intended to serve real-time application
requests. It must be able to process data as it comes in, typically
without buffering delays. Processing time requirements (including
any OS delay) are measured in tenths of seconds or shorter.
Determines the order of real-time task executions
Highest priority process runs first

Real-time scheduling is one of the most active areas of research in
computer science.
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
(3) Whether the result of the analysis itself produces a
schedule or plan according to which tasks are dispatched
at run time

Real time scheduling following some of the algorithms
• Static table-driven approaches: These perform a static analysis of
feasible schedules of dispatching. The result of the analysis is a schedule
that deter-mines, at run time, when a task must begin execution.
• Static priority-driven preemptive approaches: Again, a static analysis
is per-formed, but no schedule is drawn up. Rather, the analysis is used
to assign priorities to tasks, so that a traditional priority-driven
preemptive scheduler can be used.

• 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 sys-tem 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 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 deter-mine 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 ex-ample of this approach is the rate monotonic
algorithm

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 and 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

Deadline scheduling is a technique that allows a user to schedule a job
by time-of-day, week, month, or year. The job's priority remains in
force, but as the deadline approaches, increases the job's priority.
Thus, deadline scheduling increases the likelihood that the job will be
scheduled for execution by the specified deadline.
As a result of deadline scheduling, a job will be reclassified when its
priority is changed.
There have been a number of proposals for more powerful and
appropriate approaches to task scheduling.

Real-time processes are often specified as having a start time (release
time) and a stop time (deadline). The release time is the time at which
the process must start after some event occurred that triggered the
process. For example, suppose that a collision sensor interrupt must
start airbag deployment within 20 msec. of sense time. The deadline is
the time by which the task must complete. The scheduler must allot
enough CPU time to the job so that the task can indeed complete.
There are several times of deadlines. A hard deadline is one in which
there is no value to the computation if it completes after the deadline.

the following information about each task might be used: :
• Ready time: Time at which task becomes ready for execution. In
the case of a repetitive or periodic task, this is actually a sequence of
times that is known in advance. In the case of an aperiodic task, this
time may be known in advance, or the operating system may only be
aware when the task is actually ready.
• Starting deadline: Time by which a task must begin.
• Completion deadline: Time by which task must be completed.
The typical real-time application will either have starting deadlines or
completion deadlines,
but not both.

• Processing time: Time required to execute the task to completion.
In some cases, this is supplied. In others, the operating system measures
an exponential average For still other scheduling systems.
• Resource requirements: Set of resources (other than the
processor) required by the task while it is executing.
• Priority: Measures relative importance of the task. Hard real-time
tasks may have an “absolute” priority, with the system failing if a
deadline is missed. If the system is to continue to run no matter what,
then both hard and soft real-time tasks may be assigned relative
priorities as a guide to the scheduler.
• Subtask structure: A task may be decomposed into a mandatory
subtask and an optional subtask. Only the mandatory subtask
pos1sesses a hard deadline.

There are several dimensions to the real-time scheduling function
when dead-lines are taken into account: which task to schedule
next, and what sort of preemption is allowed. It can be shown, for a
given preemption strategy and using either starting or completion
deadlines, that a policy of scheduling the task with the earliest
deadline minimizes the fraction of tasks that miss their deadlines
This conclusion holds both for single-processor and multi-processor
configurations.

As an example of scheduling periodic tasks with completion
deadlines, con-sider a system that collects and processes data from
two sensors, A and B. The dead-line for collecting data from sensor A
must be met every 20 ms, and that for B every 50 ms. It takes 10 ms,
including operating system overhead, to process each sample
of data from A and 25 mms to process each sample of data from B.
Table 10.2 summarizes the execution profile of the two tasks. Figure
10.6 compares three scheduling techniques using the execution
profile of Table 10.2. The first row of Figure 10.6 repeats the
information in Table 10.2; the remaining three rows illustrate three
scheduling techniques.

In this example, by scheduling to give priority at any preemption point
to the task with the nearest deadline, all system requirements can be
met. Because the tasks are periodic and predictable, a static table-driven
scheduling approach is used.

Now consider a scheme for dealing with aperiodic tasks with starting
dead-lines. The top part of Figure 10.7 shows the arrival times and
starting deadlines for an example consisting of five tasks each of which
has an execution time of 20 ms. Table 10.3 summarizes the execution
profile of the five tasks.
A straightforward scheme is to always schedule the ready task with
the earliest deadline and let that task run to completion. When this
approach is used in the example of Figure 10.7, note that although
task B requires immediate service, the service is denied. This is the risk
in dealing with aperiodic tasks, especially with starting deadlines. A
refinement of the policy will improve performance if deadlines can
be known in advance of the time that a task is ready. This policy,
referred to as earliest deadline with unforced idle times, operates as
follows: Always schedule the eligible task with the earliest deadline
and let that task run to completion.

task may not be ready, and this may result in the processor remaining
idle even though there are ready tasks. Note that in our example the
system refrains from scheduling task A even though that is the only
ready task. The result is that, even though the processor is not used
to maximum efficiency, all scheduling requirements are met. Finally,
for comparison, the FCFS policy is shown. In this case, tasks B and
E do not meet their deadlines.

44
RM (Rate Monotonic)
• Executes a job with the shortest period
(4,1)
(5,2)
(7,2)
Deadline Miss !
5
5
10 15
10
15
T1
T2
T3

45
RM (Rate Monotonic)
• Executes a job with the shortest period
(4,1)
(5,2)
(7,2)
Deadline Miss !
5
5
10 15
10
15
T1
T2
T3

46
Response Time
• Response Time (ri) [
r


i i e
• HP(Ti) : a set of higher-priority tasks than Ti
(4,1)
(5,2)
(10,2)
k
i
p
T HP T k
r e
k i
 



  
 ( )
5
5
10
10
T1
T2
T3

For RMS, the highest-priority task is the one with the shortest period,
the second highest-priority task is the one with the second shortest
period, and so on. When more than one task is available for
execution, the one with the shortest period is serviced
first. If we plot the priority of tasks as a function of their rate, the
result is a monotonically increasing function (Figure 10.8); hence the
name, rate monotonic scheduling.

One measure of the effectiveness of a periodic scheduling algorithm is
whether or not it guarantees that all hard deadlines are met. Suppose
that we have n tasks, each with a fixed period and execution time. Then
for it to be possible to meet all deadlines, the following inequality must
hold:
(10.1)

The sum of the processor utilizations of the individual tasks cannot
exceed a value of 1, which corresponds to total utilization of the
processor. Equation (10.1) provides a bound on the number of tasks that
a perfect scheduling algorithm can successfully schedule. For any
particular algorithm, the bound may be lower. For RMS, it can be
shown that the following inequality holds:
(10.2)

RM Utilization Bounds
1.1
1
0.9
0.8
0.7
0.6
0.5
1 4 16 64 256 1024 4096
The Number of Tasks
Utilization

Rate-monotonic assignment requires that the highest frequency
process(es) (B and C) get the highest priority and A, having the lowest
frequency of execution, gets a lower priority. If we do not follow the
rules and give A the highest priority, B the next highest, and C the
lowest, the CPU will run processes in the following order:

This does not give us the desired performance because, while processes
A and B get scheduled acceptably, process C is late the second time it is
scheduled and misses an entire period! Now let us reverse the priorities
as ratemonotonic assignment would dictate:

The scheduler can now satisfactorily meet the real-time requirements
these tasks. Rate monotonic priority assignment is guaranteed to be
optimal. If processes cannot be scheduled using rate monotonic
assignment, the processes cannot be properly scheduled with any
other static priority assignment.

Conclusion :
Rate Monotonic
Simpler implementation, even in systems without
explicit support for timing constraints (periods,
deadlines)
Predictability for the highest priority tasks

Priority inversion is a phenomenon that can occur in any
priority-based preemptive scheduling scheme but is
particularly relevant in the context of real-time scheduling.
The best-known instance of priority inversion involved the Mars
Pathfinder mission
In any priority scheduling scheme, the system should always be
executing the task with the highest priority. Priority inversion occurs
when circumstances within the system force a higher-priority task to
wait for a lower-priority task.

A more serious condition is referred to as an unbounded priority
inversion, in which the duration of a priority inversion depends not
only on the time required to handle a shared resource, but also on the
unpredictable actions of other unrelated tasks as well

Real time Scheduling in Operating System for Msc CS

More Related Content

What's hot

Similar to Real time Scheduling in Operating System for Msc CS

Recently uploaded

Real time Scheduling in Operating System for Msc CS