+ All Categories
Home > Documents > ENGG4420‐‐ CHAPTER 4 ‐‐ LECTURE 5...ENGG4420‐‐CHAPTER 4 ‐‐LECTURE 5...

ENGG4420‐‐ CHAPTER 4 ‐‐ LECTURE 5...ENGG4420‐‐CHAPTER 4 ‐‐LECTURE 5...

Date post: 30-May-2020
Category:
Upload: others
View: 7 times
Download: 0 times
Share this document with a friend
16
DEADLINE MONOTONIC ALGORITHM (DMA) RMA no longer remains an optimal scheduling algorithm for periodic realtime tasks, when task's period pi differs from the relative deadline di. 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 5 November1912 12:07 PM CHAPTER 4 By Radu Muresan University of Guelph Page 1
Transcript

DEADLINE MONOTONIC ALGORITHM (DMA)

RMA no longer remains an optimal scheduling algorithm for periodic real‐time tasks, when task's period pi differs from the relative deadline di.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 5November‐19‐1212:07 PM

CHAPTER 4 By Radu Muresan University of Guelph Page 1

EXAMPLE 5

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

CHAPTER 4 By Radu Muresan University of Guelph Page 2

CONTEXT SWITCHING OVERHEAD

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

However, there might be situations when we have only one context switch such as: 1) the task arrives when the processor is idle or 2) when a higher priority task executes.

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

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).

CHAPTER 4 By Radu Muresan University of Guelph Page 3

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.

CHAPTER 4 By Radu Muresan University of Guelph Page 4

SELF SUSPENSION

When a task self suspends, the operating system removes the task 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.

CHAPTER 4 By Radu Muresan University of Guelph Page 5

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

SOLUTION ‐‐‐

CHAPTER 4 By Radu Muresan University of Guelph Page 6

A higher priority task Tk may affect the response time of a lower priority task Ti by as much as min (ek, bk), as a caused of self suspension.

•SELF SUSPENSION OF A LOWER PRIORITY TASK Ti

CHAPTER 4 By Radu Muresan University of Guelph Page 7

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.

CHAPTER 4 By Radu Muresan University of Guelph Page 8

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

CHAPTER 4 By Radu Muresan University of Guelph Page 9

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 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•

CHAPTER 4 By Radu Muresan University of Guelph Page 10

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.

CHAPTER 4 By Radu Muresan University of Guelph Page 11

COPING WITH LIMITED PRIORITY LEVELS

To reduce OS overload and to improve task response times, 

some 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?

CHAPTER 4 By Radu Muresan University of Guelph Page 12

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)

CHAPTER 4 By Radu Muresan University of Guelph Page 13

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.

CHAPTER 4 By Radu Muresan University of Guelph Page 14

DEALING WITH TASK JITTER

(Arrival jitter) = (latest arrival time among all instances of a task) ‐ (earliest arrival time among all instances of a task);(Completion time jitter) = (latest completion time) ‐(the earliest completion time of the task).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.

CHAPTER 4 By Radu Muresan University of Guelph Page 15

END OF CHAPTER 4

CHAPTER 4 By Radu Muresan University of Guelph Page 16


Recommended