chapter 4 by radu muresan university of guelph

Real‐Time Task Model Concepts○Types of Real‐Time Tasks and Their Characteristics

○

Task Scheduling ○Clock Driven Scheduling○Hybrid Schedulers○Event‐Driven Scheduling○Earliest Deadline First (EDF) Scheduling○Rate Monotonic Algorithm (RMA)○Some Issues Associated with RMA○RMA in Practical Situations○

UNIPROCESSOR SCHEDULING•

Multiprocessor Task Allocation○Dynamic Allocation Tasks○Fault Tolerant Scheduling of Tasks○Clocks in Distributed Real‐Time Systems○Centralized Clock Synchronization○Distributed Clock Synchronization○

MULTI‐PROCESSOR SCHEDULING•

Real‐Time Systems by Jane Liu;○Real‐Time Systems by Krishna Shin○Real‐Time Systems by Rajib Mall, 2008.○

REFERENCES:

CHAPTER 4 CONTENTOctober‐30‐094:10 PM

CHAPTER 4 By Radu Muresan University of Guelph

Other types of time constraints are related to performance constraints and behaviouralconstraints.

○Assume only deadline constraints on real‐time tasks•

Examples: internal clock interrupt; user pressing a switch.

○

Real‐time tasks get generated (issued or released) in response to some events that may be either internal or external to a system:

•

When a task gets generated, it is said to have arrived or released.

•

Every real‐time system usually consists of a number of real‐time tasks ‐‐ the time bounds on different tasks may vary.

•

Criticality of a real‐time task relates to the consequences of a task missing its time bounds.

•

Appropriate scheduling of tasks is the basic mechanism adopted by a RTOS to meet the time constraints of a task.

•

Therefore, selection of an appropriate task scheduling algorithm is central to the proper functioning of a real‐time system.

•

Understanding the scheduling algorithms will help us appreciate the modern commercial RTOS.

•

REAL‐TIME TASK SCHEDULINGOctober‐30‐094:10 PM


Ex. A task handling a device interrupt□At random instants

Temperature sensing task in a chemical plant□Within certain fixed periods

Real‐time tasks, therefore, normally recur a large number of times at different instants of time depending on the event occurrence time:

○

Task instance: each time an event occurs, it triggers the task that handles this event to run (a task is generated when some specific event occurs).

•

The jth instance of a task Ti would be denoted as Ti(j).

○

Each instance of a real‐time task is associated with a deadline by which it needs to complete and produce results.

○

The first time a task occurs is called the first instance of the task; the next occurrence is called the second instance and so on.

•

We can use interchangeably task instance or process.•

REAL‐TIME TASK CONCEPTSOctober‐30‐094:26 PM


The absolute deadline of a task is the absolute time value (counted from time 0) by which the results from the task are expected.

•

The Relative deadline is the time interval between the start of the task and the instant at which the deadline occurs.

•

The response time is the time duration from the occurrence of the event generating the task to the time the task produces its result.

•

Note that for hard real‐time tasks, as long as all their deadlines are met, there is no special advantage of completing the tasks early.

1)

For soft real‐time tasks, average response time of tasks is an important metric measure. As a result, the soft real‐time task execution should try to minimize the average response time.

2)

RELATIVE AND ABSOLUTE DEADLINE OF A TASK PLUS THE RESPONSE TIME OF A TASKOctober‐30‐094:27 PM


TASK PRECEDENCE

A task is said to precede another task, if the first task must complete before the second task can start

•

Ex. If T1 proceeds T2 then: T1(1) precedes T2(1); T1(2) precedes T2(2); etc.

○

When a task Ti precedes another task Tj, then each instance of Ti precedes the corresponding instance of Tj

•

A precedence order defines a partial order among tasks ‐‐ a partial ordering relation is reflexive, anti‐symmetric, and transitive.

•

Figure below is an example of partial ordering among tasks ‐‐ task T1 precedes T2, but we cannot relate T1 with either T3 or T4.

•


DATA SHARING AMONG TASKS

Tasks often need to share their results among each other ‐‐ precedence relation between two tasks sometimes implies data sharing (not always true, sometimes we need to perform only actions without data sharing).

•

Data sharing may occur not only when one tasks precedes another, but might occur among truly concurrent tasks, and overlapping tasks.

•

In other words, data sharing among tasks does notnecessarily impose any particular ordering among tasks.

•

T2 uses the results of T3, but T2 and T3 may execute concurrently,

○

T2 may even start executing first, after sometimes it may receive some data from T3, and continue its execution, and so on.

○

As a result, data sharing relation among tasks is represented using a dashed arrow as in the figure above where:

•


TYPES OF REAL‐TIME TASKS AND THEIR CHARACTERISTICS

Based on the task recurrence over a period of time the real‐time tasks are classified into 3 main categories:

•

Periodic tasks repeat after a certain fixed time interval.

○PERIODIC TASKS•

Sporadic tasks recur at random instants.○SPORADIC TASKS•

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

○APERIODIC TASKS•


PERIODIC TASKS

Φi is the phase of task Ti and is the time from 0 until the first instance of Ti (i.e., Ti(1));

○

pi is the period of the task Ti;○ei is the worst case execution time of Ti;○di is the relative deadline of the task.○

Formally, a periodic task Ti can be represented by a four tuple (Φi, pi, ei, di), where:

•

The periods are usually demarcated by clock interrupts •and the task are also called clock‐driven tasks.


A VAST MAJORITY OF TASKS present in a typical real‐time system are periodic ‐‐ the reason being many activities carried out by real‐time systems are periodic in nature.

•

In a chemical plant several temperature monitors, pressure monitors, and chemical concentration monitors periodically sample the current temperature, pressure, and chemical concentration values which are then communicated to the plant controller.

○

The instance of the temperature, pressure, and chemical concentration monitoring tasks are normally generated through the interrupts received from a periodic timer ‐‐ the inputs are used to compute corrective actions required to maintain the chemical reaction at a certain rate.

○

The corrective actions are then carried out through actuators.

○

EXAMPLES are numerous in chemical plants•

EXAMPLE ‐‐ the computation that occurs in air traffic monitors, once a flight is detected by the radar until the radar exits the radar signal zone is an a dynamically created periodic task.

○

The periodic task in the above example exists from initialization ‐‐ however, periodic tasks can also come into existence dynamically.

•


SPORADIC TASKS

A sporadic task is one that recurs at random instants. A sporadic task Ti can be represented by a three tuple: Ti = (ei, gi, di)

ei is the worst case execution time of an instance of the task;

○

gi denotes the minimum separation between two consecutive instances of the task;

○

di is the relative deadline.○

Where:

NOTE that gi restricts the rate at which sporadic tasks can arise.The first instance of a sporadic task Ti is denoted by Ti(1) and the successive instances by Ti(2), Ti(3), etc.

•

Ex. 1) In a robot a task that gets generated to handle an obstacle that suddenly appears is a sporadic task; 2) In a factory, the task that handles fire conditions is a sporadic task

○

Many sporadic tasks such as emergency message arrivals are highly critical in nature

•

Ex. 1) An I/O device interrupt, or a DMA interrupt is moderately critical; 2) a task handling the reporting of fire conditions is highly critical.

○

The criticality of sporadic tasks varies from highly critical to moderately critical

•


APERIODIC TASKS

An aperiodic task is similar to a sporadic task in a sense that it can arise at random instances

the minimum separation gi between two consecutive aperiodic tasks can be 0 => two or more instances of an aperiodic task might occur at the same time instant;

