RTP

RTP
Real-Time Programmatuur
hoofdstuk 13:
scheduling
Yolande Berbers
Programmatuur voor real-time controle
slide 1
RTP


overzicht
inleiding tot scheduling
eenvoudig procesmodel
 cyclische uitvoeringsaanpak
 procesgebaseerde scheduling
 gebruik-gebaseerde tests voor scheduleer-baarheid
 analyse van de responstijd








slechtste geval uitvoeringstijd
sporadische en aperiodieke processen
deadline monotonic priority assignment (DMPA)
procesinteractie en blokkering
protocols met plafond op prioriteiten
een uitgebreider procesmodel
programmeren van prioriteit-gebaseerde systemen
andere schedulingsmethoden
Yolande Berbers
Programmatuur voor real-time controle
slide 2
RTP
(Non)-Preemptive Scheduling
chosen
New
Terminated
Ready
I/O or event
completion
Running
3
4
Waiting
2
I/O or
1 event
Scheduling
When?
Release CPU
Non-Preemptive:
(1) + (2)
Volontarily
Preemptive:
(1) + (2) + (3) + (4) Every Interrupt
Yolande Berbers
Programmatuur voor real-time controle
slide 3
RTP








Scheduling Algorithms
FCFS
SJF
Priority-Based
Round-Robin
Multi-Level Queue
Multi-Level Queue with Feedback
Multi-Processor
Real Time
Yolande Berbers
Programmatuur voor real-time controle
slide 4
RTP

inleiding
bij 5 verschillende onafhankelijke taken:
 120 mogelijke volgordes als niet onderbroken
 oneindig meer indien processen onderbroken kunnen worden

scheduling: bepaalt de volgorde van uitvoeren
 kan statisch gebeuren (volgorde ligt vast voor de uitvoering)
 kan dynamisch gebeuren (volgorde bepaald tijdens uitvoering)
 bij interactieve systemen: altijd dynamisch
 real-time systemen

meestal statisch, omdat taken en deadlines van te voren
bekend zijn (dit zullen we hier behandelen)

in zeer complexe systemen is dat dynamisch (als van te
voren niet alles gekend is)
Yolande Berbers
Programmatuur voor real-time controle
slide 5
RTP

eenvoudig procesmodel
karakteristieken van eenvoudig procesmodel
 vast aantal processen
 alle processen zijn periodiek, met gekende periodes
 de processen zijn volledig onafhankelijk van elkaar
 systeemoverhead wordt verwaarloosd
 alle processen hebben een deadline gelijk aan hun periode
 alle processen hebben een vaste, gekende slechtste-geval
uitvoeringstijd
Yolande Berbers
Programmatuur voor real-time controle
slide 6
RTP

eenvoudig procesmodel
cyclische uitvoerings-aanpak
 gegeven een tabel met periodes en uitvoeringstijd kun je een tabel
opstellen die bestaat uit procedure-oproepen
 omdat periodes niet gelijk zijn: meestal een major cycle (waar proces
met grootste periode éénmaal voorkomt) en een minor cycle (waar
proces met kortste periode telkens éénmaal voorkomt)
 voorbeeld:
proces
periode
uitvoeringstijd
A
25
10
B
25
8
C
50
5
D
50
4
E
100
2
tijd
A
Yolande Berbers
B
C
A
B
D E
A
B
C
Programmatuur voor real-time controle
A
B
D
slide 7
RTP

eenvoudig procesmodel
code hiervoor:
loop
Wait_For_Interrupt;
A;
B;
C;
Wait_For_Interrupt;
A;
B;
D;
Wait_For_Interrupt;
A;
B;
C;
Wait_For_Interrupt;
A;
B;
D;
end loop;
Yolande Berbers
E;
Programmatuur voor real-time controle
slide 8
RTP

eenvoudig procesmodel
karakteristieken van deze eenvoudige aanpak
 er bestaan geen echte processen tijdens uitvoering (at run-time)
 gewone procedures, dus delen deze allemaal één adresruimte
warbij procedures niet voor elkaar moeten beschermd worden
omdat er nooit kans is dat ze onderbroken worden
 alle periodes moeten een veelvoud zijn van de minor cycle

nadelen
 laatste karakteristiek: veelvouden van minor cycle
 sporadische processen hieraan toevoegen is heel moeilijk
 processen met een lange periode maakt het moeilijker
 grote processen moeten soms opgesplitst worden, in de praktijk
niet zo eenvoudig
 tabel opstellen is niet eenvoudig (NP-hard probleem)
Yolande Berbers
Programmatuur voor real-time controle
slide 9
RTP intermezzo: NP-harde problemen

NP-harde problemen: Niet-deterministisch Polynomisch probleem

voorbeeld: traveling salesman
 probleemstelling
handelsreiziger moet N steden aandoen met een beperkt budget
 vind een pad zodat de totale lengte binnen het budget past
 eigenschappen
 probleem wordt erg rekenintensief bij grote N
 berekenen van lengte bij gegeven pad is polynomisch
 maar kies een volgend beter pad is niet-deterministisch


toepassing
 alle beveiligingsalgoritmen zijn hierop gebaseerd


Yolande Berbers
men kiest N heel groot
het kost heel veel rekentijd om beveiligingsalgoritme te kraken
Programmatuur voor real-time controle
slide 10
RTP

procesgebaseerde scheduling
karakteristieken
 beschouwen echte processen, in een van volgende toestanden
klaar om uit te voeren (runnable of ready)
 geblokkeerd op tijdsgebeurtenis (bv voor periodieke proc.)
 geblokkeerd op een andere gebeurtenis (bv interrupt)
 elk proces heeft een prioriteit
 prioriteit is bepaald door temporele eisen, niet door belang
 pre-emptive: proces A voert uit; en proces B met hogere prio.
wordt runnable; dan wordt A gestopt ten voordele van B

Yolande Berbers
Programmatuur voor real-time controle
slide 11
RTP

scheduling aanpakken
3 grote aanpakken
 Fixed-Priority Scheduling (FPS)
meest gebruikte, grootste gedeelte van hoofdstuk
 ieder proces krijgt een statische prioriteit
 prio. hangt af van temporele eigenschappen, niet van belang
 Earliest Deadline First (EDF)
 volgend proces is proces met vroegste deadline
 dynamisch want deadlines worden at run-time berekent
 Value-Based Scheduling (VBS)
 als systeem overbelast is, adaptieve technieken
 gaan wij niet behandelen

Yolande Berbers
Programmatuur voor real-time controle
slide 12
RTP

RMPA (vorm van FPS)
Rate Monotonic Priority Assignment (RMPA)
 hoe korter de periode, hoe hoger de prioriteit
 optimaal (indien mogelijk, dan ook mogelijk met dit schema)

voorbeeld (let op: hoe hoger prioriteitswaarde, hoe groter prioriteit)
proces
A
B
C
D
E

periode
25
60
42
105
75
prioriteit
5
3
4
1
2
uitvoeringstijd speelt hier dus niet mee
Yolande Berbers
Programmatuur voor real-time controle
slide 13
RTP test van scheduleerbaarheid (FPS)

indien de processen voldoen aan de volgende formule dan zullen
al de processen hun deadline halen
1


 Ci 
    N  2 N  1
i 1 Ti 


N

C: slechtste-geval uitvoeringstijd
T: periode
de volgende tabel toont het processorgebruik bij lage N (gaat naar
69.3% bij grote N)
N
1
2
3
4
5
10
Yolande Berbers
% gebruik
100.0
82.8
78.0
75.7
74.3
71.8
Programmatuur voor real-time controle
slide 14
RTP


