Sistemi Operativi. Lez. 13: primitive per la concorrenza monitor e messaggi

Transcript

1 Sistemi Operativi Lez. 13: primitive per la concorrenza monitor e messaggi

2 Osservazioni I semafori sono strumenti particolarmente potenti poiché consentono di risolvere ogni problema di sincronizzazione tra processi, tuttavia La programmazione della concorrenza con i semafori non è facile P e V, sparpagliate nel codice problema del corretto ordine di esecuzione di P e V l uso di P e V in ordine errato può portare a deadlock o a violazione della mutua esclusione Proposte soluzioni alternative a livello di linguaggio di programmazione Monitor: primitiva di sincronizzazione di alto livello 2

3 I monitor Costrutto di un linguaggio di programmazione d alto livello che 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 Primitive per la sincronizzazione tra processi che usano il monitor Un monitor: protegge i dati da accessi poco strutturati Garantisce che i dati condivisi siano acceduti solo attraverso interfacce ben definite 3

4 I Monitor: semantica 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 4

5 Esempio Monitor account {! double balance;!! }! double addebito(amount) {! balance = balance amount;! return balance; }!! double accredito(amount) {! balance = balance + amount;! return balance;}!! 5

6 Variabili Condition Le variabili condition sono un meccanismo introdotto con i monitor per sospendere i thread in attesa della verifica di particolari Le operazioni definite sulle variabili condition sono: Wait il processo che la effettua rilascia il lock sul monitor, e si mette in attesa di essere risvegliato da una successiva Signal sulla stessa variabile (questo significa che per ogni variabile condition deve essere implementata una coda) Signal risveglia un processo in attesa Broadcast risveglia tutti i processi in attesa Nota: le variabili condition non sono oggetti booleani: if (condition_variable) then non ha alcun senso if (num_resources == 0) then wait(condition_variable) invece è corretto 6

7 Esempio I processi produttori e consumatori eseguono le procedure del monitor, senza preoccuparsi della mutua esclusione La mutua esclusione è implicita nell uso del costrutto monitor La sezione critica è tutta raccolta nel monitor Più semplice da controllare 7

8 Prod - Cons 8

9 Variabili Condition vs. Semafori I semafori possono essere usati in qualunque punto del codice, la variabili condizione solo all interno del monitor La wait() è sempre bloccante, mentre la dow() può non esserlo La signal() sblocca un processo, se ve n è qualcuno in attesa, altrimenti va a vuoto; la Up() se non ci sono processi da sbloccare incrementa il valore del semaforo 9

10 Signal() Semantica Quando un thread A effettua una signal(), può risvegliare un thread B che verrà a sua volta a trovarsi all interno del monitor, poiché è proprio all interno del monitor che si è sospeso A questo punto però il principio della mutua esclusione all interno del monitor viene meno 10

11 Signal() semantica Esistono due diverse soluzioni al suddetto problema: Monitor di Hoare: il processo A viene sospeso e il controllo ceduto a B (per il quale si instaura una sorta di priorità di anzianità); l esecuzione di A ripresa in tempi successivi Monitor Mesa: il processo A continua la sua esecuzione, e B sarà eseguito quando il monitor si libererà (a questo punto però l evento precedentemente segnalato potrebbe non essere più vero!!!) 11

12 Variabili Condizione Le variabili condizione possono essere usate anche al di fuori dei monitor e possono essere trovate in diverse librerie di supporto alla programmazione concorrente In questi casi sono usate per introdurre dei meccanismi per sincronizzare tra di loro diversi thread sulla base del verificarsi o meno di opportune condizioni 12

13 SCAMBIO MESSAGGI 13

14 Premessa I semafori e i monitor sono i principali costrutti presenti nei linguaggi di programmazione concorrente Si tratta di meccanismi che richiedono la presenza di memoria condivisa e di un sistema centralizzato che provveda alla gestione delle rispettive code Storicamente accanto a questi meccanismi si sono sviluppati altri meccanismi di comunicazione tra processi che non richiedevano la presenza di entità centralizzate, più adeguati quindi alla comunicazione tra entità loosely coupled Questi meccanismi sono basati sulla comunicazione invece che sulla condivisione La sincronizzazione tra processi avviene consentendo ai processi stessi di comunicare 14

15 Il modello Nel paradigma message-passing thread e processi interagiscono tra di loro inviando e ricevendo messaggi Le entità concorrenti non hanno quindi bisogno di shared memory e quindi per questa categoria di applicazioni non si pone il problema della mutua esclusione Processi e thread possono essere fisicamente localizzati su computer diversi, collegati tra loro da una rete di comunicazione Questo non esclude di usare il message passing anche tra processi all interno di uno stesso sistema 15

16 Il modello Nel message passing esistono due primitive fondamentali di comunicazione send e receive Se due processi vogliono comunicare devono per prima cosa definire un meccanismo per specificare a chi vogliono inviare un messaggio e da chi vogliono riceverlo: Comunicazione diretta Comunicazione indiretta Tra due processi comunicanti il sistema crea almeno un canale di comunicazione, cioè una coda FIFO di messaggi, che può essere one-way o two-way 16

17 Comunicazione diretta I processi devono conoscere l identità dell interlocutore ed esprimerla esplicitamente: send (p, message)/receive (q, message) dove p e q sono identificativi di un processo In questo caso il SO provvede a stabilire un canale di comunicazione tra ogni coppia di processi che vuole comunicare, il link è solitamente two-way Svantaggi: modularità e portabilità del codice fortemente limitata 17

18 Comunicazione indiretta I messaggi sono inviati e ricevuti su opportune strutture dati chiamate mailbox o porte Ogni mailbox è univocamente identificata all interno del sistema Processi possono comunicare tra loro solo se condividono mailbox In questo caso le primitive di comunicazione diventano: send (mailbox, message)/receive (mailbox, message) 18

19 Comunicazione indiretta Operazioni Crea/distruggi una nuova mailbox Send/receive Canale di comunicazione La comunicazione tra processi è possibile solo se questi condividono una mailbox Può essere stabilito un canale di comunicazione condiviso tra più processi Una coppia di processi può condividere più canali di comunicazione 19

20 Comunicazione indiretta Condivisione di mailbox p1, p2, p3 condividono la mailbox A p1 invia un messaggio? Chi riceve? Possibili soluzioni: Evitare di stabilire canali di comunicazione condivisi Stabilire una politica di ricezione che consente ad un solo processo alla volta di ricevere Conentire la sistema di scegliere il ricevente, che sarà poi comunicato al mittente 20

21 Sincronizzazione Lo scambio messaggio può essere sia bloccante che non bloccante Bloccante o sincrono Send bloccante: il sender si blocca finché il destinatario non ha ricevuto il messaggio Receive bloccante: il destinatario si blocca finchè il messaggio non è disponibile 21

22 Non bloccante o Asincrona Send non bloccante, il mittente invia un messaggio dopodiché continua la sua elaborazione Receive non bloccante, il ricevente accede al canale e recupera un messaggio o null 22

23 Buffering Il canale di comunicazione può essere realizzato eseguendo una delle seguenti opzioni: Capacità nulla: il sender deve attendere il receiver (rendezvous) Capacità finita: in uno schema asincrono il mittente dovrà bloccarsi sul canale pieno Capacità infinita: in uno schema asincrono il sender non aspetta mai 23

24 Rendezvous Meccanismo di scambio messaggio sincrono che comporta la completa eliminazione del buffering Se send viene effettuata prima di receive, il processo che ha eseguito la send si blocca in attesa che il destinatario effettui la receive Lo stesso avviene in caso di receive anticipata Sender/receiver obbligati ad un esecuzione di tipo lockstep 24

25 Sincrono Vantaggi Consumo di memoria limitato a causa dell uso di buffer limita4(buffer space) Maggiore controllo sul canale di comunicazione: ogni thread può avere al più un messaggio non processato su ogni canale Svantaggi Concorrenza rido@a: quando due thread devono comunicare, almeno uno dei due si blocca Possibilità di deadlock 25

26 Prod-Cons 26

27 Prod-Cons 27