Carnegie Mellon University
Software Engineering Institute
Guaranteeing Real-Time
Performance Using
Rate Monotonic Analysis
Embedded Systems Conference
September 20-23, 1994
Presented by
Ray Obenza
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213
Sponsored by the U.S. Department of Defense
Carnegie Mellon University
Software Engineering Institute
Rate Monotonic Analysis
Introduction
Periodic tasks
Extending basic theory
Synchronization and priority inversion
Aperiodic servers
Case study: BSY-1 Trainer
1
Introduction
Carnegie Mellon University
Software Engineering Institute
Purpose of Tutorial
Introduce rate monotonic analysis
Explain how to perform the analysis
Give some examples of usage
Convince you it is useful
2
Introduction
Carnegie Mellon University
Software Engineering Institute
Tutorial Format
Lecture
Group exercises
Case study
Questions welcome anytime
3
Introduction
Carnegie Mellon University
Software Engineering Institute
RMARTS Project
Originally called Real-Time Scheduling in Ada Project
(RTSIA).
• focused on rate monotonic scheduling theory
• recognized strength of theory was in analysis
Rate Monotonic Analysis for Real-Time Systems
(RMARTS)
• focused on analysis supported by (RMS) theory
• analysis of designs regardless of language or
scheduling approach used
Project focused initially on uniprocessor systems.
Work continues in distributed processing systems.
4
Introduction
Carnegie Mellon University
Software Engineering Institute
Real-Time Systems
Timing requirements
• meeting deadlines
Periodic and aperiodic tasks
Shared resources
Interrupts
5
Introduction
Carnegie Mellon University
Software Engineering Institute
What’s Important in Real-Time
Criteria for real-time systems differ from that for timesharing systems.
Time-Sharing
Systems
Capacity
High throughput
Responsiveness Fast average
response
Overload
Fairness
Real-Time
Systems
Schedulability
Ensured worstcase latency
Stability
• schedulability is the ability of tasks to meet all hard deadlines
• latency is the worst-case system response time to events
• stability in overload means the system meets critical deadlines even if
all deadlines cannot be met
6
Introduction
Carnegie Mellon University
Software Engineering Institute
Scheduling Policies
CPU scheduling policy: a rule to select task to run next
• cyclic executive
• rate monotonic/deadline monotonic
• earliest deadline first
• least laxity first
Assume preemptive, priority scheduling of tasks
• analyze effects of non-preemption later
7
Introduction
Carnegie Mellon University
Software Engineering Institute
Rate Monotonic Scheduling (RMS)
Priorities of periodic tasks are based on their rates:
highest rate gets highest priority.
Theoretical basis
• optimal fixed scheduling policy (when deadlines are
at end of period)
• analytic formulas to check schedulability
8
Introduction
Must distinguish between scheduling and analysis
• rate monotonic scheduling forms the basis for rate
monotonic analysis
• however, we consider later how to analyze systems
in which rate monotonic scheduling is not used
• any scheduling approach may be used, but all realtime systems should be analyzed for timing
Carnegie Mellon University
Software Engineering Institute
Rate Monotonic Analysis (RMA)
Rate monotonic analysis is a method for analyzing sets
of real-time tasks.
Basic theory applies only to independent, periodic
tasks, but has been extended to address
• priority inversion
• task interactions
• aperiodic tasks
Focus is on RMA, not RMS.
9
Introduction
Carnegie Mellon University
Software Engineering Institute
Why Are Deadlines Missed?
For a given task, consider
• preemption: time waiting for higher priority tasks
• execution: time to do its own work
• blocking: time delayed by lower priority tasks
The task is schedulable if the sum of its preemption,
execution, and blocking is less than its deadline.
Focus: identify the biggest hits among the three and
reduce, as needed, to achieve schedulability
10
Introduction
Carnegie Mellon University
Software Engineering Institute
Rate Monotonic Theory - Experience
IBM Systems Integration Division delivered a
“schedulable” real-time network.
Theory used successfully to improve performance of
IBM BSY-1 Trainer.
Incorporated into IEEE FutureBus+ standard
Adopted by NASA Space Station Program
European Space Agency requires as baseline theory.
Supported in part by Ada vendors
11
Introduction
Carnegie Mellon University
Software Engineering Institute
Rate Monotonic Analysis - Products
Journal articles (e.g., IEEE Computer, Hot Topics)
Videotape from SEI
Courses from Telos and Tri-Pacific
A Practitioner’s Handbook for Real-Time Analysis:
Guide to Rate Monotonic Analysis for Real-Time
Systems from Kluwer
CASE tools from Introspect and Tri-Pacific
Operating systems and runtimes from Alsys, DDC-I,
Lynx, Sun, Verdix and Wind River
Standards: Futurebus+, POSIX, Ada 9X
12
Introduction
Carnegie Mellon University
Software Engineering Institute
Summary
Real-time goals are: fast response, guaranteed
deadlines, and stability in overload.
Any scheduling approach may be used, but all real-time
systems should be analyzed for timing.
Rate monotonic analysis
• based on rate monotonic scheduling theory
• analytic formulas to determine schedulability
• framework for reasoning about system timing
behavior
• separation of timing and functional concerns
13
Introduction
Provides an engineering basis for designing real-time
systems
Carnegie Mellon University
Software Engineering Institute
Plan for Tutorial
Present basic theory for periodic task sets
Extend basic theory to include
• context switch overhead
• preperiod deadlines
• interrupts
Consider task interactions:
• priority inversion
• synchronization protocols (time allowing)
Extend theory to aperiodic tasks:
• sporadic servers (time allowing)
Present BSY-1 Trainer case study
14
Introduction
Carnegie Mellon University
Software Engineering Institute
A Sample Problem
Periodics
Servers
Emergency
100 msec
!1
50 msec
20 msec
Data Server
2 msec
150 msec
!2
20 msec
5 msec
Deadline 6 msec
after arrival
40 msec
Comm Server
350 msec
!3
Aperiodics
10 msec
10 msec
Routine
40 msec
2 msec
100 msec
Desired response
20 msec average
!2’s deadline is 20 msec before the end of each period
15
Introduction
Carnegie Mellon University
Software Engineering Institute
Rate Monotonic Analysis
Introduction
Periodic tasks
Extending basic theory
Synchronization and priority inversion
Aperiodic servers
Case Study: BSY-1 Trainer
1
Periodic Tasks
Carnegie Mellon University
Software Engineering Institute
A Sample Problem - Periodics
Periodics
Servers
Emergency
100 msec
!1
50 msec
20 msec
Data Server
2 msec
150 msec
!2
20 msec
5 msec
Deadline 6 msec
after arrival
40 msec
Comm Server
350 msec
!3
Aperiodics
10 msec
10 msec
Routine
40 msec
2 msec
100 msec
Desired response
20 msec average
!2’s deadline is 20 msec before the end of each period.
2
Periodic Tasks
Carnegie Mellon University
Software Engineering Institute
Concepts and Definitions - Periodics
Periodic task
• initiated at fixed intervals
• must finish before start of next cycle
Ci
Task’s CPU utilization: U i = ----Ti
• Ci = compute time (execution time) for task !i
• Ti = period of task !i
CPU utilization for a set of tasks:
U = U1 + U2 + " + Un
3
Periodic Tasks
Carnegie Mellon University
Software Engineering Institute
Example of Priority Assignment
Semantic-Based Priority Assignment
VIP:
IP:
0
25
misses deadline
10
20
30
20
30
Policy-Based Priority Assignment
IP:
0
10
VIP:
0
4
Periodic Tasks
25
1
10 = 0.10
11
VIP: UVIP = 25 = 0.44
IP:
0
UIP =
Carnegie Mellon University
Software Engineering Institute
Schedulability: UB Test
Utilization bound(UB) test: a set of n independent
periodic tasks scheduled by the rate monotonic
algorithm will always meet its deadlines, for all task
phasings, if
Cn
C1
------ + ... + ------- # U(n) = n $ 2 1 / n – 1 %
Tn
T
1
U(1) = 1.0
U(2) = 0.828
U(3) = 0.779
U(4) = 0.756
U(5) = 0.743
U(6) = 0.734
U(7) = 0.728
U(8) = 0.724
U(9) = 0.720
For harmonic task sets, the utilization bound is
U(n)=1.00 for all n.
5
Periodic Tasks
Note: UB test = Techniques 1 and 2 in handbook.
Carnegie Mellon University
Software Engineering Institute
Sample Problem: Applying UB Test
Task !1:
Task !2:
Task&!3:
C
20
40
100
T
100
150
350
U
0.200
0.267
0.286
Total utilization is .200 + .267 + .286 = .753 < U(3) = .779
The periodic tasks in the sample problem are
schedulable according to the UB test.
6
Periodic Tasks
Carnegie Mellon University
Software Engineering Institute
Timeline for Sample Problem
0
100
200
!1
!2
!3
Scheduling Points
7
Periodic Tasks
300
400
Carnegie Mellon University
Software Engineering Institute
Exercise: Applying the UB Test
Given:
Task
!'
!2
!(
C
1
T
4
2
1
6
10
a. What is total utilization?
b. Is the task set schedulable?
c. Draw the timeline.
d. What is the total utilization if C3 = 2?
8
Periodic Tasks
U
Carnegie Mellon University
Software Engineering Institute
Toward a More Precise Test
UB test has three possible outcomes:
0 # U # U $ n % ) Success
U $ n % * U # 1.00 ) Inconclusive
1.00 * U ) Overload
UB test is conservative.
A more precise test can be applied.
10
Periodic Tasks
Carnegie Mellon University
Software Engineering Institute
Schedulability: RT Test
Theorem: for a set of independent, periodic tasks, if
each task meets its first deadline, with worst-case task
phasing, the deadline will always be met.
Response time (RT) test: let an = response time of task i.
an may be computed by the following iterative formula:
i–1 a
i
where a 0 &= + C j
a n + 1 = C i + + -----n- C j
j=1
j = 1 Tj
Test terminates when an+1 = an.
Task i is schedulable if its response time is before its
deadline: an < Ti
11
Periodic Tasks
Carnegie Mellon University
Software Engineering Institute
Example: Applying RT Test -1
Taking the sample problem, we increase the compute
time of !1 from 20 to 40; is the task set still schedulable?
Utilization of first two tasks: 0.667 < U(2) = 0.828
• first two tasks are schedulable by UB test
Utilization of all three tasks: 0.953 > U(3) = 0.779
• UB test is inconclusive
• need to apply RT test
&
12
Periodic Tasks
Carnegie Mellon University
Software Engineering Institute
Example: Applying RT Test -2
Use RT test to determine if !3 meets its first deadline:
i=3
3
a0 =
+ C j = C 1 + C 2 + C 3 = 40 + 40 + 100 = 180
j=1
i–1 a
2
a
0 C = C + +
0 C
=
C
+
+
--------- j
1
i
j
3
j = 1 Tj
j = 1 Tj
&
&=& 100 + &180
& % +
& 180
--------- $ 40 % = 100 + 80 + 80 = 260
--------- $ 40
150
100
13
Periodic Tasks
&
Carnegie Mellon University
Software Engineering Institute
Example: Applying the RT Test -3
2
a1
260 $ 40 % = 30
= C 3 + + ------ C j = 100 + 260
+
$
40
%
----------------100
150
j = 1 Tj
2
a2
300
= C 3 + + ------ C j = 100 + 300
--------- $ 40 % + --------- $ 40 % = 30
100
150
j = 1 Tj
a 3 = a 2 = 300
Done!
Task !3 is schedulable using RT test.
a3 = 300 * T = 350
14
Periodic Tasks
Carnegie Mellon University
Software Engineering Institute
Timeline for Example
0
100
200
300
!1
!2
!3
!3 completes its work at t = 300
15
Periodic Tasks
&
&
&
Carnegie Mellon University
Software Engineering Institute
Exercise: Applying RT Test
Task !1: C = 1 T = 4
1
1
Task !2: C = 2 T = 6
2
2
Task !3: C = 2 T = 10
3
a) Apply UB test
b) Draw timeline
c) Apply RT Test
16
Periodic Tasks
3
Carnegie Mellon University
Software Engineering Institute
Exercise: Worksheet
0
5
10
15
20
0
5
10
15
20
0
5
10
15
20
Task_____
Task_____
Task_____
17
Periodic Tasks
Carnegie Mellon University
Software Engineering Institute
Summary
UB test is simple but conservative.
RT test is more exact but also more complicated.
To this point, UB and RT tests share the same
limitations:
• all tasks run on a single processor
• all tasks are periodic and noninteracting
• deadlines are always at the end of the period
• there are no interrupts
• rate monotonic priorities are assigned
• there is zero context switch overhead
• tasks do not suspend themselves
19
Periodic Tasks
Carnegie Mellon University
Software Engineering Institute
Rate Monotonic Analysis
Introduction
Periodic tasks
Extending basic theory
Synchronization and priority inversion
Aperiodic servers
Case study: BSY-1 Trainer
1
Extending Basic Theory
Carnegie Mellon University
Software Engineering Institute
Extensions to Basic Theory
This section extends the schedulability tests to address
• nonzero task switching times
• preperiod deadlines
• interrupts and non-rate-monotonic priorities
2
Extending Basic Theory
Carnegie Mellon University
Software Engineering Institute
Modeling Task Switching as
Execution Time
Ci + 2S
Ui =
100
0
!'
Ti
C1
!,
C1
C2
C1
200
C1
C2
C2
!(
S
40
C1
time
40
T1
T2
2T1
Two scheduling actions per task
(start of period and end of period)
3
Extending Basic Theory
S
S
C2
S
S
Carnegie Mellon University
Software Engineering Institute
Modeling Preperiod Deadlines
Suppose task !, with compute time C and period T, has
a preperiod deadline D (i.e. D < T ).
Compare total utilization to modified bound:
U total
Cn
C1
= ------ + ... + ------ &#& U
& (n. - i)
Tn
T1
where -i is the ratio of Di to Ti .
3
1 / n – 1% + 1 – - .
$
$
%
n
21
i
i
U(n. - i) = 1
1 - . &- # 1--i 2
/ i
4
Extending Basic Theory
4
1
--&- *& - i # 1.02
2
2
2&
0
Carnegie Mellon University
Software Engineering Institute
Schedulability with Interrupts
Interrupt processing can be inconsistent with rate
monotonic priority assignment.
• interrupt handler executes with high priority
despite its period
• interrupt processing may delay execution of tasks
with shorter periods
Effects of interrupt processing must be taken into
account in schedulability model.
Question is: how to do that?
5
Extending Basic Theory
Carnegie Mellon University
Software Engineering Institute
Example: Determining Schedulability
with Interrupts
Task !1:
Task !2:
Task&!3:
Task&!4:
C
20
40
60
40
T
100
150
200
350
!3 is an interrupt handler
6
Extending Basic Theory
U
0.200
0.267
0.300
0.115
Carnegie Mellon University
Software Engineering Institute
Example: Execution with Rate
Monotonic Priorities
6
!'
!,
!(
!5
7
Extending Basic Theory
'66
,66
(66
566
Carnegie Mellon University
Software Engineering Institute
Example: Execution with an Interrupt
Priority
6
!'
!,
Interrupt
!5
8
Extending Basic Theory
'66
,66
(66
566
Carnegie Mellon University
Software Engineering Institute
Resulting Table for Example
9
Extending Basic Theory
Task
(i)
Period
(T)
Execution
Time
(C)
Priority
(P)
Deadline
(D)
!3
!1
!2
!4
200
100
150
350
60
20
40
40
HW
High
Medium
Low
200
100
150
350
Carnegie Mellon University
Software Engineering Institute
UB Test with Interrupt Priority
Test is applied to each task.
Determine effective utilization (fi) of each task i using
C j Ci 1
f i = + ----- + ----- + ---- + C k
T
T i T i k 7 H1
j 7 Hn j
Preemption
from tasks that can
hit more than once
(with period less than Di)
Preemption
from tasks that can
hit only once
(with period greater than Di)
Execution
of task under test
Compare effective utilization against bound, U(n).
• n = num(Hn) + 1
• num(Hn) = the number of tasks in the set Hn
10
Extending Basic Theory
Carnegie Mellon University
Software Engineering Institute
UB Test with Interrupt Priority: !3
For !3, no tasks have a higher priority: H = Hn = H1 = { }.
f3
C3
= 0 + ------ + 0 #& U $ 1 %
T3
& &
Note that utilization bound is U(1): num(Hn) = 0.
Plugging in numbers:
C3
60
f 3 = ------ = --------- = 0.3 * 1.0
200
T3
11
Extending Basic Theory
Carnegie Mellon University
Software Engineering Institute
UB Test with Interrupt Priority: !1
To !1, !3 has higher priority: H = {!3}; Hn = { }; H1 = {!3}.
C1 1
f 1 = 0 + ------ + ----- + C k #& U $ 1 %
T1 T1k = 3
Note that utilization bound is U(1): num(Hn) = 0.
Plugging in the numbers:
C1 C3
20
60
f 1 = ------ + ------ = --------- + --------- = 0.800 * 1.0
100 100
T1 T1
12
Extending Basic Theory
& && &
Carnegie Mellon University
Software Engineering Institute
UB Test with Interrupt Priority: !2
To !2: H = {!1.!3}; Hn = {!1}; H1 = {!3}.
C j C2 1
f 2 = + ----- + ------ + ----- + C k
T
T2 T2k = 3
j=1 j
#& U& $ 2 %
Note that utilization bound is U(2): num(Hn) = 1.
Plugging in the numbers:
C1 C2 C3
20
40
60
f 2 = ------ + ------ + ------ = --------- + --------- + --------- = 0.867
100 150 150
T1 T2 T2
13
Extending Basic Theory
8
& 0.828
& & & && && & && && &
Carnegie Mellon University
Software Engineering Institute
UB Test with Interrupt Priority: !4
To !2: H = {!1.!2.!3}; Hn = {!1.!2.!3}; H1 = {&}.
C j C4
f 4 = + ----- + ------ + 0
T
T4
j = 1. 2. 3 j
#& U $ 4 %
Note that utilization bound is U(4): num(Hn) = 3.
Plugging in the numbers:
C1 C2 C3 C4
f 4 = ------ + ------ + ------ + -----T1 T2 T3 T4
20
40
60
40
= --------- + --------- + --------- + --------- = 0.882
100 150 200 350
14
Extending Basic Theory
&8 0.756
& & &
Carnegie Mellon University
Software Engineering Institute
Exercise: Schedulability with
Interrupts
Given the following tasks:
Task
(i)
Period
(T)
Execution
Time
(C)
Priority
(P)
Deadline
(D)
!int
!1
!2
6
4
10
2
1
1
HW
High
Low
6
3
10
Use the UB test to determine which tasks are
schedulable.
15
Extending Basic Theory
Carnegie Mellon University
Software Engineering Institute
Solution: Schedulability with
Interrupts
C int
--------- # U $ 1 %
T int
0.334 * 1.0
{H1}
C 1 C int
------ + --------- # U $ 1. .75 %
T1 T1
0.250 + 0.500 = 0.750 = U $ 1. .75 %
{Hn}
C int C 1 C 2
--------- + ------ + ------ # U $ 3 %
T int T 1 T 2
0.334 + 0.250 + 0.100 = 0.684 * 0.779
16
Extending Basic Theory
&
Carnegie Mellon University
Software Engineering Institute
Basic Theory: Where Are We?
We have shown how to handle
• task context switching time: include 2S within C
• preperiod deadlines: change bound to U(n, -i)
• non-rate-montonic priority assignments
We still must address
• task interactions
• aperiodic tasks
We still assume
• single processor
• priority-based scheduling
• tasks do not suspend themselves
17
Extending Basic Theory
Carnegie Mellon University
Software Engineering Institute
Other Important Issues
Mode change
Multiprocessor systems
Priority granularity
Overload
Spare capacity assessment
Distributed systems
Post-period deadlines
18
Extending Basic Theory
Carnegie Mellon University
Software Engineering Institute
Rate Monotonic Analysis
Introduction
Periodic tasks
Extending basic theory
Synchronization and priority inversion
Aperiodic servers
Case study: BSY-1 Trainer
1
Synchronization & Priority Inversion
Carnegie Mellon University
Software Engineering Institute
Sample Problem: Synchronization
Periodics
Servers
Emergency
100 msec
!1
50 msec
20 msec
Data Server
2 msec
150 msec
!2
20 msec
5 msec
Deadline 6 msec
after arrival
40 msec
Comm Server
350 msec
!3
Aperiodics
10 msec
10 msec
Routine
40 msec
2 msec
100 msec
Desired response
20 msec average
!2’s deadline is 20 msec before the end of each period.
2
Synchronization & Priority Inversion
Carnegie Mellon University
Software Engineering Institute
Priority Inversion in Synchronization
Legend
!':{...P(S1)...V(S1)...}
!(:{...P(S1)...V(S1)...}
Critical section
(S1 locked)
Executing
S1 locked
attempts to lock S1 (blocked)
S1 unlocked
Blocked
B
!'(H)
!,(M)
S1 locked
S1 unlocked
!((L)
Time
3
Synchronization & Priority Inversion
B
Carnegie Mellon University
Software Engineering Institute
Priority Inversion
Delay to a task’s execution caused by interference from
lower priority tasks is known as priority inversion.
Priority inversion is modeled by blocking time.
Identifying and evaluating the effect of sources of
priority inversion is important in schedulability
analysis.
4
Synchronization & Priority Inversion
Carnegie Mellon University
Software Engineering Institute
Sources of Priority Inversion
Synchronization and mutual exclusion
Non-preemptable regions of code
FIFO (first-in-first-out) queues
5
Synchronization & Priority Inversion
Carnegie Mellon University
Software Engineering Institute
Accounting for Priority Inversion
Recall that task schedulability is affected by
• preemption: two types of preemption
- can occur several times per period
- can only occur once per period
• execution: once per period
• blocking: at most once per period for each source
The schedulability formulas are modified to add a
“blocking” or “priority inversion” term to account for
inversion effects.
6
Synchronization & Priority Inversion
Carnegie Mellon University
Software Engineering Institute
UB Test with Blocking
Include blocking while calculating effective utilization
for each tasks:
C j Ci Bi 1
f i = + ------ + ----- + ----- + ----- + C k
T
T i T i T i k 7 H1
j 7 Hn j
Hn Preemption
(can hit n times)
7
Synchronization & Priority Inversion
Execution
&
&
Blocking
&
&
H1 Preemption
(can hit once)
Carnegie Mellon University
Software Engineering Institute
RT Test with Blocking
Blocking is also included in the RT test:
i–1
an + 1 = Bi + Ci +
an
----- C j
Tj
+
j=1
i
&
where a 0 = B i +
+ Cj
j=1
Perform test as before, including blocking effect.
8
Synchronization & Priority Inversion
Carnegie Mellon University
Software Engineering Institute
Example: Considering Blocking
Consider the following example:
Periodics tasks
!1
100 msec
25 msec
200 msec
!2
50 msec
Data Structure
10 msec
30 msec
300 msec
!3
100 msec
What is the worst-case blocking effect (priority
inversion) experienced by each task?
9
Synchronization & Priority Inversion
Carnegie Mellon University
Software Engineering Institute
Example: Adding Blocking
Task !2 does not use the data structure. Task !2
experiences no priority inversion.
Task !1 shares the data structure with !3. Task !1 could
have to wait for !3 to complete its critical section. But
worse, if !2 preempts while !1 is waiting for the data
structure.&!1 could have to wait for !2’s entire
computation.
This is the resulting table:
10
Synchronization & Priority Inversion
Task
Period
Execution
Time
Priority
!1
!2
!3
100
200
300
25
50
100
High
Medium
Low
Blocking Deadline
Delays
30+50
0
0
100
200
300
Carnegie Mellon University
Software Engineering Institute
UB Test for Example
Recall UB test with blocking:
C j Ci Bi 1
f i = + ------ + ----- + ----- + ----- + C k
T
T i T i T i k 7 H1
j 7 Hn j
f1
C1 B1
25
80
= ------ + ------ = --------- + --------- = 1.05 8 1.00
100 100
T1 T1
f2
C1 C2
25
50
= ------ + ------ = --------- + --------- = 0.50 * U $ 2 %
100 200
T1 T2
f3
C1 C2 C3
25
50 100
= ------ + ------ + ------ = --------- + --------- + --------- = 0.84 8 U $ 3 %
100 200 300
T1 T2 T3
RT test shows
Not schedulable
!3 is schedulable
11
Synchronization & Priority Inversion
Carnegie Mellon University
Software Engineering Institute
Synchronization Protocols
No preemption
Basic priority inheritance
Highest locker’s priority
Priority ceiling
Each protocol prevents unbounded priority inversion.
12
Synchronization & Priority Inversion
Carnegie Mellon University
Software Engineering Institute
Nonpreemption Protocol
!,:{...P(S1)...V(S1)...}
!5:{...P(S1)...V(S1)...}
Ready
Legend
S1 locked
9
!'(H)
Executing
Blocked
Ready
!,
Ready
!(
S1 locked
S1 unlocked
!5(L)
13
Synchronization & Priority Inversion
Time
B
Carnegie Mellon University
Software Engineering Institute
Basic Inheritance Protocol (BIP)
!,:{...P(S1)...V(S1)...}
!5:{...P(S1)...V(S1)...}
Legend
S1 locked
Executing
!'(H)
Blocked
S1 locked S1 unlocked
Attempts to lock S1
Ready
9
!,
Ready
!(
S1 locked
S1 unlocked
!5(L)
Time
14
Synchronization & Priority Inversion
B
Carnegie Mellon University
Software Engineering Institute
Highest Locker’s Priority Protocol
!,:{...P(S1)...V(S1)...}
!5:{...P(S1)...V(S1)...}
Legend
S1 locked
!'(H)
Executing
Blocked
Ready
!,
9
9
Ready
!(
S1 locked
S1 unlocked
!5(L)
Time
15
Synchronization & Priority Inversion
B
Carnegie Mellon University
Software Engineering Institute
Priority Ceiling Protocol (PCP)
!,:{...P(S1)...V(S1)...}
!5:{...P(S1)...V(S1)...}
Legend
S1 locked
Executing
!'(H)
Attempts to lock S1
Blocked
S1 locked S1 unlocked
Ready
!,
9
Ready
!(
S1 locked
S1 unlocked
!5(L)
Time
16
Synchronization & Priority Inversion
B
Carnegie Mellon University
Software Engineering Institute
Example Of Chained Blocking (BIP)
!1:{...P(S1)...P(S2)...V(S2)...V(S1)...}
Legend
!,:{...P(S1)...V(S1)...}
!(:{...P(S2)...V(S2)...}
S2 locked
Attempts to lock S2 (blocked)
Attempts to lock S1 (blocked)
!'(H)
S1 locked
9
S1 locked
Blocked
9
S1 unlocked
!,(M)
S2 locked
S2 unlocked
!((L)
0
1
2
3
4
5
6
7
8
9
10
11
Time
17
Synchronization & Priority Inversion
12
13
B
Carnegie Mellon University
Software Engineering Institute
Blocked At Most Once (PCP)
!1:{...P(S1)...P(S2)...V(S2)...V(S1)...}
Legend
!,:{...P(S1)...V(S1)...}
!(:{...P(S2)...V(S2)...}
S2 locked
S1 locked
S2 locked
S2 unlocked
S1 locked
Ceiling
S1 unlocked
Attempts to lock S1 (blocked)
!'(H)
C
S1 locked
Attempts to lock S1 (blocked)
S1 unlocked
!,(M)
S2 unlocked
S2 locked
!((L)
0
18
Synchronization & Priority Inversion
1
2
3
4
5
6
7
8
9
10
11
Time
12
13
C
Carnegie Mellon University
Software Engineering Institute
Deadlock: Using BIP
!1:{...P(S1)...P(S2)...V(S2)...V(S1)...}
Legend
!,:{...P(S2)...P(S1)...V(S1)...V(S2)...}
S1 locked
S2 locked
attempts to lock S2 (blocked)
Blocked
locks S1
!'(H)
B
Attempts to lock S1 (blocked)
S2 locked
!,(M)
0
1
2
3
4
5
6
7
8
9
10
11
Time
19
Synchronization & Priority Inversion
12
13
B
Carnegie Mellon University
Software Engineering Institute
Deadlock Avoidance: Using PCP
Legend
!1:{...P(S1)...P(S2)...V(S2)...V(S1)...}
S1 locked
!,:{...P(S2)...P(S1)...V(S1)...V(S2)...}
S2 locked
Ceiling
locks S2
attempts to lock S1 (blocked)
locks S1
!'(H)
C
locks S2
locks S1
unlocks S1
unlocks S2
!,(M)
0
1
2
3
4
5
6
7
8
9
10
11
Time
20
Synchronization & Priority Inversion
12
13
C
Carnegie Mellon University
Software Engineering Institute
Summary of Synchronization
Protocols
Protocol
Nonpreemptible
critical sections
Highest locker’s
priority
Basic inheritance
Priority ceiling
Bounded
Priority
Inversion
Blocked at
Most Once
Deadlock
Avoidance
Yes
Yes1
Yes1
Yes
Yes1
Yes1
Yes
Yes
No
Yes2
No
Yes
1
Only if tasks do not suspend within critical sections
2
PCP is not affected if tasks suspend within critical sections
21
Synchronization & Priority Inversion
& & &
Carnegie Mellon University
Software Engineering Institute
Sample Problem with
Synchronization
When basic priority inheritance protocol is used:
22
Synchronization & Priority Inversion
Task
Period
Execution
Time
Priority
!1
!2
!3
100
150
350
20
40
100
High
Medium
Low
Blocking Deadline
Delays
20+10
10
0
100
130
350
Carnegie Mellon University
Software Engineering Institute
UB Test for Sample Problem
This format is sometimes called a schedulability model
for the task set:
f1
C1 B1
20
30
= ------ + ------ = --------- + --------- = 0.500 * U $ 1 %
100 100
T1 T1
f2
C1 C2 B2
20
40
10
= ------ + ------ + ------ = --------- + --------- + --------- = 0.534 * 0.729
100 150 150
T1 T2 T2
U $ 2. .80 % = 0.729
f3
C1 C2 C3
20
40 100
= ------ + ------ + ------ = --------- + --------- + --------- = 0.753 * U $ 3 %
100 150 350
T1 T2 T3
23
Synchronization & Priority Inversion
Carnegie Mellon University
Software Engineering Institute
Rate Monotonic Analysis
Introduction
Periodic tasks
Extending basic theory
Synchronization and priority inversion
Aperiodic servers
Case study: BSY-1 Trainer
1
Aperiodic Servers
Carnegie Mellon University
Software Engineering Institute
Sample Problem: Aperiodics
Periodics
Servers
Emergency
100 msec
!1
50 msec
20 msec
Data Server
2 msec
150 msec
!2
20 msec
5 msec
Deadline 6 msec
after arrival
40 msec
Comm Server
350 msec
!3
Aperiodics
10 msec
10 msec
Routine
40 msec
2 msec
100 msec
Desired response
20 msec average
!2’s deadline is 20 msec before the end of each period.
2
Aperiodic Servers
Carnegie Mellon University
Software Engineering Institute
Concepts and Definitions
Aperiodic task: runs at unpredictable intervals
Aperiodic deadline:
• hard, minimum interarrival time
• soft, best average response time
3
Aperiodic Servers
Carnegie Mellon University
Software Engineering Institute
Scheduling Aperiodic Tasks
0
100
●●●
99
Polling
●●●
Average Response
Time = 50 units
Interrupt Handler
●●●
●●●
Average Response
Time = 1 unit
Aperiodic Server
●●●
●●●
Average Response
Time = 1 unit
Legend
Periodic Task
Polling Task
Aperiodic Server
Interrupt Handler
Aperiodic Request
4
Aperiodic Servers
Carnegie Mellon University
Software Engineering Institute
Aperiodic Servers
Can be compared to periodic tasks:
• fixed execution budget
• replenishment interval (period)
Priority adjusted to meet requirements
5
Aperiodic Servers
Carnegie Mellon University
Software Engineering Institute
Sporadic Server (SS)
Modeled as periodic tasks:
• fixed execution budget (C)
• replenishment interval (T)
Priority adjusted to meet requirements
Replenishment occurs one “period” after start of use.
5 Execution budget
5
5
100
5
6
Aperiodic Servers
200
5
100 ms
100 ms (SS period)
300
Carnegie Mellon University
Software Engineering Institute
Sample Problem: Aperiodics
The sample problem has the following requirements:
• emergency event:
- 5 msec of work
- arrives every 50 msec, worst-case
- hard deadline 6 msec after arrival
• routine event:
- 2 msec of work on average
- arrives every 40 msec on average
- desired average response of 20 msec after arrival
7
Aperiodic Servers
Carnegie Mellon University
Software Engineering Institute
Sample Problem: Sporadic Servers
Emergency server (ES); for minimum response:
• set execution budget to processing time: C = 5
• set replenishment interval to minimum interarrival
time: T = 50
Routine server (RS); for average response:
• set execution budget to processing time: C = 2
• use queueing theory to determine required
replenishment interval, T
Then assign priorities based on periods, Ti, of tasks.
8
Aperiodic Servers
Carnegie Mellon University
Software Engineering Institute
Routine Server Period
Using M/D/1 queueing approximation:
$ T R% 2
---------------I
W = -------------------------- + C R
T R4
3
2 / 1 – ------ 0
I
I = average interarrival time between events
W = average response time
CR = capacity of sporadic server = processing time
TR = required sporadic server replenishment period
9
Aperiodic Servers
Carnegie Mellon University
Software Engineering Institute
Routine Server Budget
Computing server replenishment interval:
T R = $ CR – W % +
T R = $ 2 – 20 % +
$ W – C R % $ W – C R + 2I %
$ 20 – 2 % $ 20 – 2 + 80 %
T R = 24
Note: For more details, see RMA handbook.
10
Aperiodic Servers
& & && &
Carnegie Mellon University
Software Engineering Institute
Sample Problem: Schedulability
Analysis (BIP)
The task set is now:
11
Aperiodic Servers
Task
Period
Execution
Time
Priority
!E
!R
!1
!2
!3
50
24
100
150
350
5
2
20
40
100
Very High
High
Medium
Low
Very Low
Blocking Deadline
Delays
0
0
20
10
0
6
24
100
150
350
&&& &&
Carnegie Mellon University
Software Engineering Institute
Sample Problem:
Schedulability Analysis
Using the RT test, worst-case response times are
• !E: 5 ms
• !R: 7 ms
• !1: 56 ms
• !2: 88 ms
• !3: 296 ms
All requirements for sample problem are satisfied.
12
Aperiodic Servers
Carnegie Mellon University
Software Engineering Institute
Rate Monotonic Analysis
Introduction
Periodic tasks
Extending basic theory
Synchronization and priority inversion
Aperiodic servers
Case study: BSY-1 Trainer
1
BSY-1 Case Study
Carnegie Mellon University
Software Engineering Institute
BSY-1 Trainer Case Study
This case study is interesting for several reasons:
• RMS is not used, yet the system is analyzable
using RMA
• “obvious” solutions would not have helped
• RMA correctly diagnosed the problem
Insights to be gained:
• devastating effects of nonpreemption
• how to apply RMA to a round-robin scheduler
• contrast conventional wisdom about interrupt
handlers with the results of an RMA
2
BSY-1 Case Study
Carnegie Mellon University
Software Engineering Institute
System Configuration
Mainframe Channels
MainFrame
PC-RT
PC-RT
PC-RT
NTDS Channels (1 to 6)
System Being Stimulated
BSY-1
3
BSY-1 Case Study
Carnegie Mellon University
Software Engineering Institute
Software Design
E1
E2
E3
E4
E5
E6
Mainframe
Application
Ada RTS
AIX
VRM
Mainframe Channel
NTDS Channels (5)
PC-RT
BSY-1
4
BSY-1 Case Study
Carnegie Mellon University
Software Engineering Institute
Scheduling Discipline
Wait for signal
Event Flag
●●●
✔
Pending Event
●●●
✔
●●●
●●●
✔
✔
5
BSY-1 Case Study
●●●
●●●
Carnegie Mellon University
Software Engineering Institute
Execution Sequence: Original Design
0
Interrupt
Application begins
Interrupt level
Application level
258
1
Interrupt
0
43
86
129
172
215
258
2
0
Missed deadline
129
3
Interrupt
6
BSY-1 Case Study
258
Carnegie Mellon University
Software Engineering Institute
Problem Analysis by Development
Team
During integration testing, the PC-RT could not keep up
with the mainframe computer.
The problem was perceived to be inadequate
throughput in the PC-RT.
Actions planned to solve the problem:
• move processing out of the application and into
VRM interrupt handlers
• improve the efficiency of AIX signals
• eliminate the use of Ada in favor of C
7
BSY-1 Case Study
Carnegie Mellon University
Software Engineering Institute
Data from Rate Monotonic
Investigation
Ci
Ca
C
T
(msec) (msec) (msec) (msec)
Event 1
Event 2
Event 3
Event 4
Event 5
Event 6
Total
2.0
7.4
6.0
21.5
5.7
2.8
0.5
8.5
0.6
26.7
23.4
1.0
2.5
15.9
6.6
48.2
29.1
3.8
43
74
129
258
1032
4128
U
0.059
0.215
0.052
0.187
0.029
0.001
0.543
Observe that total utilization is only 54%; the problem
cannot be insufficient throughput.
8
BSY-1 Case Study
Carnegie Mellon University
Software Engineering Institute
Analyzing Original Design
9
BSY-1 Case Study
Event
ID
Arrival
Period
Execution
Time
Priority
e1i
e2i
e3i
e4i
e5i
e6i
e1a
e2a
e3a
e4a
e5a
e6a
43
74
129
258
1032
4128
43
74
129
258
1032
4128
2.0
7.4
6.0
21.5
5.7
2.8
0.5
8.5
0.6
26.7
23.4
1.0
HW
HW
HW
HW
HW
HW
SW
SW
SW
SW
SW
SW
Blocking Deadline
Delays
0
0
0
0
0
0
0
0
0
0
0
0
n/a
n/a
n/a
n/a
n/a
n/a
43
74
129
258
1032
4128
Carnegie Mellon University
Software Engineering Institute
Schedulability Model: Original Design
e1a
10
BSY-1 Case Study
C 1i + C 2i + C 2a + C 3i + C 3a + C 4i + C 4a + C 5i + C 5a + C 6i + C 6a
C 1a
--------- + ---------------------------------------------------------------------------------------------------------------------------------------------------------------- # U(1)
T1
T 1a
e2a
C 2i + C 3i + C 3a + C 4i + C 4a + C 5i + C 5a + C 6i + C 6a
C 1i + C 1a
C 2a
----------------------- + --------------------------------------------------------------------------------------------------------------------------------------- # U(2)
-+
T1
T2
T2
e3a
C 3i + C 4i + C 4a + C 5i + C 5a + C 6i + C 6a
C 3a
C 1i + C 1a C 2i + C 2a
----------------------- + ----------------------- + --------- + --------------------------------------------------------------------------------------------------- # U(3)
T3
T1
T2
T3
e4a
C 4i + C 5i + C 5a + C 6i + C 6a
C 1i + C 1a C 2i + C 2a C 3i + C 3a
C 4a
------------------------------------------------------------------------------------------ + ----------------------- + ----------------------- + --------- +
# U(4)
T4
T1
T2
T3
T4
e5a
C 5i + C 6i + C 6a
C 1i + C 1a C 2i + C 2a C 3i + C 3a C 4i + C 4a
C 5a
----------------------- + ----------------------- + ----------------------- + ----------------------- + --------- + -------------------------------------- # U(5)
T5
T1
T2
T3
T4
T5
e6a
C 6i
C 1i + C 1a C 2i + C 2a C 3i + C 3a C 4i + C 4a C 5i + C 5a
C6
----------------------- + ----------------------- + ----------------------- + ----------------------- + ----------------------- + ------ + -------- # U(6)
T6
T1
T2
T3
T4
T5
T6
Carnegie Mellon University
Software Engineering Institute
Schedulability Test: Original Design
e1a
11
BSY-1 Case Study
2.0 + 7.4 + 8.5 + 6.0 + 0.6 + 21.5 + 26.7 + 5.7 + 23.4 + 2.8 + 1.0
0.5
------- + ----------------------------------------------------------------------------------------------------------------------------------------------------------- # U(1)
43
43
e2a
2.0 + 0.5
7.4 + 6.0 + 0.6 + 21.5 + 26.7 + 5.7 + 23.4 + 2.8 + 1.0
8.5
--------------------- + ------- + ------------------------------------------------------------------------------------------------------------------------------- # U(2)
43
74
74
e3a
6.0 + 21.5 + 26.7 + 5.7 + 23.4 + 2.8 + 1.0
2.0 + 0.5 7.4 + 8.5
0.6
--------------------- + --------------------- + --------- + --------------------------------------------------------------------------------------------------- # U(3)
129
43
74
129
e4a
21.5 + 5.7 + 23.4 + 2.8 + 1.0
26.7
2.0 + 0.5 7.4 + 8.5 6.0 + 0.6
--------------------- + --------------------- + --------------------- + ---------- + --------------------------------------------------------------------- # U(4)
258
258
43
74
129
e5a
5.7 + 2.8 + 1.0
23.4
2.0 + 0.5 7.4 + 8.5 6.0 + 0.6 21.5 + 26.7
--------------------- + --------------------- + --------------------- + --------------------------- + ------------ + ----------------------------------- # U(5)
1032
258
1032
43
74
129
e6a
2.8
1.0
2.0 + 0.5 7.4 + 8.5 6.0 + 0.6 21.5 + 26.7 5.7 + 23.4
--------------------- + --------------------- + --------------------- + --------------------------- + ------------------------ + ------------ + ------------ # U(6)
4128
1032
4128
43
74
129
258
Carnegie Mellon University
Software Engineering Institute
Utilization: Original Design
Event
1a
2a
3a
4a
5a
6a
Period Preempt
Preempt
Execute
(msec)
{Hn}
{H1}
43
74
129
258
1032
4128
0.000
0.059
0.274
0.326
0.513
0.542
0.012
0.115
0.005
0.104
0.023
0.001
2.456
1.286
0.676
0.211
0.010
0.001
Total
(fi)
2.468
1.460
0.955
0.641
0.546
0.544
Effective utilizations (fi) for events 4, 5, and 6 are all
under 69%. These events are schedulable.
The problem for events 1, 2, and 3 is excessive
H1 preemption.
12
BSY-1 Case Study
Carnegie Mellon University
Software Engineering Institute
Process Events in RM Order
U
5.9%
21.5%
5.2%
18.7%
2.9%
0.1%
Ci
2.0
7.4
6.0
21.5
5.7
2.8
Ca
0.5
8.5
0.6
26.7
23.4
1.0
T
43
74
129
258
1032
4128
E1
E2
E3
E4
E5
E6
Mainframe
Application
BSY-1
Ada RTS
AIX
VRM
Mainframe Channel
13
BSY-1 Case Study
PC-RT
NTDS Channels (5)
Carnegie Mellon University
Software Engineering Institute
Schedulability Model:
Process Events in RM Order
e1a
14
BSY-1 Case Study
max $ C 2a. C 3a. C 4a. C 5a. C 6a % + C 1i + C 2i + C 3i + C 4i + C 5i + C 6i
C 1a
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +
T1
T1
e2a
max $ C 3a. C 4a. C 5a. C 6a % + C 2i + C 3i + C 4i + C 5i + C 6i
C 1i + C 1a
C 2a
----------------------- + -------- + -----------------------------------------------------------------------------------------------------------------------------------------T1
T2
T2
e3a
max $ C 4a. C 5a. C 6a % + C 3i + C 4i + C 5i + C 6i
C 3a
C 1i + C 1a C 2i + C 2a
----------------------- + ----------------------- + --------- + --------------------------------------------------------------------------------------------------------------T3
T1
T2
T3
e4a
max $ C 5a. C 6a % + C 4i + C 5i + C 6i
C 1i + C 1a C 2i + C 2a C 3i + C 3a
C 4a
----------------------- + ----------------------- + ----------------------- + --------- + -----------------------------------------------------------------------------------T4
T1
T2
T3
T4
e5a
C 6a + C 5i + C 6i
C 1i + C 1a C 2i + C 2a C 3i + C 3a C 4i + C 4a
C 5a
----------------------- + ----------------------- + ----------------------- + ----------------------- + --------- + -------------------------------------T5
T1
T2
T3
T4
T5
e6a
C 6a C 6i
C 1i + C 1a C 2i + C 2a C 3i + C 3a C 4i + C 4a C 5i + C 5a
----------------------- + ----------------------- + ----------------------- + ----------------------- + ----------------------- + --------- + -------T1
T2
T3
T4
T5
T6 T6
Carnegie Mellon University
Software Engineering Institute
Schedulability Test:
Process Events in RM Order
e1a
15
BSY-1 Case Study
$ 26.7 % + 2.0 + 7.4 + 6.0 + 21.5 + 5.7 + 2.8
0.5
------- + ------------------------------------------------------------------------------------------------------43
43
e2a
2.5
$ 26.7 % + 7.4 + 6.0 + 21.5 + 5.7 + 2.8
8.5
------- + ------- + ----------------------------------------------------------------------------------------43
74
74
e3a
$ 26.7 % + 6.0 + 21.5 + 5.7 + 2.8
2.5 15.9
0.6
------- + ---------- + --------- + --------------------------------------------------------------------------129
74
129
43
e4a
$ 23.4 % + 21.5 + 5.7 + 2.8
2.5 15.9 6.6
26.7
------- + ---------- + --------- + ---------- + -------------------------------------------------------------258
43
74 129
258
e5a
1.0 + 5.7 + 2.8
23.4
2.5 15.9 6.6 48.2
------- + ---------- + --------- + ---------- + ------------ + ----------------------------------1032
43
74 129 258
1032
e6a
2.8
2.5 15.9 6.6 48.2 29.1
1.0
------- + ---------- + --------- + ---------- + ------------ + ------------ + -----------4128
43
74 129 258 1032
4128
Carnegie Mellon University
Software Engineering Institute
Utilization:
Process Events in RM Order
Event
1a
2a
3a
4a
5a
6a
16
BSY-1 Case Study
Period Preempt
Preempt
Execute
(msec)
{Hn}
{H1}
43
74
129
258
1032
4128
0.000
0.059
0.274
0.326
0.513
0.542
0.012
0.115
0.005
0.104
0.023
0.001
1.677
0.948
0.487
0.207
0.010
0.001
Total
(fi)
1.689
1.122
0.766
0.637
0.546
0.544
Previous
Total
2.468
1.460
0.955
0.641
0.546
0.544
Carnegie Mellon University
Software Engineering Institute
Increasing Preemptibility
Preemptible I/O
U
5.9%
Ci
2.0
Ca
T
Packetized Data Movement
21.5%
5.2%
18.7%
2.9%
0.1%
7.4 (1.5)
6.0
21.5
5.7
2.8
0.5
8.5 (1.7)
0.6
26.7 (4.5)
23.4 (3.9)
43
74
129
258
1032
4128
E5
E6
E1
E2
E3
E4
Mainframe
Application
1.0
BSY-1
Ada RTS
AIX
VRM
Mainframe Channel
17
BSY-1 Case Study
PC-RT
NTDS Channels (5)
Carnegie Mellon University
Software Engineering Institute
Schedulability Test: Preemptible I/O
and Packetized Data Movement
e1a
18
BSY-1 Case Study
$ 4.5 % + 2.0 + 1.5 + 6.0 + 21.5 + 5.7 + 2.8
0.5
------- + ---------------------------------------------------------------------------------------------------43
43
e2a
2.5
$ 4.5 % + 7.4 + 6.0 + 21.5 + 5.7 + 2.8
8.5
------- + ------- + -------------------------------------------------------------------------------------43
74
74
e3a
$ 4.5 % + 6.0 + 21.5 + 5.7 + 2.8
2.5 15.9
0.6
------- + ---------- + --------- + -----------------------------------------------------------------------129
74
129
43
e4a
$ 3.9 % + 21.5 + 5.7 + 2.8
2.5 15.9 6.6
26.7
------- + ---------- + --------- + ---------- + ----------------------------------------------------------258
43
74 129
258
e5a
1.0 + 5.7 + 2.8
23.4
2.5 15.9 6.6 48.2
------- + ---------- + --------- + ---------- + ------------ + ----------------------------------1032
43
74 129 258
1032
e6a
2.8
2.5 15.9 6.6 48.2 29.1
1.0
------- + ---------- + --------- + ---------- + ------------ + ------------ + -----------4128
43
74 129 258 1032
4128
Carnegie Mellon University
Software Engineering Institute
Utilization: Preemptible I/O and
Packetized Data Movement
Event
1a
2a
3a
4a
5a
6a
Period Preempt
Preempt
Execute
(msec)
{Hn}
{H1}
43
74
129
258
1032
4128
0.000
0.059
0.274
0.326
0.513
0.542
0.012
0.115
0.005
0.104
0.023
0.001
1.024
0.648
0.314
0.132
0.010
0.001
Total
(fi)
1.036
0.822
0.593
0.562
0.546
0.544
Previous
Total
1.689
1.122
0.766
0.637
0.546
0.544
According to the utilization bound test, all events now
are schedulable, except event 1.
19
BSY-1 Case Study
Carnegie Mellon University
Software Engineering Institute
Streamlined Interrupt Handler
U
5.9%
Ci
2.0
Ca
T
21.5%
5.2%
18.7%
2.9%
0.1%
7.4 (1.5)
6.0
6.5
5.7
2.8
0.5
8.5 (1.7)
0.6
41.7 (4.5)
23.4 (3.9)
43
74
129
258
1032
4128
E5
E6
E1
E2
E3
E4
Mainframe
Application
1.0
BSY-1
Ada RTS
AIX
VRM
Mainframe Channel
20
BSY-1 Case Study
PC-RT
NTDS Channels (5)
Carnegie Mellon University
Software Engineering Institute
Schedulability Test:
Streamlined Interrupt Handler
e1a
21
BSY-1 Case Study
$ 4.5 % + 2.0 + 1.5 + 6.0 + 6.5 + 5.7 + 2.8
0.5
------- + ------------------------------------------------------------------------------------------------43
43
e2a
2.5
$ 4.5 % + 7.4 + 6.0 + 6.5 + 5.7 + 2.8
8.5
------- + ------- + ----------------------------------------------------------------------------------43
74
74
e3a
$ 4.5 % + 6.0 + 6.5 + 5.7 + 2.8
2.5 15.9
0.6
------- + ---------- + --------- + --------------------------------------------------------------------129
74
129
43
e4a
$ 3.9 % + 6.5 + 5.7 + 2.8
2.5 15.9 6.6
41.7
------- + ---------- + --------- + ---------- + -------------------------------------------------------258
43
74 129
258
e5a
1.0 + 5.7 + 2.8
23.4
2.5 15.9 6.6 48.2
------- + ---------- + --------- + ---------- + ------------ + ----------------------------------1032
43
74 129 258
1032
e6a
2.8
2.5 15.9 6.6 48.2 29.1
1.0
------- + ---------- + --------- + ---------- + ------------ + ------------ + -----------4128
43
74 129 258 1032
4128
Carnegie Mellon University
Software Engineering Institute
Utilization:
Streamlined Interrupt Handler
Event
1a
2a
3a
4a
5a
6a
22
BSY-1 Case Study
Period Preempt
Preempt
Execute
(msec)
{Hn}
{H1}
43
74
129
258
1032
4128
0.000
0.059
0.274
0.326
0.513
0.542
0.012
0.115
0.005
0.162
0.023
0.001
0.675
0.445
0.198
0.074
0.010
0.001
Total
(fi)
0.687
0.619
0.477
0.562
0.546
0.544
Previous
Total
1.036
0.822
0.593
0.562
0.546
0.544
Carnegie Mellon University
Software Engineering Institute
Summary: BSY-1 Trainer Case Study
Recall original action plan:
• improve efficiency of AIX signals
• move processing from application to interrupts
• recode 17,000 lines of Ada to C
Final actions:
• increase preemption and improve AIX
• move processing from interrupts to application
• modify 300 lines of Ada code
• RMA took 3 people 3 weeks
23
BSY-1 Case Study