test van scheduleerbaarheid
gevolg: elke combinatie van processen die de processor
minder dan 69.3% gebruiken is altijd volgens de RMPA
methode scheduleer-baar
3 vb (tijd in een of andere eenheid, van geen belang)
 voorbeeld 1
periode uitvoeringstijd prioriteitprocessorgebruik
T1
50
12
1
0.24
T2
40
10
2
0.25
T3
30
10
3
0.33
 totaal gebruik: 0.82, is dus te hoog
 ga je de uitvoering na, dan zie je dat het niet gaat
 volgende slides: tijdslijn en Gantt chart
Yolande Berbers
Programmatuur voor real-time controle
slide 15
RTP
test van scheduleerbaarheid
tijdslijn
T1
missed
deadline
T2
T3
10
voorbeeld 1
T1
T2
T3
Yolande Berbers
20
30
40
50
periode uitvoeringstijd
prioriteit
processorgebruik
50
40
30
1
2
3
0.24
0.25
0.33
12
10
10
Programmatuur voor real-time controle
60
slide 16
RTP
test van scheduleerbaarheid
Gantt chart
T3
T2
10
voorbeeld 1
T1
T2
T3
Yolande Berbers
T1
20
T3
30
T2
40
50
periode uitvoeringstijd
prioriteit
processorgebruik
50
40
30
1
2
3
0.24
0.25
0.33
12
10
10
Programmatuur voor real-time controle
slide 17
RTP
test van scheduleerbaarheid
 voorbeeld 2
periode uitvoeringstijd
prioriteitprocessorgebruik
T1
80
32
1
0.400
T2
40
5
2
0.125
T3
16
4
3
0.250
 totaal gebruik: 0.775, lager dan maximaal, is dus haalbaar
 ga je de uitvoering na dan zie je dat het wel gaat
 je kunt hiervoor ook een tijdslijn en Gantt chart opstellen
Yolande Berbers
Programmatuur voor real-time controle
slide 18
RTP
test van scheduleerbaarheid
 voorbeeld 3
periode uitvoeringstijd
prioriteitprocessorgebruik
T1
80
40
1
0.50
T2
40
10
2
0.25
T3
20
5
3
0.25
 totaal gebruik: 100%, is dus hoger dan maximaal
 toch kan dit gescheduled worden
 de test is dus voldoende maar niet noodzakelijk
(als je aan de test voldoet mag je met een gerust hart slapen,
voldoe je niet dan kan het nog dat het werkt)
 volgende slide: tijdslijn
Yolande Berbers
Programmatuur voor real-time controle
slide 19
RTP
test van scheduleerbaarheid
T1
T2
T3
10
voorbeeld 3
T1
T2
T3
Yolande Berbers
20
30
40
50
60
70
periode uitvoeringstijd
prioriteit
processorgebruik
80
40
20
1
2
3
0.50
0.25
0.25
40
10
5
Programmatuur voor real-time controle
80
slide 20
RTP test van scheduleerbaarheid (EDF)

er bestaat ook een test voor EDF (eenvoudigere test)
1


 Ci 
    N1  2 N  1
i 1 Ti 


N

toch voordelen van FPS boven EDF
 FPS statisch, gemakkelijker te implementeren dan EDF
 gemakkelijker om processen zonder deadline toe te voegen
 andere factoren (buiten deadline) gemakkelijker in te brengen
 bij overbelasting
FPS voorspelbaarder: lage prio zullen deadline missen
 EDF kan dominoeffect hebben: alle deadlines gemist

Yolande Berbers
Programmatuur voor real-time controle
slide 21
RTP analyse van de responstijd (FPS)


nadeel van vorige methode: niet exact en niet algemeen
bruikbaar (alleen voor eenvoudig procesmodel)
analyse van de responstijd
 voor elk proces apart wordt slechtste-geval responstijd berekend
 voordeel v.d. methode: zowel voldoende als noodzakelijk voorwaarde

enkele afkortingen
 R: slechtste-geval responstijd
 I: interferentie door andere processen
 C: uitvoeringstijd
 T: periode


