Show page

Differences

This shows you the differences between two versions of the page.

--- so:meta:examen [2019/03/18 17:39]
maria.mihailescu [Lucrare 1]
+++ so:meta:examen [2021/03/04 15:33] (current)
maria.mihailescu
@@ Line 1: / Line 1: @@
 ====== Examen ======
-Urmăriți precizările din [[:so:meta:notare|pagina de reguli]].
+{{section>so:meta:examen:2020-2021&noheader&nofooter&noindent}}
+<spoiler>
+<hidden>
+====== Template pentru anii următori ======
 ===== Examen final =====
 Puteți participa la **un singur** examen final.
-Datele de examen de SO pentru sesiunea iunie 2019 sunt:
+Datele de examen de SO pentru sesiunea iunie 2020 sunt:
+  * TODO
+  * TODO
   * TODO
@@ Line 38: / Line 43: @@
 ==== Lucrare 1 ====
-  * La începutul cursului 4:
+  * La începutul cursului TBA:
-    * 11.03.2019, seria CA
+    * TBA, seria CA
-    * 13.03.2019, seria CB
+    * TBA, seria CB
-    * 13.03.2019, seria CC
+    * TBA, seria CC
 === 3CA, varianta 1 ===
-  - Explicaţi de ce apelul ''printf(”aici”)'' înainte de o instrucţiune care accesează o zonă de memorie invalidă nu afişează nimic la consolă.
+  - TODO
-    * **Răspuns**: Biblioteca va stoca local mesajul aici pentru a-l trimite la consolă atunci când bufferul se umple sau utilizatorul scrie EOL (i.e. \n). Atunci când procesul este întrerupt în urma accesului invalid la memorie, bufferul nu mai este scris la consolă.
+    * **Răspuns**: TODO
-  -  Explicați semnificația stării RUNNING în viața unui proces și tranzițiile posibile din această stare.
+  -  TODO
-    * **Răspuns**: Procesul se află în execuție pe procesor. Dacă îi expiră cuanta va merge în starea READY; dacă face un apel blocant va tranziționa în starea WAITING. Dacă își încheie executța va ajunge în starea TERMINATED.
+    * **Răspuns**: TODO
-  - Ce valori va afișa execuția codului următor atunci când fork reușește? <code C>
+  - TODO
-  int i = 0;
+    * **Răspuns**: TODO
-  if (fork()==0)
-      i++;
-  else sleep(1);
-  printf(”%d\n”,i); </code>
-    * **Răspuns**: Va afișa 1 (scris de copil) urmat de 0 (scris de părinte).
 === 3CA, varianta 2 ===
-  - Explicați de ce apelul ''fwrite(..)'' este mai rapid decât ''write(..)'' atunci când facem multe scrieri.
+  - TODO
-    * **Răspuns**: fwrite scrie într-un buffer în memoria procesului și execută write cu mai multe date, reducând numărul de apeluri de sistem. Apelurile de sistem sunt costisitoare, iar reducerea lor creste performanța.
+    * **Răspuns**: TODO
-  - Explicați semnificația stării READY în viața unui proces și tranzițiile către această stare.
+  -  TODO
-    * **Răspuns**: Procesul este gata să ruleze însa așteaptă să fie planificat. Un proces ajunge în READY după ce este pornit, dacă este RUNNING si este preemptat, sau dacă este WAITING și operația pe care o asteptă se termină.
+    * **Răspuns**: TODO
-  - Câte procese noi vor fi create la execuția codului următor atunci când fork reușește? <code C>
+  - TODO
-int i = 0;
+    * **Răspuns**: TODO
-for (i = 0;i<5;i++)
-  if (fork()>0)
-     break; </code>
-    * **Răspuns**: Vor fi create 5 procese noi; de fiecare dată părintele își încheie execuția și copilul va continua bucla pâna când i devine 5.
 === 3CB, varianta 1 ===
-  - Numiți un rol al bibliotecilor în sistemul de operare și exemplificați.
+  - TODO
-    * **Răspuns**: Permit refolosirea codului de mai multe procese; o singură bibliotecă poate să fie mapată în memoria mai multor procese ocupând mai puțină memorie fizică. De asemenea, o bibliotecă poate fi o interfață între nucleu și procese.
+    * **Răspuns**: TODO
-  - Fie secvența ''int fd2 = dup(fd)''. Execuția apelului de sistem ''write'' pe fd2 va influența în vreun fel apelurile ce folosesc ca parametru **fd**? Explicați.
+  -  TODO
-    * **Răspuns**: Da, deoarece file offset-ul din structura alocată în kernel se va modifica prin apelul write pe fd2.
+    * **Răspuns**: TODO
-  - Care este diferența între un proces zombie și unul orfan?
+  - TODO
-    * **Răspuns**: Un proces orfan este un proces al cărui părinte a murit, iar unul zombie este un proces care a murit, dar la care părintele nu a făcut wait.
+    * **Răspuns**: TODO
 === 3CB, varianta 2 ===
