Obiectiv capitol

Prezentarea particularitatilor sistemelor de timp real.

Cuprins:
Restrictii de timp. Modele STR
Taskuri si intreruperi. Preemptiune. Planificator
Algoritmi de alocare si planificare
Aplicatii monoprocesor: sincronizare taskuri
Arhitecturi STR. Algoritmi de planificare a mesajelor
Dispozitiv IO
Sincronizarea ceasurilor in STR distribuite
Directii de cercetare

Bibliografie
Richard Zurawski,
Embedded Systems Handbook, CRC Press, 2006
***, OSEK/VDK Operating System Specifications, http://www.osek-vdx.org/
V. PROBLEMATICA APLICAŢIILOR DE
TIMP REAL
V.1. Generalităţi

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
prestabilite

Hardware -ul asigura răspuns rapid la evenimente externe, sincronizare

temporală, siguranţă

Aplicaţia dezvoltată multitasking – procese modulare, cu priorităţi diferite

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

cel putin o resursa activa (procesor, server)

eventual anumite resurse pasive (memorie, etc)

se considera ca o resursa pasivă poate fi ocupata de un singur

proces la un moment dat (acces exclusiv)

după ce a ocupat o resursa, un proces poate ceda temporar resursa

unui alt proces mai prioritar (acces preemtiv)
Ocuparea resurselor active/pasive este tratată distinct se SOTR

1. Ocuparea resurselor active:

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;
Motontasking Multitasking
ISR
ISR
while(1){ while(1){
if() operatii task 1
if(…) operatii task 2 }
etc Task3
} Task1
Task2

Avantaje abordare multitasking:

- Extensie simpla – adaugare taskuri T2 T1 T1T2 T2 T2T3 T3
- Prioritati diferite
- Temporizari & restrictii de timp mai
flexibil de gestionat, independent
pentru fiecare task
 SOTR asigura comutarea corecta de la un proces la altul (comutarea
contextelor)

Context task

= conţinut regiştri + adresa de început task + stare task +adresa stivei iniţiale +
var. specifice ale SOTR

orice proces trebuie executat consistent, indiferent ce comutări de

contexte au loc
2. Ocuparea resurselor pasive:

o 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 acestora

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)

V. 1. 1. Sisteme de operare de TR
Asigură
- planificarea cu restricţii de timp
- comutarea rapidă a contextelor
- tratarea predictibilă a întreruperilor
Nu sunt esenţiale: gestionare fişiere, suport memorie virtuală, securitate

Clasificare:
o Kernel
– mici, rapide, predictibile
– acceptă taskuri puţine ⇒ aplicaţii mici
o SO comerciale cu extensii de TR
- Mai lente, mai putin predictibile
- Au interfeţe prietenoase
- Permit dezvoltarea unor aplicaţii mai ample, dar nu critice
o SO dedicate
Limbaje de programare utilizate: asamblare; C; ADA
V. 1. 2. Detalii despre ocuparea resurselor active in SOTR

V. 1. 2. 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

⇒ necesitate considerare priorităţi pentru taskuri

3) dupa gradul de independenta

o dependendente (restrictii de precedenta, resurse partajate)
o independente (fără resurse partajate, fără aşteptare rezultate)
V. 1. 2. 2. Starile posibile ale unui task

in curs de executie
(“running”)
Cere asteptarea
unui eveniment Se termina de
executat
Pierde Primeste
procesorul procesorul
in asteptare (“preempt”) (“start)
(“waiting”) suspendata

Evenimentul asteptat pregatita pentru activata

a avut loc executie (“ready”)

Pot exista diferente intre SOTR cu privire la modul de trecere del a o stare la alta sau
denumirea stării
V. 1. 2. 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:

activare T1 Terminare T1

T1
suspendat in executie suspendat

v
in executie “ready” in executie
T2
 o nepreemtiv

un proces nu cedează procesorul altui proces activ, fără acordul său

activare T1

T1
suspendat ready” in executie

v
in executie suspendat
T2
Terminare T2

>> pot fi admise moduri mixte: unele procese preemtive, altele nepreemtive
V. 1. 2. 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:
planificatorul se activează periodic (o perioadă = frame)
+ procesul in executie cere acces la planificator, se termina sau intra in
asteptare

event driven:
planificatorul se activează cand apare un eveniment ce modifică coada
ready
+ procesul in executie cere acces la planificator, se termina sau intra in
asteptare
o algoritmul de planificare – cum alege taskul câştigător:

 uzual pe bază de prioritate – taskul prioritar primeste controlul

+ ce algoritm se foloseste daca pe exista mai multe taskuri ready pe

acelasi nivel (maxim) de prioitate: FIFO, round rubin

 priorităţile pot fi
• statice (un task are aceeaşi priroitate pe durata execuţiei
aplicaţiei) – vezi RM, DM
• dinamice (un task îşi modifică prioritatea) – vezi EDF, MLF

La multe SOTR: statice (stabilite de designer)

 planificatoare

“event-driven” „clock-driven”

static on-line
on-line static

cu prorităţi cu priorităţi
fixe dinamice cu prorităţi cu priorităţi
fixe dinamice
Performantele algoritmului de planificare:

