51. Excludere mutual 64.

Administrarea intrrilor-ieirilor
52. Sincronizarea proceselor 65. Administrarea unui periferic
53. Exprimarea i implementarea restriciilor de precedare 66. Buferizarea imprimrii
54. Probleme de realizare a sincronizrii 67. Sincronizare temporal
55. Monitorul mecanism de sincronizare. Definiii. Ex. 68. Gestionarea dinamic a proceselor
56. Implementarea sincronizrii. Probleme-tip 69. Sincronizarea n Windows
57. Administrarea unei resurse partajate 70. Procese i fire
58. Alocarea resurselor banalizate 71. Necesitatea sincronizrii
59. Modelul cititorului i redactorului 72. Structura mecanismului de sincronizare n Windows
60. Comunicarea ntre procese 73. Administrarea obiectelor de sincronizare n Windows
61. Modelul productorului i consumatorului 74. Excluderea mutual
62. Primitive de comunicare 75. Evenimentele
63. Aplicaii : relaia client-server
51. Excludere mutual (3.2.2.1)
(1) p q

(2) p q p q p q

(3) p q

Fig. 3.2. Executarea unei mulimi de procese

Fie o mulime de procese contextele crora au un obiect comun, care poate fi utilizat la un moment de timp dat de un singur
proces. Se va spune n acest caz, c obiectul constituie o resurs critic pentru procesele date sau c procesele sunt n
excludere mutual (excludere reciproc sau concuren) pentru utilizarea unei resurse. n situaia descris, procesorul
este o resurs critic pentru procesele p i q.

52. Sincronizarea proceselor (cap. 3)

Sincronizarea reprezint derularea concomitent (se petrec n acela timp) a proceselor ce folosesc resurse commune , de
obicei un hardware device sau o mulime de variabile. Sincronizarea i propune 4 aciuni cheie:
accesarea de ctre o mulime de procese a unei resurse partajate comune,
comunicarea ntre procese,
gestionarea perifericelor i intrrilor-ieirilor tamponate,
sincronizare temporal.

53. Exprimarea i implementarea restriciilor de precedare (3.3.1)

Exemplul 3.4. Procesul p transmite informaii procesului q scriind ntr-un segment a, consultat de q (se presupune c aceast transmitere are loc o singur dat). Este
necesar s se verifice condiia: sfrit(scriere(a)) < nceput(citire(a))
Aceast relaie exprim restricia, c citirea lui a de ctre q nu poate ncepe nainte de terminarea scrierii lui a de ctre p.
Restriciile de sincronizare pot fi exprimate prin urmtoarele dou forme echivalente:
1. Se va impune o ordine de succesiune n timp logic pentru unele puncte ale traiectoriei temporale ale
procesului,
2. Se va impune unor procese o condiie de autorizare a depirii acestor puncte ale traiectoriei lor
temporale.
Punctele privilegiate astfel se vor numi puncte de sincronizare. Expresia (2) arat, c restriciile de
sincronizare pot fi satisfcute impunnd un proces s atepte s execute o aciune pn cnd o oarecare
condiie va fi satisfcut. Aceast noiune de ateptare nu poate fi exprimat cu ajutorul instrumentarului introdus
pn acum; pentru aceasta vom introduce o nou stare pentru un proces, stare n care procesul se zice n
ateptare sau blocat, prin opoziie strii activ, considerate pn acum n mod implicit. Se numete blocare
tranziia activateptare i deblocare tranziia invers. Specificarea proceselor se va produce n dou etape:
1) definirea punctelor de sincronizare pentru fiecare proces,
2) asocierea unei condiii de depire fiecrui punct de sincronizare, condiie exprimat prin intermediul
variabilelor de stare a sistemului.
54. Probleme de realizare a sincronizrii
Exemplul 3.8 sincronizare a proceselor p si q. var e : eveniment memorizat;
procesul p procesul q
scriere(a); <debut_q>;
e:=sosit; ateptare(e);
<continuare_p> citire(a)
Implementarea condiiilor de sincronizare nu poate fi corect realizat numai cu ajutorul operaiilor de
ateptare. Consultarea i modificarea variabilelor de stare, care intervin n aceste condiii, trebuie s fie executate
n regim de excludere reciproc. Observaia dat ne impune s introducem un mecanism de sincronizare, care n
mod automat ar asigura acest regim de funcionare (e vorba de monitor).

55. Monitorul mecanism de sincronizare. Definiii. Exemple de utilizare (3.3.3)

Un monitor este o metod de sincronizare a dou sau mai multe sarcini ce folosesc o resurs comun, de
obicei un hardware device sau o mulime de variabile. n concurena bazat pe monitor, compilatorul sau
interpretorul introduce cod, n mod transparent, pentru blocarea sau deblocarea unor proceduri specificate, fr a
fi nevoie ca programatorul s acceseze explicit primitive de sincronizare. Un monitor este constituit dintr-o
mulime de variabile de stare i o mulime de proceduri. Monitorul poate fi utilizat doar prin apelarea
procedurilor sale externe; acestea permit blocarea sau deblocarea proceselor conform specificaiilor problemei.
Condiiile de blocare sau deblocare sunt exprimate ca funcie ale variabilelor de stare, iar mecanismul de execuie
a monitorului garanteaz manipularea acestor variabile n regim de excludere mutual. n fine, un monitor
conine un fragment de cod de iniializare, executat o singur dat la crearea monitorului.
Exemplul de utilizare 3.10. sinc: monitor; procedura debut_citire;
var fact: boolean; if non fact then
term: condiie; term.ateptare
endif
procedura terminare_scriere;
begin begin -- iniializare
fact:=true; fact := false
term.semnalizare end
end
end sinc

56. Implementarea sincronizrii. Probleme-tip (3.4.1)

Experiena demonstreaz, c problemele de sincronizare logic ntlnite n practic pot fi reduse, n marea lor
majoritate, la combinaia unui numr mic de situaii elementare, schemele de soluionare ale crora sunt
cunoscute. Seciunile 3.4.2 3.4.5 sunt consacrate studierii acestor probleme-tip, utiliznd instrumentarul de
baz, pus la dispoziie de monitoare. Problemele-tip sunt urmtoarele:
accesarea de ctre o mulime de procese a unei resurse partajate comune,
comunicarea ntre procese,
gestionarea perifericelor i intrrilor-ieirilor tamponate,
sincronizare temporal.

57. Administrarea unei resurse partajate (3.4.2)

Considerm o resurs (fizic sau logic) partajat de o mulime de procese. Utilizarea acestei resurse trebuie
s respecte nite reguli de utilizare sau restricii de integritate, pentru fiecare resurs. O modalitate de garantare
a respectrii regulilor de utilizare a unei resurse const n adoptarea urmtoarei scheme:
modul de folosire a resursei presupune utilizarea obligatorie a procedurilor de acces asociate resursei;
orice tentativ de utilizare, care nu respect acest mod este detectat automat,
procedurile de accesare sunt grupate ntr-un monitor, sau mai multe, programul cruia impune respectarea
restriciilor de integritate.
 Cel mai simplu caz este acela al unei resurse pentru care singura restricie de integritate este de a fi utilizat n
excludere reciproc. Simpla grupare a procedurilor sale de acces ntr-un monitor unic garanteaz respectarea
acestor restricii.

58. Alocarea resurselor banalizate (3.4.2.1)

Considerm o resurs pentru care exist un numr fix de N exemplare. Un proces poate accesa la cerere n
uniti din cele N, le poate utiliza i apoi elibera. O unitate, folosit de un proces, se numete alocat procesului,
care o utilizeaz, pentru toat perioada de la accesare pn la eliberare. Toate unitile sunt echivalente din
punctul de vedere al proceselor utilizatoare, vom mai zice c resursa este banalizat. Zonele-tampon din
memoria principal sau pe disc, unitile de band magnetic, etc. sunt exemple de resurse banalizate.
Vom admite urmtoarele reguli de utilizare:
o unitate poate fi alocat la un moment de timp dat doar unui singur proces,
o unitate poate fi alocat unui proces, care cere alocarea, doar dac ea este liber (ne alocat de alt proces),
operaia de eliberare este aplicat mereu ultimelor resurse, obinute de procesul care execut eliberarea,
o cerere de alocare este blocant n caz de eec (numr insuficient de uniti libere).

59. Modelul cititorului i redactorului (3.4.2.2)

S considerm un fiier manipulat de procese din dou clase diferite: cititori (read-only) i scriitori (read-
write). Fie pentru un moment arbitrar de timp ncit i nscr numrul de cititori i de scriitori. Definim restriciile:
(nscr=0) i (ncit0) -- fiier n citire
sau (nscr =1) i (ncit=0) -- fiier n scriere
Fie fich un monitor care asigur respectarea acestor restricii. Impunem urmtoarea form a acceselor la fiier:
proces cititor proces scriitor
fich.debut_citire; fich.debut_scriere;
<acces citire> <acces scriere>
fich.terminare_citire; fich.terminare_scriere;
Procedurile debut_citire, terminare_citire, debut_scriere, terminare_scriere trebuie s asigure
respectarea restriciilor de mai sus. Vom implementa aceste restricii autoriznd depirile; pentru aceasta este
necesar s fie precizate prioritile ntre cititori i scriitori.
Exemplu, presupunem c cititorii au prioritate n faa redactorilor (o scriere nu va fi autorizat, dac exist cititori n ateptare).
Definim urmtoarele variabile de stare:
scr = o scriere este n curs (valoare boolean)
nc = numrul de cititori n ateptare sau n curs de citire
n acest caz, condiiile de depire se vor exprima dup cum urmeaz:
aut(citire) : scr=false (nu exist scrieri curente)
aut(scriere): scr=false i nc=0 (nici scrieri nici citiri n curs, nici cititori n ateptarea)

