Curs 4

Arhitectura sistemelor de operare

Gestiunea proceselor

Sisteme de operare
Lect. Dr. Ozten CHELAI

Facultatea de Matematica si Informatica

Universitatea Ovidius Constanta

Curs2 SO - lect. dr. Ozten Chelai, 2009-2010 1

Arhitectura SO

descrie componentele sistemului software şi
relaŃiile dintre acestea

Există mai multe variante de structurare a
sistemelor de operare:

sistemele de operare monolitice,

Sisteme de operare multinivel,

Sisteme de operare microkernel

SO moderne caracterizate de arhitecturi
complexe
 Sisteme monolitice

SO monolitice sunt formate din module cu interfeŃe bine definite care specifică parametrii
de apel, rezultatul şi se pot apela una pe alta fără restricŃii

SO este construit prin asamblarea tuturor acestor module (proceduri) şi legarea lor într-
un singur fişier obiect

Apelul unui serviciu se face

pregătind în prealabil parametrii de apel care precizează serviciul şi operaŃiile solicitate acestuia

Se execută apoi o instrucŃiune specială a procesorului: TRAP care realizează comutarea
procesorului din mod utilizator în mod protejat (kernel-nucleu).

Această comutare lansează automat modulul principal care examinează parametrii pentru a
determina serviciul solicitat şi apelează apoi procedura corespunzătoare lansării serviciului respectiv

Desi e considerat monolitic, structura interna este pe trei nivele.

Primul nivel este cel care conŃine 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 încât

al treilea nivel conŃine procedurile partajate de procedurile de pe nivelul doi.

este realizat un prim obiectiv important, cel al separării implementării de interfaŃă. La interfaŃă se
oferă posibilitatea de a solicita serviciile într-o formă unitară, indicând numele serviciului şi
parametrii de apel. Implementările serviciilor sunt pe nivelele inferioare şi pot fi modificate fără a
modifica forma de apel a serviciului. ImportanŃa acestui obiectiv constă în asigurarea portabilităŃii
SO pe maşini fizice diferite prin realizarea de modificări minime în implementarea acestuia şi fără a
afecta interfaŃa cu nivelele superioare (software şi utilizator).
TRAP + param. pregătiŃi
Modulul
principal

proceduri servicii

proceduri utilitare

Fig.x.x Structura internă a unui sistem monolitic

Arhitectura multinivel (stratificata)

Modulele SO sunt organizate pe nivele multiple suprapuse vertical. Această structură are la bază
separarea funcŃiilor SO şi plasarea lor pe nivele diferite.

Un nivel tipic oferă un set de operaŃii ce pot fi invocate de nivelul superior şi poate invoca la rândul
lui operaŃii ale nivelului inferior.

Caracteristicile acestei arhitecturi sunt modularitatea şi invocarea de operaŃii într-un singur sens, de la
nivelul superior către cel inferior.Manager memorieDriver disk

Problema care trebuie soluŃionată este amplasarea corectă a nivelelor în funcŃie de relaŃiile dintre ele.
De exemplu, având în vedere faptul că memoria virtuală utilizează un spaŃiu de pe disc, este necesar ca
ea să acceseze discul prin intermediul driver-ului corespunzător. De aceea trebuie să-i poată apela
funcŃiile, deci trebuie ca driver-ul să fie plasat pe un nivel inferior.

Primul SO organizat pe nivele multiple a fost SO, cu prelucrare în loturi de lucrări, numit THE (propus de
Djikstra). Nivelele erau dispuse conform figurii de mai jos.
operator
Programe utilizator
Manager de I/E
Manager comunicare
procese-operator
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. OperaŃiile se pot face în ambele sensuri, dar pe fiecare sens există
anumite restricŃii de acces funcŃie de privilegiile pe care le are nivelul respectiv. Inelul interior are privilegii
maxime.

Această structurare pe nivele multiple are avantajul modularităŃii, dar o eficienŃă scăzută datorită
lanŃului de apeluri. O operaŃie de I/E implică un lanŃ de apeluri de la fiecare nivel la următorul, fiecare
apel necesitând pregătirea parametrilor specifici şi adăugând operaŃii suplimentare (overhead) operaŃiei
globale. De exemplu, Windows NT care utilizează o astfel de arhitectură are performanŃe mai slabe
decât Win 95. Totuşi, prin restructurarea nivelelor, printr-o mai bună integrare şi prin transferarea lor în
spaŃiul Kernel, s-a obŃinut o creştere considerabilă a performanŃelor la versiunile ulterioare.
 Masina virtuala

Un SO în regim de timesharing oferă multiprogramare şi o maşină extinsă cu o interfaŃă de
programare mai simplă decât interfaŃa hardware.=>ideea separării acestor două funcŃii => a fost
implementat conceptul de maşină virtuală(reproducerea identică a resursei hardware în instanŃe
multiple). Un astfel de SO oferă maşini virtuale multiple.

Utilizând planificarea proceselor şi implementarea memoriei virtuale, un SO crează iluzia că
fiecare proces are la dispoziŃie un procesor propriu şi o memorie proprie, deci o maşină de calcul
proprie.

Conceptul de maşină virtuală a fost introdus de sistemele IBM în forma în care maşina virtuală oferă
o interfaŃă identică cu nivelul hardware inferior, fără a introduce funcŃionalitate suplimentară, adică
fiecare proces primeşte o copie virtuală a resurselor hardware.

Procesele din sistem partajează de fapt aceleaşi resurse fizice, alocate şi gestionate în mod
transparent de către software-ul de gestiune a maşinilor virtuale. Sisiemul de operare instalat pe o
maşină virtuală poate fi chiar diferit de cel instalat pe o altă maşină virtuală.

La sistemul IBM de maşini virtuale, fiecare utilizator execută un SO interactiv monoutilizator numit
CSM (Conversational Monitor System). Componenta software ce reprezintă implementarea
conceptului de maşină virtuală este responsabilă doar cu multiprogramarea maşinilor virtuale
multiple peste o maşină fizică unică.
API API API

API
procese procese procese
SO1 SO2 SOk
Procese MV1 MV2 MVk
SO Soft gestiune maşini virtuale
Hardware Hardware

(a) (b)
a) a)
Fig. X.x Modele de sisteme fără (a) şi cu (b) implementarea conceptului de maşină virtuală în sens IBM
Arhitectura microkernel

Extinzând ideea de separare a funcŃiilor sistemului de operare, arhitectura microkernel se
bazează pe separarea funcŃiilor în servicii specializate ale SO, cu preluarea lor ca
procese în spaŃiul utilizator, şi în funcŃii 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 spaŃiul utilizator. Nucleul este redus astfel la
funcŃii de gestiune minimală a proceselor, memoriei şi facilităŃilor de comunicare.

Această arhitectură este bazată pe paradigma client-server şi este reprezentată în fig.Xx.
Serviciu SO în
Proces client spaŃiul utilizator

microkernel

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

proces server terminal
procese client proces server memorie

proces server fişiere

spaŃiul utilizator

microKernel spaŃiul nucleu

Fig.x.x Separarea şi repartizarea funcŃiilor SO îmtr-o arhitectură cu microkernel

Această arhitectură asigură sistemului de operare extensibilitate cu noi servicii adăugate

în spaŃiul utilizator, actualizări mai puŃin laborioase la nivelul unui nucleu minimal, deci o
adaptare mai uşoară la diferite arhitecturi hardware, portabilitate mai bună, securitatea
serviciilor şi disponibilitatea lor prin posibilităŃi de implementare tolerante la erori (ex.
replicare). Exemple: Apple MacOS Server , QNX.
Structura SO de tip UNIX

SpaŃiul utilizator
SHELL Proces utilizator Proces utilizator

InterfaŃă apeluri sistem

SpaŃiul kernel
Sistemul de fişeiere Gestiunea proceselor

Bloc memorie
intermediară IPC Planificare

Driver-e dispozitive Semnale Gestiunea memoriei

Hardware
Structura unui SO de tip
Windows

SpaŃiul utilizator AplicaŃie Win32

Subsistem POSIX Subsistem Win32 Subsistem OS/2

InterfaŃă sistem
SpaŃiul kernel
Ex Serviciile sistem
ec
uti I/E Mem Mem Proc Se
v orie orie ese cu
cach virtu şi rit
e ală fire at
pentr de e Win32 şi interfaŃare grafică
u exec
fişier uŃie
Sistemul Gestiunea
e obiectelor
de
fişiere

Drivere dispozitive Microkernel

Nivel abstract hardware

Hardware
Gestiunea proceselor.
Procesul

Proces= program in executie

Fiecarui proces i se asociaza:

un spatiu de memorie (program, date si stiva)

Un set registri (PC, SP, etc.) necesari executiei programului

Spatiu de intrare/iesire - fisiere

SO controleaza executia proceselor: care, cand se suspenda/pornesc si corespunzator
salveaza/restaureaza contextul de executie.

La multe SO, exista un tabel de procese (process table) cu informatii despre procese.

Un proces poate crea mai multe procese (copii) care pot crea procese copii => se obtine o structura
arborescenta de procese.

Procesele inrudite trebuie sa comunice ca sa-si sincronizeze operatiile.

Comunicarea intre procese se realizeaza prin mesaje si utilizand timeouturi (semnale)

apelurile sistem – se ocupa cu gestiunea sistemului (initierea/terminarea proceselor)

Exemplu:

un proces shell (interpretor de comenzi) citeste comenzile de la terminal.

Utilizatorul introduce o comanda: compilare program

Interpretorul creaza un proces care sa ruleze compilatorul

Cand procesul termina compilarea, executa un apel sistem pentru a se opri.

Alte apeluri sistem sunt pentru pentru a solicita mai multa memorie sau pentru a elibera memoria
neutilizata, pentru a astepta un proces copil sa-si termine activitatea, pentru a inlocui programul de
executat cu altul

Fiecare persoana primeste un UID (User Identification),

fiecare proces care porneste contine UID-ul persoanei care l-a declansat.

Un proces copil are acelasi UID cu procesul care l-a declansat.

Utilizatorii pot fi membri unui grup GID (Group Identification)

Un super-utilizator are drepturi depline in sistem
Starile proceselor

Starea unui proces reprezintă activitatea sa curentă.

Starile proceselor sunt:

proces nou – stare rezultată după crearea sa sub controlul SO

proces în execuŃie – instrucŃiunile procesului sunt executate de procesor

proces blocat – procesul nu poate continua fiind blocat în aşteaptarea apariŃiei unui
eveniment (ex. încheierea unei operaŃii de I/E lansată anterior)

proces ready – procesul poate continua în momentul în care primeşte acces la
procesor

proces terminat – procesul şi-a încheiat execuŃia.

Pe parcursul execuŃiei sale procesul execută tranziŃii între diferite stări.
Comutarea controlului între procese şi sistemul de
operare

În sistemele cu monoprogramare

controlul e preluat de SO la lansarea de către proces a unei instrucŃiuni OSML pentru realizarea
unei operaŃii de I/E,

până la încheierea operaŃiei de I/E comandată de proces, procesorul înregistrează timpi morŃi.

În sistemele cu multiprogramare în loturi de lucrări

controlul e preluat de SO la lansarea de către procesul activ din sistem a unei instrucŃiuni OSML
pentru realizarea unei operaŃii de I/E,

până la încheierea operaŃiei de I/E comandată de un proces SO predă controlul altui proces existent
în sistem,

un proces deŃine controlul asupra procesorului până se termină sau până lansează o operaŃie de
I/E prin intermediul unei instrucŃiuni OSML.

În sistemele cu multiprogramare cu partajarea timpului (timesharing)

timpul procesor e împărŃit in cuante egale, ce vor fi atribuite, în mod echitabil, proceselor din sistem.

controlul e preluat de SO la lansarea de către procesul activ din sistem a unei instrucŃiuni OSML
pentru aşteptarea unui eveniment (lansarea unei operaŃii de I/E şi aşteptarea încheierii acesteia,
aşteptarea unor date ce trebuie furnizate de către alt proces din sistem sau aşteptarea eliberării unei
resurse ocupată de alt proces din sistem) sau la apariŃia unei intreruperi de la dispozitivul de
temporizare ce măsoară cuantele de timp procesor,

până la apariŃia evenimentului necesar continuării acestui proces, SO predă controlul altor procese
existente în sistem, conform unui algoritm de atribuire a cuantelor de timp procesor (planificare).

un proces deŃine controlul asupra procesorului până îi expiră timpul procesor alocat sau până
lanseaza o operaŃie OSML de aşteptare a unui eveniment.
Multiprogramarea

DefiniŃie: Comutarea între execuŃia mai multor procese, supervizată de sistemul de operare.

Multiprogramarea presupune existenŃa în sistem a n procese ce se execută în paralel.

Variante

Sistem de calcul cu n procesoare fizice => paralelism real, fizic

Sistem de calcul cu 1 procesore fizic => paralelism simulat

Sistem de calcul cu p (<n>)procesoare fizice =>paralelism parŃial real, parŃial simulat(hibrid)

Modelul paralelismului proceselor într-un sistem cu multiprogramare

Într-un sistem cu multiprogramare întregul software, inclusiv sistemul de operare, este
organizat sub forma unei colecŃii de procese secvenŃiale, fiecare fiind executat pe un procesor
virtual propriu.

n PC - uri

contoare program P2P1P3. . .PnFig.3.3 Modelul conceptual pentru n procese
secvenŃiale

Conform acestui model, SO are o componenta - planificatorul de procese – ce oferă restului de
componente software din sistem (inclusiv celorlalte module ale sistemului de operare) atâtea maşini
virtuale de nivel 3 câte procese sunt lansate în sistem.

Conform acestui model componenta software a unui sistem de calcul e alcătuita din procese
paralele, fiecare având la dispoziŃie un procesor virtual propriu caracterizat de un contor program
(PC-program counter) păstrat într-un registru special al procesorului (IP-instruction pointer).

P P P
1 2 n

n MV3
maşini virtuale
de nivel 3
PLANIFICATORUL DE PROCESE

Hardware ( p procesoare, memorii,

dispozitive de I/E)
Fig.3.2 Modelul paralelismului (parŃial) simulat

Comutarea de context

Comutarea procesorului de la un proces P1 la altul P2 , necesită salvarea stării
procesului P1 urmată de încărcarea stării procesului P2. Această operaŃe se
numeşte comutare de context. Contextul unui proces este reprezentat de valorile din
regiştrii procesorului, starea procesului şi informaŃiile de alocare a memoriei. La o
comutare de context SO salvează starea procesului P1 în intrarea corespunzătoare
acestuia din tabela proceselor. Încarcă apoi, din intrarea corespunzătoare lui P2,
starea acestuia. Odată cu încărcarea contorului program al unui proces în registrul IP
are loc continuarea execuŃiei procesului refăcut de la punctul în care fusese întrerupt
anterior. În perioada de realizare a comutării între procese nu se execută operaŃii utile
la nivelul utilizator, acest timp fiind considerat “overhead”. Durata lui depinde de
caracteristicile calculatorului şi are valori între 1-1000 microsec. Depinde, de
asemenea, şi de complexitatea SO. Utilizarea firelor de execuŃie duce la creşterea
performanŃelor sistemului şi datorită evitării comutării de context.

Crearea unei ierarhii de procese

Procesele paralele ce se execută într-un sistem cu multiprogramare sunt organizate
ierarhic, pe modelul părinte-descendent.

Ierarhia proceselor se poate crea:

static – procesele sunt încărcate şi lansate automat imediat după lansarea sistemului de
operare,

dinamic –procesele sunt create în timp, având rădăcina într-un proces iniŃial încărcat
odată cu sistemul de operare,

hibrid – unele procese sunt încarcate odată cu sistemul de operare, altele sunt generate
dinamic de procese existente la un moment dat în sistem.

Ierarhia de procese seamănă cu cea a directorilor într-un sistem de fişiere dar se
diferenŃiază în mod semnificativ aceasta prin:

grad superior de dinamism

număr mult mai mic de nivele ( în general, max.4)
Apeluri sistem pentru gestiunea
proceselor

Un proces este identificat, la nivelul sistemului de operare, printr-un
număr unic, numit PID (process identifier).

Crearea unui proces descendent presupune clonarea procesului
părinte. Ulterior procesului descendent i se va ataşa un program
propriu.

Apelurile implementate de SO Linux

fork() – creare proces descendent prin clonarea procesului părinte.

apelul întoarce:

val < 0 daca nu s-a putut crea noul proces (ex. resurse insuficiente)

val=0 procesului descendent creat

val>0 procesului părinte.

Valoarea numerică val reprezintă PID-ul procesului descendent creat.

exec(nume_fisier_executabil,parametri_liniei_de_comanda,variabile_de_co
ntext)

- lansare program

exit() – încheiere proces

wait(), waitpid(pid) – aşteptarea încheierii unei operaŃii sau a unui proces
identificat prin pid

getpid() – aflarea PID-ului procesului curent

kill(pid, sig) / sigaction(sig) – lansare/capturare semnal

alarm(time) / sigalarm – lansare/capturare semnal cu temporizare
 Procese. Exemple de creare

Exemplu de creare a unui proces descendent:
 pid = fork();
 if pid < 0
 {/* mesaj de eroare */
 exit;}
 if pid = 0
 {/*cod proces descendent*/}

 else
 {/* cod proces parinte */}
 End

Alt exemplu

#include <stdio.h>

void main(int argc, char *argv[])

{

int pid;

// generare proces descendent prin clonare proces părinte

pid = fork();

if (pid < 0)

{

fprintf(stderr, “Eroare FORK”);

exit(-1);

}

else if (pid == 0)

/* lansare execuŃie descendent prin indicarea programului ce trebuie încărcat, lista de parametri de
lansare ai acestuia şi lista valorilor variabilelor de context*/

exec(“/bin/ls”,”ls”,NULL);

else

/* proces părinte ce aşteaptă încheierea execuŃiei descendentului identificat prin pid*/

waitpid(pid);

printf(“Finalizare executie descendent”);

exit(0);

}

}