SISTEMI OPERATIVI. Sincronizzazione dei processi. Domande di verifica. Luca Orrù Centro Multimediale Montiferru 30/05/2007

Transcript

1 2007 SISTEMI OPERATIVI Sincronizzazione dei processi Domande di verifica Luca Orrù Centro Multimediale Montiferru 30/05/2007

2 Sincronizzazione dei processi 1. Si descrivano i tipi di interazione tra processi? Due processi possono essere indipendenti oppure interagenti. Nel caso interagiscono, l esecuzione di un processo influenza l esecuzione dell altro processo. Esistono due tipi di interazione tra i processi: cooperazione (comunicazione) e competizione. La cooperazione tra processi avviene tramite scambio di informazioni. E necessario rispettare dei vincoli per quanto riguarda l ordine con la quale i processi si scambiano le informazioni. I processi devono essere sincronizzati in modo che i messaggi vengano scambiati rispettando un determinato ordine. Come esempio di comunicazione si può considerare il caso di due processi, un processo produttore e un processo consumatore. Il processo produttore produce un messaggio da stampare, mettendolo in un buffer (buffer che può contenere un solo messaggio). Il processo consumatore preleva il messaggio dal buffer e lo stampa. In questo caso il vincolo da rispettare è che il processo consumatore non possa prelevare il messaggio dal buffer finché il produttore non ha prodotto e posto nel buffer il messaggio. L ordine delle operazioni deve essere sempre: inserimento-prelievo-inserimento-prelievo. Qualunque altra sequenza di operazioni non va bene. Due processi sono invece in competizione quando hanno delle risorse comuni e non possono usare queste risorse contemporaneamente. Consideriamo due processi A e B che durante la loro esecuzione richiedono di stampare un file. I nomi dei file da stampare vengono posti in una coda di stampa e il processo demone della stampante si occuperà di prelevare i file dalla coda di stampa per stamparli. Supponiamo poi che ci siano due variabili condivise: la prima variabile che chiamiamo successivo punta al prossimo file da stampare e la seconda variabile che chiamiamo libero punta alla prima posizione libera della coda di stampa. Ad un certo istante la situazione della coda di stampa è la seguente: sono presenti file nelle posizioni 3, 4, 5, 6; i file da 0 a 2 sono appena stati stampati e quindi sono stati tolti dalla coda; la prima posizione libera è la posizione 7. La variabile successivo contiene il valore 3 e libero contiene 7. Ora A e B decidono contemporaneamente di accodare un file per la stampa.

3 Il processo A legge libero e memorizza 7 in una variabile locale primo slot libero. Dopo che ha letto libero arriva un interruzione perché il suo quanto di tempo è scaduto (perde la CPU). Il sistema operativo manda in esecuzione il processo B. Il processo B legge libero e memorizza 7 in una sua variabile locale primo slot libero. Ora entrambe i processi pensano che la prima posizione libera sia 7. Il processo B continua l esecuzione e carica in posizione 7 della coda il nome del suo file e aggiorna la variabile condivisa libero al valore 8. Il processo B perde la CPU e ad un certo istante il processo A viene schedulato nuovamente e riprende l esecuzione dal punto d interruzione. Aveva memorizzato come primo slot libero il valore 7 e quindi carica in posizione 7 il nome del suo file che dunque va a cancellare il file del processo B. Aggiorna il valore di libero che diventa 8. Il demone della stampante stamperà quindi il file del processo A ma non stamperà mai il file del processo B. Si può notare da questo esempio che il risultato finale, in questo caso la stampa, dipende dall ordine di esecuzione dei processi. Situazioni come queste prendono il nome di corse critiche (race condition). E necessario sincronizzare i processi in modo tale che l accesso alle risorse condivise avvenga in modo mutuamente esclusivo. Un solo processo alla volta può accedere alla risorsa condivisa. successivo=3 Processo A File 3 File 4 File 5 libero=7 Processo B File 6

