sisteme de operare cc

Conf.dr. Teodor-Florin Forti

#4-5

Informatii de baza

after A.S.Tanenbaum, Modern Operating Systems, 3rd edition

Cum poate fi definit un proces?

Care este mecanismul de realizare a multiprogramrii?


Un proces este un program in executie, impreuna cu valorile asociate acestuia;

Un sistem poate pastra la un moment dat mai multeprocese, incluzand si sistemul de operare;

Sistemul de operare ofera mecanismele necesare pentruoperatia de comutare de proces, ascunzand executiasecventiala a proceselor in spatele iluziei de paralelism;

Multiprogramarea este bazata pe operatia de comutare a proceselor;

Prin aceasta operatie, procesorul poate fi oferit alternativfiecarui proces;

Ce presupune operaia de comutare de context?

Care sunt factorii care pot influena realizarea acestei operaii?


In cazul operatiei de comutare de proces, vor fiavute in vedere limitarile hardware existente: De regula exista un singur set de registrii care sunt

utilizati direct pentru executie, chiar dacaprocesorul poate oferi mai multe seturi de registri.

Sistemul de operare trebuie sa foloseascaaceasta caracteristica pentru a rezolva toateoperatiile legate de comutarea de context (salvare si restaurare de context);

Sistemul de operare nu va face niciun fel de presupuneri legate de timpii de executie a proceselor.

(a) Multiprogramarea pentru patru programe.

(b) Modelul conceptual a patru procese

independente, secventiale.

(c) Doar un program este activ la un moment dat

Putei identifica evenimentele care duc la crearea unui proces?

Care sunt evenimentele care sunt iniiate de un alt proces? Dar cele iniiate din exterior?


Evenimente care pot determina

crearea proceselor:

Initializarea sistemului.

Executia unui apel sistem pentru

crearea proceselor de catre un proces.

O cerere utilizator pentru crearea unui

proces nou.

Initierea unei prelucrari in loturi.

La initializarea sistemului, sistemul de operare vacreea procesele necesare pentru utilizarea corecta a sistemului Ex. Procese care suporta interactiunea utilizat; procese

destinate rezolvarii unor sarcini specifice. In cazul sistemelor de operare moderne, procesele

noi sunt capabile sa creeze alte procese. Exista diferite motive pentru un asemenea

comportament: Oferirea de servicii specializate;

Oferirea sprijinului pentru rezolvarea de probleme;

Oferirea sprijinului pentru executia proceselor inrudite; etc.

Pentru sistemele interactive, cererile utilizator pot fiutilizate pentru crearea de procese noi. Interactiunea cu utilizatorul este posibila prin utilizarea

unui interpretor de comenzi; procesele nou create sunt(de regula) instante ale unor comenzi sistem sauprograme utilizator.

Pentru sistemele cu prelucrare in loturi, creareaproceselor se poate realiza in timpul transmiteriiunei lucrari catre sistem, sau ca urmare a prelucrariiunei cartele de control. Sistemul de operare trebuie sa decida asupra creerii

unei lucrari noi doar atunci cand resursele disponibilesunt suficiente pentru aceasta operatie.

Care sunt mecanismele legate de implementarea operaiei de creare a proceselor?


Mecanismul de creare a proceselor este urmatorul: Un proces existent emite un apel sistem pentru a creea

un proces nou (ex. Apelul sistem fork()). Anumitesisteme de operare limiteaza aceasta posibilitate la anumtie categorii de procese.

Sistemul de operare poate fi instiintat, in acelasi timp, asupra necesitatii de a incarca (sau executa) un alt program in spatiul nou creat (ex. Printr-un apel sistemde tip exec()).

Alte sisteme de operare, cum ar fi sisteme de tip Windows, ofera o functie unica (si in acelasi timpcomplexa) pentru a rezolva toate cerintele operatiei de creare a proceselor.

Putei identifica evenimentele care duc la terminarea unui proces?

Care sunt evenimentele care sunt iniiate de ctre procesul nsui? Dar cele iniiate din exterior?


Evenimente care pot determina

terminarea proceselor:

Terminare normala (voluntar).

Terminare printr-o eroare (voluntar).

Eroare fatala (involuntar).

Terminare datorata unui alt proces

(involuntar).

Majoritatea proceselor dintr-un sistem de operare suntcaracterizate printr-o terminare normala, odata emis un apelsistem specific;

Erorile fatale reprezinta evenimente speciale in timpul executieiproceselor (ex. Ca urmare a utilizarii unui nume de fisierinvalid). Procesele nu-si pot continua executia, ca urmare a erorilor fatale;

Situatiile de exceptie (ex. Impartire la zero, acces ilegal la memorie, operatii invalide cu pointeri) ofera un alt tip de motivpentru terminarea proceselor. Exceptiile pot fi interceptate si manipulate. Pentru acest tip de

evenimente, terminarea proceselor poate fi evitata sau amanata; Terminarea fortata poata sa apara doar ca urmare a cererii unui

alt proces, autorizat pentru acest tip de operatie.

Care sunt legturile dintre procese?

Exist o legtur printe-copil? n care sisteme de operare?

Poate fi implementat o ierarhizare a proceselor? Dac da, cum?


Diferitele sisteme de operare ofera mecanismediferite pentru a pune in evidenta relatiile dintreprocese. Pentru sistemele UNIX este implementata o relatie de

tip parinte-copil.

Toate procesele sunt descendetul unui unic proces, init, creat odata cu initializarea sistemului (traditional, valoarea PID Process ID este 1).

Pentru sistemele de tip Windows, creatorul unuiproces este inzestrat cu un token special prin care poatefi utilizat pentru a controla procesul creat. Cu toateacestea, in filozofia Windows, toate procesele sunt egale.

Starile proceselor


Putei identifica principalele evenimente legate de execuia proceselor?


Starile unui proces reflecta principalele momente in cursul executiei acestora. Primele sisteme folosescun model simplu, cu 3 stari: in curs de executie pregatit blocat.

Procesele sunt blocate atunci cand asteapta aparitiaunui eveniment extern (de regula, o operatie I/O, dar si activitatea unui planificator sau altele)

Fiecare Sistem de operare implementeaza o schema proprie de tranzitie intre stari, in conformitate cu politicile sistemului in ceea ce priveste gestiuneaproceselor.

Cum se poate realiza tranziia ntre aceste stri?


Un proces se poate gasi in stare running (in curs

de executie), blocked (blocat) sau ready

(pregatit).

Tranzitiile dintre aceste stari, pentru modelul simplu

cu trei stari, sunt evidentiate.

Cum credei c influeneaz mecanismele de memorie virtual strile din cursul execuiei proceselor?


Modelul clasic ofera o viziune de ansamblu asupraexecutiei proceselor.

Ca urmare a introducerii tehnicilor de memorievirtuala, modelul cu 3 stari poate fi modificat pentrua oferi stari suplimentare, asociate mecanismelor de swapping. Un proces blocat (in memorie) poate fi transferat pe

disc, ca proces suspendat. Activitatea unui processuspendat poate fi reluata prin readucerea acestuia in memorie ca proces pregatit pentru executie.

Procesele suspendate nu pot fi incarcate in memorieintr-o alta stare decat daca fac obiectul uneiactivitati de planificare.

Preluat din http://www.ksvali.com

Implementarea proceselor


Cum pstreaz sistemul de operare informaii legate de procese?

Care sunt aceste informaii?


Sistemul de operare pastreaza permanent in memorieinformatii despre procese intr-o tabela specializata (tabelaproceselor).

Fiecare proces aflat in memorie sau memoria virtuala estecaracterizat printr-o intrare in aceasta tabela.

Informatiile din aceasta tabela formeaza PCB (Process Control Block). Acesta include infromatii care definesc contextulproceselor: Informatii pentru gestiunea proceselor: UID, GID, descriptori de

fisiere, directorul radacina, directorul curent. Informatii de utilizare a memoriei: pointeri catre segmentele

program. Informatii specifice: registrii, informatii de planificare, PID, PPID,

PGRP, semnale, timpii CPU, si altele.

Campuri tipice aflate in tabela proceselor.

Nivelul de baza al unui SO bazat pe procese rezolva

intreruperile si planificarea. Deasupra acestui

nivel se regasesc procesele secventiale.

Sarcini rezolvate de nivelele inferioare ale unui SO la aparitia unei

intreruperi.

Introducere


Cum credei c se poate defini un fir de execuie fa de un proces?

Oferii definiii posibile acestei noiuni.


Procesele clasice sunt caracterizate prin executiiunice, urmand un singur fir (sau directie) de executie. Acest singur fir ofera un model simplu, secvential.

Firele de executie ofera o extensie a modelului clasical proceselor, prin implementarea de executiiparalele care pot fi realizate in spatiul unui singurproces, aceste fire avand de asemenea un anumitgrad de independenta.

Firele de executie folosesc o cantitate limitata de informatii, definite in contextul procesului gazda. Aceasta limitare se refera doar la informatii care suntstrict legate de executia curenta.

(a) Trei procese, cu cate un fir de executie. (b) Un singur proces cu trei fire de executie.

Sunt firele de execuie orientate ctre calcul sau ctre gestiunea resurselor?

Oferii argumente

Care sunt diferenele dintre execuiile orientate ctre calcul i cele orientate spre gestiune de resurse?


Firele de executie ruleaza in contextul unuianumit proces, mostenind o parte dintreproprietatile acestuia. Uneori este folosittermenul de proces usor pentru a face referirela fire de executie.

Se presupune ca firele de executie suntorientate mai degraba catre executii (calcul), in locul gestiunii resurselor existente (sipartajate) in contextul procesului curent.

Procesele clasice sunt puternic orientate atatcatre identificarea si gruparea resurselor, cat sispre executie.

Fiecare fir de executie are o stiva proprie.

Care credei c sunt informaiile necesare pentru implementarea firelor de control a execuiei?


INFORMATII PARTAJATE DE TOATE FIRELEDE EXECUTIE DINTR-UN PROCES

Spatiul de adrese Variabile globale Fisiere deschise Procese copil Alarme in asteptare Semnale si handlere

asociate Informatii de

contabilitate

INFORMATII PRIVATE PENTRU FIECARE FIR

Contorul program Stiva Registrii Starile.


Independe vs. Interdependen.

Sunt procesele independente sau interdependente?

Sunt firele de control a execuiei independente sau interdependente?

Explicai fiecare rspuns.


Exista un inalt grad de interdependenta intre firele de executie. Aceasta se datoreaza faptului ca firele de executie ruleaza in acelasi spatiu proces, si au un acces uniform catre resursele disponibile procesuluigazda.

Fiecare fir de executie poate interactiona cu executiaunui alt fir de executie.

Nu exista niciun mecanism de protectie la nivel de fir. Acest tip de protectie nu este necesar, avand in vedere caracteristicile principale ale firelor: Oferirea de executii paralele pentru a rezolva

(colaborativ) problemele in acelasi spatiu cu procesulgazda.

Cum credei c este implementat multi-threadingul?

Cum influeneaz interdependena firelor de control a execuiei acest mecanism?


Spre deosebire de multi-tasking, multi-threadingul se bazeaza pe presupunerea ca diferitele fire ale aceluiasiproces pot partaja diferite resurse logice care suntutilizate de catre proces. Multi-threadingul nu implica neaparat suportul pentru multi-

tasking din partea sistemului de operare. Multi-threadingul este oferit intr-o maniera similara cu

multi-programarea: alternarea executiilor diferitelor fire printr-o permanenta comutare intre firele care se executa. Mecanismul de comutare poate fi coordonat de catre sistemul

de operare insusi, sau poate fi comandat de catre un proces, functie de modelul pentru fire de executie utilizat.

Starile firelor de executie


Putei identifica strile firelor de control, prin comparaie cu procesele?


Pentru firele de executie poate fi imaginat un model similar cu cel pentru procese, cu stari de baza si tranzitiisimilare: Fire pregatite pentru executie, orice fir care este capabil sa

fie executat, indata ce firul este planificat pentru executie. Fir in executie, este singurul fir activ, firul care controleaza

procesul curent. Fire blocate, sunt fire care asteapta anumite evenimente.

Totusi, un fir poate fi blocat si la cererea unui alt fir! Fire incheiate, sunt fire care si-au terminat activitatea, si

asteapta raportarea rezultatelor executie (prin mecanismuljoin).

In cazul modelului Windows 2000, exista urmatoarele sase stari: Pregatit: aceasta stare precizeaza un fir care poate fi planificat

pentru executie. Micro-nucleul va lua decizia asupra firului care va fiplanificat efectiv.

Standby: stare care specifica faptul ca firul a fost ales pentruexecutie pe un procesor. Firul ramane in aceasta stare pana candprocesorul este pregatit pentru a-l suporta.

In executie: acesta este firul activ. Executia sa se incheie la terminare firului, blocarea acestuia, expirarea feliei de timp sauevacuarea firului.

In asteptare: un fir in asteptarea unei operatii I/O, unei sincronizarisau un fir care a fost suspendat.

Tranzitie: o stare temporara care specifica fire in asteptare ale carorresurse sunt insa temporar indisponibile.

Terminat: un fir terminat, din unul din motivele: terminare normala, datorata unui alt fir, prin terminarea procesului parinte.

Implementare


Care sunt mecanismele de creare a firelor de control a execuiei?

Dar cele de terminare?


Fiecare proces isi incepe executia ca un procescu un singur fir.

Firul principal este responsabil cu crearea altorfire. Mai tarziu, fiecare alt fir este de asemeneacapabil sa creeze alte fire.

Tinand seama de caracteristicile firelor, utilizarea si mentinerea unor mecanisme de tip parinte-copil este o sarcina dificila.

Apelul tipic pentru aceasta operatie este de forma thread_create()

La fel ca pentru proces, terminarea firelor se poaterealiza explicit, printr-un apel thread_exit(), sau implicit, odata ce firul returneaza si/sau termina executiaasociata functiei de fir.

Firele de executie ofera mecanisme proprii de sincronizare, prin utilizarea apelurilor de bazathread_wait() si thread_join(). Pentru a utiliza acest tip de sincronizare, un fir trebuie sa fie in starea joinable.

Mecanismele de sincronizare pot include primitive ale SO, cum ar fi variabilele de conditie (ca mecanism de semnalizare a unor conditii de continuare a executiei), excluderea mutuala (mutex), semafoare, si altele.

Firele sunt executate in spatiul unui singur proces, astfel incatmecanismele de limitare a timpului de executie nu mai suntefective. Diferitele fire vor concura permanent pentru rezolvarea sarcinilor in

spatiul proces. Pornind de la aceasta idee, este extrem de important ca firele sa fie capabila sa ofere voluntar resursele detinute altor fire.

Firele de executie utilizeaza un apel de forma thread_yield()pentru a oferi controlul catre alte fire; acest apel poate fi utilizatpentru evaluarea unor anumite conditii.

Pentru a concepe un mecanism de control al firelor de executie, pot fi avute in vedere cateva probleme, cum ar fi: Mostenirea firelor de la procese copil (de regula, acest tip de

facilitate nu este oferita de catre sistemul de operare) (Re)utilizarea resurselor care sunt detinute exclusiv de catre un alt

fir, in urma unor evenimente neprevazute (de exemplu, datorate unuialt fir).

Exist mai multe modele de implementare a firelor de control a execuiei.

Primul dintre acestea a fost exploatat i pentru Windows, ca interfa grafic.

Putei identifica o serie de caracteristici ale acestui model de implementare?


O abordare posibila in cazul sistemelor de operaresimple, cum ar fi SO mono-utilizator, pentru sistemede operare care nu ofera suport pentru executiafirelor sau pentru orice alt sistem de operare.

Executia firelor este realizata doar in spatiulutilizator: SO nu are niciun fel de informatie despre aceste executii.

Intregul management este rezolvat la nivel de proces, printr-un subsistem specializat de management al firelor.

Acest management este bazat pe o tabela de fire, insotita de decizii similare deciziilor de planificare.

(a) Fire de executie in spatiul utilizator. (b) Fire de executie in spatiul nucleu.

Deoarece toate firele sunt executate in spatiulutilizator, activitatea planificatorului de fire trebuie sa fie extrem de rapida.Contra: la utilizarea apelurilor cu blocare (ex. open,

read, alte apeluri cu fisiere) este posibila blocareaintregii aplicatii, nu doar a firului curent.

