7.1. Introducere: Caracteristicile sistemelor de operare în timp real
Atunci când lucrăm cu dispozitive mobile în mișcare (care este, în esență, un robot), ne confruntăm cu nevoia de a reacționa cât mai repede posibil la evenimentele externe. Pentru a rezolva această problemă, există o clasă specializată de sisteme de operare.
Sistemele de operare în timp real (RTOS) sunt concepute pentru a oferi o interfață cu resursele sistemelor de timp în timp real. Sarcina principală în astfel de sisteme este actualitatea procesării datelor.
Deoarece principalele cerințe pentru un RTOS este invocat cerința de a asigura predictibilitatea și determinismul comportamentului sistemului în cele mai rele condiții de mediu, care este foarte diferit de cerințele de performanță și viteză scop OS. Un bun RTOS are un comportament previzibil pentru toate scenariile de boot al sistemului (întreruperi simultane și filetare).
Există diferențe între sistemele în timp real și sistemele încorporate. Sistemul încorporat nu necesită întotdeauna comportamente previzibile și, în acest caz, nu este un sistem în timp real. Cu toate acestea, chiar și o privire sumară la sistemele integrate posibile sugerează că majoritatea sistemelor integrate necesită un comportament previzibil, cel puțin pentru o parte din funcționalitatea, și, prin urmare, aceste sisteme pot fi atribuite sistemelor în timp real.
Se obișnuiește să se facă distincția între sistemele soft și greu în timp real. În sistemele grele în timp real, incapacitatea de a reacționa la orice evenimente la un moment dat duce la eșecuri și la imposibilitatea de a îndeplini sarcina la îndemână. În majoritatea literaturii în limba rusă, astfel de sisteme sunt numite sisteme cu timp determinist. În practică, timpul de reacție trebuie să fie minim. Sistemele soft în timp real sunt sisteme care nu se încadrează în definiția "greu", tk. în literatură nu există încă o definiție clară pentru ei. Este posibil ca sistemele soft în timp real să nu aibă timp să rezolve problema, dar acest lucru nu duce la o eșecare a sistemului în ansamblu. În sistemele în timp real necesare pentru introducerea unor termene limită (în literatura engleză - termen), în care trebuie în mod necesar (pentru sisteme în timp real moale - de preferat), sarcina să fie îndeplinite. Această perioadă de planificare este utilizată de programatorul de sarcini atât pentru a atribui o prioritate sarcinii atunci când este lansată, fie când se selectează o sarcină de executat.
- Sistemul de operare ar trebui să fie multi-tasking și preemptable (preemptable),
- Sistemul de operare ar trebui să aibă conceptul de prioritate pentru fire,
- OS ar trebui să sprijine mecanismele de sincronizare previzibile,
- OS ar trebui să ofere un mecanism pentru moștenirea priorităților,
- comportamentul sistemului de operare ar trebui să fie cunoscut și previzibil (întârzieri în procesarea întreruperilor, întârzieri în comutarea sarcinilor, întârzieri ale conducătorilor auto etc.); acest lucru înseamnă că, în toate scenariile privind volumul de lucru al sistemului, timpul maxim de răspuns trebuie determinat.
În ultimii 25-30 de ani, structura sistemelor de operare a evoluat de la o structură OS monolitică la mai multe straturi și ulterior la o arhitectură client-server. Cu o structură monolită, sistemul de operare constă dintr-un set de module, iar modificările la un modul afectează alte module. Cu cât mai multe module, cu atât mai mult haos în funcționarea unui astfel de sistem. În plus, este imposibil să distribuim sistemul de operare într-un sistem multiprocesor. Într-o structură multistrat, modificările într-un singur strat afectează straturile adiacente; în plus, tratamentul prin strat nu este posibil. Pentru sistemele în timp real, accesul direct la fiecare strat OS ar trebui să fie furnizat și, uneori, direct la hardware.
Ideea principală a tehnologiei client-server în sistemul de operare este reducerea bazei sistemului de operare la minimum (primitive de programator și de sincronizare). Toate celelalte funcționalități sunt aduse la un alt nivel și puse în aplicare prin fire sau sarcini. Totalitatea acestor sarcini de server este responsabilă pentru apelurile de sistem. Aplicațiile sunt clienți care solicită servicii prin apeluri de sistem.
Tehnologia client-server vă permite să creați sisteme de operare scalabile și simplificați distribuția într-un sistem multiprocesor. Atunci când utilizați sistemul, înlocuirea unui modul nu cauzează un efect de zăpadă; În plus, defecțiunea modulului nu implică întotdeauna o eșecare a sistemului în ansamblu. A existat o oportunitate de încărcare și expediere dinamică a modulelor. Principala problemă a acestui model este protejarea memoriei. Deoarece procesele de server trebuie să fie protejate. De fiecare dată când serviciul este solicitat, sistemul trebuie să treacă de la contextul aplicației la contextul serverului. Cu ajutorul protecției memoriei, timpul de comutare de la un proces la altul este mărit.
De regulă, majoritatea RTOS-urilor moderne sunt construite pe baza unui microkernel (kernel sau nucleu), care oferă sarcini de programare și dispecerizare și, de asemenea, le interacționează. În ciuda minimalizării abstractizărilor sistemului de operare, microkernelul ar trebui să aibă încă o idee despre abstractizarea procesului. Toate celelalte abstracții conceptuale ale sistemelor de operare se află în afara nucleului, sunt solicitate la cerere și sunt executate ca aplicații.
Luați în considerare abstracțiile conceptuale ale sistemului de operare prin prisma cerințelor pentru sistemele în timp real.
7.2. Procese, fluxuri, sarcini
Deci, în sistemele în timp real, procesul se descompune în sarcini sau fire. În orice caz, fiecare proces este tratat ca o aplicație. Nu ar trebui să existe prea multe interacțiuni între aceste aplicații și, în cele mai multe cazuri, ele au o natură diferită - timp real greu, timp real moale, nu timp real.
7.3. Planificare, priorități
În legătură cu problema termenelor limită, principala problemă în RTOS este programarea, ceea ce ar asigura comportamentul previzibil al sistemului în toate circumstanțele. Procesul cu termene limită trebuie să înceapă și să fie efectuat astfel încât să nu piardă niciunul dintre termenele sale. Dacă acest lucru nu este posibil, procesul trebuie respins.
Din cauza unor probleme de programare RTOS a studiat și a dezvoltat două abordări - algoritmi de planificare statice (RMS - Rata monotonă Programarea) și algoritmi de planificare dinamice (FED - Cea mai devreme Termen întâi).
RMS este folosit pentru a demonstra în mod oficial predictibilitatea sistemului. Pentru a pune în aplicare această teorie, trebuie să planificați pe baza programării prioritare preemptive. În teoria RMS, prioritatea este atribuită fiecărui proces în avans. Procesele trebuie să îndeplinească următoarele condiții:
- procesul trebuie să fie finalizat pe durata perioadei sale,
- procesele nu depind de ele,
- fiecare proces necesită același timp CPU la fiecare interval,
- în procesele neperiodice nu există termeni rigizi,
- procesul este întrerupt pentru o perioadă limitată de timp.
Procesele sunt efectuate în conformitate cu prioritățile. La planificarea RMS, preferința este dată sarcinilor cu cele mai scurte perioade de execuție.
În EDF, prioritatea este atribuită dinamic, iar cea mai mare prioritate este setată la procesul care are cel mai scurt timp de execuție. Pentru sarcini mari de sistem, EDF are avantaje față de RMS.
Toate sistemele în timp real necesită o politică de planificare. gestionate de termene limită - planificate. Cu toate acestea, această abordare este în curs de dezvoltare.
De obicei, RTOS utilizează programarea cu priorități care întrerup serviciul, care se bazează pe RMS. Prioritatea întreruperii serviciului (preemption) este o parte integrantă a RTOS. într-un sistem în timp real, trebuie să existe garanții că un eveniment cu prioritate ridicată va fi procesat înainte de un eveniment cu prioritate mai mică. Toate acestea conduc la faptul că RTOS nu are nevoie doar de un mecanism de programare bazat pe priorități care întrerupe întreținerea, dar și în mecanismul adecvat de control al întreruperii. În plus, RTOS ar trebui să poată interzice întreruperile atunci când este necesar să execute un cod critic care nu poate fi întrerupt. Durata procesării întreruperilor ar trebui să fie redusă la minimum.
Un RTOS ar trebui să aibă un sistem dezvoltat de priorități. În primul rând, este necesară deoarece sistemul în sine poate fi privit ca un set de aplicații server care sunt împărțite în fire și mai multe niveluri de prioritate ar trebui să fie alocate proceselor și firelor de sistem. În al doilea rând, în aplicații complexe, toate fluxurile în timp real trebuie plasate pe diferite niveluri de prioritate, iar fluxurile non-în timp real ar trebui să fie plasate pe un nivel (mai mici decât orice flux în timp real). Atunci când acest flux nu este posibilă procesarea în timp real în round-robin modul de programare (RRS - round-robin programare), în care fiecare proces oferă un cuantum de timp CPU, iar când cuantumul se termină contextul procesului este salvat, și este pus în coada de așteptare. În multe RTOS, RRS este folosit pentru a programa sarcini la același nivel. Nivelul de prioritate 0 este de obicei utilizat pentru modul inactiv.
Când se planifică pe baza priorităților, trebuie rezolvate două probleme obligatorii:
- Asigurați-vă că procesul este executat cu cea mai mare prioritate,
- Prevenirea inversării priorităților, când sarcinile cu priorități mari așteaptă resursele captate de sarcinile cu priorități mai mici.
Pentru a combate inversarea prioritară în RTOS, mecanismul prioritar de moștenire este adesea folosit, dar trebuie să renunțați la planificarea bazată pe RMS. deoarece prioritățile devin dinamice.
Trimiteți-le prietenilor: