Sistemi Operativi A Parte III - Sincronizzazione

Transcript

1 Cooperazione e competizione tra processi (1) Sistemi Operativi A Parte III - Sincronizzazione Augusto Celentano Università Ca Foscari Venezia Corso di Laurea in Informatica Due o più processi possono interagire fra loro secondo due modalità: cooperazione e competizione due processi cooperano se sono logicamente connessi e ciascuno ha bisogno dell altro per operare l interazione è desiderata e prevista due processi competono se potrebbero evolvere indipendentemente ma entrano in conflitto sulla ripartizione di risorse l interazione è non desiderata e non prevista Augusto Celentano Sistemi Operativi A - Parte III - 2 Cooperazione e competizione tra processi (2) Cooperazione e competizione tra processi (3) Cooperazione genera dati scrive buffer produttore legge buffer usa dati consumatore In entrambi i casi occorre predisporre meccanismi di sincronizzazione e comunicazione che permettano ai processi di gestire la cooperazione o la competizione: attraverso l uso di dati comuni (memoria condivisa) i processi condividono parte dei loro dati: le modifiche effettuate da un processo possono essere rilevate da un altro processo Competizione processo 1 attraverso lo scambio di messaggi un processo trasmette le informazioni ad un altro processo attraverso operazioni simili alle operazioni di I/O processo 2 Augusto Celentano Sistemi Operativi A - Parte III - 3 Augusto Celentano Sistemi Operativi A - Parte III - 4

2 Cooperazione e competizione tra processi (4) Una coppia (o un insieme) di processi cooperanti può condividere una parte dei dati può sincronizzarsi in momenti selezionati dell esecuzione Una coppia (o un insieme) di processi in competizione deve evitare di condividere risorse comuni in modo scorretto deve sincronizzarsi nell accesso alle risorse condivise Ciascun processo evolve anche indipendentemente dagli altri i processi operano (anche) su dati privati le operazioni sui dati condivisi (per cooperazione o per competizione) devono essere controllate per evitare interferenze Augusto Celentano Sistemi Operativi A - Parte III - 5 Processi concorrenti Sono processi il cui comportamento è influenzato dalla contemporanea presenza di altri processi il comportamento è indipendente dalla velocità di esecuzione, purché esista la possibilità di sincronizzarsi su punti specifici dell'esecuzione (es. produttore-consumatore) se una coppia di processi viene rieseguita con gli stessi programmi, gli stessi dati, e gli stessi meccanismi di sincronizzazione, produce gli stessi risultati Augusto Celentano Sistemi Operativi A - Parte III - 6 Condizioni di interferenza (1) Si ha una condizione di interferenza quando due o più processi accedono ad una informazione comune la modificano attraverso sequenze di operazioni non atomiche, il risultato finale varia al variare dell ordine relativo delle singole operazioni i = 10; i = 10; i = i * 2; i = i + 1; if (i == 20) if (i == 11) Condizioni di interferenza (2) La parte di programma che manipola informazioni condivise è detta sezione critica per evitare interferenza è 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 essere protetta bloccando temporaneamente uno dei processi i = 10; i = 10; i = i * 2; i = i + 1; if (i == 20) if (i == 11) Augusto Celentano Sistemi Operativi A - Parte III - 7 Augusto Celentano Sistemi Operativi A - Parte III - 8

