Afcat GK Questions 2018

Real Time System notes as per RTU syllabus
UNIT- 1
What is a real time system?
Definition 1
A real-time system is one that must process information and produce a response within a
specified time, else risk severe consequences, including failure. A real-time system must produce
output before specified time period. Correct output after specified time period is useless.
Definition 2
Any system in which the time at which output is produced is significant. This is usually because
the input corresponds to some event in the physical world, and the output has to relate to that
same event. The lag from input time to output time must be sufficiently small for acceptable
timeliness
Definition 3
Any information processing activity or system which has to respond to externally generated
input stimuli within a finite and specified period.
Examples
Pace Maker, Metro Rail door sensors, Anti-Missile System, Aircraft control, Ticket reservation
system at airport, Over-temperature monitor in nuclear power station, Mobile phone, Oven
temperature controller, Doppler blood-flow monitor, ECG/arrhythmia monitor.
Failure is inability to perform according to specification. In the case of real-time systems the
‘failed’ specification may be lack of correctness or the failure to produce the response by the
required time.
A real-time system is one whose correctness is based on both the correctness of the outputs and
their timeliness. The ‘novelty’ here is that the system is time critical.
NOTE: It does not have to be ‘fast’: the deadline may be days or weeks… For instance, Texas
Instruments European Program Information Centre (epic) responds within 48 hours for literature
requests.
Characteristics of Real Time Systems:

1. Time Constraints: Every real time task is associated with some time constraints. One
form of time constraints that is very common is deadline associated with tasks. A task
deadline specifies the time before which the task must complete and produce the result.
1 By: Vipin Saraogi (Asst Professor BKBIET Pilani)

2. New Correctness Criterion: The notion of correctness in real time systems is different
from that used in the context of traditional system. In real time systems correctness
implies not only correctness of the, but the time at which the results are produced is also
important. A logically correct result produced after the deadline would be considered
as an incorrect result.
3. Embedded: Majority of real-time systems are embedded in nature. An embedded
computer system is physically “embedded” in its environment and often controls it. A
system having sensors and actuators may be categorized as embedded system.
4. Safety-Critical: For traditional non real time systems safety and reliability are
independent issues. However, in many real time systems these two issues are strongly
bound together making them safety-critical. A safety-critical system is required to be
highly reliable since any failure of the system can cause extensive damage.
5. Concurrency: A real time system usually needs to respond to several independent events
within very short and strict time bound. For instance, consider a chemical plant
automation system, which monitors the rate of a chemical reaction and controls the rate
of reaction by changing the different parameters of reaction such as pressure,
temperature, and chemical concentration.
6. Distributed and feedback structure: In many real time systems, the different
components of the system are naturally distributed across widely spread geographic
locations. In such systems, the different events of interest arise at the geographically
separate locations. For example earthquake and tsunami alert systems. Many distributed
as well as centralized real-time systems have a feedback structure. In these systems, the
sensors usually sense the environment periodically. The sensed data about the
environment is processed to determine the corrective actions necessary. The result of the
processing are used to carry out the necessary corrective actions on the environment
through the actuators, which in turn again cause a change to the required characteristics
of the controlled environment.
7. Task Criticality: Task criticality is the measure of the cost of failure of the task. The
higher the criticality of a task, the more reliable it should be made. Further, in the event
of a failure of a highly critical task, immediate failure detection and recovery are
important.
8. Custom Hardware: A real time system is often implemented on custom hardware that is
specifically designed and developed for the purpose. For ex: a cell phone does not use
traditional microprocessor. Cell phone use processors which are tiny, supporting only
those capabilities that are really necessary for cell phone operation.
9. Reactive: Real time systems are often reactive. A reactive system is one in which an on-
going interaction between the computer and the environment is maintained.
10. Stability: Under overload conditions, real time systems need to continue to meet the
deadlines of the most critical tasks, though the deadlines of the non-critical tasks may not
be met.
11. Exception handling: Many real time systems work round the clock and often operate
without human operators. For example, consider a small automated chemical plant that is
set up to work nonstop. When there are no human operators, taking corrective actions on
the failure becomes difficult. Even if no corrective actions can be immediate taken, it is
desirable that a failure does not result in catastrophic situations. A failure should be

detected and the system should continue to operate in a gracefully degraded mode rather
than shutting off abruptly.
BASIC MODEL OF A REAL-TIME SYSTEM
A Model of a Real-Time System
Sensor: Most of the real-time systems get its input from sensors. Sensors act as input unit for
real-time systems For example a photo-voltaic cell which converts light energy into electrical
energy. A sensor converts some physical characteristic of its environment into electrical signals.
A wide variety of temperature and pressure sensors are also used. Typically, a temperature
sensor operates on the principle of a thermocouple. In anti-missile system radar acts as sensor
which senses any missile in the range and gives signal to the system for action.
Actuator: An actuator is any device that takes its inputs from the output interface of a computer
and converts these electrical signals into some physical actions on its environment. The physical
actions may be in the form of motion, change of thermal, electrical, pneumatic, or physical
characteristics of some objects. A popular actuator is a motor. Heaters are also very commonly
used. Besides, several hydraulic and pneumatic actuators are also popular. A remote controlled
car is best example of actuator where a remote acts as actuator for the car and controls the car
motion.
Signal Conditioning Units:
There are two conditioning units used in real-time system
Input conditioning unit: Input conditioning is required to be carried out on sensor signals
before they can be accepted by the computer. For example, analog signals generated by a photo-
voltaic cell are normally in the milli- volts range and need to be conditioned before they can be

processed by a computer. The following are some important types of conditioning carried out on
raw signals generated by sensors and digital signals generated by computers:
1. Voltage Amplification: Voltage amplification is normally required to be carried out to

match the full-scale sensor voltage output with the full-scale voltage input to the interface
of a computer. For example, a sensor might produce voltage in the milli-volts range,
whereas the input interface of a computer may require the input signal level to be of the
order of a volt.
2. Voltage Level Shifting: Voltage level shifting is often required to align the voltage level
generated by a sensor with that acceptable to the computer. For example, a sensor may
produce voltage in the range −0.5 to +0.5 volt, whereas the input interface of the
computer may accept voltage only in the range of 0 to 1 volt. In this case, the sensor
voltage must undergo level shifting before it can be used by the computer.
3. Frequency Range Shifting and Filtering: Frequency range shifting is often used to reduce
the noise components in a signal. Various types of noise occur in narrow bands and the
signal must be shifted from the noise bands so that noise can be filtered out.
4. Signal Mode Conversion: A type of signal mode conversion that is frequently carried out
during signal conditioning involves changing direct current into alternating current and
vice versa. Another type of signal mode conversion frequently used is conversion of
analog signals to a constant amplitude pulse train such that the pulse rate or pulse width is
proportional to the voltage level. Conversion of analog signals to a pulse train is often
necessary for input to systems such as transformer coupled circuits that do not pass direct
current.
Output conditioning unit: The electrical signals produced by a computer can rarely be used to
directly drive an actuator. The computer signals usually need conditioning before they can be
used by the actuator. This is termed output conditioning.
Interface Unit:
There are two interface units in a real-time system:
Input interface unit: Analog to digital conversion is frequently deployed in an input interface.
Output interface unit: Commands from the CPU are delivered to the actuator through an output
interface. An output interface converts the stored voltage into analog form and then outputs this
to the actuator circuitry. Digital to analog conversion is frequently used in an output interface.
An Output Interface

In the following, we discuss the important steps of Analog to Digital Signal Conversion (ADC).
Analog to Digital Conversion: Digital computers cannot process analog signals. Therefore,
analog signals need to be converted to digital form using a circuitry whose block diagram is
shown below
TYPES OF REAL TIME SYSTEMS

Real-time systems are categorized into three categories on the basis of performance
Real-time System
Hard Real-time System Firm Real-time System Soft Real-time System
Hard real-time systems
A hard real-time system is one that is constrained to produce its result within certain predefined
time bounds. The system is considered to have failed whenever any of its hard real-time tasks
does not produce its required results before the specified time bound. An example of a system
having hard real-time tasks is:
Robot: The robot cyclically carries out a number of activities including communication with the
host system, logging all completed activities, sensing the environment to detect any obstacles
present, tracking the objects of interest, path planning, effecting next move, etc. Now consider
that the robot suddenly encounters an obstacle. The robot must detect it, and as soon as possible

try to escape colliding with it. If it fails to respond to it quickly (i.e. the concerned tasks are not
completed before the required time bound) then it would collide with the obstacle and the robot
would be considered to have failed.
An anti-missile system: An anti-missile system consists of the following critical activities

(tasks). An anti-missile system must first detect all incoming missiles, properly position the anti-
missile gun, and then fire to destroy the incoming missile before the incoming missile can do any
damage. All these tasks are hard real-time in nature and the anti-missile system would be
considered to have failed, if any of its tasks fails to complete before the corresponding deadlines.
Applications having hard real time tasks are typically safety-critical. This means that any failure
of a real-time task, including its failure to meet the associated deadlines, would result in severe
consequences. This makes hard real time tasks extremely critical.
For hard real-time tasks in practical systems, the time bounds usually range from several
microseconds to few milliseconds. It may be noted that a hard real-time task does not need to be
completed within the shortest time possible, but it is merely that the task must complete within
the specified time bound. In other words, there is no reward in completing a hard real-time task
much ahead of its deadline.
Firm Real-Time systems
Every firm real-time system is associated with some predefined deadline before which it is
required to produce its result. However, unlike a hard real-time task, even when a firm real-time
task does not complete within its deadline, the system does not fail. The late results are merely
discarded. In other words, the utility of the results computed by a firm real time task becomes
zero after the deadline.

Firm real-time tasks typically found in multimedia applications. The following are two examples
of firm real-time tasks.
Video conferencing: In video conferencing applications, video frames and the accompanying
audio are converted into packets and transmitted to the receiver over a network. However, some
frames may get delayed at different nodes during transmit on a packet-switched network due to
congestion at different nodes. This may result in varying queuing delays experienced by packets
travelling along different routes. Even when packets traverse the same route, some packets can
take much more time than the other packets due to the specific transmission strategy used at the
nodes. When a certain frame is being played, if some preceding frame arrives at the receiver,
then this frame is of no use and is discarded.
Satellite-based tracking of enemy movements: Consider a satellite that takes pictures of an

enemy territory and beams it to a ground station computer frame by frame. The ground computer
processes each frame to find the positional difference of different objects of interest with respect
to their position in the previous frame to determine the movements of the enemy. When the
ground computer is overloaded, a new image may be received even before an older image is
taken for processing. In this case, the older image is of not much use. Hence the older images
may be discarded and the recently received image could be processed.
For firm real-time task, the associated time bound typically range from a few milli seconds to
several hundreds of milli seconds.
Soft Real-Time system
Soft real-time systems also have time bounds associated with them. However, unlike hard and
firm real-time tasks, the timing constraints on soft real-time tasks are not expressed as absolute

values. Instead, the constraints are expressed either in terms of the average response times
required. An example of a soft real-time task is:
Web browsing: Normally, after an URL (Uniform Resource Locater) is clicked, the
corresponding web page is fetched and displayed within a couple of seconds on the average.
However, when it takes several minutes to display a requested page, we still do not consider the
system to have failed, but merely express that performance of the system has degraded.
Seat reservation in a railway reservation application: Once a request for reservation is made,
the response should occur within 20 seconds on the average. The response may either be in the
form of a printed ticket or an apology message on account of unavailability of seats.
Alternatively, we might state the constraint on the ticketing task as: At least in case of 95% of
reservation requests, the tickets should be processed and printed in less than 20 seconds.
In a lose approach all practical systems can be said to be real-time systems because they must
produce an output or respond to the user’s commands within a reasonable amount of time
(insurance company responding to letters, word processor displaying what was typed on the
screen, mobile phones responding with delays that allow ‘comfortable’ conversation). These
systems where ‘uncomfortably’ long response times are a nuisance but the system still functions
even if deadlines are sometimes not met are called soft real-time systems. Systems where
failure to meet response time constraints leads to catastrophic system failure (aircraft crashing,
car skidding, patient dying before corrective action is performed) are called hard real-time
systems.
Parameters of a real-time task
Following are the parameters associated with a Real-time Task (Ti) :-
● Arrival Time (ai) / Release Time / Request Time (ri) :- It is the time instant at which a
task becomes ready for execution.

● Computation Time (Ci) / Execution Time (ei) :- It the time required by the processor for
executing the task without interruption or the time taken by a task for execution.
● Absolute Deadline (di) :- It is the time before which a task should be completed to avoid
damage to the system.
● Relative Deadline (Di) :- It is the difference between the absolute deadline and the request
time/arrival time/release time.
Di = di – ri
● Start Time (si) :- It is the time at which a task starts its execution.
● Finishing Time (fi) :- It is the time at which a task finishes or completes its execution.
● Response Time (Ri) :- It is the difference between the finishing time and the request time /
release time / arrival time.
Ri = fi − ri
● Lateness (Li) :- It is the time period by which a task is delayed or completed before its
deadline. It is the difference between the finishing time and the deadline.
Li = fi −di
It represents the delay of a task completion with respect to its deadline.
If a task completes before the deadline, its lateness is negative.
If a task completes after the deadline, its lateness is positive.
If a task completes exactly on deadline, its lateness is zero.
● Tardiness or Exceeding Time (Ei) :- It is the time by which a task misses the deadline or
the time a task stays active after its deadline. It is the maximum of zero or lateness of a task.
Ei = max(0, Li)
Tardiness of a task is either zero or positive value. It is never negative.
● Laxity or Slack Time (Xi) :- It is the maximum time a task can be delayed on its
activation to complete within its deadline.
Xi = di − ai – Ci
It is the time period a task can wait for execution so that it does not misses its deadline.
For example a task arrives at 5 ms and its absolute deadline is 12 ms and its execution time is
3 ms then its slack time is
Xi = 12 – 5 – 3 = 4
Therefore slack time for the task is 4 ms
● Criticality is a parameter related to the consequences of missing the deadline (typically, it

can be hard, firm, or soft).
● Value vi represents the relative importance of the task with respect to the other tasks in the
system

Tardiness of a job
Tardiness refers to the time interval by which a job misses its deadline i.e. how much a job is late
respective to its deadline. The tardiness is equal to the difference between completion time of a
job and its deadline if job completes after the deadline. If job completes at or before the deadline
the tardiness is equal to zero. The tardiness is never negative.
Tardiness or Exceeding time Ei: Ei = max(0, Li) is the time a task stays active after its deadline.
Effect of Tardiness on hard and soft real-time systems
A hard real-time system must complete its jobs before deadline therefore in hard real-time
systems tardiness of jobs must be zero. If a system completes its work at or before the deadline
then there is no tardiness value and the timing constraints of the system should be hard. Thus for
a hard real-time system tardiness of jobs must be zero.
In soft real-time system some jobs may miss deadline i.e. some jobs may have positive tardiness.
If a system completes its work after the deadline then we measure the tardiness. In this case the
tardiness is equal to the difference between completion time of the job and its deadline. Thus for
soft real-time system some jobs may have small positive tardiness.
Difference between a Job & Task
● A job is a unit of work that is scheduled and executed by a system. e.g. computation of a
control-law, computation of an FFT on sensor data, transmission of a data packet, retrieval of
a file
● A task is a set of related jobs which jointly provide some function. e.g. the set of jobs that
constitute the “maintain constant altitude” task, keeping an airplane flying at a constant altitude
Difference between Tardiness & Lateness
Tardiness Lateness
Tardiness refers to the time interval by which a It is the time period by which a task is delayed
job misses its deadline or completed before its deadline
It is the maximum of zero or lateness of a task. It is the difference between the finishing time
Ei = max(0, Li) and the deadline.
Li = fi −di
Tardiness of a task is either zero or positive Lateness of a task may be negative, zero or
value. It is never negative. positive.
Tardiness of tasks in a hard real-time system Lateness of task must be zero or negative for
must be zero. hard real-time systems.
Based on the regularity of activation tasks can be classified as:
Based on the way real-time tasks recur over a period of time, it is possible to classify them into
three main categories:
 Periodic tasks
 Aperiodic tasks
 Sporadic tasks
Periodic Tasks
 A set of jobs that are executed repeatedly at regular time intervals can be modeled as a
periodic task.
 A periodic task is denoted by τ(i), whereas an aperiodic job by J(i). The generic kth job of
a periodic task τi will be denoted by τ(i,k).
 The activation time of the first periodic job τ(i,1) is called phase.
 The period T(i) of task τ(i) is the minimum length of all time intervals between release
times of consecutive jobs.
 If φ(i) is the phase of task τ(i), the activation time of the kth instance (job) is given by
φ(i) + (k − 1)T(i),
 The execution time Ci of a task τ(i) is the maximum execution time of all jobs in the
periodic task.
Aperiodic & Sporadic Tasks
 In aperiodic tasks, the activation of jobs is not regularly interleaved.

 An aperiodic task where the consecutive jobs are separated by a minimum inter-arrival
time is called a sporadic task.
Periodic and Aperiodic Tasks
Real-time applications are also classified depending on the tasks that comprise the
application. In some systems, tasks are executed repetitively within a specified period. A task
ti is characterized as (pi, ei), where pi its periodicity and ei is its (worst-case) execution time.
Monitoring patient’s vitals is an example of such a system. Hard real-time systems are
usually designed using periodic tasks, and static scheduling can be used for periodic tasks.
Aperiodic tasks are tasks that are executed on demand (or with unknown period). A task is
executed in response to an event, and a task ti is characterized as (ai, ri, ei, di) where ai its the
arrival time. ri is the time when the task is ready for execution, ei is its (worst-case) execution
time, and di is the deadline by which the task must complete. It should be noted that the
arrival time may not be specified in some systems, and the ready time is defined by the
arrival of an event. Real-time systems that must react to external stimuli will consist of
aperiodic tasks, which define the response to the events. Systems that include aperiodic tasks
fall into the class of soft real-time applications, because scheduling may not guarantee
completion of tasks within specified deadlines.
Real-time applications may also include sporadic tasks, which are defined random arrival
times. Sporadic task can be characterized by (ai, ri, ei, di); similar to aperiodic tasks.
Release and Response Time
• Release time – the instant in time when a job becomes available for execution
– May not be exact: Release time jitter so is in the interval
– A job can be scheduled and executed at any time at, or after, its release time, provided
its resource dependency conditions are met
• Response time – the length of time from the release time of the job to the time instant when it
completes
– Not the same as execution time, since may not execute continually

Deadlines and Timing Constraints
• Completion time – the instant at which a job completes execution

• Relative deadline – the maximum allowable job response time
• Absolute deadline – the instant of time by which a job is required to be completed (often called
simply the deadline)
– absolute deadline = release time + relative deadline
– Feasible interval for a job Ji is the interval ( ri, di ]
• Deadlines are examples of timing constraints
Hard Real -Time System Soft Real-Time System

Hard real time systems are systems that can’t Soft real time systems are systems that can
tolerate any delay. The task must be completed tolerate some amount of delay
before deadline.
If delay happens the whole system will be
worthless and will have some negative effect.
In Hard Real Time Systems the correctness of In Soft real time systems if it can't meet the
output depends on time not before and not after required time, this will affect only the quality but
and time must be predictable. not the correctness of results. Off course up to
limit.
Tardiness of tasks in hard real-time system must Tardiness of some task may be some small positive
be zero value as some task may miss the deadline
For hard real-time tasks in practical systems, For Soft real-time tasks, the time bounds range
the time bounds usually range from several from few seconds to few minutes.
microseconds to few milli seconds.
Hard real-time systems are often safety critical Soft real-time systems are not safe
Hard real-time systems have small data files Soft real-time systems have larger databases
and databases so that queries must meet there
deadlines
In hard real-time system validation of system Validation is not required
and tasks is requred
Example: Example:
– Flight control – Stock trading system
– Railway signaling – DVD player
– Anti-lock brakes – Mobile phone
– Anti missile defense system – Browser application
Real time Databases

Real-time databases are traditional databases that use an extension to give the additional power
to yield reliable responses. They use timing constraints that represent a certain range of values
for which the data are valid. This range is called temporal validity. A conventional database
cannot work under these circumstances because the inconsistencies between the real world
objects and the data that represents them are too severe for simple modifications. An effective
system needs to be able to handle time-sensitive queries, return only temporally valid data, and
support priority scheduling.
The main differences between a conventional database and a real-time database lie in the
temporal characteristics of the stored data, timing constraints imposed on the database
operations, and the performance goals
There are three main differences between traditional and real-time databases. First, unlike
traditional databases, timing constraints are associated with the different operations carried out
on real-time databases. Second, real-time databases have to deal with temporal data compared to
static data as in case of traditional databases. Third, the performance metrics that are meaningful
to the transactions of these two types of databases are very different. We now elaborate these
three issues.
Temporal Data: Data whose validity is lost after the elapse of some pre-specified time interval
are called temporal data or perishable data. Example of such data includes the following:
 Consider the periodic data generated by temperature sensor. The temperature sensor
transmits sampled temperature data periodically to the controller, say every 100
milliseconds. As new temperature readings become available, the old temperature data
become stale and are reduced to archival data.
 Consider stock market price quotations. As new price quotations come in, data pertaining
to previous quotations become obsolete.
Timing constraints on database operations: Tasks and transactions are similar abstractions in the
sense that both are units of work as well as scheduling. However, unlike real-time tasks, a
transaction execution might require many data records in exclusive mode. Also, while the
execution times of tasks can be reasonably be assumed be deterministic, the transaction
execution times are much more unpredictable, especially if disk accesses are required.
Performance Metric: the most common performance metric for all databases (real-time or not)
is transaction response time. For traditional database systems, this is number of transactions
completed per unit time. For real-time databases on the other hand, the typical metric of interest
is the number of transactions missing their deadlines per unit time.
Real-Time database occurs in many important applications:

1) Airline Reservations
2) Banking
3) Stock Market System
In airline reservation and banking systems the response time needs to be kept low in order not to
annoy customer. In stock market systems, the slow execution of orders can be very expensive in
volatile markets.

UNIT-2
Real time processors and resources
Processor is a kind of system resource which is used to schedule the job on a system. Processor
is an active resource of the system. It is also known as server. Example of processor is: CPU,
Database servers, transmission links, disks etc. processors carry out machine instructions and
move data from one place to another place, retrieving files, process queries etc. Every job
contains one or more processors according to the application. According to the functionality
processors are of two types:
 Processors that perform same work and can be used inter changeably. For example
symmetrical multiprocessor (SMP).
 Processors that are functionally different and cannot be used interchangeably. For
example CPU, transmission links, database servers etc.
Resource is also a kind of system resource. It is known as passive resource of the system. These
resources are needed in addition to the processor for execution. Without passive resource the job
execution is not complete. For example memory, mutexes, semaphores, database etc.
Example: sliding-window scheme:

– Job: message transmission
– Processor: data link
– Resource: valid sequence numbers
Real-Time workload model
The real time workload model describes the application that are executed and scheduled by the
processors using some resources. A real-time application is characterized by four parameters:-
Temporal parameter: Defines the timing constraints and behavior associated with the
application.
Temporal parameters
Ji : Job-- Unit of work

Tj : Task-- Set of related jobs.
e.g. Periodic task is sequence of invocations of identical jobs.
ri : Release time of Job Ji
di : Absolute deadline of Job Ji
Di : Relative deadline of Job Ji
ei : (Maximum) execution time of Job Ji

Release time may be classified as:

1. Fixed Release Time: It is the time at which a job is available for execution. There is no
variation or flexibility in release time
2. Jittered Release Time: jittered or delay release time refers to the instant which is not
known by the job or user that mean when it release. When we do not know exactly when
each job will be released then we specify a range of release time that is earliest and latest
release time. The range is specified in terms of [ri-,ri+]. Here ri- denotes the earliest release
time and ri+ denotes the latest release time. This interval is also known as delay in release
time. The job becomes available for execution in this range. This is specified as jittered
release time.
3. Sporadic Release Time: Sporadic release time refers to the time of instants when some
external events occurs randomly and real-time system is required to respond to external
event. When such event occurs, the system executes a set of jobs in response; so release
time for these jobs are not known until the event triggered by other event. This type of
instant is called sporadic release time and jobs are called sporadic job or aperiodic job.
Precedence Constraints
Jobs are either precedence constrained or independent. i.e. either jobs are executed independent
of each other in any order or they must be executed in some specific order if they are dependent
on each other.
The jobs are said to be precedence constrained if they are restricted to execute in some order,
otherwise if the jobs can execute in any order they are said to be independent.
Precedence relation is shown by < (partial order) symbol.
For example:
Ji < Jj : Ji is predecessor of Jj
Precedence graph: G = (J, <) it is the graphical representation of precedence constraints imposed
on jobs with a system.
For Example:

AND/OR Dependency:
AND/OR dependency is shown by the task graph (precedence graph).
Generally in task graph the jobs are represented by AND/OR system. AND jobs cannot
commence computing before all their precedents have completed. OR jobs can commence after
any one of their predecessor has completed. The AND jobs are represented by unfilled circles in
the task graph and OR jobs are represented by square vertices in task graph
Conditional Branch Dependency:

The conditional dependency arises when sub graph is considered. The sub graph that begins from
a vertex representing a branch job and ends at the vertex representing a branch job and ends at
the vertex representing the associated join job is called conditional block. The outgoing edges
called AND constraints and the modeled edge presenting by OR constraint. The conditional
branch dependency occurs when the all immediate successor jobs are executed.
Pipeline Dependency:
Pipeline dependency refers to the sequential execution of jobs one after other. In task graph the
pipeline dependency is shown by dotted line.

DATA DEPENDENCY
In many real time systems, jobs communicate via shared data. i.e. there is common data shared
between multiple jobs. If this happens between jobs then we can say there is data dependency
between jobs.
Data dependency cannot be captured by a precedence graph. Data dependencies among jobs are
represented explicitly by data dependency edges (data dependency graph) among jobs.
Sometimes the scheduler may not be able to schedule data dependent jobs independently.
To ensure data integrity some locking mechanism must be used to ensure that only one job can
access the shared data at a time.
For example:
In an avionics system, the navigation job updates the location of the air plane periodically.
Whenever the flight management job needs navigation data, it read the most current data
produced by the navigation data from the shared space. So we can say there is data dependency
between navigation job and flight management job.
FUNCTIONAL PARAMETERS
Functional parameters define the internal characteristics and properties of a job. i.e. the
parameters that are associated with job. The functional parameters are classified as
Preemptively of job:
Preemption: suspend job then dispatch different job to processor. According to preemption the
scheduler may suspend execution of less urgent job and give the processor to a more urgent job.
Cost includes context switch overhead.
Non-preemptable task - must be run from start to completion.
Criticality of job:
Criticality refers to the importance of a job. The importance of a job can be measured by
quantitative values like priority and weight. The criticality or importance denoted by a positive
number with respect to the job. The main objective of assigning criticality to a job is to meet
their deadlines.
Optional Execution:
In real-time system every job contain two portions called optional portion and mandatory
portion. The quality of the system depends on the execution of optional portion. If an optional
portion of a job complete late or not executed the system performance may degrade. The
mandatory portion of the job must be completed before the deadline. For example: in a collision
avoidance system, we may consider the job that computes the correct action and inform the
operator.
Laxity Type:
Laxity type refers to usefulness of a function in the real time system for a job. The usefulness
function defines the tardiness of a job. The tardiness refers to the job completes how much late
respective to deadline. If the job completes on or before deadline that means tardiness is zero and
system is hard. If the job completes after the deadline that means tardiness is equal to the
difference between completion time and deadline.

RESOURCE PARAMETERS
The resource parameter defines the resources required by the real time application. The real-time
resources are divided into two parts:
 Active resources also called processor or server
 Passive resources called resources
For the execution, a job requires more resources except processor. The resource parameters
define the type of processor and units of each resource required by the job. There are different
kinds of resource parameters like:
Preemptivity of resources: A preemptive resource is a resource that can be taken from a lower
priority job and given to a higher priority job if required. A resource is non preemptable when it
is not possible to take back that resource before completion of that job completes.
Resource Graph: It is the graphical representation of various resources available in a system
and the relationship among them.
Vertices in resource graph represent the resources and Edges in resource graphs represent the
relationship among resources.
There are 2 types of edges in resource graphs
Is-a-part-of edge
– An edge from vertex Ri to vertex Rk can mean that Rk is a component of Ri. e.g.
a memory is part of a computer and so is a monitor.
– This edge is an is-a-part-of edge.
– The subgraph containing all the is-a-part-of edges is a forest. The root of each
tree represents a major component, with subcomponents represented by vertices.
e.g. the resource graph of a system containing 2 computers consists of 2 trees.
The root of each tree represents a computer with children of this vertex including
CPUs etc.
Accessibility edge
– Some edges in resource graphs represent connectivity between components.
– These edges are called accessibility edges.
– e.g. if there is a connection between two CPUs in the two computers, then each
CPU is accessible from the other computer and there is an accessibility edge from
each computer to the CPU of the other computer.
– Each accessibility edge may have several parameters.
– e.g. a parameter of an accessibility edge from a processor Pi to another Pk is the

cost of sending a unit of data from a job executing on Pi to a job executing on Pk
– Some algorithms use such information to decide how to allocate jobs and
resources to processors in a statically configured system.
Example:
In the above diagram the solid arrow defines the is-a-part-of resource dependency and dotted
arrow defines the accessibility edge.
PERIODIC TASK MODEL

In a periodic task system each task makes a resource request at regular periodic intervals. The
processing time and the time elapsed between the request and the deadline is always the same for
each request of a particular task; they may however be different for different tasks.
Periodic Jobs repeated at regular or semi-regular intervals.

• We call the tasks in the system
T1, T2, …, Tn
where there are n periodic tasks in the system. n can vary as periodic tasks are added or
deleted from the system.
• We call the individual jobs in the task Ti
Ji,1, Ji,2, …, Ji,k
where there are k jobs in the task Ti
• Each periodic task, Ti, is a sequence of jobs.
• The period pi of the periodic task Ti is the minimum length of all time intervals between
release times of consecutive jobs in Ti.
• The execution time, ei, is the maximum execution time of all the jobs in it.
If we want to talk about individual jobs but are not concerned about which task they are in, we
can call the jobs J1, J2, etc.
Phase of job
• The release time ri,1 of the first job Ji,1 in each task Ti is called the phase of Ti
• We use ϕi to denote the phase of Ti
• In general different tasks may have different phases.
• Some tasks are in phase, meaning that they have the same phase.
Hyperperiod
• A time interval of length H is called a hyperperiod of the periodic tasks. H denotes the
least common multiple of pi for i = 1, 2, … n
Example:
• The maximum number of jobs in each hyperperiod is :
Example: the length of a hyperperiod for 3 periodic tasks with periods 3,4 and 10 is 60 therefore
the maximum number of jobs in each hyperperiod is:
– 20 jobs with period 3,
– 15 jobs with period 4,
– 6 jobs with period 10.
And total no of jobs is 41.

Processor Utilization
• The ratio ui = ei / pi is called the utilization of the task Ti
• ui is the fraction of time that a truly periodic task with period pi and execution time ei
keeps a processor busy.
• ui is an upper bound of utilization for the task modelled by Ti
The total utilization U of all tasks in the system is the sum of the ui
For Example:
If the execution times of the three periodic tasks are 1, 1, and 3, and their periods are 3, 4, and
10, then their utilizations are:
u1= (e1/p1) = (1/3) = 0.33
u2= (e2/p2) = (1/4) = 0.25
u3= (e3/p3) = (3/10) = 0.30
The total utilization of these tasks is 0.88 thus these tasks can keep a processor busy at most 88
percent of the time.
APERIODIC AND SPORADIC TASKS