○

The deadline for an aperiodic task is expressed as either an average value or is expressed statistically;

○

Aperiodic tasks are generally soft real‐time tasks○Aperiodic tasks can recur in quick succession; as a result, it becomes very difficult to meet the deadline of all instances of an aperiodic task.

○

However, •

Example: 1) logging task in a distributed system ‐ the logging task can be started by different tasks running on different nodes; the logging requests from different tasks may arrive at the logger almost at the same time, or requests may be spaced in time; 2)operator requests, keyboard presses, mouse movements, etc. (all interactive commands issued by users are handled by aperiodic tasks.

•


TASK SCHEDULING

Real‐Time task scheduling refers in general to determining the order in which the various tasks are to be taken up for execution by the operating system. Every operating system relies on one or more task schedulers to prepare the schedule of execution of various tasks it needs to run;

•

Each scheduler is characterized by the scheduling algorithm it employs;

•

Real‐time scheduling on uniprocessor is a mature discipline with most of the important results having been worked out in the early 1970s;

•

We present broad scheduling classes and study the characteristics of a few algorithms

•


BASIC CONCEPTS AND TERMINOLOGIES

VALID SCHEDULE: a valid schedule for a set of tasks is one where at most one task is assigned to a processor at a time, no task is scheduled before its arrival time, and the precedence and resource constraints of all tasks are satisfied.FEASIBLE SCHEDULE: a valid schedule is called a feasible schedule, only if all tasks meet their respective time constraints in the schedule.

If SCH1 can feasibly schedule all task sets that SCH2 can feasibly schedule and vice versa, then SCH1 and SCH2 are called equally proficient schedulers.

○

PROFICIENT SCHEDULER: a task scheduler SCH1 is said to be more proficient than another scheduler SCH2, if SCH1 can feasibly schedule all task sets that SCH2 can, but there is at least one task set that SCH2 can not feasibly schedule, whereas SCH1 can.

OPTIMAL SCHEDULER: a real‐time scheduler is called optimal, if it can feasibly schedule any task set that can be feasibly scheduled by any other scheduler ‐we can't find a more proficient scheduling algorithm than the optimal scheduler.


A task scheduler is activated by the OS only at the scheduling points to make decisions on which task needs to run next

○

Ex. 1) in a clock driven scheduler the scheduling points are defined at the time instants marked by interrupts generated by a periodic timer; 2) in an event‐driven scheduler the scheduling points are determined by occurrence of certain events

○

SCHEDULING POINTS: the scheduling points of a scheduler are the points on the time line where the scheduler makes decisions regarding which task is to be run next

PREEMPTIVE SCHEDULER: See Chapter 2.

For a periodic task Ti:1)For a set of periodic tasks {Ti}:2)

UTILIZATION: the processor utilization of a task is the average time for which it executes per unit time interval

JITTER: is the deviation of a periodic task from its strict periodic behaviour. ARRIVAL TIME JITTER ‐‐ is the deviation of the task from arriving at the precise periodic time of arrival. It may be caused by imprecise clocks, or other factors such as network congestions. COMPLETION TIME JITTER ‐‐ is the deviation of the completion of a task from precise periodic points. It may be cause by the specific algorithm employed for scheduling and the load at an instant.


CLASSIFICATION OF REAL‐TIME TASK SCHEDULING ALGORITHMS

COMMON CLASSIFICATIONS of real‐time task scheduling algorithms are based on:HOW THE SCHEDULING POINTS ARE DEFINED ‐ in this class we have the following types of schedulers:

A)

Table‐drivena.Cyclicb.

CLOCK DRIVEN1)

Simple priority‐based;a.Rate Monotonic Analysis (RMA)b.Earliest Deadline First (EDF)c.

EVENT DRIVEN ‐‐more complex, more proficient (they can schedule some task sets that clock driven can't), and more flexible (they can feasibly schedule sporadic and aperiodic tasks in addition to periodic tasks) than clock driven. EDF and RMA are the most popular scheduling algorithms that came as the result of intensive research during 1970s. These two algorithms form the basis of uniprocessor scheduling.

2)

Round‐robina.HYBRID3)

TYPE OF ACCEPTANCE TEST PERFORMED BY SCHEDULER ‐ in this class we have two broad categories

B)

Planning‐base 1)Best effort2)


Best effort ‐‐ no acceptance test is performed. All tasks that arrive are taken up for scheduling and best effort is made to meet their deadlines. But, no guarantee is given as to whether a task's deadline would be met. Planning Base ‐ the scheduler first determines whether the task can meet its deadlines and if does not cause other already scheduled tasks to miss their deadlines, before it is taken up for execution. THE TARGET PLATFORM on which the tasks are to be run. According to this scheme, we have the following classes of scheduling algorithms:

C)

Uniprocessor: are the simplest scheduling algorithms1)Multiprocessor: algorithms must first decide which task needs to run on which processor and then these tasks are scheduled.

2)

In contrast to multiprocessor systems the processors in a distributed system: do not possess shared memory; there is no global up‐to‐date state information available. As a result, uniprocessor algorithms that assume a central state information of all tasks are unsuitable to be used in distributed systems.

a.

The communication among tasks in distributed systems is through message passing which is costly. As a result, the communication among tasks in distributed systems should be minimized.

b.

Distributed systems ‐‐ we need first to allocate tasks and we need carefully designed scheduling algorithms:

3)


CLOCK‐DRIVEN SCHEDULING

Scheduling points are determined by timer interrupts

○

Clock driven schedulers make their scheduling decisions regarding which task to run next, only at the clock interrupt points

•

Clock‐driven schedulers are also called off‐line schedulers because these schedulers fix the schedule before the system starts to run (predetermines which task will run when).

•

These schedulers incur very little run time overhead

•

The exact time of occurrence of these tasks cannot be predicted.

○

SHORTCOMING OF THIS CLASS OF SCHEDULERS is that they cannot satisfactorily handle aperiodic and sporadic tasks

As a result, these schedulers are also called static schedulers.

•

IMORTANT CLOCK‐DRIVEN SCHEDULERS ARE:Table‐driven 1)Cyclic schedulers2)

ENGG4420 ‐ CHAPTER 4 ‐ LECTURE 2 and 3November‐04‐097:51 PM


TABLE DRIVEN SCHEDULING

Table‐driven schedulers usually precompute which task would run and when and store this schedule in a table at the time the system is designed or configured.The application programmer can be given the freedom to select his own schedule for the set of tasks in the application and store the schedule in a table called schedule table to be used by the scheduler at the run time.

•

An important question for this type of scheduler is what would be the SIZE OF THE SCHEDULE TABLE that would be required for a given set of tasks in system ?

•


THE SIZE OF THE SCHEDULE TABLE

Given a set of n tasks ST = {Ti}, then the entries in the schedule table will replicate themselves after the major cycle of the set ST.

•

The major cycle of the set ST is the Least Common Multiple of the periods of all the tasks in ST: LCM(p1, p2, ..., pn), where p1, p2, ..., pn are the periods of T1, T2, ..., Tn.

•

For any given task set it is sufficient to store the entries only for LCM(p1, p2, ..., pn) duration in the schedule table.

•

DEFINITION: a major cycle of a set of tasks is an interval of time on the time line such that in each major cycle, the different tasks recur identically.

•

The above reasoning assumed that all tasks are in phase meaning that Φi = 0.


THEOREM: The major cycle of a set of tasks ST =