voor proces met hoogste prioriteit:
voor andere processen:
Yolande Berbers
Ri = Ci
Ri = Ci + Ii
Programmatuur voor real-time controle
slide 22
RTP


analyse van de responstijd
Ii hangt af van hoe vaak proces i gestopt wordt door
processen met een hogere prioriteit
aantal keren dat proces j (met hogere prioriteit dan i)
proces i zal onderbreken:
 Ri gedeeld door periode van j
 van deze breuk: gehele getal dat net groter is (plafond functie)


tijdsduur van onderbreking: dat resultaat maal Cj
en dit moet je berekenen voor alle processen met hogere
prio.
 Ri 
Ri  Ci    C j
j  i  Tj 
Yolande Berbers
Programmatuur voor real-time controle
slide 23
RTP
analyse van de responstijd
 Ri 
Ri  Ci    C j
j  i  Tj 



deze formule is exact
maar deze formule heeft Ri langs beide kanten en is
moeilijk op te lossen vanwege de plafondfunctie
is oplosbaar met een recurente relatie
win1
Yolande Berbers
 win 
 Ci    C j
j  i  Tj 
Programmatuur voor real-time controle
slide 24
RTP
analyse van de responstijd
win1



 win 
 Ci    C j
j  i  Tj 
de waarden van w stijgen monotoon
als w(n+1,i) = w(n,i) dan mogen we stoppen
als w groter wordt dan de periode en w stijgt nog steeds,
dan zullen we geen gepaste R vinden
Yolande Berbers
Programmatuur voor real-time controle
slide 25
RTP
analyse van de responstijd
voorbeeld 4
T1
T2
T3
periode uitvoeringstijd
prioriteit
7
12
20
3
2
1
3
3
5
R1  3
w20  3
w21
win1
 3
 3   3
 7
 win 
 Ci    C j
j  i  Tj 
w22  w21  6  R2
w30  5
Yolande Berbers
Programmatuur voor real-time controle
slide 26
RTP
analyse van de responstijd
w30  5
voorbeeld 4
periode uitvoeringstijd
T1 7
T2 12
T3 20
3
3
5
prioriteit
3
2
1
R3 = 20 = periode = deadline
R3 zal het dus net halen
Yolande Berbers
 5  5 
 5    3    3  11
 7 12
11  11
2
w3  5    3    3  14
 7  12
14 14
3
w3  5    3    3  17
 7  12
17 17
4
w3  5    3    3  20
 7  12
 20  20
5
w3  5    3    3  20
 7   12 
w31
Programmatuur voor real-time controle
slide 27
RTP
analyse van de responstijd
voorbeeld 4
T1
T2
T3
T1
2
Yolande Berbers
periode uitvoeringstijd
prioriteit
7
12
20
3
2
1
T2
4
3
3
5
T3
6
T1
8
T3
10
12
T2
14
T1
16
Programmatuur voor real-time controle
T2 T3
18
20
slide 28
RTP analyse van de responstijd (EDF)

analyse van de responstijd voor EDF
 kan maar is erg ingewikkeld
 wordt hier niet behandeld (ook niet in het boek)
Yolande Berbers
Programmatuur voor real-time controle
slide 29
RTP


slechtste-geval uitvoeringstijd
vorige methoden gebruikten slechtste-geval uitvoeringstijd
meestal niet gekend, en moet dus geschat worden
 via metingen
probleem: meten we wel het slechtste geval ?
 analytisch
 verdeel code in blokken zonder sprongen
 bereken voor elke blok de uitvoeringstijd (afhankelijk ook
van cache, pipeline, enz.)
 voor elke if of case neem je als schatting de langste kant
 voor elke lus neem je als schatting het max aantal keren
 nadelen: alle lussen moeten begrensd zijn, geen recursie,
geen virtueel geheugen (swapping !), problemen met
hedendaagse processoren