Eficienta – intervalul de timp alocat executiei proceselor (fara comutare de

context) intr-o unitate temporala
Debit – numar de procese executate intr-o unitate de timp

Imparţialitate – numar de procese distincte executate intr-o unitate de timp

>> partajare echitabilă a procesorului

Timp răspuns mic interval de timp mediu de raspuns la evenimente externe şi

întreruperi

OBS: unele cerinţe sunt contradictorii: eficienta - debit

Predictibilitate

- garantarea faptului că se respectă RT (şi o anumită secvenţă de execuţie)

Elemente ce pot influenţa secvenţa de execuţie:

- arhitectura hardware: procesor, DMA, memorie cash, prefetch, INT
- SOTR: planificator, management I/O, management memorie, sincronizări
- limbaj

Predictibilitatea este mai importantă ca timpul total de execuţie

+ Fiabilitate, robusteţe
V. 1. 2. 5. Execuţia ISR

Atentie: ISR nu sunt supervizate de planificator!

Cererile nu sunt stocate in coada ready

Uzual ISR sunt gestionate pe nivele de prioritate superioare:

un ISR intrerupe orice task daca IF permite

Un ISR poate intrerupe un ISR mai putin prioritar daca IF permite

V. 1. 3. Restricţiile de timp – definiţii utile

Caracteristicile unui task

un task - un set de joburi {J i1 , J i 2 ,....} .

un job desemnează o secvenţă de procesare

• un job este asociat unei noi instanţe active a takului Ti

sau

• mai multe joburi pentru fiecare instanţă activă.

Sunt acceptate si notatii simplificate J i .

Momentul de activare („release time”) r i

- momentul de timp la care J i trece din din starea „suspendată” în starea gata
de execuţie

La un task periodic - distribuite periodic.

Faza – momentul primei activări

gata de execuţie, gata de execuţie, gata de execuţie,

in curs de execuţie, in curs de execuţie, in curs de execuţie,
„suspendat” „suspendat” „suspendat”
în asteptare în asteptare în asteptare

Ji1 Ji2 timp

Ji3
ri1 ri2 ri3 ..........

La un task aperiodic - uzual distribuite stocastic.

Termen limită (“deadline”)

- momentul de timp până la care jobul trebuie să se termine de executat:

• absolut d i - exprimat considerand t = 0 = momentul începerii

execuţiei aplicaţiei

• relativ Di - exprimat relativ la momentul de activare:

Di = d i − ri

Analiza bazată pe termeni limită relativi este avantajoasă, în

special dacă aplicaţia conţine numai taskuri periodice.
Timpul de răspuns al unui job

- intervalul de timp dintre momentul de activare şi momentul la care se

termină execuţia job-ului.

Condiţie necesară pentru respectarea RT: timpul de răspuns ≤ Di .

Întârzierea („tardness”) - intervalul de timp cu care a fost depăşit di

Timpul de execuţie ei

- intervalul de timp necesar pentru execuţia completă a jobului J i ,

considerând că acesta ocupă resursa activă fără a fi întrerupt, preemtat sau
blocat şi că are acces la toate resursele pasive necesare.
+ +
ei ∈ [ei− , ei ] → cazul cel mai nevaforabil ei = ei

(d i − ei ) − ri = rezerva jobului.
Jobul trebuie să îşi inceapă execuţia în intervalul de timp
[ri , (d i − ei ) − ri ] pentru a avea şanse să respecte termenul limită
asociat.
o Dacă acest lucru nu se întâmplă, restricţia de timp este
încălcată, dar condiţia nu este suficientă.
Determinarea WCET („worst case execution time”) şi BCET („best-case
execution time”)

o Prin măsurare → la sisteme non-critice

- Folosind facilităţi SOTR, emulatoare, simulatoare, osciloscoape, etc.

Observaţii:
Măsurarea prin soft modifică caractersiticile temporale ale execuţiei
Rezoluţie adecvată – uzual microsec
Trebuie cunoscută secvenţa de execuţie
Trebuie delimitate intervalele de timp consumate pentru execuţii ISR
şi de SOTR

Probleme:
o cost,
o să existe facilităţi oferite de SOTR,
o portabilitate scăzută a soluţiei de măsurare pe alte arhitecturi
o Prin analiză statică (şi măsurare)

3 etape:

i) Analiza diagramei de flux

- Determină toate secvenţele de execuţie posibile
- Elimină secvenţele de execuţie care nu sunt compatibile cu
datele de intrare acceptate

ii) Analiza informaţiilor legate de timpi de execuţie

iii) Calcul WCET şi BCET


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

( I d , t release , t exec , p I d ,t deadline )

cu t exec < t deadline − t release ,

p perioada de activare a proceselor periodice

Id – identificator task
 interval in care procesul
trebuie sa se execute
(occurance interval, feasible interval)

Di
(deadline relativ)

procesi timp

ri di
activare ei termen limita
(release) (executie) (deadline absolut)

li Taski
rezerva
(laxity, slack)
intarziere
(tardeness)

Taski
Obs:
In aplicatiile de timp real exista multe procese periodice
Aplicaţii on-line: Tdeadline < ∞ ; aplicaţii off-line: Tdeadline → ∞

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
utilitate

intarziere

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!!!!

Restricţii de precedenţă

- indică faptul că jobul se poate executa doar dacă alte joburi s-au executat
anterior.

Graf de precedenţă:
ipoteză: joburile între care nu
J1 (2,8) J3 (2,8) J4 (4,9) J6 (4,20)
există restricţii de precedenţă
(2,10) (1,12) (4,9) (0,20) sunt independente

(0,7) (6,21) Nod: job

(0,7) (6,21)
J7 Arc: existenţă unei restrictţii de precedenţă
J2
Etichete pentru nod graf: (ri, di)
J5
(2,8)

(1,8)
Plan

Plan valid:

o un procesor are asignat un singur job la un moment dat;

- condiţie implicit asigurată de SOTR

o un job este asignat maxim unui singur procesor la un moment dat;

- la sistemele mono-procesor condiţia implicit îndeplinită;
- la sistemele distribuite condiţia implicit asigurată de SOTR;

o niciun job nu îşi începe execuţia înainte de momentul de activare

- înainte de activarea unui task, SOTR nu permite execuţia acestuia;
- momentele de activare rezultă din modul în care a fost dezvoltată
aplicaţia, folosind servicii SOTR;
o restricţiile de precedenţă şi de accesare corectă a resurselor pasive sunt
îndeplinite;
- pentru a îndeplini această condiţie pot fi folosite servicii ale SOTR
pentru activarea înlănţuită a taskurilor şi partajarea resurselor
partajate;
- satisfacerea acestor cerinţe depinde de modul în care a fost
dezvoltată aplicaţia;

o un job ocupă resursa activă doar pe durata execuţiei sale ( ei < ei+ );
- SOTR care asigură tranziţiile adecvate de stare pentru fiecare task;
Respectarea restricţiilor de timp

- plan valid (corect): SO + PROGRAMATOR

- plan admisibil (“feasible”) – ce asigura respectarea restricţiilor

La priorităţi statice: verificare realizată de programator pe cazul cel mai

nefavorabil

La priorităţi dinamice:
verificare realizată de programator pe cazul cel mai nefavorabil – mai
dificil

Există teoreme utile pentru cazuri simple, particulare.

Eliminarea restricţiilor de precedenţă

- momentele de activare şi cele limită pot fi transformate în momente de

activare efective, respectiv momente limită efective care să înglobeze
restricţiile de precedenţă.

Avantaj: Restricţiile de timp vor putea fi analizate direct în raport cu aceste

valori, considerând taskurile independente.

J1 (2,8) J3 (2,8) J4 (4,9) J6 (4,20)

(2,10) (1,12) (4,9) (0,20)

(0,7) (6,21)
(0,7) J7
(6,21)

J2 J5
(2,8)

(1,8)
Momentul de activare efectiv pentru jobul Ji cu moment de activare ri :

o dacă taskul are predecesori, rei = max{ri , max (re _ p j + e _ p j )} , unde

j

re _ p j şi e _ p j reprezintă momentele de activare efective şi timpii de

execuţie pentru predecesori;

o dacă taskul nu are predecesori, rei = ri .
J1 (2,8) J3 (2,8) J4 (4,9) J6 (4,20)
(2,10) (1,12) (4,9) (0,20)

!! parcurgerea grafului
în sensul indicat de arce.
(0,7) (6,21)
(0,7) J7
(6,21)

J2 J5
(2,8)

(1,8)
Termenul limită absolut efectiv pentru jobul J i cu „deadline” absolut d i :

o dacă taskul are succesori, dei = min{d i , min (de _ p j − e _ p j )} , unde

j

de _ p j reprezintă termenele limită absolute efective pentru succesori;

o dacă taskul nu are succesori, dei = d i .

J1 (2,8) J3 (2,8) J4 (4,9) J6 (4,20)

(2,10) (1,12) (4,9) (0,20)

!! parcurgerea grafului
în sensul invers celui
(0,7) (6,21)
J7
indicat de arce.
(0,7) (6,21)

J2 J5
(2,8)

(1,8)
Lemă (Gary şi Johnson):

o aplicaţie mono-procesor cu
un set de joburi cu restricţii de precedenţă, fără alte tipuri de dependenţe

admite un plan admisibil în raport cu ri , d i

dacă şi numai dacă

admite un plan admisibil în raport cu rei , dei , generat neglijând restricţiile

de precedenţă ( rei , dei sunt calculate prin metoda aproximativă).

• Lemă elimină dezavantajul de a considera timpii de execuţie la calcularea

valorilor rei , dei .

• Lema permite eliminarea restricţiilor de precedenţă în analiza de admisibilitate.

V. 1. 4. Modele STR – variante

- sisteme cu mapare directă: fiecare task are un hardware

corespunzător ce îi asigură execuţia
⇒ planificare taskuri şi alocare resurse statice (prestabilite)

- sisteme ciclice – procese periodice

se convertesc taskurile aperiodice în cvasi-periodice.

⇒ planificare taskuri şi alocare resurse statice, dar mai flexibile
⇒ se poate depista relativ uşor cazul cel mai nefavorabil
⇒ se pot asigura deadline-urile pentru taskuri critice
Definiţii necesare în aplicaţii construite NUMAI cu taskuri periodice:

perioada

faza = momentul de activare al primului job (instanţă) a taskului periodic:

0 ri ≠ 0 T T+ri 2T 2T+ri

hiperperioada H = durata pentru cea mai scurta secvenţa de execuţie repetitivă

– definită pentru taskuri periodice, independente, fara ISR
(orice task se execută de un numar întreg de ori pe o hiperperioadă)
La sistemele periodice conteaza si lungimea cadrului:
exemple: per_T1=3, per_T2=4, H=12
per_T1=3.5, per_T2=4, H= 28

un ciclu major = secvenţa de execuţie dintr-o hiperperioada

Gradul de utilizare trebuie să fie cel mult unitar:
(altfel nu există resurse active suficiente)

n e
La taskuri periodice: U = ∑ i , cu
i =1 pi U ≤1
ei = timp executie task Ti
pi = perioada taskului Ti
n = numar taskuri

exemplu: două taskuri de perioadă 2, cu timp de execuţie 1

1 1 1 1
+ = + =1
p1 p 2 2 2

Obs: în practică, situaţia U =1 nu este robustă, deoarece pot apărea:

 comutări de contexte,
 întârzieri,
 ISR.
- sisteme cu evenimente asincrone:

tratare cereri de întreruperi; se convertesc taskurile periodice în

pseudoîntreruperi.

⇒ planificare taskuri şi alocare resurse dinamice

⇒ se poate depista foarte greu cazul cel mai nefavorabil

ri - valori aleatoare >> distributie de probabilitate pentru intervalul

dintre doua activari succesive
V. 2. Algoritmi de planificare in sisteme de timp real
monoprocesor

Teoria algoritmilor de planificare

Algoritm de planificare optimal - lucrând pe un jet de joburi ce permit obţinerea

unui plan admisibil, algoritmul de planificare produce un plan admisibil.

Această definiţie pune în evidenţă două situaţii de interes:

o Fiind dat un set de joburi şi un algoritm optimal, dacă planul obţinut este neadmisibil
înseamnă ca setul de joburi nu permite obţinerea unui plan admisibil, cu niciun
algoritm de planificare.
o Fiind dat un set de joburi şi un algoritm optimal, dacă planul obţinut este admisibil
înseamnă că pot exista şi alte planuri admisibile, posibil de obţinut cu alţi algoritmi
optimali sau neoptimali.
 Observatii:

• Set de taskuri pentru care există cel puţin un plan admisibil – planificabil

• Lema enunţată de Gary şi Johnson

Teoremele de optimalitate – indică algoritmi de planificare optimali

Ipoteze de lucru uzuale:

- aplicaţia este monoprocesor;

- aplicaţia include numai task-uri periodice;
- task-urile sunt independente (fără dependenţe legate de partajarea resurselor
sau de precedenţă);
- task-urile sunt active la începutul perioadei şi au Di ≤ p i ;
- task-urile au un timp de execuţie constant, mai mic decât perioada, ei ≤ pi ;
- task-urile nu se pot suspenda în mod voluntar;
- task-urile pot fi oricând preemtate de planificator pentru a ceda procesorul altui
task.
Plan = secventa/ordinea in care se vor executa taskurile

• Plan valid (corect) – asigura respectarea conditiilor:

• Plan admisibil (“feasible”) – plan valid ce asigura respectarea deadline-urilor

o Set de procese planificabil = set de procese pentru care exista cel putin
un plan admisibil

o Algoritm de planificare optimal = algoritm ce produce un plan admisibil,

daca acesta exista
Daca un algoritm optimal de planificare nu produce un plan admisibil,
atunci setul de procese nu este planificabil (planul admisibil nu exista)

• Plan maximal = plan obtinut pentru timpi maximi de executie pentru fiecare
job
• Plan minimal = plan obtinut pentru timpi minimi de executie pentru fiecare job
OBS:

o Majoritatea STR garanteaza respectarea restrictiilor DOAR pentru taskuri

critice şi esenţiale

Se pot considera pentru fiecare task două componente (joburi): una obligatorie
şi una opţională (preferabil de executat înainte de termenul limita).
Daca nu exista un plan admisibil se poate urmari:

• minimizarea numarului de joburi care incalca deadline-ul

• minimizarea intarzierilor/maximizarea valorii de utilizare

• minimizarea „makespan” [momentul de timp la care se termina de executat

ultimul job dintr-o secventa de joburi cu precedente]

• minimizarea ratei de esec:

invalid_rate = miss_rate [% joburi executate cu intarziere]

+ loss_rate[% joburi neexecutate]
V. 2. 1. Algoritmi de planificare – pentru planificatoare clock driven
Algoritmi de planificare cu priorităţi statice

Algoritm cu frecventa monotona RM:

= asignează prioritatea în funcţie de frecvenţa taskului periodic:
>> prioritate maximă pentru taskul cu frecvenţa (1/pi) maximă

Algoritm Liu, Layland:

= asignează prioritatea în funcţie de durata de executie :
>> prioritate maximă pentru taskul cu timp de executie minim

Algoritm cu deadline monoton DM:

= asignează prioritatea în funcţie de deadline-ul relativ al taskului
periodic:
>> prioritate maximă pentru taskul cu deadline-ul relativ (Di) mai
mic

