3.

ARHITECTURA SO
Arhitectura unui sistem software, deci i a sistemului de operare, descrie
componentele sistemului software i relaiile dintre acestea.
Exist mai multe variante de structurare a sistemelor de operare, plecnd de la
sistemele de operare monolitice, nestructurate, pn la SO moderne caracterizate de
arhitecturi complexe.

3.1 Sisteme monolitice

SO monolitice sunt formate din module cu interfee bine definite care specific
parametrii de apel, rezultatul i se pot apela una pe alta fr restricii. SO este construit prin
asamblarea tuturor acestor module (proceduri) i legarea lor ntr-un sigur fiier obiect.
Apelul unui serviciu se face pregtind n prealabil parametrii de apel care precizeaz
serviciul i operaiile solicitate acestuia. Se execut apoi o instruciune special a
procesorului: TRAP care realizeaz comutare procesorului din mod utilizator n mod protejat
(kernel-nucleu). Aceast comutare lanseaz automat modul principal care examineaz
parametrii pentru a determina serviciul solicitat i apeleaz apoi procedura corespunztoare
lansrii serviciului respectiv.
Chiar i sistemele considerate monolitice au o structur intern simpl pe trei nivele.
Primul nivel este cel care conine modulul principal, al doilea nivel este format din procedurile
care implementeaz serviciile SO. Un serviciu poate folosi proceduri comune cu alte servicii
din sistem, astfel nct al treilea nivel conine procedurile partajate de procedurile de pe
nivelul doi.
TRAP + param. pregtii
Modulul
principal

proceduri servicii

proceduri utilitare

Fig.x.x Structura intern a unui sistem monolitic

Se constat c este realizat un prim obiectiv important, cel al separrii implementrii

de interfa. La interfa se ofer posibilitatea de a solicita serviciile ntr-o form unitar,
indicnd numele serviciului i parametrii de apel. Implementrile serviciilor sunt pe nivelele
inferioare i pot fi modificate fr a modifica forma de apel a serviciului. Importana acestui
obiectiv const n asigurarea portabilitii SO pe maini fizice diferite prin realizarea de
modificri minime n implementarea acestuia i fr a afecta interfaa cu nivelele superioare
(software i utilizator).

3.2 Arhitectura multinivel

Modulele SO sunt organizate pe nivele multiple suprapuse vertical. Aceast structur
are la baz separarea funciilor SO i plasarea lor pe nivele diferite.
Un nivel tipic ofer un set de operaii ce pot fi invocate de nivelul superior i poate
invoca la rndul lui operaii ale nivelului inferior.
Niv. N interfaa utilizator

...
Interfaa nivelului k
Nivel intermediar,
cu module ale SO

Nivel k

...

Sistemul de
operare

Interfaa nivelului k-1

Niv. 0 - hardware

O perspectiv mai detaliat a relaiei dintre dou nivele adiacente ilustreaz faptul c
fiecare nivel ofer n general operaii noi, realizate prin utilizarea celor ale nivelului inferior,
dar poate oferi i acces direct la operaii oferite de nivelul inferior.
operaii noi

operaii ascunse ale

nivelului M-1

nivel M
nivel M-1

operaii vizibile ale

nivelului M-1

Caracteristicile acestei arhitecturi sunt modularitatea i invocarea de operaii ntr-un

singur sens, de la nivelul superior ctre cel inferior.
Problema care trebuie soluionat este amplasarea corect a nivelelor n funcie de
relaiile dintre ele. De exemplu, avnd n vedere faptul c memoria virtual utilizeaz un
spaiu de pe disc, este necesar ca ea s acceseze discul prin intermediul driver-ului
corespunztor. De aceea trebuie s-i poat apela funciile, deci trebuie ca driver-ul s fie
plasat pe un nivel inferior.
Manager memorie
Driver disk

Primul SO organizat pe nivele multiple a fost SO, cu prelucrare n loturi de lucrri,

numit THE1. Nivelele erau dispuse conform figurii de mai jos.
operator
Programe utilizator
Manager de I/E
Manager comunicare
Manager memorie
Planificator procese

Un alt exemplu este SO MULTICS care era organizat pe o structur inelar n care
nivelele sunt organizate ca inele concentrice. Operaiile se pot face n ambele sensuri, dar pe
fiecare sens exist anumite restricii de acces funcie de privilegiile pe care le are nivelul
respectiv. Inelul interior are privilegii maxime.

Nivelul cu privilegii maxime

Aceast arhitectur inelar poate fi extins i la nivelele software superioare,

permind evoluia diferitelor componente ale unei aplicaii pe nivele de privilegiu diferite.
Aceast structurare pe nivele multiple are avantajul modularitii, dar o eficien
sczut datorit lanului de apeluri. O operaie de I/E implic un lan de apeluri de la fiecare
nivel la urmtorul, fiecare apel necesitnd pregtirea parametrilor specifici i adugnd
operaii suplimentare2 operaiei globale. De exemplu, Windows NT care utilizeaz o astfel de
arhitectur are performane mai slabe dect Win 95. Totui, prin restructurarea nivelelor,
printr-o mai bun integrare i prin transferarea lor n spaiul Kernel, s-a obinut o cretere
considerabil a performanelor la versiunile ulterioare.

3.3 Arhitectura cu maini virtuale (n sens IBM)

Un SO n regim de timesharing ofer multiprogramare i o main extins cu o
interfa de programare mai simpl dect interfaa hardware. Plecnd de la ideea separrii
acestor dou funcii a fost implementat conceptul de main virtual. Se permite astfel

1
2

Propus de Djikstra.
overhead

reproducerea identic a resursei hardware n instane multiple, astfel c pentru un anume

hardware, un astfel de SO ofer maini virtuale multiple.
Maina virtual este realizat prin soft specializat n gestiunea timpului procesor
(divizat n cuante) i pe implementarea memoriei virtuale (spaii suficiente i independente
de memorare). Utiliznd planificarea proceselor i implementarea memoriei virtuale, un SO
creaz iluzia c fiecare proces are la dispoziie un procesor propriu i o memorie proprie,
deci o main de calcul proprie.
Conceptul de main virtual a fost introdus de sistemele IBM n forma n care maina
virtual ofer o interfa identic cu nivelul hardware inferior, fr a introduce funcionalitate
suplimentar, adic fiecare proces primete o copie virtual a resurselor hardware.
Procesele din sistem partajeaz de fapt aceleai resurse fizice, alocate i gestionate
n mod transparent de ctre software-ul de gestiune a mainilor virtuale. Sisiemul de operare
instalat pe o main virtual poate fi chiar diferit de cel instalat pe o alt main virtual.
La sistemul IBM de maini virtuale, fiecare utilizator execut un SO interactiv
monoutilizator numit CSM (Conversational Monitor System). Componenta software ce
reprezint implementarea conceptului de main virtual este responsabil doar cu
multiprogramarea mainilor virtuale multiple peste o main fizic unic.
API
API

Procese

API

API

procese

procese

procese

SO1

SO2

SOk

MV1

MV2

MVk

SO

Soft gestiune maini virtuale

Hardware

Hardware

(a)

(b)

Fig. X.x Modele de sisteme fr (a) i cu (b) implementarea conceptului de main virtual n sens IBM

3.4 Maina virtual Java (JVM)

Arhitectura JVM este oarecum diferit de modelul mainii virtuale n sens IBM care
reproduce identic resursele hardware. JVM este o specificaie pentru un calculator abstract.
Gestiunea memoriei este realizat conform unui model corespunztor lucrului cu obiecte.
Alocarea memoriei se face conform acestui model, iar eliberarea se face automat, utiliznd
un mecanism pentru colectarea spaiilor eliberate, numit garbage collector.
Structura JVM este reprezentat n figura urmtoare.

Fiiere cu cod Java executabil (bytecode)

ncrctor (class loader)
Verificator (verifier)

Fig.x.x
Maina virtual Java

Interpretor (java interpreter)

Sistem gazd

Modulul ncrctor ncarc n sistemul gazd fiierele ce conin cod Java executabil
(*.class) ale aplicaiei i ale bibliotecilor utilizate de aceasta.
Modulul de verificare este responsabil cu corectitudinea codului din fiierele ncrcate,
verificnd totodat i faptul c nu se depete capacitatea stivei.
Interpretorul este modulul care execut codul. El poate fi un modul software care
interpreteaz instruciune cu instruciune acest cod, sau poate fi un compilator JIT (just in
time) care transform codul n limbajul nativ al mainii gazd i care asigur astfel o
cretere a performanei. Cele mai performante execuii de cod Java au loc pe procesoarele
fizice care implementeaz hardware interpretorul Java.
Ansamblul acestor module realizeaz adaptarea codului executabil Java (bytecode) la
diferite sisteme gazd, asigurnd astfel independena i portabilitatea sa. Pentru aceasta
exist implementri ale JVM pentru diferite platforme hard-soft. O platform hard-soft este
caracterizat de procesor i de sistemul de operare instalat. JVM ofer programelor Java o
interfa independent de arhitectura platformei.
n concluzie, JVM ofer o main virtual pentru limbajul Java. Aceasta este un
context de execuie a programelor Java care le ofer securitate, eficien, orientare obiect,
portabilitate i independen de platform.

3.5 Arhitectura microkernel

Extinznd ideea de separare a funciilor sistemului de operare, arhitectura microkernel
se bazeaz pe separarea funciilor n servicii specializate ale SO, cu preluarea lor ca
procese n spaiul utilizator, i n funcii minimale ce implementeaz mecanismele utilizate de
aceste servicii, implementate ntr-un nucleu redus al SO (microkernel). Altfel spus, nucleul
SO este modularizat i o parte din aceste module sunt transferate spre executare ca i
procese de tip server n spaiul utilizator. Nucleul este redus astfel la funcii de gestiune
minimal a proceselor, memoriei i facilitilor de comunicare.
Aceast arhitectur este bazat pe paradigma client-server i este reprezentat n
fig.Xx.

proces server terminal

procese client

proces server memorie

proces server fiiere
spaiul utilizator

microKernel

spaiul nucleu

Fig.x.x Separarea i repartizarea funciilor SO mtr-o arhitectur cu microkernel

Apelul unui serviciu din spaiul utilizator de ctre un proces client se face prin
intermediul componentei microkernel, avnd la baz un mecanism pentru transfer de
mesaje.
Serviciu SO n
spaiul utilizator

Proces client

microkernel

Fig.x.x Apelul unui serviciu SO, n arhitectura microkernel

Aceast arhitectur asigur sistemului de operare extensibilitate cu noi servicii

adugate n spaiul utilizator, actualizri mai puin laborioase la nivelul unui nucleu minimal,
deci o adaptare mai uoar la diferite arhitecturi hardware, portabilitate mai bun, securitatea
serviciilor i disponibilitatea lor prin posibiliti de implementare tolerante la erori (ex.
replicare).
Sistemul de operare Apple MacOS Server este bazat pe microkernel, ca i sistemul
de operare pentru timp real QNX. La acesta din urm microkernel-ul asigur transferul de
mesaje, planificarea proceselor, gestiunea comunicrii n reea i a ntreruperilor hardware.
Sistemul de operare Windows are o structur hibrid i poate rula aplicaii scrise
pentru diferite interfee de programare (API), anume Win32 pentru aplicaii Windows native),
OS/2 sau POSIX. Pentru fiecare API, SO ofer un serviciu specializat accesibil prin
microkernel.
Client
aplicaie
Win32

Aplicaie POSIX

Aplicaie Win32

Server Win32

Server OS/2

Aplicaie POSIX

Server POSIX

kernel

Fig.x.x Arhitectura unui sistem de calcul cu sistem de operare Windows

n fig. anterioar este ilustrat arhitectura unui sistem software compus din SO
Windows, aplicaii instalate pe acesta i clieni ai acestor aplicaii. Fiecare tip de aplicaie
utilizeaz un server corespunztor tipului su, server ce se execut n spaiul utilizator i
care este accesat prin intermediarea nivelului kernel al SO.
Un alt avataj major al arhitecturilor cu microkernel este acela al extensibilitii acestora
la sistemele distribuite. n acest caz modulul microkernel include i funcia de transfer n
reea, iar mecanismul de comunicare ntre componente este acelai mecanism de transfer
de mesaje. n figura de mai jos se observ utilizarea mai multor calculatoare legate n reea
pentru a asigura funciile unui sistem distribuit. Pe fiecare main se instaleaz
componenente microkernel identice pentru a se crea un sistem unitar.
Maina 1

Maina k

Maina k+1

Maina n

Client

Server fiiere

Server procesare

Server terminal

microkernel

microkernel

microkernel

microkernel

3.6 Exemple
3.6.1 Structura unui sistem de tip UNIX
Spaiul utilizator
SHELL

Proces utilizator

Proces utilizator

Interfa apeluri sistem

Spaiul kernel
Sistemul de fieiere
Bloc memorie
intermediar

Driver-e dispozitive

Hardware

Gestiunea proceselor

IPC

Planificare

Semnale

Gestiunea memoriei

3.6.1 Structura unui sistem de tip Windows

Aplicaie Win32

Spaiul utilizator
Subsistem POSIX

Subsistem Win32

Subsistem OS/2

Interfa sistem

Spaiul kernel

Sistemul
de
fiiere

Securitate

Procese i fire
de execuie

Memorie
virtual

Memorie cache
pentru fiiere

I/E

Executiv

Serviciile sistem

Win32 i interfaare grafic

Gestiunea obiectelor

Drivere dispozitive

Microkernel

Nivel abstract hardware

Hardware

4. PROIECTAREA, IMPLEMENTAREA I GENERAREA SO

4.1 Cerinele de proiectare
Ca pentru orice sistem software, prima etap n proiectarea unui sistem de operare
este definirea cerinelor i specificaiilor acestuia.
Prima influen major n proiectarea unui SO o are alegerea componentelor
hardware i a tipului de sistem (cu loturi de lucrri sau cu partajare timp, mono/multi
utilizator, distribuit, de timp real, etc.).
Cerinele de proiectare impuse unui sistem de operare pot fi mprite n dou
categorii: cerine utilizator i cerine sistem.
ntre cerinele utilizator se afl uurina n utilizare, simplitate, disponibilitate, siguran
i rspuns ct mai rapid. n aceeai categorie se consider i cerinele impuse de
dezvoltatori, cum ar fi uurina de a realiza proiectarea, implementarea i ntreinerea
sistemului, flexibilitatea acestuia, eficiena i lipsa erorilor.
Aceste cerine sunt destul de generale i exist soluii multiple pentru ndeplinirea lor.

4.2 Mecanism i politic

Pentru a susine proiectrea unui sistem de operare exist o serie de principii ale
ingineriei software speciale acestui tip de sisteme.
Un principiu foarte important n acest sens este cel al separrii politicii de mecanism.
Mecanismele determin modul n care se realizeaz o anumit funcie iar politica definete
ceea ce va realiza acea funcie. De exemplu, un mecanism de temoprizare va lansa
ntreruperi la un interval prestabilit, pe cnd politica asociat acestuia va preciza durata
intervalului respectiv.
Aplicarea principiului separrii politicii de mecanism conduce la creterea gradului de
flexibilitate a sistemului. Pentru toate problemele de alocare de resurse i de planificare de
activiti, SO trebuie s ia decizii politice. n plus, politicile sunt supuse schimbrilor cu o
dinamic neneglijabil. Dac se aplic acest principiu i se generalizeaz un anume
mecanism, politica asociat acestuia poate fi redefinit fr modificarea mecanismului ci
doar prin transmiterea de parametrii cu valori diferite ctre acesta.
SO bazate pe microkernel duc la extrem separarea politicii de mecanism prin
implementarea unui set de blocuri primitive pentru construirea sistemului. Aceste blocuri
implementeaz doar mecanisme i permit adugarea de mecanisme i politici avansate n
module create de utilizator. La extrema cealalt se afl SO Apple Macintosh, n care politicile
i mecanismele sunt codificate n sistem pentru a oferi o perspectiv global a acestuia; de
exemplu, toate aplicaiile au interfee similare doarece interfaa este o component a SO.

4.3 Implementarea SO
SO sunt implementate n mod tradiional n limbaj de asamblare. SO moderne sunt
ns dezvoltate n limbaje de nivel superior, cum ar fi C i C++.
Avantajele utilizrii limbajelor de nivel superior sunt legate de uurina crescut n
programare, structurarea compact a codului, faptul c acesta este mai uor de neles i de
depanat. n plus, evoluiile tehnologice n domeniul compilatoarelor mbuntesc generarea
codului pentru ntreg sistemul de operare prin simpl recompilare. De asemena, un SO
dezvoltat ntr-un limbaj independent de procesor poate fi portat, cu adaptri minime, pe
diferite maini fizice.
Dezavantajele acestei abordri se refer la o vitez de execuie mai redus i la
cerina pentru capaciti de memorare mai mari. Aceste dezavantaje pot fi ns compensate
pe de o parte de tehnicile de optimizare a execuilor oferite de compilatoare i de procesoare
i pe de alt parte de posibilitatea de a utiliza structuri de date i algoritmi performani. n
plus, se poate msura timpul de execuie a unor secvene de cod n raport cu altele. Mai
genereal, tot prin msurtori asupra timpilor de execuie se pot determina zonele n care se
produc gtuiri ale execuiilor. S-a observat c n jur de 80% din timpul procesor se
consum pe aprox. 20% din codul programelor, deci se va aciona la acele secvene de cod
cu timpi mari de execuie i dimensiuni reduse ale codului n sensul rescrierii lor n limbaj de
asamblare.
Prin calcularea i afiarea rezultatelor msurtorilor de performan, administratorul
are la dispoziie detalii despre comportamentul diferitelor componente ale sistemului i poate
lua decizii de modificare a acestuia n timp real.

4.4 Generarea sistemului de operare

Un sistem de operare este proiectat i apoi implementat ntr-o manier flexibil astfel
nct s poat fi executat pe diferite arhitecturi hardware. SO trebuie configurat (sau generat)
pentru fiecare calculator pe care se instaleaz.