Contra: un singur fir poate fi executat la un moment dat. Executia altor fire este bazata integral pecorectitudinea firului curent (de exemplu, acesttrebuie sa emita apeluri explicite thread_yield() sausimilare pentru a renunta la controlul asupraprocesului).

Al doilea model presupune un suport deosebit din partea sistemului de operare.



De aceasta data activitatile de management ale firelorsunt pasate sistemului de operare. SO va oferi apeluri sistem specifice pentru gestiunea firelor, si

va mentine informatii suplimentare pentru acest scop. Acum firele blocate nu mai blocheaza intreaga aplicatie

SO este capabil sa planifice de data aceasta alte fire ale aceleiasi aplicatii, daca este cazul.

Crearea si stergerea firelor este insa costisitoare, fiindsimilare cu operatiile pentru procese. Pentru a trece peste aceasta dificultate, SO poate mentine un

set de socluri-fir, iar firele sterse vor fi doar marcate, insapastrate in sistem pentru a grabi operatii viitoare de creare a firelor noi.


Care credei c ar putea fi a treia abordare?



De regula SO nu se limiteaza la una dintre cele douaimplementari precizate anterior. O abordare hibridaeste utilizata pentru a combina avantajele firelor in spatiul utilizator cu managementul firelor in spatiulnucleu.

In abordarea hibrida, firele sunt mapate in spatiulnucleu, astfel incat vor putea fi oferite mecanismeletipice pentru gestiunea firelor (si proceselor). Nucleul SO este insa interesat doar in aceste activitati de

management, fara un interes deosebit pentru obiectelegestioante (care acum exista in spatiul utilizator).

Multiplexarea firelor in spatiul utilizator pe fire in spatiul nucleu.

Variabilele globale pot ridica probleme serioase cand sunt utilizate in aplicatii multifir. Aceste probleme se datoreaza faptului ca fiecare fir poate accesa orice informatie din spatiul procesului.

Deoarece nu exista mecanisme de protectie bine definite, ar putea fiposibil ca diferitele fire de executie care partajeaza aceleasi informatiiglobale sa fie capabile sa modifice simultan aceste valori, oferind astfelposibilitatea unei utilizari incorecte a acestora. De exemplu, un executia unui fir s-ar putea baza pe o valoare gestionata de

un alt fir. Daca primul fir foloseste aceasta valoare inainte ca celalalt fir sa fifost capabil sa-l modifice, ar putea fi posibil un comportament incorect al primului fir.

Astfel de probleme pot fi evitate astfel: Evitarea problemei: neutilizarea de informatii globale care pot fi alterate. Oferirea de vederi private pentru variabilele globale (aceasta informatie

poate fi numita variabila global-locala).

O biblioteca de functii este reentranta daca un alt doilea apel este posibil in timp ce un prim apel estein functiune (nu neaparat din acelasi fir de executie).

Uneori o astfel de functie este numita thread-safe. Majoritatea bibliotecilor de functii nu sunt, insa, reentrante. Un al doilea apel ar putea lasa diferitelestructuri interne ale acestora intr-o stare inconsistenta.

Solutii pentru aceasta problema includ: Rescrierea bibliotecii de functii pentru a putea oferi o

varianta reentranta; Interzicerea de apeluri nesigure (non-reentrante) in

aplicatiile multifir.

Pentru sistemele de operare cu fire de executiein spatiul utilizator, cand stiva asociata unui fir este plina, sistemul de operare nu va reactionaneaparat. Aceasta situatie ar putea fi posibiladatorita lipsei unei cereri explicite a procesuluicare detine firul.

Procesul insusi este responsabil cu gestiuneastivelor, astfel incat subsistemul de gestiune a firelor de executie ar trebui sa rezolve cererilesuplimentare ale firelor de executie si sa le redirecteze catre sistemul de operare.

Printre motivele utilizarii firelor de executie, putem aminti urmatoarele: Procesare foreground si background: o aplicatie

ar putea folosi tehnicile multifir pentru a afisa un meniu, pentru a cauta un document, dar si pentru o activitate de update, realizate in acelasi timp.