{T1, T2, ..., Tn) is LCM{p1, p2, ..., pn} even when the tasks have arbitrary phasing.PROOF. Let's assume that the occurrences of a task Ti in a major cycle are as shown below.

In figure above there are k‐1 occurrences of the task Ti in the major cycle M.

•

The first occurrence of Ti starts at φ•The major cycle M ends x time units after the last occurrence of Ti (i.e., Ti(k‐1)).

•

Of course this scenario must be the same in all major cycles.•

M = (k‐1)*pi + φ + x; (1)○

Inspecting the figure above we can conclude that for a task to repeat identically in each major cycle we need to have:

•

M = (k ‐ 1)*pi + pi = k*pi; (2)○

Now, for the task Ti to have identical occurrence times in each major cycle, φ + x must equal to pi. Substituting this in Eq. (1) we get:

•

As a result of (2) M contains an integral multiple of pi and this argument holds for each task in the set.

•

THEREFORE, M = LCM({p1, p2, ..., pn}).•


CYCLIC SCHEDULERS

Many small embedded applications are based on cyclic schedulers that are simple, efficient, and easy to program. For example a temperature controller within a computer controlled air conditioner.

Each task in the task set to be scheduled repeats identically in every major cycle.

○

The major cycle is divided into one or more minor cycles and each minor cycle is called a frame.

○

THE SCHEDULING POINTS of a cyclic scheduler occur at frame boundaries. As a result, a task can start executing only at the beginning of a frame.

○

The frame boundaries are defined through interrupts generated by a periodic timer.

○

Each tasks is assigned to run in one or more frames○The assignment of tasks to frames is stored in a schedule table.○

A cyclic scheduler repeats a precomputed schedule that is stored for one major cycle.

•


SELECTING THE SIZE OF THE FRAME

The size of the frame to be used by the scheduler is an important design parameter and needs to be chosen carefully.

•

Minimum context switching1)Minimization of table size2)Satisfaction of task deadline3)

A frame size should satisfy the following 3 constraints:•

MINIMUM CONTEXT SWITCHINGThis constraint aims to minimize the number of context switching during task execution. As a result, a task should complete running within its assigned frame. Otherwise the task might have to be suspended and restarted in a later frame.

•

To avoid unnecessary context switches, the selected frame size should be larger than the execution time of each task.

•

FORMALLY the constraint is: max ({ei}) ≤ F (1)Where, ei is the execution time of the task Ti, and F is the frame size.Note that this constraint imposes a lower‐bound on frame size, i.e., the frame size F must not be smaller than max ({ei}).

•


MINIMIZATION OF TABLE SIZE

The constraint 2 requires that the number of entries in the schedule table should be minimum in order to minimize the storage requirement of the schedule table.

No fractional minor cycles in M so we don't need to store the table for more than one M

○

Minimization of the number of entries to be stored in the schedule table can be achieved when the minor cycle F squarely divides the major cycle M.

•


SATISFACTION OF TASK DEADLINE

Constraint 3 imposes that between the arrival of a task and its deadline, there must exist at least one full frame ‐ this constraint arises from the fact that a task can only be taken up for scheduling at the start of a frame.

If between the arrival and completion of a task not even one frame exists, a situation as shown in figure above might arise ‐‐ in this case the task arrives a little after the kth frame and can't be taken for scheduling until frame (k+1).

•

However, if the execution time e of T is greater than x then T misses its deadline.

•

We therefore, need a full frame to exist between the arrival of a task and its deadline.

•


THE FORMULATION OF CONSTRAINT 3

Assume that a single frame is sufficient to complete T•

2F ‐ Δt ≤ d; or 2F ≤ Δt + d○The worst case scenario for a task to meet its deadline occurs for its instance that has the minimum separation from the start of frame (in this case the task would have to wait the longest before its execution can start)

○

