Aritoni Ovidiu Sisteme de operare 1 Introducere

Ierarhia de procese

Sistemul de operare care suportă conceptul de proces trebuie să furnizeze o modalitate pentru a crea toate procesele necesare. În sistemele foarte simple, sau în sistemele concepute pentru a rula doar o singură aplicaţie (exemplu: controlarea unui dispozitiv în timp real), este posibil să aibă toate procesele care vor fi vreodată necesare când sistemul este pronit. Oricum în majoritatea sistemelor este necesar o modalitate de a crea şi a distruge procesele necesare în timpul operaţiei. În MINIX procesele sunt create de apelul sistem fork, care crează copia identică a procesului care apelează. Procesul copil poate de asemenea executa fork, deci este posibil să obţină o ierarhie de procese. În alte sisteme de operare, apelurile sistem există pentru a crea un proces, pentru a încărca memoria, şi pentru a porni rularea. Oricare ar fi natura exactă a apelului sistem procesele au nevoie de o modalitate de a crea alte procese. Observaţi că fiecare proces are un singur părinte dar zero, una, doi sau mulţi copii. Ca exemplu a felului cum sunt folosite ierarhile de procese, haide să ne uităm la felul cum MINIX se iniţializează când porneşte. Un proces special numit INIT, este prezent în boot image (imaginea de bootare). Când începe să ruleze citeşte un fişier spunând câte terminale există. Apoi generează un nou proces pe terminal. Aceste procese aşteaptă ca alte proces să se login-ieze (să se identifice). Dacă un login este reuşit procesul de login-are execută un apel al shellului pentru a accepta comenzi. Aceste comenzi pot să genereze mai multe procese, ş.a.m.d. Astfel toate procesel din întregul sistem aprţin unei singuri ierarhi, un INIT la rădăcină (codul pentru INIT nu este prezentat în carte şi nici shellul. Linia trebuie trasă undeva.)

• Stările proceselor

Deşi fiecare proces nu este o entitate independentă cu propriul său program de contabilizare şi o stare internă deseori procesele trebuie să interacţioneze cu alte procese. Un proces poate genera date de ieşire pe care alt proces le poate folosi ca date de intrare. În comanda shell cât chapter 1, chapter 2, chapter 3/greep tree primul proces, care rulează cât concretizează şi generează 3 fişiere. Al doilea proces, care lucrează greep selectează toate liniile ce conţin cuvântul tree. Depinzând de vitezele relative ale celor două procese (care depind atât de complexitatea relativă a programelor cât şi decât de mult timp a avut fiecare proces), s-ar putea întâmpla ca greep să fie gata să ruleze, dar nu există date de intrare care-l aşteaptă. Trebuie astfel blocat până când câteva date de intrare sunt disponibile. Când un proces se blochează se întâmplă asta pentru că din punct de vedere logic el nu poate continua deoarece aşteaptă datele de intrare care nu sunt încă disponibile. Este de asemenea posibil ca un proces care conceptual vorbind este gata şi capabil să ruleze să fie oprit deoarece sistemul de operare a decis să aloce procesorul altui proces pentru un timp. Aceste două condiţii sunt complet diferite.În primul caz suspensia este inerentă în problema (nu poţi procesa linia comandă a utilizatorului până când nu a fost tipărită.) În al doilea caz este o chestiune de tehnică a sistemului (nu sunt suficiente procesoare pentru a acorda câte unu fiecărui proces). În figura 2-2 observăm o diagramă a stării arătând cele trei stări în care poate fi un proces.

• 
  Rulare (de fapt folosim procesorul în acel moment);
  
• 
  Ready (pregătit de rulare care poate rula, oprit temporar pentru a lăsa alt proces să ruleze);
  
• 
  Blocat (incapabil să ruleze până când anumite evenimente externe se întâmplă).
  

Din punct de vedere logic primele două stări sunt similare. În ambele cazuri procesul e dispus să ruleze numai ca în cea de a doua stare, temporar nu este nici un procesor disponibil pentru el. A treia stare este diferită de primele două prin faptul că procesul nu poate rula chiar dacă procesorul nu are nimic altceva de făcut. Patru tranziţii sunt posibile între cele trei stări aşa cum este arătat. Tranziţia 1 are loc când un proces descoperă că nu poate continua. În unele sisteme procesul trebuie să execute un apel sistem BLOCK pentru a intra in starea blocată. În alte sisteme inclusiv MINIX când un proces citeşte dintr-un fişier special (exemple un terminal) şi nu este nici o dată de intrare disponibilă procesul se blochează automat.


fig 2-2. Un proces poate fi in stare de rulare, blocare sau pregatit. Trecerile dintre aceste stari sunt cele din figura
Tranziţiile 2 şi 3 sunt cauzate de administratorul de procese (o parte a sistemului de operare), fără ca nici măcar procesele să ştie despre ele. Tranziţia 2 are loc când administratorul decide că procesul aflat în rulare a rulat suficient de mult şi că este timpul să permită altui proces să aibe pentru un timp acces la procesor. Tranziţia 3 are loc în toate celelalte procese a avut partea lor şi este timpul ca primul proces să aibă acces la procesor pentru a rula din nou. Funcţia administratorului care este de a decide care proces ar trebui să ruleze când şi pentru cât timp, este mai importantă. O vom analiza mai târziu în acest capitol. Mulţi algoritmi au fost divizaţi pentru a încerca să aprecieze cererile competitive de eficienţă pentru sistem, astfel încât toate aceste cereri să fie ca un întreg pentru procesele individuale. Tranziţia a patra are loc când un eveniment extern după care un proces aştepta să se întâmple (ca de exemplu sosirea unor inputuri.) Dacă nici un alt proces nu rulează la momentul respectiv tranziţia 3 va fi pusă în aplicaţie şi procesul va începe să ruleze altfel, s-ar putea să trebuiască să aştepte în starea ready pentru puţin timp până când procesorul este disponibil. Folosind un proces model devine mult mai uşor să ne gândim la ce se întâmplă în interiorul sistemului. Unele procese rulează anume programul care efectuează comenzi tipărite de un utilizator. Alte procese sunt parte dintr-un sistem şi se ocupă de comenzi ca de exemplu: efectuarea cererilor de servicii-fişiere, sau administrarea detalilor pentru rularea unui disc. Când o întrerupere a discului are loc sistemul ia decizii să oprească rularea procesului curent şi să ruleze procesul de disc care era blocat aşteptând aceea întrerupere (de disc) . Astfel în loc să ne gândim la întreruperi ne putem gândi la procesele user, procesele disk, procesele terminal ş.a.m.d. care se blochează când aşteaptă ca ceva să aibă loc. Când blocul disk a fost citit sau caracterul a fost tipărit, procesul care aşteaptă după el este deblocat şi este disponibil să ruleze din nou. Această viziune dă importanţă modelului din figura 2.3. Aici cel mai de jos nivel al sistemului de operare este administratorul (schedulerului) cu o varietate de procese deaasupra lui. Toate întreruperile şi detaliile proceselor ce pornesc şi se opresc sunt ascunse în administrator care este de fapt destul de mic. Restul SO este structurat în mod atrăgător în forma unui proces. Modelulul din figura 2.3. este folosit în MINIX cu înţelegerea că „schedulerul” (administratorul) nu înseamnă doar organizarea proceselor şi de asemenea şi întreruperea şi comunicarea dintre toate procesele. Totuşi ca primă aproximare arată structura de bază.