OBS: Dacă Di= pi >> RM si DM sunt identici

Algoritmi de planificare cu priorităţi dinamice

Algoritm EDF:
= asigneaza prioritatea maxima pentru taskul cu deadline-ul
absolut (di) cel mai apropiat, faţă de punctul de replanificare
curent.

Algoritm MLF:
= asigneaza prioritatea maxima pentru taskul cu rezerva („laxity”)
mai mică, calculul acesteia fiind realizat în punctul de
replanificare curent.

Dezavantaj MLF: solicita calcularea timpilor de executie

Ex: r1 = 0, d1 = 10, e1 = 3
r2 = 2, d 2 = 14, e2 = 6
r3 = 4, d 3 = 12, e3 = 4 pentru f = 1.
Exemple MLF: T2 se poate executa dupa teminarea executiei pentru T1

T1, l1=3
e1=3 e2=2
T1 r1=0 T2 r2=5 T3, l3=3
d1=6 d2=8

1 3 2
e3=2 k
r3=2 T3
d3=7 l= d–r-e
T2, l2=1

F0, F1: ready T1 (l1=3).

F2: ready T1 (l1=3), T3(l3=3).
F3, F4: ready T3 (l3=2).
F5, F6: ready T2 (l2=1) – restr. de precedenta indeplinita.
 T1

T3

e1=3 e2=2
T1 r1=0 T2 r2=5
d1=6 d2=8
1 3 2
k

e3=2 Alt task T2

r3=2 T3
d3=7 l1=1 l3=0
l3=3 l2=1

F2: ready T1 (l1=1), T3(l3=3). F3: ready T1 (l1=1), T3(l3=2).

F4: ready T1 (l1=1), T3(l3=1).
F5: ready T2 (l2=1), T3(l3=0). F6: ready T2 (l2=0), T3(l3=0).
Restrictie de timp pentru T2 neindeplinită
 T1

T3

e1=2 e2=2
T1 r1=0 T2 r2=5
d1=10 d2=8 3 2 3 1
k k

T2
e3=4
T3 l1=6 l1=3
r3=2
l3=3 l3=3 l1=1
d3=9
l2=1 l3=1

F2: ready T1 (l1=6), T3(l3=3). F3: ready T1 (l1=5), T3(l3=3).

F4: ready T1 (l1=4), T3(l3=3). F5: ready T1 (l1=3), T3(l3=3), T2 (l2=1)
Restr. de precedenţă neîndeplinită - continuare eliminând această restricţie.
F6: ready T1 (l1=2), T3(l3=2), T2 (l2=1).
F7: ready T1 (l1=1), T3(l3=1), F8: ready T1 (l1=0)
Teoreme referitoare la optimalitatea algoritmilor RM şi DM,

în ipotezele de lucru anterior formulate: caz monoprocesor, mod preemptiv,

taskuri independente, Di ≤ p i , pentru U ≤ 1

1) Dacă DM nu conduce la plan admisibil, RM nu conduce la plan admisibil.

(DM poate oferi un plan admisibil în situaţii în care RM nu reuşeşte).

2) Dacă Di = p i si U ≤ 1 , atunci RM şi DM sunt algoritmi optimali.

Condiţie suficienta ca planul RM/DM să fie admisibil:

Di = p i , U ≤ 1 , set de taskuri planificabil
Conditii suficiente ca planul RM sa fie admisibil - nu se stie din ipoteza ca setul
este planificabil, dar concluzia asigura implicit si set planificabil

- pentru aplicaţii cu n taskuri independente, cu Di = p i :

Dacă U < U max şi ….., atunci RM conduce la un plan admisibil

1) Garanţia LL (Liu şi Layland):

Dacă U < n(21 / n − 1) , atunci RM conduce la un plan admisibil

Observatii:
n(21/ n − 1) este descrecătoare, lim
n→∞
n ( 21/ n
− 1) = ln 2 = 0.69
2) Dacă U < 1 şi taskurile sunt armonice, atunci RM conduce la un plan
admisibil
1
Taskuri armonice: ∃υ , ∀i → υ i = = kυ , cu k ∈ N
pi

3) Garanţie H - hiperbolică (Bini şi Butazzo)

n  e 
Dacă ∏  i + 1 ≤ 2 , atunci RM conduce la un plan admisibil .
i =1
 pi 

Observatie:
Mai puţin restrictivă decât garanţia LL
 U2
1 garanţia EDF

0.828

garanţia H

garanţia LL

O 0.828 1 U1
Teoreme referitoare la optimalitatea algoritmilor EDF si MLF

Teorema1:
Ipoteze: caz monoprocesor, mod preemtiv, taskuri independente.
EDF (Earliest Deadline First) este optimal

Teorema2:
Ipoteze: caz monoprocesor, mod preemtiv, taskuri independente.
MLF (Minimum Laxity First) este optimal

Teorema Horn
Ipoteze: caz monoprocesor, mod preemtiv, taskuri independente.
EDF asigură minimizarea valorii maxime a întârzerii
Demo teorema 1:
Orice plan admisibil poate fi transformat intr-un plan admisibil produs cu EDF

rk dk di