60. Comunicarea ntre procese (3.4.3)

Procesele pot comunica prin accesarea unei mulimi de variabile comune. Acest mod de comunicare este slab
structurat i ineficace, deoarece el trebuie s asigure excluderea reciproc a variabilelor. Este utilizat doar n
cazuri speciale, cum ar fi un nucleu de sincronizare, unde excluderea mutual global este redus la secvene
scurte i bine protejate. Pentru cazuri generale sunt utilizate alte moduri de comunicare.
Exemple: a) o schem de baz pentru comunicarea prin mesaje - modelul productorului i consumatorului, realizat cu ajutorul
monitoarelor. b) O alt posibilitate, const n a considera operaiile de comunicare ca un fel de mecanisme primitive de sincronizare. c)
o aplicaie frecvent de comunicare modelul client-server.
61. Modelul productorului i consumatorului (3.4.3.1)
O schem uzual de comunicare este cea n care un proces (productorul) trimite mesaje unui alt proces
(consumatorul), utiliznd un tampon (monitorul) n memoria comun. Mesajele sunt de lungime fix i
capacitatea tamponului este de N mesaje. Specificaiile comunicaiei sunt urmtoarele:
un mesaj dat poate fi preluat doar o singur dat dup ce a fost depozitat n tampon,
un mesaj nu poate fi pierdut; dac tamponul conine N mesaje nepreluate, nu pot fi depozitate aici altele
o operaie imposibil (depozitare ntr-un tampon plin / preluare dintr-un tampon vid) blocheaz
procesul, care ncearc s o execute.
Condiiile de depire pot fi exprimate dup cum urmeaz, notnd prin n numrul de mesaje din tampon, care
nu au fost nc preluate:
aut(depozitare) : n < N -- tamponul nu este plin
aut(preluare) : n > 0 -- tamponul nu este vid
Respectarea acestor restricii este asigurat de un monitor tampon, utilizat dup cum urmeaz:
proces productor proces consumator
... ...
produce(mesaj_emis); tampon.preluare(mesaj_recepionat);
tampon.depozitare(mesaj_emis); consumator(mesaj_recepionat);

62. Primitive de comunicare (3.4.3.2)

Schimbul de mesaje ntre procese, n afar de funcia de transmitere a informaiei, poate fi utilizat i pentru
ordonarea evenimentelor n cadrul unor procese distincte, deoarece emiterea unui mesaj precede ntotdeauna
recepia sa. Operaiile de schimb de mesaje pot fi definite ca nite mecanisme primitive i s le utilizm pentru
sincronizarea proceselor. Primitivele de baz n comunicarea prin mesaje sunt: emitere(mesaj,destinaie) i
recepie(mesaj,origine). Specificrile acestor primitive trebuie s precizeze:
natura i forma mesajelor,
modul de adresare a proceselor emitoare i destinatare,
modul de sincronizare a acestor procese,
tratarea erorilor.
1) Natura mesajelor
Lungimea poate fi constant sau variabil. Mai frecvent sunt utilizate mesajele de lungime constant, care
pot fi create mai simplu, mesajele de lungime variabil vor fi transmise prin referin, pasnd adresa fizic sau
identificatorul informaiei transmise.
2) Modul de adresare
Procesele, care fac schimb de mesaje, se pot desemna reciproc prin numele lor (desemnare direct) sau pot
utiliza numele unui obiect intermediar ori cutie potal (desemnare indirect). Aceste nume sunt folosite ca
parametri origine i destinaie.
n cazul desemnrii directe parametrul origine a primitivei recepie poate fi interpretat n dou moduri:
fie ca dat: receptorul specific explicit c ateapt un mesaj de la un destinatar special (recepie
selectiv),
fie ca rezultat: receptorul primete un mesaj care i-a fost adresat mpreun cu identitatea emitorului.
n cazul desemnrii indirecte asocierea proceselor cutiilor potale poate fi static sau dinamic. n ultimul
caz, sunt utilizate dou primitive conectare i deconectare pentru ataarea procesului la o cutie potal (n calitate
de receptor) i de abrogare a acestei atari, respectiv. n unele sisteme un receptor sau mai multe pot fi ataate
unei cutii potale date; cutiile potale supuse unor asemenea restricii sunt adesea numite pori.
3) Moduri de sincronizare
n caz general, avem dou moduri de sincronizare:
 Schema productor-consumator, n care cutia potal este realizat printr-o zon tampon. Emiterea nu
