Rajib Mall Chapters 1,2,3

03/08/10 1 1

Characteristics of

Real-Time Systems

(Lecture 2)

Department Of Computer Science & Engineering

What is a Real-Time

System?

• A system is called real-time:

 Whenever we need to quantitatively express time to describe its

behaviour.

• Recall how to describe the

behaviour of a system?

 List inputs to the system and the corresponding system response.

03/08/10 3 3

Important Characteristics

• An embedded system responds to events.

Process New Data

External

Input Event External Output Event

Example: An Automobile airbag system.

When the airbag’s motion sensors detect a collision, the system needs to respond by deploying the airbag within 10ms or less.

Embedded Systems = Hardware + RTOS +Application Program

SENSORS _CONVERSIOND/A

DIAGNOSTIC PORT

SOFTWARE

A/D

CONVERSION CPU ACTUATORS

MEMORY HUMAN INTERFACE AUXILLARY SYSTEMS (POWER, COOLING) ELECTROMECHANICAL BACKUP & SAFETY

External

03/08/10 5 5

• An embedded system responds to

external inputs:

 If response time to an event is too long, the system fails.

• General purpose Operating

Systems:

 Not designed for real-time use

• Real-time Operating Systems:

 Help tasks meet their deadline.

Characteristics of An

Embedded System

•Real-time:

• Every real-time task is

associated with some time

constraints, e.g. a Deadline.

•Correctness Criterion:

• Results should be logically

correct,

03/08/10 7 7

Characteristics of an

Embedded System c

• Safety and Task Criticality:

 A critical task is one whose failure causes system failure (example:

obstacle avoidance).

 A safe system does not cause damage.

 A safety-critical real-time system is one where any failure causes severe damage.

Characteristics of an

Embedded System cont…

• Concurrency:



A RT system needs to respond to

several independent events.



Typically separate tasks process

each independent event.



For the same inputs, the result can

be different (

Non-determinism).

03/08/10 9 9

Characteristics of

Embedded Systems

• Distributed and Feedback

Structure

• Custom Hardware:

 An embedded system is often

implemented on custom H/W that is specially designed and developed for the purpose.

Characteristics of

Embedded Systems

03/08/10 11 11

Characteristics of Embedded

Systems

• Reactive:

 On-going interaction between computer and environment.

• Stability:

 Under overload conditions, work acceptably for at least important tasks.

Safety and Reliability

•Independent concepts in

traditional systems.

• A safe system does not cause

damage even when it fails.

• A reliable system operates for

long time without any failure.

03/08/10 13 13

Safety and Reliability

• In traditional systems, safety and

reliability are independent

concerns:

 A system can be safe and unreliable and vice versa.

 Give examples of:

• A safe and unreliable system • A reliable and unsafe system

Safety and Reliability

cont…

• Interrelated in safety-critical

system.



A safety critical system is one

for which any failure of the

system would result in severe

damage.

• Safety can be ensured only

through increased reliability.

03/08/10 15 15

Safety and Reliability

• An unreliable system can be made

safe upon a failure:

 By reverting to a fail-safe state.

• A fail-safe state:

 No damage can result if a system fails in this state.

 Example: For a traffic light, all

Fail-Safe State

• The fail-safe state of a word

processing program:

 The document being processed has been saved onto the disk.

• Fail-safe states help separate the

issues of safety and reliability.

 Even if a system is unreliable, it can always be made to fail in a fail-safe state.

03/08/10 17 17

Safety and Reliability

• For a safety-critical system

 No fail-safe state exists.

• Consider the navigation system on an aircraft:

• When the navigation system fails: • Shutting down the engine can be of

little help!

 As a result, for a safety-critical system:

• The only way to achieve safety is by making it reliable.

Safety-Critical

Systems

• A safety-critical system is one

for which a failure can cause

severe damages.

• A safety-critical system does

not have any fail-safe states:



Safety can only be ensured

through increased reliability.

03/08/10 19 19

How to Design a Highly

Reliable System?

–Error Avoidance

–Error Detection and

Removing

Fault Tolerance in RT

System

• The essential idea:

 Provide redundancy

• Hardware Fault-Tolerance:

 Masks the effects of a hardware fault.

• Software Fault-Tolerance:

 Masks the effects of a program fault.

03/08/10 21 21

Fault Tolerance in RT

System

–Hardware FT:

•Built in self test (BIST)

•Triple modular redundancy

–Software FT:

•N-Version programming

•Recovery Blocks

Triple Modular Redundancy

03/08/10 23 23

N-version Programming

• Software fault tolerance technique

inspired by TMR of hardware:

 Different teams are employed to develop the same software.

 Unsatisfactory performance in practice.

 Reason: Faults are correlated in the

different versions.

Recovery Blocks