• Most real-time jobs are required to respond to external events, and to respond they
execute aperiodic or sporadic jobs whose release times are not known in advance.
• In the aperiodic task model the workload generated in response to these unexpected
events takes the form of aperiodic and sporadic tasks.
• Each aperiodic or sporadic task is a stream of aperiodic or sporadic jobs.
• The inter-arrival times between consecutive jobs in such a task may vary widely.
• The inter-arrival times of aperiodic and sporadic jobs may be arbitrarily small.
• The jobs in each task model the work done by the system in response to events of the
same type.
• The jobs in each aperiodic task are similar in the sense that they have the same statistical
behavior and the same timing requirement.
• Inter-arrival times of aperiodic jobs are identically distributed random variables with
probability distribution A(x)
• Similarly the execution times of jobs in each aperiodic or sporadic task are identically
distributed random variables according to probability distribution B(x)
• These assumptions mean that the statistical behavior of the system does not change with
time. i.e. the system is stationary.
• That the system is stationary is usually valid for a time interval of length of order H.
• That is the system is stationary during any hyper period during which no periodic tasks
are added or deleted.
• We say a task is aperiodic if the jobs in it have either soft deadlines or no deadlines.
• We therefore want to optimize the responsiveness of the system for the aperiodic jobs,
but never at the expense of hard real-time tasks whose deadlines must be met at all timed.
What is a sporadic task?

• Tasks containing jobs that are released at random time instants and have hard deadlines
are sporadic tasks.
• We treat sporadic tasks as hard real-time tasks.

• Our primary concern is to ensure that their deadlines are met.
• Minimizing their response times is of secondary importance.
Examples of aperiodic and sporadic tasks

• Aperiodic task
– An operator adjusts the sensitivity of a radar system. The radar must continue to
operate and in the near future change its sensitivity.
• Sporadic task
– An autopilot is required to respond to a pilot’s command to disengage the
autopilot and switch to manual control within a specified time.
– Similarly a fault tolerant system may be required to detect a fault and recover
from it in time to prevent disaster.
UNIT-3
Real Time Scheduling
What is schedule?
A schedule is an assignment by the scheduler of all the jobs in the system on the available
processors.
A scheduler specifically assigns jobs to processors
A schedule is an assignment of all jobs in the system on the available processors.
A scheduler works correctly if it produces only valid schedules.
A valid schedule satisfies the following conditions:
1. Every processor is assigned to at most one job at any time.
2. Every job is assigned at most one processor at any time.
3. No job is scheduled before its release time.
4. Depending on the scheduling algorithms used, the total amount of processor time assigned to
every job is equal to its maximum or actual execution time.
Note that we have assumed implicitly that jobs do not run in parallel on more than one processor
to speed up their execution.
Of course it may be possible to run parallel jobs but we will not be considering such a
complication at this stage
Terms related to a schedule
Valid schedule
A schedule is said to be a valid schedule if it satisfies the following conditions:

– Every processor is assigned to at most one job at any time
– Every job is assigned at most one processor at any time
– No job is scheduled before its release time
– The total amount of processor time assigned to every job is equal to its maximum or actual
execution time
– All the precedence and resource usage constraints are satisfied
Feasible Schedule
A valid schedule is a feasible schedule if every job completes by its deadline and in general
meets its timing constraints.
A set of jobs is schedulable according to a scheduling algorithm if when using the algorithm the
scheduler always produces a feasible schedule.
Optimal Schedule
The criterion we usually use to to measure the performance of scheduling algorithms is for hard
real-time applications is their ability to find feasible schedules of the given application system
whenever such schedules exist.
A hard real-time scheduling algorithm is optimal if using the algorithm the scheduler always
produces a feasible schedule if the given set of jobs has feasible schedules.
If an optimal algorithm cannot find a feasible schedule, we can conclude that a given set of jobs
cannot feasibly be scheduled by any algorithm.
Tardiness
Zero if completion time <= deadline, otherwise > 0 (complete - deadline).
Lateness
Difference between completion time and deadline, can be negative if early.
Performance Measures for a Real-time scheduling algorithm
Miss rate: Percentage of jobs executed but completed late

Loss rate: Percentage of jobs discarded
Invalid rate: Sum of miss and loss rate and gives the percentage of jobs that do not produce a
useful result. We try to minimize the invalid rate.
makespan : When all jobs have the same release time and deadline, the problem of scheduling
the jobs to meet their deadlines is the same as that of scheduling to minimize the completion time
of the job which completes last.
The response time of that job is the response time of the set of jobs as a whole, and is often
called the makespan of the schedule.
The makespan is a performance criterion commonly used to compare scheduling algorithms.
An algorithm that produces a schedule with a shorter makespan is better.
If the makespan is less than or equal to the length of their feasible interval, the jobs can meet
their deadline.
Average Response time: The most frequently used performance measure for jobs with soft
deadlines is their average response time.
We can compare the performance of scheduling algorithms on a given set of jobs based on the
average response times of the jobs when scheduled according to the algorithms.
The smaller the average response time, the better the algorithm.
Commonly Used Approaches to Real-Time Scheduling

There are three commonly used approaches to real-time scheduling
– Clock-driven
– Weighted round-robin
– Priority-driven
The weighted round-robin approach is mainly used for scheduling real-time traffic in high-speed
switched networks. It is not ideal for scheduling jobs on CPUs.
Clock Driven
– Clock-driven scheduling is often called time-driven scheduling.
– When scheduling is clock-driven, decisions are made at specific time instants on what
jobs should execute when.
– Typically in a system using clock-driven scheduling, all the parameters of hard real-time
jobs are fixed and known.
– A schedule of the jobs is computed off-line and is stored for use at run-time.
– The scheduler schedules the jobs according to this schedule at each scheduling decision
time.
– Thus scheduling overhead at run-time is minimized.
– Scheduling decisions are usually made at regularly spaced time instants.
– One way to implement this is to use a hardware timer set to expire periodically which
causes an interrupt which invokes the scheduler.
– When the system is initialized, the scheduler selects and schedules the jobs that will
execute until the next scheduling decision time and then blocks itself waiting for the
expiration of the timer.
– When the timer expires, the scheduler repeats these actions.
Round Robin Approach

– The round-robin approach is commonly used for scheduling time-shared applications.
– When jobs are scheduled in a round-robin system, every job joins a first-in-first-out
(FIFO) queue when it becomes ready for execution.
– The job at the head of the queue executes for at most one-time slice.
– If the job does not complete by the end of the time slice, it is preempted and placed at the
end of the queue to wait for its next turn.
– When there are n ready jobs in the queue, each job gets one time slice in n, that is every
round.
– Because the length of the time slice is relatively short (typically tens of milliseconds) the
execution of each jobs begins almost immediately after it becomes ready.
– In essence, each job gets 1/nth share of the processor when there are n jobs ready for
execution.
– This is why the round-robin algorithm is also known as the processor-sharing algorithm.
Weighted Round Robin Approach

– The weighted round-robin algorithm has been used for scheduling real-time traffic in
high-speed switched networks.
– Rather than giving all the ready jobs equal shares of the processor, different jobs may be
given different weights.
– The weights refer to the fraction of the processor time allocated to the job.
– A job with weight wt gets wt time slices every round.
– The length of the round equals the sum of the weights of all the ready jobs.
– By adjusting the weights of jobs we can speed up or slow down the progress of each job.
– By giving each job a fraction of the processor, a round-robin scheduler delays the
completion of every job.
– If round-robin scheduling is used to schedule precedence constrained jobs, the response
time of a chain of jobs can get very large.
– For this reason, the weighted round-robin approach is unsuitable for scheduling such
jobs.
– However if a successor job is able to consume incrementally what is produced by a
predecessor job, such as with a Unix pipe, weighted round-robin scheduling may be a
reasonable approach.
Priority Driven Approach

– The term priority-driven algorithms refers to a class of scheduling algorithms that never
leave any resource idle intentionally.
– With a priority-driven algorithm a resource idles only when no job requiring the resource
is ready for execution.
– Scheduling decisions are made when events such as releases and completions of jobs
occur.
– Priority-driven algorithms are event-driven.
– Other commonly used terms for this approach are greedy scheduling, list scheduling, and
work-conserving scheduling.
– A priority-driven algorithm is greedy because it tries to make locally optimal decisions.
– Leaving a resource idle while some job is ready to use the resource is not locally optimal.
– When a processor or resource is available and some job can use it to make progress, a
priority-driven algorithm never makes the job wait.
– However there are cases where it is better to have some jobs wait even when they are
ready to execute and the resources they require are available.
– The term list scheduling is also used because any priority-driven algorithm can be
implemented by assigning priorities to jobs.
– Jobs ready for execution are placed in one or more queues ordered by the priorities of the
jobs.
– At any scheduling decision time, the jobs with the highest priorities are scheduled and
executed on the available processors.
– Hence a priority-driven scheduling algorithm is defined largely by the list of priorities it
assigns to jobs.
– The priority list and other rules such as whether preemption is allowed, define the
scheduling algorithm completely.
– Most non real-time scheduling algorithms are priority-driven.

– Examples include:
– FIFO (first-in-first-out) and LIFO (last-in-first-out) algorithms which assign priorities to
jobs based on their release times.
– SETF (shortest-execution-time-first) and LETF (longest-execution-time-first) algorithms
which assign priorities based on job execution times.
– Because we can dynamically change the priorities of jobs, even round-robin scheduling
can be thought of as priority-driven.
– The priority of the executing job is lowered to the minimum among all jobs waiting for
execution after the job has executed for a time slice.
The following goals should be considered in scheduling a real-time system:

 Meeting the timing constraints of the system
 Preventing simultaneous access to shared resources and devices
 Attaining a high degree of utilization while satisfying the timing constraints of the
system; however this is not a primary driver.
 Reducing the cost of context switches caused by preemption
 Reducing the communication cost in real-time distributed systems; we should find the
optimal way to decompose the real-time application into smaller portions in order to have
the minimum communication cost between mutual portions (each portion is assigned to a
computer).
Real-Time Scheduling Policies
Real-time engineers use a number of different schemes for scheduling events. Some popular real-
time scheduling policies include:
Fixed Priority Preemptive Scheduling: Every task has a fixed priority that does not change
unless the application specifically changes it. A higher-priority task preempts a lower-priority
task. Most real-time operating systems support this scheme.
Dynamic-Priority Preemptive Scheduling: The priority of a task can change from instance to
instance or within the execution of an instance, in order to meet a specific response time
objective. A higher priority task preempts a lower-priority task. Very few commercial real time
operating systems support such policies.
Rate-Monotonic Scheduling: An optimal fixed-priority preemptive scheduling policy in which,
the higher the frequency (inverse of the period) of a periodic task, the higher its priority. This
policy assumes that the deadline of a periodic task is the same as its period. It can be
implemented in any operating system supporting fixed-priority preemptive scheduling or
generalized to a-periodic tasks.
Deadline-Monotonic Scheduling: A generalization of the rate-monotonic scheduling policy in
which the deadline of a task is a fixed point in time relative to the beginning of the period. The
shorter this (fixed) deadline, the higher the priority. When the deadline time equals the period,
this policy is identical to the rate-monotonic scheduling policy.
Earliest-Deadline-First Scheduling: A dynamic-priority preemptive scheduling policy. The
deadline of a task instance is the absolute point in time by which the instance must complete. The
deadline is computed when the instance is created. The scheduler picks the task with the earliest
deadline to run first. A task with an earlier deadline preempts a task with a later deadline. This

policy minimizes the maximum lateness of any set of tasks relative to all other scheduling
policies.
Least Slack Scheduling: A dynamic-priority non-preemptive scheduling policy. The slack of a
task instance is its absolute deadline minus the remaining worst-case execution time for the task
instance to complete. The scheduler picks the task with the shortest slack to run first.
This policy maximizes the minimum lateness of any set of tasks.
Real-Time Scheduling
A hard real-time system must execute a set of concurrent real-time tasks in such a way that all
time-critical tasks meet their specified deadlines. Every task needs computational and data
resources to complete the job. The scheduling problem is concerned with the allocation of the
resources to satisfy the timing constraints. Figure 2 given below represents classification of real-
time scheduling algorithms.
Real-Time scheduling can be categorized into hard vs soft. Hard real-time scheduling can be
used for soft real-time scheduling. Hard real-time scheduling can be broadly classifies into two
types: static and dynamic. In static scheduling, the scheduling decisions are made at compile
time. A run-time schedule is generated off-line based on the prior knowledge of task-set
parameters, e.g., maximum execution times, precedence constraints, mutual exclusion
constraints, and deadlines. So run-time overhead is small. On the other hand, dynamic
scheduling makes its scheduling decisions at run time, selecting one out of the current set of
ready tasks. Dynamic schedulers are flexible and adaptive. But they can incur significant
overheads because of run-time processing. Preemptive or non-preemptive scheduling of tasks is
possible with static and dynamic scheduling. In preemptive scheduling, the currently executing
task will be preempted upon arrival of a higher priority task. In non-preemptive scheduling, the
currently executing task will not be preempted until completion.
ONLINE VS OFF-LINE SHEDULING

The scheduling algorithms can be divided into off-line scheduling algorithms and online
scheduling algorithms. In offline scheduling all decisions about scheduling is taken before the
system is started and the scheduler has complete knowledge about all the tasks. During runtime
the tasks are executed in a predetermined order. Offline scheduling is useful if we have a hard
real-time system with complete know-ledge of all the tasks because then a schedule of the tasks
can be made which ensures that all tasks will meet their deadlines, if such a schedule exists.
In online scheduling the decisions regarding how to schedule tasks are done during the runtime
of the system. The scheduling decisions are based on the tasks priorities which are either
assigned dynamically or statically. Static priority driven algorithms assign fixed priorities to the
tasks before the start of the system. Dynamic priority driven algorithms assign the priorities to
tasks during runtime.
DYNAMIC VERSUS STATIC SYSTEMS
In multiprocessor based scheduling algorithms, jobs that are ready for execution being placed in
a priority queue common to all processors. When a processor is available, the job at the head of
the queue executes on the processor. Such a system is called a dynamic system, because jobs are
dynamically dispatched to processors.
In the example of priority scheduling we allowed each pre-empted job to resume on any
processor. We say a job migrates if it starts execution on a processor, is pre-empted, and later
resumes on a different processor.
An alternate approach to scheduling in multiprocessor and distributed systems is to partition the

jobs in the system into subsystems and to allocate the subsystems statically to particular
processors. In such systems, jobs are moved between processors only when the system must be
reconfigured such as when a processor fails. We call such systems, static systems, because the
system is statically configured.
If jobs on different processors are dependent the schedulers on the processors must synchronize
the jobs according to some synchronization and resource access-control protocol. Otherwise,
jobs on each processor are scheduled by themselves
For example we could do a static partitioning of the jobs in our priority-driven scheduling
example.
Put J1, J2, J3, J4 on P1 and the remaining jobs on P2.
The priority list is segmented into two parts:
• (J1, J2, J3, J4) used by the scheduler of processor P1
• (J5, J6, J7, J8) used by the scheduler of processor P2
It is easy to see that the jobs on P1 complete by time 8 and the jobs on P2 complete by time 11.
Also J2 completes by time 4 while J6 starts at time 6, thus the precedence constraint is satisfied.
In this example the response of the static system is just as good as that of the dynamic system. In
general we may expect that we can get better average response by dynamically dispatching and
executing jobs. While dynamic systems may be more responsive on average, their worst case
real-time performance may be poorer than static systems.
More importantly, there exist no reliable techniques for validating the timing characteristics of
dynamic systems, whereas such techniques exist for static systems. For this reason, most hard
real-time systems implemented today are static.

EFFECTIVE RELEASE TIMES AND DEADLINES

• The given release times and deadlines are sometimes inconsistent with the precedence
constraints of the jobs.
– i.e. the release time of a job may be later than that of its successors, and its
deadline may be earlier than that of its predecessors.
• Rather than working with the given release times and deadlines, we first derive a set of
effective release times and deadlines from these timing constraints together with the
given precedence constraints.
• These derived timing constraints are consistent with the precedence constraints.
• Where there is only one processor we can compute the derived values:
– Effective Release Time:
• The effective release time of a job without predecessors is equal to its
given release time.
• The effective release time of a job with predecessors is equal to the
maximum value among its given release time and the effective release
times of all its predecessors.
– Effective Deadline:
• The effective deadline of a job without a successor is equal to its given
deadline.
• The effective deadline of a job with successors is equal to the minimum
value among its given deadline and the effective deadlines of all of its
successors.
• The effective release times of all the jobs can be computed in one pass through the
precedence graph in O(n2) time where n is the number of jobs. Similarly for the effective
deadlines.
• Consider the following example whose task graph is given in the following figure
“example of effective timing constraints”
• Consider the following example whose task graph is given in figure “example of
effective timing constraints”
• The numbers in brackets next to each job are its given release time and deadline.
• Because J1 and J2 have no predecessors, their effective release times are their given
release times, 2 and 0 respectively.
• The given release time of J3 is 1, but the latest effective release time of its predecessors is
2 (that of J1) so its effective release time is 2.
The effective release times of J4, J5, J6, J7 are 4, 2, 4, 6 respectively.

• J6 and J7 have no successors so their effective deadlines are their given deadlines, 20 and
21 respectively.
• Since the effective deadlines of the successors of J4 and J5 are later than the given
deadlines of J4 and J5, the effective deadlines of J4 and J5 are equal to their given
deadlines, 9 and 8 respectively.
• However the given deadline of J3 (12) is larger than the minimum value (8) of its
successors, so the effective deadline of J3 is 8.
Static scheduling
– A fixed schedule is determined statically
– E.g., Cyclic Executive
Static-priority scheduling
– Assign fixed priorities to processes
– A scheduler only needs to know about priorities
– E.g., Rate Monotonic (RM)
Dynamic-priority scheduling
– Assign priorities based on current state of the system
– E.g., Least Completion Time (LCT), Earliest Deadline First (EDF), Least Slack Time
(LST)
Static Scheduling Algorithms

In static scheduling, scheduling decisions are made during compile time. This assumes
parameters of all the tasks is known a priori and builds a schedule based on this. Once a schedule
is made, it cannot be modified online. Static scheduling is generally not recommended for
dynamic systems. Applications like process control can benefit from this scheduling, where
sensor data rates of all tasks are known beforehand. There are no explicit static scheduling
techniques except that a schedule is made to meet the deadline of the given application under
known system configuration. Most often there is no notion of priority in static scheduling. Based
on task arrival pattern a time line is built and embedded into the program and no change in
schedules are possible during execution.
• Static scheduling is used for scheduling periodic tasks, whereas dynamic scheduling is
used to schedule both periodic and aperiodic tasks.
Cyclic Executives
A cyclic executive consists of continuously repeated task sequences, known as major frames.
Each major frame consists of a number of small slices of time, known as minor frames; tasks are
scheduled into specific minor frames.
• A timeline uses a timer to trigger a task every minor cycle (or frame).
• A non-repeating set of minor cycles makes up a major cycle.
• The operations are implemented as procedures, and are placed in a pre-defined list
covering every minor cycle.
• When a minor cycle begins, the timer task calls each procedure in the list.
• Concurrency is not used; long operations must be manually broken to fit frames.

Below is a sample cyclic executive; it consists of minor frames and major frames. Major frames
repeat continuously. Within a minor frame, one or more functions execute. Suppose that a minor
frame is 10 ms long. Consider 4 functions that must execute at a rate of 50 Hz, 25
Hz, 12.5 Hz, and 6.25 Hz respectively (corresponding to a period of 20 ms, 40 ms, 80 ms, and
160 ms respectively). A cyclic executive can execute them as follows. Note that one minor frame
lies idle in the major frame and can lend itself to future expansion.
RM Scheduling
The following assumptions are made for both the RM and EDF algorithms.
(a) No task has any non-preemptable section and the cost of preemption is negligible.
(b) Only processing requirements are significant; memory, I/O, and other resource requirements
are negligible.
(c) All tasks are independent; there are no precedence constraints.
It is a uniprocessor static-priority preemptive scheme. For the RM scheduling algorithm, in

addition to assumptions (a) to (c), we assume that all tasks are periodic and the priority of task
Ti is higher than the priority of task Tj, where i<j
The RM scheduling algorithm is an example of priority driven algorithms with static priority
assignment in the sense that the priorities of all instances are known even before their arrival.
The priorities of all instances of each task are the same. They are determined only by the period
of the task.

The RM algorithm takes O((N+α)2))) ,time in the worst case, where N is the total number of the
requests in each hyper-period of n periodic tasks in the system and α is the number of aperiodic
tasks.
Rate Monotonic Algorithm (RMA)
Rate monotonic algorithm is a dynamic preemptive algorithm based on static priorities. The rate
monotonic algorithm assigns static priorities based on task periods. Here task period is the time
after which the tasks repeat and inverse of period is task arrival rate. For example, a task with a
period of 10ms repeats itself after every 10ms. The task with the shortest period gets the highest
priority, and the task with the longest period gets the lowest static priority. At run time, the
dispatcher selects the task with the highest priority for execution. According to RMA a set of
periodic, independent task can be scheduled to meet their deadlines, if the sum of their utilization
factors of the n tasks is given as below.
Schedulability check for RMS
A set of n tasks is schedulable on a uniprocessor by the RMS algorithm if the processor

utilization (utilization test):
The term n(21/n -1) approaches ln 2, (0.69 as n  ).
This condition is sufficient, but not necessary.
RMS is an optimal preemptive scheduling algorithm with fixed priorities.

Static/fixed priority algorithm assigns the same priority to all the jobs (instances) in each task.
Example:
Task set: Ti = (ci, pi)

T1 = (2,4) and T2 = (1,8)
Schedulability check:
2/4 + 1/8 = 0.5 + 0.125 = 0.625 ≤ 2(√2 -1) = 0. 82

Therefore we can say tasks T1 and T2 are schedulable using RMS algorithm.
Example 2:
Task set: Ti = (ci, pi)

T1 = (2,4) and T2 = (4,8)
2/4 + 4/8 = 0.5 + 0.5 = 1.0 > 2(√2 -1) = 0. 82