este blocant, cu excepia cazului n care tamponul este plin.
Schema rendez-vous, n care emitorul este blocat pn la preluarea mesajului de ctre receptor. Aceast
schem poate fi considerat caz limit a precedentei cu lungimea nul a tamponului.
n fine, atunci cnd un proces este asociat n recepie la mai multe pori, poate fi definit un mod de
sincronizare, zis ateptare multipl, n care sosirea unui mesaj la o oarecare din aceste pori deblocheaz
receptorul.
4) Tratarea erorilor
Scopul tratrii erorilor este de a evita blocrile infinite ale proceselor, care se pot produce n diverse
circumstane:
Emiterea unui mesaj cu o destinaie (proces sau poart) inexistent. n acest caz primitiva nu este blocant;
eroarea este tratat prin emiterea unui cod de eroare sau printr-o deviere.
Distrugerea unui proces de la care alte procese ateapt un mesaj sau un rspuns: procesele n ateptare
sunt blocate i recepioneaz un cod de eroare.

63. Aplicaii: relaia client-server (3.4.3.3)

O aplicaie curent a comunicrilor ntre procese este relaia client-server. Un proces server are n arj
ndeplinirea unor servicii (executarea unui program predefinit) proceselor client. Pentru aceasta poate fi utilizat
urmtoarea schem:
procesul server procesul client
ciclu poart_serviciu.emitere(cerere)
poart_serviciu.recepionare(cerere)
<executare serviciu> ...
[poart_client.emitere(rezultat)] ...
endciclu [poart_client.recepionarere(rezultat)]
Procesul server este asociat unei pori, unde clienii i depun cererile, trimind cereri; el este blocat atta
timp ct nu exist cereri de servicii n ateptare.
Serviciul cerut poate conine trimiterea la client a rezultatului. n acest caz clientul trebuie s trimit serverului
n cererea sa numrul unei pori la care el se va bloca n ateptarea rezultatului.

64. Administrarea intrrilor-ieirilor (3.4.4)

Vezi ntrebrile nr. 44, 65 i 66.
65. Administrarea unui periferic (3.4.4.1)
Fiecrui periferic i este asociat un monitor procedurile externe ale cruia permit executarea intrrilor-ieirilor
la acest periferic. Acest monitor are urmtoarea form general (pentru un sistem mono-utilizator):
perif: monitor; var ..., sfr_schimb_i,...: condiie;
<declaraiile variabilelor de stare ale perifericului>
...
procedura schimb_i(<parametri>);
begin
<mascarea ntreruperilor>;
if starea preg then
<tratare eroare(perifericul nu este gata)>
endif;
lansare_transfer_i(parametri);
sfr_schimb_i.ateptare; -- ntrerupere demascat
if starea ok then -- n timpul ateptrii
<tratare eroare(incident de transfer)>
endif;
<demascare ntreruperi>
end;
...
 begin
<iniializare>
end
end perif

Procedura lansare_transfer_i pregtete programul pentru schimbul cerut i lanseaz execuia sa. Procesele
apelante ateapt sfritul transferului datorit condiiei sfr_schimb_i. Sosirea unei ntreruperi, care marcheaz
sfritul schimbului de tip i provoac n mod automat executarea urmtoarei secvene:
if sfr_schimb_i.vid then <tratarea eroare ntrerupere care nu este ateptat>
else sfr_schimb_i.semnalizare
endif
Pentru un proces care execut o intrare-ieire apelnd o procedur de schimb a acestui monitor, totul se
petrece ca i cum schimbul este sincron: la returul din procedur, informaia a fost efectiv transferat (sau o
eroare a fost detectat i semnalizat). Mecanismul de blocare evit ateptarea activ i procesorul poate fi
utilizat n timpul transferului de un alt proces.

66. Buferizarea imprimrii

