Differences
This shows you the differences between two versions of the page.
|
so:meta:examen:2019-2020 [2020/05/20 00:52] dragos_florin.costea [Examen final] |
so:meta:examen:2019-2020 [2020/08/22 00:21] (current) dragos_florin.costea [Examen final] |
||
|---|---|---|---|
| Line 4: | Line 4: | ||
| ===== Examen final ===== | ===== Examen final ===== | ||
| - | Puteți participa la **un singur** examen final. | + | <note important> |
| + | Consultați [[https://docs.google.com/document/d/e/2PACX-1vRlcVhbiPUIZ2bGS2k4VJDdBTlXyxQbU166hL-_XKlnhKh0m3VpSQVNJiFYwH-QCF5CPUz00nnmXLUI/pub|ghidul pentru studenți al examenului de SO]]. | ||
| + | |||
| + | Consultați [[https://docs.google.com/document/d/e/2PACX-1vS10vLsN9jtxbYkrkBE7p3MKm0fq0Yk22_qfasxRlrRgGVjegDnD3dIvvc2cj_d83suM0_H2CEJTn9z/pub|lista de întrebări]] de la care vom porni discuția pe parcursul examenului. | ||
| + | </note> | ||
| + | |||
| + | Puteți participa **o singură** dată pe sesiune la examenul final. | ||
| + | |||
| + | ==== Sesiunea din toamnă, august 2020 ==== | ||
| + | |||
| + | Datele de examen de SO pentru sesiunea din toamnă, august 2020, sunt: | ||
| + | * marți, 25 august 2020, 9-11. | ||
| + | * miercuri, 26 august 2020, 9-11. | ||
| + | |||
| + | ==== Sesiunea din vară, mai 2020 ==== | ||
| Datele de examen de SO pentru sesiunea mai 2020 sunt: | Datele de examen de SO pentru sesiunea mai 2020 sunt: | ||
| Line 11: | Line 25: | ||
| * joi, 28 mai 2020, 9-11 și 12-14, seria 3CB. | * joi, 28 mai 2020, 9-11 și 12-14, seria 3CB. | ||
| - | Puteți veni o singură dată la examen. | + | ==== Desfășurare examen ==== |
| Având în vedere situația din acest an, examenul de SO din această sesiune se va desfășura exclusiv online. Modul de examinare va fi asemănător unui examen oral sau al unui interviu. Vom folosi Microsoft Teams ca mediu de comunicare. | Având în vedere situația din acest an, examenul de SO din această sesiune se va desfășura exclusiv online. Modul de examinare va fi asemănător unui examen oral sau al unui interviu. Vom folosi Microsoft Teams ca mediu de comunicare. | ||
| Examenul de SO va consta într-un //call// / interviu de 15 minute cu doi supraveghetori. În decursul acestui examen oral, studentul va fi rugat să răspundă la câteva întrebări din materia de SO adresate de către supraveghetori. Răspunsurile date de către student la întrebarile supraveghetorilor vor fi evaluate cu un punctaj. Nota obținută în cadrul examenului va fi suma punctajelor obținute la toate întrebările. | Examenul de SO va consta într-un //call// / interviu de 15 minute cu doi supraveghetori. În decursul acestui examen oral, studentul va fi rugat să răspundă la câteva întrebări din materia de SO adresate de către supraveghetori. Răspunsurile date de către student la întrebarile supraveghetorilor vor fi evaluate cu un punctaj. Nota obținută în cadrul examenului va fi suma punctajelor obținute la toate întrebările. | ||
| - | În timpul examenului veți putea consulta orice materiale scrise sau online. **Nu se permisă** comunicarea, fie fizică, fie online (Messenger, Instagram, WhatsApp etc.) cu alte persoane în afară de supraveghetori în timpul examenului. | ||
| - | Echipa de SO va organiza o sesiune de simulare cu 8 studenți, sâmbătă, 23 mai 2020, ora 14:00, unde ceilalți studenți vor putea participa ca public. | + | În timpul examenului veți putea consulta orice material scris sau online. **Nu este permisă** comunicarea, fie fizică, fie online (Messenger, Instagram, WhatsApp etc.) cu alte persoane în afară de supraveghetori în timpul examenului. |
| - | Precizăm că va trebui să aveți la dispoziție o cameră video pentru a vă confirma identitatea, împreună cu un act de identitate. Dacă există situații obiective în care nu veți avea o cameră video în timpul examenului, trimiteți un e-mail către [[dragosflorincostea@gmail.com|Dragoș]] cu subiectul ''[SO][Examen] Cameră video: Prenume NUME, grupă'', de exemplu ''[SO][Examen] Cameră video: Ana POPESCU, 332CB''. | + | Vom organiza o simulare de examen sâmbătă, 23 mai 2020, ora 14:00, pe Microsoft Teams, 2 ore cu 8 studenți. Vor putea participa toți studenții și toți asistenții dar doar 8 studenți vor fi examinați. Ceilalți studenți vor asista. Simularea se înregistrează, iar studenții nu vor porni camera (din considerente de privacy). |
| - | Studenții de anul 3 pot veni în alte zile față de cea aferentă grupei/seriei lor. Studenții în alte situații (de exemplu transferați de la IS) pot veni oricând. Cei care doresc să vină în altă zi față de cele alocate, să trimită un e-mail către [[dragosflorincostea@gmail.com|Dragoș]] cu subiectul ''[SO][Examen] Transfer: Prenume NUME, grupă'', de exemplu ''[SO][Examen] Transfer: Ana POPESCU, 332CB''. | + | Precizăm că va trebui să aveți la dispoziție, în timpul examenului, o cameră video pentru a vă confirma identitatea, împreună cu un act de identitate. Dacă există situații obiective în care nu veți avea o cameră video în timpul examenului, trimiteți un e-mail către [[dragosflorincostea@gmail.com|Dragoș]] cu subiectul ''[SO][Examen] Cameră video: Prenume NUME, grupă'', de exemplu ''[SO][Examen] Cameră video: Ana POPESCU, 332CB''. |
| Informații despre desfășurătorul și conținutul examenului găsiți în [[:so:meta:notare#examen_4_puncte|secțiunea aferentă din pagina de notare]]. În pregătirea examenului puteți să parcurgeți [[:so:meta:examen#examene_anterioare|subiectele de examen anterioare]]. | Informații despre desfășurătorul și conținutul examenului găsiți în [[:so:meta:notare#examen_4_puncte|secțiunea aferentă din pagina de notare]]. În pregătirea examenului puteți să parcurgeți [[:so:meta:examen#examene_anterioare|subiectele de examen anterioare]]. | ||
| Urmăriți precizările din [[:so:meta:notare|pagina de reguli]]. | Urmăriți precizările din [[:so:meta:notare|pagina de reguli]]. | ||
| + | |||
| Line 286: | Line 300: | ||
| * 13.05.2020, seria CC | * 13.05.2020, seria CC | ||
| - | === 3CA, varianta 1 === | + | === 3CA === |
| - | - TODO | + | - Explicați diferența dintre spinlock si mutex și descrieți un caz în care folosirea fiecăruia este eficientă. |
| - | * **Răspuns**: TODO | + | * **Răspuns**: Blocarea unui spinlock realizează busy waiting atunci când thread-ul încearcă să obțină un lock care este deja blocat, această operație ocupând timp inutil pe procesor. Prin contrast, un mutex va face ca thread-ul care a încercat blocarea lock-ului să fie scos de pe procesor, economisind cicli de ceas cât timp mutexul nu este eliberat. Datorită overhead-ului necesar pentru scoaterea de pe procesor a thread-ului, uun spinlock este mai eficient pentru zone critice mici, dar costisitor pentru zone critice de dimensiuni mai mari. |
| - | - TODO | + | - Argumentațiu diferența între operații non-blocante și operații asincrone. Scrieți câte un exemplu. |
| - | * **Răspuns**: TODO | + | * **Răspuns**: O operație de transfer non-blocantă asigură că sistemul nu se va bloca pentru așteptarea terminării operației, însă nu specifică modul de terminare a operației. Operațiile non-blocante se pot realiza sincron, iar rezultatul întors de funcția de transfer reprezintă cantitatea de date care a putut fi transmisă imediat, sau în mod asincron, atunci când transferul este pornit, dar executat în paralel de o altă unitate de execuție decât thread-ul care l-a pornit. Exemplu de operație non-blocantă: read care are setat flag-ul O_NONBLOCK. Exemplu de operație asincronă: ReadFile pe un fișier deschis cu FILE_FLAG_OVERLAPPED. |
| - | - TODO | + | - După repornirea forțată a unui sistem observăm că avem un fișier _special_ pe disc al cărui conținut se modifică din când în când fără ca data lui de scriere să se modifice. Explicați fenomenul. |
| - | * **Răspuns**: TODO | + | * **Răspuns**: Oprirea forțată a sistemului a dus sistemul de fișiere într-o stare inconsistentă în care doar inode-ul fișierului “special” a fost actualizat, fără ca bitmap-ul blocurilor de date să fie actualizat. Fișierul practic deține un bloc de date marcat ca fiind liber. Acesta va putea fi folosit de alte fișiere, explicând modificarea anormală a conținutului fișierului nostru “special”. Sistemele de fișiere moderne cu jurnalizare previn acest lucru. |
| - | === 3CA, varianta 2 === | + | === 3CB === |
| - | - TODO | + | - Un programator dorește să proceseze un volum mare de date încărcate în memorie, stocate într-un vector. Pentru a le procesa în paralel, își definește global un pointer cu rol de iterator peste vector, și îl folosește în threadurile create. La rulare primește eroare de acces invalid la memorie. De ce se întâmplă acest lucru? Argumentați răspunsul. |
| - | * **Răspuns**: TODO | + | * **Răspuns**: Deși un pointer are dimensiunea cuvântului procesorului (adică poate fi scris din registru în memorie într-o singură operație), un pointer nealiniat va necesita două scrieri succesive. Greșeala fundamentală în abordare este că iteratorul nu este protejat de la accesul concurent, însă această greșeală ar cauza doar rezultate incorecte / nedeterministe. Motivul pentru care se primește segfault este că un thread citește iteratorul când acesta este scris pe jumătate, fiind în acel moment de timp un pointer invalid. O altă variantă posibilă: Dacă accesul la variabile nu este protejat, un thread care realizează citirea pointer-ului și verificarea limitelor array-ului, dar care este scos de pe procesor înainte de accesarea datelor, ar putea realiza un acces invalid la memorie prin utilizarea unei valori care a devenit invalidă între timp. Atât accesul la iterator, cât și la array ar trebui protejate prin intermediul unui mutex comun. |
| - | - TODO | + | - Este mai sigură folosirea instrucțiunii de asamblare “inc [ebp - 16]” decât setul “mov eax, [ebp - 16]; inc eax; mov [ebp - 16], eax” din punctul de vedere al sincronizării? Argumentați răspunsul. |
| - | * **Răspuns**: TODO | + | * **Răspuns**: Instrucțiunile x86 se traduc la rândul lor în instrucțiuni elementare, interne procesorului (microcod). Deși instrucțiunea inc este singulară la nivel de ISA, la nivel de microcod ea va fi alcătuită dintr-un fetch din RAM, adunare, și stocare înapoi în RAM. Prin urmare, la fel ca și varianta cu add, nu oferă nicio garanție de sincronizare pentru procesoare multicore. |
| - | - TODO | + | - Observăm că pe un sistem cu disk caching activat, citirea datelor dintr-un fișier de pe disc durează de fiecare dată foarte mult timp, chiar dacă sunt efectuate în mod repetat operații pe aceleași date. Care ar putea fi o cauză pentru acest fenomen? Argumentați răspunsul. |
| - | * **Răspuns**: TODO | + | * **Răspuns**: Un scenariu posibil ar fi citirea integrală și repetată a unui fișier mult mai mare față de memoria RAM liberă. Din cauză că SO-ul nu are un cache îndeajuns de mare, va fi nevoit să citească paginile de pe disk. O alternativă este încărcarea foarte mare a sistemului, astfel încât nu mai este suficient loc în memorie pentru cache-ul fișierelor. |
| + | === 3CC === | ||
| - | === 3CB, varianta 1 === | + | - O bibliotecă oferă funcția atomic_inc(&value) pentru incrementarea în mod atomic a unei variabile “value” de tip întreg (int), aflată în memorie la adresa &value. Precizați și motivați secvența în limbaj de asamblare x86 folosită pentru implementarea părții atomice a acestei funcții. |
| - | + | * **Răspuns**: lock inc DWORD PTR [eax]. Prefixul lock va bloca magistrala de date pentru celelalte nuclee pe durata execuției instrucțiunii. În eax se află adresa valorii value. | |
| - | - TODO | + | - În mod obișnuit, atunci când se închide sistemul de calcul, se folosește apelul sync() care aduce datele din memorie pe disc. Ce s-ar întâmpla dacă, la închiderea sistemului de calcul, apelul sync() nu mai este apelat? |
| - | * **Răspuns**: TODO | + | * **Răspuns**: Paginile dirty (modificate doar în RAM) ce aparțin fișierelor de pe disk nu ar mai ajunge să fie scrise. Acest lucru poate lăsa fișierele într-o stare coruptă. Dacă fișierele erau de configurare sau binare de sistem, SO-ul poate ajunge într-o stare instabilă/defectuoasă. |
| - | - TODO | + | - Rulăm comanda rm a.txt. În ce situație sunt eliberate de pe disc blocurile de date și inode-ul fișierului a.txt? |
| - | * **Răspuns**: TODO | + | * **Răspuns**: Se vor elibera blocurile și inode-ul numai în cazul în care numărul de hard link-uri ale fișierului ajunge la 0. |
| - | - TODO | + | |
| - | * **Răspuns**: TODO | + | |
| - | + | ||
| - | === 3CB, varianta 2 === | + | |
| - | + | ||
| - | - TODO | + | |
| - | * **Răspuns**: TODO | + | |
| - | - TODO | + | |
| - | * **Răspuns**: TODO | + | |
| - | - TODO | + | |
| - | * **Răspuns**: TODO | + | |
| - | + | ||
| - | === 3CC, varianta 1 === | + | |
| - | + | ||
| - | - TODO | + | |
| - | * **Răspuns**: TODO | + | |
| - | - TODO | + | |
| - | * **Răspuns**: TODO | + | |
| - | - TODO | + | |
| - | * **Răspuns**: TODO | + | |
| - | + | ||
| - | + | ||
| - | === 3CC, varianta 2 === | + | |
| - | + | ||
| - | - TODO | + | |
| - | * **Răspuns**: TODO | + | |
| - | - TODO | + | |
| - | * **Răspuns**: TODO | + | |
| - | - TODO | + | |
| - | * **Răspuns**: TODO | + | |
