SISTEMI OPERATIVI E LABORATORIO (Indirizzo Sistemi e Reti) 21 dicembre 2004

Transcript

1 SISTEMI OPERATIVI E LABORATORIO (Indirizzo Sistemi e Reti) 21 dicembre 2004 Cognome: Nome: Matricola: ESERCIZIO 1, teoria (6 punti) a) riportate lo pseudocodice che descrive l implementazione dell operazione di signal su un semaforo. A cosa serve la system call usata nello pseudocodice? Vedere lucidi usati a lezione, sezione b) Elencate le proprietà fondamentali che deve avere una corretta soluzione al problema della sezione critica. mutua esclusione, progresso, attesa limitata c) Perche i semafori sono preferibili ad una soluzione come l algoritmo di dekker, o l algoritmo del fornaio, o gli algoritmi che usano speciali istruzioni hardware? Perché evitano il busy-waiting d) Quali problemi possono comunque sorgere dall uso errato dei semafori? Se non si bilanciano correttamente le operazioni di wait e signal si può verificare deadlock, starvation, o non e assicurata la mutua esclusione. ESERCIZIO 2, teoria (7 punti) Quattro processi arrivano al tempo indicato e consumano la quantità di CPU indicata nella tabella sottostante) Processo T. di arrivo Burst P1 0 7 P2 2 6 P3 2 2 P4 7 1 (a) Calcolare il turnaround medio e il waiting time medio per i processi nel caso degli algoritmi di scheduling SJF preemtpive e RR (quanto di tempo = 1), riportando anche i diagrammi di Gantt corrispondenti ai tre algoritmi (nel caso di RR assumete per semplicità che ad un processo che entra in coda di ready venga assegnato un quanto di tempo di CPU appena

2 possibile. Assumete anche che a parità di altre informazioni, quando è necessario scegliere tra due processi da mandare in CPU venga selezionato quello con il burst time più breve) (b) Nel caso dell algoritmo di scheduling RR, supponete ora che il tempo necessario per il context-switch non sia nullo, ma sia pari ad 1/5 di un quanto di tempo. Ricalcolate il turnaround e il waiting time medio nel caso RR tenendo conto del context switch. Spiegate le vostre scelte. Per ogni risposta numerica di (a) e (b) riportate semplicemente la frazione che rappresenta il risultato cercato. (c) SJF e RR garantiscono l assenza di starvation? Cosa si può fare per assicurare che un algoritmo di scheduling sia libero da starvation? (d) Riportate il diagramma di stato della vita di un processo, e dite quali sono le transizioni che un generico processo può compiere volontariamente. Soluzione (nello svolgimento dell esercizio era opportuno ricordare che per calcolare il waiting time di un processo basta sottrarre al suo turnaround time il burst time - esercizio 6.3 visto a lezione) (a) SJF preemptive: P1 (2) P3 (4) P1 (7) P4 (8) P1 (10) P2 (16) turnaround medio: P1=10; P2=14; P3=2; P4=1 turnaround time medio = 27/4 waiting time medio: P1=3; P2=8; P3=0; P4=0 waiting time medio = 11/4 RR: ( in neretto l ultimo quanto di ogni processo) P1, P1, P3, P2, P1, P3, P2, P4, P1, P2, P1, P2, P1, P2, P1, P2 turnaround medio: P1=15; P2=14; P3=4; P4=1 turnaround time medio = 34/4 waiting time medio: P1=8; P2=8; P3=2; P4=0 waiting time medio = 18/4 (b) per tenere conto del tempo di context switch basta contare quante volte il SO deve passare da un processo ad un altro. Se escludiamo il tempo necessario a far partire la prima volta P1, abbiamo in tutto 15 context switch, pari a 3 quanti di tempo (ogni context switch dura 1/5 di quanto). Il turnaround medio diventa quindi: 37/4, e il waiting time medio diventa 21/4. (c) SJF preemptive non garantisce assenza di starvation. Si può eliminare il pericolo di starvation usando un meccanismo di aging. (d) Si vedano i lucidi del corso per il diagramma. Un generico processo può, dallo stato di running, scegliere di terminare o di mettersi in stato di wait in attesa di un qualche evento.

