TECN.PROG.SIST.INF. Programmazione concorrente. Roberta Gerboni

Transcript

1 Roberta Gerboni

2 Concorrenza tra processi Multiprogramming più processi presenti in memoria, ma unico processore (parallelismo apparente) Multiprocessing più processori che operano in parallelo (parallelismo reale) In entrambi i casi si hanno gli stessi problemi in quanto non è possibile predire come evolvono i singoli processi e la velocità relativa tra di loro. Concorrenza tra processi La concorrenza tra processi avviene secondo diverse modalità, a seconda del modo in cui due o più processi interagiscano tra loro. Si parla infatti di: Cooperazione e Competizione 2

3 Cooperazione Due processi cooperano se sono logicamente connessi e ciascuno ha bisogno dell altro per operare. L interazione è desiderata e prevista. Concorrenza tra processi Competizione Due processi che potrebbero evolvere indipendentemente, ma entrano in conflitto sulla ripartizione di risorse perché richieste da entrambi. Un tipico esempio è quello del produttore-consumatore in cui un processo si occupa di produrre delle informazioni per un altro processo che poi le utilizzerà. L interazione NON è desiderata e NON prevista. Questo tipo di interazione potrebbe portare il sistema allo stallo. P0 P0 xxx P1 P1 3

4 Cooperazione tra processi Nel caso della cooperazione occorre predisporre meccanismi di comunicazione (IPC Inter Process Comunication) e di sincronizzazione che permettano ai processi di coordinare le loro azioni senza generare situazioni anomale. Questo viene implementato con due diverse modalità: Scambio di messaggi inviati tra processi. Un processo trasmette le informazioni ad un altro processo attraverso operazioni simili alle operazioni di I/O. Memoria condivisa (uso di dati comuni). I processi condividono parte dei loro dati e le modifiche effettuate da un processo possono essere rilevate da un altro processo. 4

5 Cooperazione tra processi Scambio di messaggi o memoria condivisa Quando devono essere scambiate: numerose informazioni poche informazioni Conviene implementare la comunicazione utilizzando la memoria condivisa, con uno o più buffer nei quali depositare e poi prelevare. Problemi: Lettura e scrittura sono incompatibili tra loro, quindi c è la necessità di sincronizzazione dei processi per accesso in mutua esclusione. Conviene implementare la comunicazione utilizzando lo scambio di messaggi, ad esempio usando delle primitive. Problemi: Sincronizzazione per l accesso ai messaggi gestita però implicitamente dal SO fornendo due operazioni: send (messaggio) receive (messaggio) 5

6 Scambio di messaggi Lo scambio di messaggi si presta ad una implementazione su macchine distribuite, dove i processi possono risiedere su macchine diverse connesse ad una rete. (Es. una chat sul Web). La comunicazione dal punto di vista logico attraverso il canale può essere di diversi tipi: Comunicazione diretta I processi devono conoscere esplicitamente il nome del destinatario o del mittente: I messaggi vengono spediti direttamente al processo destinazione Le primitive sono le seguenti: send (P, msg) manda un messaggio al processo P receive (Q, msg) riceve un messaggio dal processo Q L oggetto delle send e receive sono i processi. Le send e receive si bloccano fino a che la controparte non esegue la chiamata duale (rendez-vous). 6

7 Scambio di messaggi Comunicazione indiretta I messaggi sono mandati e ricevuti attraverso una mailbox o porta che sarà condivisa dai due processi che devono comunicare. Ciascuna mailbox ha un identificatore univoco. I messaggi spediti ma non ancora consumati vengono automaticamente bufferizzati nella mailbox. Le primitive sono le seguenti: send (A, msg) manda un messaggio alla mailbox A receive (A, msg) riceve un messaggio dalla mailbox A L oggetto delle send e receive sono le mailbox. La send si blocca se la mailbox è piena; la receive si blocca se la mailbox è vuota. Esempio Server remoto che fornisce pagine HTML ad un browser che le ha richieste e le presenta localmente. 7

8 Scambio di messaggi Windows XPusa due tipi di porte: una di connessione (chiamate object) visibile a tutti i processi per instaurare un canale di comunicazione una di comunicazione - Il client apre la porta di connessione del subsystem con il suo identificatore e manda una richiesta di connessione e effettua una richiesta di connessione al server - Il server crea due porte private di comunicazione e restituisce l identificatore di una di queste al client (connessa attraverso un Handle). - Il client ed il server usano il corrispettivo identificatore di porta per mandare i msg (memorizzati temporaneamente nella coda dei msg della porta se di lunghezza inferiore a 256 bytes o altrimenti in un section object condiviso) e per ascoltare le risposte. 8

9 Competizione tra processi La competizione tra processi si verifica quando più processi cercano di accedere contemporaneamente alla stessa risorsa. Si considerino ad esempio due processi P0 e P1 che hanno entrambi necessità di stampare dati accedendo alla medesima risorsa stampante contemporaneamente. Ad una delle due applicazioni verrebbe necessariamente negato l accesso, oppure i dati delle due applicazioni verrebbero mischiati tra loro. P0 P1 9

10 Competizione tra processi Questa situazione si chiama corsa critica e la parte di codice che viene eseguita per accedere alla risorsa viene chiamata sezione critica o regione critica. Nell esempio sia P0 che P1 dovendo accedere alla stessa risorsa R avranno entrambi nel loro codice una sezione critica e interferiranno tra loro quando entrambi tenteranno di eseguire la sezione critica. /* * Processo P0 * */. Stampa (); Sezioni critica /* * Processo P1 * */. Stampa (); Sezioni critica 10

11 Competizione tra processi 11