The determination of the minimum separation value (i.e., min(Δt) for a task among all instances of the task would help in determining a feasible frame size.

○

The task can complete before its deadline if:•

Next theorem shows that min(Δt) = GCD(F, pi); =>•

‐

Here GCD is the greatest common multiple.


THEOREM ‐MINIMUM SEPARATION

Theorem. The minimum separation of the task arrival from the corresponding frame start time (min(Δt)) considering all instances of a task Ti is equal to GCD(F, pi). (GCD means greatest common divisor)

PROOF. Let g = GCD(F, pi) => g must divide squarely F and pi;Let Ti be a task with 0 phasing;Assume that the Theorem is violated for certain integers m and n, such that Ti(n) occurs in the mth

frame and the difference between the start time of mth frame and the arrival of nth instance of the task Ti is less than g;That is,

We proved that the minimum separation can't be smaller than GCD(F, pi).

•


SELECTING A FRAME SIZE

For a given task set it is possible that more than one frame size satisfies all the 3 constraints. In such cases, it is better to choose the shortest frame size. This is because the schedulability of a task set increases as more number of frames become available in a major cycle.

•

A suitable frame size for a task set does not assure a feasible schedule for the task set. It may so happen that there are not enough number of frames available in a major cycle to be assigned to all the task instances.

•

Next we show 2 examples. In Example 1 we can find a suitable frame size that satisfies all 3 constraints.

•

In such cases, to find a feasible frame size we might have to split the task (or a few tasks) that is (are) causing the violation of the constraints into smaller sub‐tasks that can be scheduled in different frames.

○

It is difficult to come up with a set of guidelines to identify the exact task that is to be split, and the parts into which it needs to be split. This can therefore be done by trial and error.

○

However, it is possible that a suitable frame size may not exist for many problems (Example 2):

•


EXAMPLE 1

A cyclic scheduler is to be used to run the following set of periodic tasks on a uniprocessor: T1:(4, 1); T2:(5, 1); T3:(20, 1); T4:(20, 1.5).

Select an appropriate frame size.SOLUTION. For the given task set, an appropriate frame size is the one that satisfies all the 3 required constraints. Below we determine a suitable frame size F that satisfies all 3 constraints.Constraint 1. Let F be an appropriate frame size, then max {1, 1, 1, 1.5} ≤ F. From this constraint F ≥ 1.5;

1.

Constraint 2. The major cycle M for the given task set is given by M = LCM(4, 5, 20, 20) = 20. M should be an integral multiple of the frame size F, i.e., M mod F = 0. This consideration implies that F {2, 4, 5, 10, 20}. Note: Frame size of 1 has been ruled out since it would violate the constraint 1.

2.

Constraint 3. To satisfy this constraint, we need to check whether a selected frame size F satisfies the inequality: 2F ‐ GCD(F, pi) ≤ di; for each pi.

3.

Next page shows the calculations for Constraint 3.


EXAMPLE 2

Consider the following set of periodic real‐time tasks to be scheduled by a cyclic scheduler:T1:(4, 1); T2:(5, 2); T3:(20, 5).

Determine the frame size for the task set.SOLUTION. Using Constraint 1 => F ≥ 5;Using Constraint 2 => M = LCM(4, 5, 20) = 20As a result the set of values for F is {5, 10, 20}.

To overcome this problem, we need to split the task that is making the task set unschedulable;

○

It is easy to observe that task T3 has the largest execution time, and consequently due to Constraint 1 makes the feasible frame size quite large.

○

T3,1 = (20, 1, 20); T3,2 = (20, 2, 20); T3,3 = (20, 2, 20).

We try to split T3 into 3 sub‐tasks. After splitting T3 into 3 tasks, we have:

○

Now the new possible values of F are 2 and 4. We can check that after splitting the tasks, F = 2 and F = 4 are feasible frame sizes ‐‐ we pick the smallest one.

○

Checking for a frame size that satisfies Constraint 3, we can find that no value of F is suitable.


ALGORITHM FOR CONSTRUCTING STATIC SCHEDULES

The INF algorithm iteratively tries to find a feasible cyclic schedule of the system for a possible frame size at a time, starting from the largest possible frame size in order of decreasing frame size.

•

A feasible schedule thus found tells us how to decompose some tasks into subtasks if their decomposition is necessary.

•

If the algorithm fails to find a feasible schedule after all the possible frame sizes have been tried, the given tasks do not have a feasible cyclic schedule that satisfies the frame size constraints even when tasks can be decomposed into subtasks.

•

ENGG4420: Real-Time Systems Design; Developed by Radu Muresan82

Scheduling Independent Preemptable Tasks; The Iterative Network-Flow (INF) Algorithm

The general problem of choosing minor frame length for a given set of periodic tasks, segmenting the tasks if necessary, and scheduling the tasks that meet all their deadlines is NP-hard

Step 1: Find all possible frame sizes of the system that meet the frame size constrains 2 and 3 but not necessarily constraint 1;

Step 2: Apply INF algorithm starting with the largest possible frame;

The INF algorithm iteratively tries to find a feasible cyclic schedule of the system for a possible frame size at a time, starting with the largest value Example that meets constraints (2) and (3) but not 1

T1=(4,1); T2=(5,2,7) and T3=(20,5) Frame sizes: 2 and 4



Network-Flow Graph The algorithm used in

each iteration is based on the network-flow formulation of the preemptive scheduling problem

In this formulation we ignore the tasks to

which the jobs belong we name the jobs in a

major cycle of F frames as J1, J2, ..., JN

the constraints are represented by a graph

The graph contains the following vertices, edges Job vertex Ji, i=1, ..., N Frame vertex j, j=1,..., F Vertices source and sink Edges (Ji,j) if job Ji can be

scheduled in frame j edge capacity = f

Edges from source to every job vertex Ji edge capacity = ei

Edges from every frame vertex to the sink edge capacity = f

J1, J2, ..., JN is an enumeration of all tasks instances that need to be scheduled in the major cycle M that contains F frames.

•

Here a job can be understood as an instance of a task.•



Network Flow Graph Algorithm

A flow of an edge is a positive number that satisfies the following constraints: < the edge capacity

∑(flow into vertexes) = ∑(flow out)

Flow of a network-flow graph = ∑(all flows into the sink)

Problem: Find the maximum flow of network-flow graph

J1 J2 JN

1 2 3 F

Jobs/Major cycle

Frames/Major cycle

source

(ei), ei

Ji(f), h x

(f), h

(f), ei+ek-h

sink

(f), 0. . .

F

z(f), 0

Jk(ek), ek

(f), ek

(f) ei-h

y

(f), 0

Jobs Frames

A flow of an edge is a nonnegative number that satisfies the following two constraints:

•

(1) It is no greater than the capacity of the edge and (2) with the exception of the source and sink, the sum of the flows of all the edges into every vertex is equal to the sum of the flows of all the edges out of the vertex. This slide shows part of a network‐flow graph. The label “(capacity), flow” of each edge gives its capacity and flow. This graph indicates that job Ji can be scheduled in frames x and y and the job Jk can be scheduled in frames y and z.

•

A flow of a network‐flow graph, or simply a flow, is the sum of the flows of all the edges from the source and it should equal to the sum of the flows of all the edges into the sink.

•

There are many algorithms for finding the maximum flows of network‐flow graphs. The time complexity of the straightforward ones is O((N+F)^3).

•



Maximum Flow and Feasible Preemptive Schedule

The flow of an edge (Ji,j) gives the amount of time in frame j allocated to job Ji

The maximum flow ≤ ∑ (all job times per major cycle)

The set of flows of edges from job vertices to frame vertices that gives the maximum flow represents a feasible preemptive schedule of the jobs in the frame

source

J1+4

J1+2

J1+3

J1+1

J1+5

J2+1

J2+2

J2+3

J2+4

J3+1

(1),1

(1),1

(1),1

(1),1

(1),1

(2), 2

(2), 2

(2), 2

(2), 2

(2), 2

(4),1

(4),1

(4),1

(4),1

(4),2

(4),2

(4),1

(4),1

(4),2

(4),4

(4),4

(4),4

(4),3

(4),3

(4),2

(4),0

(4),3

(4),0

2

3

4

5

(4),2

1

sink

Clearly, the maximum flow of a network‐flow graph defined above is at most equal to the sum of the execution times of all the jobs to be scheduled in a major cycle.

•

The set of flows of edges from job vertices to frame vertices that gives this maximum flow represents a feasible preemptible schedule of the jobs in the frames. Specifically, the flow of an edge (Ji, j) from a job vertex Ji to a frame vertex j gives the amount of time in frame j allocated to job Ji.

•

This figure considers the previous example with tasks T1, T2, and T3. The possible frame sizes that satisfy Constraints 2 and 3 are f= 4 and 2. The network‐flow graph used in the first iteration when f=4 is shown in this figure.

•

We want every job to be scheduled in a frame which begins no sooner than its release time and ends no later than its deadline. This is reason for the edges from the job vertices to the frame vertices.

•

The maximum flow of this graph is 18, which is the total execution time of all the jobs in a hyperperiod. Hence, the flows of edges from the job vertices to the frame vertices represent a schedule of the tasks.

•

It is possible that the maximum flow of a network‐flow graph is less than the sum of the execution times of all N jobs. This fact indicates that the given tasks have no feasible schedule with the frame size used to generate the graph.

•


WORK PAGE EXAMPLE


GENERALIZED TASK SCHEDULER

In practical applications we need to be able to schedule a mixture of periodic, aperiodic, and sporadic tasks.

•

Assigning aperiodic and sporadic tasks to frames will affect the overall achievable utilization factor of the system.

•

Slack time in a frame is the time left after the periodic tasks allocated to the frame complete.

○

In a generalized scheduler, initially a schedule only for periodic tasks is developed; the sporadic and aperiodic tasks are scheduled in the slack time available in the frames.

•

An arriving sporadic task is taken for scheduling only if enough slack time is available the task to complete before its deadline => acceptance test upon its arrival

•

The best effort can be made to schedule them in the available slack ‐ no guarantee for meeting deadlines.

○Aperiodic task do not have strict deadline •

EFFICIENT IMPLEMETATION ‐ slack times for all frames are stored in a table and during acceptance test this table is used to check schedulability of the arriving tasks

•

POPULAR ALTERNATIVE ‐ all sporadic and aperiodic tasks are accepted and best effort is made to meet their deadlines

•

ENGG4420 ‐‐ CHAPTER 4 ‐‐ LECTURE 4November‐12‐092:49 PM


PSEUDO‐CODE FOR A GENERALIZED SCHEDULER

The generalized scheduler below schedules periodic, aperiodic, and sporadic tasks; it is assumed that the precomputed schedule for periodic tasks is stored in a schedulable table, and the sporadic tasks have been subjected to an acceptance test and only the tasks that have passed the test are available for scheduling

•

cyclic-scheduler( ) {current-task T = Schedule-Table [k];k = k + 1; //N is the total number of tasksk = k mod N; //in the schedule table

dispatch-current-Task (T);repeat above instruction for all tasks in periodschedule-sporadic-tasks( ); //current task T //completed early, sporadic task can be takenschedule-aperiodic-tasks ( ); //at the end of the //frame, the running task is preempted, //if not completeidle ( ); //no task to run, idle}

The cyclic scheduler routine cyclic‐scheduler() is activated at the end of every frame by a periodic timer

•


COMPARISON OF CYCLIC AND TABLE‐DRIVEN SCHEDULING

A cyclic scheduler needs to set a periodic timer only once at the application initialization time; this timer continues to give an interrupt exactly at every frame boundary.

•

In a table‐driven scheduling, a timer has to be set every time a task starts to run; the execution time of a typical real‐time task is usually of the order of a few milliseconds => a call to a timer is made every few milliseconds => degraded system performance.

•

A CYCLIC SCHEDULER IS MORE EFFICIENT THAN A TABLE‐DRIVEN SCHEDULER

•

The frame size must be chosen to be greater than the largest execution time of a task => processor time can be wasted when we execute tasks that have their execution times smaller than the frame size.

○

If the overhead of setting a timer can be ignored A TABLE DRIVEN SCHEDULER IS MORE PROFICIENT than a cyclic scheduler because:

•


HYBRID SCHEDULERS

In hybrid schedulers, the scheduling points are defined both through the clock interrupts and the event occurrences.

ENGG4420: Real-Time Systems Design; Developed by Radu Muresan; Fall 200628

Time-Sliced Round-Robin SchedulingAlso, called processor-sharing algorithm

Round-robin approach is used for scheduling time-shared applications

n n-1 3 2 1

FIFO Queue

Scheduling Algorithmti – time slice (xx ms)

t1 t2 tn

Job Completion

preempted

jobs enteringthe queue

the job at the head of the queueenters execution for at most one time slice

Round period = n*tWhere: n - number of jobsand t - time slice1/n – processor share/job

Time sliced round‐robin schedulers are commonly used in the traditional operating systems.

•

This type of scheduler treats all task equally, and all tasks are assigned identical time slices irrespective of their priority, criticality, or closeness to their deadline.

○

A time‐sliced round‐robin scheduler is less proficient than table‐driven or cyclic scheduler

•

We can extend the round‐robins scheme and assign weights to tasks.

•



Weighted Round-Robin Approach

WRR has been used for scheduling real-time traffic in high-speed switched networks

n n-1 3 2 1

FIFO Queue

Scheduling Algorithmt – time slice (xx ms)

w1t w2t wnt

Job Completion

preempted

jobs enteringthe queue

the job at the head of the queueenters execution for wt slices

Round length = ∑(wi*t)

The weighted round‐robin algorithm has been used for scheduling real‐time traffic in high‐speed switched networks.

•

Rather than giving all the ready jobs equal shares of the processor, different jobs may be given different weights. Here, the weight of a job refers to the fraction of processor time allocated to the job.

•

Specifically, a job with weight w gets w*t time slices every round, and the length of a round is equal to the sum of the weights of all the ready jobs. By adjusting the weights of the jobs, we can speed up or retard the progress of each job toward its completion.

•


SHORTCOMINGS OF CYCLIC SCHEDULERSDifficult to determine a suitable frame size as well as a feasible schedule when the number of tasks is large.

•

In almost every frame some processing time is wasted (as the frame size is larger than all task execution times) resulting in sub‐optimal schedules.

•

Reduced proficiency in handling sporadic and aperiodic tasks.

•

EVENT DRIVEN SCHEDULERS overcome these shortcomings, however they are less efficient as they deploy more complex scheduling algorithms => event‐driven schedulers are less suitable for embedded applications as they required to be of small size, low cost, and consume minimal amount of power.In event‐driven schedulers, the scheduling points are defined by tasks completion and task arrival events.

•

These class of schedulers are normally preemptive, that is, a higher priority task when ready, preempts any lower priority task that may be running.

•

WE DISCUSS 3 important examples of event‐driven schedulers: 1) foreground‐background; 2) EDF; 3) RMA