Yolande Berbers
Programmatuur voor real-time controle
slide 30
RTP


sporadische en aperiodieke processen
bedoeling is om in de vorige methoden de sporadische
en aperiodieke processen toe te voegen
voor aperiodieke processen
 periode: beschouw de minimum tijd tussen twee voorkomens
van zo een proces als de periode T
 deadline
 bij eenvoudig procesmodel: deadline = periode
 bij periodieke processen is meestal deadline << periode
 stopcriterium bij zoeken van gepaste R:
w(n+1, i) > D (i.p.v. T)
Yolande Berbers
Programmatuur voor real-time controle
slide 31
RTP

sporadische en aperiodieke processen
voor sporadische processen
 men werkt met gemiddelden en grootste aankomstfrequenties
 vaak is het slechtste geval (grootste aankomstfrequentie) veel
hoger dan het gemiddelde geval
 interrupts komen vaak in ‘burst’
 ‘een probleem komt nooit alleen’
 een probleem geeft vaak aanleiding tot extra code die
uitgevoerd moet worden, ook in de andere processen
 meestal hanteert men de volgende regels
 neem voor zachte real-time processen het gemiddelde
 neem voor harde real-time processen altijd slechtste geval
 processoren worden daarom vaak ondergebruikt het grootste
gedeelte van de tijd
Yolande Berbers
Programmatuur voor real-time controle
slide 32
RTP

sporadische en aperiodieke processen
implementatie met server bij FPS
 Deferrable Server (DF) of Sporadic Server (SS)
kleine varianten van hetzelfde
 bepaal 1 proces (een server) die de capaciteit gebruikt die
overblijft (na responstime analyse kan dit berekent worden)
 schedule dit als een soort periodische taak
 tijdens zijn tijdslot voert deze aperiodieke processen uit


implementatie met server bij EDF
 analoge methode
 tijdens run-time wordt de tijd die vrij is gealloceerd aan server
Yolande Berbers
Programmatuur voor real-time controle
slide 33
deadline monotonic priority
assignment
RTP

bij eenvoudig procesmodel
 D = T (deadline = periode)
 Rate Monotonic Priority Assignment (RMPA) is optimaal

voor model waarbij D < T
 Deadline Monotonic Priority Ordering (DMPO) is optimaal
 als Di < Dj dan moet Pi > Pj
 bewijs in 13.8.1
vb 5
periode
T
T1
T2
T3
T4
Yolande Berbers
20
15
10
20
deadline
D
5
7
10
20
uitvoeringst.
C
3
3
4
3
prioriteit responstijd
P
R
4
3
2
1
Programmatuur voor real-time controle
3
6
10
20
slide 34
RTP

procesinteractie en blokkering
eenvoudig proces model
 veronderstelt onafhankelijke processen
 irrealistisch (zie hoofdstukken 7-11)

processen moeten soms wachten op een ander proces
 dit ander proces kan een lagere prioriteit hebben
 dit leidt tot prioriteitsinversie
 voorbeeld van problemen waartoe dit kan leiden: volgende slide






Yolande Berbers
4 periodieke processen L1, L2, L3, L4
L4 heeft hoogste prioriteit, L1 laagste
L4 en L1 delen kritische sectie, beschermd door semafoor Q
L4 en L3 delen kritische sectie, beschermd door semafoor V
E staat voor uitvoering tijdens een tijdseenheid
Q en V staan voor uitvoering terwijl men Q of V vasthoudt
Programmatuur voor real-time controle
slide 35
RTP
procesinteractie en blokkering
uitvoerend Q
voorbeeld
L4
L3
L2
L1
prioriteit
uitvoering
aankomsttijd
4
3
2
1
EEQVE
EVVE
EE
EQQQQE
uitvoerend V
4
2
2
0
geblokkeerd
pre-empted
uitvoerend (E)
L4
L3
L2
L1
2
Yolande Berbers
4
6
8
10
12
14
Programmatuur voor real-time controle
16
18
slide 36
RTP