Ti Tk

rk dk di

Tk Tk Ti
Pentru taskuri nonpreemtive EDF nu este optimal
Ex: r1 = 0, d1 = 10, e1 = 3
r2 = 2, d 2 = 14, e2 = 6
r3 = 4, d 3 = 12, e3 = 4

Pentru cazul multiprocesor EDF nu este optimal

Ex: r1 = 0, d1 = 1, e1 = 1
r2 = 0, d 2 = 2, e2 = 1
r3 = 0, d 3 = 5, e3 = 5
doua procesoare
Exercitii

T1, T2 periodice, independente, preemtive

1. T1: p1=2 sec, are de executat niste operatii cu e1 = 1 sec; D1 = 1.5 (sau 2)
T2: p2=1 sec, are de executat niste operatii cu e2 = 0.5sec; D2 = 0.7 (sau 1).

2. T1: p1=2 sec, are de executat niste operatii cu e1 = 1 sec; D1 = 1.5 (sau 2)
T2: p2=2 sec, are de executat niste operatii cu e2 = 0.5sec; D2 = 1.7 (sau 2).

3. T1: p1=2 sec, are de executat niste operatii cu e1 = 1 sec; D1 = 1.1 (sau 2)
T2: p2=2.5 sec, are de executat niste operatii cu e2 = 0.5sec; D2 = 1 (sau 2.5).

Indicatie: Analiza se va face pe o hiperperioadă

Tratarea taskurilor non-periodice in sisteme clock driven

Ipoteze:
1. STR are n taskuri periodice, n= fix
2. parametrii taskurilor sunt cunoscuti
3. niciun task aperiodice nu este critic (nu exista taskuri sporadice)

Variante de lucru:

Taskurile aper. ready sunt introduse într-o listă separată, fără activarea
planificatorului

Procesorul execută taskuri aperiodice din această listă, DOAR atunci cand
nu trebuie executate taskuri periodice.
1. Taskurile aper. sunt introduse în listă fără a le verifica indeplinirea deadline-
ului.

Execuţia taskurilor aperiodice din coada de taskuri aperiodice ready se

poate realiza astfel:

i) taskurile aperiodice se execută dacă nu există taskuri periodice

ready (după execuţia taskurilor periodice în acel frame)

ii) taskurile aperiodice se execută în fiecare frame înainte de

taskurile periodice, in limita timpului permis de rezerva
REZ = f - e ,
cu e = timpul de executie pentru taskuri periodice
planificate in acel cadru
 Dezav: trebuie să existe un plan offline pentru taskuri periodice
 Avantaj: se asigură timp de răspuns mai bun la taskurile aper.
2. Un task aperiodic este inclus în lista de taskuri aperiodice ready numai dacă
trece un test de acceptanţă.

Trebuie să existe un plan offline pentru taskuri periodice – cu rezervele

disponibile la fiecare frame.

la fiecare început de frame se aplică testul de acceptare pentru taskurile

aperiodice activate în frame-ul anterior: dacă poate fi găsit un plan
admisibil, taskul e acceptat, altfel taskul e rejectat.

Planificare EDF (on - line) doar pentru taskurile aperiodice

EDF aplicat pentru coada de taskuri aperiodice acceptate
>> taskul aperiodic executat primul este cel cu deadline mai apropiat.
 Reject A4

A4: 5 >4.5
Reject A1
A4(44,5)
A1:4.5> 4

A1 (17, 4.5) A3 (22, 1.5)

A2(29,4
)

S2

3.5 7 10 15 23.5 27 30
19 35 39
4 8 12 16 20 24 28 36
32 40
1 2 3 4 5 6 7 8

hiperperioada hiperperioada

Accept A2
A2: 4 < 5,5

Accept A3
A3: 1,5 <=2 Notatie: A(d, e)
A2: rest 2, rezerva cu A3 1,5
EDF ciclic este optimal:
= poate gasi un plan admisibil pentru taskurile aperiodice
preemtive acceptate,
daca testul de acceptanta este facut la inceputul fiecarui cadru

ATENTIE!!!!:

EDF presupune ca anumite taskuri aperiodice vor fi rejectate.

EDF ciclic nu este optimal daca e comparat cu algoritmi care fac testul de
acceptanta oriunde (ex: se poate accepta S1),
dar e avantajos pentru takurile periodice (nu se ajunge la nr. mare
de preemtiuni)

Rezerva de timp stabilită offline poate fi uneori consumata de taskuri

periodice in situatii de supraincarcare (f. f. rare – ex: volum f. mare de date
de intrare) .
V. 2. 2. Gestionarea priorităţilor taskurilor in sisteme event driven
monoprocesor

Algoritmi cu prioritati statice

RM

Teorema 1:
RM optimal pentru un set de taskuri periodice independente, preemtive, cu
aceeasi perioada si Di ≥ pi, daca si numai daca U ≤ 1

Teorema 2:
RM optimal pentru un set de taskuri periodice independente, preemptive, cu Di
1
= pi, daca U ≤ n( 2 n − 1) , n = nr.taskuri
DM

Teorema 3
Exista un plan DM admisibil pentru un set de taskuri periodice independente,
preemptive, cu aceeasi faza si Di ≤ pi, daca exista un plan admisibil pentru orice
alt algoritm cu prioritati fixe
Algoritmi cu prioritati dinamice