EVENT‐DRIVEN SCHEDULINGNovember‐13‐096:33 PM



Priority-Driven Approach (Event-Driven) The term priority-driven algorithms refers to a large class of

scheduling algorithms that never leave any resources idle intentionally

Priority-driven algorithms are event-driven scheduling decisions are made when events such as release and

completions of jobs occur A priority-driven algorithm is greedy because it tries to make

locally optimal decisions A priority-driven algorithm is list scheduling because any priority-

driven algorithm can be implemented by assigning priorities to jobs

ResourceAvailability Data

List of PrioritiesQueues

Releasesand

Completionsof Jobs

Priority Driven Scheduling Algorithms

Events

greedy scheduling list scheduling

A priority driven algorithm is greedy because it tries to make locally optimal decisions. Leaving a processor or resource idle while some job is ready to use them is not locally optimal. However, sometimes it is better to have some jobs wait even when they are ready to execute and the resources they require are available.

○

The term list scheduling implies assigning priorities to jobs. Jobs ready for execution are placed in one or more queues ordered by the priorities of the jobs. At any scheduling decision time, the jobs with the highest priorities are scheduled and executed on the available processors. Hence, a priority‐driven scheduling algorithm is defined to a great extent by the list of priorities it assigns to jobs; the priority list and other rules, such as whether preemption is allowed, define scheduling algorithm completely.

○

A resource (processor or other type) idles only when no job requiring the resource is ready for execution. Scheduling decisions are made when events such a release and completions of jobs occur. Hence, priority‐driven algorithm are event‐driven. Other commonly used names for this approach are greedy scheduling, list scheduling and work‐conserving scheduling.

•

Examples include: FIFO (First‐In‐First‐Out), LIFO (Last‐In‐First‐Out) which assign priorities to jobs according to their release time; SETF (Shortest‐Execution‐Time‐First) and LEFT (Longest‐Execution‐Time‐First), which are algorithm that assign priorities based on the basis of job execution time.

○Most scheduling algorithms used in non‐real‐time systems are priority‐driven. •



Example of Priority-Driven Approach

Schedule and execute the jobs J1, …, J8 on 2 processors with shared memory

Task graph: Ji, k i job number

k execution time

J5 released at 4; all other jobs at time 0

Priority list Ji > Jk if i < k

(a) jobs are preemptable

(b) jobs are nonpreemptable

Priority list

0 1 2 3 4 5 6 7 8 9 10 11 12

0 1 2 3 4 5 6 7 8 9 10 11 12

0 1 2 3 4 5 6 7 8 9 10 11 12

0 1 2 3 4 5 6 7 8 9 10 11 12

P1

P2

P1

P2

J1

J2

J2

J1

J3

J3

J4 J7 J6

J5J7 J8

J4 J5 J6

J7 J8

(J1, J2,…,J8)

J1,3

J3,2 J4,2J2,1

J6,4J5,2

J7,4 J8,1

(a)

(b)

All edges in the task graph shown represent precedence constraints. The priority list is given next to the graph: Ji has a higher priority than Jk if i < k. All the jobs are preemptable; scheduling decisions are made whenever some job becomes ready for execution or some job completes.

At time 1, J2 completes and hence, J3 becomes ready; J3 is placed in the priority queue ahead of J7 and is scheduled on P2 (P2 was freed by J2).

○

At time 3, both J1 and J3 complete; J5 is still not released; J4 and J7 are scheduled.

○

At time 4, J5 is released. Now we have 3 jobs ready. J7 has the lowest priority; consequently it is preempted and J4 and J5 have the processors.