03/08/10 25 25

Modern Embedded Systems

• Embedded systems incorporate:

 Application-specific hardware (ASICs, FPGAs etc.)

• performance, low power

 Programmable processors: DSPs, controllers etc.  Mechanical transducers and actuators

Application Specific HW Processor Cores Analog I/O Memory

Block Diagram of An

Embedded System

03/08/10 27 27

Some Basic Issues

(Lecture 3)

Dr. RAJIB MALL

Professor

Department Of Computer Science & Engineering

Why Have an OS in an

Embedded Device?

• Support for:

 Multitasking, scheduling, and synchronization

 Timing aspects.

 Memory management  File systems

 Networking

 Graphics displays

 Interfacing wide range of I/O devices

 Scheduling and buffering of I/O operations  Security and power Management

03/08/10 29 29 • Example: A recent cell phone operating system

contained over five million lines of code!

• Few, if any projects will have the time and funding:

 To develop all of this code on their own!

• Typical Embedded OS license fees are a few dollars per device –-- less than a desktop OS

• Some very simple low-end devices might not need an OS:

 But new devices are getting more complex.

Why Have an OS in an

Embedded Device?

What is Actually Being Used?

• What Types of Processors are used? • What Operating Systems are used? • What Programming Languages are

used?

• Will examine data from a 2006 Market Survey of design engineers:

03/08/10 31 31

Processor Bit Size Used in

New Embedded Designs

Data was derived from EETimes and Embedded Systems Design Magazine 2006 Embedded Market Survey

0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 60.00% 4-bit 8-bit 16-bit 32-bit 64-bit

Processor Architectures Widely

Used in New Embedded Designs

• ARM

• X86

• PowerPC

• MIPS

• Xscale (ARM)

• Renesas SuperH

03/08/10 33 33

32-64 bit Annual

Processor Sales

Processor Sales Volume

Number of Processors Used

in New Embedded Designs

Data was derived from EETimes and Embedded Systems Design Magazine 2006 Embedded Market Survey

0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 60.00% More Than 5

3-5 Processors 2 Processors 1 Processor

03/08/10 35 35

Processor Selection Issues

• Software Support

 OS, Compilers, Debug Tools, Applications

• Price

• Performance • Power

 Battery Life (MIPS/Watt), Cooling (Fan?)

• Desktop PC 100 W vs. Battery power 200 mw

• Availability

Use of Real-Time OS Kernels

in New Embedded Designs

0.00% 10.00% 20.00% 30.00% 40.00% 50.00% Open Source

Internally Developed None Commercial OS

03/08/10 37 37

Pros and Cons of Open

Source OS

• Embedded devices are

extremely cost sensitive:



Even a $1 license fee per device

can make a product

uncompetitive.

• For satisfactory performance:



The source code often needs to

be fine tuned.

Open Source OS: Cons

• “Free” OS can increase product development

cost:

 More time to develop device drivers, increased labor cost.

 More than offset the commercial OS license fees saved.

• Some other licenses may still required:

 Encoders & decoders, encryption, media player

• Open source license model may require:

03/08/10 39 39

Commercial Operating Systems

used in New Embedded Designs

0.00% 5.00% 10.00% 15.00% 20.00% 25.00% 30.00% Others Palm Green Hills Symbian Wind River Microsoft Emb.

Programming Languages Used

in New Embedded Designs

0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 60.00% 70.00% Others Assembly Java C# C++ C

03/08/10 41 41

Future of Embedded

Systems

• Use of multi-core processors:



Present operating systems and

tools do not make satisfactory

utilization of the multiple cores.

• Support of wireless and mobile

Internet.

Modelling Timing

Constraints

(Lecture 4)

Dr. RAJIB MALL

Professor

Department Of Computer Science & Engineering

03/08/10 43 43

Types of Real-Time Systems

• Real-time systems are different from the traditional systems:

 Tasks have deadlines associated with

them.

• A classified based on the consequence of a failure:

 Hard real-time systems  Soft real-time systems  Firm real-time systems

Hard Real-Time Systems

• If a deadline is not met:

 The system is said to have failed.

• The task deadlines are of the order of micro or milliseconds.

• Many hard real-time systems are safety-critical.

• Examples:

 Industrial control applications  On-board computers

03/08/10 45 45

Firm Real-Time Systems

• If a deadline is missed occasionally,

the system does not fail:

 The results produced by a task after the deadline are rejected.

Utility

Firm Real-Time Systems

• Examples:



A video conferencing application



A telemetry application



Satellite-based surveillance

applications

03/08/10 47 47

Soft Real-Time Systems

• If a deadline is missed, the system

does not fail:

 Only the performance of the system is said to have degraded.

 The utility of a result decreases with time after the deadline.

Utility

Soft Real-Time Systems

• Examples of soft real-time

systems:



Railway reservation system



Web browsing

03/08/10 49 49

Types of Real-Time Tasks

 Periodic:

• Periodic tasks repeats after a certain fixed time interval.

 Sporadic:

• Sporadic tasks recurs at random instants.

 Aperiodic:

• Same as sporadic except that minimum separation between two instances can be 0.

Timing Constraints

• A timing constraint:



Defined with respect to some

event.

• An event:



Can occur at an instant of time



May also have duration



Generated either by the system

or its environment

03/08/10 51 51

Events in a Real-Time

System

• Events in a real-time system

can be classified into:



Stimulus Events

Stimulus Event

• Generated by the environment:

 Act on the system.

• Typically asynchronous in nature:

 Aperiodic

 Can also be periodic

• Example:

 A user pressing a button on a telephone set

 Stimulus event acts on the telephone system.

Telephone System

03/08/10 53 53

Stimulus Event

cont

…

• Periodic stimulus event example :

 Periodic sensing of temperature in a

Response Event

• Produced by the system:

 In response to some stimulus events

• Example:

 In a chemical plant as soon as the temperature exceeds 100°C,

 The system responds by switching off the heater.

03/08/10 55 55

Classification of Timing

Constraints

• Classification of the timing

constraints in a system:



Can help us to quickly identify

these from a problem

description.

Classification of Timing

Constraints

• Different timing constraints

can broadly be classified into:



Performance constraints

03/08/10 57 57

Types of Timing

Constraints

• Performance constraints:



Imposed on the response of

the system.

• Behavioral constraints:



Imposed on the stimuli

generated by the

environment.

Types of Timing

Constraints

• Both performance and

behaviorial constraints can

be classified into:



Delay Constraints



Deadline Constraints

03/08/10 59 59

Delay Constraint

• Expresses

minimum

time delay:



Allowed between the occurrence

of two arbitrary events e1 and e2



t(e2) - t(e1) ≥ d



if e2 occurs earlier than d then a

delay violation would occur.

t(e1) t(e2)

Deadline Constraint

• Expresses the maximum

permissible separation:



Between any two arbitrary

events.

03/08/10 61 61

Duration Constraint

• A duration constraint on an

event:



Specifies the time period over

which the event acts.

• A duration constraint can be:



minimum type

Duration Constraints

• Minumum:

 Once a duration event starts:

• It must not end before a certain minimum time.

• Maximum:

 Once a duration event starts:

• It must end before a certain maximum time. _{t(e1) t(e2)}

t(e1) t(e2) Min

03/08/10 63 63

Timing Constraints in

an Example System

SS Deadline Example

• Deadline is defined between two stimuli.

 A behavioral constraint.  Imposed on stimulus.

• Once a user completes dialling a digit,

 He must dial the next digit within the

next 5 seconds.

 Otherwise an idle tone is produced.

03/08/10 65 65

RS Deadline Example

• Deadline is defined on the stimulus

from the respective response event.

 A behaviorial constraint.  Imposed on stimulus.

• Once the dial tone appears:

 The first digit must be dialed within 30

seconds,

 Otherwise the system enters

an idle state and an idle tone is produced

RR Deadline Example

• Deadline is defined on the

response from another response.



A performance constraint

.



Imposed on response.

• Once ring tone is given to the callee,

 Ring back tone must be given to the caller within two seconds,

 Otherwise the call is terminated.

03/08/10 67 67

SR Deadline Example

• Deadline is defined on the response

from the respective stimulus.

 A performance constraint.  Imposed on response.

• Once the receiver of the hand set is

lifted:

 The dial tone must be produced by the system within 2 seconds,

 otherwise a beeping sound is produced until the handset is replaced.

SS Type Delay

Constraint

• A behaviorial constraint.

 Imposed on the environment.

• Once a digit is dialled,

 The next digit should be dialled after at least 1 second.

 Otherwise, a beeping sound is produced until the call initiator replaces the handset.

03/08/10 69 69

Duration Constraint

• Specifies the time interval over which the event acts.

• If you press the button of the handset for less than 15 seconds,

 It connects to the local operator.

• If you press the button for any duration lasting between 15 to 30 seconds,

 It connects to the international operator.

• If you keep the button pressed for more than 30 seconds,

 Then on releasing it would produce the dial tone.

Timing Constraints

Behaviorial Constraints Performance Constraints

Delay Deadline Duration

RR SR RR SR

Delay Deadline Duration

03/08/10 71 71

Modelling Timing

Constraints

(Lecture 5)

Department Of Computer Science & Engineering

Why Model Timing

Constraints?

• Modelling time constraints in a

system:

 Can serve as a formal specification of the system.

 May be used to automatically generate code.

 Can help to understand real-time behavior.

