Rajib Mall Chapters 1,2,3
Short Description
engg book...
Description
Characteristics of Real-Time Systems (Lecture 2)
Dr. RAJIB
MALL
Professor Department Of Computer Science & Engineering IIT Kharagpur.
03/08/10
1
1
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? 03/08/10
List inputs to the system and the corresponding system response.
2
2
Important Characteristics • An embedded system responds to events. External Input Event
Process New Data
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. – or the system fails! 03/08/10
3
3
Embedded Systems = Hardware + RTOS +Application Program ELECTROMECHANICAL BACKUP & SAFETY
SENSORS
A/D CONVERSION
HUMAN INTERFACE
SOFTWARE
MEMORY
CPU DIAGNOSTIC PORT
D/A CONVERSION
ACTUATORS
AUXILLARY SYSTEMS (POWER, COOLING)
External Environment 03/08/10
4
4
What is a Real-Time OS? • 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.
03/08/10
5
5
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, • And within the stipulated time.
03/08/10
6
6
Characteristics of an Embedded System cont…
• 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. 03/08/10
7
7
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
8
8
Characteristics of Embedded Systems cont… • 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. 03/08/10
9
9
Characteristics of Embedded Systems
Feedback structure of real-time systems 03/08/10
10
10
Characteristics of Embedded Systems cont…
• Reactive:
On-going interaction between computer and environment.
• Stability: Under overload conditions, work acceptably for at least important tasks.
• Exception Handling: 03/08/10
11
11
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
12
12
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 03/08/10
13
13
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
14
14
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 lights orange and blinking. 03/08/10
15
15
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.
03/08/10
Even if a system is unreliable, it can always be made to fail in a failsafe state. 16
16
Safety and Reliability • For a safety-critical system
No fail-safe state exists. • Consider the navigation system on an aircraft:
03/08/10
• 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.
17
17
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
18
18
How to Design a Highly Reliable System?
–Error Avoidance –Error Detection and Removing –Fault Tolerance 03/08/10
19
19
Fault Tolerance in RT System • The essential idea: Provide redundancy
• Hardware Fault-Tolerance: Masks the effects of a hardware fault.
• Software Fault-Tolerance: 03/08/10
Masks the effects of a program fault.
20
20
Fault Tolerance in RT System
–Hardware FT:
•Built in self test (BIST) •Triple modular redundancy
–Software FT: •N-Version programming •Recovery Blocks 03/08/10
21
21
Triple Modular Redundancy
C1, C2 and C3 are redundant copies of same component 03/08/10
22
22
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. All versions fail for similar reasons.
03/08/10
23
23
Recovery Blocks
Software Fault Tolerance using recovery blocks 03/08/10
24
24
Modern Embedded Systems Application Specific HW Processor Cores
Analog I/O Memory
• Embedded systems incorporate:
Application-specific hardware (ASICs, FPGAs etc.) • performance, low power
03/08/10
Programmable processors: DSPs, controllers etc. Mechanical transducers and actuators 25
25
Block Diagram of An Embedded System controller processes
control panel
ASIC
DSP Assembly Code
Real-time OS
Processor
Programmable DSP
Programmable DSP
Dual-ported RAM 03/08/10
UI processes
DSP Assembly Code
CODEC 26
26
Some Basic Issues (Lecture 3)
Dr. RAJIB
MALL
Professor Department Of Computer Science & Engineering IIT Kharagpur.
03/08/10
27
27
Why Have an OS in an Embedded Device? • Support for: 03/08/10
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 28
28
Why Have an OS in an Embedded Device? • 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. 03/08/10
29
29
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: Embedded Systems Design Magazine. 03/08/10
30
30
Processor Bit Size Used in New Embedded Designs 64-bit 32-bit 16-bit 8-bit
4-bit 0.00%
10.00%
20.00%
30.00%
40.00%
50.00%
60.00%
Data was derived from EETimes and Embedded Systems Design Magazine 2006 Embedded Market Survey
03/08/10
31
31
Processor Architectures Widely Used in New Embedded Designs
• ARM • X86 • PowerPC • MIPS • Xscale (ARM) • Renesas SuperH 03/08/10
32
32
32-64 bit Annual Processor Sales Processor Sales Volume ARM X86 MIPS SuperH PowerPC 0.00%
03/08/10
5.00%
10.00%
on 2002 sales25.00% data 15.00%Based20.00%
30.00%
35.00%
40.00%
33
33
Number of Processors Used in New Embedded Designs 1 Processor
2 Processors
3-5 Processors
More Than 5 0.00%
10.00%
20.00%
30.00%
40.00%
50.00%
60.00%
Data was derived from EETimes and Embedded Systems Design Magazine 2006 Embedded Market Survey
03/08/10
34
34
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
Long term availability, Multiple Vendors?
03/08/10
35
35
Use of Real-Time OS Kernels in New Embedded Designs Commercial OS None Internally Developed Open Source 0.00%
10.00%
20.00%
30.00%
40.00%
50.00%
Data was derived from EETimes and Embedded Systems Design Magazine 2006 Embedded Market Survey
03/08/10
36
36
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: 03/08/10
The source code often needs to be fine tuned.
37
37
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: That you publish your device’s source code 03/08/10
38
38
Commercial Operating Systems used in New Embedded Designs Microsoft Emb. Wind River Symbian Green Hills Palm Others 0.00%
5.00%
10.00%
15.00%
20.00%
25.00%
30.00%
Data was derived from EETimes and Embedded Systems Design Magazine 2006 Embedded Market Survey
03/08/10
39
39
Programming Languages Used in New Embedded Designs C C++ C# Java Assembly Others 0.00%
03/08/10
10.00% 20.00% 30.00% 40.00% 50.00% Data was derived from EETimes and Embedded Systems Design Magazine 2006 Embedded Market Survey
60.00%
70.00%
40
40
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. • Power minimization. 03/08/10
41
41
Modelling Timing Constraints (Lecture 4)
Dr. RAJIB
MALL
Professor Department Of Computer Science & Engineering IIT Kharagpur.
03/08/10
42
42
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 03/08/10
43
43
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 safetycritical. • Examples: Industrial control applications On-board computers Robots 03/08/10
44
44
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 D Time 03/08/10
45
45
Firm Real-Time Systems • Examples: A video conferencing application A telemetry application Satellite-based surveillance applications
03/08/10
46
46
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 D Time 03/08/10
47
47
Soft Real-Time Systems • Examples of soft real-time systems: Railway reservation system Web browsing In fact, all interactive applications
03/08/10
48
48
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. 03/08/10
49
49
Timing Constraints • A timing constraint:
Defined with respect to some event.
• An event:
03/08/10
Can occur at an instant of time May also have duration Generated either by the system or its environment 50
50
Events in a Real-Time System
• Events in a real-time system can be classified into: Stimulus Events
Response Events
03/08/10
51
51
Stimulus Event
• Generated by the environment: Act on the system.
• Typically asynchronous in nature: Aperiodic Can also be periodic
Telephone System
• Example:
A user pressing a button on a telephone set Stimulus event acts on the telephone system.
03/08/10
52
52
Stimulus Event cont
• Periodic stimulus event example :
…
Periodic sensing of temperature in a chemical plant.
03/08/10
53
53
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
54
54
Classification of Timing Constraints
• Classification of the timing constraints in a system:
Can help us to quickly identify these from a problem description.
03/08/10
55
55
Classification of Timing Constraints
• Different timing constraints can broadly be classified into: Performance constraints
Behavioral constraints
03/08/10
56
56
Types of Timing Constraints
• Performance constraints:
Imposed on the response of the system.
• Behavioral constraints: Imposed on the stimuli generated by the environment.
03/08/10
57
57
Types of Timing Constraints
• Both performance and behaviorial constraints can be classified into: Delay Constraints Deadline Constraints Duration Constraints 03/08/10
58
58
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) d
03/08/10
59
59
Deadline Constraint • Expresses the maximum permissible separation: Between any two arbitrary events.
t(e2) - t(e1) ≤ d 03/08/10
60
60
Duration Constraint • A duration constraint on an event:
Specifies the time period over which the event acts.
• A duration constraint can be: minimum type maximum type.
03/08/10
61
61
Duration Constraints
• Minumum:
Once a duration event starts:
• It must not end before a certain minimum time. t(e1)
• Maximum:
t(e2)
Min
Once a duration event starts:
• It must end before a certain maximum time. t(e1) t(e2)
03/08/10
Max
62
62
Timing Constraints in an Example System PSTN
03/08/10
63
63
SS Deadline Example • Deadline is defined between two stimuli. PSTN 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
64
64
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:
PSTN
The first digit must be dialed within 30 seconds, Otherwise the system enters an idle state and an idle tone is produced
03/08/10
65
65
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, PSTN
Ring back tone must be given to the caller within two seconds, Otherwise the call is terminated.
03/08/10
66
66
SR Deadline Example • Deadline is defined on the response from the respective stimulus. A performance constraint. Imposed on response.
PSTN
• Once the receiver of the hand set is lifted:
03/08/10
The dial tone must be produced by the system within 2 seconds, otherwise a beeping sound is produced until the handset is replaced. 67
67
SS Type Delay Constraint
• A behaviorial constraint.
Imposed on the environment.
PSTN
• 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
68
68
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.
03/08/10
69
69
Timing Constraints Performance Constraints
03/08/10
Delay
Deadline
RR SR
RR SR
Duration
Behaviorial Constraints
Delay
Deadline
RS SS
RS SS
Duration
70
70
Modelling Timing Constraints (cont…) (Lecture 5)
Dr. RAJIB
MALL
Professor Department Of Computer Science & Engineering IIT Kharagpur.
03/08/10
71
71
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
72
72
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.
03/08/10
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. 73
73
FSM e1/set-timer(20 msec)
S1
S2
• Transition is annotated with:
Enabling event Action that takes place during transition
03/08/10
74
74
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 Next digit
Await second digit
03/08/10
Await Caller Onhook
75
75
Model of RS Deadline Constraint
• 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 Await Next digit Await first digit
03/08/10
Await Caller Onhook
76
76
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 first digit
Await Dial tone
03/08/10
Await Receiver Onhook
77
77
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 first digit Await Ringback tone
03/08/10
Await Receiver Onhook
78
78
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 digit
Await next event
03/08/10
Await Receiver Onhook 79
79
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
80
80
Model Construction for Duration Example
• To construct the model:
First identify the deadline and delay constraints. The constraints are for which events?
03/08/10
81
81
Model of Duration Constraint Example Local operator
Internl operator
Await event1
Await event2
Dial tone
Await Button release 03/08/10
82
82
Exercise 1 • When the temperature of a chemical reactor rises above T°C:
The heater needs to be shutoff within 10mSec Otherwise, the entire plant is shut-off.
03/08/10
83
83
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
84
84
Basics of Real-Time Task Scheduling (Lecture 6) Dr. RAJIB
MALL
Professor Department Of Computer Science & Engineering IIT Kharagpur. 03/08/10
85
85
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 highlevel.
• When a task gets generated: 03/08/10
It is said to be released or arrived . 86
86
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 problem in RTOS.
03/08/10
87
87
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
88
88
Relative and Absolute Deadlines
• Absolute deadline:
Counted from time 0.
• Relative deadline:
Counted from time of occurrence of task. deadline
abs relative 0 03/08/10
t
d 89
89
Response Time • The time from the occurrence of the event generating the task:
To the time results are produced by the task.
Response time
0 03/08/10
e
t
90
90
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
91
91
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: 03/08/10
• Same as sporadic except that minimum separation between two instances can 92be
92
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 03/08/10
P
e1
P
e2
e3
time
93
93
Phase Example
Φ
0
P e1
P e2
time
e3
• 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.
03/08/10
94
94
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: 03/08/10
• Valid schedule is one in which all tasks meet their respective time constraints. 95
95
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
96
96
Important Scheduling Terminologies Optimal Scheduler: • An optimal scheduler can feasibly schedule any task set that can be scheduled by any other scheduler.
03/08/10
97
97
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
98
98
Real-Time Task Scheduling cont…
• Significant amount of research has been carried out to develop schedulers for real-time tasks: Schedulers for uniprocessors Schedulers for multiprocessors and distributed systems. 03/08/10
99
99
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
100
100
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. 03/08/10
101
101
Clock-Driven Scheduling • Popular examples: Table-driven scheduler Cyclic scheduler
• Round robin scheduling is also an example of clockdriven scheduling. 03/08/10
102
102
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. 03/08/10
103
103
Table-Driven Scheduling Task Start timeStop time
03/08/10
T1
0
100
T2
101
150
T3
151
225
104
104
Cyclic Schedulers (Lecture 7) Dr. RAJIB
MALL
Professor Department Of Computer Science & Engineering IIT Kharagpur. 03/08/10
105
105
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
106
106
Clock-Driven Scheduling • For scheduling n periodic tasks: The schedule is stored in a table. •Repeated forever.
03/08/10
The designer needs to develop a schedule for what period? • LCM(P1,P2,...,Pn).
107
107
Clock-Driven Scheduling • Used in low cost applications: Pro: • Compact: Require very little storage space • Efficient: Incur very little runtime overhead.
Con: 03/08/10
• Inflexible: Very difficult to accommodate dynamic tasks. 108
108
Disadvantage of TableDriven 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.
03/08/10
109
109
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
110
110
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:
Occur at the beginning of frames.
03/08/10
111
Major Cycle • In each major cycle:
The different tasks recur at identical time points. Major cycle
03/08/10
Major cycle
Frame (minor cycle)
112
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
113
Minor Cycle (Frame) • Each major cycle: Usually contains an integral number of minor cycles (frames).
• Frame boundaries are marked: 03/08/10
Through interrupts from a
114
114
A Typical Schedule
03/08/10
Frame
Task
F1
T2
F2
T3
F3
T2
115
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 satisfy a few constraints. 03/08/10
116
116
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:
03/08/10
• At least one full frame must exist.
117
117
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.
03/08/10
The scheduler would get invoked many times. 118
118
Minimum Context Switch • To avoid unnecessary context switches: • Selected frame size should be larger than execution time of each task. • Sets a lower bound for frame size.
03/08/10
119
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.
03/08/10
Major cycle
Major cycle
Frame
120
120
Major cycle
Major cycle
Frame 03/08/10
121
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 imminent. ti di
03/08/10
F
F
122
122
Satisfaction of Task Deadline
• The worst case for a task occurs when the task arrives just after a frame has started. ti
di
ti would miss deadline
ti
di ti deadline can be met
03/08/10
123
123
Satisfaction of Task Deadline
• The minimum separation of an arrival time for ti from a frame ti di start: GCD(F,pi)
• Thus, for all ti
F
F
2F-GCD(F,pi) ≤ di must be satisfied 03/08/10
124
124
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: • The chances of successful scheduling is higher.
03/08/10
125
Example 1 • Compute a suitable frame size for the following task set: e1 = 1, p1=4, d1=4 e2 = 1, p2=5, d2=5 e3 = 1.5, p3=20, d3=20
03/08/10
126
126
Example 2 • Compute a suitable frame size for the following task set: e1 = 1, p1=4, d1=4 e2 = 2, p2=6, d2=6 e3 = 3, p3=20, d3=20
03/08/10
127
127
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 subtasks.
• Example: T1=(20,100,100) can be split into (10,100,100) and (10,100,100). 03/08/10
128
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. • Results in poor schedulability. 03/08/10
129
129
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: • As and when the spordic and aperiodic tasks arise.
03/08/10
130
Cyclic Scheduler: Pseudocode 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(), } 03/08/10
131
Event-Driven Scheduling (Lecture 8) Dr. RAJIB
MALL
Professor Department Of Computer Science & Engineering IIT Kharagpur. 03/08/10
132
132
Event-Driven Schedulers
• Unlike clock-driven
schedulers: These can handle sporadic and aperiodic tasks. Used in more complex applications.
03/08/10
133
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: Foreground-Background Scheduler 03/08/10
134
134
Scheduling Points for
Event-Driven Schedulers
• Scheduling decisions are made when certain events occur: •A task becoming ready •A task completing execution 03/08/10
135
135
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
136
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. 03/08/10
137
137
Preemptive Scheduling • Independent tasks execute on a uniprocessor. Two algorithms pretty much summarise the important results in this case: • EDF • RMA 03/08/10
138
138
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: When no foreground task is ready. 03/08/10
139
139
Background Task Completion Time • Let TB be the only background task
• Its processing time be eB • The time for it to complete would be:
eB
ctB ei 1 pi 03/08/10
140
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. • Compute the completion time for the background task.
03/08/10
141
Example 2 •On account of every context switch : •Assume an overhead of 1 msec. •Compute the completion time of TB.
03/08/10
142
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. 03/08/10
143
143
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 scheduling algorithm. 03/08/10
144
144
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 03/08/10
145
145
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.
03/08/10
• Can schedule both periodic and aperiodic tasks.
146
146
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. 03/08/10
147
EDF Schedulability Check • Sum of utilizations due to all tasks is less than one:
e i u i 1 i 1 p i n
• Both the necessary and sufficient condition for schedulability. 03/08/10
148
Example 1 • Compute a suitable frame size for the following task set: e1 = 1, p1=4, d1=4 e2 = 1, p2=5, d2=5 e3 = 5, p3=20, d3=20
03/08/10
149
149
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
150
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 03/08/10
151
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
152
152
Disadvantages of EDF
•Main disadvantages of EDF: •Poor transient overload handling •Runtime inefficiency •Poor support for resource sharing among tasks. 03/08/10
153
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
154
154
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: 03/08/10
• log(n), n is the number of tasks.
155
155
Poor Resource Sharing Support • Support for tasks to share nonpremptable resources (critical sections): Extremely inefficient. Tasks often miss their deadlines.
We shall elaborate this problem later in our discussions. 03/08/10
156
156
General EDF Schedulability • When task deadlines differ from task periods: The schedulability criterion needs to be generalized:
e i 1 i 1 min( p i,d i) n
• If pi
View more...
Comments
