Realtime System Fundamentals :
Scheduling and Priority-based
scheduling
Pag
e1
B. RAMAMURTHY
Amrita-UB-MSES-2013-7
5/11/2013
Realtime scheduling
Pag
e2
 We will realtime system scheduling as in:



Earliest deadline scheduling (EDS)
 Starting deadline
 Completion deadline
 Dynamic priority scheduling
Rate monotonic scheduling (RMS)
 Periodic tasks are prioritized by the frequency of repetition (high
priority to tasks with shorter periods)
 Preemptive scheduling
 Fixed priority scheduling
 Schedulability according to RMS
Σ(Ci/Ti) <= n(21/n-1)
Cyclic executives (pre-scheduled)
 Concepts of cycle, slot and frame
 Repeated execution
 times
Amrita-UB-MSES-2013-7
5/11/2013
Task State Diagram
Task admitted
New
Resources allocated
Blocked
Amrita-UB-MSES-2013-7
Ready
Waiting for event
Page
3
Run
5/11/2013
Deadline driven scheduling
Pag
e4
 Parameters: ready time, starting deadline,
completion deadline, processing time, resource
requirement, priority, preemptive or non-preemptive
Amrita-UB-MSES-2013-7
5/11/2013
Deadline Scheduling
Pag
e5














Process Arrival Time Execution Time Ending Deadline
A(1)
0
10
20
A(2)
20
10
40
A(3)
40
10
60
A(4)
60
10
80
A(5)
80
10
100
••••
••••
••••
B(1)
0
25
50
B(2)
50
25
100
••••
••••
••••
Amrita-UB-MSES-2013-7
5/11/2013
deadline
A1 B1 A2 B1 A3 B2 A4 B2 A5 B2
A1 A2 B1 A3 A4 A5, B2
(missed)
A1
(missed)
A2 A3 A4
(missed)
A5, B2
B1 A2 A3 B2 A5
A1 A2 B1 A3 A4 A5, B2
A1 B1 A2 B1 A3 B2 A4 B2 A5
Fixed-priority scheduling;
A has priority
Fixed-priority scheduling;
B has priority
Earliest-deadline scheduling
using completion deadlines
B1
Amrita-UB-MSES-2013-7
Page
6
5/11/2013
Aperiodic Task set
Pag
e7
Arrival Time Execution Time Starting Deadline
A
10
20
110
B
20
20
20
C
40
20
50
D
50
20
90
E
60
20
70
Use earliest deadline with unforced idle time
Amrita-UB-MSES-2013-7
5/11/2013
Rate-monotonic scheduling
Pag
e8
 First proposed by Liu.
 For RMS, the highest-priority task is the one with the
shortest period, the
 second highest-priority task is the one with the
second shortest period, and so on.
 Schedulability according to RMS
 Σ(Ci/Ti) <= n(21/n-1)
Amrita-UB-MSES-2013-7
5/11/2013
Resources & Critical Resources
Pag
e9
 Shared resources: need mutual exclusion
 Tasks cooperating to complete a job
 Tasks contending to access a resource
 Tasks synchronizing
 Critical resources and critical region
 A important synchronization and mutual
exclusion primitive / resource is “semaphore”
Amrita-UB-MSES-2013-7
5/11/2013
Critical sections and Semaphores
Pag
e 10
 When multiples tasks are executing there may be
sections where only one task could execute at a
given time: critical region or critical section
 There may be resources which can be accessed only
be one of the processes: critical resource
 Semaphores can be used to ensure mutual
exclusion to critical sections and critical resources
Amrita-UB-MSES-2013-7
5/11/2013
Semaphores
Pag
e 11
See semaphore.h of xinu
Amrita-UB-MSES-2013-7
5/11/2013
Semaphore: wait()
Pag
e 12