12 Competizione tra processi La parte di programma che utilizza una o più risorse condivise viene detta sezione critica (critical section). L esecuzione di sezioni critiche da parte di programmi concorrenti o cooperanti può portare a risultati non attendibili. Per evitare questo: è necessario (ma non sufficiente) evitare che due processi si trovino contemporaneamente all interno di una sezione critica relativa allo stesso dato condiviso la sezione critica deve essereprotetta bloccando temporaneamente uno dei processi Esempio: La variabile totale è globale per i due processi e quindi è condivisa mentre a1 e a2 sono variabili locali e quindi non condivise a1 10 a2 15 totale 1000 Al termine dell esecuzione dei due processi totale ? oppure oppure 12

13 Competizione tra processi a1 10 a2 15 totale 1000 totale 1025 totale 1015 totale 1010 totale

14 Competizione tra processi Una soluzione ai problemi di corsa critica è il metodo di mutua esclusione. Supponiamo di avere da preparare la stampa degli estratti conto di una serie di clienti di una banca. Questa operazione può essere svolta da due processi P0 e P1 cooperanti: - il primo produce i dati di un cliente e li deposita in un buffer - il secondo li preleva dal buffer e li manda in stampa. Clienti P0 Buffer P1 Stampa estratto conto 14

15 Competizione tra processi Clienti P0 Buffer P1 Stampa estratto conto /* * Processo P0 * */ while (esistonoclienti) producidaticliente( ); scrivedatinelbuffer( ); /* * Processo P1 * */ while (esistonoclienti) leggedatidalbuffer( ); stampaestrattoconto( ); 15

16 I due processi P0 e P1 operano in parallelo, ma questa scomposizione non garantisce che queste azioni siano eseguite nell ordine corretto e questo può portare a risultati non corretti. Questo accade a causa: - dell accesso concorrente al buffer Competizione tra processi - della diversa velocità di esecuzione dei processi. Se P0 ritarda nel depositare i dati del cliente successivo P1 rischia di prelevare due volte e quindi di stampare due volte i dati del cliente precedente. viceversa Clienti P0 Buffer P1 Stampa estratto conto se P0 è più veloce a depositare i dati di un cliente rispetto alla velocità di P1 a prelevarli dal buffer e stampare i dati di un cliente, c è il rischio che qualche cliente non venga stampato. Clienti P0 Buffer P1 Stampa estratto conto 16

17 Mutua esclusione Può anche accadere che mentre P0 sta modificando una parte dei dati nel buffer, pensiamo a più campi informazione di un cliente (per esempio il cognome e nome, il codice del conto corrente e il saldo) il processo P1 inizia a prelevare i campi dal buffer che quindi contengono alcuni dati di un cliente e altri ancora del cliente precedente. Clienti P0 Buffer P1 Stampa estratto conto Di fatto sono le variabili condivise, in questo caso il buffer, a determinare le sezioni critiche. Questi problemi si possono presentare sia in sistemi multiprocessore, sia in sistemi monoprocessore dove il parallelismo avviene alternando l esecuzione dei due processi. I problemi accennati possono essere risolti con la mutua esclusione, impedendo a P0 di modificare il buffer mentre P1 vi accede in lettura; questo significa che ciascuno dei due processi deve accedere al buffer in maniera esclusiva. Di conseguenza: l esecuzione di scrivedatinelbuffer( ) può iniziare solo se leggedatidalbuffer( ) è terminata e viceversa 17

18 Soluzioni al problema delle corse critiche Per evitare i problemi della corsa critica (race condition) serve assicurare che: quando un processo esegue la sua sezione critica, nessun altro processo possa entrare nella propria sezione critica. while (TRUE) sezione non critica entrasezionecritica() sezione critica escisezionecritica() sezione non critica 18

19 Soluzioni al problema delle corse critiche Si protegge la sezione critica con apposito codice di controllo che consente di eseguire la sezione in mutua esclusione: entrasezionecritica() escisezionecritica() per accedere alla sezione critica dopo aver terminato la sezione critica L implementazione delle funzioni che regolano l accesso alla sezione critica può avvenire: Attraverso strumenti software Attraverso strumenti hardware 19

20 20

21 Soluzioni software al problema delle corse critiche Per risolvere il problema delle corse critiche devono essere soddisfatti requisiti: i seguenti 1. Garantire la mutua esclusione tra processi che vogliono accedere alla sezione critica. 2. Garantire il progresso: un processo fuori dalla sezione critica non deve impedire, né ritardare l accesso alla sezione critica da parte di altri processi. 3. Non si possono fare ipotesi sulla velocità relativa dei diversi processi (ad esempio che uno sia più veloce di un altro o che eseguano la sezione critica alla stessa velocità). 4. Garantire un attesa limitata per i processi che hanno fatto richiesta di accedere a una sezione critica. Questo significa che un processo può rimanere nella sezione critica per un tempo limitato e non ci deve essere stallo, né ritardo indefinito proprio per non bloccare gli altri processi. 21

22 Soluzioni software al problema delle corse critiche (esempio 1) Per attuare la mutua esclusione per: - accedere alle regioni critiche - sincronizzare i due processi si aggiungono due attese una per P0 che deve aspettare che il buffer sia stato svuotato da P1 e una per P1 che deve aspettare che P0 abbia riempito il buffer. Queste realizzano in pratica il codice entrasezionecritica() sia per P0 che per P1. /* * Processo P0 * */ while (esistonoclienti) producidaticliente( ); //sez. non critica attendibuffervuoto scrivedatinelbuffer( ); bufferpieno Sezioni critiche /* * Processo P1 * */ while (esistonoclienti) attendibufferpieno leggedatidalbuffer( ); buffervuoto stampaestrattoconto( ); //sez. non critica 22

23 Soluzioni software al problema delle corse critiche (esempio 1) Per tenere conto dello stato del buffer, pieno o vuoto, si può usare la variabile globale: pieno che assume il valore true dopo che P0 ha depositato i dati nel buffer e il valore false dopo che P1 ha prelevato i dati dal buffer. /* * Classe EstrattoConto * */ class EstrattoConto static boolean pieno = false; public static void main (String args[ ] ) /* * P0 e P1 sono eseguiti in parallelo * */ P0( ); P1( ); continua 23

24 Soluzioni software al problema delle corse critiche (esempio 1) /* * Processo P0 * */ void P0 ( ) while (esistonoclienti) producidaticliente( ); while (pieno) // attende // buffer vuoto scrivedatinelbuffer( ); pieno = true; //sez.critica // buffer riempito /* * Processo P1 * */ void P1 ( ) while (esistonoclienti) while (!pieno) // attende // buffer pieno leggedatidalbuffer( ); //sez.critica pieno = false; // buffer svuotato stampaestrattoconto( ); In questo modo si sono risolti due problemi: l accesso concorrente alle informazioni del buffer facendo eseguire in mutua esclusione le sezioni critiche individuate nel codice la sincronizzazione dei due processi. 24

25 Osservazioni sull esempio 1 Il problema precedente è stato risolto usando la variabile globale pieno per controllare se il processo P0 o P1 può entrare nella regione critica, ma la soluzione adottata ha anche degli aspetti negativi: Si verifica un busy wait: attesa attiva di un evento (es: testare ripetutamente il valore di una variabile). Nel nostro esempio: while (pieno) // attende buffer vuoto è semplice da implementare, ma consuma risorse: cicli di CPU. Questo può portare a consumi inaccettabili di CPU. (Accettabile solo in caso di attese molto brevi). Soddisfa il requisito di mutua esclusione, ma i due processi eseguono la sezione critica alternandosi, quindi costringe i due processi P0 e P1 ad evolvere alla stessa velocità => inadatto per processi con differenti velocità. In questo modo non è concesso ad un processo di entrare consecutivamente due volte all interno della sezione critica prima che l altro processo non sia entrato a sua volta. Ma uno dei requisiti è che: un processo fuori dalla sezione critica non debba impedire, né ritardare l accesso alla sezione critica da parte di altri processi. 25

26 Osservazioni sull esempio 1 Usando un buffer con capacità unitaria la soluzione adottata con l esempio 1 può sembrare accettabile, ma se il buffer potesse contenere i dati di 100 clienti, la limitazione imposta sarebbe inaccettabile, perché P0 deve poter produrre dati fino a quando il buffer non è pieno e P1 deve poter accedere al buffer fino a quando ci sono dati da prelevare. Queste considerazioni ci portano a concludere che l accesso alle regioni critiche va trattato separatamente dal problema della sincronizzazione tra processi. Una soluzione all attesa attiva Per evitare il problema dell attesa attiva si possono richiamare specifiche syscall o funzioni di kernel che sospendono il processo in attesa di un evento e lo riattivano successivamente quando l evento si è verificato. Esempio: sleep() : il processo si autosospende (si mette in wait) wakeup(pid) : il processo pid viene posto in ready, se era in wait. 26

27 Soluzioni software al problema delle corse critiche (esempio 2) Si utilizzano due variabili condivise con le quali costruire il protocollo di sincronizzazione. Queste due variabili sono un array di due elementi di tipo logico inizializzate entrambe con il valore falso. boolean voglioentrare[ ] = new boolean[2]; voglioentrare[ 0 ] = false; voglioentrare[ 1 ] = false; Il significato di voglioentrare[ 0 ] = true Il significato di voglioentrare[ 1 ] = true significa che P0 vuole entrare nella propria sezione critica significa che P1 vuole entrare nella propria sezione critica 27

28 Soluzioni software al problema delle corse critiche (esempio 2) In questo caso quindi si considerano due processi che: - esprimano l intenzione di entrare nella loro sezione critica, - ma ciascuno dei due gentilmente consente all altro di proseguire se ha già espresso l intenzione. /* * Classe MutuaEsclusione * */ class MutuaEsclusione static boolean voglioentrare[ ] = new boolean[2]; public static void main (String args[ ] ) voglioentrare[ 0 ] = false; voglioentrare[ 1 ] = false; /* * P0 e P1 sono eseguiti in parallelo * */ P0( ); P1( ); continua 28

29 Soluzioni software al problema delle corse critiche (esempio 2) /* * Processo P0 * */ void P0 ( ). voglioentrare[ 0 ] = true; while (voglioentrare[ 1 ] ) sezione Critica voglioentrare[ 0 ] = false;. /* * Processo P1 * */ void P1 ( ). voglioentrare[ 1 ] = true; while (voglioentrare[ 0 ] ) sezione Critica voglioentrare[ 1 ] = false;. P0 esprime l intenzione di entrare nella sua sezione critica, ma attende che voglioentrare[1] sia falso. Per uscire dalla sezione critica P0 esegue un unica istruzione: voglioentrare[ 0 ] = false, consentendo così a P1 di poter accedere alla propria sezione critica se lo ha richiesto. 29

30 Osservazioni sull esempio 2 Anche con questo secondo esempio: è garantita la mutua esclusione perché un solo processo alla volta può accedere alla sezione critica. È garantito anche il progresso infatti uno stesso processo può accedere due volte consecutivamente all interno della proria sezione critica. Sorge però un problema: Introduce la possibilità di stallo dei processi. Se entrambi i processi tentano di entrare nella sezione critica e pongono voglioentrare[ i ] = true In questo caso se i due valori booleani sono settati contemporaneamente nessuno dei due processi riesce a progredire perché attendono l uno la terminazione dell altro con l istruzione : while (voglioentrare[ i ] ) e restano bloccati indefinitamente. 30

31 Soluzioni software al problema delle corse critiche (esempio 3) Algoritmo di Peterson Nel 1965 il matematico olandese Dekker propose un algoritmo efficace, ma piuttosto complicato per risolvere il problema della mutua esclusione. Circa 16 anni dopo, G. L. Peterson, nel 1981, ideò un metodo più semplice di quello di Dekker. Algoritmo di Peterson Combina le soluzioni degli esempi 1 e 2 visti. È basato sulla gentilezza, perché, in caso di accesso contemporaneo alla sezione critica, ciascun processo invita l'altro (o gli altri) a farsi avanti. Vengono usate le seguenti variabili: int turno = 0 boolean voglioentrare[0] = voglioentrare[1] = false Quando il processo P0 vuole entrare nella sezione critica imposta : voglioentrare[0]=true; turno = 1; // serve per dare la precedenza // all altro processo Il ciclo while che realizza l attesa per poter accedere alla sezione critica combina: un test sulla variabile voglioentrare e sulla variabile turno 31

32 Soluzioni software al problema delle corse critiche (esempio 3) /* * Classe MutuaEsclusione * */ class MutuaEsclusione static boolean voglioentrare[ ] = new boolean[2]; static int turno; public static void main (String args[ ] ) voglioentrare[ 0 ] = false; voglioentrare[ 1 ] = false; turno = 1; Algoritmo di Peterson /* * P0 e P1 sono eseguiti in parallelo * */ P0( ); P1( ); continua 32

33 Soluzioni software al problema delle corse critiche (esempio 3) Algoritmo di Peterson /* * Processo P0 * */ void P0 ( ). voglioentrare [ 0 ] = true; turno = 1; while (voglioentrare[ 1 ] AND turno == 1) /* * Processo P1 * */ void P1 ( ). voglioentrare [ 1 ] = true; turno = 0; while (voglioentrare[ 0 ] AND turno == 0) sezione Critica voglioentrare[ 0 ] = false;. sezione Critica voglioentrare[ 1 ] = false;. Se uno dei due processi, ad esempio P0, è entrato nella sezione critica allora voglioentrare[ 0 ] = true e quindi P1 non potrà entrare fino a quando P0 non esce e imposta voglioentrare[ 0 ] = false. Se P0 e P1 vogliono entrare contemporaneamente nella sezione critica significa che voglioentrare[ 0 ] = voglioentrare[ 1 ] = true ma sicuramente turno o vale 0 o vale 1 33

34 Osservazioni sull esempio 3 Algoritmo di Peterson Questo algoritmo usa il concetto di processo favorito per determinare chi deve accedere alla sezione critica (variabile turno). Infatti P0 posiziona voglioentrare [ 0 ] = true, ma imposta turno = 1 per dare la precedenza all altro processo. Risolve i conflitti tra i processi per l accesso alla sezione critica Sincronizza i processi Sono soddisfatte tutte le condizioni: è garantita la mutua esclusione perché un solo processo alla volta può accedere alla sezione critica in quanto una sola delle due condizioni while è vera in un determinato istante. È garantito anche il progresso infatti uno stesso processo può accedere due volte consecutivamente all interno della proria sezione critica se l altro non è in sezione critica. È garantita l attesa limitata (cioè assenza di starvation) infatti P1 entra nella sezione critica al massimo dopo un entrata di P0. Difetto di questo algoritmo: fa uso di attesa attiva. 34

35 Soluzioni software al problema delle corse critiche (esempio 4) Algoritmo del fornaio L algoritmo di Peterson risolve il problema della sezione critica tra due processi. La soluzione del problema della sezione critica per n processi è dovuta all algoritmo del fornaio proposta da Leslie Lamport. Simula la situazione di n clienti, che sono gli n processi, che entrano nel negozio e che prima di essere serviti devono prendere un numero. Quindi prima di entrare nella loro sezione critica: I processi ricevono un numero che è non decrescente, questo significa che due o più processi possono ricevere anche lo stesso numero. Il processo con il numero più basso è quello che entra ogni volta per primo nella sezione critica. Dato che più processi possono avere lo stesso numero, viene scelto quello che ha l indice più basso dato che ogni processo ha un proprio identificativo: se Pi e Pj hanno lo stesso numero => se i < j Pi viene servito per primo altrimenti Pj viene servito per primo 35

36 /* * Processo Pi generico * */ void Pi( ) while (1) sezione non critica Soluzioni software al problema delle corse critiche (esempio 4) Algoritmo del fornaio scelta [ i ] = true; // prendo un numero number [ i ] = max(number [0],, number [n-1] )+1 ; scelta [ i ] = false; for ( j=0; j<n ; j++) // controllo altri processi if ( i!= j ) while ( scelta[ j ] ) // aspetto che Pj prenda il numero while ( (number [ j ]!=0) && (number [ j ], j ) <(number [ i ], i )) // aspetto il mio turno sezione Critica number [ i ] = 0; sezione non critica escisezionecritica entrasezionecritica 36

37 Soluzioni software al problema delle corse critiche (esempio 4) Algoritmo del fornaio Questo algoritmo prevede l uso di variabili condivise, in particolare sono due array di n elementi, un elemento per ogni processo: boolean scelta [ n] = false tutti posti uguali a false int number [ n ] = 0 tutti posti uguali a 0 Abbiamo quindi tutti programmi che eseguono lo stesso codice perché sono n istanze dello stesso programma. La entrasezionecritica consiste nei seguenti passi: il processo Pi prima di accedere alla sezione critica deve prendere un numero e questo lo fa calcolando il massimo di tutti i numeri assegnanti in precedenza agli altri processi + 1 Avendo più processi in competizione tra loro può accadere che alcuni calcolino lo stesso max nello stesso istante e ottengano lo stesso numero. La consegna del numero è preceduta da: scelta [ i ] = true ed è seguita da: scelta [ i ] = false per indicare che Pista prendendo un numero. 37