Avem nevoie de trei tampoane tm1 i tm2 de capacitate N1 i N2 n memoria central i unul pe disc, td, de lungime
Ndisc. Pentru simplitate presupunem c transferurile se fac cu blocuri constante egale cu o linie. Fiecare tampon este
comandat de un monitor cu aceeai structur care are rolul de a asigura excluderea mutual i sincronizarea condiiilor
tampon plin i tampon vid. Definind pointerii top i coad locali fiecrui monitor, procedurile de depozitare i preluare pot
fi: <pentru tamponul 1> <pentru tamponul 2>
procedura intrare(l:linie); procedura intrare(l:linie);
tm1[coad] := l; tm2[coad] := l;
coad := coad+1 mod N1 coad := coad+1 mod N2
procedura ieire(var l:linie); procedura ieire(var l:linie);
l := tm1[top]; l := tm2[top];
top := top+1 mod N1 top := top+1 mod N2
n monitorul tampon_disc operaiile de depozitare i preluare sunt intrri-ieiri ce utilizeaz mon. de gestionare a discului:
procedura intrare(l:linie); procedura ieire(var l:linie);
disc.scriere(l,td[coad]); disc.scriere(l,td[top]);
coad := coad+1 mod Ndisc top := top+1 mod Ndisc
Programul de intrare-ieire este realizat prin cooperarea a patru procese programul crora este prezentat schematic mai
jos (trei procese ale sistemului de operare i procesul utilizator). Pentru a simplifica expunerea au fost omise secvenele de
tratare a erorilor i am admis, c sistemul funcioneaz n regim permanent fr limitarea numrului de linii la imprimare.
Programele folosesc trei monitoare de gestionare a perifericelor (tampon1, tampon2 i tampon_disc) i dou monitoare de
gestionare a perifericelor (impr i disc), construite n baza modelului perif.
proces imprimare linie proces scriere_disc proces citire_disc
ciclu ciclu ciclu
tampon2.preluare(l); tampon1.preluare(l); tampon_disc.citire(l);
impr.scriere(l); tampon_disc.scriere(l); tampon2.depozitare(l);
endciclu endciclu endciclu
Imprimarea unei linii este cerut de procedura:
procedura scriere_linie(l:linie);
tampon1.depozitare(l)
Programele de mai sus sunt mult mai simple dect cele care folosesc direct ntreruperile. Structura modular, introdus
de monitoare permite separarea total a gestionrii tampoanelor de cea a perifericelor. Schimbarea capacitii unui tampon
modific doar monitorul care comand acest tampon; nlocuirea unui periferic cu un altul implic rescrierea doar a
monitorului, care comand acest periferic.

67. Sincronizare temporal (3.4.5)

Sincronizarea temporal face ca timpul s intervin nu numai ca mijloc de ordonare a evenimentelor, dar i ca msur de
durat absolut. Acest mod de sincronizare este utilizat n aplicaiile de timp real, care conin interaciuni cu organe externe
(comanda proceselor industriale, de exemplu). Sincronizarea temporal solicit folosirea unui ceas, realizat prin
intermediul unui oscilator cu quartz, care emite impulsuri la intervale regulate. Aceste impulsuri pot fi utilizate pentru a
declana o ntrerupere la fiecare impuls sau pentru a decrementa n mod automat coninutul unui registru contor, o
ntrerupere este declanat atunci cnd coninutul acestui registru atinge valoare 0.
valoarea absolut a timpului (ora absolut), msoar la orice moment timpul trecut de la o instan iniial,
un registru, adic o list a proceselor care ateapt deblocarea, ordonat conform timpului absolut de deblocare.
Toate procesele, care apeleaz primitiva suspendare(t) (folosit pentru blocarea ceasul pe durat t) sunt inserate n
registru n poziia, care corespunde orei sale absolute de deblocare.
Numim ora_de_baz ora absolut a ultimei nnoiri a ceasului, adic a ultimei iniializri a contorului; fie t_at ultima
valoare ncrcat. Ora absolut exact este dat la fiecare moment de timp de relaia
ora_exact = ora_de_baz + t_at - contor
(t_at - contor este timpul care s-a scurs dup ultima nnoire a contorului). De la o ntrerupere de ceas (la trecerea
contorului prin 0), dup ultima nnoire s-a scurs un timp egal cu t_at; ora_de_baz poate, deci, fi iniializat conform
relaiei
ora_de_baz := ora_de_baz + t_at
Variabila ora_de_baz, odat iniializat, va fi corect ntreinut cu condiia ca registrul s nu fie nicicnd vid; n caz
general aceast condiie va fi asigurat introducnd un proces, numit paznic:
procesul paznic
ciclu
suspendare(tmax)
endciclu
n care tmax este un interval foarte mare de timp, paznicul rmnnd pentru toat perioada de lucru n coada registrului.
Mecanismele descrise sunt realizate ntr-un monitor numit ceas, care are dou intrri: procedura suspendare (apelat
prin ceas.suspendare(t)) i procedura tratare_ntrerupere, pentru tratarea ntreruperii de ceas (trecerea contorului prin zero).
Registrul este realizat cu ajutorul unui fir de ateptare, care conine descriptorii proceselor. Un descriptor este format din
numele procesului i timpul absolut de deblocare; firul de ateptare este ordonat n ordinea creterii timpului deblocrii.

