This shows you the differences between two versions of the page.
so:2012-2013:examen [2013/04/04 21:48] traian.popeea [Lucrări] |
— (current) | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ===== Examen ===== | ||
- | * Urmăriți precizările din [[:so:2012-2013:notare:reguli-notare-ca-cc|pagina de reguli]]. | ||
- | |||
- | ==== Examen final ==== | ||
- | |||
- | * Examenele finale ale cursului de Sisteme de Operare se vor desfășura astfel: | ||
- | * TODO | ||
- | * Rugăm să veniți în intervalul stabilit grupei voastre. Dacă, din motive obiective, nu puteți participa în data repartizată, trimiteți-i un e-mail lui [[traian.popeea@gmail.com|Traian]] cu subiectul "[SO] Transfer examen - Prenume Nume, Grupa". | ||
- | * Puteți participa la **un singur** examen. | ||
- | |||
- | ==== Lucrări ==== | ||
- | |||
- | * Nu există sesiune de contestații pentru lucrările de curs. În cazul în care considerați că au fost lipsuri la corectarea lucrării, trimiteți un e-mail lui [[traian.popeea@gmail.com|Traian]]. | ||
- | * Folosiți subiectul [SO][Lucrare X] Prenume Nume - grupa; de exemplu [SO][Lucrare 1] Andreea Popescu - 332CA. | ||
- | |||
- | === Lucrare 1 === | ||
- | |||
- | * 12 martie, 14:05-14:15, EC101, seria CA | ||
- | * 13 martie, 17:05-17:15, EC105, seria CC | ||
- | |||
- | == 3CA, nr. 1 == | ||
- | |||
- | - Fie P0 procesul părinte al procesului P1, T0 momentul de timp la care P0 execută apelul wait() și T1 momentul de timp la care P1 execută apelul exit(). În ce stare vor fi cele două procese în intervalul (T0, T1) dacă T0<T1? | ||
- | * **Răspuns** Procesul P0 este în starea WAITING, în așteptarea semnalului de la copil. Procesul P1 poate fi în orice stare, în funcție de codul său, dar va trece, cu siguranță, prin starea RUNNING pentru a putea executa apelul exit(). | ||
- | - Știind că apelul write(42, "X", 1), executat în procesul P, se întoarce cu succes, care este numărul minim de fișiere deschise **de** procesul P? De ce? Antetul apelului write este write(fd, *buf, count). | ||
- | * **Răspuns** Numărul minim de fișiere deschise **de** procesul P este 0, deoarece este posibil ca toate fișierele să fi fost deschise de părintele lui P. Numărul minim de fișiere deschise **în** procesul P este 1, și anume fișierul cu descriptorul 42, deoarece este posibil ca toți ceilalți descriptori de fișier să fie închiși. | ||
- | - Prezentați un avantaj al mapării spațiului de memorie al kernel-ului în spațiul de adresă al fiecărui proces. | ||
- | * **Răspuns** Prin maparea spațiului de memorie al kernel-ului în spațiul de adresă al fiecărui proces se evită schimbarea de context la fiecare apel de sistem, inclusiv apelul schedule(). | ||
- | |||
- | == 3CA, nr. 2 == | ||
- | |||
- | - Fie P0 procesul părinte al procesului P1, T0 momentul de timp la care P0 execută apelul wait() și T1 momentul de timp la care P1 execută apelul exit(). În ce stare vor fi cele două procese în intervalul (T1, T0) dacă T1<T0? | ||
- | * **Răspuns** Procesul P0 poate fi în orice stare, în funcție de codul său, dar va trece, cu siguranță, prin starea RUNNING pentru a putea executa apelul wait(). Procesul P1 este în starea TERMINATED (zombie), deoarece și-a încheiat execuția și așteaptă să îi fie citită valoarea de ieșire de către părinte. | ||
- | - Fie secvența de pseudocod:<code> | ||
- | for (i = 0; i < 42; i++) | ||
- | printf(...);</code>Care este numărul minim, respectiv numărul maxim de apeluri de sistem din secvența de mai sus? | ||
- | * **Răspuns** Numărul minim de apeluri de sistem din secvența de mai sus este 0. Dacă printf scrie la terminal, este line buffered și nu se va executa apel de sistem dacă nu se umple buffer-ul sau nu a fost primit caracterul '\n'. Numărul maxim de apeluri de sistem este 42, dacă în fiecare iterație a for-ului se umple buffer-ul sau a fost primit caracterul '\n'. | ||
- | - De ce un proces orfan nu poate deveni zombie? | ||
- | * **Răspuns** Deoarece un proces orfan este adoptat imediat de init, este imposibil ca el să devină zombie. Acesta execută wait pentru fiecare proces copil al său, care și-a încheiat execuția, împiedicând ca acesta să devină zombie. | ||
- | |||
- | == 3CC, nr. 1 == | ||
- | |||
- | - De ce apelul fclose realizează în spate apel de sistem, dar apelul printf nu întotdeauna? | ||
- | * **Răspuns** Apelul fclose realizează în spate apel de sistem, deoarece închide un fișier, modificând tabela de descriptori din proces. Apelul fclose se mapează pe apelul de sistem close. Apelul printf scrie într-un buffer, iar apelul de sistem write se realizează dacă se umple buffer-ul sau a fost primit caracterul '\n'. | ||
- | - Fie P1 și P2 două procese diferite. Când este posibil ca modificarea cursorului de fișier pentru un descriptor din P1 să conducă la modificarea cursorului de fișier pentru un descriptor din P2? | ||
- | * **Răspuns** Această situație este posibilă dacă cele două procese au un proces "strămoș" comun și descriptorul de fișier nu a fost închis de niciunul dintre procese. Atunci, modificarea cursorului de fișier pentru un descriptor din P1 poate conduce la modificarea cursorului de fișier pentru același descriptor din P2. | ||
- | - Fie P un proces zombie. Ce procese îl pot elimina din sistem prin apelul wait()? | ||
- | * **Răspuns** Procesele care pot elimina din sistem un proces zombie prin apelul wait() sunt: părintele său (dacă nu și-a încheiat execuția) și procesul init (care adoptă procesele orfane și execută wait pentru fiecare proces copil al său, care și-a încheiat execuția. | ||
- | |||
- | == 3CC, nr. 2 == | ||
- | |||
- | - În urma unui apel fork() pot rezulta între X și Y procese **noi**. Ce valori au X și Y? | ||
- | * **Răspuns** Dacă apelul fork() eșuează nu va fi creat niciun proces nou. Dacă apelul se execută cu succes, va fi creat un proces nou, copil al procesului care a executat fork(). Astfel, pot rezulta între 0 și 1 procese **noi**. X=0. Y=1. | ||
- | - Care este numărul minim de descriptori de fișier valizi în cadrul unui proces? În ce situație este posibilă această valoare? | ||
- | * **Răspuns** Numărul minim de descriptori de fișier valizi în cadrul unui proces este 0, în cazul în care un proces închide toți descriptori de fișier, inclusiv stdin, stdout, stderr. Un astfel de proces este numit daemon. | ||
- | - Dați două exemple de resurse care pot aparține unui proces, dar nu pot aparține unui program. | ||
- | * **Răspuns** Procesul reprezintă o instanță activă activă a unui program. Resursele care pot aparține unui proces, dar nu pot aparține unui program sunt: memoria, CPU-ul, PCB-ul (PID, spațiul de adresă - zonele de date, cod, heap, stivă, tabela de descriptori, masca de semnale, etc.). | ||
- | |||
- | === Lucrare 2 === | ||
- | |||
- | * 2 aprilie, 14:05-14:15, EC101, seria CA | ||
- | * 3 aprilie, 17:05-17:15, EC105, seria CC | ||
- | |||
- | == 3CA, nr. 1 == | ||
- | |||
- | - De ce un planificator echitabil (fair) nu este, în general, productiv (nu oferă un throughput mare)? | ||
- | * **Răspuns** Un planificator echitabil implică schimbări de context dese, astfel că este petrecut un timp relativ mare cu schimbările de context, scăzând productivitatea. | ||
- | - De ce este necesară folosirea mutex-urilor, și nu a spinlock-urilor, pentru regiunile critice cu operații de I/O? | ||
- | * **Răspuns** Regiunile critice cu operații de I/O sunt, de obicei, lungi. De asemenea, operatiile I/O pot duce la blocarea thread-ului, caz în care nu poate fi folosit spinlock-ul. | ||
- | - De ce numărul de pagini virtuale dintr-un sistem este mai mare decât numărul de pagini fizice? | ||
- | * **Răspuns** Numărul de pagini fizice este limitat de dimensiunea memoriei RAM, în timp ce numărul de pagini virtuale este determinat de numărul de procese. În cazul memoriei partajate de două sau mai multe procese, pot exista mai multe pagini virtuale mapate pe aceeași pagină fizică. | ||
- | |||
- | == 3CA, nr. 2 == | ||
- | |||
- | - În ce situație este posibil ca un proces să treacă **direct** din starea WAITING în starea TERMINATED? | ||
- | * **Răspuns** Un proces va trece direct din starea WAITING în starea TERMINATED dacă primește un semnal care nu poate fi ignorat sau suprascris, precum SIGKILL sau SIGQUIT, care conduce la terminarea procesului, indiferent de context. | ||
- | - În ce situație este posibilă apariția unui deadlock pe o singură resursă critică? | ||
- | * **Răspuns** Fie procesul P1 care a acaparat resursa critică și procesele P2, P3, ... , Pn care așteaptă eliberarea resursei respective. Un deadlock pe resursa respectivă va apărea dacă procesul P1 nu va elibera resursa critică, fie datorită codului său (nu există instrucțiunea de release/unlock, intră într-un ciclu infinit, etc.), fie deoarece a fost terminat prin semnal SIGKILL. | ||
- | - De ce paginarea ierarhică are un overhead de prelucrare mai mare decât paginarea neierarhică? | ||
- | * **Răspuns** În cazul paginării neierarhice, numărul paginii virtuale este și indexul în tabela de pagini, deci va exista un singur acces la memorie pentru aflarea paginii fizice. În cazul paginării ierarhice se vor face atâtea accese la memorie, cât numărul de niveluri ierarhice. | ||
- | |||
- | == 3CC, nr. 1 == | ||
- | |||
- | - De ce nu mai este folosită planificarea cooperativă în sistemele desktop moderne? | ||
- | * **Răspuns** | ||
- | - Care este principală sursă de overhead la schimbarea de context între două procese? | ||
- | * **Răspuns** | ||
- | - De ce nu este necesară eliminarea paginilor de memorie ale kernel-ului din TLB în cazul unei schimbări de context? | ||
- | * **Răspuns** | ||
- | |||
- | == 3CC, nr. 2 == | ||
- | |||
- | - De ce, pe un sistem desktop, de obicei, sunt mai multe procese în starea WAITING decât în starea READY? | ||
- | * **Răspuns** | ||
- | - Descrieți două diferențe între un mutex și un semafor binar. | ||
- | * **Răspuns** | ||
- | - Fie un sistem cu paginare ierarhică pe două niveluri, fără TLB. Pot două pagini de memorie virtuală referi aceeași pagină de memorie fizică? | ||
- | * **Răspuns** | ||
- | |||
- | === Lucrare 3 === | ||
- | |||
- | * 23 aprilie, 14:05-14:15, EC101, seria CA | ||
- | * 24 aprilie, 17:05-17:15, EC105, seria CC | ||
- | |||
- | == 3CA, nr. 1 == | ||
- | |||
- | == 3CA, nr. 2 == | ||
- | |||
- | == 3CC, nr. 1 == | ||
- | |||
- | == 3CC, nr. 2 == | ||
- | |||
- | === Lucrare 4 === | ||
- | |||
- | * 21 mai, 14:05-14:15, EC101, seria CA | ||
- | * 22 mai, 17:05-17:15, EC105, seria CC | ||
- | |||
- | == 3CA, nr. 1 == | ||
- | |||
- | == 3CA, nr. 2 == | ||
- | |||
- | == 3CC, nr. 1 == | ||
- | |||
- | == 3CC, nr. 2 == | ||
- | |||
- | == Examene anterioare == | ||
- | |||
- | {{indexmenu>:examen#1|rsort}} |