38 Soluzioni software al problema delle corse critiche (esempio 4) Algoritmo del fornaio Una volta scelto il numero, Pi deve confrontare il proprio numero con quello di tutti gli altri processi e questo viene fatto con il ciclo for con j che parte da 1 e arriva a n-1 (escludendo il caso i = j ). for ( j=0; j<n ; j++) // controllo altri processi if ( i!= j ) while ( scelta[ j ] ) // aspetto che Pj prenda il numero while ( (number [ j ]!=0) && (number [ j ], j ) <(number [ i ], i )) // aspetto il mio turno Pi aspetta nel caso in cui Pj stia prendendo il numero. (while su scelta[ j ]) Poi Pi aspetta che il proprio numero sia il più piccolo di tutti i numeri in possesso degli altri processi e se è uguale a quello di altri aspetta che siano serviti tutti quelli che hanno indice inferiore ad i. (while su number[ j ]) Se number [ j ]==0 l attesa while può essere saltata in quanto Pj non è in attesa di entrare nella sezione critica. Finite queste due attese, Pi può entrare nella sezione critica. E in questo istante Pi sarà l unico processo a trovarsi nella sezione critica Quando Pi avrà terminato, per uscire dalla sezione critica sarà sufficiente porre number[ i ]=0. 38

39 39

40 Soluzioni hardware al problema delle corse critiche (esempio 1) Disabilitazione delle interruzioni Fino ad ora abbiamo utilizzato solo strumenti software per risolvere il problema della sezione critica. Vediamo ora soluzioni hardware che quindi non usano delle variabili condivise. In un ambiente multiprogrammato per garantire la mutua esclusione basterebbe disabilitare le interruzioni, in modo che i processi non vengano interrotti mentre eseguono la sezione critica. Infatti una sezione critica è una porzione di codice che deve essere eseguito in maniera atomica, quindi disabilitando le interruzioni, ad esempio quella del timer in un sistema time-sharing, un processo non viene interrotto fino a quando le interruzioni non vengano riabilitate. In un ambiente multiprogrammato questa soluzione annulla tutti i vantaggi del time sharing. Inoltre non è applicabile in sistemi multiprocessore. Quindi questa soluzione non è praticabile se non in casi particolari e con sezioni critiche di piccola dimensione. /* * Processo Pi * */ void Pi ( ) sezione non critica DisabilitaInterruzioni; sezione Critica AbilitaInterruzioni; sezione non critica 40

41 Soluzioni hardware al problema delle corse critiche (esempio 2) TestAndSet ( ) Molte architetture possiedono particolari istruzioni che sono eseguite atomicamente. Queste istruzioni possono essere utilizzate per risolvere il problema della sezione critica in maniera facile, efficiente e sicura, anche nel caso di n processi. Istruzione TestAndSet ( ) è una funzione che viene eseguita atomicamente : riceve come parametro una variabile logica e restituisce un valore logico /* * Funzione TestAndSet * */ boolean TestAndSet(boolean *target) boolean temp = *target; *target = true; return temp; In particolare: Ritorna vero se target è vero Ritorna falso se target è falso Pone sempre target vero Questa funzione: - mentre testa il valore della variabile target e lo restituisce - setta target a true 41

42 Soluzioni hardware al problema delle corse critiche (esempio 2) TestAndSet ( ) Supponiamo di avere n processi e una variabile globale lock inizialmente impostata a false. Il primo processo che eseguirà while ( TestAndSet (&lock) ) riceverà false e non essendo interrompibile contemporaneamente imposterà lock a true, quindi entrerà subito nella sezione critica, mentre tutti gli altri resteranno bloccati sul TestAndSet che restituirà true. /* * Classe MutuaEsclusioneTestAndSet * */ class MutuaEsclusione static boolean lock ; /* * Processo Pi generico * */ void Pi( ) while (1) public static void main (String args[ ] ) lock = false; /* * P0 Pi sono eseguiti in parallelo * */ P0( );. Pi( ); sezione non critica while ( TestAndSet (&lock) ) sezione Critica lock = false; sezione non critica escisezionecritica entrasezionecritica 42

43 Soluzioni hardware al problema delle corse critiche (esempio 3) In maniera analoga alla TestAndSet ci sono altre istruzioni macchina che eseguono più operazioni in modo atomico. Alcuni sistemi dispongono della: Istruzione Swap( ) che scambia atomicamente il contenuto di due variabili. Anche questa istruzione può essere utilizzata per realizzare la mutua esclusione tra n processi. /* * Funzione Swap * */ void Swap(boolean *a, boolean *b) boolean temp; temp =*a; *a = *b; *b = temp; Istruzione swap ( ) 43

44 44

45 I semafori Relativamente al problema della sincronizzazione tra processi abbiamo visto diverse soluzioni alcune basate su strumenti software e altre su strumenti hardware. Tutte le soluzioni viste implicano comunque un attesa attiva, dato che utilizzano un ciclo while che consuma cicli di CPU e quindi non sono metodi efficienti. Vediamo un nuovo strumento: i semafori che risolvono completamente e in modo efficiente il problema dell attesa attiva Il processo in questo caso viene messo veramente in attesa (utilizzando delle funzioni del sistema operativo) perché viene spostato nello stato di wait fino a quando non si verifica una determinata condizione. Nei moderni sistemi operativi vengono proprio utilizzati i semafori per risolvere il problema della sincronizzazione dei processi nell accesso ad una sezione critica. 45

46 I semafori Il concetto di semaforo è stato inventato dall olandese Edsger Dijkstra, e usato per la prima volta nel sistema operativo THE. I semafori sono speciali variabili intere pensate per gestire i meccanismi di collaborazione tra processi concorrenti e per proteggere l accesso alle sezioni critiche. Il concetto alla base dell uso di semafori è che i processi possono collaborare scambiandosi segnali. Per inviare e ricevere segnali un processo dispone di due primitive atomiche consentono di accedere al semaforo: che s.wait( ) con la quale il processo chiede di accedere alla propria sezione critica. Esso aspetta se altri processi sono dentro la loro sezione critica. s.signal( ) con la quale il processo vuole uscire dalla propria sezione critica consentendo agli altri processi in attesa di proseguire. Altri nomi di wait e signal: wait ( ) == down ( ) == P ( ) P (proberen=testare) signal ( ) == up ( ) == V ( ) V (verhogen=incrementare) 46

47 I semafori I semafori si possono considerare come oggetti composti da: una variabile intera count che serve per contare i segnali inviati al semaforo e il suo valore viene incrementato dalla primitiva signal e decrementato dalla primitiva wait. una coda di processi che si forma perché i processi sono in attesa di ricevere un segnale con wait. Se count 0 e quindi non ci sono segnali, il processo viene fermato e inserito in coda. Il semaforo s ha count = 3; questo significa che nella coda associata ci sono tre processi in attesa di essere riattivati. count Si consideri un semaforo s con il valore iniziale di count = 1, senza processi in coda (fig.a); se un processo Q esegue s.wait() diventa count = 0 e la coda associata a s è vuota (fig.b). Se ora un processo P esegue una s.wait() diventa count = 1 (fig.c). e P viene inserito in coda 47

48 I semafori Definizione di wait e signal s.wait ( ) Il contatore viene decrementato: s.count Se s.count>=0 allora il processo continua l esecuzione altrimenti (s.count < 0) il processo si blocca e viene inserito nella coda s.signal ( ) Se s.count < 0 significa che c è almeno un processo in attesa nella coda e viene estratto Il contatore viene comunque incrementato: s.count ++ 48

49 I semafori Dalla definizione di wait e signal, si può osservare che: count 0 serve a contare i segnali di sveglia inviati a un semaforo s con s.signal() e non ancora consumati con s.wait(). count < 0 serve a contare i processi in coda in attesa di ricevere un segnale di sveglia con s.signal() Questo significa che un semaforo ricorda i segnali di sveglia inviati e quanti s.wait() possono essere eseguiti dai processi sul semaforo s, prima che uno dei processi sia bloccato. 49

50 Implementazione dei semafori Si definisce un semaforo come una struttura dati con: un contatore che rappresenta il numero di processi in attesa sul semaforo e un puntatore a una lista di processi. /* * struttura Semaforo * */ struct Semaforo int count; processo *waiting_list; ; Si assume che siano disponibili due operazioni che sono due chiamate di sistema (syscall): block che sospende il processo che la invoca e sposta il PCB nella coda wakeup(p) che riprende l esecuzione di un processo sospeso P I semafori si possono implementare nel nucleo del sistema operativo in diversi modi. Quello scelto nella slide successiva mostra come realizzare i metodi wait() e signal() con l'istruzione TestAndSet. 50

51 Implementazione dei semafori Nel codice si ipotizza l'esistenza di una variabile globale s della classe Semaforo e si usa una variabile globale, occupata, di tipo boolean per accedere alla sezione critica con una funzione che viene eseguita atomicamente: la TestAndSet /* * Implementazione dei semafori * */ static boolean occupata = false; static Semaforo s; /* * Implementazione di wait() * */ public void wait() while (TestAndSet(occupata)) s.count--; if (s.count < 0) block; //BloccaProcesso; InserisciProcesso (s.coda); occupata = false; I comandi block per bloccare il processo, usato in wait(), e wakeup(p), per riattivare un processo, che compare nel codice di signal(), sono realizzati richiedendo i servizi del sistema operativo per operare il cambiamento di stato del processo. /* * Implementazione di signal() * */ public void signal() while (TestAndSet(occupata)) if (s.count < 0) P=EstraiProcesso(s. coda); wakeup(p); //AttivaProcesso; s.count++; occupata = false; 51

52 Implementazione dei semafori La tecnica di implementazione è simile a quella proposta nella classe MutuaEsclusioneTestAndSet. Lo scopo è infatti esattamente lo stesso: garantire che il controllo del valore di count e il suo aggiornamento avvengano in mutua esclusione. Essendo funzioni di piccole dimensioni abbiamo garantito che le operazioni wait e signal vengano eseguite atomicamente usando l istruzione TestAndSet che comporta un attesa attiva, in questo caso accettabile. Avremmo potuto garantire l esecuzione di wait e signal in mutua esclusione in maniera quindi atomica anche disabilitando le interruzioni subito prima e riabilitandole subito dopo. In questo caso, proprio per la dimensione ridotta del codice da eseguire, non si verrebbero a perdere i vantaggi del time-sharing e della multiprogrammazione. Nel codice si nota anche che le operazioni di attesa e risveglio di un processo sono realizzate richiedendo l'intervento del sistema operativo per modificare lo stato del processo: i semafori sono realizzati, nell'esempio, sia utilizzando speciali istruzioni macchina eseguite in modo atomico, sia i servizi del sistema operativo per la sospensione e la riattivazione dei processi. 52

53 Mutua esclusione con i semafori Per implementare la mutua esclusione si usa un semaforo di nome mutex con la variabile mutex.count inizializzata a 1. La soluzione è generalizzabile a N processi concorrenti. /* * MutuaEsclusione con i semafori * */ class MutuaEsclusione static Semaforo mutex(1); // mutex.count è inizializzato a 1 public static void main (String args[ ] ) /* * P0 e P1 sono eseguiti in parallelo * */ P0( ); P1( ); continua 53

54 Mutua esclusione con i semafori Occorre poi delimitare la porzione di codice che deve essere eseguita in mutua esclusione con wait e signal su quel semaforo. wait e signal prendono il posto delle istruzioni speciali entrasezionecritica ed escisezionecritica. /* * Processo P0 * */ void P0 ( ) entrasezionecritica.. mutex.wait(); sezione Critica mutex.signal();. escisezionecritica /* * Processo P1 * */ void P1 ( ).. mutex.wait(); sezione Critica mutex.signal();. Poiché il metodo wait non è interrompibile, anche se P0 e P1 eseguono contemporaneamente mutex.wait(), le due esecuzioni saranno sequenziali. 54