procesinteractie en blokkering
probleem van prioriteitsinversie
 een hoog-prioriteitsproces p is geblokkeerd op een hulpmiddel
dat vast wordt gehouden door een proces q met lagere prioriteit
 proces q met lagere prioriteit moet zelf wachten met uitvoeren
omdat processen met tussenliggende prioriteit tussen komen

mogelijke oplossing: erven van prioriteit
 prioriteit van proces is niet meer statisch (ligt niet meer vast)
 als proces p wacht op een hulpmiddel dat proces q vast heeft,
en proces q heeft een lagere prioriteit dan p,
dan erft q de prioriteit van p (totdat q het hulpmiddel vrijgeeft)
 erven van prioriteit op ons voorbeeld in volgende slide

tot nu toe: fixed priority assignment, nu gedeeltelijk
dynamic priority assignment
Yolande Berbers
Programmatuur voor real-time controle
slide 37
RTP
procesinteractie en blokkering
uitvoerend Q
voorbeeld
L4
L3
L2
L1
prioriteit
uitvoering
aankomsttijd
4
3
2
1
EEQVE
EVVE
EE
EQQQQE
uitvoerend V
4
2
2
0
geblokkeerd
pre-empted
uitvoerend (E)
L4
L3
L2
L1
2
Yolande Berbers
4
6
8
10
12
14
Programmatuur voor real-time controle
16
18
slide 38
RTP

procesinteractie en blokkering
problemen met erven van prioriteit
 meestal niet geweten welk proces het hulpmiddel zal vrijgeven
zeker niet met semaforen en wait-signal primitieven
 bij boodschappen systemen wel bij directe symmetrische
naamgeving (maar dit wordt weinig gebruikt)


berekening van tijd die men kan blokkeren (B)
 proces p met K kritische secties kan maximaal K keer blokkeren
 als het aantal processen (n) met lagere prioriteit dan p kleiner is
dan K (dus n < K) dan is dit nog lager
K
Bi   usage(k , i )CS (k )
k 1
Yolande Berbers
- usage(k,i) is 0 of 1 afhankelijk
of proces i kritische sectie k gebruikt
- CS(k) is kost van kritische sectie k
Programmatuur voor real-time controle
slide 39
RTP

procesinteractie en blokkering
formule voor de responstijd
 kan nu aangepast worden: R = C + B + I
 wordt wel pessimistisch want het is niet zeker dat het proces B
tijd zal blokkeren
 de formule is nu voldoende maar niet noodzakelijk
 Ri 
Ri  Ci  Bi    C j
ji Tj 
win 1
Yolande Berbers
 win 
 Ci  Bi    C j
ji Tj 
Programmatuur voor real-time controle
slide 40
RTP protocols met plafond op prioriteiten

twee varianten
 original ceiling priority protocol (OCPP)
 immediate ceiling priority protocol (ICPP)

eigenschappen
 een proces met hoge prioriteit wordt maar 1 maal geblokkeerd
door een proces met lagere prioriteit
 deadlocks worden vermeden
 transient blokkeren wordt vermeden
 wederzijdse uitsluiting wordt door het protocol bewerkstelligd
 kern van de methode: als proces p1 een hulpmiddel vast heeft,
en dit zou kunnen leiden tot het blokkeren van een proces p2
met hogere prioriteit, dan mag geen enkel ander hulpmiddel dat
p2 zou kunnen blokkeren toegekend worden, behalve aan p1
Yolande Berbers
Programmatuur voor real-time controle
slide 41
RTP protocols met plafond op prioriteiten

original ceiling priority protocol
 elk proces krijgt een statische prioriteit
bv door DMPO
 elk hulpmiddel heeft een statische plafond-prioriteit
 dit is de maximale prioriteit van de processen die het
