eda222 dit161 real time systems chalmers gu 2010 2011
play

EDA222/DIT161 Real-Time Systems, Chalmers/GU, 2010/2011 - PDF document

EDA222/DIT161 Real-Time Systems, Chalmers/GU, 2010/2011 Lecture #14 Updated February 27, 2011 Specification Dynamic scheduling Implementation -- Deadline-monotonic scheduling


  1. EDA222/DIT161 – Real-Time Systems, Chalmers/GU, 2010/2011 Lecture #14 Updated February 27, 2011 Specification • Dynamic scheduling Implementation -- Deadline-monotonic scheduling • Response-time analysis 1

  2. EDA222/DIT161 – Real-Time Systems, Chalmers/GU, 2010/2011 Lecture #14 Updated February 27, 2011 τ i τ j τ j τ i τ j 5 0 10 t 2

  3. EDA222/DIT161 – Real-Time Systems, Chalmers/GU, 2010/2011 Lecture #14 Updated February 27, 2011 τ i τ j τ j τ i τ j 0 5 10 t τ i τ j τ i R i τ i τ j If , task can be preempted at most one time by τ i τ j If , task can be preempted at most two times by τ i τ j If , task can be preempted at most three times by ... τ j 3

  4. EDA222/DIT161 – Real-Time Systems, Chalmers/GU, 2010/2011 Lecture #14 Updated February 27, 2011 • For static-priority scheduling, the interference term is • The response time for a task is thus: • The equation does not have a simple analytic solution. • However, an iterative procedure can be used: • The iteration starts with a value that is guaranteed to be 0 = C i less than or equal to the final value of (e.g. ) R i n + 1 = R i • The iteration completes at convergence ( ) or if n R i the response time exceeds some threshold (e.g. ) D i 4

  5. EDA222/DIT161 – Real-Time Systems, Chalmers/GU, 2010/2011 Lecture #14 Updated February 27, 2011 D i ≤ T i 5

  6. EDA222/DIT161 – Real-Time Systems, Chalmers/GU, 2010/2011 Lecture #14 Updated February 27, 2011 Task C i D i T i 12 52 52 10 40 40 10 30 30 6

  7. EDA222/DIT161 – Real-Time Systems, Chalmers/GU, 2010/2011 Lecture #14 Updated February 27, 2011 ⎡ ⎤ ∑ R i R i = C i + B i + ⎢ ⎥ C j ⎢ T j ⎥ ∀ j ∈ hp ( i ) • Note that the feasibility test is now only sufficient since the worst-case blocking will not always occur at run-time. priority (H) > priority (M) > priority (L) normal execution H and L share resource R critical region L receives R’s ceiling priority (= H’s priority) H blocked L receives original priority H t M t L t 7

  8. EDA222/DIT161 – Real-Time Systems, Chalmers/GU, 2010/2011 Lecture #14 Updated February 27, 2011 • When using a priority ceiling protocol (such as ICPP), τ i a task can only be blocked once by a task with lower τ i priority than . • This occurs if the lower-priority task is within a critical τ i region when arrives, and the critical region’s ceiling τ i priority is higher than or equal to the priority of . τ i • Blocking now means that the start time of is delayed (= the blocking factor ) τ i • As soon as has started its execution, it cannot be blocked by a lower-priority task. τ i 1. Determine the ceiling priorities for all critical regions. τ i 2. Identify the tasks that have a priority lower than and that calls critical regions with a ceiling priority equal to or τ i higher than the priority of . 3. Consider the times that these tasks lock the actual critical regions. The longest of those times constitutes the blocking factor . 8

  9. EDA222/DIT161 – Real-Time Systems, Chalmers/GU, 2010/2011 Lecture #14 Updated February 27, 2011 C i D i T i H S1 H S2 Task 2 4 5 1 1 - 3 12 12 1 - 8 24 25 2 S 1 S 2 9

Recommend


More recommend