4 2. Si descriva il concetto di sezione critica (esame del ) Una sezione critica è la parte di programma in cui un processo accede alla risorsa condivisa (file, tabella etc). L accesso alla regione critica può portare a delle corse critiche, ovvero il risultato finale dell operazione svolta sulla risorsa condivisa dipende dall ordine di esecuzione dei processi. Si potrebbero evitare le corse critiche facendo in modo che due processi non possano mai essere nelle proprie sezioni critiche nello stesso istante. L esecuzione delle sezioni critiche deve essere mutuamente esclusiva mentre non esistono vincoli sull ordine di accesso alle sezioni critiche. Questo evita le corse critiche ma non è sufficiente per avere un uso efficiente delle risorse condivise. Per fare in modo che le risorse condivise siano usate in maniera efficiente è necessario soddisfare le seguenti condizioni: a. Due processi non devono mai trovarsi contemporaneamente nella propria sezione critica b. Nessun processo in esecuzione che è fuori dalla propria sezione critica può bloccare un processo che è nella propria sezione critica c. Nessun processo deve aspettare indefinitamente prima di poter accedere alla propria sezione critica d. Non si devono fare ipotesi sul numero delle CPU Esistono vari metodi per garantire la mutua esclusione, uno di questi è la disabilitazione delle interruzioni. Ad ogni processo che entra nella propria sezione critica deve essere permesso di disabilitare le interruzioni (istruzione CLI: clear interrupt) e di riabilitarle (istruzione STI: set interrupt) in seguito quando esce dalla sua sezione critica. In questo modo, la CPU non può essere assegnata ad un altro processo perché il processo in esecuzione non può essere interrotto avendo la CPU il bit d interruzione settato a 0 (interruzione disabilitata). Il processo che è dentro la propria sezione critica può quindi modificare la risorsa condivisa senza pericolo che venga interrotto. Ci sono due problemi però:

5 1. se il processo che ha disabilitato le interruzioni non le riabilita? 2. Se il sistema fosse multiprocessore e non monoprocessore? La disabilitazione avrebbe effetto solo sulla CPU che ha il processo in esecuzione ma non sulle altre CPU che quindi potrebbero eseguire altri processi, che a loro volta potrebbero accedere alla risorsa condivisa. Questa soluzione non va bene e spiega la necessita di attuare una politica che tenga conto anche del numero dei processori (punto d). 3. Si descrivano i due modelli di interazione tra processi Esistono due forme di interazione tra processi: cooperazione e competizione. Entrambe le forme di interazione richiedono degli strumenti di sincronizzazione. Nel caso di cooperazione la sincronizzazione è necessaria per garantire l ordine di esecuzione delle operazioni su una data risorsa (esempio di produttore consumatore), mentre nel caso di competizione la sincronizzazione è necessaria per far rispettare il vincolo della mutua esclusione sulla risorsa condivisa. Gli strumenti di sincronizzazione variano a seconda del tipo di modello d interazione tra processi: modello ad ambiente globale e modello ad ambiente locale. In un modello ad ambiente globale entrambe le forme d interazione avvengono tramite la memoria condivisa. I processi comunicano usando la memoria comune e competono per l uso delle risorse condivise. I processi cooperanti quindi comunicano scrivendo e leggendo da tale zona di memoria condivisa. In questo modello i processi hanno anche il vincolo di non scrivere simultaneamente in una locazione di memoria condivisa (rispetto del vincolo della mutua esclusione). Il problema del produttore consumatore richiede l uso della memoria condivisa. Il processo produttore produce dei messaggi, che vengono posti in una area di memoria comune, dalla quale il consumatore preleva i messaggi. Il processo produttore potrebbe essere un server web, che fornisce le pagine HTML, e il processo consumatore è il client, ovvero il browser web che le richiede.

