is it time yet? wing on chan. distributed systems – chapter 18 - scheduling hermann kopetz
Post on 17-Dec-2015
223 Views
Preview:
TRANSCRIPT
Is It Time Yet?
Wing On Chan
Distributed Systems – Chapter 18 - Scheduling
Hermann Kopetz
3
Scheduling Algorithm Classifications
Real-Time Scheduling• Soft
• Hard
– Dynamic
» Preemptive
» Non-preemptive
– Static
» Preemptive
» Non-preemptive
4
Scheduling Problem
• Distributed hard real-time systems– Execute a set of concurrent RT transactions
such that all time-critical transactions meet their deadlines
– Transactions need resources (Computational, communication, and data)
– Decomposition• Within a node• Communication resources
5
Hard RT Vs Soft RT Scheduling
• Hard RT Systems– Deadlines must be guaranteed before execution
starts.– Probability that the transaction finishes before
it’s deadline not enough.– Off-line schedulability tests– Feasible static schedules
6
Hard RT Vs Soft RT Scheduling
• Soft RT Systems– Violation of timing not critical– Cheaper resource-inadequate solutions can be
used– Under adverse conditions, it is tolerable that
transactions not meet their timing constraints
7
Dynamic Vs Static Scheduling• Dynamic (On-line) Scheduling
– Only considers• Actual requests• Execution time parameters
– Costly to find a schedule
• Static Scheduling (Off-line)– Complete knowledge
• Maximum execution time• Precedence constraints• Mutual exclusion constraints• Deadlines
8
Preemptive Vs Non-Preemptive
• Preemptive– Can be interrupted by more urgent tasks
• Safety assertions
• Non-Preemptive– No interruptions– Shortest response = Longest + Shortest task– Reasonable for scenarios with many short tasks
9
Central Vs Distributed
• Dynamic distributed RT systems– Central Scheduling– Distributed Algorithms
• Requires up-to-date information in all nodes
• Significant communication costs
10
Schedulability Test
• Determine if a schedule exists– Exact
– Necessary
– Sufficient
• Optimal scheduler– Optimal if schedule can be found when the exact
schedulability test says there is one
• Exact schedulability test– Belongs to the class of NP-complete problems
11
Schedulability Test
• Sufficient schedulability test– Sufficient but not necessary condition
• Necessary schedulability test– Necessary but not sufficient condition
• Difference between deadline di and computation time ci (laxity) be non-negative
12
Periodic Tasks
• Periodic Tasks– After the initial task request
• All future requests known
• Adding multiples of known period to initial request time
13
Periodic Tasks
• Task set {Ti} of periodic tasks
– Periods - pi
– Deadlines - di
– Processing requirements – ci
• Sufficient to examine schedules with length equal to the least common multiple of the periods in {Ti}
14
Periodic Tasks
• Necessary schedulability test– Sum of utilization factors i must be less than
or equal to n, where n is the number of processors
= (ci / pi) <= n i = Percentage of time the task Ti requires the
service of a CPU
15
Sporadic Tasks
• Request times are not known beforehand
• Must be a minimum interval pi between any two request times of sporadic tasks
• If pi doesn’t exist, then the necessary schedulability test will fail
• Aperiodic tasks = No constraints on request times
16
Optimal Dynamic Scheduling
• Consider a dynamic scheduler with full past knowledge only– Exact schedulability is impossible– New definition of optimal dynamic scheduler
• Optimal if it can find a schedule whenever a clairvoyant scheduler can find a schedule
17
Adversary Argument
• If there are mutual exclusion constraints between periodic and sporadic tasks, then in general, it is impossible to find an optimal totally online dynamic scheduler.
18
Adversary Argument
19
Adversary Argument
• Necessary schedulability test = (ci / pi) <= n = (2/4) + (1/4) = (3/4) <= 1
• Suppose that when T1 starts, T2 requests service– Mutually exclusive– T2 has a laxity of d2 – c2 = 1 - 1 = 0– T2 will miss it’s deadline
20
Adversary Argument
• Clairvoyant scheduler– Schedule periodic task between sporadic tasks– Laxity of periodic task > execution time of
sporadic task, so scheduler will always find a schedule
21
Adversary Argument
• If the on-line scheduler has no future knowledge about sporadic tasks, scheduling becomes unsolvable.
• Predictable hard RT systems are only feasible if there are regularity assumptions
22
Dynamic Scheduling
• Dynamic scheduling algorithm– Determines task after occurrence of a
significant event– Based on current task requests
23
Rate Monotonic Algorithm
• Classic algorithm for hard RT systems with a single CPU
• Dynamic preemptive algorithm
• Static task priorities
24
Rate Monotonic Algorithm
• Assumptions1. All requests in set {Ti} are periodic
2. All tasks are independent. No precedence or mutual exclusion constraints
3. di = pi
4. The maximum ci is known and constant
5. Context switching time is ignored6. = (ci / pi) <= n (21/n – 1) [approaches ln 2 or 0.7]
25
Rate Monotonic Algorithm
• Algorithm defines task priorities– Short pi tasks get higher priority
– Longer pi tasks get lower priority
– During run-time, always run the highest priority
• If all assumptions are met, all Ti meet their deadlines
• Optimal for single processor systems
26
Earliest-Deadline-First Algorithm
• Optimal dynamic preemptive algorithm• Uses dynamic priorities• Assumptions 1-5 of the Rate Monotonic
Algorithm must also hold can go up to 1, even with tasks that do not have
pis that are multiples of the shortest period • After a significant event
– Task with the shortest di gets the highest dynamic priority
27
Least-Laxity Algorithm
• Optimal in single processor system• Same assumptions as Earliest-Deadline-First
algorithm• At scheduling decision point
– Task with the shortest laxity (di – ci) is given the highest dynamic priority
• In multiprocessor systems– Earliest-deadline-first and least-laxity algorithms are not
optimal– Least-laxity algorithm is able to handle task scenarios that
the Earliest-deadline-first algorithm could not
28
Scheduling Dependent Tasks
• Analysis of tasks with precedence and mutual exclusion constraints more useful
• Scheduling competing with tasks for resources• Possible solutions
– Provide extra resources. Simpler sufficient schedulability tests and algorithms.
– Divide problem into 2 parts• One solved at compile time• One solved during run-time (Simpler of the two)
– Add restricting regularity assumptions
29
Kernelized Monitor
• For a set of short critical sections, the longest critical section less than a given duration q.
• Allocates processor time in uninterruptible quantums of q.– Assumes all critical sections can be started and
completed within this single uninterruptible– Process may only be interrupted after xq where
x is an integer
30
Kernelized Monitor
• Example:– Assume there are two periodic tasks
• T1: c1 = 2, d1 = 2, p1 = 5
• T2: c21 = 2, c22 = 2, d2 = 10, p2 = 10
• T2 has two scheduling blocks
– C22 of T2 is mutually exclusive to T1
• q = 2
31
Kernelized Monitor
• At t = 5, the earliest-deadline algorithm will need to schedule T1 again but it can’t since T22 is block the critical section between T1 and T22
32
Kernelized Monitor
• Region before the second activation of T1 is blocked– Forbidden region
• Dispatcher must know about all forbidden regions during compile time
33
Priority Inversion
• Consider three tasks T1, T2, and T3 with T1 having the highest priority– Scheduled with rate-monotonic algorithm
– T1 and T3 require exclusive access to a resource protected by a semaphore S
34
Priority Inversion
– T3 starts and has exclusive access to resource
– T1 requests service but is blocked by T3
– T2 requests service and is granted service
– T2 finishes
– T3 finishes and releases S
– T1 starts and finishes
– Actual execution is T2, T3, then T1
– Solution: Priority Ceiling Protocol
35
Priority Ceiling Protocol
• Priority ceiling (PC) of S = priority of the highest task that can lock S
• T only enters a new critical section if it’s priority is higher than the PC of all semaphores locked by tasks != T
• Runs at assigned priority unless in critical region and blocks higher priority tasks– Inherits highest priority of blocked tasks while in the
critical region– Returns to assigned priority when exiting
36
Priority Ceiling Protocol
1. T3 starts
2. T3 locks S3
3. T2 starts and preempts T3
4. T2 is blocked when locking S3. T3 resumes at T2’s inherited priority
37
Priority Ceiling Protocol
5. T3 enters nested critical region and locks S1.
6. T1 starts and preempts T3
7. T1 is blocked when locking S1. T3 resumes
8. T3 unlocks S2. T1 awakens and preempts T3. T1 locks S1
38
Priority Ceiling Protocol
9. T1 unlocks S1
10. T1 locks S2
11. T1 unlocks S2
12. T1 completes. T3 resumes at priority of T2
39
Priority Ceiling Protocol
13. T3 unlocks S3. T2 preempts T3 and locks S3
14. T2 unlocks S3
15. T2 completes. T3 resumes
16. T3 completes
40
Priority Ceiling Protocol
• One sufficient schedulability test– Set of n periodic tests {Ti}, periods pi, computation
time ci
– Worse case blocking time by lower priority tasks = Bi
i, 1 i n :
(c1/p1) + (c2/p2) + …+ (ci/pi) + (Bi/p2) i(21/i – 1)
• Not the only test. There are more complex ones.• Priority ceiling protocol – Predictable, non-
deterministic scheduling protocol
41
Dynamic Scheduling In Distributed Systems
• Hard to guarantee deadlines in single processor systems
• Even harder in distributed systems or multiprocessor systems due to communication
• Applications required to tolerate transient faults like message losses as well as detect permanent faults
42
Dynamic Scheduling In Distributed Systems
• Positive Acknowldgement or Retransmission (PAR)– Large temporal uncertainty between shortest and
longest execution time– Worse case – assume longest time.
• Poor responsiveness of system
• Masking Protocols– Send message k + 1 in case the tolerance of k is
required.• No temporal problem but can’t detect permanent faults due to
unidirectional communication
43
Dynamic Scheduling In Distributed Systems
• Solutions?– No idea– Providing good temporal performance is a
“fashionable research topic”
44
Static Scheduling
• Static schedules guarantees all deadlines, based on known resources, precedence, and synchronization requirements, is calculated off-line
• Strong regularity assumptions
• Known times when external events will be serviced
45
Static Scheduling
• System design– Maximum delay time until request is recognized +
maximum transaction response time < service deadline
• Time– Generally a periodic time-triggered schedule– Time line divided into a sequence of granules (cycle
time)– Only one interrupt, a periodic clock interrupt for the start
of a new granule– In distributed systems, synchronized to a precision of
less than a granule
46
Static Scheduling
• Periodic with pi being a multiple of the basic granule
• Schedule period = least common multiple of all pi
• All scheduling decisions made at compile-time and executed at run-time
• Optimal schedule in a distributed system => NP complete
47
Search Tree
• Precedence Graph– Tasks = Nodes, Edges = dependencies
• Search Tree– Level = unit of time, Depth = period– Path to a leaf node = complete schedule– Goal: Find a complete schedule that observes
all precedence and mutual exclusion constraints before the deadline
48
Heurisitc Function
• Two terms: Actual cost of path, estimated cost to goal
• Example– Estimate time needed to complete precedence graph
(Time Until Response) (TUR)
– Necessary estimate of TUR = (max exec time + communications)
– If necessary estimate > deadline, prune branches of the node and backtrack to the parent
49
Increasing Adaptability
• Weakness: Assumption of strictly periodic tasks
• Proposed solutions for flexibility– Transformation of sporadic requests into
periodic requests– Sporadic server task– Mode changes
50
Transformation Of Sporadic Requests To Periodic Requests
• Possible to find a schedule if the sporadic task has a laxity
• One solution: Replace T with a quasisporadic task T’
– c’ = c– d’ = d – p’ = min(p – d + 1, p)
• Sporadic task with a short latency will demand a lot of resources, but will request it infrequently
51
Sporadic Server Task
• Periodic server task of high priority created– Maintains execution time for duration of
server’s period– When sporadic task arrives, services with
server’s priority (Depletes execution time)– Replenishes execution time when active– Sporadic server task is dynamically scheduled
in response to a sporadic request
52
Mode Change
• During system design, identify all modes• For each mode, generate a static schedule
off-line• Analyze mode changes and develop mode
change schedule• During run-time, when a mode change is
requested, change to corresponding static schedule
53
Comparisons
• Predictability– Static Scheduling
• Accurate planning of schedule, so precise predictability
– Dynamic Scheduling• No schedulability tests exist for distributed system
with mutual exclusion and precedence relations
• Dynamic nature can not guarantee timeliness
54
Comparisons
• Testability– Static Scheduling
• Performance tests of every task can be compared with established plans
• Systematic and constructive since all input cases can be observed
– Dynamic Scheduling• Confidence of timeliness based on simulations
• Real loads not enough since rare events don’t occur often
• Are the simulated loads representative of real loads?
55
Comparisons
• Resource Utilization– Static Scheduling
• Planned for peak load with time for each task at least the maximum execution time
• If many operating modes, can lead to “combinatorial explosion” of static schedules
– Dynamic Scheduling• Processor available more quickly
• Resources needed to do dynamic scheduling
56
Comparisons
• Resource Utilization– Dynamic Scheduling (Cont’d)
• If loads low, better utilization than static schedule
• If loads high, more resources used for dynamic scheduling and less for execution of tasks
57
Comparisons
• Extensibility– Static Scheduling
• If a new task is added or the maximum execution time is modified, the schedule needs to be recalculated
• If the new node sends information into the system, the communications schedule needs to be recalculated
• Impossible to calculate static schedule if the number of tasks changes dynamically during run-time
58
Comparisons
• Extensibility– Dynamic Scheduling
• Easy to add/modify tasks
• Change can ripple through system
• Probability of change and system test-time are proportional to tasks.
• Assessing the consequences increase more than linearly with the number of tasks
• Scales poorly for large applications
top related