is it time yet? wing on chan. distributed systems – chapter 18 - scheduling hermann kopetz

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


• 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


• 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


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


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


9. T1 unlocks S1

10. T1 locks S2

11. T1 unlocks S2

12. T1 completes. T3 resumes at priority of T2

39


13. T3 unlocks S3. T2 preempts T3 and locks S3

14. T2 unlocks S3

15. T2 completes. T3 resumes

16. T3 completes

40


• 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


• 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


• 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

is it time yet? wing on chan. distributed systems – chapter 18 - scheduling hermann kopetz

Documents