gebruiken
 een proces heeft een dynamische prioriteit
 max (eigen statische prioriteit, ge-erfde prioriteit door
blokkering)
 een proces kan enkel een hulpmiddel vast krijgen
 als dyn. prio. > plafond huidige toegekende hulpmiddelen in
het systeem, zonder rekening te houden met de eigen
hulpmiddelen

Yolande Berbers
Programmatuur voor real-time controle
slide 42
RTP protocols met plafond op prioriteiten

effect van dit protocol
 het eerste hulpmiddel kan altijd toegekend worden
 een tweede krijgt men pas als er geen ander hoger-
prioriteitsproces is dat beide nodig heeft

voordeel
 een proces kan slecht éénmaal per activatie geblokkeerd
worden door een proces met lagere prioriteit

kost hiervan
 meer processen zullen geblokkeerd geraken
Yolande Berbers
Programmatuur voor real-time controle
slide 43
RTP protocols met plafond op prioriteiten
uitvoerend Q
voorbeeld
L4
L3
L2
L1
prioriteit
uitvoering
aankomsttijd
4
3
2
1
EEQVE
EVVE
EE
EQQQQE
uitvoerend V
4
2
2
0
geblokkeerd
pre-empted
uitvoerend (E)
L4
L3
L2
L1
2
Yolande Berbers
4
6
8
10
12
14
Programmatuur voor real-time controle
16
18
slide 44
RTP protocols met plafond op prioriteiten

immediate ceiling priority protocol
de prioriteit van een proces stijgt van zodra het een
hulpmiddel toegekend krijgt
 i.p.v. enkel wanneer het proces een ander proces van
hogere prioriteit blokkeert
 elk proces krijgt een statische prioriteit
 bv door DMPO
 elk hulpmiddel heeft een statische plafond-prioriteit
 dit is de maximale prioriteit van de processen die het
gebruiken
 een proces heeft een dynamische prioriteit
 max (eigen statische prioriteit, de plafond-prioriteit van de
hulpmiddelen die het vast heeft)

Yolande Berbers
Programmatuur voor real-time controle
slide 45
RTP protocols met plafond op prioriteiten

gevolg van dit protocol
 een proces zal enkel blokkeren bij het begin van zijn uitvoering
 eenmaal dat het proces uitvoert zullen al de hulpmiddelen die
het gebruikt vrij zijn
 als dat niet zo zou zijn, dan zou er een proces zijn met gelijke of
hogere prioriteit die aan het uitvoeren is

voordelen
 deadlocks kunnen niet meer voorkomen (omdat alle
hulpmiddelen vrij zijn als een proces uitvoering mag beginnen)
Yolande Berbers
Programmatuur voor real-time controle
slide 46
RTP protocols met plafond op prioriteiten
uitvoerend Q
voorbeeld
L4
L3
L2
L1
prioriteit
uitvoering
aankomsttijd
4
3
2
1
EEQVE
EVVE
EE
EQQQQE
uitvoerend V
4
2
2
0
geblokkeerd
pre-empted
uitvoerend (E)
L4
L3
L2
L1
2
Yolande Berbers
4
6
8
10
12
14
Programmatuur voor real-time controle
16
18
slide 47
RTP protocols met plafond op prioriteiten

verschil tussen OCPP en ICPP
 ICPP is gemakkelijk te implementeren omdat geen
blokkeringsrelaties gebruikt worden
 ICPP leidt tot minder proceswisselingen omdat er geblokkeerd
wordt voor de uitvoering
 ICPP vraagt meer veranderingen van prioriteiten omdat dit
gebeurt bij elke toekenning van een hulpmiddel; OCPP
verandert alleen de prioriteit als er een blokkering is
Yolande Berbers
Programmatuur voor real-time controle
slide 48
RTP andere algoritmen en uitbreidingen

cooperative scheduling
 geen pre-emption
 processen bepalen zelf wanneer ze de processor willen afstaan