68. Gestionarea dinamic a proceselor (3.5)

n sistemele concurente, mai ales n cele interactive, procesele sunt comandate dinamic. Exemple: n Multics, un proces
nou este creat odat cu admiterea unui nou utilizator; n Unix, la executarea fiecrei comenzi. Crearea unui proces
presupune alocarea resurselor i iniializarea contextului. Distrugerea unui proces elibereaz toate resursele care i-au fost
alocate.
Primele primitive, propuse pentru gestionarea dinamic a proceselor, au fost fork i join. Aceste operaii au fost
introduse pentru organizarea executrii paralele a programelor pe un sistem multiprocesoral, noiunea de proces nefiind
nc clar. Vom descrie cteva variante ale acestor primitive. Fie P o procedur. Instruciunea
id := fork(p),
executat de un proces p (printe), creaz un proces nou q (fiul), care va fi executat paralel cu p. Primitiva fork prezint ca
rezultat identificatorul lui q (sau nil, dac crearea este imposibil). Contextul iniial al lui q este o copie a lui p, mai puin
contorul ordinal, care este fixat la prima instruciune a lui p. Procesul fiu se termin cu o primitiv, numit exit sau quit,
care provoac dispariia sa. Dup ce fork creaz un proces fiu q, primitiva join q permite procesului printe s fixeze un
punct de rendez-vous cu acest fiu. Executarea lui join q blocheaz procesul printe pn cnd q nu va executa exit.
Primitivele fork i join au avantajele i dezavantajele instruciunii go to din programarea secvenial.
Exemplul 3.15. n sistemul de operare Unix crearea unui proces poate fi realizat de ctre interpretorul limbajului de comand ( shell) sau cu ajutorul instruciunii
fork() de un program. Ultima situaie este prezentat schematic n fig.3.4.
 procesul 1 procesul 2

copie

date date

stiv stiv

procesul fiu
procesul printe
Fig.4.4. Crearea proceselor cu ajutorul instruciunii fork

Efectul instruciunii fork():

duplicarea procesului printe;
returnarea valorii pid (numrului procesului fiu) n procesul printe;
returnarea valorii 0 n procesul fiu:
procesul printe procesul fiu

if (fork() == 0) if (fork() == 0)
codul procesului fiu codul procesului fiu
else else
codul procesului printe codul procesului printe

returnarea pid al procesului fiu ( 0) returnare 0

Altfel spus, n Unix primitiva fork (fr parametri) creeaz un proces al crui spaiu de lucru este o copie a spaiului de lucru a creatorului, inclusiv i
contorul ordinal. Diferena poate fi determinat consultnd valoarea returnat de primitiv (0 pentru fiu; identificatorul fiului sau nil pentru printe). O
primitiv wait permite printelui s atepte terminarea execuiei unuia dintre programele fiu (fr a putea alege care anume, dac exist mai multe). Un
proces termin execuia sa cu primitiva exit. Primitiva exec(p) permite unui proces s schimbe contextul, apelnd o procedur specificat de p.
La lansarea Unix-ului sunt create dou procese: procesul numit Swaper, care administreaz memoria, cu pid=0 i procesul Init cu pid=1, care creeaz
toate celelalte procese.
Ilustrm folosirea primitivelor fork i exec:
...
id := fork();
if id = 0 then -- eu sunt fiul
exec(p) -- programul fiului
else -- eu sunt printele
if id = -1 then -- nil : creare imposibil
<tratare eroare>
else
<programul printelui>
endif
endif
Primitiva wait este utilizat dup cum urmeaz:
id := wait(cod) -- blocare pn la terminarea programului unuia dintre fii
... -- id = numrul programului fiu terminat, cod = cauza terminrii

69. Sincronizarea n Windows (3.6)

Platforma pe 32 de bii pune la dispoziia programatorului instrumente evoluate pentru multiprogramare, att la nivelul
unei mulimi de lucrri, ct i a unei lucrri singulare. Poate s apar ntrebarea CND s fie utilizat multiprogramarea n
cadrul unei singure aplicaii. Rspunsul este foarte simplu: atunci cnd dorim ca mai multe fragmente de cod s fie
executate simultan (pseudosimultan, dac exist mai multe fragmente dect procesoare). De exemplu, dac dorim ca unele
activiti s fie ndeplinite n regim de fond sau programul s continue s reacioneze la unele evenimente exterioare n
timpul ndeplinirii unor calcule foarte costisitoare. Pot fi aduse i alte exemple.