○

At time 5, J4 completes; J7 resumes on processor P1.○At time 6, J5 completes; because J7 is not yet completed, both J6 and J8 are not ready for execution; consequently, P2 becomes idle.

○

J7 finally completes at time 8; J6 and J8 can now be scheduled.○

Schedule (a) shows the schedule of jobs on the two processors generated by the priority‐driven algorithm following this priority assignment. At time 0, jobs J1, J2, and J7 are ready for execution. They are the only jobs in the common priority queue at this time. J1 and J2 are scheduled. The following events occur and new scheduling decisions are made:

Schedule (b) shows a non‐preemptive schedule according to the same priority assignment. It turns out that for this system the postponment of J5 at time 4 benefits the set of jobs as a whole. In general, nonpreemptive scheduling is not better than preemptive scheduling.


FOREGROUND‐BACKGROUND SCHEDULER

Simplest priority‐driven preemptive schedulerReal‐time tasks are run as foreground tasks;•The sporadic, aperiodic, and non‐real‐time tasks are run as background tasks ‐ the background tasks run at the lowest priority.

•

Assume that we have n foreground periodic tasks T1, T2, ..., Tn and one background task TB with its execution time eB. In this case the completion time ctB for the background task is given by:

•


EXAMPLE 1

Consider a real‐time system in which tasks are scheduled using foreground‐background scheduling of one foreground task Tf and one background task TB. Compute the completion time for the background task if:


ASSIGNMENTS

PROBLEM 1. In a simple priority‐driven preemptive scheduler, two periodic tasks T1 and T2 and a back‐ground task T3 are scheduled. The periodic task T1 has the highest priority and executes once every 20 ms and requires 10 ms of execution time each time. T2 requires 20 ms of processing every 50 ms. T3, the background task, requires 100 ms to complete. Assuming that all the tasks start at time 0, determine the time at which T3 will complete.

PROBLEM 2. Suppose that in PROBLEM 1, an overload of 1 ms on account of every context switch is to be taken into account. Compute the completion time of T3.


In EDF scheduling, at every scheduling point the task having the shortest absolute deadline is taken up for scheduling.A task set is schedulable under EDF, if and only if it satisfies the condition that the total processor utilization due to the task set is less than 1. For a set of periodic real‐time tasks {T1, T2, ..., Tn}, EDF schedulability criterion can be expressed as:

•

EDF has been proven to be an optimal uniprocessor scheduling algorithm.

•

If pi > di, then each task needs ei execution time every min(pi, di). Therefore, Eq (2) can be rewritten as:

•

However, if pi < di, it is possible that a set of tasks is EDF schedulable, even when the task set fails to meet Eq. (3). Therefore, Eq. (3) is conservative in this case and is not a necessary condition, but only a sufficient condition for a given task set to be EDF schedulable.

•

EARLIEST DEADLINE FIRST (EDF) SCHEDULINGNovember‐13‐096:35 PM


EXAMPLE OF EDF SCHEDULE

Consider the following task set


MINIMUM LAXITY FIRST (MLF) scheduling is a variant of EDF. In MLF, at every scheduling point, a laxity value is computed for every task in the system, and the task having the minimum laxity is executed first.

Unlike EDF, MLF takes into consideration the execution time of a task

○

Laxity of a task measures the amount of time that would remain if the task is taken up for execution next ‐ laxity is a measure of the flexibility available for scheduling a task.

•


Minimum Laxity First (MLF) Algorithm

Scheduler checks the slack of all the ready jobs each time a new job is released (Slack = d-t-x) and schedules based: The smaller the slack the higher the priority

Ex. {T1,T2} = {(2, 0.9), (5, 2.3)} => LST identical with EDF Ex.{T1,T2,T3} = {(2, 0.8), (5, 1.5), (5.1,1.5)} => Φi=0; Di=pi

(p1,e1) (p2,e2) (p3,e3)(Φi,pi,ei,Di)

2 4 5 10

2 4 5 10

Decision

Execution

Decision

Execution

Φ=0J1,1

J2,1

J3,1

J1,2

J2,1

J3,1


EDF EXAMPLE

Consider the 3 periodic real‐time tasks to be scheduled using EDF on a uniprocessor: T1:(20, 10); T:(50, 5); T3:(35, 10).

Determine whether the task set is schedulable.


IS EDF REALLY A DYNAMIC PRIORITY SCHEDULING ALGORITHM

If EDF were to be considered a dynamic priority‐scheduling algorithm, we should be able to determine the priority value of each task at any point of time and also be able to show how it changes with time.

•

As described, EDF scheduling does not require any priority value for any task to be computed at any time.

•

Tasks are scheduled solely on their proximity to their deadlines.

•

However, the longer the task waits in the ready queue, the higher the chance (probability) of being taken up for scheduling. As a result, a virtual priority value associated with a task keeps increasing with time until the task is taken up for scheduling.

•

If we associate a priority to the task that is related to the proximity to the absolute deadline then EDF is a dynamic scheduling.

•

ENGG4420 ‐‐ CHAPTER 4 ‐‐ LECTURE 5November‐14‐094:57 PM



EDF Algorithm

0 2 4 6 8 10

EDF algorithm: dynamic-priority algorithm assigns priorities to individual jobs in the tasks according to their

absolute deadlines task-level dynamic-priority (and job-level fixed-priority) algorithm

once a job is placed in the ready queue according to its priority its order with respect to other jobs in the queue remains fixed

Ex: Priority of T1 is > priority of T2 from time 0 until time 4 T2 starts to have higher priority at time 4 When job J2,2 is released, T2 again has a lower priority

(b)

RM-ScheduleAn earliest-deadline-first schedule of (2, 0.9) and (5, 2.3)

0 2 4 6 8 10

On the other hand, RM is a fixed priority algorithm at the task and job levels.

•

The RM schedule above is not dynamic, the priority of the tasks is based on their frequency that is the inverse of the period.

•


IMPLEMENTATION OF EDF

Maintain all ready tasks in a queuea.Insert new freshly arriving tasks at the end of queueb.Every node in the queue will contain the Di (relative deadline) of tasks.

c.

At every preemption point the entire queue will be scanned from beginning to determine the task with the shortest deadline.

d.

Complexity of the scheme: insertion of a task is achieved in O(1) or constant time; task selection (to run next) and its deletion would require O(n) time sine it needs to scan the entire queue.

e.

NAIVE IMPLEMENTATION OF EDF: 1.

Maintain all ready tasks in a sorted priority queue that can be efficiently implemented by using a heap data structure ‐ the sort criteria is in accordance to the tasks proximity to their deadline.

a.

When a task arrives, a record for it can be inserted into the heap in O(log2n) time.

b.

At every scheduling point, the next task to be run can be found at the top of the heap. So, in O(1) time.

c.

EFFICIENT IMPLEMENTATION 1 OF EDF: 2.

Assume that the number of distinct deadlines that tasks in an application can have are restricted.

a.

A separate FIFO queue is maintained for each distinct relative deadline.

b.

The scheduler inserts a newly arrived task at the end of the corresponding relative deadline queue. As a result, tasks in each queue are ordered according to their absolute deadline.

c.

Complexity: find the task to run is in O(1) time; time to insert a task is O(1).

d.

EFFICIENT IMPLEMENTATION 2 OF EDF:3.


SHORTCOMINGS OF EDF

When EDF is used to schedule a set of periodic real‐time tasks, a task overshooting its completion time can cause other task(s) to miss their deadlines.

