Aritoni Ovidiu Sisteme de operare 1 Introducere

D. Modelul client-server

UM / 370 câştigă mult în simplitate mutând o mare parte a codului de operare tradiţional (suplementarea maşinii extinse) într-un strat superior, CMS. Totuşi, VM 370 însuşi este încă un program complex deoarece simularea unui 370 nu este aşa de simplă (în special dacă vrei să faci acest lucru eficient). Tendiţa în sistemele de operare moderne este de a aduce această idee a mutării codului în straturile superioare, mai departe şi să o îndepărteze de sistemul de operare, lăsând un Kernel minim. Maniera uzuală este de a implementa majoritatea funcţiilor sistemelor de operare în procesele user. A cere un serviciu ca de exemplu să citeşti un bloc de fişiere, un proces user (acum cunoscut ca proces client) trimite o cerere la proces client) trimite o cerere la procesul server, care apoi face munca şi trimite înapoi răspunsul.

fig 1-20. Modelul client-server
În acest model arătat în figura 1.20 tot ce face Kernelul este să asigure comunicarea dintre clienţi şi servere. Împărţind sistemele de operare în diferite părţi dintre care fiecare doar se ocupă de o singură faţetă a sistemului ca de exemplu serviciul de fişier, serviciul de proces, serviciul terminal sau serviciul de memorie, fiecare parte devine mică şi uşor de administrat. Mai departe pentru că toate servele rulează ca procese user şi nu în mod Kernel nu au acces direct la hardware. Ca şi consecinţă dacă un bug este în serverul de fişiere, serviciul de fişiere se poate prăbuşi, dar aceasta de obicei nu distruge întreaga maşină.

Alt avantaj al modelului client server este adaptabilitatea lui la folosirea sistemelor distribuite. Dacă un client comunică cu un server trimiţându-i mesaje, clientul nu e nevoie să ştie dacă mesajul este analizat local, sau în propria sa maşină sau dacă a fost trimis prin reţea la un server pe o maşină izolată. În ceea ce îl priveşte pe client acelaşi lucru se întâmplă în ambele cazuri:

O cerere este trimisă şi un răspuns se întoarce


fig 1-21. Modelul client-server intr-un sistem distribuit
Imaginea de mai sus a Kernelului care se ocupă doar de transmiterea mesajului de la clienţi la servere şi înapoi nu este complet reală. Anumite funcţii ale sistemelor de operare (ca de exemplu încărcarea comenzilor în registre fizice de I/O) sunt dificil dacă nu chiar imposibil de realizat de la un program user la altul. Există 2 căi de a trata această problemă, una este de a avea câteva procese critice pe server (ca de exemplu driverele de intrare-ieşire de fapt rulate în modul Kernel) cu acces complet la totul hardul dar care încă comunică cu alte procese folosind mecanismul normal de transmitere a mesajelor. Cealaltă cale este de a construi o cantitate minimă de “mecanism” (algoritm) în Kernel dar să lase totuşi deciziile de tip policy la îndemnarea servelor în spaţiul user. De exemplu Kernelul ar putera recunoaşte că un mesaj trimis la o anumită adresă înseamnă să ia conţinutul acelui mesaj şi să îl încarce în registre de I/O pentru un disc, cu scopul de a porni citirea discului. În acest exemplu Kernelul nici măcar nu ar inspecta biţi din mesaj să vadă dacă sunt valizi sau nu, pur şi simplu i-ar copia în regiştrii discului (desigur trebuie folosite anumite scheme pentru limitarea a astfel de mesaje doar către procesele autorizate) Despărţirea dintre mecanisme şi policy este un concept important şi se repetă continuu în sistemele de operare în diferite contexte.

Procese

1.Introducere

Majoritatea calculatoarelor moderne pot să efectueze în acelaşi timp mai multe lucruri. În timp ce rulează un program utilizator, calculatorul poate de asemenea să citescă de pe disc sau să afişeze un text pe ecran sau la imprimantă. În sistemele multiprogramare, CPU de asemenea întrerupe program după program, rulându-l pe fiecare câteva sute de milisecunde. În timp ce, strict vorbind, la orice moment al timpului CPU rulează un singur program, în decurs de 1 secundă, el efectuează o mulţime de programe, oferind iluzia utilizatorilor de paralelism. Uneori oamenii vorbesc de pseudoparalelism pentru a înţelege acestă schimbare înainte şi înapoi a CPU între programe, în contrast cu adevăratul paralelism Hardware a sistemelor multiprocesor (care au 2 sau mai multe CPU distribuite la aceeaşi memorie). Activităţile paralele sunt greu de efectuat de către oameni deoarece au consecinţe multiple. Prin urmare, designul SO a evoluat de-a lungul anilor la un model care face