03/08/10 73 73

Modelling Time

Constraints

• Several approaches can be used.

 We discuss an approach based on FSM

proposed by Dasarathy (IEEE TSE, 1985).

• A state is defined in terms of the values assumed by some attributes.

 The states of an elevator may be denoted in terms of its directions of motion.

 Values of the attribute direction define the states up, down, and stationery.

FSM

• Transition is annotated with:

 Enabling event

 Action that takes place during transition

S1

S2

03/08/10 75 75

Model of SS Deadline

Constraint

• Once a user completes dialling a digit,

 He must dial the next digit within the next 5 seconds.

 Otherwise an idle tone is produced.

Await second digit Await Next digit Await Caller Onhook

Model of RS Deadline

Constraint

 The first digit must be dialed within 30 seconds,  Otherwise the system enters

an idle state and an idle tone is produced

Await first digit Await Next digit Await Caller Onhook

03/08/10 77 77

Model of SR Deadline

Constraint

• Once the receiver is lifted from the hand set:

 The dial tone must be produced by the system within 2 seconds,

 Otherwise a beeping sound is produced until the handset is replaced. Await Dial tone Await first digit Await Receiver Onhook

Model of RR Deadline

Constraint

• Once ring tone is given to the callee,

 Ring back tone must be given to the caller within two seconds,

 Otherwise the call is terminated.

Await Ringback tone Await first digit Await Receiver Onhook

03/08/10 79 79

Model of Delay

Constraint

• Once a digit is dialled,

 The next digit should be dialled after at least 1 second.

 Otherwise, a beeping sound is produced until the call initiator replaces the handset.

Await next event Await next digit Await Receiver Onhook

Duration Constraint

Example

• If you press the button of the handset for less than 15 seconds,

 It connects to the local operator.

• If you press the button for any duration lasting between 15 to 30 seconds,

 It connects to the international operator.

• If you keep the button pressed for more than 30 seconds,

 Then on releasing it would produce the dial tone.

03/08/10 81 81

Model Construction for

Duration Example

• To construct the model:



First identify the deadline and

delay constraints.



The constraints are for which

events?

Model of Duration

Constraint Example

03/08/10 83 83

Exercise 1

• When the temperature of a

chemical reactor rises above

T°C:



The heater needs to be

shut-off within 10mSec



Otherwise, the entire plant is

shut-off.

Exercise 2

• Identify and model time

constraints:



Once the start switch of a

wash machine is pressed,



Stirring commences:

• Continues until a preset timer expires or the stop button is pressed by the user.

03/08/10 85 85

Basics of Real-Time

Task Scheduling

Department Of Computer Science & Engineering

Introduction

• Real-time tasks are generated due

to certain event occurrences:

 Either internal or external events.

• Example:

 A task may get generated due to a temperature sensor sensing high-level.

• When a task gets generated:

03/08/10 87 87

Real-Time Task Scheduling

• Task Scheduling:

 Essentially refers to the order in

which the various tasks are to be executed.

 Primary means adopted by an operating system to meet task deadlines.

 So, scheduling is an important

Task Instance

• A task typically recurs a large

number of times:

 Each time triggerred by an event

 Each time a task recurs, an

instance of the task is said to have been generated.

• The ith time a task T recurs:

 Task instance Ti is said to have arrived.

03/08/10 89 89

Relative and Absolute

Deadlines

• Absolute deadline:

 Counted from time 0.

• Relative deadline:

 Counted from time of occurrence of task.

abs

deadline

relative

Response Time

• The time from the occurrence of the event generating the task:

 To the time results are produced by the task.

Response time

03/08/10 91 91

Response Time

• For soft real-time tasks:



The response time needs to be

minimized.

• For hard real-time tasks:



As long as the task completes

within its deadline,

• No advantage of completing it any early.

03/08/10 92 92

Types of Real-Time Tasks

 Periodic:

• Periodic tasks repeats after a certain fixed time interval.

• A vast majority of real-time tasks are

periodic.

 Sporadic:

• Sporadic tasks recurs at random instants.

 Aperiodic:

• Same as sporadic except that minimum separation between two instances can be 0.

03/08/10 93 93

Phase of a Periodic

Task

• Phase for a periodic task:

 The time from 0 till the occurrence of the first instance of the task.

 Denoted by Φ.

Φ

0 _{e1 e2 e3} time

Phase Example

• The track correction task starts

2000 mSecs after the launch of

the rocket:

 Periodically recurs every 50 milli Seconds then on.

 Each instance of the task requires a processing time of 8 mSecs and its relative deadline is 50 mSecs.

Φ

0 e1 _e2 e3 time

03/08/10 95 95

Important Scheduling

Terminologies