55 Sincronizzazione con i semafori Per sincronizzare due processi su un evento bisogna utilizzare un semaforo s inizializzato a 0 e usare wait e signal nel seguente modo: il processo che rileva l evento esegue s.signal(), il processo che attende l evento per sincronizzarsi su di esso esegue s.wait(). /* * Sincronizzazine con i semafori * */ class Sincronizzazione static Semaforo s(0); // s.count è inizializzato a 0 public static void main (String args[ ] ) /* * P0 e P1 sono eseguiti in parallelo * */ P0( ); P1( ); continua 55

56 /* * Processo P0 * */ void P0 ( ) AzioniPreEvento; Sincronizzazione con i semafori Esempio: Si consideri il caso di due processi P0 e P1 che si devono sincronizzare su un evento rilevato da P1. Per esempio, P1 rileva l'arrivo in stazione di un treno a lunga percorrenza, mentre P0 autorizza la partenza di un treno locale che viaggia in coincidenza con il primo treno. /* * Processo P1 * */ void P1 ( ) RilevaEvento; s.wait(); s.signal(); AzioniPostEvento; AttendeEvento AltreAzioni; EventoRilevato SeP0 esegue s.wait() prima che P1 rilevi l'evento ed esegua s.signal(), => s.count diventa negativo e P0 viene bloccato sul semaforo s sino alla rilevazione dell'evento da parte di P1. Se invece fosse P1 a eseguire s.signal() per primo, => il valore di s.count diventerebbe 1 e P0, dopo avere invocato s.wait(), non sarebbe bloccato e potrebbe proseguire nell'esecuzione. 56

57 Stallo e attesa indefinita con i semafori Un semaforo con coda d'attesa può generare delle situazioni di stallo (deadlock), ossia di attesa indefinita di un evento. Esempio Siano S e Q due semafori inizializzati a 1 /* * Processo P0 * */ void P0 ( ) s.wait(); q.wait();.. /* * Processo P1 * */ void P1 ( ) q.wait(); s.wait();.. s.signal(); q.signal(); q.signal(); s.signal(); Il processo P0 esegue s.wait(), quindi P1 deve aspettare s.signal() prima di entrare nella sezione critica; d'altro canto P1 esegue q.wait(), quindi P0 deve aspettare q.signal() prima di poter eseguire la sua sezione critica e, in seguito, s.signal(); ciò comporta una situazione di stallo. 57

58 Monitor I semafori forniscono un ottimo strumento per la programmazione concorrente, anche se richiedono spesso una complessa tecnica di programmazione paragonabile a scrivere istruzioni macchina. E più difficile che scrivere programmi in assembly, perché gli errori e i malfunzionamenti sono difficili da individuare essendo in genere non riproducibili. Per questi motivi nella programmazione concorrente sono stati ideati costrutti linguistici di livello più elevato rispetto ai semafori. Il programmatore scrive i propri programmi utilizzando delle istruzioni potenti, ma più semplici da usare e sarà poi il compilatore che si occuperà di tradurle in righe di codice che ad esempio usano i semafori. 58

59 Monitor Un costrutto ad alto livello per la programmazione è il monitor introdotto da Charles Hoare nel Esso è utilizzato per definire tipi di risorse condivise e consente di controllare l accesso ad una risorsa condivisa: Le primitive di mutua esclusione sono introdotte automaticamente dal compilatore. Un monitor è una classe che include: Dati condivisi tra processi. Le procedure che operano su questi dati Il codice per inizializzarli. Variabili speciali dette variabili condizione Primitive per la sincronizzazione tra processi che usano il monitor. 59

60 Un monitor: Monitor Protegge i dati da accessi poco strutturati Garantisce che i dati condivisi siano acceduti solo attraverso interfacce ben definite. Un monitor garantisce la muta esclusione: Un solo thread alla volta può eseguire una procedura definita nel monitor (in questo caso si dice che il thread è nel monitor). Un thread che richiama una procedura di monitor, quando un altro thread è già nel monitor, viene BLOCCATO su un opportuna coda associata al monitor. Quando un thread all interno del monitor si blocca, un altro thread deve poter accedere al monitor. 60

61 Monitor Le variabili e le procedure di monitor sono caratterizzate dai seguenti comportamenti: Le variabili del monitor sono accessibili solo attraverso le procedure definite nel modulo stesso. Le procedure del monitor sono le uniche operazioni ammesse sulle variabili locali del modulo. Le procedure di monitor sono eseguite in mutua esclusione. Una sola procedura può essere attiva in un dato momento. Se due processi cercano di attivare contemporaneamente procedure di monitor, anche differenti, solo una delle due sarà eseguita. Il processo che ha chiamato l'altra rimane in attesa, in una coda di processi abbinata al monitor. Si dice che un processo P è entrato nel monitor quando riesce ad eseguire una procedura di monitor. Le variabili di condizione sono un meccanismo introdotto con i monitor per sospendere e riattivare i thread in coda in attesa della verifica di particolari condizioni su queste variabili. Le procedure definite su queste variabili: Wait il processo che la effettua viene sospeso e introdotto nella coda individuata dalla variabile e rilascia il lock sul monitor; si mette quindi in attesa di essere risvegliato da una successiva Signal sulla stessa variabile (questo significa che per ogni variabile conditione deve essere implementata una coda) Signal risveglia un processo in attesa. Se non vi sono processi in coda, non produce effetti. 61

62 Accesso al monitor Il controllo nell accesso al monitor e alla risorsa da esso rappresentata viene realizzato tramite la sospensione dei processi in alcune code: Primo livello (mutua esclusione): se un processo P che vuole accedere al monitor (tramite un operazione public) lo trova occupato, esso viene sospeso nella entry queue. Secondo livello: Il secondo livello controlla l ordine con il quale i processi hanno accesso alla risorsa. Se la condizione di sincronizzazione C i di un processo P che esegue le istruzioni nel monitor (tramite una funzione public) non è soddisfatta, esso viene sospeso liberando il monitor e viene posto nella condition queue associata alla condizione C i di sincronizzazione. Monitor 62

