Forlæsningsplan

1. Del 1: Introduktion, definition af sandtidssystemer og gennemgang af analyse og design metoder. Kort intro til AVR platform. Del 2: Scheduleringsprincipper: Statiske/dynamiske f.eks. round robin/dynamic priority. Scheduleringskriterier: Generelt og for enkelte scheduleringsprincipper. Del 3: Schedulerbarhedskriterier ved fixed priority schedulering. Del 4: Schedulerbarhedskriterier ved dynamic priority schedulering. Del 5: Aperiodiske tasks og lidt køteori. Forlæsningsplan

2. Fra task struktureringen haves tidskarakteristikker for følgende tasksæt {(1), .., (N)} ready times r(i,j) computation times c(i,j) starting times S(i,j) Completion times C(i,j) deadlines d(i,j) jobs J(i,j) index (i,j) referer til det j te job i den i te task, f.eks. (j) Naturen af de enkelt tasks kendes: periodisk (T(j)) eller aperiodisk (Tmin(j)) Tidsfunktionen R(t): Angiver den resterne CPU tid, som er reserveret til tasks og endnu ikke afviklet Reservationsfunktionen L(t): Angiver den totale mængde reserveret tid til et givent tidspunkt Scheduling: Resume

3. Er udnyttelsen under 100% (U<1) Gælder uanset afviklingsrækkefølge Er udnyttelsen over 100% (U>1) Første trin i en validering af om alle dead-lines i et system nåes Tidsfunktionen: Resume

4. Der behandles i dette kursus Fixed Priority skedulering, hvor Tidsenheder, ready og dead-line, er kun delvis kendte i forvejen Kun perioder og relative dead-lines er kendte i forvejen Theorem (Critical Instant) Et job J(i, j) fra task(i) vil aldrig blive senere færdig end i den situation hvor alle andre tasks er igangsætter deres jobs på nøjagtig samme tid r(i, j), således o(i) = 0 Kan simplificeres ved kun at betragte tasks med samme eller højere prioritet Kontrol af skedulerbarhed Hvis worst case er skedulerbar er alle andre scenarier det også Kontrol metode analog til den for Round-Robin Tænk! Er der sammenhæng mellem det theorem og det vi så sidste gang for Round-Robin? Er theoremet anvendeligt i praksis? Fixed Priority Scheduling o(1) T(1) o(2) T(2) o(3) T(3)

5. Uformelt bevis, hvor det antages at {(1), .., (N)} er sorteret i prioritets rækkefølge ved indekseringen Antag: At theoremet holder for k<i WLOG: o(k) = 0 for alle k<i, hvorefter J(i, 1) betragtes Observer: At completion tiden for alle højere prioritet jobs er uafhængige af frigivelses tiden for J(i, 1) Derfor: Jo tidligere J(i, 1) frigives jo længere skal den vente på completion Tænk! Er det bevis nok? Mindre uformelt bevis Antag: (m) ready til tiden t Observer: Hvis ingen højere prioritets interrupts er ready i perioden [t; t+c(m)] vil C(m) = c(m) Antag: At en højere prioritets task er ready til tiden t0 i perioden [t; t+c(m)], f.eks. (i) Observer: C(m) er mindst øget til c(m) + c(i), formentlig mere pga. kontekst skift og evt. flere ready tider for (i) inden c(m) er afviklet Derfor: Worst-case opstår når t0 er lig t (= flest mulige (i) ready tider inden c(m) er afviklet) QED: Efter gentagelse for alle højere prioritets tasks Beviser for Critical Instant theoremet

6. Af Critical Instant theoremet findes funktionen Li( t) (ikke at forveksle med den fra resumeet), som et udtryk for den tid der i en periode [0; t] er til overs fra højere prioritets tasks Completion tid for (i) må følge C(i, j) må således være det mindste t der opfylder Dette udtryk kan også omskrives til Tænk! Kan udtrykket løses analytisk? Kan udtrykket løses grafisk? Completion time analyse: Teorien

7. Samme eksempel som sidst, bare beregnet på en anden måde Task 1 er altid ok, hvis den har højeste prioritet Tænk! Er dette nemmere end den måde vi testede tasksættet på sidste gang? Er denne metode anvendelig i praksis? Krævet tid Krævet tid Completion time analyse: Eksempel Prioritet: (1, 3, 2) Prioritet: (1, 2, 3) RMA d(1) = T(1) = 4 og c(1) = 2 d(2) = T(2) = 12 og c(2) = 4 d(3) = T(3) = 64 og c(3) = 6 C(3) = 12 < d(3) = 64 C(2) = 20 > d(2) = 12 C(2) = 8 < d(2) 12 C(3) = 24 < d(3) = 64 Tid Tid

8. Theorem (DMA optimal prioritering) For et tasksæt {(1), .., (N)} med deadlines d(i) ≤ T(i), hvor d(i) ≤ d(i+1) vil Deadline Monotonic (DMA) prioritering (Laveste deadline = højeste prioritet) være optimal, i den forstand at hvis en anden prioriteringsfølge er skedulerbar er DMA det også d(i) = T(i) for alle i fører til DMA = RMA d(i) > T(i) for mindst et i fører IKKE til noget generelt resultat Tænk! Vil man så altid bruge DMA? Uformelt bevis, hvor det antages at {(1), .., (N)} er sorteret i prioritets rækkefølge og er skedulerbar Antag: At der for et k gælder at d(k) > d(k+1) Observer: At C(k) < C(k+1) ≤ d(k+1) < d(k) Byttes prioriteterne fåes C(k+1) < C(k) ≤ d(k+1) < d(k) Task i < k og i > k+1 er uberørt af ombytningen Derfor: Ombytning af prioriteter ved flytning af tasks med lavere relativ dead-line foran tasks med højere relativ dead-line bibeholder skedulerbarhed QED: Gentages til DMA prioritering er opnået Optimal prioritet tildeling

9. Udnyttelse Garantigrænse for skedulerbarhed med RMA i tasksæt hvor d(i) = T(i) angivet af Liu og Layland Går mod log(2) = 0,69 for store N Tænk! Hænger det sammen med de tommelfingerregler der en nævnt tidligere i kurset? Kan vi så ikke skedulere systemer hvis U > 0,69? Completion time analyse, i omskrevet form for non-preemptive systemer Tænk! Hænger det sammen med de eksempler vi så sidst? Hvad med virkeligheden er den også indstillet på disse beregninger? Udnyttelse og Non-preemptive systemer

10. Kontekst skift antages at tage en fast tid Tc I preemptive systemer skal der lægges 2Tc til alle c(i) værdier, en for preemption og et for genoptagelse af beregningen I non-preemptive systemer lægges der kun Tc til hver c(i) værdi Tænk! Hvad gør man normalt? Aktiv task Aktiv task Tid Tid Kontekst skift Tid

11. Generelt er alle RTOS API’er rimelig ens, lige bortset fra Metoderne hedder lidt forskelligt Der kan være forskellige håndtag til kontrol af scheduleringen Der kan være for få kommandoer Generelt kan man begrænse sig til at designe i forhold til et rimeligt subset af RTOS API metoder...... og glemme resten Tænk! Er det rimeligt i design-fase at se bort fra ekstra features i den aktuelle RTOS? Er der andre ting man skal være opmærksom på omkring RTOS APIet under et design? Eksempel på et RTOS API frame-work Uden for del 3 emnet: Lidt om RTOS API’er