-  - Care este motivul pentru care există noțiunea de “apel de sistem” într-un sistem de operare? De ce nu se fac pur și simplu apeluri simple de funcție?
+  - TODO
-    * **Răspuns**: Pentru izolarea proceselor, anumite funcționalități care pot influența alte procese sau integritatea sistemului au nevoie de un schimb de context către kernel unde se verifică dacă procesul are permisiunile necesare pentru efectuarea operației.
+    * **Răspuns**: TODO
-  - Fie secvența ''int fd2 = dup(fd)''. Execuția apelului de sistem ''write'' pe fd va influența în vreun fel apelurile ce folosesc ca parametru **fd2**? Explicați.
+  -  TODO
-    * **Răspuns**: Da, deoarece file offset-ul din structura alocată în kernel se va modifica prin apelul write pe fd.
+    * **Răspuns**: TODO
-  - Numiți un avantaj și un dezavantaj al structurării ierarhice al proceselor într-un sistem de operare (în comparație de exemplu cu o structură liniară). Explicați.
+  - TODO
-    * **Răspuns**: Reprezentarea proceselor într-o ierarhie ajută la partajarea de date între procesul părinte și procesul copil, însă implementarea este mai dificilă, deoarece trebuie păstrate mereu legături cu procesul părinte (ex. Procesele orfane sunt adoptate de init).
+    * **Răspuns**: TODO
 === 3CC, varianta 1 ===
-  - De ce preferăm să folosim un apel de bibliotecă care NU realizează în spate un apel de sistem în locul unui apel de bibliotecă ce face apel de sistem? De exemplu ''fwrite()'' în loc de ''write()''.
+  - TODO
-    * **Răspuns**: Un apel de sistem are un overhead mai mare decât un apel simplu de funcție întrucât se face schimbarea nivelului de privilegiu la apel și revenirea din apel, care consumă timp. Din acest motiv, dacă avem de ales, optăm pentru funcții de bibliotecă ce nu fac apel de sistem ca să reducem overhead-ul.
+    * **Răspuns**: TODO
-  - Fie apelul ''close(fd)'' executat cu succes. Observăm că structura de fișier deschis referită de descriptorul fd (acum închis) nu este eliberată din memorie. De ce?
+  -  TODO
-    * **Răspuns**: pelul ''close(fd)'' invalidează descriptorul fd și decrementează contorul de referință din structura de fișier deschis. Structura este dezalocată în momentul în care contorul de referință este 0. Dacă după ''close(fd)'' structura de fișier deschis nu a fost dezalocată înseamnă că mai există un descriptor care o referă, descriptor care a fost obținut printr-un apel ''dup()'' sau ''dup2()''. Un apel ''open()'' nu este un răspuns corect, pentru că acela creează o structură nouă de fișier deschis.
+    * **Răspuns**: TODO
-  - Un proces zombie devine și proces orfan: procesul său părinte își încheie execuția. Ce se întâmplă acum cu procesul zombie rămas orfan?
+  - TODO
-    * **Răspuns**: Un proces orfan, indiferent dacă este zombie sau nu este adoptat de init. Apoi init face “reaping” în procesele zombie, așteptându-le și eliminându-le astfel complet din sistemul de operare.
+    * **Răspuns**: TODO
 === 3CC, varianta 2 ===