EDF = prioritate fixa la nivel de job, dinamica la nivel de task

prioritatea unui job este stabilita la activarea job-ului
prioritatea unui job plasat in coada nu se modifica
prioritate maxima - > jobului cu deadline absolut mai mic

Teorema 1
Exista un plan EDF admisibil pentru un set de taskuri periodice independente,
preemtive, planificabile, cu Di = pi, daca si numai daca U ≤ 1.
Demo:
U > 1- evident nu exista un plan admisibil
U ≤ 1 – se demonstreaza ca EDF produce un plan admisibil pentru cazul
limita U = 1

Teorema 2
Exista un plan EDF admisibil pentru un set de taskuri periodice independente,
preemtive, , planificabile, cu Di > pi, daca U ≤ 1
FIFO

LDF nonstrict
= prioritate dinamica la nivel de job
toate rezervele joburilor din coada ready sunt recalculate la activarea
planificatorului
d −t − x
d= deadline absolut job,
x= timp de executie ramas pentru job
t= moment de timp actual
>> prioritatea unui job plasat in coada se poate modifica
prioritate maxima pentru jobul cu rezerva mai mica

Ex: T1(2,0.8), T2(5,1.5),T3(5.1,1.5)

LDF strict
Rezervele sunt recalculate continuu (nu doar la activare/terminare)
Prioritatile sunt modificate ori de cate ori ordinea rezervelor se modifica
 Obs: O comparatie se poate face in raport cu gr. de utilizare (< 1) pe planul
admisibil creat

EDF versus RM, DM:

Avantaje Dezavantaje
EDF Optimal Predictii greoaie
(←prioritati dinamice)
RM, Predictibilitate Neoptimale
DM (← prioritati fixe)
V. 3. Alte aspecte legate de aplicatiile de TR monoprocesor
Sincronizarea taskurilor

Directă - se trimit direct semnale/mesaje de blocare/activare

⇒ unele mesaje se pot pierde (dacă nu sunt aşteptate)

Indirectă – se folosesc mecanisme intermediare

o Prin semafoare – sincronizare printr-o întrerupere
Iniţializare: p1=p2=0

Task M Task A Task B

V(p1) P(p1) P(p2)

V(p2)

A şi B aşteaptă o execuţie a lui M

Dacă M se execută de mai multe ori (m)– A şi B dispun de m execuţii fără
blocare
 o Prin evenimente eveniment=0 şi eveniment=1

Exemplu OSEK– sincronizare pentru taskuri extinse preemtive

Eveniment sters setat sters

Planificator

Sterge asteapta
eveniment eveniment

T1 (extinsa) in asteptare r in executie in asteptare

e

T2 (extinsa) in executie ready in executie

Seteaza
eveniment
 o Metoda rendez-vous

A1 B1 C1

SC SC SC

sincronizare

A2 B2 C2

- nu se ştie care task ajunge primul la punctul de sincronizare

iniţializare rdv = număr taskuri în aşteptare (=3) – variabilă globală

SC:
rdv - -;
dacă rdv = = 0, relansează celelalte taskuri;
dacă rdv > 0, blocare task curent (aşteaptă celelate taskuri)
Probleme la sincronizarea taskurilor

eliminarea situaţiilor în care unele taskuri ocupă resurse fără a mai progresa
(aşteaptă evenimente care nu se mai pot produce)
⇒ producator-consumator
V. 4 Arhitecturi STR
Un STR distribuit consideră noduri interconectate în reţea.
Comunicarea între nodurile distribuite se va face prin mesaje.
Se vor asocia deadline-uri şi pentru mesaje.

A. NIVEL NOD

Un nod poate fi:

- reţea de procesoare (ce permite dezvoltări ulterioare)
- multiprocesor orientat pe aplicaţii (module încapsulate – nu permit dezvoltări
software)

Un nod trebuie să asigure:

- Să răspundă cererilor de întreruperi
- Să asigure interacţiunea cu exteriorul
- Să asigure execuţie instrucţiuni şi acces la memorie
OBS: nu se vor folosi memoriile dinamice care fac impredictibil accesul
B. NIVEL REŢEA
Se asigură
- comunicare flexibilă între noduri
- implementare simplă
- fiabilitate
- posibilitate de reconfigurare în caz de eroare

De obicei nodul conţine un procesor dedicat comunicaţiei (NETWORK

PROCESSOR) care se ocupă de:
- transmite mesajele (cu detecţie erori şi retransmisie în caz de eroare)
- alege căile de transmisie a mesajelor prin reţea şi intervalele de timp
aferente
- gestionează mesajele pe nivel de priorităţi, cu facilităţi de bufferare
- încapsulează datele în blocuri mai mici şi le reasamblează la
destinaţie
- monitorizează stare reţelei (încărcare curentă + trasee defecte) şi
gradul de încărcare a procesoarelor din nodul său
Algoritmi de planificare a transmiterii mesajelor

1) pentru reţele cu acces multiplu

Dezavantaj: dacă o legătură cade, legătura între noduri nu poate fi refăcută decât
dacă se foloseşte hardware redundant