Procesari asincrone: activitatile asincrone ar putea fiimplementate intr-o aplicatie folosind diferite fire de executie. De exemplu, o activitate de update, o activitate de auto-salvare a documentelor ar putea ficonsiderate activitati tipic asincrone.

Imbunatatirea vitezei de executie: diferitele fire ar putea fi utilizate pentru a realiza suprapunerea operatiilor. De exemplu, unul dintre fire ar putea realiza

anumite operatii de calcul, in timp ce un alt fir pregateste datele pentru calculele urmatoare.

Daca o problema poate fi decompusa si diferitele sub-probleme pot fi rezolvate simultan, ar putea fi utilizate mai multe fire de executie pentru a realiza aceste calcule.

Exemplu: un procesor de texte cu trei fire de executie.

Structura modulara a programelor:

Multi-threadingul poate fi utilizat pentru a oferi mecanisme facile de design si implementare pentru aplicatiile care realizeaza activitati multiple, cu un numar mare de surse si destinatii pentru operatiile de intrare/iesire.

Un server Web multifir simplu.

O bucata de cod pentru Figura precedenta(a) Firul Dispatcher. (b) Firul Worker.

Fire de executie POSIX


Motive pentru utilizarea FCECost inalt pentru crearea de procese noi (via mecanismul

fork()). FCE necesita mai putina memorie la momentul pornirii.Acces facil catre informatiile sau datele partajate.

Fiecare proces este compus din unul sau mai multe FCE.Informatiile partajate de toate procesele pot include:Memoria (codul program, datele globale); Fisierele deschise, socketuri deschise;Handlere pentru semnale si semnale emise; Informatii de mediu (e.g. directorul curent, ID utilizator, etc.).

Ca in cazul proceselor, fiecare FCE este dotat cu o serie de informatii proprii:Thread ID (integer);

Thread stack, registrii, program counter;

errno (in caz contrar errno ar fi inutil!)

Toate FCE care exista in cadrul aceluiasi proces au acces uniform catre datele globale, precum si catrezonele de memorie partajate. Acestea pot folosimemoria partajata pentru a rezolva cerintele de comunicare.

POSIX Threads Un API pentru FCE cu larg suport; Impementarile sunt disponibile pentru platforme

diferite, inclusiv Windows; Pentru sistemele *NIX, sau UNIX-like, aplicatiile pot

fi legate cu biblioteca corespunzatoare intr-o maniera relativ simpla:E.g. gcc -lpthread

Nota: compilatorul ar putea fi ajutat utilizand (pediferite sisteme) versiuni reentrante ale functiilor de biblioteca existente, atunci cand acestea suntdisponibile.E.g. strtok_r () este sigura pentru utilizare in FCE, spre

deosebire de strtok ().

Crearea FCE Realizabila printr-un apel pthread_create :

pthread_create(pthread_t *tid, const pthread_attr_t *attr, void*(*func)(void *), void *arg);

Functia returneaza 0 pentru SUCCESS, o valoareapozitiva pentru situatie de eroare (Nota: cu toateacestea, multe apeluri sistem intorc -1 pentru situatiade eroare)

Aceasta functie nu seteaza errno in caz de eroare!

Noul FCE returneaza ID-ul prin valoarea pthread_t*tid.

Crearea FCE Functia func () specificata este functia de fir

care urmeaza sa fie apelata.

FCE isi termina existenta indata ce functia de fir se incheie.

Pointerul pthread_attr_t * attr este utilizat pentru precizarea atributelor FCE, incluzand: Informatii asupra starii de detasare;

Informatii de planificare.

(Sau precizati NULL pentru valorile implicite)

Identificarea FCE:

Fiecare ID de fir este unic in contextul procesului curent. Un FCE isi poate obtine propriul identificator prin apelul pthread_self ().

Toti identificatorii sunt de tip pthread_t. Acesta este o simpla valoare intreaga (deghizata, ca multe alte tipuri).

La crearea FCE pot fi transmise argumente catrefunctia de fir. Acestea pot fi pasate prin parametrulvoid * arg. Folositi NULL pentru a preciza lipsaargumentelor.Mecanismul implicit se bazeaza pe argumente de tipul

generic void * pentru functia de fir. Parametrii complecsi pot fi transmisi printr-o