-  - Dați exemplu de acțiune care poate fi executată doar în modul privilegiat (kernel mode). Justificați de ce acea acțiune nu poate fi executată în modul neprivilegiat (user mode).
+  - TODO
-    * **Răspuns**: Acțiuni care pot fi executate doar în kernel mode sunt: lucrul cu I/O, forme de IPC (Inter-Process Communication), alocarea memorie. Acestea sunt privilegiate pentru a garanta integritatea sistemului și izolarea proceselor. Dacă ar fi executate în mod neprivilegiat, un proces ar avea acces la datele altui proces, i-ar putea suprascrie și corupe informații. Cu atât mai mult cu cât dorim separație între procese privilegiate (ce aparțin utilizatorului root) și procese neprivilegiate.
+    * **Răspuns**: TODO
-  - Ce câmpuri din structura de fișier deschis și din structura de fișier de pe disc (FCB: File Control Block) modifică apelul ''write()''? Argumentați răspunsul.
+  -  TODO
-    * **Răspuns**:  Apelul ''write()'' modifică pointer-ul/cursorul de fișier, îl crește cu numărul de octeți scriși în fișier; cursorul de fișier este reținut în structura de fișier deschis. În plus, dacă în urma scrierii octeților se trece de limita fișierului, atunci se modifică și dimensiunea fișierului; dimensiunea fișierului este reținută în structura de fișier de pe disc (FCB).
+    * **Răspuns**: TODO
-  - Ce efect are, la nivel de implementare, folosirea operatorului ''&'' în shell?
+  - TODO
-    * **Răspuns**: Atunci când folosim operatorul ''&'' în shell, shell-ul nu mai așteaptă încheierea procesului nou creat. Adică shell-ul nu apelează wait() și nu se blochează în așteptarea încheierii execuției procesului. Din acest motiv shell-ul poate primi noi comenzi de la terminal.
+    * **Răspuns**: TODO
 === Greșeli frecvente ===
-  * Confuzie între procesele **zombie** și procesele **orfan**. Un proces zombie este un proces care și-a terminat execuția, dar pe care nu l-a "așteptat" părintele, iar un proces orfan este un proces al cărui părinte și-a încheiat execuția.
-  * Confuzie între kernel mode și utilizator privilegiat. Chiar dacă utilizatorul root este privilegiat, este doar un utilizator. În continuare se face diferențierea între user mode și kernel mode.
-  * Greșeli legate de utilizarea ''&'' în shell. În shell, ''&'' are rolul de a duce un proces în background, nu de a face o dereferențiere (ca de exemplu în C) sau de operator logic //AND// între comenzi (precum ''&&'').
-  * Confuzie între procesele trimise în background și daemoni. Unui proces trimis în background **NU** i se închid ''stdin'', ''stdout'' și ''stderr''.
 === Lucrări foarte bune ===
-  * APOSTOL Teodor-Petruț, 336CA
-  * ŞENDRE Mihai-Alin, 332CC
-  * RADU Valentin-Gabriel, 333CC
-  * BĂLĂNICĂ Darius, 334CC
-  * COCOŞ Vlad, 334CC
-  * DUMITRU Philip, 334CC
-  * VIŞAN Anamaria, 334CC
-  * FOLEA Rareş, 336CC
-  * ILIE Vlad-Florin 331CB
-  * POPESCU Teodor-Constantin 333CB
-  * SMĂDU Răzvan-Alexandru 335CB
-  * FIRUŢI Bogdan-Cristian, 331CA
-  * IVAN Vlad, 331CA
-  * VASILE Cristian-Ştefan, 331CA
-  * ANDREI Rareş, 332CA
-  * DRAGOMIR Horia-Alexandru, 333CA
-  * POPA Bogdan, 333CA
-  * BUCUR Adrian-Cătălin, 336CA
-  * MARICA Andreea-Mădălina, 336CA
@@ Line 144: / Line 114: @@
-  * La începutul cursului 7:
+  * La începutul cursului TBA:
-    * 01.04.2019, seria CA
+    * TBA, seria CA
-    * 03.04.2019, seria CB
+    * TBA, seria CB
-    * 03.04.2019, seria CC
+    * TBA, seria CC
 === 3CA, varianta 1 ===
@@ Line 153: / Line 123: @@
   - TODO
     * **Răspuns**: TODO
-  - TODO
+  -  TODO
     * **Răspuns**: TODO
   - TODO
@@ Line 163: / Line 133: @@
   - TODO
     * **Răspuns**: TODO
-  - TODO
+  -  TODO
     * **Răspuns**: TODO
   - TODO
     * **Răspuns**: TODO
 === 3CB, varianta 1 ===
@@ Line 173: / Line 142: @@
   - TODO
     * **Răspuns**: TODO
-  - TODO
+  -  TODO
     * **Răspuns**: TODO
   - TODO
@@ Line 182: / Line 151: @@
   - TODO
     * **Răspuns**: TODO
-  - TODO
+  -  TODO
     * **Răspuns**: TODO
   - TODO
@@ Line 191: / Line 160: @@
   - TODO
     * **Răspuns**: TODO
-  - TODO
+  -  TODO
     * **Răspuns**: TODO
   - TODO