ppcb->sem = sem; /* record semaphore id in pcb */
enqueue(currpid, psem->queue);
resched();
/* place in wait queue and reschedule */
}
restore(ps);
/* restore interrupts
*/
return OK;
}
Amrita-UB-MSES-2013-7
5/11/2013
Semaphore: signal()
Pag
e 13
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
/*signal - signal a semaphore, releasing one waiting process, and block
* @param sem id of semaphore to signal
* @return OK on success, SYSERR on failure
*/
syscall signal(semaphore sem)
{
irqmask ps;
register struct sentry *psem;
ps = disable();
/* disable interrupts
*/
if ( isbadsem(sem) )
/* safety check
*/
{
restore(ps);
return SYSERR;
}
psem = &semtab[sem];
/* retrieve semaphore entry
*/
if ( (psem->count++) < 0 ) /* release one process from wait queue */
{ ready(dequeue(psem->queue), RESCHED_YES); }
restore(ps);
/* restore interrupts
*/
return OK;
}
Amrita-UB-MSES-2013-7
5/11/2013
Semaphore: usage
Pag
e 14
• Problem 1:
–
–
–
Create 3 tasks that each sleep for a random time and update a
counter.
Counter is the critical resources shared among the processes.
Only one task can update the counter at a time so that counter
value is correct.
• Problem 2:
–
Create 3 tasks; task 1 updates the counter by 1 and then signal
task 2 that updates the counter by 2 and then signals task 3 to
update the counter by 3.
Amrita-UB-MSES-2013-7
5/11/2013
Problem 1
Pag
e 15
#include <..>
//declare semaphore
semaphore mutex1 = newsem(1);
int counter = 0;
//declare functions: proc1,proc1, proc3
ready(create((void *)proc1, INITSTK, INITPRIO,
“PROC1",, 2, 0, NULL), RESCHED_NO);
ready(create((void *)proc2, INITSTK, INITPRIO,
“PROC2",, 2, 0, NULL), RESCHED_NO);
ready(create((void *)proc3, INITSTK, INITPRIO,
“PROC3",, 2, 0, NULL), RESCHED_NO);
Amrita-UB-MSES-2013-7
5/11/2013
Problem 1: multi-tasks
Pag
e 16
void proc1()
{ while (1) {
sleep (rand()%10);
wait(mutex1);
counter++;
signal(mutex1);
}}
void proc2()
{ while (1) {
sleep (rand()%10);
wait(mutex1);
counter++;
signal(mutex1);
}}
//similarly proc3
Amrita-UB-MSES-2013-7
5/11/2013
Problem 1
Pag
e 17
Task 1
Counter1
Task 2
Task 3
Amrita-UB-MSES-2013-7
5/11/2013
Problem 2
Pag
e 18
semaphore synch12 = newsem(0);
semaphore synch23 = newsem(0);
semaphore synch31 = newsem(0);
ready(create((void *)proc1, INITSTK, INITPRIO,
“PROC1",, 2, 0, NULL), RESCHED_NO);
ready(create((void *)proc2, INITSTK, INITPRIO,
“PROC2",, 2, 0, NULL), RESCHED_NO);
ready(create((void *)proc3, INITSTK, INITPRIO,
“PROC3",, 2, 0, NULL), RESCHED_NO);
signal(synch31);
Amrita-UB-MSES-2013-7
5/11/2013
Task flow
Pag
e 19
void proc1()
void proc2()
void proc3()
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
{
while (1) {
sleep (rand()%10);
wait(synch31);
counter++;
signal(synch12);
}}
Amrita-UB-MSES-2013-7
{
while (1) {
sleep (rand()%10);
wait(synch12);
counter++;
signal(synch23);
}}
{
while (1) {
sleep(rand()%10);
wait(synch23);
counter++;
signal(synch31); } }
5/11/2013
Priority Inversion
Pag
e 20
 When we allow concurrent task to execute and with
semaphore and mailboxes and other synchronization
primitives, it is possible that a low priority task may
come to block a high priority task. This situation is
known as priority inversion.
 What happened on Mars?
Amrita-UB-MSES-2013-7
5/11/2013
Priority inversion
(Priority: t1>t2>t3)
Pag
e 21
blocked
task1
task2
Critical
section
task3
0
1
Amrita-UB-MSES-2013-7
2
3
4
5
6
7
8
time
9
10
5/11/2013
Problem: Priority inversion
Solution1: Priority Inheritance
Pag
e 22
blocked
task1
Task 2 delayed
task2
Critical
section
task3
0
1
Amrita-UB-MSES-2013-7
2
Priority of t1
inherited
Priority reverted
To t3
3
4
5
6
7
8
time
9
10
5/11/2013
Solution2:Priority
Ceiling Protocol
Pag
e 23
Acquire S1
CS
Used
by
Priority
Ceiling
S1
t1,t2
P(t1)
S2
t1,t2,t3
P(t1)
S3
t3
P(t3)
Release S1
task1
Attempt to
Acquire S1
No way
task2
Acquire S1
Acquire S2
Release S2
Critical
section
task3
0
1
Amrita-UB-MSES-2013-7
2
Acquire S2
3
4
5
6
7
8
time
9
10
5/11/2013