6 In un modello ad ambiente locale, detto anche modello a scambio di messaggi, i processi comunicano attraverso scambio di messaggi non usando aree di memoria condivisa. Non esistono in questo modello risorse condivise. Ogni processo opera solo sulle risorse private che non sono accessibili da altri processi. I processi comunicano attraverso dei canali di comunicazione. E il tipico modello di un sistema distribuito (reti di calcolatori) in cui abbiamo più processi che girano su processori diversi e usano la propria memoria locale (non esiste memoria condivisa). I processi comunicano usando la rete di comunicazione. In un modello a memoria condivisa la comunicazione è più veloce rispetto al caso di modello ad ambiente locale. Infatti il modello a scambio di messaggi richiede l uso di opportune system call che richiedono l intervento del kernel del Sistema Operativo. Nel caso di modello ad ambiente globale (memoria condivisa) invece il sistema operativo interviene solo per allocare l area di memoria condivisa che verrà usata per la comunicazione, poi tutti gli accessi alla memoria avvengono senza l intervento del kernel. Nel caso di modello a memoria condivisa gli strumenti di sincronizzazione sono i semafori e le primitive wait e signal, mentre nel caso di modello ad ambiente locale gli strumenti di sincronizzazione sono le primitive send e receive. Processo A Processo B 2 1 Modello ad ambiente locale kernel

7 Processo A 1 Memoria condivisa Modello ad ambiente globale Processo B 2 kernel 4. Si illustrino i principali metodi di sincronizzazione dei processi mediante segnali (esame del ) La sincronizzazione tra processi può essere eseguita nei seguenti modi: a. attraverso l utilizzo di strutture dati come i semafori e le relative primitive wait e signal (modello ad ambiente globale o a memoria condivisa): vedi risposta alla domanda 5. b. mediante l uso delle primitive sleep() e wakeup (P): quando un processo esegue una sleep () esso si sospende in attesa di essere risvegliato. Quando un processo esegue la wakup (P) risveglia il processo P. Se il processo P non è sospeso il risveglio viene perduto. Per maggiori dettagli vedere la risposta alla domanda 9. c. mediante l uso delle primitive send e receive (modello a scambio di messaggi): vedi risposta alla domanda 10 d. Altri strumenti di sincronizzazione di più alto livello sono i monitor.

8 5. Si descriva il funzionamento di un semaforo per la sincronizzazione dei processi (esame del ) In un ambiente a memoria comune è possibile realizzare la sincronizzazione dei processi attraverso i semafori e le primitive WAIT e SIGNAL. I semafori consentono di risolvere sia il problema della mutua esclusione sia il problema della comunicazione (processo produttore consumatore). Un semaforo S è una variabile intera non negativa che indichiamo con S.VALUE con valore iniziale (S.iniziale >=0). Ad ogni semaforo è associata una coda di processi bloccati S.CODA. Inoltre su un semaforo possono essere eseguite due sole operazioni, che sono le operazioni di WAIT (S) e di SIGNAL (S). Queste operazioni sono indivisibili cioè se un processo fa una WAIT(S) nessun altro processo può fare contemporaneamente la WAIT(S) e cosi pure per la SIGNAL. Quando un processo fa la WAIT (S) se trova il semaforo S con valore maggiore di 0, il valore del semaforo viene decrementato di una unità ed il processo prosegue la sua esecuzione (semaforo verde), altrimenti se trova il semaforo S con S=0 (semaforo rosso) il processo viene sospeso e il suo descrittore viene inserito nella coda dei processi bloccati associata a quel semaforo. La CPU viene assegnata ad un altro processo. L operazione di SIGNAL(S) risveglia un processo sospeso ma non è sospensiva per chi la esegue. Quando un processo che è in esecuzione fa la SIGNAL, se nessun processo è presente nella coda dei processi bloccati su quel semaforo, allora il valore del semaforo S viene incrementato di 1 altrimenti viene risvegliato il primo processo presente in coda che andrà nella coda dei processi pronti e il processo che ha fatto la SIGNAL prosegue la sua esecuzione a meno che non sia un sistema a priorità e il processo risvegliato abbia priorità più alta del processo in esecuzione. In tal caso va in esecuzione il processo risvegliato a scapito del processo che ha fatto la SIGNAL che verrà inserito nella coda dei processi pronti. Le operazioni di WAIT e SIGNAL sono descritte di seguito:

9 void WAIT (S) { if (s.value==0) /il processo viene sospeso e il suo descrittore inserito in S.CODA/ else S.VALUE=S.VALUE-1; } void SIGNAL (S) { if (esiste almeno un processo nella coda S.CODA dei processi sospesi ) /il suo descrittore viene estratto e inserito nella coda dei processi pronti/; else S.VALUE=S.VALUE+1; } 6. Descrivere il meccanismo di mutua esclusione mediante semafori (esame del ) Il problema della mutua esclusione può essere risolto attraverso l uso di un semaforo binario a cui si da il nome di MUTEX. Un semaforo binario può assumere solo due valori: 0 e 1. Il semaforo MUTEX è inizializzato al valore 1. Per ogni processo, dell insieme dei processi che competono per l uso della risorsa condivisa, è valido il seguente schema: Processo P prologo wait (MUTEX); /*chiede di entrare nella regione critica*/ <sezione critica>; epilogo: signal (MUTEX); /*informa che ha rilasciato la regione critica */

10 Il prologo è l insieme delle istruzioni che devono essere eseguite per richiedere l accesso alla sezione critica. L epilogo è l insieme delle istruzioni che vengono eseguite per dichiarare libera la regione critica. Quando il processo P fa l istruzione wait (MUTEX), se trova MUTEX=1 (semaforo verde) allora decrementa il valore di MUTEX al valore 0 (semaforo rosso) ed esegue la propria sezione critica. Avendo messo a 0 il MUTEX qualunque altro processo che vuole accedere alla propria sezione critica farà la wait ma verrà sospeso in coda al semaforo MUTEX. Quando il processo termina la sezione critica, fa signal (MUTEX) e risveglia il primo processo presenta nella coda dei processi sospesi. Il processo che ha fatto la signal potrebbe continuare la sua esecuzione oppure no, dipende dalla priorità del processo risvegliato. N.B: se c è almeno un processo in coda, il semaforo MUTEX rimane a 0 quando viene fatta la signal. Si consideri il seguente esempio: Siano P1 P2 e P3 tre processi che competono per l uso di una risorsa comune. Indichiamo con A B e C le regioni critiche associate ai tre processi. Usiamo un semaforo MUTEX inizializzato a 1. I tre processi seguono il seguente schema: Processo P1 prologo wait (MUTEX); <sezione critica A>; epilogo: signal (MUTEX); Processo P2 prologo wait (MUTEX); <sezione critica B>; epilogo: signal (MUTEX); Processo P3 prologo wait (MUTEX); <sezione critica C>; epilogo: signal (MUTEX);

11 Supponiamo che il primo processo ad andare in esecuzione sia il processo P2. Il processo P2 trova MUTEX=1 e quindi eseguendo la wait (MUTEX) decrementa MUTEX a 0 e accede alla propria sezione critica (sezione critica B). Ora ad un certo istante il processo P2 subisce la revoca della CPU (es.quanto di tempo scaduto) e viene schedulato il processo P1. Il processo P1 fa la wait(mutex) ma trova MUTEX=0 (semaforo rosso) e di conseguenza non può entrare nella propria sezione critica e viene sospeso andando nella coda dei processi bloccati. Se ora viene schedulato P3 accadrà la stessa cosa. Anche P3 viene sospeso. P2 si trova in stato di pronto e P1 e P3 si trovano in stato di bloccato. Ora viene schedulato il processo P2 che completerà la sua sezione critica. Al termine esegue la signal (MUTEX) e risveglia il primo processo in coda al semaforo, che passa in stato di pronto. Se P1 ha priorità più alta rispetto a P2 allora P2 viene sospeso e viene eseguito P1 altrimenti continua l esecuzione di P2. In questo caso, quando P2 termina o viene sospeso, perché è scaduto il suo quanto di tempo, viene eseguito il processo P1 che può accedere alla propria sezione critica (N.B la MUTEX non viene fatta perché il PC contiene l indirizzo dell istruzione successiva alla WAIT(MUTEX) e cioè punta alla prima istruzione della regione critica). Al termine della propria sezione critica esegue la signal (MUTEX) che risveglia P3 che andrà nella coda dei processi pronti. Al termine dell esecuzione di P1 viene schedulato P3 che potrà accedere alla propria sezione critica. Ora quando il processo P3 termina la propria sezione critica e fa la SIGNAL (MUTEX), nessun processo è più presente nella coda dei processi bloccati e quindi il semaforo MUTEX viene incrementato e ritorna a 1. In definitiva qualunque sia l ordine di esecuzione dei processi, con il semaforo MUTEX inizializzato a 1, è garantita la mutua esclusione delle sezioni critiche A B e C. Un vantaggio di questa tecnica è quello di evitare un attesa attiva dei processi che non possono entrare nella propria sezione critica. Infatti, un processo che non può entrare nella propria sezione critica viene sospeso, al contrario della soluzione con lock x e unlock x nella quale un processo rimane in attesa attiva, tenendo occupato il processore eseguendo ciclicamente delle istruzioni per richiedere l accesso alla regione critica.