impachetare corespunzatoare (e.g. struct, typedef): Creati structurile necesare si transmiteti adresele acestor

structuri;Nota: deoarece diferitele fire folosesc stive distincte

(fiecare cu date private proprii), nu veti putea utiliza date locale pentru a le transmite prin intermediulargumentelor.

#include

#include

void *print_num (void *a)

{

int i, odd = *((int *) a), ret ;

for (i=0; i

Ciclul de viata

Functia de fir, func(), este executata indata ce FCE a fost creat.

FCE isi termina executia indata ce functia func() se incheie.

Alternativ, un FCE poate folosi functia pthread_exit() pentru a cere terminarea executiei.

Cu toate acestea, un FCE se incheie atunci cand functia main se incheie sau cand exista un apel explicit exit() din orice alt fir din spatiul procesului.

Pot fi identificate doua stari (de detasare) : detasat si joinable. FCE detasate

La terminarea FCE, toate resursele acestuia sunt eliberate de catresistemul de operare. In cazul FCE, acestea nu pot fi reunite cu altefire.

Nu exista niciun mecanism pentru recuperarea valorii returnate de functia de fir (de fapt, nici nu exista valoare de retur :D).

FCE Joinable La terminarea FCE, ID si starea de terminare sunt salvate de catre sistemul de

operare. Un FCE se poate reuni cu un alt fir printr-un apel explicit pthread_join ():

Firul apelant isi suspenda activitatea (se blocheaza) pana cand firul precizat isi terminaexecutia. Totusi, celalalt fir trebuie sa fie in starea joinable!

int pthread_join( pthread_t tid, void **status);

Firul apelant poate, prin acest mecanism, sa recuperezestarea de terminare a celuilalt fir.

Probleme cu utilizarea FCE: variabile globaleatomic_t counter=0;void *dummy(void *arg) {

counter++;printf("Thread %u has counter %d\n",

pthread_self(), counter);

}void main() {

int i; pthread_t tid;for (i=0;i

Probleme cu utilizarea FCE: variabile globale

La utilizarea informatiilor partajate (e.g. acces la variabile globale), FCE pot utiliza mecanisme tipice IPC pentru a rezolva eventualele probleme.

Biblioteca pthread ofera suportul necesar pentru mecanisme de excludere mutuala (mutex).

Prin mutex, diferitele FCE pot controla modul in care se realizeaza accesul catre informatiile partajate, prin blocarea temporara a accesului.

De precizat ca acest mecanism nu este impus de catre sistemul de operare!

O blocare este implementata prin utilizarea uneivariabile globale de tiptype pthread_mutex_t.

pthread_mutex_t lock= PTHREAD_MUTEX_INITIALIZER;

In cazul variabilelor statice, este necesara o initializareexplicita cu valoarea PTHREAD_MUTEX_INITIALIZER.

In cazul variabilelor dinamice vor fi disponibile optiunisuplimentare.

Variabile de conditiepthreads suporta conceptul de variabile de conditie, prin

care un FCE poate astepta aparitia unui eveniment generatde un alt fir.

Prin acest mecanism este posibila evitarea problemelor de asteptare activa.pthread_cond_t foo = PTHREAD_COND_INITIALIZER;

Folosirea mutex. Mecanismul mutex ofera doua functii cu blocare:

pthread_mutex_lock(pthread_mutex_t &);

pthread_mutex_unlock(pthread_mutex_t &);

Firul apelant se va bloca pana cand este capabil safinalizeze actiunea precizata (mutex lock sauunlock).

Folosirea Variabilelor de ConditieAcestea sunt utilizate doar impreuna cu un mutex.

pthread_cond_wait(pthread_cond_t *cptr, pthread_mutex_t *mptr);

pthread_cond_signal(pthread_cond_t *cptr);

STANDARD WAITER

pthread_mutex_t mutex;pthread_cond_t cond;

pthread_mutex_lock(&mutex);

while ( !condition )pthread_cond_wait (&cond,

&mutex);do_something();pthread_mutex_unlock

(&mutex);

STANDARD SIGNALER

pthread_mutex_lock(&mutex);

// make condition TRUEpthread_mutex_unlock

(&mutex);pthread_cond_signal

(&cond);


sisteme de operare cc

Documents