70. Procese i fire (3.6.1)

 Numim proces n Windows o instan (un exemplar, o stare) a programului, ncrcat n memoria operativ.
Aceast instan poate crea fire (thread) - secvene de instruciuni, care urmeaz a fi executate. Este important
s se neleag c n Windows anume firele sunt executate (nu procesele!), fiecrui proces fiindu-i asociat
minimum un fir, numit firul principal al aplicaiei.
Deoarece n realitate exist mult mai multe fire dect procesoare fizice, firele vor fi executate secvenial,
timpul de procesor repartizndu-se ntre fire. Dar viteza mare de execuie i frecvena mare de comutare a firelor
las impresia unei execuii paralele a acestora.
Strile elementare ale unui fir sunt aceleai ca i n cazul proceselor: ales (exe), eligibil (ready) i blocat
(wait). Starea blocat este asociat ateptrii unui anume eveniment. Cnd evenimentul se produce firul este trecut
n mod automat n starea eligibil.
n cadrul sistemului de operare Windows exist dou tipuri de fire fire interactive, care execut un ciclu
propriu de prelucrare a mesajelor (de exemplu, firul principal al unei aplicaii) i fire de lucru, care sunt funcii
simple. n ultimul caz execuia firului se ncheie atunci cnd calculele, generate de funcia respectiv, iau sfrit.
Merit atenie i modalitatea organizrii ordinii de execuie a firelor. Algoritmul FIFO este departe de a fi cel mai
optimal. n Windows toate firele sunt ordonate conform prioritilor. Prioritatea unui fir este un numr ntreg de la 0 la 31 i
este determinat de prioritatea procesului, care a generat firul i prioritatea relativ a firului. n acest mod se ajunge la o
flexibilitate maxim, fiecrui fir punndu-i-se la dispoziie n caz ideal exact atta timp de procesor, ct are nevoie.
Prioritatea firului poate fi modificat dinamic. Firele interactive, care au prioritatea Normal, sunt executate n
mod deosebit de ctre sistem, prioritatea acestor fire fiind majorat, atunci cnd procesul, care le-a generat, se
afl n planul central (foreground). n rezultat, aplicaia curent reacioneaz mai repede la cererile utilizatorului.

71. Necesitatea sincronizrii (3.6.2)

Cnd un proces este creat n mod automat este creat firul principal al acestuia. Acest fir poate crea n timpul
execuiei alte fire, care la fel pot crea fire noi i aa mai departe. Timpul de procesor fiind repartizat ntre fire,
fiecare fir lucreaz n mod independent.
Toate firele unui proces mpart resursele comune, de exemplu, spaiul de adrese al memoriei operative sau
fiierele deschise. Aceste resurse aparin ntregului proces, deci i fiecrui fir. Fiecare fir poate s utilizeze aceste
resurse fr nici un fel de restricii. n realitate, din cauza multitaskingului controlat (preemptive multitasking - la
orice moment de timp sistemul poate ntrerupe execuia unui fir i transmite controlul unui alt fir), se poate
ntmpla ca un fir s nu fi terminat nc lucrul cu o resurs comun oarecare, iar sistemul s treac la un alt fir,
care utilizeaz aceeai resurs. Rezultatele pot fi imprevizibile. Asemenea conflicte se pot produce i n cazul
unor fire, care aparin chiar unor procese diferite. Problema poate s apar ntotdeauna cnd dou sau mai multe
fire folosesc o resurs comun. De aceeea este necesar un mecanism de coordonare a lucrului firelor cu resurse
comune. n Windows acest mecanism se numete sincronizarea firelor (thread synchronization).

72. Structura mecanismului de sincronizare n Windows (3.6.3)

