Commit graph

13 commits

Author SHA1 Message Date
LucaSforza
455bb6bbaa domande che non stavano nel bot dell'appello di gennaio 2024 2024-02-02 13:26:17 +01:00
4d56d71aa2 Add so1_new 2024-01-31 04:56:46 +01:00
391862b3fb Fix images syntax in so1.txt 2024-01-22 17:37:30 +01:00
5b626f09a4
Update unive message 2024-01-22 00:02:08 +01:00
53857456ed Fix so1.txt ending with two empty lines 2024-01-21 14:51:44 +01:00
LucaSforza
d35b46206a aggiunta un ultima domanda che mi era sfuggita 2024-01-21 14:51:44 +01:00
LucaSforza
f820abf32b aggiunta nuove domande prese da esami precedenti trovati su telegram 2024-01-21 14:51:38 +01:00
gp
3fd89253b2 fixups after questions review 2024-01-20 18:52:40 +01:00
gp
32e08eb505 Marcato come UNSAFE la domanda 2 e cambiato risposta. La disabilitazione delle interruzioni non impedisce la creazione di nuove interruzioni, ma semplicamente impedisce che esse vengano gestite. Quindi e' falso dire che la disabilitazione delle interruzioni impedisce la creazione di nuove interruzioni. Quindi dovrebbe essere la risposta 1. Al tempo stesso non e' chiaro cosa voglia dire che La disabilitazione delle interruzioni non funziona su sistemi con più processori o più core. Volendo, su ogni processore, si possono disabilitare le interruzioni, e quindi dire che 'La disabilitazione delle interruzioni non funziona su sistemi con più processori o più core' e' falso. Forse intendeva dire che La disabilitazione delle interruzioni non funziona su sistemi con più processori o più core per garantire la mutua esclusione.... In questo caso sarebbe vera. Quello che pero' e' certo e' che la 1 e' falsa.
Cambiato risposta domanda 5. Dire che 'Il translation lookaside buffer permette di accedere direttamente al contenuto degli indirizzi di memoria virtuali usati più di recente'  e' falso dato che gli unici dati presenti nel TLB sono delle associazioni (page_number: frame_number) e non c'e' assolutamente nulla relativo al contenuto dei frame. Viceversa dire che 'Il translation lookaside buffer è una particolare cache, ma non è completamente trasparente al sistema operativo' e' vero visto che ad ogni process switch ne va fatto il flush
                                Aggiunto parte mancante della domanda 16
                                Aggiunto commento alla domanda 20 (lo posso anche rimuovere). Ma qualora avessimo due processi A e B che si scambiano messaggi e due altri processi C e D che si scambiano messaggi e e' assurdo pensare che se A esegue un receive bloccante anche le receive di C si blocchino.
                                Commento sulla domanda 22. E' vero che 'il data rate confronta le velocità di 2 diversi dispositivi di I/O'. Si veda vd. gruppo 5 di slide, slide 11.
                                Aggiunto commento alla domanda 24. Nel caso di un mode switch non c'e' alcun motivo per cui lo hardware context debba essere salvato
                                Cambiato risposta 25. In slide 67 del 5 blocco di slide, e' scritto esplicitamente che 'si passa dalla parte nuova alla vecchia per scorrimento' ma 'quando un blocco viene referenziato, lo si sposta all’inizio dello stack'. Quindi, a "scendere" effettivamente si procede per scorrimento, ma a salire no. Al contrario, la quattro ('L'algoritmo di sostituzione basato su frequenza a 2 segmenti della page cache può non avere buone performance quando un settore viene acceduto spesso, ma tra il primo accesso e quelli successivi ci sono N accessi ad altri settori, diversi tra loro, con N pari alla dimensione del segmento nuovo') e' vera.
                                Aggiunto UNSAFE alla 64. Qualora lo scheduler esegua per primo il processo numero 0, e qualora esso superi il while piu' esterno prima che p1 venga eseguito, ecco che p0 e' entrato nella sezione critica. Quindi e' falso dire che 'Nell'algoritmo di Dekker, se la variabile turn è inizializzata ad 1, allora il processo 1 sarà sicuramente il primo ad entrare nella sezione critica nella prima iterazione'. Purtroppo anche tutte le altre risposte sono sbagliate
                                Aggiunto UNSAFE alla 106. In generale, su una architettura CISC (ad esempio x86) non e' vero che gli opeandi devono essere cariacati nei registri. Ad esempio addq (%rax), %rbx aggiunge un valore (il quale si trova in memoria) puntato dal registro %rax al contenuto del registro %rbx. Qualora invece ci restringessimo ad una architettura RISC, quanto affermato nella domanda sarebbe vero. Va quindi cambiata la domanda essendo piu' espliciti su CISC e RISC?
2024-01-20 17:23:29 +01:00
9870ec28f1 Merge remote-tracking branch 'refs/remotes/origin/main' 2024-01-19 20:34:57 +01:00
0cddce0e08 Fix wrong S01 command && update welcome message 2024-01-19 20:34:20 +01:00
LucaSforza
0bb085e548 aggiunta domande per SO1 2024-01-19 16:25:17 +01:00
8fc89fbc03 Refactor repo structure 2024-01-19 03:29:39 +01:00