12 7. Si descrivano nel dettaglio le primitive semaforiche e si mostri come queste possano essere usate per risolvere il problema produttoriconsumatori (esame del ) Le primitive semaforiche sono le primitive wait (S) e signal (S) dove S è la variabile semaforica. Il semaforo S è una variabile intera non negativa. Le operazioni di WAIT e SIGNAL sono descritte di seguito: void WAIT (S) { if (s.value==0) /il processo viene sospeso e il suo descrittore inserito in S.CODA/ else S.VALUE=S.VALUE-1; } void SIGNAL (S) { if (esiste almeno un processo nella coda S.CODA dei processi sospesi ) /il suo descrittore viene estratto e inserito nella coda dei processi pronti/; else S.VALUE=S.VALUE+1; } Il problema del produttore consumatore può essere risolto utilizzando le primitive semaforiche nel modo seguente. Ipotesi: buffer di dimensione 1 e inizialmente vuoto. Utilizziamo due semafori: il semaforo spazio-disponibile inizializzato a 1 e il semaforo messaggio-disponibile inizializzato a 0.

13 Processo produttore { do { <produzione del nuovo messaggio>; wait (spazio-disponibile); <deposito del messaggio nel buffer>; signal (messaggio-disponibile); } while (!fine); } Processo consumatore { do { wait (messaggio-disponibile); <prelievo del messaggio dal buffer >; signal (spazio-disponibile); <consumo del messaggio> } while (!fine); } Il produttore produce un nuovo messaggio e fa una wait sul semaforo spazio-disponibile. Se spazio-disponibile=0 allora semaforo rosso e il processo produttore viene sospeso fintanto che il consumatore non consuma il messaggio e lo risveglia. Se invece il semaforo spaziodisponibile=1 (semaforo verde) allora il produttore inserisce il messaggio nel buffer. Ora fa la signal sul semaforo messaggio-disponibile che incrementa messaggio-disponibile al valore 1 se il consumatore non era sospeso, oppure risveglia il consumatore se quest ultimo era sospeso. Il consumatore fa la wait sul semaforo messaggio-disponibile. Se messaggio-disponibile=0 allora il consumatore si sospende in attesa che venga risvegliato dalla signal del produttore. Se messaggiodisponibile=1 il consumatore preleva il messaggio dal buffer e risveglia, con la signal sul semaforo spazio-disponibile, il processo produttore se questo era sospeso, oppure se non era sospeso incrementa spazio disponibile e continua la sua esecuzione consumando il messaggio prelevato dal buffer.