Mecanismul de sincronizare este un set de obiecte ale sistemului de operare Windows, create i gestionate
program, comune pentru toate firele sistemului i utilizate pentru coordonarea accesului la resurse. n calitate de
resurse pot fi toate obiectele, care pot fi accesate de dou i mai multe fire un fiier pe disc, un port, un articol
al unei baze de date, o variabil global a unui program, accesibil firelor unui singur procesor, un obiect al
dispozitivului interfeei grafice (Graphic Device Interface), etc.
De obicei, sunt utilizate mecanismele (obiectele) de sincronizare, introduse mai sus: excluderea mutual
(mutex), secia critic (critical section), eveniment memorizat (event) i semaforul (semaphore), fiecare
realiznd metoda proprie de sincronizare. n calitate de obiecte sincronizate pot fi chiar procesele sau firele (cnd
un fir ateapt terminarea execuiei unui proces sau a unui alt fir), fiierele, dispozitivele de comunicaie, etc.
Sensul mecanismelor de sincronizare const n faptul, c fiecare poate s fie n starea set. Atunci cnd un fir
lucreaz cu mecanismele de sincronizare (le creeaz, le modific starea) sistemul nu ntrerupe execuia firului,
pn nu va fi terminat aceast aciune, adic toate operaiile finite din mecanismele de sincronizare sunt atomare
(nu pot fi ntrerupte).
Menionm de asemenea, c nu exist nici o legtur real ntre mecanismele de sincronizare i resurse.
Mecanismele de sincronizare nu pot interzice accesul nedorit la o resurs, ele doar indic firului momentul cnd
acesta poate accesa resursa, sau cnd acesta trebuie s atepte.
73. Administrarea obiectelor de sincronizare n Windows (3.6.4)
Crearea unui obiect de sincronizare se produce prin apelarea unei funcii speciale din WinAPI de tipul Create
(ex.,CreateMutex). Acest apel returneaz descriptorul obiectului (handle), care poate fi folosit de toate firele
procesului dat. Un obiect de sincronizare poate fi accesat i dintr-un alt proces, dac acest proces a motenit
descriptorul obiectului dat, sau folosind funcia de deschidere a unui obiect (Open). Obiectului, dac el nu este
destinat doar pentru uz intern (n interiorul unui singur proces), n mod obligator i se acord un nume unic. Nu
poate fi creat un eveniment memorizat i un semafor cu acelai nume.
Folosind descriptorul poate fi determinat starea curent a obiectului cu ajutorul funciilor de ateptare. De
exemplu, funcia WaitForSingleObject(x, y) cu doi parametri (primul este descriptorul obiectului, iar al doilea
timpul de ateptare n ms) returneaz WAIT_OBJECT_0, dac obiectul se afl n starea set (adic nu aparine
nici unui fir i poate fi utilizat pentru sincronizare), WAIT_TIMEOUT dac a expirat timpul de ateptare i
WAIT_ABANDONED, dac obiectul de sincronizare nu a fost eliberat nainte ca firul, care-l comanda, s se fi
terminat. Dac timpul de ateptare este egal cu 0, atunci funcia returneaz rezultatul imediat, n caz contrar,
ateapt intervalul de timp indicat. n cazul n care starea obiectului de sincronizare va deveni set pn la
expirarea acestui timp, funcia returneaz WAIT_OBJECT_0, altfel - WAIT_TIMEOUT.
Dac n parametrul timp este indicat constanta simbolic INFINITE, funcia va atepta pn cnd starea
obiectului va deveni set, fr vre-o restricie.
Starea mai multor obiecte poate fi aflat cu ajutorul funciei WaitForMultipleObjects. Pentru ncheierea
lucrului cu un obiect de sincronizare i eliberarea descriptorului se apeleaz funcia CloseHandle. Este
important de tiut, c apelarea unei funcii de ateptarea blocheaz firul curent, adic atta timp ct un fir se afl
n starea de ateptare el nu are acces la procesor.

74. Excluderea mutual (3.6.4.1)

Cum a fost menionat deja, mecanismele de excludere mutual (mutex-ele, de la MUTual EXclusion) permit
coordonarea accesului la o resurs partajat (processor de ex.). Starea set a obiectului corespunde momentului de timp n
care obiectul nu aparine nici unui fir i poate fi utilizat, iar starea reset momentului cnd un fir oarecare controleaz
deja mutex-ul. Accesarea va fi permis doar dup eliberare.
Pentru a lega mutex-ul de firul curent trebuie apelat una din funciile de ateptare. Firul, cruia i aparine mutex-ul, l
poate ocupa de mai multe ori, fr autoblocare, ns mai apoi acesta va trebui eliberat tot de attea ori cu ajutorul funciei
ReleaseMutex.

75. Evenimentele (3.6.4.2)

Obiectele-evenimente sunt utilizate pentru a informa firele, care sunt n ateptare, despre producerea unui eveniment. n
Windows exist dou tipuri de evenimente cu resetare manual i automat. Resetarea manual se execut cu funcia
ResetEvent. Aceste evenimente sunt folosite pentru informarea mai multor fire, iar evenimentele cu resetare automat sunt
utilizate pentru informarea unui anumit fir, celelalte rmnnd n ateptare.
Funcia CreateEvent creaz un obiect-eveniment, funcia SetEvent seteaz evenimentul n starea set, iar funcia
ResetEvent reseteaz evenimentul. Funcia PulseEvent seteaz evenimentul, iar dup semnalizarea firelor, care erau n
ateptare (toate n cazul resetrii manuale i doar unul la resetarea automat), reseteaz obiectul. Dac nu exist fire n
ateptare, PulseEvent doar reseteaz obiectul, fr semnalizare.