@@ Line 201: / Line 170: @@
   - TODO
     * **Răspuns**: TODO
-  - TODO
+  -  TODO
     * **Răspuns**: TODO
   - TODO
@@ Line 208: / Line 177: @@
 === Greșeli frecvente ===
 === Lucrări foarte bune ===
@@ Line 215: / Line 183: @@
 ==== Lucrare 3 ====
-  * La începutul cursului 10:
+  * La începutul cursului TBA:
+    * TBA, seria CA
-    * 22.04.2019, seria CA
+    * TBA, seria CB
-    * 24.04.2019, seria CB
+    * TBA, seria CC
-    * 24.04.2019, seria CC
 === 3CA, varianta 1 ===
@@ Line 225: / Line 192: @@
   - TODO
     * **Răspuns**: TODO
-  - TODO
+  -  TODO
     * **Răspuns**: TODO
   - TODO
     * **Răspuns**: TODO
 === 3CA, varianta 2 ===
@@ Line 235: / Line 201: @@
   - TODO
     * **Răspuns**: TODO
-  - TODO
+  -  TODO
     * **Răspuns**: TODO
   - TODO
@@ Line 244: / Line 210: @@
   - TODO
     * **Răspuns**: TODO
-  - TODO
+  -  TODO
     * **Răspuns**: TODO
   - TODO
     * **Răspuns**: TODO
 === 3CB, varianta 2 ===
@@ Line 254: / Line 219: @@
   - TODO
     * **Răspuns**: TODO
-  - TODO
+  -  TODO
     * **Răspuns**: TODO
   - TODO
     * **Răspuns**: TODO
 === 3CC, varianta 1 ===
@@ Line 264: / Line 228: @@
   - TODO
     * **Răspuns**: TODO
-  - TODO
+  -  TODO
     * **Răspuns**: TODO
   - TODO
@@ Line 274: / Line 238: @@
   - TODO
     * **Răspuns**: TODO
-  - TODO
+  -  TODO
     * **Răspuns**: TODO
   - TODO
@@ Line 281: / Line 245: @@
 === Greșeli frecvente ===
+ .
@@ Line 289: / Line 253: @@
 ==== Lucrare 4 ====
-  * La începutul cursului 13:
+  * La începutul cursului TBA:
-    * 20.05.2019, seria CA
+    * TBA, seria CA
-    * 22.05.2019, seria CB
+    * TBA, seria CB
-    * 22.05.2019, seria CC
+    * TBA, seria CC
 === 3CA, varianta 1 ===
@@ Line 298: / Line 262: @@
   - TODO
     * **Răspuns**: TODO
-  - TODO
+  -  TODO
     * **Răspuns**: TODO
   - TODO
@@ Line 308: / Line 272: @@
   - TODO
     * **Răspuns**: TODO
-  - TODO
+  -  TODO
     * **Răspuns**: TODO
   - TODO
@@ Line 318: / Line 282: @@
   - TODO
     * **Răspuns**: TODO
-  - TODO
+  -  TODO
     * **Răspuns**: TODO
   - TODO
@@ Line 327: / Line 291: @@
   - TODO
     * **Răspuns**: TODO
-  - TODO
+  -  TODO
     * **Răspuns**: TODO
   - TODO
@@ Line 336: / Line 300: @@
   - TODO
     * **Răspuns**: TODO
-  - TODO
+  -  TODO
     * **Răspuns**: TODO
   - TODO
@@ Line 346: / Line 310: @@
   - TODO
     * **Răspuns**: TODO
-  - TODO
+  -  TODO
     * **Răspuns**: TODO
   - TODO
@@ Line 353: / Line 317: @@
 === Greșeli frecvente ===
 === Lucrări foarte bune ===
+</hidden>
+</spoiler>
 ===== Examene anterioare =====
+  * [[:so:meta:examen:2019-2020 | Examene și lucrări 2019-2020]]
+  * [[:so:meta:examen:2018-2019 | Examene și lucrări 2018-2019]]
   * [[:so:meta:examen:2017-2018 | Examene și lucrări 2017-2018]]
   * [[:so:meta:examen:2016-2017 | Examene și lucrări 2016-2017]]

Informații generale SO

Informații SO 2021-2022

Laboratoare

Curs

Accesibile pe GitHub, în organizația Open Education Hub, cu deployment prin Docusaurus.

Cursuri vechi

Teme

so/meta/examen.1552923586.txt.gz · Last modified: 2019/03/18 17:39 by maria.mihailescu

Show page Old revisions

Media Manager Back to top