14 8. Si descriva il meccanismo di sincronizzazione mediante semafori nel caso di più produttori e più consumatori. E richiesto lo psudo-codice sia per il produttore sia per il consumatore. (esame del ) La soluzione è analoga al caso di buffer di dimensione 1. Ci saranno ancora due semafori: spazio-disponibile che ora verrà inizializzato al valore N con N dimensione del buffer e messaggio-disponibile che è ancora inizializzato al valore 0. Il produttore verifica che ci sia spazio nel buffer tramite la primitiva wait (spazio-disponibile). Se spazio-disponibile = 0 allora il buffer è pieno e il produttore viene sospeso. Quando il consumatore preleva un messaggio dal buffer, il buffer non è più pieno e il produttore viene risvegliato dal consumatore che esegue la primitiva signal (spazio-disponibile). Il consumatore verifica che ci sia un messaggio nel buffer attraverso la primitiva wait (messaggio-disponibile). Se messaggio-disponibile=0 (buffer vuoto) allora il consumatore viene sospeso in attesa che venga risvegliato dal produttore mediante la signal (messaggio-disponibile). #define spazio-disponibile N #define messaggio-disponibile 0 Processo produttore { do { <produzione del nuovo messaggio>; wait (spazio-disponibile); <deposito del messaggio nel buffer>; signal (messaggio-disponibile); } while (!fine); } Processo consumatore { do { wait (messaggio-disponibile); <prelievo del messaggio dal buffer >; signal (spazio-disponibile); <consumo del messaggio> } while (!fine); }

15 9. Descrivere il meccanismo di sincronizzazione dei processi basato su sleep e wakeup. (esame del ) Esistono diversi meccanismi per sincronizzare i processi. La sincronizzazione è necessaria nel caso di processi interagenti, ossia processi che si influenzano a vicenda durante l esecuzione. Due processi interagenti possono essere in competizione per l uso della stessa risorsa (risorsa condivisa) e allora devono rispettare la proprietà di mutua esclusione. Un solo processo alla volta può accedere alla risorsa condivisa (esempio una variabile) altrimenti si verificano delle corse critiche. Affinché la proprietà di mutua esclusione sia rispettata occorre che i processi siano sincronizzati. Processi interagenti possono anche cooperare ovvero possono scambiarsi informazioni per eseguire un attività comune. In questo caso è necessario che i processi rispettino un determinato ordine di esecuzione (es. produttore consumatore). L ordine da rispettare nel caso di buffer con una sola locazione disponibile è: inserimento-estrazioneinserimento-estrazione. Solo dopo che il produttore ha inserito il messaggio nel buffer il consumatore lo può prelevare. Qualunque altra sequenza non va bene. Le possibili tecniche di sincronizzazione sono: uso delle primitive sleep e wakeup, uso dei semafori con le primitive wait e signal e uso delle primitive send e receive (scambio di messaggi). Il funzionamento della sincronizzazione tramite sleep e wakeup è il seguente: la primitiva sleep() provoca la sospensione del processo che la esegue. La sleep non ha parametri e quindi quando un processo P che è in esecuzione la esegue, esso viene sospeso e il suo descrittore viene inserito nella coda dei processi bloccati in attesa che venga risvegliato. La primitiva che consente di risvegliare un processo P sospeso è la primitiva wakeup (P). La wakeup ha come parametro il processo da risvegliare. Come esempio di utilizzo delle primitive sleep e wakeup consideriamo il problema del produttore-consumatore con buffer di dimensione limitata. Di seguito sono rappresentati i codici del produttore e del consumatore

16 #define TRUE 1 /*costante 1*/!sleep (); /*se il buffer è pieno il produttore si sospende*/ "# #wakeup $ $ %sleep(); /*se il buffer è vuoto il consumatore si sospende*/ #!#wakeup $ $ La descrizione dei due codici è la seguente: Il buffer ha dimensione N. Il produttore produce il messaggio è successivamente controlla che il buffer non sia pieno. Se non è pieno, ovvero contatore<n, allora inserisce nuovo messaggio nel buffer e incrementa il contatore. Se invece contatore=n allora il buffer è pieno e il produttore si sospende con una sleep, in attesa che il consumatore prelevi