a.

We can't predict which task will miss its deadline, and it can happen with the most critical task.

b.

TRANSIENT OVERLOAD PROBLEM: denotes the overload of a system for a very short time. Transient overload occurs when some task takes more time to complete due to reasons such as, entering an infinite loop, entering a rarely used branch due to some abnormal input values, etc.

1.

RESOURCE SHARING PROBLEM: when EDF is used to schedule a set of real‐time tasks, unacceptably high overheads might have to be incurred to support resource sharing among the tasks without making tasks to miss their respective deadlines (later).

2.

EFFICIENT IMPLEMENTATION PROBLEM: the efficient implementation that assumes a restricted number of tasks with distinct deadlines is not always feasible. For a more flexible EDF algorithm, we need to keep the tasks ordered in terms of their deadlines using a priority queue.

3.


The lower the occurrence rate of a task , the lower the priority assigned to it.

○

A task having the highest occurrence rate (lowest period) is accorded the highest priority.

○

RMA is a static priority (event driven) algorithm and is extensively used in practical applications. RMA assigns priorities based on their rate of occurrence:

RMA has been proven to be the optimal static priority real‐time task scheduling algorithm.

•

In RMA the priority of a task Ti is computed as: priority = k/pi, where pi is the period of a task Ti and k is a constant.

•

RATE MONOTONIC ALGORITHM (RMA)November‐17‐091:25 PM


SCHEDULABILITY TEST FOR RMA

Schedulability of a task set under RMA can be determined from a knowledge of the worst‐case execution times and periods of the tasks.

The worst‐case execution times are usually determined experimentally or through simulation

○

QUESTION: how can a system developer determine the worst‐case execution time of a task even before the system is developed?

CRITERIA TO USE FOR RMA SCHEDULABILITY TESTNecessary condition: a set of periodic real‐time tasks would not be schedulable under RMA unless they satisfy the following necessary condition:

1.

Sufficient condition: a set of n real‐time tasks are schedulable under RMA if [see Liu for proof]:

2.


RMA SCHEDULABILITY ANALYSIS

If a set of tasks satisfies the sufficient condition (2), then it is guaranteed that the set of tasks would be RMA schedulable.However, even if a task set fails the sufficient condition (2), it may still be RMA schedulable.


EXAMPLE 1

Check whether the following set of periodic real‐time tasks is schedulable under RMA on a uniprocessor:


EXAMPLE 2

Check whether the following set of three periodic real‐time tasks is schedulable under RMA on a uniprocessor:


LEHOCZKY TEST

Even when a task set fails the sufficient condition we should not conclude that the task set is not schedulable. A test that can be performed to check whether a task set is RMA schedulable when it fails the condition (2) (Liu and Layland test) is the Lehoczky's test.THEOREM. A set of periodic real‐time tasks is RMA schedulable under any task phasing, if all the tasks meet their respective first deadlines under zero phasing.

Example of applying this theorem to Example 2.


FORMAL EXPRESSION FOR LEHOCZKY TEST

Let {T1, T2, ..., Ti} be the set of tasks to be scheduled. Let us also assume that the tasks have been ordered in descending order of their priority. That is, task priorities are related as: pri(T1) > pri(T2)> ... > pri(Ti); In the example below assume that task Ti arrives at time 0. During the first instance of task Ti, 3 instances of task T1 have occurred. Each time Ti occurs, Ti has to wait since T1 has higher priority than Ti.NOTE: worst case response time for a task occurs when it is in phase with its higher priority tasks.


LET US DETERMINE the exact number of times that T1 occurs within a single instance of Ti.


EXAMPLE 3

Consider the following set of 3 periodic real‐time tasks: T1=(20, 10); T2 = (60, 15); T3 = (120, 20) to be run on a uniprocessor. Determine whether the task set is schedulable under RMA.


EXAMPLE 4

RMA is used to schedule a set of periodic hard real‐time tasks in a system. Is it possible in this system that a higher priority task misses its deadline, whereas a lower priority task meets its deadline? If your answer is negative, prove your assertion. If your answer is affirmative give an example involving two or three tasks scheduled using RMA where the lower priority task meets all its deadlines whereas the higher priority task misses its deadline.

SOLUTION: YES


CAN THE ACHIEVABLE CPU UTILIZATION BE ANY BETTER THAN IT WAS PREDICTED?

Liu and Layland RMA schedulability criterion is conservative and restricts the maximum achievable utilization of a task set to 0.69 when the number of tasks in a set is large.Experimentally has been proven that for a large collections of tasks with independent periods, the maximum utilization below which a task set is schedulable is on average close to 88%.

•

The task periods in a task set are said to be harmonically related, if for any two arbitrary tasks Ti and Tk in the task set, whenever pi > pk, it should imply that pi is an integral multiple of pk.

•

THEOREM: for a set of harmonically related tasks HS = {Ti}, the RMA schedulability criterion is given by:


ADVANTAGES AND DISADVANTAGES OF RMA

ADVANTAGES:Unlike EDF, RMA requires very few special data structures

•

Among tasks in a single level, the RTOS provide an option of either round‐robin or FIFO scheduling

○

Most commercial real‐time operating systems support real‐time (static) priority levels for tasks. Tasks having real‐time priority levels are arranged in multilevel feedback queues

•

Will a delay in completion by a lower priority task affect a higher priority task? ‐‐‐ NO ‐‐‐ a lower priority task even when it exceeds its planned execution time, cannot make a higher priority task wait ‐‐ according to the basic principles of RMA a high priority task preempts any lower priority task => execution overshooting in lower priority tasks can not make a high priority task miss its deadline

○

RMA possesses good transient overload handling capability

•

DISADVANTAGESIt is very difficult to support scheduling of aperiodic and sporadic tasks under RMA; RMA is not optimal when task periods and deadlines differ.

•


DEADLINE MONOTONIC ALGORITHM (DMA)

RMA no longer remains an optimal scheduling algorithm for periodic real‐time tasks, when pi and di of tasks differ.For such task sets DMA is more proficient than RMA•

DMA assigns higher priorities to tasks with shorter relative deadlines

○

When the relative deadline of every task is proportional to its period, RMA and DMA produce identical solutions

○

When the relative deadlines are arbitrary, DMA is more proficient than RMA in that it can sometimes produce a feasible schedule when RMA fails ‐‐ on the other hand RMA always fails when DMA fails.

○

DMA is a variant of RMA and assigns priorities to tasks based on their relative deadlines, rather than assigning priorities based on task periods.

•

ENGG4420‐‐ CHAPTER 4 ‐‐ LECTURE 6November‐17‐091:28 PM


EXAMPLE 5

Check if the following task set is schedulable by DMA and then by RMA:


CONTEXT SWITCHING OVERHEAD

So far, we have ignored in our schedulability tests the switching overhead.

The task can run to completion if it is the highest priority task and at completion there is another context switch.

○

If there is another task that arrives then the maximum two context switches are attached to this new task.

○

If the system is in idle mode there is only one context switch at the completion.

○

Under RMA, whenever a task arrives, at most it preempts one task ‐‐ the task that is currently running.

Of course a task may just incur one context switch ‐‐ if it arrives when processor idle or if it arrives when processor running a higher priority tasks.

○

We can conclude that in the worst case, each task incurs at most 2 context switches under RMA: one, when it arrives and preempts a lower priority task and the second when it completes.

•

For simplicity we assume that the context switch is constant, and equals c ms.

•