o reţele nonRT pentru transmiterea mesajelor se foloseşte un algoritm local

fiecărui nod (listă FIFO locală) ⇒ nu se garantează că strategia este globală

o reţele RT – trebuie folosită o strategie globală – liste FIFO la nivel de retea!!

 Ceas virtual
Schema Molle: se construieşte o lista FIFO după timp sosire mesaj
Schema Yhao şi Ramamrithan: se construieşte o lista FIFO după
Minimum Laxity First, Earliest Dealine First, Shortest Length First
Dezavantaj: nu foloseşte istoria evenimentelor în selectarea
mesajelor de transmis
 Protocoale window-based
Când un canal este liber se alege fereastra pentru timpii de sosire şi
din acest interval se selectează un mesaj de transmis
Dezavantaj: nu garantează determinist trimiterea mesajelor şi
respectarea termenelor pentru taskurile critice

 Metoda Agrawal
Fiecărui nod i se aloca un interval de timp (cuanta). Nodul va deservi
intâi mesajele critice
Avantaj: se pot anticipa mai uşor rezultatele
2) pentru reţele punct la punct

Avantaj:
- există mai multe legături între orice două noduri (în caz de defect – variante de
rezervă)

Dezavantaj:
- pot să nu existe legături directe între orice 2 noduri.
- traseul optim greu de ales.

Protocol real-time channel:

Pas 1: stabilire canal
– utilizarea unor resurse minime de reţea,
– balansarea traficului
– respectarea restricţiilor de timp
Pas 2: transmitere mesaj
- separare pe pachete
- calculare deadline pentru fiecare pachet
OBS:

Alegerea unei rute afectează posibilităţile viitoare de selecţie

Pentru siguranţă, mesajele se pot transmite în mai multe copii, pe căi diferite
Varianta Garcia, Molina: 2 copii
Alte variante: numar copii ales în funcţie de importanţa mesajului, intensit.
taficului, nr. noduri intermediare
V.5 Dispozitive IO
IO afectează hotărâtor viteza STR.

La STR distribuite: de obicei distribuite, conduse de un controller.

IO trebuie să permită acces multiplu

O variantă:
- Sunt grupate dispozitivele IO;
- Pentru fiecare cluster se foloseşte un controller;
- Controllerul poate fi accesat de N noduri;
- Pentru alocarea dispozitivelor, controllerul poate folosi algoritmi

 Statici – ordine prestabilită de verificare a încărcării disp. IO

 Dinamici
V.6. Sincronizarea ceasurilor
STR distribuit solicită un timp global unic
⇒ ceasurile trebuie sincronizate

Metode de sincronizare:

1) software
Principiul metodei:
- pentru sincronizare ceasurile îşi transmit mesaje între ele (cu ora lor
exactă);
- se compară informaţiile primite;
- momentele de timp pentru sincronizare sunt prestabilite

avantaje: flexibile, puţin costisitoare

dezavantaje: încarcă STR cu mesaje suplimentare, performanţele lor
solicită cunoaşterea intevalului necesar transmiterii mesajelor
 o Algoritm fără mediere
Se alege un ceas ca referinţă pentru întreg sistemul

o Algoritm cu mediere
Fiecare ceas calculeaza deviaţia sa ştiind valoarea citită şi momentul de
citire
Deviaţia finală
= media aritmetică a deviaţiilor
= media aritmetică pentru unele deviaţii (cele mai mari m deviaţii
sunt eliminate)
- eventual dacă deviaţia este mai mare decât un prag – neconsiderată.

Anomalia bizantină
= un ceas din STR este stricat şi minte celelate ceasuri

o pentru m ceasuri defecte, cu minim 2m+2 ceasuri (noduri) în total – anomalia

este detectabilă (preferabil 3m+1):
 1 1

1:00 1:00
1:05 1:10 12:55 1:10
1:00 1:00

1:05 12:55
2 3 2 3
1:10 1:10

2) hardware
dezavantaje: hardware adiţional
 CLK
Detector U=kϕ Oscilator
CLK
de fază comandat
sincronizat
REFERINŢĂ în tensiune

Semnalul de referinţă este greu de ales!!!

OBS:
rata anomaliilor pe conexiunile dintre ceasuri este mai mare decât rata defectării
ceasurilor
V.7. Aplicaţii. Direcţii de dezvoltare
Aplicaţii:

Controlul proceselor

Inteligenţă artificială:
Construcţia unor baze de reguli
Probleme de predictibilitate: îmbunătăţirea bazei de reguli separat, în
paralel; on-line se foloseşte un planificator anterior proiectat

Baze de date: acces rapid şi garanţii temporale
Direcţii de dezvoltare:

Determinarea timpilor de execuţie (în cazul resurselor partajate, bucle dependente
de datele de intrare, în funcţie de SO, limbaj-compilator)

Metode sistematice de asignare a termenelor limită pe taskuri, mesaje

Formalizarea determinării cazului mai nefavorabil

Comunicare în TR

Planificare IO

Baze de date: verificarea capacităţii lor de respecta restricţiile de timp privind
accesul, planificarea accesărilor

Diagnoza anomaliilor, reconfigurare

Experimentare pe cazuri complexe