This set of tasks fails schedulability check but still these tasks are schedulable.
Some task sets that FAIL the utilization-based schedulability test are also schedulable under
RMS  We need exact analysis (necessary & sufficient)
So we have other check

Necessary Condition: A set of periodic real-time tasks would not be RMA schedulable unless
they satisfy the following necessary condition:

Where ei is the worst case execution time and pi is the period of the task Ti, n is the number of
tasks to be scheduled, and ui is the CPU utilization due to the task Ti. This test simply expresses
the fact that the total CPU utilization due to all the tasks in the task set should be less than 1.
EDF / DM Scheduling
The EDF scheduling algorithm is a priority driven algorithm in which higher priority is assigned
to the request that has earlier deadline, and a higher priority request always preempts a lower
priority one. This scheduling algorithm is an example of priority driven algorithms with dynamic
priority assignment in the sense that the priority of a request is assigned as the request arrives.
EDF is also called the deadline-monotonic scheduling algorithm.
Suppose each time a new ready task arrives, it is inserted into a queue of ready tasks, sorted by
their deadlines. If sorted lists are used, the EDF algorithm takes O((N+α)2))) ,time in the worst
case, where N is the total number of the requests in each hyper-period of n periodic tasks in the
system and α is the number of aperiodic tasks.
Earliest Deadline-First (EDF) Algorithm:
EDF algorithm is an optimal dynamic preemptive algorithm based on dynamic priorities. In this
after any significant event, the task with the earliest deadline is assigned the highest dynamic
priority. A significant event in a system can be blocking of a task, invocation of a task,
completion of a task etc. The processor utilization can up to 100% with EDF, even when the task
periods are not multiples of the smallest periods. The dispatcher operates in the same way as the
dispatcher for the rate monotonic algorithm.
Schedulability check for EDF/DM algorithm
A set of n tasks is schedulable on a uniprocessor by the EDF algorithm if the processor

utilization.
This condition is both necessary and sufficient.
Example:
Task set: Ti = (ci, pi, di)

T1 = (1,3,3) and T2 = (4,6,6)
1/3 + 4/6 = 0.33 + 0.67 = 1.0
As it satisfies the condition so we can say these tasks can be schedulable using EDF algorithm.

The Priority Ceiling Protocol:
The priority ceiling protocol is used to schedule a set dependant periodic tasks that share
resources protected by semaphores. The shared resources, e.g., common data structures are used
for inter-process communication. The sharing of resources can lead to unbounded priority
inversion. The priority ceiling protocols were developed to minimize the priority inversion and
blocking time.
Least Laxity First (LLF)/Least Slack Time First (LSTF) algorithm:
Least laxity First (LLF), also known as least slack time, is a dynamic priority driven scheduling
algorithm that assigns priority based on the laxity. The definition of laxity is the tasks deadline
minus the remaining computation time of the task. It can also be described as the maximum time
a task can wait before it needs to execute in order to meet its deadline. The task with the
currently least laxity is assigned the highest priority and is therefore executed. The executing
task will be preempted by any other task with a currently smaller laxity. When the task is
executing the laxity remains constant. If two tasks have similar laxity they will continually
preempt each other and it will therefore create many context switches. But if we ignore the cost
of the context switches LLF is also, as EDF, an optimal dynamic scheduling algorithm.

UNIT-4
Aperiodic scheduling
Assumptions and Approaches
All the tasks are Preemptive in nature and priority-driven algorithms are used for scheduling.
All the tasks/jobs are independent of one another with arbitrary interrelease times.
Timing parameters not necessarily known on release
Execution time of sporadic jobs known after they are released,
Sporadic jobs that cannot complete in time are rejected.
Periodic tasks meet all their deadline, according to some scheduling algorithm, when there are no
aperiodic and sporadic jobs.
The operating system maintains three priority queues:
• Periodic jobs,
• Aperiodic jobs,
• Sporadic jobs, preceded by an acceptance test.
Objective:
• A correct (aperiodic and sporadic jobs) scheduling algorithm produces correct schedules:
periodic and accepted sporadic jobs never miss their deadlines.
• An optimal aperiodic jobs scheduling algorithm minimizes the response time of the aperiodic
job at the head of the queue, or the average response time of all aperiodic jobs.
• An optimal algorithm for accepting and scheduling sporadic jobs accepts a sporadic job only
if it can be correctly scheduled.
• Three common used approaches: Background, polled and interrupt-driven approaches.
Approaches: Aperiodic
 Background: Aperiodic tasks are executed when there is no periodic task to execute.
It is simple to implement, but no guarantee on aperiodic schedulability nor response
time.
Example: T1 = (3, 1) and T1 = (10, 4). RMA is used. An aperiodic task A is released at
0.1 (ea = 0.8).

Response time = 7.7
 Interrupt-driven: the arrival of an aperiodic task triggers an interrupt. CPU runs the
task as an Interrupt service routine.
Execution of periodic tasks is interrupted and the aperiodic job is executed. Due to this
Periodic task may miss their deadlines.
 Slack-Stealing: postpone execution of periodic tasks only when it is safe to do so
o Well-suited for clock-driven environments.
o What about priority-driven environments? (quite complicated)
 Periodic server/Polling server: defined by (ps, es). with a polling period ps and a
reserved execution time es . In this the system schedule polling server as a periodic task.
It the start of period it examines the aperiodic task queue, if there is any aperiodic task in
the queue it executes that task for almost es time period. If empty, the server suspends
itself during its current period and gets invoked again at its next period. The
computation time allowance for the server is replenished at the start of its period
Idea:
• Consider that all hard tasks are periodic
• Create a periodic task (a periodic server) with period Ts and capacity Cs (the
allowed computing time in each period)
• Schedule the server as a periodic task (Cs, Ts)
Run time behaviour:
• Once the server is active, it serves all pending (buffered) aperiodic requests within
its capacity Cs according to other algorithms e.g FCFS, SJF etc
• If no aperiodic requests, the capacity is lost: if a request arrives after the server
has been suspended, it must wait until the next polling period
Periodic Server: a task that behaves like a periodic task, and is created for purpose of
executing aperiodic jobs.
es is called the (execution) budget.
us = es / ps is called the size of the server.
At the beginning of each period, the budget is replenished by (set to) es.
The periodic server is backlogged if the aperiodic job queue is nonempty. It is idle
elsewhere.
The server is eligible for execution only when it is backlogged and has budget.

When the server is scheduled and executes aperiodic jobs, it consumes its budget at the
rate of one per time unit.
When the budget becomes zero, the server is exhausted.
Example:
Poller: (2.5, 0.5). According to RMA, it has the highest priority.
 Bandwidth-preserving server: Improves on the periodic server by preserving budget

(bandwidth) when aperiodic queue is empty:
Algorithms that improve the polling approach: the budget is preserved when the aperiodic
job queue is empty; the poller is allowed to execute later in the period if any aperiodic job
arrives.
Assumptions:
• A backlogged bandwidth-preserving server is ready for execution when it has
budget. The scheduler suspends the server when it is exhausted or idle. The
scheduler moves the server back to the ready queue once it replenishes the server
budget if the server is backlogged.
• The server suspends itself when it becomes idle. The scheduler puts the server
back to the ready queue when it (the server) becomes backlogged again if it has
budget.
Example of bandwidth-preserving servers
o Deferrable servers
o Sporadic Server
o Constant utilization and Total bandwidth servers
Deferrable Servers
It is the simplest of bandwidth-preserving servers. When no aperiodic job is ready for execution,
Deferrable Servers preserves its budget.
 Aperiodic requests arrive at a queue.
 The head of queue request checks if there is budget available.
 If there is a budget left,

o the aperiodic request runs until either the request is served or the budget is
exhausted
o and therefore the aperiodic request is suspended until there is new budget
available
 else the aperiodic request is suspended and it waits until there is new budget available
 When the budget >> requests workload, requests seldom suspend. It has interrupt like
service if the deferrable server is running at a high priority.
 When the budget << requests workload, it behaves just like polling.
Consumption rule: Budget is consumed at the rate of one per unit time.
Replenishment rule: Budget is set to es (no accumulation) at instants kps, for k = 0, 1, 2, ...
Example: T1 = (2.0, 3.5, 1.5), T2 = (6.5, 0.5), TDS = (3, 1). RMA is used.
A arrives at 2.8; e = 1.7
It is similar to Polling server. The only difference is that the capacity of Deferrable Server will be
preserved if no pending requests upon the activation of the server. The capacity is maintained
until the end of the server, within the period, an aperiodic request will be served; thus improving
average response time
Sporadic Servers
Deferrable Server may delay lower-priority tasks. Whereas Sporadic Servers (SS) rules ensure
that each sporadic server (ps, es) never demands more processor time than the periodic task (ps,
es).
Sporadic Server in Fixed-Priority Systems: Notations

• T: system of n independent, preemptable periodic tasks.
• TH: subset of periodic tasks with higher priorities than the server priority.
• T/ TH are either busy or idle.
• Server busy interval: [an aperiodic job arrives at an empty queue, the queue becomes
empty again].
• tr: the latest (actual) replenishment time.
• tf: the first instant after tr at witch server begins to execute.
• te: the latest effective replenishment time.
• At any time t:
o BEGIN: beginning instant of the earliest busy interval among the latest
contiguous sequence of busy intervals of TH that started before t.
o END: end of the latest busy interval if this interval ends before t, infinity if the
interval ends after t.
Simple Sporadic Server

Consumption Rules: At any t > tr, budget is consumed at the rate of 1 per unit time until budget
is exhausted when
– C1: the server is executing
OR
– C2: the server has executed since tr and END < t.
• Replenishment Rules:
– R1: Initially when system begins execution and each time when budget is replenished, budget
= es and tr = current time.
– R2: At time tf, if END = tf then te = max(tr, BEGIN), if END < tf then te = tf. Next
replenishment time is te+ ps.
– R3: a) If te + ps is earlier than tf, budget is replenished as soon as it is exhausted.
b) If T becomes idle before te + ps and becomes busy again at tb, budget is replenished at
min(te + ps, tb).
Priority Exchange Server

• A periodic server task is created.
• When the server invoked, the server runs if there are any outstanding aperiodic tasks.
• If no aperiodic task exists, the high priority server exchanges its priority with a lower
priority periodic task for a duration of Cs’, where Cs’ is the remaining computation time
of the server.
• In this way, the priority of the server decreases, but its computation time is maintained.
• The computation time allowance for the server is replenished at the start of its period.
• As a consequence, the aperiodic tasks get low preference for execution. Offers worse
response time compared to Deferrable Server.
• Better schedulability bound for periodic task set compared to Deferrable Server.
Similar to Polling Server and Deferrable Server, Priority Exchange has a periodic server (usually
with high priority) for serving aperiodic tasks. The difference is in the way how the capacity of
the server is preserved
Run Time Behaviour:
If the PE server is currently the task with highest priority but there is no aperiodic
request pending, then the periodic task with next highest priority runs and the server is
assigned with the periodic task’s lower priority
Thus the capacity of the server is not lost but preserved with a lower priority (the
exchange continues until new aperiodic requests arrive)
The scheduling of the periodic server proceeds as follows:
At the start of its period, the periodic server is invoked, and services any aperiodic tasks (if any)
that are waiting. If after it finished servicing the aperiodic tasks, there is still time remaining,
then the aperiodic server exchanges priority with the highest-priority waiting periodic task. Thus,

