Laboratorio Sistemi Operativi

Transcript

1 Laboratorio Sistemi Operativi Concorrenza Dr. Giulio Pellitta Università di Bologna 11 aprile 2013

2 esecuzione concorrente due programmi si dicono in esecuzione concorrente se vengono eseguiti in parallelo; con parallelismo reale (multiprocessing o distributed processing) o apparente (multiprogramming); stesse problematiche (ipotizziamo quindi che ci sia un processore ideale per ogni processo) derivanti dalla presenza di risorse condivise tra più processi (non è possibile predire la velocità relativa dei processi). concorrenza è l insieme di notazioni per descrivere l esecuzione concorrente di due o più programmi; è l insieme di tecniche per risolvere i problemi associati all esecuzione concorrente, quali comunicazione e sincronizzazione.

3 operazioni atomiche Un istruzione/operazione si dice atomica se è indivisibile, ovvero se nessun altra istruzione può cominciare prima che sia finita (ovvero non può esserci interleaving). Ad esempio sono atomiche: le chiamate (o meglio solo il loro effetto, cioé la stampa) ai metodi print/println (es. System.out.println(verylongstring)); la maggior parte delle operazioni (es. lettura, assegnazione, confronto) sulla maggior parte dei tipi di dato primitivi (es. int, float,... ). sezione critica Una sezione critica è un frammento di codice che accede ad una risorsa condivisa (struttura dati o dispositivo) a cui non deve accedere in modo concorrente più di un thread. Qualche meccanismo di sincronizzazione è necessario all entrata e all uscita della sezione critica per assicurarne l uso esclusivo, per esempio un semaforo.

4 semaforo strumento generale di sincronizzazione usabile tramite due operazioni atomiche P() e V (). ci sono k permessi per l uso di una risorsa condivisa; quando un processo usa la risorsa si decrementano i permessi residui (si può usare la risorsa solo se ci sono ancora permessi); quando un processo finisce di usare la risorsa si aumentano i permessi disponibili. P() //critical zone V() I semafori sono strumenti di basso livello, quindi scomodi da usare (facile commettere errori).

5 Più complicato con istruzioni che alterano il flusso di esecuzione. Esempio 1 P() //begin of critical zone if(condition){ return(whatever); } //possibly an else block //end of critical zone V()

6 Esempio 2 P() //begin of critical zone //some code that may or may not throw an exception //end of critical zone V() A differenza del caso precedente aggiungere semplicemente V() quà e là (o simili) non risolve. Necessario assicurarsi che l istruzione V() venga eseguita che l eccezione sia sollevata o meno. Come?

7 metodi synchronized Dichiarando un metodo d istanza synchronized si impedisce che, mentre esso viene invocato da un thread su un istanza, altri thread possano invocare metodi synchronized sulla medesima istanza: dichiarare un metodo d istanza synchronized non protegge eventuali campi statici da accessi concorrenti. Dichiarando un metodo di classe synchronized si impedisce che, mentre esso viene invocato da un thread, altri thread possano invocare metodi synchronized della medesima classe: metodi di classe e di istanza synchronized possono alternarsi. Metodi non synchronized si possono intervallare con metodi synchronized.

8 blocchi synchronized Meccanismo di sincronizzazione che ha effetto su un blocco di codice e non su un metodo intero. Migliore efficienza rispetto ai metodi synchronized: basta mettere nel blocco synchronized solo la sezione critica e non tutto il codice del metodo; permette di consentire l accesso concorrente a campi diversi di una medesima istanza. Utile per sincronizzare rispetto a istanze di classi diverse da quella dove viene definito il blocco synchronized e per regolare l accesso ad una risorsa usata da istanze di classi diverse.

9 Qualche spunto di riflessione Se un operazione su una risorsa condivisa è atomica, è necessario utilizzare synchronized? Perché? Se più thread possono accedere ad un instanza di una data classe, com è utile impostare i modificatori di accesso ai campi di quella classe? Perché? Cosa succederebbe se si usassero blocchi/metodi synchronized al posto dei semafori negli esempi 1 e 2? Perché? Se manipoliamo una collezione tramite un iteratore, il fatto che non venga sollevata una ConcurrentModificationException garantisce che non ci siano accessi concorrenti?