Dagsplan Dagens sidesprang: Cliprep Kap. 13 (Mesteparten) oversikt kommer på senere foiler. - Tinyclip eksempel This is normal text outside of all stubs and will be thrown away. /*** #File "test.txt" ***/ This will be the first line of the generated file test.txt /*** Slot 1 ***/ This is the last line of the file. /*** End of File ***/ OK lets define some stubs going into slot 1 /*** Slot 1 ***/ Text from first stub with name "Slot 1" /*** End of Slot 1 ***/ /*** Slot 1 ***/ Text from second stub with name "Slot 1" /*** End of Slot 1 ***/ Resultat: test.txt --- This will be the first line of the generated file test.txt Text from first stub with name "Slot 1" Text from second stub with name "Slot 1" This is the last line of the file. --- Motivasjon for makroer /*** #file alarm.h ***/ #ifndef CALARM_H #define CALARM_H /*** CAlarm declarations ***/ class CAlarm: public CObject { public: /*** CAlarm public properties ***/ protected: /*** CAlarm protected properties ***/ private: /*** CAlarm private properties ***/ }; /*** CAlarm post-class declarations ***/ #endif /*** End of File ***/ /*** #file alarm.cc ***/ #include alarm.h /*** CAlarm implementation ***/ /*** End of File ***/
Løsning I %DefMacro(Class,class,baseClass,%{ class %class %If(%baseClass,: public %baseclass,){ public: /*** %class public properties ***/ protected: /*** %class protected properties ***/ private: /*** %class private properties ***/ }; Løsning II %DefMacro(DefineClass,file,class,baseClass,%a{ /*** #file "%file.h" ***/ #ifndef INCLUDE_%file #define INCLUDE_%file /*** %class declarations ***/ %Class(%class,%baseClass) /*** %class post-class declarations ***/ #endif /*** End of File ***/ /*** #file "%file.cc" ***/ #include "%file.h" /*** %class implementation ***/ /*** End of File ***/ %a}) Kallet %DefineClass(alarm,CAlarm,CObject) kan nå erstatte hele koden i motivasjonsfoilen Kap 13: Scheduling Spørsmål 1: Gitt prosesser, release times & deadlines; Lar dette seg gjøre? Spørsmål 2: Hvordan? - Hvilke algoritmer kan scheduleren bruke? Noe akademisk vinkling... (Rikelig CPU-kraft setter spørsmålene ut av spill) Men; tuning av klokkefrekvens bringer dem på bane igjen! (Dette er imidlertid ikke diskutert i boken...) Kap 13: Initielle antagelser (p466): 1) Fixed set of processes 2) All processes are periodic 3) No interaction 4) No overheads scheduler & process switches take no time. 5) A process' deadline is equal to its period. 6) All processes have fixed worst-case execution times. (i.e. we know it!)
Sitater å diskutere p 465: If the program is correct then its functional outputs will be the same regardless of... [scheduling] p 466: Most attention will be given to preemptive, priority-based schemes. p469: In real-time systems, the 'priority' of a process is derived from its temporal requirements Oversikt over kap. - I 13.2: Cyclic executive (en deterministisk ikkepreemptive scheduler) stort sett en avvisning. 13.3: Process-based scheduling - resten av kapittelet, stort sett. Basic approaches: Fixed-Priority Scheduling (FPS) Static, kort periode -> høy prioritet (Rate monotonic priority assignment) Earliest Deadline First (EDF) Value-Based Scheduling (VBS) (Kap. 13.13) Oversikt over kap. - II 13.4: Utilization-based schedulability tests 13.5 & 6: Response time -based schedulability tests (...og vi er på 13.8 og forlater the simple model ) 13.8: Sporadic and aperiodic processes (antagelse 1 og 2) 13.9: Processes with shorter deadlines than periods (halve antagelse 5). 13.10: Process interactions and blocking (antagelse 3) (incl. 13.11 priority ceiling) Oversikt over kap. - III 13.12: An extendible process model (Forsøk på) Samler trådene (dvs. diskuterer de tingene som mangler.) 13.12.3 Arbitrary deadlines 13.12.4 Fault Tolerance 13.12.5 Introducing offsets 13.14: Programming priority-based systems
En del sidesprang: 13.7: Worst case execution time 13.12.1: cooperative scheduling 13.12.2: Release jitter 13.12.6: Priority Assignment 13.13 Dynamic systems and online analysis Nomenklatur B Den lengste tiden en prosess kan være blokkert C WCET; Worst-case execution time D Deadline: tiden fra arrival til deadline I Interference: Utsettelsen pga. høyereprioritetstråder J Jitter: Usikkerheten i arrival tiden N Antall prosesser i systemet P Prioritet av prosessen R worst-case Response time T (minimum) tid imellom arrivals U Utilization: C/T a-z - Prosessnavn Cyclic executive Cyclic executive ulemper while(true){ wait; a; b; wait; a; c; wait; a; b; wait; a; } Knølete konstruksjon og vedlikehold, tuning nødvendig Alle perioder må være multiplum av minor cycle (Ingen sporadiske prosesser, ikke rom for unntakshåndtering) Prosesser med lange perioder gir lange major cycles Prosesser med høyt CPU-behov må deles.
Utilization-based scheduling test for Fixed Priority Scheduling Fig. p 472 - Tilstrekkelig, men ikke nødvendig, betingelse Utilization-based scheduling test for Earliest Deadline first Ulemper med EDF (EDF er ikke nødvendigvis bedre enn FPS, selv om formelen her er enklere formelen for FPS er ikke nødvendig...) FPS gir en veldig enkel scheduler. Trivielt å ta med prosesser uten deadliner i FPS. I det hele tatt EDF er mindre fleksibelt ovenfor andre kriterier en deadlines generelt (... utvidbarhet når vi fjerner antagelsene...) EDF håndterer overload veldig dårlig (-> Valuebased scheduling)
Response time analysis for FPS Table 13.8 For hver prosess regn ut hvor lang tid det maksimum kan gå fra den starter til den avslutter. (Må ta hensyn til at høyere-prioritetstråder avbryter) Så kan dette sammenlignes med prosessenes deadliner... Gir nødvendig & tilstrekkelig krav. Response time analysis for EDF Øh, mye arbeide... Kan ikke bruke critical instant som worst case må se på hele hyper-perioden Sidesprang: Worst case execution time (WCET) Måling: Vet aldri om en har funnet wcet Kan ikke gjøres før en har prosessen ferdig Programendringer -> analysen feil. Kode analyse: Vanskelig å ta høyde for cache/pipelining etc. Kodestruktur; kan ikke vite utfallet av tester... -> krever annotations.
Sporadic & Aperiodic processes Kontekst: unntak, feil, skjeldne signaler utenifra. gir blaffen i arrival-times, men har krav til deadline.. Response-time analysen for FPS virker fortsatt, men... Hvilken prioritet bør prosessene ha? Må/bør skille imellom grader av viktighet for prosessene. Servere En server (en klasse av prosesser i scheduleren) får tildelt en (analyserbar) andel av CPU. Sporadiske prosesser får CPU bare fra serverens kvote. Endeløse variasjoner; Hvilken prioritet har serveren? Strategi for å greie deadlines EDF i sub-system? Ikke revolusjonært: D < T I stedet for rate monotonic, Deadline Monotonic Priority Ordering, DMPO Bevis på at: Hvis det eksisterer prioritetstilordning som holder, vil også DMPO holde. Mao. vi kan alltid ta utgangspunkt i DMPO. Process interactions and blocking Vi får problem med priority inversion Løsning 1: Priority inheritance Vanskelig å implementere Grei utvidelse av response time analysen, selv om resultatene nå er pessimistiske, siden noen blokkinger kanskje aldri skjer Løsning 2: Priority ceiling -> Egen foil
Figur: Priority inversion Figur: Priority inheritance Priority ceiling protocols To forskjellige implementasjoner er nevnt; original & immediate For begge: En høyprioritetsprosess kan blokkes maks en gang Vranglåser unngås! Transitiv blokking unngås (Eksklusiv tilgang til resurser håndteres av protokollen.) Priority ceiling protocols Mål (for begge) p490: The protocol ensures that if a resource is locked by process a, and could lead to the blocking of the higher priority process b, then no other resource that could lock b is allowed to be locked by any process other than a A process can therefore be delayed not only by attempting to lock a previously locked resource, but also when the lock could lead to multiple blocking on higher-priority processes
Original Priority ceiling protocol Figur: Priority ceiling I Alle prosesser har prioriteter, som vanlig Alle resurser har en prioritetsverdi svarende til den høyeste prosessen som bruker resursen En prosess får satt opp prioriteten hvis en høyereprioritetstråd prøver å reservere en allokert resurs. En prosess kan bare reservere en resurs dersom den har en prioritet som er høyere enn prioritetsverdien til alle resurser som er allokert til andre prosesser Immediate Priority ceiling protocol (POSIX: priority protect protocol. Java: Priority Ceiling Emulation ) Alle prosesser har prioriteter, som vanlig Alle resurser har en prioritetsverdi svarende til den høyeste prosessen som bruker resursen En prosess får satt opp prioriteten når den reserverer resursen Forskjeller: Samme worst-case oppførsel, men: ICCP enklere å implementere ICCP gir færre prosess-skifter OCCP skifter prioriteter på prosesser skjeldnere.
Figur: Priority ceiling II Blocking and EDF Priority inversion -> deadline inversion Noe mer komplisert siden deadlines er dynamisk, mens prioriteter er statiske Stack resource policy : Som ICCP, bare at: hver gang en prosess slippes løs, kalkuleres en preemption level for alle aktive prosesser, og: resursene får ceiling lik maks preemption level for de trådene som bruker den. Sammendrag: