/////////////////////////////////// /// ESERCIZI SUI SEMAFORI /// /// Stefano Ferretti /// ///////////////////////////////////

Transcript

1 /////////////////////////////////// /// ESERCIZI SUI SEMAFORI /// /// Stefano Ferretti /// /////////////////////////////////// Soluzione al Problema del Barbiere Possiamo vedere questo problema come un problema di produttore-consumatore. I produttori sono i clienti, che producono se stessi. E il consumatore è il barbiere, che consuma un cliente alla volta. Innanzitutto, dobbiamo descrivere la vita del barbiere e dei clienti, perchè non è esattamente specificata: process Barbiere { while (true) { attendi cliente // taglia capelli libera poltrona process Cliente { verifica se c'è posto, altrimenti esci attendi turno // fatti tagliare i capelli E questo è il programma: Semaphore mutex = new Semaphore(1); Semaphore clientedisponibile = new Semaphore(0); Semaphore poltrona = new Semaphore(0); int sedielibere = N; process Barbiere { while (true) { clientedisponibile.p(); // taglia capelli poltrona.v(); process Cliente { if (sedielibere==0) { return; sedielibere--; clientedisponibile.v(); poltrona.p(); sedielibere++; // Fatti tagliare i capelli // e poi esci

2 Nome: Semafori Barriera abbiamo già visto (nei lucidi) un esempio in cui 2 processi si sincronizzano attraverso una sorta di "barriera" fatta di una sequenza di operazioni V() e P() su 2 semafori. Ora se ci chiedessimo di sincronizzare tramite una barriera 3 processi P, Q, R, come potremmo fare? // riporto qui la versione a 2 processi per rinfrescarci la memoria s1, s2 semafori generali iniz. a 0 process P process Q s2.v() s1.v() // P da il via a Q e viceversa s1.p() s2.p() // P aspetta il via da Q e viceversa // fine versione a 2 processi s1, s2, s3 semafori generali iniz. a 0 process P process Q process R s2.v() s1.v() s1.v() s3.v() s3.v() s2.v() s1.p() s2.p() s3.p() s1.p() s2.p() s3.p() Guardando al codice dei tre processi, sembrerebbe che non facciano nulla (non stampano, non fanno calcoli, etc.). Quello che fanno i tre processi è sincronizzarsi uno con l'altro. Dobbiamo immaginare che vi sia del codice prima e dopo le invocazioni delle primitive dei semafori, rappresentato da. Ognuno di loro potrà proseguire solo quando ognuno degli altri avrà eseguito le due V() - ovvero, quando avrà superato il codice che si trova prima. Nome: Semafori Interleaving Il seguente programma concorrente, a seconda dell'interleaving fra i due processi, può stampare una o più stringhe. Indicare quali Nota: tutti i semafori sono generali e inizializzati a 0. process P { s1.v(); print F; s1.p(); s2.v(); s1.p(); print C;

3 process Q { print G; s2.p(); print D; s1.v(); La risposta semplice a questa domanda è: FGDC, GFDC. La risposta completa dovrebbe mostrare il reticolo delle azioni, per dimostrare che effettivamente avete capito cosa state facendo. Nome: Semafori Interleaving 2 Cosa fa questo programma concorrente? (s1, s2 semafori, entrambi inizializzati a 0) process P { s1.v(); s2.p(); print O s2.p(); print D s1.v(); process Q { s1.p(); print L; s2.v(); s2.v(); s1.p(); print E Risposta veloce: stampa "LODE"; la risposta completa dovrebbe fare vedere il reticolo dei possibili passi. Nome: letargo spontaneo Contesto: un processo vuole decidere autonomamente di sospendersi; qualunque altro processo puo' svegliarlo ma solo *dopo* che si e' addormentato Soluzione: Semaphore sosp = 0; // semaforo di sospensione bool sleeping = false; // mutex process P { // che si vuole sospendere autonomamente

4 sleeping = true; sosp.p(); // si sospende perche' S vale sempre 0 process Q { // che vuole svegliare P solo se P e' gia' sospeso? if (sleeping) { sleeping = false; sosp.v(); // scelta possibile: passaggio del testimone o meno Nome: Sezione Critica con risorse condivise Contesto: abbiamo una o piu' risorse condivise e l'accesso a tali risorse deve avvenire in mutua esclusione Soluzione base (già vista ampiamente): // inizializzato a 1 // entrare in sezione critica // lasciare la sezione critica Problema: A volte e' necessario valutare il valore delle risorse condivise per sapere se sia possibile o meno proseguire nella computazione. // chiamiamo la condizione da valutare sui dati condivisi "C(shared)" Soluzione 1 errata: shared dato; if (C(shared) { // NO! Non sono in sezione critica. Dato alterabile. // entrare in sezione critica // lasciare la sezione critica Soluzione 2 errata: Semaphore sosp = 0; // semaforo di sospensione shared dato; // entrare in sezione critica if (C(shared) { else { sosp.p(); // deadlock: nessun altro entrera' mai piu' in sezione critica

5 // lasciare la sezione critica Soluzione 3 (sub-ottimale, alla Java): Semaphore sosp = 0; // semaforo di sospensione shared dato; // entrare in sezione critica while (!C(shared) { // lascio la sezione critica sosp.p(); <-- qua si puo' inserire qualcuno che cambia shared // lasciare la sezione critica Il processo che risveglia il processo sospeso esegue il seguente codice: // entra in sezione critica.. // altera i dati condivisi fra cui shared sosp.v(); // nel dubbio risveglio l'altro processo. Problemi: starvation, spreco di CPU, no FIFO Soluzione 4: (Uso il passaggio del testimone) Semaphore sosp = 0; // semaforo di sospensione shared dato; // entrare in sezione critica if (!C(shared) { // lascio la sezione critica sosp.p(); // ASSUMIAMO DI ESSERE IN SEZIONE CRITICA AL RISVEGLIO // QUA SIAMO CERTI CHE C(shared) VALGA! // lasciare la sezione critica Sia il seguente codice quello eseguito dal processo che risveglia il processo precedente. mutex.p(m); // entra in sezione critica.. // altera i dati condivisi fra cui shared if(c(shared)) { sosp.v(); // RISVEGLIA L'ALTRO PROCESSO E PASSA LA SEZIONE CRITICA. else { Problema ulteriore: La soluzione precedente si basa sull'assunzione che la condizione

6 C(shared) sia valutabile esclusivamente a partire dai dati condivisi. Questo perche' deve essere valutata da entrambi i processi. Come fare quando la condizione coinvolge anche dati non condivisi? Caso A: i dati sono sensibili e non li vogliamo condividere. Soluzione: si torna alla soluzione alla Java. Caso B: i dati non sono sensibili e possono essere condivisi Caso B.1: non mi costa troppo (in spazio) condividere sempre tutti i dati Problemi: a) spreco di memoria (forse) b) aumenta la possibilita' di bug/errori Caso B.2: Osservazione: al processo che deve risvegliare non servono i dati privati di tutti gli altri processi, ma solo quelli del processo che si e' sospeso. Soluzione: il processo che si sospende subito prima di rilasciare la sezione critica condivide i suoi dati privati che servono a testare la condizione. Soluzione alternativa ai filosofi a cena I Semaphore sem_filosofo[5] = {0,., 0; bool b_libera[5] = {1,., 1; // dice se la bacchetta è libera bool sospeso[5] = {0,., 0; // dice se il filosofo attende le bacchette Philo[i] { while (1) { pensa(); prendi_bacchette(i); mangia(); rilascia_bacchette(i); void prendi_bacchette(int i) { if (!b_libera[i]!b_libera[(i+1)%5]) { sospeso[i] = 1; // il processo si sospende sem_filosofo.p(); // PASSAGGIO DEL TESTIMONE b_libera[i] = 0; b_libera[(i+1)%5] = 0; void rilascia_bacchette(int i) { b_libera[i] = 1; b_libera[(i+1)%5] = 1; // ho 4 possibilità: // 1 - sia il filosofo a dx che quello a sx sono affamati e ci sono le

7 bacchette // 2 - il filosofo a dx è affamato e ci sono le bacchette // 3 - il filosofo a sx è affamato e ci sono le bacchette // 4 - nessuno dei 2 può mangiare if (b_libera[(i-1)%5] == 1 && sospeso[(i-1)%5] == 1) { sem_filosofo[(i-1)%5].v(); // PASSAGGIO DEL TESTIMONE if (b_libera[(i+2)%5] == 1 && sospeso[(i+1)%5) { sem_filosofo[(i+1)%5].v(); // PASSAGGIO DEL TESTIMONE else { else if (b_libera[(i+2)%5 == 1 && sospeso[(i+1)%5) { sem_filosofo[(i+1)%5].v(); // PASSAGGIO DEL TESTIMONE // start_nb: è necessario questo codice sotto? if (b_libera[(i-1)%5] == 1 && sospeso[(i-1)%5) { sem_filosofo[(i-1)%5].v(); // PASSAGGIO DEL TESTIMONE else { // end_nb: prendendo e rilasciando la mutex, forse sono più fair // nel (ri)controllare se svegliare il filosofo (i+1) else { Soluzione alternativa ai filosofi a cena II #define N 5 /* Numero di filosofi */ #define RIGHT(i) (((i)+1) % N) #define LEFT(i) (((i)==n)? 0 : (i)+1) // questa soluzione non usa l'idea di bacchette, ma setta lo stato dei filosofi typedef enum { THINKING, HUNGRY, EATING stato_filosofo; stato_filosofo state[n]; Semaphore sem_filosofo[n]; /* uno per filosofo, inizializzati a 0 */ /* Questa è la funzione principale, dato un filosofo "i", controlla quello che sta facendo il filosofo a destra e a sinistra. Il trucco qui è che se verifica che "i" può mangiare, allora setta il suo stato a EATING e chiama una V() sul semaforo privato di "i". La cosa è un po' oscura, nel senso che troviamo qui una V() senza una P() nella stessa porzione di codice (la relativa P() la troviamo in get_forks()). */ void test(int i) { if ( state[i] == HUNGRY && state[left(i)]!= EATING && state[right(i)]!= EATING ) { state[i] = EATING; sem_filosofo[i].v();

8 void get_forks(int i) { state[i] = HUNGRY; test(i); // se la condizione in test(i) precedente è stata verificata, allora // è stata preventivamente eseguita una sem_filosofo[i].v();, per cui // i non si bloccherà nella P() qui sotto // in caso contrario, il processo si blocca e potrà essere risvegliato // durante l'esecuzione di put_forks() da parte di un filofoso vicino sem_filosofo[i].p(); void put_forks(int i) { state[i]= THINKING; test(left(i)); test(right(i)); void philosopher(int process) { while(1) { think(); get_forks(process); eat(); put_forks(process); /* Nelle versioni precedenti un filosofo può cambiare lui lo stato del suo fiolosofo vicino. Se la cosa non ci piace, dobbiamo creare un'altra versione, in cui ogni volta che un filosofo rilascia le bacchette, sveglia il filosofo accanto, che dovrà controllare se ha la possibilità di prendere 2 bacchette. Questa possibilità non è sempre verificata, per cui il filosofo potrebbe essere stato svegliato per niente. */ Soluzione alternativa ai filosofi a cena III (sub-ottimale, ma che consente l'incapsulamento dello stato dei filosofi) void get_forks(int i) { state[i] = HUNGRY; while ( state[i] == HUNGRY ) { // controllo se posso mangiare if ( state[i] == HUNGRY && state[left]!= EATING && state[right(i)]!= EATING ) { state[i] = EATING; sem_filosofo[i].v(); // grazie a questa V() non mi bloccherò nella P() successiva sem_filosofo[i].p(); // se sto mangiando (entrato nell'if precedente) non mi blocco,

9 // altrimenti mi blocco e aspetto che mi risvegli un vicino void put_forks(int i) { state[i]= THINKING; if ( state[left(i)] == HUNGRY ) sem_filosofo[left(i)].v(); // lo sveglio affichè controlli se puà mangiare if ( state[right(i)] == HUNGRY) sem_filosofo[right(i)].v(); // lo sveglio affichè controlli se puà mangiare void philosopher(int process) { while(1) { think(); get_forks(process); eat(); put_forks(); Problema: i processi debbono risvegliarsi in ordine non FIFO Soluzione: invece di usare un unico semaforo S su cui tutti si sospendono, ogni processo ha un proprio semaforo S[i], sul quale si sospende facendo S[i].P(). Chi lo vuole risvegliare lo fa con S[j].V(). Problema: da dove ricava j? Idea: quando il processo "i" si sospende prima pubblica il proprio pid() i in una qualche struttura dati. Il processo che vuole risvegliare pesca da questa struttura dati con una politica!= FIFO. Esempio: coda con priorita' (2) bool libero = 1; queue coda[n]; // N e' il numero di priorita' Semaphore S[M]; // M e' il numero di processi nel sistema Process P[i,p] { // processo di indice i con priorita' p if (!libero) { queue[p].push(i); S[i].P(); else {.. // viene servito int k = 0; int svegliato = 0; while (!svegliato && k<n) { if (empty(queue[k])) k++;

10 else { // c'è qualcuno da riattivare j = queue[k].pop(); svegliato = 1; S[j].V();