Download - Curs cu pir despre un curs care este curs
I. Noţiuni introductive privind aplicaţiile
multi-tasking de timp real
� Sistem numeric:
= hardware (resurse) + sistem de operare + aplicaţie utilizator (rutine/metode)
� Sistem de timp real - un sistem care trebuie să răspundă unor restricţii de timp
(RT) prestabilite
RT – cheia funcţionalităţilor dorite
Ex: control proces, identificare online
Aplicatie de timp real ≠ Aplicaţie cu timp de execuţie mic
- [timp] contează momentele de timp la care rezultatele sunt obţinute!!
- [real] răspuns la evenimentele externe pe măsură ce acestea apar
Exemple
Control
Monitorizare + alerte/decizii
Sistem de timp real
o Hardware -ul asigura răspuns rapid la evenimente externe, sincronizare
temporală, siguranţă
o Aplicaţia dezvoltată multitasking [procese modulare, cu priorităţi
diferite] + ISRuri
o Sistemul de operare oferă anumite facilităţi suplimentare – accent pe
răspuns rapid la evenimente externe, partajare resurse, executie
multitasking (comutare de la un task la altul + planificare & alocare)
resurse
o active: procesoare – asigura execuţia instrucţiunilor
o pasive: periferice (DA, AD, PWM, numaratoare), linii de comunicatie,
locatii memorie (variabile)
+
procese care lupta pentru ocuparea resurselor (implementate de programator)
•
o Task = proces care implementeaza o anumita facilitate a aplicatiei
o ISR = proces prin care se raspunde unei cereri de intreruperi lansata de un
dispozitiv periferic
+
sistemul de operare de timp real – asigura servicii pentru execuţia proceselor şi
ocupare/eliberarea resurselor in sensul respectării restrictiilor de timp
← procesele trebuie să coopereze pentru a produce rezultate
← procesele lupta pentru ocuparea resurselor: algoritmi de planificare si
alocare
procesele ocupa pentru executie:
- o resursa activa (procesor, server) – cel putin
- eventual anumite resurse pasive (memorie, etc)
� O resursa poate fi ocupata de un singur proces la un
moment dat (acces exclusiv)
� Cedarea resursei unui alt proces mai prioritar:
o resurse active - prin preemtare (unui alt task) sau
intrerupere (unui ISR);
o resurse pasive: acces preemtiv
Proces – zona de memorie proprie pentru
- cod executat
- date folosite
+
- stare procesor (resursa activa): registri
Fir („thread” – engl.) – fara zona proprie de memorie
Procese create dinamic/static
Diferente principale sistem timp real – alte sisteme numerice
Sistem timp real
Alte sisteme numerice
Planificare Planificarea taskurilor in sensul
respectarii restrictiilor de timp
Folosirea corectă şi
eficientă a resurselor
Timp de răspuns Incalcarea unui deadline – rezultatul
nu este doar întârziat, ci şi greşit
→ timpii de răspuns să asigure
respectarea restricţiilor de timp
pentru cazul cel mai
nefavorabil
Timpi de raspuns cât mai
buni
Supraîncărcare Respectarea restricţiilor de timp
importante
Comportare acceptabilă
[The Concise Handbookof Real-Time Systems, www.timesys.com]
T2 T1 T1T2 T2 T2T3 T3
while(1){
if() operatii task 1
if(…) operatii task 2
etc
}
Motontasking
while(1){
}
Multitasking
ISR
Task1
ISR
Task2 Task3
Avantaje abordare multitasking:
- Extensie simpla – adaugare taskuri
- Prioritati diferite
- Temporizari & restrictii de timp mai
flexibil de gestionat, independent
pentru fiecare task
Executia multitasking solicită:
Task1
…………….
…………….
…………….
…………….
Task 2
……………
……………
……………
…………..
SOTR
Programator (+ servicii SOTR)
Continuarea executiei
procesului cu urmatoarea
instructiune + gestionare
corectă a stivei/memoriei
Logica nealterată,
consistenţa date,
sincronizare, etc.
SOTR asigură comutarea corectă de la un proces la
altul (comutarea contextelor)
Context task
= conţinut regiştri procesor + adresă de început task
+ stare task +adresa stivei iniţiale + var. specifice
ale SOTR
Orice proces trebuie executat
consistent, indiferent ce
comutări între procese au loc
Din perspectiva programarii: Multitasking + folosire ISR
Pot exista sectiuni critice:
� acces concurent la IO, variabile de memorie globale
� alte succesiuni de instructiuni ce trebuie nu trebuie fragmentate
Poate exista secvente reentrante – acelaşi cod executat pe instante diferite
Din perspectiva dezvoltarii unui RTOS: RTOS - mod privilegiat
Facilităţi uzuale oferite de un SOTR:
• asigură execuţie multitasking:
o creare-stergere taskuri
o gestionare taskuri pe stări multiple
o comutare între taskuri
o arbitrare taskuri
• comunicare între taskuri
• partajare resurse pasive
• monitorizare executie
+
• respectare restricţii de timp
arbitrare în sensul respectării RT – pe bază de priorităţi
Tipuri RTOS – in funcţie de facilitaţile oferite:
planificare („scheduling”) +
control execuţie („dispatcher”)
comunicare intertask
+ sincornizare
acces protejat la memorie, servicii I/0
fisiere, securitate, interfata utilizator
microkernel
kernel
executiv
Clasificare RTOS/ în funcţie de interfaţarea cu aplicaţia utilizator
- monolitic
o RTOS lucreaza in mod privilegiat, iar aplicatiile lucreaza in mod
utilizator folosind apeluri la RTOS bazate pe trap
o Executia aplicatiei in mod supervizor prin linkeditare cu RTOS
(apel sistem ≡ apel functie)
- stratificat
o RTOS organizate pe module organizate ierahic
� Permite update simplu a unui modul
� Scalabilitate, portabilitate crescute
- bazat pe OS servere
o Kernel minimal:
� asigura comunicare securizata si operatii sistem critce
(accesare registri IO)
� functii ale RTOS sunt mutate in procese de tip OS server ce
ruleaza in mod utilizator si comunica prin mesaje.
o modularitate, extensie fireasca catre sisteme distribuite
o eroare la un server SO nu devine fatala
• Probleme:
o Consum resurse pe comunicare
o Dificultati in gestionarea comunicarii
o Tratarea ISR - cereri transmise prin mesaje si
tratate in mod user prin „interrupt service
task” (implica comutari de context intre
taskuri)
Ocuparea resurselor active/pasive este tratată distinct de SOTR:
i). Ocuparea resurselor active (procesoare):
Caz multiprocesor – planificare si alocare >> procese concurente
CAND (planificare) şi UNDE (alocare) se execută taskurile (procesoarele
vor comunica prin mesaje sau zone partajate de memorie)
Caz nedetaliat în curs!!!!!!
Caz monoprocesor - planificare:
CAND se execută taskurile
o pentru taskuri exista un arbitru care decide ce task preia procesorul:
planificatorul (componenta a SOTR);
o pentru ISR arbitrul este de obicei un controller hard, nu o componenta a
SOTR.
ii). Ocuparea resurselor pasive:
Resurse pasive = zone de memorie, dispozitive periferice, etc
Resursele sunt partajabile intre procese!!!!
o Un proces care ocupa resursa trebuie să îşi poată finaliza în timp finit
operaţiile, fără a pierde consistenţa datelor
o Un proces mai puţin prioritar nu trebuie să întârzie un alt proces mai
prioritar la primirea resursei (inversare de prioritate)
o Procesele nu trebuie să se blocheze în aşteptarea resurselor („deadlock”)
Proces 1
..............
Setez mod de lucru 1
Folosesc resursa pe mod 1
........................
Proces 2
..............
Setez mod de lucru 2
Folosesc resursa pe mod 2
........................
I.1. Detalii despre ocuparea resurselor active in SOTR
I. 1. 1. Clasificare taskuri
1) după mod activare
o periodice, deterministe – activate cu regularitate
� la fiecare activare: citesc stare sistem, execută calcule, trimit comenzi
de afişare-modificare stare sistem
Ex: aviaţie - ajustarea poziţiei supapei rezervorului de combustibil în
funcţie de puterea solicitată; automobilism – verificare blocare roţi;
achiziţie date; control periodic; refresh DRAM.
o aperiodice – activate când anumite evenimente au loc
� pot fi critice (cu deadline ferm - sporadice) sau obişnuite (fără
deadline ferm - aperiodice)
Ex: reconfigurarea sistemului de control atunci când anumite anomalii sunt
detectate; operaţii de întreţinere; înregistrare de evenimente.
2) după importanţă
o critice – hard deadline - uzual : periodice
o esenţiale – deadline ferm, important
o neesenţiale – deadline-ul poate fi încălcat fără efecte imediate
(„software deadline”)
⇒ necesitate considerare priorităţi pentru taskuri
I. 1. 2. Starile posibile ale unui task
in asteptare
(“waiting”)
Se termina de
executat
in curs de executie
(“running”)
Evenimentul asteptat
a avut loc
pregatita pentru
executie (“ready”)
Cere asteptarea
unui eveniment
suspendata
activata
Primeste
procesorul
(“start)
Pierde
procesorul
(“preempt”)
Pot exista diferente intre SOTR cu privire la modul de trecere del a o stare la alta sau
denumirea stării
I. 1. 3. Moduri execuţie a taskurilor
o preemtiv
un proces poate ceda procesorul altui proces atunci cand planificatorul
decide acest lucru, fără a i se cere acordul:
in executie “ready”
T1
in executie
suspendat in executie
suspendat
activare T1 Terminare T1
T2
v
in executie “ready”
T1
in executie
suspendat in executie
suspendat
activare T1 Terminare T1
T2
v
o nepreemtiv
un proces nu cedează procesorul altui proces activ, fără acordul său
in executie
T1
suspendat
suspendat ready”
in executie
activare T1
Terminare T2
T2
v
>> pot fi admise moduri mixte: unele procese preemtive, altele nepreemtive
Un proces caracterizat in SOTR prin:
o ID
o Stare
o Resurse ocupate
- pentru control executie
1. 4. Planificator
Planificatorul („scheduler”) monitorizează coada de taskuri „ready” şi stabileşte ce
task trece executie.
Elemente ce definesc planificatorul:
o cand se activează planificatorul (când poate decide comutarea)
„clock driven” [periodic]
planificatorul se activează periodic (o perioadă = frame)
+ procesul in executie cere acces la planificator, se termina sau intra in
asteptare
„event driven” [bazat pe evenimente]
planificatorul se activează cand apare un eveniment ce modifică coada
„ready”
+ procesul in executie cere acces la planificator, se termina sau intra in
asteptare
in executie “ready”
T1
in executie
suspendat in executie
suspendat
activare T1 Terminare T1
T2
v
in executie “ready”
T1
in executie
suspendat in executie
suspendat
activare T1 Terminare T1
T2
v
cadru
(„frame”)
• mod preemptiv!!!!
o algoritmul de planificare – cum alege taskul câştigător:
� uzual pe bază de prioritate
� priorităţile pot fi statice (un task are aceeaşi priroitate pe durata
execuţiei aplicaţiei) sau dinamice (un task îşi modifică prioritatea)
• la multe SOTR: statice (stabilite de designer)
I. 1. 5. Execuţia ISR
Atentie: ISR nu sunt supervizate de planificator!
Cererile nu sunt stocate in coada ready – gestionate de controllerul de
intreruperi
Uzual ISR sunt gestionate pe nivele de prioritate superioare:
un ISR intrerupe orice task daca IF permite
+
modifcare IF – disable/enable
un ISR poate intrerupe un ISR mai putin prioritar daca IF permite
I. 2 Restricţiile de timp – definiţii utile
� Restricţia de timp - cerinţa de a executa o operaţie după ce sunt îndeplinite
anumite condiţii şi înainte de un termen prestabilit
),,,,( deadlineIexecreleased tpttId
cu releaseexec ttt −< deadline ,
p perioada de activare a proceselor periodice
Id – identificator task
procesi
ei
(executie)
Di
(deadline relativ)
Taski li
rezerva
(laxity, slack)
di
termen limita
(deadline absolut)
ri
activare
(release)
timp
interval in care procesul
trebuie sa se execute
(occurance interval, feasible interval)
Taski
intarziere
(tardeness)
Timpul de activare ri
poate incorpora şi restricţii de precedenţa (procesul se poate executa doar dacă
alte procese s-au executat)
Timpul de executie ei
este calculat pentru un proces care se executa fara a fi intrerupt-preemtat, avand
toate resursele necesare disponibile si toate restrictiile de precedenta indeplinite
Depinde de viteza resurselor active
Nu depinde de secventa de executie a taskurilor
Poate fi diferit daca exista instructiuni conditionale,
daca se foloseste memorie cash
],[+−
∈ iii eee >> se va considera in analiza +
ie
Obs:
In aplicatiile de timp real exista multe procese periodice
Aplicaţii on-line: ∞<deadlineT ; aplicaţii off-line: ∞→deadlineT
Tipuri restrictii de timp
• hard (ferme)
• soft (mai putin severe, optionale)
Functia de utilitate
Indica daca este utila executia procesului chiar si dupa expirarea termenului limita
intarziere
utilitate
0
Timp = resursa STR ⇒ corectitudine în funcţionarea STR
Alte restricţii ce trebuie îndeplinite:
� Performanţe impuse pentru anumite operaţii
� Fiabilitate STR
� Restricţii privind accesul la resursele comune limitate şi partajabile:
procesoare, dispozitive IO, baze date, resurse reţea comunicaţie
De multe ori SOTR oferă doar ajutor in gestionarea resurselor
active/pasive conform prioritatilor proceselor
Respectarea restricţiilor ramâne in sarcina designer –ului!!!!
Respectarea restrictiilor de timp se verifica pe cazul cel mai nefavorabil
Acesta este greu de gasit la sisteme cu multe procese, principalele dificultăţi
fiind: determinarea +
ie , ri, lucru cu procese aperiodice sau sporadice, intârzieri,
situaţii neprevăzute
• Cerinţă: respectarea predictibilă a restricţiilor de timp (importante)
Plan = secventa/ordinea in care se vor executa taskurile
Plan valid (corect) – asigura respectarea conditiilor:
• Un procesor are asignat un singur job la un moment dat
• Un proces este asignat maxim unui singur procesor la un moment dat
• Niciun task nu incepe inainte de ri
• Restrictiile de precedenta si de utilizare a resurselor sunt indeplinite
• Un task ocupa procesoarele maxim un timp egal cu ei
Plan admisibil (“feasible”) – plan valid ce asigura respectarea deadline-urilor
Sisteme de timp real
PET [Physical Execution Time] -
o descriere temporală exactă a secventei de executie, prin design
o acces exclusiv la procesor - uzual main + ISR in ASM
BET [Bounded Execution time] – cu SOTR: taskuri + ISR
o RT: deadine pentru taskuri
Probleme: adaugarea unor taskuri noi afecteaza modul de execuţie al
taskurilor deja existente în sistem
LET [Logical Execution time]
Exemplu: HTL [Hierarchical Timimg Language]
� comunicator = variabila ce poate fi accesata la anumite momente de timp
pentru sciere-citire
� „mode” – grup de taskuri de aceeaşi frecvenţă; acceptate restricţii de
precedenţă
→ un program HTL: set de comunicatori + „mode” -uri
o taskurile nu includ sincronizări, ci citesc/ actualizează instanţe ale
comunicatorilor;
o taskurile comunica prin comunicatori; comunicarea directa intertask
permisă în mode prin porturi