– Valid Schedule:

• At most one task is assigned to a processor at a time.

• No task is scheduled before it is ready. • Precedence and resource constraints of

all tasks are satisfied.

– Feasible Schedule:

• Valid schedule is one in which all tasks meet their respective time constraints.

Important Scheduling

Terminologies

– Proficient Scheduler:

• A scheduler S1 is as proficient as another Scheduler S2:

• If whichever tasks that S2 can feasibly schedule so can S1, but not vice versa.

• Equally proficient schedulers:

• If a task set scheduled by one can also be scheduled by the other and vice versa.

03/08/10 97 97

Important Scheduling

Terminologies



Optimal Scheduler:

• An optimal scheduler can

feasibly schedule any task set

that can be scheduled by any

other scheduler.

Scheduling Points

• At these points on time line:

 Scheduler makes decision regarding which task to be run next.

• Clock-driven:

 Scheduling points are defined by interrupts from a periodic timer.

• Event-driven:

 Scheduling points defined by task completion and generation events.

03/08/10 99 99

Real-Time Task

Scheduling

• Significant amount of research

has been carried out to develop

schedulers for real-time tasks:

 Schedulers for uniprocessors

 Schedulers for multiprocessors and distributed systems.

Task Scheduling on

Uniprocessors

• Focus of much research

during the 1970s and 80s.

• Real-time task schedulers can

be broadly classified into:



Clock-driven



Event-driven

03/08/10 101 101

Clock-Driven Scheduling:

Basics

• Decision regarding which job to

run next is made only at clock

interrupt instants:

 Timers are used to determine the

scheduling points.

• Which task to be run when and

for how long is stored in a table.

Clock-Driven Scheduling

• Popular examples:



Table-driven scheduler



Cyclic scheduler

• Round robin scheduling is

also an example of

clock-driven scheduling.

03/08/10 103 103

Clock-Driven Schedulers

• Also called offline schedulers

and also static schedulers:



Used extensively in embedded

applications.

• Pro:

Very space and time

efficient.

• Con:

Cannot handle sporadic or

aperiodic tasks.

Table-Driven

Scheduling

TaskStart timeStop time

T1

0

100

T2

101

150

03/08/10 105 105

Cyclic Schedulers

(Lecture 7)

Dr. RAJIB MALL

Professor

Department Of Computer Science & Engineering

Task Scheduling on

Uniprocessors

• Focus of much research

during the 1970s and 80s.

• Real-time task schedulers can

be broadly classified into:



Clock-driven



Event-driven

03/08/10 107 107

Clock-Driven Scheduling

• For scheduling n periodic

tasks:



The schedule is stored in a

table.

•Repeated forever.



The designer needs to develop a

schedule for what period?

03/08/10 108 108

Clock-Driven Scheduling

• Used in low cost applications:



Pro:

• Compact: Require very little storage space

• Efficient: Incur very little runtime overhead.



Con:

• Inflexible: Very difficult to accommodate dynamic tasks.

03/08/10 109 109

Disadvantage of

Table-Driven Schedulers

• When the number of tasks are

large:



Requires setting a timer large

number of times.



The overhead is significant:

• Remember that task instance runs only for a few milli or microseconds.

Cyclic Schedulers

• Cyclic schedulers are very

popular:



Extensively being used in the

industry.



A large majority of small

embedded applications being

manufactured at present use

cyclic schedulers.

03/08/10 111

Cyclic Schedulers

• The schedule is stored for one

major cycle:

 Precomputed schedule is repeated.

• A major cycle is divided into:

 One or more minor cycles (frames).

• Scheduling points for a cyclic

scheduler:

Major Cycle

• In each major cycle:



The different tasks recur at

identical time points.

Major cycle Major cycle

03/08/10 113

Major Cycle

• The major cycle of a set of tasks

ST={T1,T2,...,Tn} is at least:



LCM(p1,p2,...,pn)



Holds even when tasks have

arbitrary phasings.



Can be greater than LCM when F

does not divide major cycle.

03/08/10 114 114

Minor Cycle (Frame)

• Each major cycle:



Usually contains an integral

number of

minor cycles

(frames).

• Frame boundaries are

marked:



Through interrupts from a

periodic timer.

03/08/10 115

A Typical Schedule

Task

Frame

Minor Cycle (Frame)

• Each task is assigned to run in

one or more frames.

• Frame size (F) is an important

design parameter while using

cyclic scheduler.



A selected frame size has to

03/08/10 117 117

Selecting an Appropriate Frame Size (F)

• Minimum context switch:

 F should be larger than each task size.

 Sets a lower bound.

• Minimization of table size:

 F should squarely divide major cycle.

 Allows only a few discrete frame

size.

• Satisfaction of task deadline:

 Between the arrival of a task and its deadline:

• At least one full frame must exist.

Minimum Context Switch

• A task instance must complete

running within its assigned

frame:

 A task might otherwise have to be suspended and restarted in a later frame.

 The scheduler would get invoked many times.

03/08/10 119

Minimum Context Switch

•To avoid unnecessary context switches:

• Selected frame size should be larger

than execution time of each task.

Minimization of Table Size

• Unless the minor cycle squarely

divides the major cycle:

 Storing schedule for one major cycle would not be sufficient.

 Schedules in the major cycle would not repeat: • This would make the size of the table large. Major cycle Major cycle

03/08/10 121

Major cycle Major cycle

Satisfaction of Task Deadline

• Between the arrival of a task and

its deadline:

 At least one full frame must exist.

• If there is not even a single frame:

 The task would miss its deadline,

• By the time it could be taken up for scheduling, the deadline could be

03/08/10 123 123

Satisfaction of Task

Deadline

• The worst case for a task occurs when the task arrives just after a frame has started.

ti di

ti _di

ti would miss deadline

Satisfaction of Task

Deadline

• The minimum separation of an

arrival time for ti from a frame

start:

 GCD(F,pi)

• Thus, for all ti

 2F-GCD(F,pi) ≤ di must be satisfied

ti di

03/08/10 125

Selection of a Suitable Frame Size

• Several frame sizes may satisfy the constraints:

• Plausible frames.

• A plausible frame size has been found:

• Does not mean that the task set is schedulable.

• The smallest plausible frame size needs to be chosen:

Example 1

• Compute a suitable frame

size for the following task

set:



e1 = 1, p1=4, d1=4



e2 = 1, p2=5, d2=5

03/08/10 127 127

Example 2

• Compute a suitable frame

size for the following task

set:



e1 = 1, p1=4, d1=4



e2 = 2, p2=6, d2=6

What If None of the Frame

Sizes is Suitable?

• Possible culprit is a task with large

execution time e.g. (20,100,100):

• Prevents a smaller frame from being chosen.

• Try splitting task with large execution time into two or three

sub-tasks.

• Example: T1=(20,100,100) can be split into (10,100,100) and (10,100,100).

03/08/10 129 129

Pros and Cons of Cyclic

Schedulers

• As number of tasks increases:



It becomes very difficult to

select a suitable frame size.



Results in suboptimal schedules.

• CPU times in many frames are wasted.

A Generalized Task Scheduler

• Many practical systems:

• Consist of a mixture of periodic, aperiodic, and sporadic tasks.

• How can sporadic and aperiodic tasks be scheduled using a

cyclic scheduler?

• Use the slack time and the unused frames:

03/08/10 131 cyclic-scheduler() { current-task T = SchedTab[k]; k = k + 1; k = k mod N; dispatch-current-Task(T); schedule-sporadic-tasks(); schedule-aperiodic-tasks(); idle(), }

Cyclic Scheduler:

Pseudocode

Event-Driven

Scheduling

(Lecture 8)

Dr. RAJIB MALL

Professor

Department Of Computer Science & Engineering

03/08/10 133

Event-Driven Schedulers

• Unlike clock-driven

schedulers:



These can handle sporadic

and aperiodic tasks.



Used in more complex

Event-Driven Scheduling

• Scheduling points:

 Defined by task completion and arrival events.

• Preemptive schedulers:

 On arrival of a higher priority task, the running task may be preempted.

• Simplest event-driven scheduler:

03/08/10 135 135

Scheduling Points for

Event-Driven Schedulers

• Scheduling decisions are

made when certain events

occur:

•A task becoming ready

Time-Sliced Round Robin Scheduling: A

Hybrid Scheduler

• Time-sliced round robin schedulers:

• Commonly used in the traditional operating systems.

• We shall not discuss much about it.

• Scheduling points:

• Tasks completing or suspending • Clock interrupts

• Less proficient than cyclic and table-driven

schedulers:

• Foreground task priorities not taken into account.

03/08/10 137 137

Event-Driven Schedulers

• These are called preemptive

schedulers:

 When a higher priority task

becomes ready any executing

lower priority task is preempted.

• These are greedy schedulers:

 Never keep the processor idle if a task is ready.

Preemptive Scheduling

• Independent tasks execute

on a uniprocessor.



Two algorithms pretty much

summarise the important

results in this case:

• EDF

• RMA

03/08/10 139 139

Foreground-Background Scheduler

• Real-time tasks are run as foreground tasks.

 Sporadic, aperiodic, and non-real-time tasks are run as background tasks.

• Among the foreground tasks, at every scheduling point:

 The highest priority foreground task is scheduled.

• A background task can run:

Background Task Completion Time

•Let T

be the only background task

• Its processing time be e_B

• The time for it to complete would be:







p

e

e

ct

1

03/08/10 141

Example 1

• Consider a real-time system:

• Tasks are scheduled using foreground-background scheduling.

• There is only one periodic foreground task:

• P1=50 msec, e1=100 msec, d1=100 msec

• Background task TB, eB=1020msec.

Example 2

•On account of every context

switch :

•Assume an overhead of 1 msec.

•Compute the completion time of

03/08/10 143 143

Event-Driven Static

Priority Schedulers

• The task priorities once

assigned by the programmer:



Do not change during runtime.



RMA (Rate Monotonic Algorithm)

is the optimal static priority

scheduling algorithm.

Event-Driven

Dynamic

Schedulers

• The task priorities can change

during runtime:



Based on the relative urgency

of completion of tasks.



EDF (Earliest Deadline First) is

the optimal uniprocessor

03/08/10 145 145

Event-Driven Schedulers

• First let us consider the

simplest scenario:



Uniprocessor



Independent tasks:

• Tasks do not share resources

• There is no precedence ordering

among the tasks

EDF

•

EDF is the optimal uniprocessor

scheduling algorithm:

• If EDF cannot feasibly schedule

a set of tasks:



Then, there can exist no other

scheduling algorithm to do that.

• Can schedule both periodic and

aperiodic tasks.

03/08/10 147

EDF

•At any scheduling point:

• The scheduler dispatches the task

having the shortest deadline among

all ready tasks.

• Preempts any task (with longer

deadline) that might be running.

EDF Schedulability Check

• Sum of utilizations due to all tasks is less

than one:

• Both the necessary and sufficient

condition for schedulability.

1









_p

u

e

03/08/10 149 149

Example 1

• Compute a suitable frame

size for the following task

set:



e1 = 1, p1=4, d1=4



e2 = 1, p2=5, d2=5

Is EDF Really a Dynamic Priority

Scheduling Algorithm?

•If EDF were a dynamic priority

algorithm:

• At any point of time, the priority value

of a task can be determined.

•Also we should be able to show how it

changes with time.

03/08/10 151

Dynamic Priority

• The longer a task waits in ready queue:

• The higher the chance (probability) of its being taken up for scheduling.

• We can imagine a virtual priority value

associated with a task:

• Keeps increasing with time until the task is taken up for scheduling

EDF: An Evaluation

• EDF is:

 Simple  Optimal

• But, is rarely used:



No commercial operating system

directly supports EDF scheduling.



Why?

• Let us examine the disadvantages of EDF.

03/08/10 153

Disadvantages of EDF

•Main disadvantages of EDF:

•Poor transient overload

handling

•Runtime inefficiency

•Poor support for resource sharing

among tasks.

Poor Transient Overload Handling

• Why does transient overload occur?

 A task might take more time than estimated.

 Too many tasks might arise on some event.

• When an executing task takes more

time:

 It is extremely difficult to predict which task would miss its deadline.

03/08/10 155 155

Runtime Inefficiency

• EDF is not very efficient:



In an implementation of EDF:

• The tasks need to be maintained sorted.

• A priority queue based on task deadlines is required.



The complexity of maintaining a

priority queue is:

Poor Resource Sharing Support

• Support for tasks to share

non-premptable resources (

critical

sections

):



Extremely inefficient.



Tasks often miss their



We shall elaborate this problem

later in our discussions.

03/08/10 157 157

General EDF Schedulability

• When task deadlines differ from task

periods:

 The schedulability criterion needs to be generalized:

• If pi<di, it becomes sufficient:

 But not a necessary condition

1

)

,

min(





d

p

e

Implementation of EDF

• Simple FIFO queue:



A freshly arriving task is

inserted at the end of the

queue.

• Sorted queue:

03/08/10 159 159

An Efficient

Implementation of EDF

• Maximum number of distinct

deadlines is fixed.

• A queue is maintained for each

distinct deadline.

• When a task arrives:



Its absolute deadline is

Efficient EDF Implementation

03/08/10 161

MLF: Variation of EDF

• Minimum Laxity First:

• Laxity= relative deadline – time required to complete task execution

• The task that is most likely to fail first is assigned highest priority.

• EDF=MLF when tasks have equal execution times and deadlines.

• Bonus problem:

Rate Monotonic

Scheduling

(Lecture 9)

Dr. RAJIB MALL

Professor

Department Of Computer Science & Engineering

03/08/10 163 163

RMA

• The priority of a task is

proportional to its frequency.

 The higher the frequency (or lower the period) of a task, the higher is its priority.

Frequency Priority

RMA

• The optimal uniprocessor static

priority scheduling algorithm:



If RMA cannot schedule a set of

periodic tasks:

• No other static priority scheduling algorithm can.

• Schedulability test:

03/08/10 165

Utilization Bound 1

• Sum of utilization due to tasks is less than

one:

• Necessary condition for schedulability:

• But not the sufficient condition.

1









_p

u

e

Sufficient Condition for RMA

Schedulability

• Utilization bound II (Liu and Layland 1971):

• ui is the processor utilization due to task Ti • n is the number of tasks

Utilization bound

)