3 Sezione critica (1) L accesso ad una sezione critica deve essere regolato preceduto da una richiesta di accesso (entry section) seguito da una segnalazione di uscita (exit section) Il codice esterno alla sezione critica non richiede controllo L esecuzione di una sezione critica richiede un protocollo tale per cui il risultato non dipende dall ordine di esecuzione delle istruzioni su sistemi monoprocessore su sistemi multiprocessore Sezione critica (2) La struttura generale di un processo in cui si manipolano dati condivisi è la seguente {... // codice esterno alla SC entry section... // codice della SC exit section... // codice esterno alla SC Augusto Celentano Sistemi Operativi A - Parte III - 9 Augusto Celentano Sistemi Operativi A - Parte III - 10 Sezione critica (3) La corretta implementazione del protocollo di accesso ad una sezione critica richiede quattro condizioni: 1. non deve esserci mai più di un processo in una sezione critica (mutua esclusione) 2. non deve essere fatta nessuna ipotesi sulla velocità o sul numero dei processori 3. nessun processo fuori dalla sezione critica può bloccare altri processi 4. nessun processo deve attendere indefinitamente prima di entrare nella sezione critica Il problema produttore-consumatore (1) Due processi cooperano trasferendo dati dal primo processo (produttore) al secondo (consumatore) i due processi hanno una struttura ciclica produttore while(1) { prepara un dato trasferisci il dato al consumatore consumatore while(1) { preleva il dato dal produttore utilizza il dato le velocità relative non sono definite a priori e possono variare nel corso dell esecuzione non si devono perdere né duplicare dati Augusto Celentano Sistemi Operativi A - Parte III - 11 Augusto Celentano Sistemi Operativi A - Parte III - 12

4 Il problema produttore-consumatore (2) Soluzioni per la gestione delle sezioni critiche struct itemtype {... ; itemtype buffer[n]; int in, out; //processo produttore itemtype item; in = 0; { calcola item; while ((in+1) % N == out) ; buffer[in] = item; in = (in+1) % N; produttore consumatore //processo consumatore itemtype item; out = 0; { while (in == out) ; item = buffer[out]; out = (out+1) % N; usa item; Software algoritmi la cui correttezza non dipende da fattori esterni all algoritmo stesso Hardware disabilitazione delle interruzioni istruzioni macchina speciali Sistema operativo / linguaggio costrutti linguistici, funzioni e strutture dati per la programmazione di applicazioni concorrenti Augusto Celentano Sistemi Operativi A - Parte III - 13 Augusto Celentano Sistemi Operativi A - Parte III - 14 Soluzioni software (1) Soluzioni software (2) Si basano su algoritmi che tendono a garantire le condizioni necessarie per una corretta gestione delle sezioni critiche mutua esclusione attesa finita per entrare nella sezione critica le condizioni sulla velocità di esecuzione e sul comportamento fuori dalla sezione critica non sono critiche la variabile condivisa turno è inizializzata prima di eseguire i processi la sezione critica del processo Pi è eseguita se e solo se turno = i il processo Pi è in un ciclo di attesa (busy waiting) se il processo Pj è nella sezione critica (mutua esclusione) i processi si alternano in ordine stretto processo Pi { while (turn!=i) ; sezione critica turn = j; resto del processo Augusto Celentano Sistemi Operativi A - Parte III - 15 Augusto Celentano Sistemi Operativi A - Parte III - 16

5 Soluzioni software (3) Soluzioni hardware (1) La soluzione software non è soddisfacente i processi si alternano in senso stretto anche se la loro velocità è molto diversa i processi che devono entrare nella sezione critica eseguono un ciclo di attesa che utilizza inutilmente la CPU (busy waiting) se il processo Pi termina per errore nella sezione critica gli altri processi rimangono in attesa se la sezione critica è lunga è meglio mettere in stato di attesa (blocked) i processi che aspettano di entrarvi Vi sono soluzioni più complesse (algoritmo di Dekker, algoritmo di Peterson) che garantiscono un maggior parallelismo ma non risolvono il problema della terminazione per errore il consumo inutile di CPU Augusto Celentano Sistemi Operativi A - Parte III - 17 L indivisibilità dell esecuzione della sezione critica può essere ottenuta disabilitando le interruzioni nulla può interrompere l esecuzione fino a che le interruzioni rimangono disabilitate non è possibile alternare l esecuzione con altri processi fuori dalla loro sezione critica la sezione critica deve essere breve e affidabile non è utilizzabile su sistemi multiprocessor processo Pi { disabilita interruzioni sezione critica riabilita interruzioni resto del processo Augusto Celentano Sistemi Operativi A - Parte III - 18 Soluzioni hardware (2) L istruzione test-and-set (1) L indivisibilità dell esecuzione deve riguardare l entry section della sezione critica ogni processo chiede l accesso alla sezione critica con un operazione indivisibile successivamente la mutua esclusione è garantita dal fatto che agli altri processi viene negato l accesso Si può ottenere disabilitando le interruzioni o con istruzioni macchina speciali l accesso ad una locazione di memoria è un operazione atomica è necessario poter leggere e modificare il valore di una locazione di memoria con una sola istruzione macchina funziona anche su macchine multiprocessor E implementata su alcune architetture (es. Motorola 68000) E un istruzione che realizza in modo indivisibile questo algoritmo bool testset(int &i) { if (i == 0) { i = 1; return true; else return false; La variabile i è condivisa e inizializzata a 0 Solo il primo processo che imposta i a 1 entra nella sezione critica processo Pi { while (!testset testset(i)) ; sezione critica i = 0; resto del processo Augusto Celentano Sistemi Operativi A - Parte III - 19 Augusto Celentano Sistemi Operativi A - Parte III - 20

6 L istruzione test-and-set (2) La mutua esclusione è garantita se un processo Pi entra nella sezione critica gli altri processi restano in ciclo di attesa (busy waiting) perché l istruzione testset restituisce il valore false Non sono risolti gli altri problemi la CPU è utilizzata inutilmente per i cicli di attesa quando il processo Pi esce dalla sezione critica la scelta del prossimo processo è arbitraria un processo potrebbe non essere mai scelto (starvation) Altre architetture forniscono istruzioni simili l istruzione xchg(a,b) del Pentium cambia il valore di due locazioni di memoria in una sola operazione i problemi sono gli stessi Meccanismi di sincronizzazione del S.O. (1) Le soluzioni esaminate non sono adeguate l impiego di cicli di attesa impegnano inutilmente la CPU la disabilitazione delle interruzioni non è una soluzione praticabile i processi non possono controllare in modo appropriato l ordine di accesso alla sezione critica Sono necessari meccanismi predisposti dal sistema operativo per controllare la mutua esclusione assegnare l uso della CPU in modo efficiente garantire l accesso ad ogni processo Augusto Celentano Sistemi Operativi A - Parte III - 21 Augusto Celentano Sistemi Operativi A - Parte III - 22 Meccanismi di sincronizzazione del S.O. (2) Semafori variabili su cui sono definite operazioni indivisibili di accesso e impostazione Monitor costrutti linguistici ad alto livello che permettono di incapsulare le sezioni di codice che hanno funzioni di sincronizzazione Scambio di messaggi meccanismi di comunicazione stile I/O per il trasferimento di informazioni tra due o più processi sono realizzabili su sistemi concentrati o distribuiti Semafori (1) I semafori sono meccanismi di sincronizzazione e mutua esclusione forniti dal sistema operativo non richiedono cicli di attesa consentono la realizzazione di politiche di scheduling Un semaforo è concettualmente una variabile intera s su cui, una volta inizializzata, possono essere eseguite solo due operazioni primitive e indivisibili wait(s) altri nomi: down(s), P(s) signal(s) altri nomi: up(s), V(s) Ad un semaforo è associato un meccanismo di sospensione dei processi che evita i cicli di attesa Augusto Celentano Sistemi Operativi A - Parte III - 23 Augusto Celentano Sistemi Operativi A - Parte III - 24

7 Semafori (2) In pratica un semaforo è una struttura dati più complessa su cui agiscono le operazioni wait e signal L operazione wait comporta l esame del valore del semaforo se è negativo (rosso) il processo viene bloccato e messo in coda sul semaforo se è positivo (verde), viene decrementato di un unità e il processo prosegue l esecuzione L operazione signal incrementa il valore del semaforo se <= 0 rimuove un processo dalla coda (FIFO) e lo porta in stato di pronto se > 0 non succede nulla Semafori (3) struct semaphore { int count; process *queue; s; wait(semaphore &s) { s.count-- --; if (s.count < 0) blocca il processo e lo accoda a s->queue signal(semaphore &s) { s.count++; if (s.count <= 0) rimuove un processo da s->queue e lo porta nella ready queue Augusto Celentano Sistemi Operativi A - Parte III - 25 Augusto Celentano Sistemi Operativi A - Parte III - 26 Semafori (4) Il valore del semaforo rappresenta il numero di accessi consentiti (risorse libere) se >= 0 il numero di processi in attesa se < 0 (valore assoluto) Se il numero massimo di accessi consentiti è 1 si parla di semaforo binario se = 1 è verde se <= 0 è rosso, il valore assoluto del semaforo è uguale al numero dei processi in attesa Per entrambi i tipi di semaforo il valore 0 rappresenta l impossibilità di accedere ad una risorsa, senza che vi siano processi già in coda Semafori (5) Le operazioni wait e signal sono indivisibili e esclusive tra loro accedono alla stessa struttura dati un solo processo per volta può eseguirle funzionano anche su sistemi multiprocessor Il codice che implementa le operazioni wait e signal rappresenta una sezione critica molto breve e controllata può essere implementata disabilitando le interruzioni o con istruzioni del tipo test-and-set Augusto Celentano Sistemi Operativi A - Parte III - 27 Augusto Celentano Sistemi Operativi A - Parte III - 28

8 Mutua esclusione Un semaforo di mutua esclusione permette di risolvere i problemi di competizione per l uso di una risorsa condivisa (accesso ad una sezione critica) il semaforo ha valore iniziale = 1 (la sezione critica all inizio è libera) Processo 1 Processo wait(mutex mutex); wait(mutex mutex); sezione critica sezione critica signal(mutex mutex); signal(mutex mutex); se sono ammessi n processi contemporaneamente (risorse multiple) il valore iniziale del semaforo è impostato a n Augusto Celentano Sistemi Operativi A - Parte III - 29 Sincronizzazione produttore-consumatore (1) Un solo semaforo non permette di gestire la cooperazione produttore-consumatore attraverso un buffer condiviso produttore while(1) { genera(datoout datoout); wait(s); copia(buffer,datoout datoout); signal(s) consumatore while(1) { wait(s); copia(datoin datoin,buffer); signal(s); usa(datoin datoin); non corretto! Il produttore può produrre nuovi dati prima che il consumatore abbia letto i precedenti, e il consumatore può leggere più volte gli stessi dati Augusto Celentano Sistemi Operativi A - Parte III - 30 Sincronizzazione produttore-consumatore (2) Sincronizzazione produttore-consumatore (3) La cooperazione avviene in base a due situazioni distinte, ciascuna descritta dallo stato di un semaforo: il produttore può produrre se e solo se il buffer è vuoto, riempiendolo il consumatore può consumare se e solo se il buffer è pieno, svuotandolo all inizio vuoto = 1 (verde), pieno = 0 (rosso) produttore while(1) { genera(datoout datoout); wait(vuoto); copia(buffer,datoout datoout); signal(pieno) consumatore while(1) { wait(pieno); copia(datoin datoin,buffer); signal(vuoto); usa(datoin datoin); struct itemtype {... ; itemtype buffer[n]; int in, out; semaphore npieni=0, nvuoti=n; //processo produttore itemtype item; in = 0; { calcola item; wait(nvuoti nvuoti); buffer[in] = item; in = (in+1) % N; signal(npieni npieni); produttore consumatore //processo consumatore itemtype item; out = 0; { wait(npieni npieni); item = buffer[out]; out = (out+1) % N; signal(nvuoti nvuoti); usa item; Augusto Celentano Sistemi Operativi A - Parte III - 31 Augusto Celentano Sistemi Operativi A - Parte III - 32

9 Problemi di utilizzo dei semafori I semafori sono strutture molto semplici che realizzano i meccanismi fondamentali di sincronizzazione attraverso le operazioni wait e signal i processi possono sincronizzarsi ma hanno un controllo limitato sullo stato complessivo del sistema l utilizzo coerente dei semafori è responsabilità di ogni processo separatamente non esiste un meccanismo centralizzato di controllo la gestione di situazioni di errore, time-out, recovery,, è difficile Monitor (1) I monitor sono costrutti linguistici ad alto livello che permettono di definire operazioni di sincronizzazione in modo più controllato ed esteso un monitor è una collezione di procedure, variabili e strutture dati racchiuse in una unità modulare condivisa tra più processi i processi possono utilizzare le procedure del monitor ma non possono accedere direttamente alle sua variabili o alle sue strutture dati (analogamente al concetto di classe) le procedure del monitor sono eseguite in mutua esclusione Augusto Celentano Sistemi Operativi A - Parte III - 33 Augusto Celentano Sistemi Operativi A - Parte III - 34 Monitor (2) Monitor (3) La sincronizzazione si realizza attraverso il concetto di condition le variabili di tipo condition possono essere dichiarate e utilizzate solo in un monitor su una variabile condition possono essere eseguite solo due operazioni: wait e signal (diverse da quelle dei semafori!) l esecuzione di una operazione wait su una variabile di tipo condition comporta l immediata sospensione del processo l esecuzione di una operazione signal su una variabile condition comporta la riattivazione del processo che aveva eseguito una operazione wait sulla stessa variabile monitor buffer struct itemtype {... ; itemtype buffer[n]; int slot; condition pieno, vuoto; entry riempi(itemtype itemtype item); { if (slot == N) pieno.wait; copia item in buffer slot++; if (slot == 1) vuoto.signal signal; entry svuota(itemtype &item item); { if (slot == 0) vuoto.wait; copia buffer in item slot-- --; if (slot == N-1) pieno.signal signal; buffer() // inizializzazione { slot = 0; //processo produttore { calcola item buffer.riempi(dati) //processo consumatore { buffer.svuota(item item) usa item Augusto Celentano Sistemi Operativi A - Parte III - 35 Augusto Celentano Sistemi Operativi A - Parte III - 36

10 Monitor (4) I processi attendono in coda per l accesso al monitor o su una variabile condition L operazione wait(c) mette il processo nella coda della condition c la mutua esclusione nell accesso al monitor viene rilasciata e un altro processo può eseguire una procedura del monitor L operazione signal(c) riporta nel monitor un processo dalla coda della condition c se non ci sono processi sospesi l operazione non ha effetto Semafori vs. monitor (1) I semafori e i monitor presentano affinità e differenze ad ogni semaforo è associata una coda di processi in attesa sul semaforo ad ogni variabile di tipo condition è associata una coda su cui attendono i processi sospesi l operazione wait su un semaforo è sospensiva solo se il semaforo è rosso l operazione wait in un monitor è immediatamente sospensiva ogni controllo sulla necessità di sospendersi deve essere effettuato attraverso strutture dati ausiliarie Il meccanismo dei monitor è più elementare del meccanismo dei semafori Augusto Celentano Sistemi Operativi A - Parte III - 37 Augusto Celentano Sistemi Operativi A - Parte III - 38 Semafori vs. monitor (2) E possibile implementare i semafori utilizzando il costrutto monitor il monitor ha una variabile intera (il semaforo), una variabile condition (la coda) e due procedure wait e signal la procedura wait esamina il valore della variabile che rappresenta il semaforo e decide se sospendere il processo Per implementare i monitor serve un meccanismo di mutua esclusione nell accesso è necessario utilizzare un semaforo per garantire che solo un processo per volta accede ad una procedura di monitor Quindi? Scambio di messaggi (1) I semafori e i monitor sono basati sull uso di variabili condivise possibile solo se i processi che si sincronizzano accedono alla stessa memoria La sincronizzazione per scambio di messaggi consente di fari interagire processi che risiedono su macchine diverse la comunicazione si basa sull invio di dati da un processo mittente ad un processo destinatario la sincronizzazione si basa sulla relazione temporale che intercorre tra l invio di un messaggio e la sua ricezione Augusto Celentano Sistemi Operativi A - Parte III - 39 Augusto Celentano Sistemi Operativi A - Parte III - 40

11 Scambio di messaggi (2) In genere le operazioni relative allo scambio messaggi hanno una struttura uniforme send (destinatario, messaggio) receive (mittente, messaggio) l esecuzione della funzione receive blocca il ricevente finché il messaggio non arriva. l esecuzione della funzione send blocca il mittente se il sistema non ha risorse per la trasmissione Si utilizzano anche schemi più complessi basati sul controllo reciproco dell avvenuta comunicazione (acknowledgment) Scambio di messaggi (3) struct itemtype {... ; //processo produttore itemtype item; { calcola item; send(consumatore, (consumatore,item item); produttore consumatore //processo consumatore itemtype item; { receive(produttore, (produttore,item item); usa item; Augusto Celentano Sistemi Operativi A - Parte III - 41 Augusto Celentano Sistemi Operativi A - Parte III - 42 Problemi di utilizzo dei messaggi La cooperazione con scambio di messaggi richiede che i processi che cooperano si conoscano a vicenda i processi conoscono gli identificativi degli altri processi solo a run-time in un sistema distribuito ogni processo conosce solo l ambiente locale Si possono adottare varie soluzioni ogni processo è in comunicazione con una mailbox (casella postale), identificata con un nome, a cui invia e da cui riceve i dati in modo dinamico il sistema identifica le mailbox e le associa ai processi il messaggio contiene anche l identificazione del mittente La sincronizzazione in Unix La gestione della sincronizzazione in Unix SVR4 riguarda due aspetti scambio di dati segnalazione di eventi Lo scambio di dati avviene attraverso pipe: operazioni di I/O su code FIFO, sincronizzate dal S.O. messaggi: invio e ricezione di messaggi tipizzati su coda FIFO memoria condivisa: allocata e associata al processo attraverso system call La segnalazione di azioni avviene attraverso segnali (signal): interrupt software semafori: una generalizzazione dei semafori classici Augusto Celentano Sistemi Operativi A - Parte III - 43 Augusto Celentano Sistemi Operativi A - Parte III - 44

12 La sincronizzazione in Windows 2000 La gestione della concorrenza tra processi (tra thread) si basa su una serie di oggetti di sincronizzazione Process Thread File Console input File change notification Mutex Semaphore Event Waitable timer Deadlock (1) Il deadlock (blocco critico) è una situazione di stallo tra più processi che nasce quando ogni processo aspetta che si verifichi un evento che solo un altro processo può causare (Tanenbaum, 2001) Augusto Celentano Sistemi Operativi A - Parte III - 45 Augusto Celentano Sistemi Operativi A - Parte III - 46 Deadlock (2) Perché si verifichi un deadlock occorrono quattro condizioni mutua esclusione: una risorsa può essere acquisita da un processo alla volta allocazione parziale (hold-and-wait): un processo richiede le risorse in più fasi assenza di pre-emption: non è possibile sottrarre d autorità una risorsa ad un processo attesa circolare: esiste una catena chiusa di processi ciascuno in attesa di una risorsa posseduta dal pros- simo processo della catena (Stallings, 2000) Deadlock (3) Una situazione di deadlock si presenta se e solo se la condizione di attesa circolare è irrisolvibile La condizione di attesa circolare è irrisolvibile se valgono le tre condizioni che esprimono le strategie di gestione delle risorse Le quattro condizioni insieme sono condizioni necessarie e sufficienti perché si verifichi una situazione di deadlock ma il verificarsi di un attesa circolare non è sempre deterministico Augusto Celentano Sistemi Operativi A - Parte III - 47 Augusto Celentano Sistemi Operativi A - Parte III - 48

13 Esempio: presenza di deadlock Esempio: assenza di deadlock (Stallings, 2000) (Stallings, 2000) Augusto Celentano Sistemi Operativi A - Parte III - 49 Augusto Celentano Sistemi Operativi A - Parte III - 50 Risoluzione dei deadlock La risoluzione del problema dei deadlock può essere affrontata in tre modi prevenzione: progettare il sistema in modo che non possano verificarsi deadlock basso utilizzo delle risorse controllo: evitare le operazioni che possono portare ad un deadlock assegnazione controllata delle risorse Prevenzione dei deadlock Il S.O. è progettato in modo da escludere a priori la possibilità di deadlock indirettamente: negando una delle tre condizioni sulla gestione delle risorse direttamente: prevenendo il formarsi di una catena circolare di attesa riconoscimento: intervenire a posteriori per rimuovere una situazione di deadlock verifica difficile Augusto Celentano Sistemi Operativi A - Parte III - 51 Augusto Celentano Sistemi Operativi A - Parte III - 52

14 Prevenzione indiretta dei deadlock (1) Mutua esclusione nella maggior parte dei casi non può essere evitata esempi: scrittura su un file, occupazione di memoria, utilizzo di periferiche Allocazione parziale (hold-and-wait) può essere evitata se un processo richiede tutte le risorse di cui ha bisogno con una sola operazione indivisibile. se non sono tutte disponibili il processo viene posto in attesa (allocazione globale delle risorse) utilizza male le risorse che vengono allocate anche quando non servono non tutte le risorse necessarie sono note in anticipo Prevenzione indiretta dei deadlock (2) Assenza di pre-emption può essere evitata (ogni risorsa può essere tolta d autorità) lo stato della risorsa deve essere salvato e successivamente ripristinato non è quindi applicabile a tutte le risorse ma solo a quelle che non hanno uno stato proprio utilizzabile con CPU, memoria non utilizzabile con file, periferiche Augusto Celentano Sistemi Operativi A - Parte III - 53 Augusto Celentano Sistemi Operativi A - Parte III - 54 Prevenzione diretta dei deadlock Allocazione gerarchica delle risorse le risorse sono ordinate in livelli un processo può richiedere le risorse di cui ha bisogno solo in ordine di livello crescente per acquisire una risorsa di livello inferiore deve rilasciare le risorse di livello superiore Con queste regole l attesa circolare non può verificarsi i processi P 0, P 1,, P n sono in una situazione di attesa circolare se e solo se P i è in attesa di una risorsa R i posseduta da P i+1 e P n è in attesa di una risorsa R n posseduta da P 0 Prevenzione dei deadlock: valutazione La prevenzione interviene sulla gestione delle risorse si impedisce una delle tre condizioni di gestione che possono rendere irrisolvibile l attesa circolare oppure si impedisce per principio l attesa circolare In ogni caso si ha una gestione non ottimale delle risorse e un rallentamento dei processi Augusto Celentano Sistemi Operativi A - Parte III - 55 Augusto Celentano Sistemi Operativi A - Parte III - 56

15 Controllo delle situazioni di deadlock Si ammettono le tre condizioni sulla gestione delle risorse ma si controlla che non venga mai raggiunta una situazione di deadlock consente una gestione migliore delle risorse rispetto alla prevenzione Si basa su due differenti approcci rifiuto di esecuzione:un processo non viene iniziato se le sue richieste di risorse possono portare a deadlock rifiuto di allocazione: un processo non riceve le risorse che chiede (incrementalmente) se la loro allocazione può portare a deadlock (algoritmo del banchiere) Problema: le risorse necessarie devono essere dichiarate in anticipo Augusto Celentano Sistemi Operativi A - Parte III - 57 Rifiuto di esecuzione (1) Un processo non viene iniziato se chiede(rà) più risorse di quelle disponibili C k,i = quantità di risorse di tipo i necessarie al processo k U i = quantità di risorse di tipo i non necessarie ad alcun processo (disponibili) un nuovo processo n viene iniziato solo se C n,i <= U i per tutti i tipi i di risorsa Non può verificarsi deadlock perché ci saranno sempre risorse libere in quantità sufficiente Augusto Celentano Sistemi Operativi A - Parte III - 58 Rifiuto di esecuzione (2) Non è una strategia ottima perché suppone che tutti i processi possano chiedere tutte le risorse nello stesso momento (caso peggiore) simile all allocazione globale, ma le risorse non sono allocate ma solo prenotate Una strategia migliore si basa sul controllo delle risorse nel momento in cui queste vengono effettivamente richieste Rifiuto di allocazione (algoritmo del banchiere) I processi sono simili a clienti che chiedono prestiti (risorse) ad una banca La banca non concede prestiti se non può soddisfare completamente le richieste di almeno un cliente, che poi restituirà il prestito In ogni istante lo stato del sistema è definito da risorse totali di tipo i, R i risorse richieste complessivamente dal processo k, C k,i risorse allocate al processo k, A k,i risorse richieste dal processo k per completare l esecuzione, N k,i = C k,i -A k,i risorse disponibili nel sistema, V i = R i - Σ k A k,i Augusto Celentano Sistemi Operativi A - Parte III - 59 Augusto Celentano Sistemi Operativi A - Parte III - 60

16 Algoritmo del banchiere (1) Una risorsa richiesta viene assegnata ad un processo se l assegnazione porta il sistema in uno stato sicuro, negata se porta il sistema in uno stato insicuro uno stato è sicuro se esiste una sequenza di esecuzione di processi P i P n in cui ogni processo può completare l esecuzione uno stato è insicuro se non esiste nessuna sequenza di esecuzione di processi che li completa tutti Algoritmo del banchiere (2) Inizializzazione tutti i processi sono in corso W(i) = V(i) per ogni tipo di risorsa i Esecuzione 1) cerca un processo k in corso tale per cui N(k,i) <= W(i) i se non esiste vai al punto 2) altrimenti il processo può terminare e restituire le risorse: imposta il processo k a terminato e W(i) = W(i) + A(k,i) i torna al punto 1 2)se tutti i processi sono terminati lo stato è sicuro altrimenti è non sicuro Augusto Celentano Sistemi Operativi A - Parte III - 61 Augusto Celentano Sistemi Operativi A - Parte III - 62 Algoritmo del banchiere (3) Per ogni richiesta Q(k,i) fatta dal processo k su risorse di tipo i l algoritmo determina se l assegnazione porta in uno stato sicuro determina i casi limite: deve essere Q(k,i) <= N(k,i) i, e Q(k,i) <= V(i) i simula l assegnazione delle risorse e calcola il nuovo stato del sistema: V(i) = V(i) - Q(k,i) i A(k,i) = A(k,i) + Q(k,i) i N(k,i) = N(k,i) - Q(k,i) i Se lo stato risultante è sicuro allora la richiesta viene soddisfatta, altrimenti no (il processo aspetta) Esempio (1) 3 tipi di risorse: R(1) = 9, R(2) = 3, R(3) = 6 4 processi nel seguente stato P1 P2 P3 P4 C(claimed) A(allocated) V(available) R1 R2 R3 R1 R2 R3 R1 R2 R Se P2 fa la richiesta Q = (1,0,1), può essere soddisfatta? Augusto Celentano Sistemi Operativi A - Parte III - 63 Augusto Celentano Sistemi Operativi A - Parte III - 64

17 Esempio (2) Lo stato risultante è il seguente P1 P2 P3 P4 C(claimed) A(allocated) V(available) R1 R2 R3 R1 R2 R3 R1 R2 R E uno stato sicuro i processi possono terminare nella sequenza P2, P1, P3, P4 la richiesta può essere soddisfatta Augusto Celentano Sistemi Operativi A - Parte III - 65 Esempio (3) Se la richiesta (1, 0, 1) fosse fatta da P1 lo stato risultante sarebbe il seguente P1 P2 P3 P4 C(claimed) A(allocated) V(available) R1 R2 R3 R1 R2 R3 R1 R2 R E uno stato non sicuro nessun processo può terminare perché ognuno ha bisogno di risorse di tipo 1 che non sono più disponibili la richiesta non può essere soddisfatta Augusto Celentano Sistemi Operativi A - Parte III - 66 Riconoscimento del deadlock Il riconoscimento di una situazione di deadlock si basa sugli stessi dati su cui si basa l algoritmo del banchiere se con l allocazione attuale delle risorse non c è una sequenza di terminazione dei processi in corso il sistema è in deadlock Il controllo può essere fatto ad ogni allocazione di risorse o periodicamente un controllo frequente rileva il deadlock appena si presenta ma consuma tempo di CPU Alcuni sistemi (Unix) ignorano del tutto il problema deadlock (algoritmo dello struzzo ) Strategie per la risoluzione del deadlock Terminazione forzata di tutti i processi in deadlock Ripristino dei processi in deadlock ad un precedente punto di checkpoint e loro riesecuzione il deadlock può presentarsi ancora Successivamente, terminazione dei processi in deadlock ad uno ad uno fino a risoluzione del deadlock Successivamente rilascio forzato delle risorse (preemption) finché il deadlock non scompare Augusto Celentano Sistemi Operativi A - Parte III - 67 Augusto Celentano Sistemi Operativi A - Parte III - 68