A. Modele de procese

În acest model tot softul care rulează pe computer deseori incluzând şi sistemul de operare este organizat într-un număr mare de procese secvenţiale sau pe scurt procese. Un proces este doar un program în execuţie incluzând valorile curente ale programului de contabilizare a numărului registrele şi variabilelor. Conceptual vorbind fiecare proces are propriul său procesor virtual. În realitate, desigur procesorul real se schimbă înapoi şi înainte de la proces la proces, dar pentru înţelegerea sistemului este mult mai uşor să te gândeşti la o colecţie de procese rulând în paralel (pseudoparalelism) decât să încerci să ţii urma felului cum un procesor se schimbă de la program la program. Această schimbare rapidă înapoi şi înainte este numită multiprogramare aşa cum am văzut în capitolul precedent.

În figura 2.1 (a) noi observăm multiprogramându-se patru programe în memorie. În figura 2.1. (b) vedem 4 procese, fiecare cu propriul său control. (Exemplu: Propriul său program de contabilizare), şi fiecare rulând independent unul de altul. În figura 2.1. (c) noi observăm că privită după un interval de timp au făcut procese dar la un moment dat de fapt doar un proces rulează.

fig 2-1. (a) Multiprogramarea a 4 programme.

(b) Model conceptula a 4 procese independente,secventiale

(c) In orice moment exista un singur program activ

Cu un procesor trecând înapoi şi înainte printre procese, rata la care un proces îşi realizează calculele nu valorifică şi probabil nici măcar nu poate fi reprodusă dacă aceleaşi procese rulează din nou. Astfel procesele nu trebuie programate cu presupuneri de timp implementate. Să considerăm de exemplu un proces de I/O care începe o porţiune de program pentru a reabilita fişierele de tip back-up, execută unn ciclu de 10.000 pentru a reveni la viteza iniţială şi apoi generează o comandă pentru a citi prima înregistrare. Dacă procesorul decide să treacă la un alt proces in timpul ciclului porţiunea de proces s-ar putea să nu ruleze din nou decât după ce prima înregistrare a trecut de capul de citire. Când un proces are cerinţe critice de timp real ca acesta, ca de exemplu anumite evenimente trebuie să se întâmple într-un număr specificat de milisecunde, măsuri speciale trebuie luate pentru a fi sigur că ele se întâmplă. Oricum multe procese nu sunt afectate de multiprogramarea fundamentală a procesorului, sau de viteza relativă a diferitelor procese.

Diferenţa dintre un proces şi un program este subtilă dar crucială. O anaologie ne poate ajuta să clarificăm această idee. Să considerăm un analist programator cu înclinaţii spre gastronomie care pregăteşte, o prăjitură pentru ziua ficei lui. Reţeta pentru prăjitură cu o bucătorie bine dotată cu toate de intrare necesare: făină, ouă, zahăr, vanilie, ş.a.m.d. În această analogie reţeta este programul (un algoritm exprimat într-un limbaj potrivit), programatorul este procesorul şi ingredientele pentru prăjitură sun datele de intrare. Procesorul este activitatea ce constă in bucătarul care citeşte reţeta , aduce ingredientele şi prepară prăjitura.

Acum imaginaţi-vă că fiul programatorului intră în fugă plângând spunând că a fost înţepat de o albină. Programatorul înrregistrează unde a rămas în relizarea reţelei (starea procesorului curent este salvată), scoate o carte de prim ajutor şi începe să urmeze instrucţiunile din ea. Aici observăm cum procesorul trece de la un proces (pregătirea prăjiturii) la un proces care are prioritate. (administrarea ajutorului medical) fiecare având un program diferit (reţeta cărţii de prim ajutor) când înţepătura de albină a fost îngrijită, programatorul se întoarce la prăjitură de la momentul în care a rămas. Ideea cheie aici este că un proces este o activitate de un anumit fel. Are un program, date de intrare, date de ieşire şi un status. Un singur procesor poate fi împărţit între câteva procese, cu un anumit algoritm – scheduling fiind folosit să determine momentul opririi lucrului la un proces pentru a lucra la altul.

•