the periodic task is now serviced, while the periodic server preserves the remainder of its run
time for later on in case that a new aperiodic task arrives. In such an event, the periodic server
resumes its normally high priority, pre-empts the periodic task and services the newly arrived
aperiodic task. If the periodic server has not exhausted its allotted run time processing waiting
aperiodic tasks, then a newly arriving aperiodic task will be serviced immediately.
A truth that we need to be aware of is. The Priority Exchange Algorithm does not "bank" time.
That is, the periodic server needs at least one waiting periodic task to exchange its priority with.
If no periodic tasks are waiting, no exchange takes place, and the periodic server simply idles
until the end of its run time, or until a periodic or aperiodic task arrives.
Slack Stealing
The interval that each task can be delayed without causing deadline miss is called the slack time.
The algorithm which uses slack time to delay periodic and sporadic tasks and execute aperiodic
tasks to shorten the response time is called slack-stealing algorithm. The Slack Stealing
algorithm (slack stealer) executes aperiodic jobs when the aperiodic job queue is non empty and
suspends itself when the aperiodic job queue is empty.
The scheduler monitors the available slack σ(t) in the system and:
- when σ(t) > 0, gives the slack stealer the highest priority.
- when σ(t) = 0, gives the slack stealer the lowest priority.
When executing, the slack stealer executes always the job at the head of the aperiodic job queue.
Problem: how to compute the slack σ(t) available in the system at time t ?. there are two
techniques to compute slack time by the slack stealer.
Static computation (initial slack computed off-line and updated by the scheduler at run time):
- reduced run-time overhead,
- reliable only when jitter in inter-release times is low
Dynamic computation:
- only possibility when jitter in inter-release times is high,
- high run-time overhead.
Flexible Computation
The term flexible computation refers to a broad class of applications that are designed and
implemented to trade off at run time the quality of the results they produce for the amout of time
and resources they use to produce the result. In particular, a flexible application can reduce its
time and resource demands at the expense of quality of its result. For as long as the user finds its
result quality acceptable, a flexible application can degrade gracefully when resources are scarce
and the demands of competing workloads are high.
In recent years, the flexible computation approach has been applied for various application like
signal processing and tracking, real time communication, real-time databases etc.

Flexible computation techniques can be broadly divided into two categories:

 Applications with firm quality
 Applications with firm deadline
Applications with firm quality: In these type of systems timeliness is of much concern. For many
real-time applications, a timely result of poor quality is better than a late result of the desired
quality. For example: surveillance and collision avoidance. It is better for the system to issue
timely warning, together with estimated location of the conflict traffic then a late command for
evasive action another example is voice transmission. While a poor quality voice encoded with
fewer bits may be tolerable, long pauses due to large transmission delay may not be. One way to
increase the likelihood of completion of firm quality application is to make them flexible, a
flexible job contains an optional component( or components) which can be discarded (i.e.,
left unexecuted) when necessary in order to reduce the job’s processor time and resource
demands by its deadline
Application with firm deadline does not have optional jobs. Nevertheless, it has flexibility
because the lateness of some jobs is acceptable, provided that some on time criterion is met.
A task is said to have (l,L) firm deadline constraint if at least l>=0 jobs among any consecutive
L>=l jobs in the task must complete in time. The parameter L is the failure window of the task.
So a hard real-time task has (1,1) deadline, while a soft real-time task has(0,L) deadlines.
Flexible Application Implementation methods
The Milestone Method: A task system and its underlying computation algorithm are said to be
monotone if the quality of the intermediate result produced by it is non-decreasing as it executes
longer. We can logically decompose each monotone task into a mandatory and an optional task.
A monotone task produces a precise result when the entire task completes. An approximate result
can be made available by recording the intermediate results produced by the system at
approximate instants of its execution, i.e., milestones. If the task is terminated before it is
completed, the approximate result produced by it at the time of its termination is the best among
all the intermediate results produced before its termination. This result is usable as long as its
mandatory task is completed. This method for returning approximate result is called the
milestone method.
The Sieve Method: A computation or a set of computations whose sole purpose is to produce
outputs that are at least as precise as the corresponding inputs is called a sieve function. If a sieve
function is executed, it improves the accuracy of its inputs. If it is skipped, processing time is
saved but at the expense of having less accurate values. Hence a task that carries out a sieve
function is optional. It is either completely executed or entirely skipped.
A sieve can be skipped in order to save time and resource. When it is skipped, the result is less
precise. Conversely when a sieve completes in time it improves the quality of the result. This
method for producing approximation results is called sieve method.
There is no benefit gained by completing a sieve in part. Therefore, we want to either execute
such optional task in completion before its deadline or skip it entirely. Therefore we say that the
execution of the optional task satisfies the 0/1 constraint.

The Multiple-Version Method: This method provides at least two versions of the task system:
the primary version and the alternate version(s). The primary version produces a precise result
but has longer processing time while an alternate version has a shorter processing time but only
produces an approximate and acceptable result. The alternate version corresponds to the
mandatory part of the task system. The difference between the two versions defines the optional
part. When multiple versions are used, it is necessary to decide before the task starts which
version will execute. Also, the optional part will be completely executed (primary version) or not
executed at all (alternate version). This requirement is also called a 0/1 constraint.
Basic Imprecise Computation Model
For many systems, having an approximate but usable result on a timely basis is better than
having a late and precise result. An approximate but usable result can often be produced by much
less processor time than a precise result. So, imprecise computation technique is applicable
whenever a task can produce an imprecise result in less execution time than it would take to
produce an exact one in order to conserve resources and eliminate timing faults.
In the traditional imprecise computation technique, a task is decomposed into mandatory subtask
and optional subtasks. All the mandatory subtasks must be executed for the system to produce
correct results. The execution of optional subtasks enhances the performance of the system as
long as the end-to-end deadline is not violated. On the other hand, in the proposed model, a task
is dealt with as a unit that cannot be decomposed. Tasks are identified as mandatory M or
optional O tasks according to their type (AND or OR tasks) as well as their position in the graph.
For instance, a maximal task (which is a task with no successors) is always an M task, while a
minimal task (which is a task with no predecessors) can be an O task. Also an AND task can be
an O task when it is a direct predecessor of an OR task in the graph, while the direct predecessors
of an M AND task are all M tasks.
The end-to-end deadline in the traditional imprecise computation model is defined as a special
deadline for each task from the starting subtask to the end subtask. In this case a set of deadlines
D=[d1,d2,…,dn] is associated with the set of tasks T=[T1,T2,…,Tn]. The global end-to-end
deadline EED of the proposed model is defined over the whole system between a starting task
and an end task of the system.
There are two types of imprecise computational tasks, namely, monotone tasks and 0/1
constraint tasks.
 A task is monotone if the quality of its intermediate result does not decrease as it executes
longer.
 An imprecise task with 0/1 constraint requires the optional part to be either fully
executed or not at all.
Applications of Imprecise Computations
 In image processing, it is often better to have frames of fuzzy images in time than perfect
images.
 In radar tracking, it is often better to have estimates of target locations in time than
accurate location data too late
Firm Deadline Model

A periodic task is said to have an (m,k)-firm guarantee if it is adequate to meet the deadlines of
m out of k consecutive instances of the task, where m ≤ k.
It is a popular model for soft real-time systems.
We consider a periodic real-time task set T={T1…..TN} where N is the number of tasks. Each
task is independent and characterized by Ti=(Ci,Pi,mi,ki), where Ci is Ti’s execution time, Pi is its
period, and mi and ki are its (m,k) firm deadline parameters. A set of N periodic tasks are
executed on M homogenous processors P={P1….Pm}. when Ti is subject to (m,k) firm deadline
constraint, its distance, Disti, represents the minimum number of consecutive deadline misses to
fall into dynamic failure. With respect to the distance, we classify tasks into urgent and non-
urgent. The Disti of urgent task Ti is one while that of non-urgent task Ti is greater than one.

UNIT-5
Resource access control

In many applications, real-time tasks need to share some resources among themselves. Often
these shared resources need to be used by the individual tasks in exclusive mode. This means
that a task that is using a resource, cannot immediately hand over the resource to other task that
requests the resource at any arbitrary point in time; but it can do so only after it completes its use
of the resource. If a task is preempted before it completes using the resource, then the resource
can be corrupted. Examples of such resources are files, devices, and certain data structures.
These resources are also called non-preemptable resources, or critical resources. Nowadays non-
preemptable resources are sometimes referred to as critical sections, though the original
operating literature used this term to refer to sections of code where some non-preemptable
resource is used in exclusive mode.
Sharing of critical resources among tasks require s a different set of rules, compared to the rules
used for sharing serially reusable resources such as a CPU among tasks.
Difference between serially reusable resource and non-preemptable resource/critical

resource.
Serially reusable resource
A task using serially reusable resource can be preempted and restarted at a later time without
any problem.
A serially reusable resource is one which is used in exclusive mode, but a task using it may at
any time be preempted from using it, and then allowed to use it at some later time without
affecting the correctness of the computed results. CPU is an example of serially reusable
resource.
Non-preemptable / critical resource

A task using a non-preemptable resource on the other hand cannot be preempted from the
resource usage, otherwise the resource would become inconsistent and can lead to system failure.
A non-preemptable resource is also used in exclusive mode. Therefore, when a lower priority
task has already gained access to a non-preemptable resource and is using if, even a higher
priority task would have to wait until the lower priority task using the resource completes.
Priority Inversion problem

When a lower priority task is already holding a resource, a higher priority task needing the same
resource has to wait and cannot make progress with its computations. The higher priority task
remains blocked until the lower priority task releases the required non-preemptable resource. In
this situation, the higher priority task is said to undergo simple priority inversion on account of
the lower priority task for the duration it waits while the lower priority task keeps holding the
resource. This problem is called priority inversion problem. In this situation, the higher priority
task is said to undergo simple priority inversion on account of the lower priority task for the
duration it waits while the lower priority task keeps holding the resource.
It should be obvious that simple priority inversions are often unavoidable when two or more
tasks share a non-preemptable resource. Fortunately, a single simple priority inversion is not
really that difficult to cope with. The duration for which a simple priority inversion can occure is
bounded by the longest duration for which a lower priority task might need a critical resource in
an exclusive mode. Therefore, a simple priority inversion can easily be tolerated through careful
programming. However, a more serious problem that arises during sharing of critical resource
among tasks is unbounded priority inversion.
Unbounded priority inversion