17 un messaggio in modo da liberare un posto nel buffer. Se, dopo che ha inserito un messaggio e ha incrementato il contatore, il contatore assume valore 1, allora significa che precedentemente il buffer era vuoto e quindi il consumatore era sospeso. Il produttore risveglia il consumatore con una wakeup(consumatore) che gli dice: guarda che c è un messaggio nel buffer. Il consumatore esegue il seguente algoritmo: Se il contatore=0 significa che il buffer è vuoto (il consumatore non può prelevare messaggi) e quindi si sospende con una sleep in attesa di essere risvegliato dal produttore. Se il buffer non è vuoto, ovvero contatore>0, allora il consumatore preleva il messaggio e decrementa contatore (numero messaggi nel buffer). Se, dopo che ha decrementato il contatore, il consumatore trova che contatore=n-1, allora significa che prima il buffer era pieno e quindi il produttore era sospeso. Il consumatore in questo caso risveglia il produttore con una wakeup(produttore). L uso di sleep e wakeup non elimina però il problema delle corse critiche. La varibile contatore è infatti condivisa da produttore e consumatore. Può allora succedere questo: il buffer è vuoto e viene schedulato il consumatore che legge contatore=0. Prima che il consumatore si sospenda con la sleep, lo scheduler blocca il consumatore che passa nella coda dei processi pronti e manda in esecuzione il produttore. Il produttore legge contatore=0 (il buffer è vuoto) e quindi inserisce il nuovo messaggio nel buffer e incrementa contatore al valore 1. Ora il produttore controlla la variabile contatore e legge contatore=1 e quindi pensa che il consumatore sia sospeso perché il buffer prima era vuoto (contatore=0). Il produttore allora risveglia il consumatore con una wakeup (consumatore). Poiché il consumatore non è sospeso perché non ha fatto alcuna sleep(), il risveglio viene perso. Il consumatore ad un certo punto viene nuovamente schedulato e ritorna in esecuzione. Poiché era stato sospeso subito dopo aver letto contatore=0 allora ora esegue la sleep() e si sospende. Il produttore va nuovamente in esecuzione, fa il controllo sul numero elementi nel buffer, trova che il buffer non è pieno (c è un solo messaggio) e quindi inserisce un nuovo messaggio e incrementa contatore al valore 2. Ora fa il controllo su contatore. Contatore non è uguale a 1 e quindi non risveglia il consumatore che si era sospeso.

18 Continua allora ad inserire altri messaggi finché il buffer non è pieno (N messaggi). Quando contatore=n (buffer pieno) il produttore fa la sleep e si sospende. Ora sia il produttore e sia il consumatore sono sospesi per sempre. 10. Si descrivano i meccanismi di sincronizzazione dei processi mediante scambio di messaggi (esame del ) In un modello d interazione tra processi a scambio di messaggi, detto anche modello ad ambiente locale, la sincronizzazione dei processi avviene attraverso le primitive send e receive. In questo modello non esistono risorse comuni ( gli spazi d indirizzamento dei singoli processi sono separati) e la comunicazione avviene mediante canali di comunicazione. E il tipico modello di una rete di elaboratori dove ogni processo è in esecuzione su una cpu diversa e ciascun processo ha a disposizione una memoria locale (risorsa) il cui gestore è lui stesso. Non esistono variabili condivise. Lo scambio di messaggi può avvenire anche in un modello ad ambiente globale (memoria condivisa). I processi operano in questo caso sulla stessa macchina. Come fanno a comunicare? In questo caso i processi comunicano mediante un canale di comunicazione logico che è rappresentato da una specifica area di memoria allocata appositamente per lo scambio dei messaggi e gestita direttamente dal sistema operativo. Questa area di memoria non è accessibile dai singoli processi. I processi possono solo usarla per inserire messaggi e prelevare messaggi. Il canale funziona come una MAILBOX. In Unix questo è possibile attraverso l utilizzo dello strumento PIPE. La PIPE è un canale unidirezionale. Si inserisce il messaggio da un lato e si preleva dall altro lato. La PIPE inoltre ha capacità limitata. La PIPE è un canale di tipo molti a molti, cioè più processi possono inserire messaggi e più processi possono ricevere messaggi. L accesso ad una PIPE avviene tramite le primitive di lettura (READ) e scrittura (WRITE) di file. Vediamo ora il funzionamento delle due primitive send e receive. Lo schema generale delle due primitive è il seguente:

19 send (destinazione, messaggio) receive (origine, messaggio) La primitiva send spedisce un messaggio alla destinazione specificata, mentre la primitiva receive consente di ricevere un messaggio da un determinato processo origine. la comunicazione tra i processi può avvenire direttamente o indirettamente: la comunicazione diretta può essere simmetrica o asimmetrica. Nel caso di comunicazione diretta i processi si conoscono e si nominano a vicenda. Nella primitiva send deve essere specificato esplicitamente il nome del processo a cui si vuole inviare il messaggio e nella receive deve essere specificato esplicitamente il nome del processo da cui si vuole ricevere il messaggio. Esempio: due processi P1 e P2 che devono comunicare usano il seguente schema: send (P2, messaggio) /* P1 spedisce il messaggio al processo P2*/ receive(p1, messaggio)/* P2 riceve messaggio dal processo P1*/ Se il canale è associato in modo univoco ai due processi allora la comunicazione è simmetrica. Nel caso di comunicazione diretta e asimmetrica solo il processo mittente conosce il destinatario e lo nomina esplicitamente. Il processo destinatario invece non nomina il processo da cui vuole ricevere il messaggio in quanto questo può essere ricevuto da più mittenti. In generale il mittente verrà indicato con un generico id (identificatore di processo) che di volta in volta assumerà il nome del processo con cui è avvenuta la comunicazione. Lo schema è il seguente:

20 send (P2, messaggio) /* P1 spedisce il messaggio al processo P2*/ receive(id, messaggio)/* P2 riceve messaggio dal processo id generico*/ Nel caso di comunicazione indiretta i messaggi non sono spediti direttamente ai processi ma si usa una porta (MAILBOX) per depositare i messaggi e prelevare i messaggi. La MAILBOX è gestita direttamente dal sistema operativo ed è accessibile dai processi attraverso delle opportune system call. send (A, messaggio) /* P1 spedisce il messaggio alla mailbox A*/ receive(a, messaggio) /* P2 preleva il messaggio dalla mailbox A*/ Di seguito è rappresentato il caso di comunicazione client-server: ogni processo che vuole accedere al server effettua la richiesta attraverso la mailbox. Client 1 Client 2 mailbox A Forza Roma server Client N

21 Per quanto riguarda la sincronizzazione mediante send e receive esistono varie possibilità che dipendono dalle proprietà della send e della receive. la send può essere sincrona o asincrona e la receive può essere bloccante o non bloccante. Nel caso di send asincrona il processo mittente continua la sua esecuzione dopo che ha spedito il messaggio senza attendere conferma dal ricevente. Non c è alcuna garanzia che il messaggio sia stato ricevuto. Nel caso di send sincrona il processo mittente rimane bloccato fino alla ricezione del messaggio da parte del destinatario (rendez -vouz semplice) oppure rimane bloccato fino a che il destinatario non elabora il messaggio (termina di svolgere l azione richiesta dal mittente) e risponde (rendez-vous esteso). Nel caso di receive bloccante il destinatario si blocca se non c è nessun messaggio da elaborare. Quando arriva il primo messaggio il processo destinatario viene risvegliato. Nel caso di receive non bloccante il destinatario continua l esecuzione anche se non c è alcun messaggio. Nel modello client-server la send è di tipo sincrono e la receive è bloccante. Il server si blocca se non c è alcun messaggio da elaborare e il client rimane in attesa della risposta dal server. 11. Si illustri (a livello di pseudo-codice) la soluzione del problema dei produttori e dei consumatori risolta mediante semafori (esame del ) Vedi risposta alla domanda 7.