3 ESERCIZIO 3, Unix (7 punti) (a) A partire dallo scheletro di programma C riportato qui sotto, scrivete un programma C che si comporta come segue: un processo padre si forka producendo un figlio, che chiameremo figlio_1, dopodiché padre va ad eseguire un loop infinito. Figlio_1 si forka a sua volta producendo un figlio_2 dopodiché figlio_1 esegue un loop infinito. Figlio_2 invia prima un segnale a suo nonno (ossia a padre), poi un segnale di terminazione a figlio_1 (ossia suo padre) e poi termina egli stesso. Quando padre riceve il segnale, si mette in attesa della terminazione di suo figlio figlio_1, e poi termina egli stesso. Suggerimento: Avete molto spazio a disposizione nella pagina successiva, ma il programma che dovete scrivere occupa molto meno spazio Per indicare un loop infinito, usate semplicemente: for (;;) sleep (1); #include <stdio.h> #include <signal.h> #include<sys/types.h> #include<sys/wait.h> myfunc() { wait(0); exit(0); main() { signal(sigusr1,myfunc); int p1, p2, i; int father_pid = getpid(); p1 = fork(); if ( p1 == 0) { //figlio_1 p2 = fork(); if ( p2 == 0) { //figlio_2 kill(father_pid,sigusr1); kill(getppid(),sigkill); else for(;;)sleep(1); for(;;) sleep(1); //padre (b)

4 E possibile che, quando il processo padre si mette in attesa della terminazione di figlio_1, questo sia in realtà già terminato? Motivate la vostra risposta. Risposta Si. Se dopo l esecuzione delle due kill di figlio_2, lo scheduler manda in esecuzione figlio_1, questo trova il segnale SIGKILL pendente e termina immediatamente, anche se il segnale SIGUSR1 è stato inviato a padre prima di inviare a figlio_1 il segnale SIGKILL. ESERCIZIO 4, Unix (7 punti) ln source dest è il comando unix che permette di creare un nuovo link fisico dest a partire da un link fisico esistente source. Source e dest possono essere sia pathname assoluti che relativi. L opzione del comando -s permette di indicare che il link deve essere simbolico, anziché fisico. Considerate la seguente porzione di file system Unix, nella quale la directory sources contiene solo il file prog.c, e la directory shared è vuota: utilities shared sources Sia sources la working directory, e sia 100 il numero dell i-node associato a prog.c. Considerate la seguente sequenza di comandi unix, eseguiti uno di seguito all altro: 1. ln prog.c newprog.c 2. cd../shared 3. ln../sources/newprog.c sharedprog.c 4. rm../sources/prog.c 5. cp sharedprog.c myprog.c 6. ln -s../sources/newprog.c simprog.c rispondete alle seguenti domande, motivando le vostre risposte: a) quale/quali valori puo avere il link counter dell i-node 100 dopo l esecuzione del comando 6? Qualsiasi valore maggiore o uguale a due, poiché prima del comando 1, il link counter 100 ha almeno valore 1. Il link counter viene incrementato ai comandi 1 e 3, e decrementato al comando 4. Il comando 5 non ha effetto sul link counter 100, come pure il comando 6, essendo un link simbolico. b) quale/quali valori ha il link counter dell i-node associato a myprog.c? Il link counter vale uno, dato che il file e stato appena creato.

5 c) Disegnate la struttura interna dei file cartella shared e sources dopo l esecuzione dei comandi 1, 2, 3 4, 5 e 6 riportati sopra. Segliete dei valori opportuni per gli i-node coinvolti. shared: sharedprog.c 120 myprog.c sources: prog.c 100 newprog.c simprog.c d) supponete che l output del comando ls -l sharedprog.c sia: -rwsr-xr-x../sources/newprog.c descrivete in dettaglio il significato dei caratteri che compaiono nella prima colonna dell output, facendo specifico riferimento ai valori riportati. Riportate anche il significato del flag/bit s presente nell output riportato. Nella prima colonna dell output di ls -l vengono riportati i permessi relativi al file specificato. In particolare, da sinistra a destra: I. Primo trattino: indica che sharedprog.c è un file regolare (non è una cartella o una pipe) II. Primo gruppo di 3 flag: sono i permessi in scrittura/lettura/esecuzione per il possessore del file. Sharedprog.c è leggibile, scrivibile ed eseguibili dal possessore del file (si veda avanti per il bit s) III. Secondo gruppo di 3 flag: sono i corrispondenti permessi per il gruppo a cui appartiene il possessore del file. Sharedprog.c è leggibile ed eseguibile dagli utenti del gruppo. IV. Terzo gruppo di 3 flag: sono i permessi per tutti gli altri utenti del sistema. Nel nostro caso i permessi sono gli stessi del gruppo. V. Si vedano i lucidi relativi ai processi unix (pagina 14 e seguenti)