Sunteți pe pagina 1din 35

PR OG R A M A R E A A PLIC A TIILOR IN TIM P R E A L

Curs 12 Planificarea in sisteme in timp-real (continuare)

Planificarea taskurilor in sisteme in timp-real:


Politicile de planificare pot fi de tip:

fair. Planifica in asa fel incat toate taskurile progreseaza mai mult sau mai putin uniform (in acelasi fel evenly).

exemple: executivul de tip ciclic, executiv ciclic de tip time-triggered, roundrobin, round-robin preemptiv (cu diviziunea timpului)

priority-driven (unfair policies). Anumite taskuri (cele cu prioritate mai mare) sunt planificate preferential fata de celelalte.

cand mai multe taskuri sunt gata de executie, selectia se va face in functie de prioritati in cazul unui planificator preeemptiv cu prioritati, taskul care se executa va fi scos din executie de un task cu prioritate mai mare care este gata de executie planificatoarele bazate pe prioritati sunt responsive atita timp cat prioritatea taskului activat de evenimentul exterior (incoming event) este mai mare decat cea a taskului care se executa in momentul aparitiei evenimentului. Din aceasta cauza, in astfel de sisteme intreruperile au cea mai mare prioritate. exemple: Rate Monotonic Scheduling (RMS), Deadline Monotonic Scheduling (DMS), Maximum Urgency First (MUF), Earliest Deadline First (EDF), Least Laxaty (LL)

Politici de planificare bazate pe prioritati (unfair):

Rate Monotonic Scheduling (RMS) Deadline Monotonic Scheduling (DMS) Earliest Deadline First (EDF) Least Laxity (LL) Maximum Urgency First (MUF)

Rate Monotonic Scheduling (RMS):

toate taskurile se presupun a fi periodice, cu deadline-ul la sfarsitul perioadei prioritatile se ataseaza in momentul proiectarii, astfel incat taskurile cu perioadele cele mai scurte au prioritatea cea mai mare. avantaj: stabil, optimal, robust. dezavantaj: unfair, poate sa nu corespunda sistemelor mai complexe.
T T

Timp C D=T
RUNNING

C D=T

C = timpul de executie al taskului T= perioada de executie a taskului D = deadline

Rate Monotonic Scheduling (RMS) - cont.:


OBSERVATIE: daca un task periodic este executat intotdeauna pina la finalizare (adica nu exista situatii in care o instanta a taskului nu se poate executa din lipsa de resurse), atunci utilizarea procesorului de catre acest task este specificata de o relatie de tipul
U= C T

CUM SETAM PRIORITATEA TASKURILOR: toate schemele de planificare pe baza de prioritati se bazeaza pe urgenta este posibil sa se pondereze pe baza importantei prin multiplicarea cu un factor de importanta, wj, setandu-se apoi prioritatea taskului ca fiind egala cu produsul dintre unweighted priority si factorul de importanta e.g. prioritatea taskului la planificarea RMS va fi setata la:
p j= wj Tj

unde pj este prioritatea taskului, wj este o masura a importantei finalizarii taskului (completion), iar Tj este perioada de executie a taskului

Rate Monotonic Scheduling (RMS) - cont.:

in cazul planificarii de tip RMS, taskul cu prioritatea cea mai mare este taskul cu cea mai mica perioada T, al doilea in ordinea prioritatii este cel cu a doua cea mai mica perioada, etc ... daca mai multe taskuri sunt gata de executie, va fi servit primul cel cu cea mai mica perioada, adica: P1 > P2 (prioritate) = T1 < T2 (perioada)

daca afisam grafic prioritatea unui task functie de frecventa sa de executie (rate) rezulta o functie monoton crescatoare (de aici numele rate monotonic scheduling)

Rate Monotonic Scheduling (RMS) - cont.:

Prioritate

Mare
Cea mare frecventa, cel mai prioritar task

Mica

Cea mai mica frecventa, cel mai putin prioritar task

Frecventa (HZ)

Observatie:

ca masura a eficientei (effectiveness) a unui algoritm cu planificare periodica trebuie specificat daca acesta garanteaza sau nu indeplinirea deadline-urilor hard. presupunem ca avem n taskuri, fiecare avand o perioada de executie fixa si un anumit timp de executie, pentru a fi posibil ca toate deadline-urile sa fie indeplinite, trebuie sa fie indeplinita urmatoarea inegalitate:
C1 C2 C ... n 1 T1 T2 Tn

adica suma indicilor de utilizare a procesorului pentru toate taskurile nu poate depasi valoarea 1 (utilizare totala a procesorului). aceasta ecuatie estimeaza o limita superioara a numarului de taskuri pe care algoritmul le poate planifica cu succes.

Deadline Monotonic Scheduling (DMS):

la fel ca si planificatorul RMS, cu exceptia faptului ca nu se presupune ca deadline-ul este la sfirsitul perioadei prioritatile sunt asociate in momentul proiectarii aplicatiei, pe baza lungimii (shortness) deadline-ului taskului avantaj: stabil, optimal, robust. dezavantaj: unfair.
T T

Timp C D<T
RUNNING

C D<T

C = timpul de executie al taskului T= perioada de executie a taskului D = deadline

Observatii "Fixed Priority Scheduling":

Bibliografie:

"Real Time Systems by Fixed Priority Scheduling", Ken Tindell, Hans Hansson, 1997, (Internet), capitolul 4, sectiunile 4.1, 4.2, 4.3, 4.4

Observatii "Fixed Priority Scheduling":

analysis of a given set of tasks with fixed priorities

analysis is an important part of any scheduling approach

we must know before the system runs if deadlines will be met

RMS Rate Monotonic Sheduling C. L. Liu, J. W. Layland, "Scheduling Algorithms for Multiprogramming in a Hard Real-ime Environment", JACM, Volume 20, Number 1, pages 46-61, 1973

Observatii "Fixed Priority Scheduling":

In fixed priority scheduling the dispatcher will make sure that at any time the highest priority runnable task is actually running. So if we have a task with a low priority running and a high priority task arrives i.e. there was some event that occurred and the dispatcher needs to kick o a task to deal with it, the low priority task will be suspended and the high priority task will start running i.e. the low priority task has been preempted. If while the high priority task is running a medium priority task arrives the dispatcher will leave it unprocessed and the high priority task will carry on running and at some later time nish its computation. Then the medium priority task starts executing to finish at some later time. Only when both tasks have completed can the low priority task resume its execution, the low priority task can then carry on executing until either more higher priority tasks arrive or it has finished its work.

Observatii "Fixed Priority Scheduling" - ipoteze:

the work of Liu and Layland mentioned above used the following model for xed priority scheduling:

IPOTEZA: all tasks have periods with deadlines equal to these periods; tasks are not allowed to be blocked or to suspend themselves. IPOTEZA SUPLIMENTARA: we need to say how the priorities are chosen: in their paper Liu and Layland coined the term rate monotonic for how priorities were chosen, i.e. priorities should be set monotonically with rate .i.e period a task with a shorter period should be assigned a higher priority; priorities are unique.

Observatii "Fixed Priority Scheduling":

Observatii "Fixed Priority Scheduling":

Observatii "Fixed Priority Scheduling" - discutie:

! the utilisation bound given by Liu and Layland represented analysis that was not exact some task sets could be rejected that are in reality schedulable

Observatii "Fixed Priority Scheduling" - exemplu:

the utilisation of this task set is 81.41% therefore, for the three tasks the utilisation bound calculated by the Liu and Layland equation is 77.98%, so the scheduling test would say "No this task set might miss deadlines"

Observatii "Fixed Priority Scheduling" - exemplu:

this figure presents an exact schedulability test suggested by Liu and Layland: if all tasks meet their deadlines at their most dificult invokation then they will always meet their deadlines

Observatii "Fixed Priority Scheduling" analiza exacta:

M Joseph and P Pandya, "Finding Response Times in a Real-Time System", The Computer Journal, Volume 20, Number 5, 1986

Earliest Deadline First (EDF):

prioritatile sunt asociate la run-time atunci cand taskurile sunt gata de executie, pe baza aproprierii (nearness) deadline-ului taskului (cu cat deadline-ul este mai aproape, cu atat prioritatea este mai mare). avantaj: optimal, robust, scales up better than RMS sau DMS. dezavantaj: unstable, unfair, lipsa suport din partea sistemului de operare in timp-real.

Inversiunea de prioritate:

sistemele de timp-real executa taskuri multiple trebuie sa coordoneze aceste taskuri si sa partajeze resurse, de aceea maniera in care aceste resurse sunt gestionate este foarte importanta, atat pentru functionarea corecta a aplicatiei, cat si pentru planificare problema principala o reprezinta protejarea resurselor fata de accesul concurent solutia uzuala - serializarea accesului la resurse si prevenirea accesului simultan de exemplu, accesul la resurse prin intermediul sectiunilor critice Aceasta solutie este utila atunci cand timpul de acces la resursa este foarte scurt relativ la deadline-uri si timpii necesari pentru finalizarea actiunii (action completion) in acest caz resursa este protejata cu un semafor (sau orice alt mecanism pentru excludere mutuala, de exemplu, mutex-uri) poate apare o situatie speciala, denumita unbounded priority inversion, adica deoarece detinea resursa, un task cu prioritate mai mica se executa, in timp ce un task cu prioritate mai mare, care a facut o cerere de alocare resursa mai tarziu, va fi blocat, asteptand eliberarea resursei de catre taskul cu prioritate mai mica

Exemplu - scenariu aparitie inversiune de prioritate:

consideram 4 taskuri care au urmatoarele prioritati: PHPT > PTask1 > PTask2 > PLPT

Folosim urmatoarele notatii:


a taskul este activ i taskul este inactiv b taskul este blocat

Prioritate

Resursa partajata

Resursa ocupata Resursa disponibila

Task HPT

B D E

Activ Inactiv Blocat

Activ Inactiv Blocat

Task 1

C
Task 2

Activ Inactiv Blocat

A
Task LPT

Activ Inactiv Blocat Timp

Exemplu - scenariu aparitie inversiune de prioritate:

A- Taskul LPT este READY, intra in RUN, si in timpul executiei sale acapareaza resursa partajata SR (shared resource). B - Taskul HPT este READY, dar are nevoie de resursa, si se blocheaza pentru a-i permite taskului 1 sa se termine (sau sa elibereze resursa). C - Taskul 2, care are prioritate mai mare decat LPT, este READY. Deoarece nu are nevoie de resursa, preempts taskul LPT. In acest moment, HPT e blocat de doua taskuri, taskul 2 si LPT). D - Taskul 1, care are prioritatea mai mare decat Task 2, este READY. Deoarece nu utilizeaza resursa, preempts Task 2. Taskul HPT e blocat acum de 3 taskuri. E - Taskul 1 se termina, si se reia taskul 2. F - Deadline-ul taskului HPT este pierdut, chiar daca a fost suficient de lung pentru a permite atat executia taskului HPT, cat si a taskului LPT (dar nu a fost suficient de lung pentru a permite ca toate taskurile sa se execute). Aici apare inversiunea de prioritate. G - Taskul 2 se termina, deci se va relua taskul LPT. H - Taskul LPT se termina si elibereaza resursa. Taskul HPT va avea acum acces la resursa.

Prioritate

Exemplu:

High Task C

Aici apare inversiunea de prioritate

Taskul C isi continua executia

Task B

Task A Low

se considera 3 taskuri si o resursa, X. Task A B C


lock(X)

unlock(X)

Prioritate mica - 10 medie - 15 mare - 20

taskul A foloseste resursa X, blocand-o (lock). taskul B scoate A din executie in mod preemptiv si incepe sa se execute un timp mai lung. taskul C scoate taskul B din executie in mod preemptiv si incearca sa acapareze resursa X (sa faca lock), dar nu poate, deoarece taskul A a preluat deja lock-ul resursei X. astfel, taskul C, cu prioritatea cea mai mare, nu poate progresa atata timp cat taskul A nu elibereaza resursa X, iar taskul A nu poate face acest lucru pana cand taskul B nu-si termina executia. Acest scenariu ii da efectiv taskului C aceeasi prioritate ca si taskului A

Inversiune de prioritate - OBSERVATII::

inversiunea de prioritate apare in cazul planificatoarelor cu prioritati fixe (din ce in ce mai rare), care planifica taskurile in functie de prioritatile specificate de programator, si care nu pot fi modificate inversiunea de prioritate este o situatie in care un task cu prioritate mai mare este planificat ca si cand ar avea o prioritate mai mica decat un task cu prioritate mai mica decat a lui. alternativa o constituie un planificator cu prioritati care pot fi modificate dinamic (dynamic-priority scheduler), in timpul executiei aplicatiei inversiunea de prioritate poate fi controlata de un programator experimentat, insa doar daca poate fi anticipata, fiind greu de detectat inversiunea de prioritate apare doar atunci cand o secventa particulara de evenimente face ca un task de prioritate redusa sa detina o resursa atunci cand un task de prioritate mai mare are nevoie de aceasta acest tip de situatie poate necesita pentru aparitie o combinatie improbabila de evenimente, nedetectate in perioada de testare a software-ului si care se poate manifesta intermitent in sistemul aflat in functiune

Tehnici de rezolvare a inversiunii de prioritate:

poarta denumirea de priority inversion avoidance protocols sunt protocoale standard in doua variante (a)priority inheritance protocol (b)priority ceiling emulation protocol

Protocolul cu mostenire de prioritate (priority inheritance protocol PIP):

daca un task care asteapta pe o anumita resursa are o prioritate mai mare decat cea a taskului care detine resursa, acest protocol va da taskului cu prioritatea mai mica prioritatea taskului cu prioritate mare care asteapta eliberarea resursei, pana cand taskul mai putin prioritar va elibera resursa. in exemplu, protocolul cu mostenire a prioritatii va da taskului A prioritatea taskului C, astfel incat taskul A va executa blocul de cod intre operatia de lock si cea de unlock, fara a mai trebui sa astepte taskul B sa se termine
Prioritate High Task C

PIP

Taskul C isi continua executia

Task B

Task A Low

lock(X)

unlock(X)

Protocolul cu mostenire de prioritate (priority inheritance protocol PIP):

probleme: implementarea este destul de complexa. Folosind PIP, un task altereaza temporar prioritatea unui alt task, atunci cand incearca sa acapareze o resursa acest lucru se poate intampla de mai multe ori, cand taskurile cu prioritate mare intra in coada de wait sistemul trebuie sa refaca prioritatile originale ale taskurilor cand acestea elibereza o resursa (fac unlock())

Priority Ceiling Emulation Protocol (PCEP):

mareste temporar prioritatea unui task care detine o resursa peste prioritatea celui mai prioritar task care ar putea incerca sa acapareze resursa. un task isi seteaza propria prioritate atunci cand recupereaza o resursa (un lock) si se reintoarce la prioritatea originala atunci cand elibereaza resursa sectiunea de cod in care este preluat lockul se executa indivizibil in raport cu alte taskuri care ar vrea sa acapareze resursa
Prioritate High Task C lock(X) Task B
Priority raised to ceiling
Taskul C isi continua executia

unlock(X)

Priority returned to normal

Task A Low lock(X) unlock(X)

Inversiunea de prioritate:

Bibliografie:

"Real Time Systems by Fixed Priority Scheduling", Ken Tindell, Hans Hansson, 1997, (Internet), capitolul 4, sectiunile 4.5, 4.6, 4.7

Alte probleme asociate concurentei deadlock si starvation:

resursele pe care procesele le pot utiliza in mod concurent, situatii in care acestea pot ajunge la blocaje de tip deadlock sau starvation, pot fi reutilizabile sau consumabile:

resurse reutilizabile. O resursa reutilizabila este acea resursa care poate fi utilizata la un moment dat de catre un proces si nu este distrusa de acesta (de exemplu, procesorul, canalele de I/O, memorie, structuri de date fisiere, baze de date, semafoare) resurse consumabile. O resursa consumabila este o resursa care poate fi creata (produsa) si distrusa (consumata). Atunci cand o astfel de resursa a fost acaparata de un proces, ea inceteaza sa mai existe (de exemplu, intreruperi, semnale, mesaje, datele din bufferele de I/O)

Deadlock:

deadlock-ul poate fi definit ca fiind o blocare permanenta a unei multimi de procese care fie sunt in competitie pentru resurse, fie comunica intre ele spre deosebire de alte probleme referitoare la managementul proceselor concurente, nu exista o solutie eficienta generala de rezolvare a unei situatii de deadlock exemplu aparitie deadlock daca primitiva receive() este cu blocare (de obicei aceasta este o eroare de programare, greu de detectat):
Task 1 Task 2 receive(Task1); send(task1, mesaj2);

receive(Task2); . send(Task2, mesaj1);

Deadlock:
In general, cauzele aparitiei deadlock-ului pot fi multiple: o excludere mutuala realizata incorect- doar un singur proces poate utiliza o anumita resursa la un moment dat; o operatie de tip hold and wait - un proces detine resursele alocate in timp ce asteapta primirea altor resurse; nu este posibila preemptiunea - resursele nu pot fi dealocate fortat de la procesul care le detine; asteptare circulara (engl. circular wait) - presupune existenta unui lant inchis de procese, astfel incat fiecare proces tine ocupata cel putin o resursa asteptata de urmatorul proces din lant.
Resursa A detinuta de Proces 2 Resursa B cere

cere Proces 1 detinuta de

Deadlock:

primele trei conditii sunt necesare, dar nu si suficiente pentru aparitia deadlock-ului. ce-a patra este o consecinta potentiala a primelor trei conditii (adica, daca una dintre primele trei conditii sunt indeplinite, poate apare o secventa de evenimente care pot conduce la o coada circulara fara rezolvare) astfel, cele patru conditii, considerate impreuna sunt conditiile necesare si suficiente pentru aparitia deadlock-ului. o coada circulara nerezolvata poarta denumirea de deadlock