deze de-scheduling primitieven moeten goed geplaatst
worden in programma
 processen zijn dus cooperatief
 eigenschappen
 als critische sectie binnen een niet-onderbroken blok valt:
wederzijdse uitsluiting is gegarandeerd
 verhoogt de scheduleerbaarheid
 kan leiden tot kleinere waarden van C: minder
pessimistische voorspelling van uitvoeringstijd, nut van
cache en pipeline kan ingecalculeerd worden

Yolande Berbers
Programmatuur voor real-time controle
slide 49
RTP andere algoritmen en uitbreidingen

release jitter
 variatie in het starten van een proces
 kan voorkomen
indien start afhangt van periodisch proces op andere knoop
 indien granulariteit van klok grover is dan granulariteit van
tijdsberekeningen
 geeft aanleiding tot aanpassing van de formules


willekeurige deadline
 tot nu toe: deadline < periode
 kan ook: deadline > periode
meerdere voorkomens van zelfde proces gelijktijdig actief
 geeft aanleiding tot aanpassing van de formules

Yolande Berbers
Programmatuur voor real-time controle
slide 50
RTP

ondersteuning door talen en systemen
ondersteuning door talen
 klein
 Ada via Real-Time Systems Annex (dus niet in core van taal)

ondersteuning door systemen
 groot voor real-time besturingssystemen
 meeste normale systemen ondersteunen enkel scheduling
gebaseerd op prioriteiten
 POSIX (zie volgende slides)
Yolande Berbers
Programmatuur voor real-time controle
slide 51
RTP

ondersteuning door talen en systemen
POSIX
ondersteunt scheduling gebaseerd op prioriteiten
 heeft opties om prioriteitserving en plafondprotocol te
gebruiken
 prioriteiten kunnen dynamisch aangepast worden


drie basisalgoritmen
 FIFO
een proces loopt totdat het eindigt of blokkeert
 wordt het onderbroken door een proces met hogere prioriteit
dan wordt het teruggeplaatst vooraan in rij van zijn prioriteit
 round-robin
 idem maar kan ook onderbreken als tijdskwantum verloopt;
dan wordt het teruggeplaatst achteraan in rij van zijn prioriteit
 ander door implementatie bepaald

Yolande Berbers
Programmatuur voor real-time controle
slide 52
RTP

ondersteuning door talen en systemen
POSIX
 ondersteuning voor scheduling op basis van processen of van
threads
 voor threads
 system contention: alle threads staan in competitie
 process contention: de threads van één proces staan in
competitie met elkaar
 ondersteuning voor het associeren van een ervingsprotocol of
ICPP met een semafoor (mutex)
 wachtlijsten met boodschappen zijn geordend volgens prioriteit
 prio. threads kan dynamisch opgevraagd en veranderd worden
 threads kunnen opgeven of hun attributen ivm scheduling
geërfd moeten worden door de threads die zij creëren
Yolande Berbers
Programmatuur voor real-time controle
slide 53
RTP

dynamisch schedulen
earliest deadline
 kies altijd het proces waarvan de deadline het eerste afloopt

least slack time
 kies altijd het proces dat de minste ‘vrije tijd’ over heeft

voordelen van beide
als scheduleerbaar en geen afhankelijkheden tussen
processen, dan werkt dit
 werkt ook goed met vele aperiodische processen


nadelen van beide



Yolande Berbers
moet alle deadlines (of rest uitvoeringstijd) dynamisch kennen
als het misloopt (deadlines worden gemist) gebeurt dit op een
onvoorspelbare manier
wordt heel ingewikkeld met afhankelijkheden tussen processen
Programmatuur voor real-time controle
slide 54
RTP
System Classification
fast & simple slow & complex
RTOS
RTOS
Electronic
Hardware
1 ns
Processor
RTOS
1 program multitasking
1 s
1 ms
OS
multiprocess
1s
Mechanics
10 s
100 s
Manual
1000
s
deadline
Yolande Berbers
Programmatuur voor real-time controle
slide 55