In order to take context switching time into consideration, in all schedulability computations, we need to replace ei by ei + 2c for each Ti.

○

As a result, we can consider that the net effect of context switch increases the execution time of each task Ti to ei + 2*c.

•


EXAMPLE 6

Check the schedulability under RMA on a uniprocessor for the following task set: T1 = (100, 20); T2 = (150, 30); T3 = (200, 90). Assume that context switching overhead does not exceed 1 ms and is to be taken into account in all computations.


SELF SUSPENSION

When a task self suspends, the operating system removes it from the ready queue, places it in the blocked queue, and takes up the next eligible task for scheduling ‐‐ thus self suspension introduces an additional scheduling point which we did not consider before.

•

Definition. In event‐driven scheduling, the scheduling points are defined by task completion, task arrival, and self‐suspension events.

•

Let the delay that task Ti might incur due to self suspension and the self suspension of all higher priority tasks be bti

○

Self suspension effect on the schedulability of a task set {T1, T2, ..., Tn} when the worst case self suspension time of a task Ti is bi.


EXERCISE: Explain the self suspension expression (1) by justifying the terms of the right side.

SOLUTION ‐‐‐


EXAMPLE 7

Consider the following set of periodic real‐time tasks: T1=(50, 10); T2 = (150, 25); T3 = (200, 50).

Assume that the self suspension times of T1, T2, and T3 are 3, 3, and 5 respectively. Determine if the task will be RMA schedulable.


SELF SUSPENSION WITH CONTEXT SWITCHING OVERHEAD

In a fixed priority preemptable system, each task preempts at most one task if there is no self suspension ‐‐ at most two context switches

○

When a task self‐suspends, it causes at most two additional context switches

○

Let us examine the effect of context switches on the generalized Lehoczky test that consider self suspensions.

We need to replace the execution time of a task Ti by (ei + 4c), where c is the maximum context switch time.

○

As a result, when a task is allowed to self suspend we will incur at most 4 context switches as overhead

•


ISSUES IN USING RMA IN PRACTICAL SITUATIONS

handling critical tasks with long periods; handling aperiodic and sporadic tasks; coping with limited priority levels; dealing with task jitter.

○Practical RMA problems that need to be addressed:

HANDLING CRITICAL TASKS WITH LONG PERIODS

If we raise the priority of critical task to higher level, then the RMA schedulability results would not hold.

○

Consider a very critical task that has a long period in comparison with some task of lower criticality ‐‐ as a result, the critical task could miss at times its deadline due to some transient overload of low critical (but high priority) task.

•

The critical task Ti is logically divided into k small subtasks of period, deadline, execution times of ‐‐ pi/k; di/k and ei/k

○

The net effect of Ti being logically split into {Ti1 ,..., Tik} is to effectively raise the priority of Ti

○

Each subtasks of Ti would be represented by:○

SOLUTION ‐‐ period transformation technique•


HANDLING APERIODIC AND SPORADIC TASKS

Under RMA it is difficult to assign high priority values to sporadic tasks ‐‐ a burst of sporadic task arrivals would overload the system

However, in practical applications sometimes we need high priority for sporadic tasks.

○

The RMA schedulability analysis presented are no longer applicable when aperiodic and sporadic tasks are assigned high priority values ‐‐ therefore these type of tasks have very low priority values

•

SOLUTION: APERIODIC SERVER

The server deposits a "ticket" which is replenished at the expiration of a certain replenishment period.

○

When an aperiodic event occurs, the server checks to see whether any ticket is available.

○

Handles aperiodic and sporadic tasks and passes them to an RMA scheduler.

•

Based on the ticket creation policies we have: 1)deferrable servers; 2) sporadic servers

•

Deferrable servers: tickets are replenished at regular intervals, completely independent of the actual ticket usage ‐‐ if an aperiodic task arrives, the system will process it immediately if it has enough tickets, and wait until the tickets are replenished if it does not.

1.

Sporadic server: the replenishment time depends on exact ticket usage time ‐‐ as soon as a ticket is used, the system set a timer that replaces any used tickets when the timer goes off (in this way a minimum separation between sporadic tasks is guaranteed.

2.


COPING WITH LIMITED PRIORITY LEVELS

To reduce OS overload and to improve task response times,

RTOS support only a restricted number of priority levels (i.e. Real‐Time LabView)

○

As the number of priority levels increases, the number of feedback queues to be maintained by the operating system also increases. As a result, increased memory requirement and processing overhead at every scheduling point.

•

PROBLEM: more tasks than priority levels => more tasks need to share same priority level ‐‐ RMA analysis differ in this case

•

Let SP(Ti) be the set of tasks sharing a single priority value with the task Ti

○

HOW LEHOCZKY'S TEST CHANGES when priority sharing among tasks?


PRIORITY ASSIGNMENT TO TASKS

There are various schemes available for assigning priority values to tasks when the number of real‐time tasks to be scheduled exceed the distinct real‐time priority levels supported by the underlying OSUniform Scheme: all tasks in the application are divided uniformly among the available priority levels ‐‐ if uniform division is not possible, then more tasks should be made to share the lower priority levels for better schedulability;

1)

Arithmetic scheme: the number of tasks assigned to different priority levels form an arithmetic progression ‐‐ a possible scenario would be that r tasks are assigned to the highest priority level, 2r to the next highest priority level, etc. ‐‐ for a total of N tasks in an application N = r + 2r + 3r + ... nr; where n is the total number of priority levels;

2)

Geometric scheme: the number of tasks assigned to different priority levels form a geometric progression ‐‐ the r task having the shortest periods are assigned to the highest priority level, kr2 tasks are assigned to the next highest priority level, etc. ‐‐

3)


The scheme requires that the shorter period tasks should be allotted distinct priority levels as much as possible while the lower priority tasks should be combined together at the same priority levels ‐‐ the high priority tasks will be assured schedulability.PROCEDURE: arrange task in increasing order of their periods; the range of task periods are divided into a sequence of logarithmic intervals; the tasks are assigned to priority levels based on the logarithmic intervals they belong to

•

EXAMPLE. Consider an OS with 4 priority levels. An application with 10 periodic real‐time tasks are to be scheduled on this OS using RMA. It is known that pmax = 10,000 ms and pmin = 1 ms. Other task periods are distributed uniformly over this interval. Assign the tasks to priority levels using the logarithmic scheme

Logarithmic scheme or logarithmic grid assignment scheme

4.


DEALING WITH TASK JITTER

(Arrival jitter) = (latest arrival time among all tasks) ‐(earliest arrival time among all tasks)(Completion time jitter) = ...CAUSES FOR ARRIVAL JITTER ‐‐ physical clock skewCAUSES FOR COMPLETION JITTER ‐‐ basic nature of RMA ‐‐ the response time of a task depends on how many higher priority tasks arrive (or were waiting) during the execution of the task.Real‐time developers commonly handle tasks with tight completion time jitter requirements following one of these techniques:

•

If only one or two actions (tasks) have tight jitter requirements, these actions are assigned very high priority ‐‐ works well for small applications

1.

This method involves setting the second task's priority to very high values and its period to be the same as that of the first task ‐‐ an action scheduled with this approach will run one cycle behind, but the task will have tight completion time jitter.

a.

If jitter must be minimized for an application that is barely schedulable, each task needs to be split into two parts: one part that computes the output but does not passes it on, and one which passes the output on.

2.


END OF CHAPTER 4


chapter 4 by radu muresan university of guelph

Documents