1

2

(







_u

_n

03/08/10 167

Liu and Layland Bound

• The maximum utilization for a schedulable

task set:

• Falls as the number of tasks increases.

• For a very large number of tasks:

• What is the maximum utilization permitted?

692

.

0

2

ln

)

1

2

(













u

Example 1

• Check whether

the following

task set is schedulable

using

RMA:



T1: e1 = 1, p1=4, d1=4



T2: e2 = 2, p2=6, d2=6

03/08/10 169

Solution to Example 1

• Therefore the task set is schedulable.

1 15 11 60 44 20 3 3 1 4 1 1







03/08/10 170 170

Liu and Layland Condition

• The upper bound on utilization converges to 69% (ln2):

 As the number of tasks approaches

infinity

• Liu and Layland's condition is conservative:

 If a set of tasks passes Liu and Layland test, then it is definitely RMA schedulable.

 But, even if a task set fails Liu-Layland

test:

• Still it may be RMA schedulable (completion time theorem).

03/08/10 171 171

Example 2

• Check RMA schedulability of three periodic tasks:

 T1: e1=20mSec, p1= d1= 100mSec

 T2: e2=40msec, p2= d2= 150mSec

 T3: e3=100mSec, p3= d3= 350mSec

• The utilization for these 3 tasks are

 0.2+0.267+0.286=0.753

• Liu-Layland bound=3((2)1/3_{-1) =0.779}

Some More Issues in

RMA Scheduling

(Lecture 10)

Dr. RAJIB MALL

Professor

Department Of Computer Science & Engineering

03/08/10 173

RMA Schedulability

• Utilization bound 1:

• Utilization bound 2:

(Liu-Layland)

• Schedulability check 3: Liu and Lehoczky’s Completion

Time Theorem

1









_p

u

e

)

1

2

(







_u

_n

RMA Schedulability Test- III

• Completion time theorem (Liu

and Lehoczky 1989):



If each of a set of tasks

individually meets its first

deadline under zero phasing:

•

Then the task set is RMA

03/08/10 175 175

Completion Time Theorem

(Liu and Lehoczky)

• How to check schedulability of a

task set?

 Consider zero phasing for all tasks.

 Draw up the schedules till the first deadline of each task.

 Observe if each task is schedulable.

 Then the task set is schedulable.

• Drawing the schedule is cumbersome:

Time in milliseconds

Completion Time Theorem: Basic Premise

• Worst case completion time for a task:

 Occurs when it is in phase with its higher priority tasks. _{T1=10,30 Φ=0}

T2=60,120 Φ=0

T1=10,30 Φ=20 T2=60,120 Φ=0 (a) T₁ is in phase with T₂

T₂ T₁ T₂ 20 30 50 60 T₂ T₁ Time in milliseconds 80 T₁ T₂ T₁ T₂ T₁ T₂ 10 30 40 60 70 90

03/08/10 177 177

Testing Liu and

Example 3

•

Consider three periodic tasks

–

T1: e1=20mSec, p1=100mSec

–

T2: e2=30mSec, p2=150mSec

–

T3: e3=60mSec, p3=200mSec

•

Check whether they are RMA

schedulable.

03/08/10 179

Answer 3

• Checking for Liu-Layland criterion:

• The criterion satisfied:

–Therefore, the task set is schedulable.

78 . 0 7 . 0 600 420 200 60 150 30 100 20 1





Example 4

•

Consider three periodic tasks

–

T1: e1=20mSec, p1=100mSec

–

T2: e2=30mSec, p2=150mSec

–

T3: e3=90mSec, p3=200mSec

•

Check whether the tasks are

RMA schedulable.

03/08/10 181

Answer 4

• Checking for Liu-Layland test:

• Fails Liu-Layland test:

–Before concluding about schedulability, let us check Liu-Lehoczky criterion.

78 . 0 85 . 0 600 510 200 90 150 30 100 20 1





Checking for Lehoczky’s

Criterion

T₁

20 100

Deadline for T₁

(a) T meets its first deadline

50

T₂

(b) T meets its first deadline

Deadline for T₂ 150 T₃ T₁ T₂ Deadline for T₃ T₃ 120 190

(c) T meets its first deadline

T1: e1=20mSec, p1=100mSec T2: e2=30mSec, p2=150mSec T3: e3=90mSec, p3=200mSec