63 Monitor Un monitor si dichiara con una sintassi del tipo: monitor NomeMonitor VariabiliDelMonitor; condition VariabiliCondizione; /* * Procedure del monitor * */ void ProceduraMonitor1 (...) void ProceduraMonitor2 (... ) void ProceduraMonitorN (... ) /* * Inizializzazione delle variabili del monitor * */ CodiceDelMonitorPerInizializzazioni 63

64 Soluzioni con Monitor Esempio 1 Una sala cinematografica ha molte casse che effettuano la vendita di biglietti. Il numero di posti ancora disponibili deve essere continuamente aggiornato e visualizzato sugli schermi nell atrio del cinema per informare gli spettatori. Il numero di posti liberi è memorizzato nella variabile intera postiliberi condivisa dalle diverse casse e decrementata ad ogni vendita. L accesso concorrente a postiliberi per decrementare il valore è una corsa critica che va eseguita in mutua esclusione. Si può risolvere il problema inserendo il metodo che decrementa il numero di posti liberi in un monitor in modo che la sua esecuzione avvenga in mutua esclusione. Posti liberi Cassa 1 Cassa 2 Cassa 3 64

65 Soluzioni con Monitor /* * Definizione del monitor Posti * */ monitor Posti int postiliberi; /* * Procedura del monitor * */ boolean assegnaposto() if (postiliberi>0) postiliberi ; return true; else return false; /* * Inizializzazione della variabile del monitor * */ postiliberi = 350; // variabile privata del monitor Alla creazione del monitor Posti la variabile privata postiliberi viene inizializzata con il valore 350 /* * Posti liberi con un monitor * */ Class AcquistoBiglietto monitor Posti; public static void main (String args[ ] ) /* * Tutti i processi sono eseguiti in parallelo * */ cassa( ); cassa( );.. cassa( ); /* * cassa esegue * */ void cassa( ) boolean eseguito; while (true) ArrivaSpettatore; eseguito = Posti. assegnaposto( ); if (eseguito). else.; 65

66 Soluzioni con Monitor Esempio 2 Problema presentato da Dijkstra nel 1965 per esporre un problema di sincronizzazione. Cinque filosofi sono seduti attorno a un tavolo circolare. Ogni filosofo ha un piatto di spaghetti che necessitano di 2 forchette per poter essere mangiati. Sul tavolo vi sono in totale 5 forchette. Ogni filosofo può prendere una forchetta alla volta e ha un comportamento ripetitivo, che alterna due fasi: una fase in cui pensa, una fase in cui mangia. Rappresentando ogni filosofo con un thread, realizzare una politica di sincronizzazione che eviti situazioni di deadlock. Osservazioni - I filosofi non possono mangiare tutti insieme: ci sono solo 5 forchette, mentre ne servirebbero 10; - Due filosofi vicini non possono mangiare contemporaneamente perché condividono una forchetta e pertanto quando uno mangia, l'altro è costretto ad attendere. 66

67 Soluzioni con Monitor Soluzione n.1 Quando un filosofo ha fame: 1. prende la forchetta a sinistra del piatto 2. poi prende quella che a destra del suo piatto 3. mangia per un po 4. poi mette sul tavolo le due forchette. Possibilità di deadlock: se tutti i filosofi afferrassero contemporaneamente la forchetta di sinistra, tutti rimarrebbero in attesa di un evento che non si potrà mai verificare. Soluzione n.2 Quando un filosofo ha fame: 1. Ogni filosofo verifica se entrambe le forchette sono disponibili: in caso affermativo, acquisisce le due forchette (in modo atomico); in caso negativo, aspetta. in questo modo non si può verificare deadlock (per un filosofo non c è possesso mentre attende) 67

68 Implementazione soluzione n.2 Soluzioni con Monitor /* * Definizione del monitor Tavola * */ public class Tavola private int forchette[5]; // variabile privata del monitor private Condition codaf[5]; // 1 coda per ogni filosofo private Lock lock= new ReentrantLock(); /* * Procedure del monitor * */ // metodi public : public void prendiforchette (int i)... public void rilasciaforchette (int i)... // metodi privati: int destra (int i) int sinistra (int i) // costruttore Inizializzazioni Public Tavola( ) for ( int i=0; i<5; i++) codaf[i] = lock.newcondition(); for ( int i=0; i<5; i++) forchette[i]=2; // le forchette disponibili per ogni filosofo i-esimo // inizialmente sono 2 Processo: filosofo Risorsa condivisa: la tavola apparecchiata definiamo la classe tavola, che rappresenta il monitor che alloca le forchette Viene dichiarato un vettore di tipo variabile Condition codaf. ReentrantLock è una classe che implementa l interfaccia Lock. Ad ogni variabile condizione deve essere associato un lock. Per questo la creazione di una variabile Condition deve essere effettuata mediante il metodo newcondition() del lock associato ad essa. 68

69 Implementazione soluzione n.2 Soluzioni con Monitor /* * Struttura del Filosofo i-esimo * */ public class Filosofo extends Thread Tavola m; // istanza del monitor int i; La classe Filosofo è un estensione della classe Thread. public Filosofo (Tavola M, int id) this.m =M; this.i=id; public void run( ) while(true) System.out.print("Filosofo "+ i+" pensa...\n"); m.prendiforchette(i); System.out.print("Filosofo "+ i+" mangia...\n"); sleep(10); m.rilasciaforchette(i); sleep(100); Vene riscritto il metodo public void run() della classe Thread (overriding) che verrà eseguito quando verrà richiamato il metodo start() per un thread della classe Filosofo. 69