Unbounded priority inversion is a troublesome problem that programmers of real-time and
embedded systems often have to encounter. Unbounded priority inversion occurs when a higher
priority task waits for a lower priority task to release a resource it needs, and in the meanwhile
intermediate priority tasks preempts the lower priority task from CPU usage repeatedly; as a
result, the lower priority task cannot complete its usage of the critical resource and the higher
priority task waits indefinitely for its required resource to be released.
Unbounded priority inversions can upset all calculations of a programmer regarding worst case
response time for a real-time task and cause it to miss its deadline.
Consider a real-time application having a high priority task TH and a low priority task TL.
Assume that TH and TL need to share a critical resource R. Besides TH and TL assume there are
several tasks TI1, TI2, TI3,…… that have priorities intermediate between TH and TL, and do not
need the resource R in their computations. These tasks have schematically been shown in Figure.
Assume that the low priority task (TL) starts executing at some instant and locks the non-
preemptable resource as shown in figure. Suppose soon afterward, the high priority task (TH)
becomes ready, preempts TL and starts executing. Also assume that it needs the same non-
preemptable resource. It is clear that TH would block for the resource as it is already being held
by TL and TL would continue its execution. But, the low priority task TL may be preempted (
from CPU usage) by other intermediate priority tasks (TI1,TI2,…) which become ready and do
not require R. in this cae, the hish priority task (TH) would have to wait not only for the low
priority task (TL) to complete its use of the resource, but also all intermediate priority tasks
(TI1,TI2,…) preempting the low priority task to complete their computations. This might result in
the high priority task having to wait for the required resource for a considerable period of time.
In the worst case, the high priority task might have to wait indefinitely for a low priority task to
complete its use of the resource in the face of repeated preemptions of the low priority tasks by
the intermediate priority tasks not needing the resource. In such scenario, the high priority task is
said to undergo unbounded priority inversion.

The simplest way to avoid priority inversions is to prevent preemption (from CPU usage) of the
low priority task holding critical resource by intermediate priority tasks. This can be achieved by
raising the priority level of the low priority task to be equal to that of the waiting high priority
task. In other words, the low priority task is made to inherit the priority of the waiting high
priority task. This basic mechanism of a low priority task inheriting the priority of a high priority
task forms the central idea behind the priority inheritance protocol (PIP).
Priority Inheritance Protocol

The basic priority inheritance protocol (PIP) is a simple technique to share critical resources
among tasks without incurring unbounded priority inversions. The essence of this protocol is that
whenever a task suffers priority inversion, the priority of the lower priority task holding the
resource is raised through a priority inheritance mechanism. This enables it to complete its usage
of the critical resource as early as possible without having to suffer preemptions from the
intermediate priority tasks. When many tasks are waiting for a resource, the task holding the
resource inherits the highest priority of all tasks waiting for the resource (if this priority is greater
than its own priority). Since the priority of the low priority task holding the resource is raised to
equal the highest priority of all tasks waiting for the resource being held by it, intermediate
priority task cannot preempt it and unbounded priority inversion is avoided.
Working of priority inheritance protocol

The above figure shows four consecutive scenarios in the execution a system deployment PIP. In
each scenario, the executing task is shown shaded, and the blocked tasks are shown unshaded.
The priority changes that two tasks Ti and Tj undergo in the course of execution due to priority
inheritance is shown. Ti is a low priority task with priority 5 and Tj is a higher priority task with
priority 10. In scenario 1, Ti is executing and has acquired a critical resource CR. In scenario 2,
Tj has become ready and being of higher priority is executing. In scenario 3, Tj is blocking after
requesting for the resource R and Ti inherits Tj’s priority. In scenario 4, Ti has unlocked the
resource and has got back its original priority and Tj is executing with the resource.
It is clear that PIP can let real-time tasks share critical resources without letting them incur
unbounded priority inversions. However, it suffers to chain blocking and it does nothing to
prevent deadlines.
PIP is susceptible to chain blocking and it does nothing to prevent deadlocks.
Deadlock problem in PIP
The basic priority inheritance protocol (PIP) leaves open possibility of deadlocks. The following
example illustrates how deadlocks can occur in PIP. Consider the following sequence of actions
by two tasks T1 and T2 which need access to two shared critical resources CR1 and CR2.
T1: lock CR1, lock CR2, unlock CR2, unlock CR1

T2: lock CR2, lock CR1, unlock CR1, unlock CR2
Assume that T1 has higher priority than t2, t2 starts running first and locks critical resource CR2
(T1 was not ready at that time). After some time, t1 arrives, preempts T2, and starts executing.
After some time, T1 locks CR1 and then tries to lock CR2 which is being held by T2. As a
consequence T1 blocks and T2 inherits T1’s priority according to the priority inheritance
protocol. T2 resumes its execution and after some time needs to lock the resource CR1 being
held by T1. Now T1 and T2 are both deadlocked.

Chain Blocking problem in PIP

A task is said to undergo chain blocking, if each time it needs a resource, it undergoes priority
inversion. Thus if a task needs n resources for its computations, it might have to undergo priority
inversions n times to acquire all its resources.
Example that shows how chain blocking occurs

In the figure below assume that t1 needs several resources. In the first snapshot, a low priority
task t2 holding two resources CR1 and CR2, and a high priority task T1 arrives and requests to
lock CR1. It undergoes priority inversion and causes T2 to inherit its priority. In the second
snapshot, as soon as T2 releases CR1 its priority reduces to its original priority and T1 is able to
lock CR1. In the third snapshot, after executing for some time, T1 requests to lock CR2. This
time it again undergoes priority inversion since T2 is holding CR2. T1 waits until T2 releases
CR2. From this example, we see that chain blocking occurs when a task undergoes multiple
priority inversions to lock its required resources.
Priority Ceiling Protocol (PCP)

Priority Ceiling Protocol (PCP) extends the ideas of PIP to solve the problems of unbounded
priority inversion, chain blocking, and deadlocks, while at the same time minimizing inheritance-
related inversions. A fundamental difference between PIP and PCP is that the former is a greedy
approach whereas the latter is not. In PIP whenever a request for a resource is made, the resource
will be allocated to the requesting task if it is free. However, in PCP a resource may not be
granted to a requesting task even if the resource is free.
Resource sharing among tasks under PCP is regulating using two rules for handling resource
requests: resource grant and resource release.
Resource Grant Rule:

Resource grant rule consists of two clauses. These two clauses are applied when a task requests
to lock a resource.
1. Resource request clause:

If a task Ti is holding a resource whose ceiling priority equals CSC, then the task is
granted access to the resource.
Otherwise, Ti will not be granted CRj, unless its priority is greater than CSC (i.e. pri(Ti)>
CSC). In both (a) and (b) above, if Ti is granted access to the resource CRj and if CSC <
Ceil (CRj), then CSC is set to Ceil(CRj)
2. Inheritance clause: when a task is prevented from locking by failing to meet the resource
grant clause, it blocks and the task holding the resource inherits the priority of the
blocked task if the priority of the task holding the resource is less than that of the blocked
task.
Resource Release Rule

If a task release a critical resource it was holding and if the ceiling priority of this resource equals
CSC, then CSC is made equal to the maximum of the ceiling value of all other resource in use,
else CSC remains unchanged. The task releasing the resource either gets back its original priority
or the highest priority of all tasks waiting for any resources which it might still be holding,
whichever is higher.
Use of Priority- Ceiling Protocol in Dynamic Priority Systems

In dynamic priority systems, the priority of a task might change with time. As a consequence, the
priority ceilings of every resource needs to be appropriately recomputed each time a task’s
priority changes. In addition, the value of the CSC and the inherited priority values of the tasks
holding resources also need to be changed. This represents a high run time overhead. The high
run time overhead makes use of PCP in dynamic priority systems unattractive.

Afcat GK Questions 2018

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Afcat GK Questions 2018

Uploaded by

Copyright:

Available Formats

Real Time System notes as per RTU syllabus

What is a real time system?

Characteristics of Real Time Systems:

1 By: Vipin Saraogi (Asst Professor BKBIET Pilani)

2 By: Vipin Saraogi (Asst Professor BKBIET Pilani)

BASIC MODEL OF A REAL-TIME SYSTEM

A Model of a Real-Time System

Signal Conditioning Units:

There are two conditioning units used in real-time system

3 By: Vipin Saraogi (Asst Professor BKBIET Pilani)

1. Voltage Amplification: Voltage amplification is normally required to be carried out to

There are two interface units in a real-time system:

4 By: Vipin Saraogi (Asst Professor BKBIET Pilani)

TYPES OF REAL TIME SYSTEMS

Hard Real-time System Firm Real-time System Soft Real-time System

Hard real-time systems

5 By: Vipin Saraogi (Asst Professor BKBIET Pilani)

An anti-missile system: An anti-missile system consists of the following critical activities

Firm Real-Time systems

6 By: Vipin Saraogi (Asst Professor BKBIET Pilani)

Satellite-based tracking of enemy movements: Consider a satellite that takes pictures of an

Soft Real-Time system

7 By: Vipin Saraogi (Asst Professor BKBIET Pilani)

Parameters of a real-time task

Following are the parameters associated with a Real-time Task (Ti) :-

8 By: Vipin Saraogi (Asst Professor BKBIET Pilani)

● Criticality is a parameter related to the consequences of missing the deadline (typically, it

9 By: Vipin Saraogi (Asst Professor BKBIET Pilani)

Effect of Tardiness on hard and soft real-time systems

Difference between a Job & Task

Difference between Tardiness & Lateness

Based on the regularity of activation tasks can be classified as:

Aperiodic & Sporadic Tasks

 In aperiodic tasks, the activation of jobs is not regularly interleaved.

Periodic and Aperiodic Tasks

Release and Response Time

12 By: Vipin Saraogi (Asst Professor BKBIET Pilani)

Deadlines and Timing Constraints

• Completion time – the instant at which a job completes execution

Hard Real -Time System Soft Real-Time System

Real time Databases

Real-Time database occurs in many important applications:

15 By: Vipin Saraogi (Asst Professor BKBIET Pilani)

Real time processors and resources

Example: sliding-window scheme:

Real-Time workload model

Ji : Job-- Unit of work

16 By: Vipin Saraogi (Asst Professor BKBIET Pilani)

Release time may be classified as:

17 By: Vipin Saraogi (Asst Professor BKBIET Pilani)

Conditional Branch Dependency:

18 By: Vipin Saraogi (Asst Professor BKBIET Pilani)

19 By: Vipin Saraogi (Asst Professor BKBIET Pilani)

There are 2 types of edges in resource graphs

– This edge is an is-a-part-of edge.

– Some edges in resource graphs represent connectivity between components.

– These edges are called accessibility edges.

– Each accessibility edge may have several parameters.

– e.g. a parameter of an accessibility edge from a processor Pi to another Pk is the

PERIODIC TASK MODEL

21 By: Vipin Saraogi (Asst Professor BKBIET Pilani)

Periodic Jobs repeated at regular or semi-regular intervals.

• The maximum number of jobs in each hyperperiod is :