Corso di Sistemi Operativi

Transcript

1 Corso di Sistemi Operativi Sincronizzazione tra processi a.a. 2012/2013 Francesco Fontanella

2 Modello concorrente In un sistema operativo coesistono un gran numero di attività che vengono eseguite più o meno contemporaneamente È necessario un modello adeguato che renda possibile la coesistenza delle diverse attività Questo modello prende il nome di modello concorrente e si basa sul concetto (astratto) di processo a.a. 2012/2013 2

3 Finite progress assumption Il modello concorrente si basa sulla seguente assunzione (Finite progress assumption): a tutti i processi pronti è garantito di poter progredire in un tempo finito NOTA la velocità dei diversi processi non è nota a.a. 2012/2013 3

4 Concorrenza Negli S.O. riguarda la gestione di processi multipli: Multiprogramming più processi su un solo processore (parallelismo apparente) Multiprocessing Più processi su una macchina con processori multipli (parallelismo reale) Distributed processing più processi su un insieme di computer distribuiti e indipendenti (parallelismo reale) a.a. 2012/2013 4

5 Concorrenza Due programmi sono in esecuzione concorrente se vengono eseguiti in parallelo (con parallelismo reale o apparente) I principali problemi associati alla concorrenza sono: Comunicazione (IPC) Sincronizzazione a.a. 2012/2013 5

6 Concorrenza: esempi Applicazioni multiple la multiprogrammazione è stata inventata affinchè più processi indipendenti condividano il processore Applicazioni strutturate su processi estensione del principio di progettazione modulare; alcune applicazioni possono essere progettate come un insieme di processi o thread concorrenti Struttura del sistema operativo molte funzioni del sistema operativo possono essere implementate come un insieme di processi o thread a.a. 2012/2013 6

7 Multiprogramming vs Multiprocessing Multiprogramming (singolo processore fisico): processi multipli sono "alternati nel tempo" per dare l'impressione di avere un multiprocessore (interleaved execution) ad ogni istante, uno solo processo è in esecuzione Multiprocessing (due o più processori fisici) più processi vengono eseguiti simultaneamente su processori diversi (overlapped execution) a.a. 2012/2013 7

8 Programmazione concorrente: problemi L'accesso concorrente a risorse condivise può provocare incosistenza dei dati. Per preservare la consistenza sono necessari meccanismi che assicurino l'esecuzione ordinata dei processi cooperanti. a.a. 2012/2013 8

9 Concorrenza: esempio Si consideri il codice seguente: Codice C void modifica(int valore) { totale = totale + valore Codice assembly.text modifica: lw $t0, totale add $t0, $t0, $a0 sw $t0, totale jr $ra Supponiamo che: Esista un processo P1 che esegue modifica(+10) Esista un processo P2 che esegue modifica(-10) P1 e P2 siano in esecuzione concorrente totale sia una variabile condivisa tra i due processi, con valore iniziale 100 Alla fine, totale dovrebbe essere uguale a 100. Giusto? a.a. 2012/2013

10 Scenario 1: multiprogramming (corretto) P1 lw $t0, totale totale=100, $t0=100, $a0=10 P1 add $t0, $t0, $a0 totale=100, $t0=110, $a0=10 P1 sw $t0, totale totale=110, $t0=110, $a0=10 S.O. interrupt S.O. salvataggio P1 S.O. ripristino P2 totale=110, $t0=?, $a0= 10 P2 lw $t0, totale totale=110, $t0=110, $a0= 10 P2 add $t0, $t0, $a0 totale=110, $t0=100, $a0= 10 P2 sw $t0, totale totale=100, $t0=100, $a0= 10 a.a. 2012/2013

11 Scenario 2: multiprogramming (errato) P1 lw $t0, totale totale=100, $t0=100, $a0=10 S.O. interrupt S.O. salvataggio P1 S.O. ripristino P2 totale=100, $t0=?, $a0= 10 P2 lw $t0, totale totale=100, $t0=100, $a0= 10 P2 add $t0, $t0, $a0 totale=100, $t0=90, $a0= 10 P2 sw $t0, totale totale= 90, $t0=90, $a0= 10 S.O. interrupt S.O. salvataggio P2 S.O. ripristino P1 totale=90, $t0=100, $a0=10 P1 add $t0, $t0, $a0 totale= 90, $t0=110, $a0=10 P2 sw $t0, totale totale=110, $t0=110, $a0=10 a.a. 2012/2013

12 Scenario 3: multiprocessing (errato) I due processi vengono eseguiti simultaneamente da due processori distinti Processo P1 lw $t0, totale add $t0, $t0, $a0 sw $t0, totale Processo P2 lw $t0, totale add $t0, $t0, $a0 sw $t0, totale Nota i due processi hanno insiemi di registri distinti l'accesso alla memoria su totale non può essere simultaneo a.a. 2012/2013

13 Concorrenza: osservazioni Non vi è sostanziale differenza tra i problemi relativi a multiprogramming e multiprocessing Si assume la presenza di un "processore ideale" per ogni processo I problemi derivano dal fatto che: non è possibile predire gli istanti temporali in cui vengono eseguite le istruzioni (finite proggress assumption) i due processi accedono ad una o più risorse condivise a.a. 2012/2013

14 Sezione critica (Race condition) Un insieme di processi concorrenti presenta una sezione critica (race condition) se il risultato finale dipende dalla temporizzazione con cui i processi vengono eseguiti Nella programmazione concorrente divente quindi di fondamentale importanza individuare ed eliminare eventuali sezioni critiche a.a. 2012/2013

15 Sezione critica (Race condition) la correttezza di un programma concorrente non dipende (solo) dall'esattezza dei passi svolti da ogni singola componente del programma, ma anche dalle interazioni tra le varie possibili istanze Il debuging delle applicazioni concorrenti è molto difficile: Gli effetti negativi delle condizioni critiche potrebbero presentarsi in pochissimi casi, e pertanto sono difficili da individuare in fase di debug a.a. 2012/2013

16 Sezione Critica:Produttore/Consumatore Problema del produttore consumatore: I due processi condividono: un buffer, e una variabile contatore (incrementata dal consumatore e decrementata dal produttore) Produttore while (true) { while (count == BUFFER_SIZE) ; // do nothing buffer [in] = nextproduced; in = (in + 1) % BUFFER_SIZE; count++; while (true) { while (count == 0) ; // do nothing nextconsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; count--; Consumatore /* consume the item in nextconsumed a.a. 2012/

17 Programma con sezione critica do { in section critical section out section remainder section (not critical) while (true); a.a. 2012/

18 Proprietà di un programma Una proprietà di un programma concorrente è un attributo che rimane vero per ogni possibile esecuzione del programma stesso. Due tipi di proprietà: Safety: Il programma non esegue nessuna azione erronea ("nothing bad happens") Liveness: Il programma raggiunge sempre lo stato finale atteso ("something good eventually happens") a.a. 2012/2013

19 Proprietà dei programmi sequenziali Nei programmi sequenziali: le proprietà di safety esprimono la correttezza dello stato finale (il risultato è quello atteso) la principale proprietà di liveness è la terminazione a.a. 2012/2013

20 Programmi concorrenti: Safety I processi non devono "interferire" fra di loro nell'accesso alle risorse condivise ( non vale per i processi che cooperano tramite comunicazione) Può essere garantita per mezzo dei meccanismi di sincronizzazione. a.a. 2012/2013

21 Programmi concorrenti: liveness I meccanismi di sincronizzazione non devono prevenire l'avanzamento del programma Bisogna evitare di: Sospendere tutti i processi in attesa di eventi che possono essere generati da processi a loro volta sospesi (deadlock) un processo debba "attendere indefinitamente" prima di poter accedere ad una risorsa condivisa a.a. 2012/2013

22 Mutua esclusione (safety) l'accesso ad una risorsa è detto mutualmente esclusivo se, ad ogni istante, al più un processo può accedere a quella risorsa Esempi: due processi che accedono conteporaneamente ad una stampante due processi che comunicano per mezzo di un buffer condiviso a.a. 2012/2013

23 Deadlock (stallo) (liveness) la mutua esclusione può causare il blocco permanente dei processi Esempio: siano P 1 e P 2 due processi che devono accedere a R 1 e R 2 contemporaneamente, prima di poter terminare il programma supponiamo che il S.O. assegni R 1 a P 1, e R 2 a P 2 i due processi sono bloccati in attesa circolare P 1 e P 2 sono detti in deadlock a.a. 2012/2013

24 Starvation (inedia) (liveness) Esiste anche la possibilità che un processo non possa accedere ad un risorsa perché "sempre occupata" Esempio sia R una risorsa siano P 1, P 2, P 3 tre processi che accedono periodicamente a R supponiamo che P 1 e P 2 si alternino nell'uso della risorsa P 3 non può accedere alla risorsa, perché utilizzata in modo esclusivo da P 1 e P 2 P 3 è detto in starvation a.a. 2012/2013

25 Azioni atomiche Le azioni atomiche vengono compiute in modo indivisibile (o tutto o niente). La loro implementazione dipende dal tipo di parallelismo: Se è reale l'azione atomica non deve interferire con quelle di altri processi Se è apparente il context switch può avvenire solo prima o dopo l'azione a.a. 2012/2013

26 Azioni atomiche - Esempi Le singole istruzioni del linguaggio macchina sono atomiche Esempio: sw $a0, ($t0) parallelismo apparente: L'hardware delle CPU garantisce che gli interrupt vengano eseguiti prima o dopo un'istruzione, mai "durante" Parallelismo reale: se più istruzioni cercano di accedere conteporaneamente alla stessa cella di memoria (quella puntata da $t0), l'hardware del bus (arbitraggio) serializza l'accesso a.a. 2012/2013

27 Azioni atomiche - Controesempi In generale, sequenze di istruzioni in linguaggio macchina non sono azioni atomiche Esempio: lw $t0, ($a0) add $t0, $t0, $a1 sw $t0, ($a0) Attenzione: le singole istruzioni in linguaggio macchina sono atomiche le singole istruzioni in assembly possono non essere atomiche esistono le pseudoistruzioni! a.a. 2012/2013

28 Azioni atomiche in C In C l'atomiticità dipende da: processore compilatore Esempi a=0; /* int a */ questo statement è atomico; la variabile a viene definita come un intero di lunghezza "nativa" e inizializzata a 0 a=0; /* long long a */ questo statement non è atomico, in quanto si tratta di porre a zero una variabile a 64 bit; questo può richiedere più istruzioni a++; anche questo statement in generale non è atomico, ma dipende dalle istruzioni disponibili in linguaggio macchina a.a. 2012/2013

29 Azioni atomiche E nei compiti di concorrenza? Assumiamo che in ogni istante, vi possa essere al massimo un accesso alla memoria alla volta Questo significa che operazioni tipo: aggiornamento di una variabile incremento di una variabile valutazione di espressioni etc. non sono atomiche Operazioni tipo: assegnamento di un valore costante ad una variabile sono atomiche a.a. 2012/2013

30 Sezione critica: requisiti Esistono diverse soluzioni al problema della sezione critica Ogni possibile soluzione deve soddisfare tre requisiti fondamentali: Mutua esclusione Progresso Attesa limitata a.a. 2012/

31 Mutua esclusione il processo P è nella sua sezione critica nessun altro processo può essere eseguito nella sua sezione critica a.a. 2012/

32 Progresso nessun processo è nella sua sezione critica e più processi richiedono l'accesso alla sezione critica la scelta del prossimo processo che accederà alla sezione critica spetta ai processi in attesa e non può essere rinviata indefinitamente a.a. 2012/

33 Attesa limitata un processo P richiede l'accesso alla sua sezione critica, esiste un limite al numero di volte che si consente agli altri processi di accedere alla loro sezioni critiche, senza soddisfare la richiesta di P a.a. 2012/

34 Sezioni critiche: Possibili approcci Approcci software Le sezioni critiche sono gestite dai processi (o meglio dal programmatore) che accedono in maniera concorrente ad qualche risorsa problemi Possibili errori! costoso in termini di esecuzione (busy waiting) Approcci hardware utilizza istruzioni speciali del linguaggio macchina efficienti problemi Hardware dependent: poca portabilità a.a. 2012/2013

35 Sezioni critiche: Possibili approcci Altri approcci si basano sul supporto del S.O. o anche del linguaggio stesso La mutua esclusione è garantita appunto dal S.O. o dal linguaggio (e.g. Java) Esempi Semafori Monitor Message passing a.a. 2012/2013

36 La soluzione di Peterson È una soluzione SOFTWARE Poniamo di avere 2 processi Prevede la condivisione di due variabili: int turn; boolean flag[2]; La prima variabile indica quale processo può entrare nella sezione critica Il vettore flag indica se l'i-esimo processo è pronto ad entrare nella sua sezione critica a.a. 2012/

37 Accesso alla sezione critica per il P i do { flag[i] = true; turn = j; while (flag[j] && turn == j) ; Busy waiting critical section flag[i] = false; remainder section while (true); NOTA La soluzione di Peterson rispetta i tre requisiti di: mutua esclusione progresso attesa limitata a.a. 2012/

38 Sincronizzazione hardware Molti sistemi forniscono dei sistemi hardware per l'esecuzione di sezione critiche. Sistemi monoprocessore: Disabilitazione degli interrupts durante la modifica delle variabili condivise. Sistemi multiprocessore: La disabilitazione degli interrupt è troppo inefficiente; Vengono implementate particolari istruzioni dette atomiche: queste singole istruzioni non sono soggette ad interrrupt. a.a. 2012/

39 Sezione critica per mezzo di lock remainder section acquire lock critical section release lock remainder section a.a. 2012/

40 L'istruzione TESTandSET boolean TestAndSet (boolean *target) { boolean rv = *target; *target = true; return rv; a.a. 2012/

41 Realizzazione hardware di TESTandSET L'istruzione TESTandSET viene realizzata per mezzo di una specifica istruzione del processore: TSL Register, Lock Quest'istruzione realizza una duplice azione: Carica il contenuto della variabile Lock in Register Scrive nella variabile Lock un valore non nullo Queste due operazioni sono garantite come indivisibili dal hardware Questa indivisibilità è garantita chiudendo il bus di accesso alla memoria a.a. 2012/

42 Uso di TESTandSET remainder section while ( TestAndSet (&lock )) ; // do nothing critical section lock = false; remainder section NOTA non soddisfa il requisito dell'attesa limitata a.a. 2012/

43 L'istruzione SWAP void swap (boolean *a, boolean *b) { boolean temp = *a; *a = *b; *b = temp: a.a. 2012/

44 Realizzazione hardware di SWAP L'istruzione SWAP è realizzata per mezzo dell'istruzione del processore: XCHG Register, lock Quest'istruzione scambia il contenuto del registro e della variabile lock in maniera atomica (bus bloccato). Tutte le CPU INTEL a partire dalla x86 implementano ques'istruzione per fornire sincronizzazione hardware a.a. 2012/

45 Mutua esclusione con swap remainder section key = true; while ( key == true) swap (&lock, &key ); critical section lock = false; remainder section NOTA non soddisfa il requisito dell'attesa limitata a.a. 2012/

46 Attesa limitata e mutua esclusione do { waiting[i] = true; key = true; while (waiting[i] && key) key = TestAndSet(&lock); waiting[i] = false; critical section j = (i + 1) % n; while ((j!= i) &&!waiting[j]) j = (j + 1) % n; if (j == i) lock = false; else waiting[j] = false; remainder section while (true); a.a. 2012/

47 INTEL: Il prefisso LOCK L'instruction set delle CPU INTEL più moderne, prevedono l'utilizzazione del prefisso LOCK che rende atomiche le istruzioni che lo seguono. Può essere usato con tutte le istruzioni di accesso alla memoria Il suo effetto è quello di inviare un lock signal al bus di memoria ES: lock sw $a0, ($t0) a.a. 2012/

48 Semafori a.a. 2012/

49 Semafori Sono un paradigma di sincronizzazione Viene implementato per mezzo di segnali che due o più processi possono scambiarsi al fine di cooperare Un processo può essere bloccato in un specifico punto finché non riceve un segnale da un altro processo a.a. 2012/

50 Semafori E' un tipo di dato astratto. Può essere visto come una variabile intera. Sono definite due operazioni signal(): è invocata per inviare un segnale, che indica il verificarsi di un evento o il rilascio di una risorsa wait() : è invocata per attendere il segnale (ovvero, per attendere un evento o il rilascio di una risorsa) a.a. 2012/

51 Semafori Ad un semaforo S si può accedere solo tramite operazioni atomiche wait(s): esegue due azioni: attende che il valore del semaforo sia positivo Ne decrementa il valore signal(s): incrementa il valore del semaforo S a.a. 2012/

52 Definizione di semaforo class Semaphore { private int val; Semaphore(int init) { val = init; void wait() { while (val<=0) ; // no op. val ; NOTA Questa a fianco è una definizione Che definisce la semantica delle operazioni wait e signal L' atomicità di queste operazioni può essere garantita con l'istruzione xchg void signal() { val++; a.a. 2012/

53 Semafori binari e contatore Semafori binari: possono assumere due soli valori e garantiscono la mutua esclusione (sono detti lock mutex). Semafori contatore: possono assumere valori > 1. sono usati per condividere una risorsa presente in un numero massimo di esemplari. a.a. 2012/

54 Semafori e mutua esclusione I semafori possono essere utilizzati per la mutua esclusione tra N diversi processi: Semaphore mutex = 1; // initialized to 1 do { mutex.wait(); critical section mutex.signal(); remainder section while (true); a.a. 2012/

55 Semafori per la condivisione di risorse Uso dei semafori; Semaphore s=x; do { s.wait(); critical Section Se x vale 1 si ottiene la mutua esclusione Se x > 1 si ottiene l'accesso controllato ad una risorsa presente in quantità x s.signal(); // remainder section while (true); a.a. 2012/

56 Semafori per la sincronizzazione Poniamo di avere due processi concorrenti P1 e P2, che eseguono rispettivamente le istruzioni S1 e S2: vogliamo che venga eseguita prima S1 e poi S2. Soluzione i processi possono condividere un semaforo sync: S1; P1 sync.signal(); sync.wait(); S2; P2 DOMANDA: a quanto deve essere inizializzato il valore della variabile sync? a.a. 2012/

57 Implementazione dei semafori La precedente definizione di semaforo prevedeva la cosiddetta attesa attiva (busy waiting): wait (S) { while S <= 0 ; // no-op S--; Impegna la CPU a vuoto! a.a. 2012/

58 Soluzione al problema del busy waiting La chiamata wait() provoca il blocco del processo P che l'ha invocata, se il semaforo S è non positivo: (P è rimosso dalla coda dei processi pronti è inserito nella lista dei processi in attesa di S Il processo P viene riattivato dopo l'esecuzione di una chiamata signal(). A tale scopo è necessario aggiungere alla classe Semaphore vista in precedenza una lista dei processi in attesa: Class Semaphore { int val; struct task_struct *list; semaphore; Può essere una coda FIFO a.a. 2012/

59 La nuova classe Semaphore class Semaphore { private int val; private struct task_struct *p_list; Semaphore(int init) { val = init; void wait(); void signal(); a.a. 2012/

60 Semafori senza busy waiting Semaphore::wait() { val ; if (val < 0) { add me to S >p_list; block(); Rimuove il chiamante dalla lista dei processi pronti Semaphore::signal() { val++; if (val <= 0) { remove the process P from S >list; wakeup(p); NOTA block() e wakeup() sono chiamate di sistema Reinserisce il chiamante nella lista dei processi pronti a.a. 2012/

61 Semafori senza busy waiting L'implementazione deve garantire che le operazioni signal() e wait()non siano eseguite conteporaneamente sullo stesso semaforo. Dal punto di vista pratico: I sistemi senza busy waiting sono convenienti solo se sono previste sezioni critiche molto lunghe (> di qualche sec) In tutti gli altri casi il busy waiting non crea problemi. a.a. 2012/

62 Situazioni di stallo Poniamo di avere due semafori S e Q condivisi dai processi P 0 e P 1 : P 0 P 1 wait (S); wait (Q); wait (Q); wait (S); signal (S); signal (Q); signal (Q); signal (S); Questa situazione è detta stallo (deadlock): Due o più processi sono in attesa di un evento che può essere provocato solo da uno dei processi in attesa a.a. 2012/

63 Attesa indefinita Una situazione fortemente connessa alle situazioni di stallo e quella dell'attesa indefinita (starvation): Un processo viene inserito in una coda d'attesa di un semaforo e mai rimosso Questa situazione si potrebbe presentare, ad esempio, nel caso in cui la coda di un semaforo sia di tipo LIFO a.a. 2012/

64 Inversione di Priorità Si verifica quando processi ad elevata priorità devono accedere a dati utilizzati anche da processi a priorità più bassa. Poniamo di avere 3 processi L,M e H, con priorità L<M<H: H richiede l'accesso alla risorsa R bloccata da L M diventa eseguibile (ready) con prelazione su L Risultato: M influenza il tempo di attesa di H, anche se ha priorità minore! Domanda: quale potrebbe una possibile soluzione a questo problema? a.a. 2012/

65 Esempio di mutua esclusione Poniamo di avere un parcheggio che può accogliere al più MAX auto. Le auto in arrivo: se c'è ancora posto entrano e ne occupano uno. se il parcheggio è pieno l'auto vanno via PROGRAMMA Scrivere un programma in C, che utilizzando la libreria pthread, regoli gli accessi al parcheggio. Ogni auto è rappresentata da un thread distinto. Mentre il parcheggio è rappresentato da una variabile condivisa. Se un thread trova posto aggiorna lo stato del parcheggio, altrimenti termina. Le auto (threads) parcheggiano per un tempo casuale e poi vanno via (il thread termina). a.a. 2012/

66 Esempio di mutua esclusione Poniamo di avere un parcheggio che può accogliere al più MAX auto. Le auto in arrivo: se c'è ancora posto entrano e ne occupano uno. se il parcheggio è pieno l'auto vanno via PROGRAMMA Scrivere un programma in C, che utilizzando la libreria pthread, regoli gli accessi al parcheggio. Ogni auto è rappresentata da un thread distinto. Mentre il parcheggio è rappresentato da una variabile condivisa. Se un thread trova posto aggiorna lo stato del parcheggio, altrimenti termina. Le auto (threads) parcheggiano per un tempo casuale e poi vanno via (il thread termina). a.a. 2012/

67 Mutua esclusione in Pthread La libreria pthread consente la mutua esclusione (MUtual EXclusion, MUTEX) fra due o più thread. È definito il tipo pthread_mutex_t È un semaforo binario Un mutex ha due possibili stati: Locked Unlocked Un solo thread può bloccare (lock) un mutex Se un altro thread tenta di bloccare un mutex viene sospeso finche quel mutex non viene rilasciato (unlocked) a.a. 2012/

68 Pthread mutex: funzioni int pthread_mutex_init(pthread_mutex_t *m, const pthread_mutexattr_t *m_attr) Inizializza il mutex puntato da m con gli attributi specificati da m_attr. Se m_attr vale NULL allora si usano quelli di default int pthread_mutex_lock(pthread_mutex_t *m) Blocca il mutex puntato da m Se m è già bloccato da un altro thread allora il thread chiamante viene sospeso a.a. 2012/

69 Pthread mutex: funzioni int pthread_mutex_trylock(pthread_mutex_t *mutex) Come la precedente tranne che il thread non viene sospeso se il mutex è già bloccato int pthread_mutex_unlock(pthread_mutex_t *m) Sblocca il mutex puntato da m Si assume che il mutex sia effettivamente bloccato e appartenga al chiamante a.a. 2012/

70 Pthread mutex: possibili problemi Cosa succede se un thread esegue pthread_mutex_lock(&m)... pthread_mutex_lock(&m) Cosa succede se un thread diverso da quello che lo possiede esegue pthread_mutex_unlock(&m) a.a. 2012/

71 Tipi di mutex normal: Non vengono effettuati controlli Le situazioni precedenti provocano problemi Error checking: Le situazioni precedenti vengono gestite restituendo degli errori al processo chiamante a.a. 2012/

72 Il thread auto pthread_mutex_t M; int in=0; void *thread_auto(void *arg) /*codice auto*/ { int id, t; id=*((int *)arg); srand((int)pthread_self()); Sezione critica pthread_mutex_lock(&m); if (in < CAPIENZA) // entrata { in++; printf("auto n %d parcheggiata ci sono %d auto nel parcheggio\n", id, in); pthread_mutex_unlock(&m); else { // Non ha trovato posto: termina pthread_mutex_unlock(&m); pthread_exit(); t = rand() % MAX_TIME; //durata parcheggio sleep(t); Continua.. a.a. 2012/

73 Il thread auto Sezione critica pthread_mutex_lock(&m); in ; printf("auto %d uscita ci sono %d auto nel parcheggio\n", id, in); pthread_mutex_unlock(&m); return t; a.a. 2012/

74 Il main main (int argc, char *argv[]) { pthread_t T[MAX]; pthread_mutex_init (&M, NULL); int i; for (i=0; i<max; i++) /* Creazione thread */ pthread_create (&T[i], NULL, thread_auto, (void *)&i); for (i=0; i < MAX; i++) { pthread_join(t[i], (void *)&A[i]); if (A[i]> 0) printf("il figlio %d e` rimasto in sosta %d secondi\n", i, A[i]); else printf("il figlio %d non e` entrato \n", i); return 0; a.a. 2012/

75 Semafori: Esempi Gestione di un pool di risorse equivalenti Produttore/consumatore Lettori/scrittori Cinque filosofi a.a. 2012/

76 Semafori: pool di risorse equivalenti Si può operare su una qualsiasi risorsa del pool purché libera. Necessità di un gestore che memorizzi lo stato delle risorse. Per operare su una delle risorse è necessario chiederne l allocazione al gestore. Il gestore assegna una risorsa libera (se esiste). È possibile operare sulla risorsa assegnata senza preoccuparsi della mutua esclusione. Al termine dell'operazione la risorsa deve essere restituita al gestore. a.a. 2012/

77 pool di risorse equivalenti: Soluzione 1 La struct risorsa: #define NUM_RISORSE 10 struct struct_risorsa { semaphore mutex = 1; /*semaforo di mutua esclusione*/ int risorse = N; /* #risorse disponibili. */ boolean libera[n]; /*indicatori di risorsa libera*/ ; void init(struct_risorsa) { int i; /*inizializzazione*/ for(i=0; i < N; i++) libera[i]=true; a.a. 2012/

78 int richiesta(struct_risorsa &r) { int i=0; wait(r.mutex); while(r.risorse == 0) signal(r.mutex); wait(r.mutex); while(!r.libera[i++]) ; r.libera[i]=false; signal(r.mutex); Busy waiting DOMANDA Funziona? Se SÌ, perche? return i; void rilascio(struct_risorsa &r, int i) { wait(r.mutex); r.libera[i] = true; r.n++; signal(r.mutex); a.a. 2012/

79 pool di risorse equivalenti: Soluzione 2 La struct risorsa: #define NUM_RISORSE 10 struct struct_risorsa { semaphore mutex = 1; /*semaforo di mutua esclusione*/ semaphore risorse = N; /*semaforo risorsa. */ boolean libera[n]; /*indicatori di risorsa libera*/ ; void init(struct_risorsa) { int i; /*inizializzazione*/ for(i=0; i < N; i++) libera[i]=true; a.a. 2012/

80 int richiesta(struct_risorsa &r) { int i=0; wait(r.risorse); wait(r.mutex); NO busy waiting while(!r.libera[i++]) ; r.libera[i]=false; signal(r.mutex); return i; void rilascio(struct_risorsa &r, int i) { wait(r.mutex); r.libero[i] = true; signal(r.mutex); signal(r.risorse); a.a. 2012/

81 Problema Produttore/Consumatore Due processi: Produttore: inserisce item in un buffer (circolare) Consumatore: estrae item Buffer circolare out in in out a.a. 2012/

82 void producer(item buffer[], int &in, int out) item tmp; while (true) { /* si produce un item*/.. DOMANDA Quali sono le sezione critiche? /* si aspetta che ci sia posto nel buffer */ while (( (in + 1) % BUFFER_SIZE ) == out) ; buffer[in] = item; in = (in + 1) % BUFFER SIZE; a.a. 2012/

83 void consumer(item buffer[], int in, int &out) { item tmp while (true) { while (in == out) ; // la coda è vuota: attesa // si estrae l'item tmp = buffer[out]; out = (out + 1) % BUFFER SIZE; DOMANDA Quali sono le sezione critiche? /* si consuma l'item*/.. a.a. 2012/

84 Produttore/Consumatore con semafori Possiamo usare un semaforo in mutua esclusione. Come? Cosa deve garantire il semaforo? Quali sono le variabili alle quali bisogna garantire l'accesso esclusivo? a.a. 2012/

85 semaphore mutex; void producer(item buffer[], int &in, int out) { Semaforo binario item tmp; while (true) { /* si produce un item*/.. /* si aspetta che ci sia posto nel buffer */ wait(mutex); while (( (in + 1) % BUFFER_SIZE ) == out){ signal(mutex); wait(mutex); buffer[in] = item; wait(mutex); in = (in + 1) % BUFFER SIZE; signal(mutex); a.a. 2012/

86 semaphore mutex; void consumer(item buffer[], int in, int &out) { item tmp while (true) { wait(mutex); while (in == out) // la coda è vuota: attesa signal(mutex); wait(mutex); // si estrae l'item tmp = buffer[out]; wait(mutex); out = (out + 1) % BUFFER SIZE; signal(mutex); /* si consuma l'item*/.. a.a. 2012/

87 Produttore/Consumatore con semafori Problema della soluzione precedente: Attesa busy waiting Possiamo eliminare l'attesa busy waiting con dei semafori? Quali sono le condizioni di busy waiting: Buffer vuoto Buffer pieno a.a. 2012/

88 Produttore/Consumatore con semafori Tutto il codice può essere semplificato utilizzando tre diversi semafori: empty (inizializzato a BUFFER_SIZE) full (inizializzato a 0) mutex (inizializzato a 1) while (true) { wait(empty); Produttore while (true) { wait(full); Consumatore // add an item // remove an item... wait(mutex); count++; signal(mutex) signal(full). wait(mutex) count ; signal(mutex) signal(empty) a.a. 2012/

89 Problema dei lettori e scrittori Descrizione un database è condiviso tra un certo numero di processi esistono due tipi di processi Lettori:accedono al database in lettura Scrittori: accedono al database per aggiornarne il contenuto Proprietà L'accesso degli scrittori deve avvenire in mutua esclusione; nessun altro lettore o scrittore può accedere al database se nessuno scrittore sta accedendo al database, un numero arbitrario di lettori può accedere al database in lettura a.a. 2012/

90 Problemi dei lettori e scrittori: soluzioni Quali sono le strutture dati necessarie? Di quante variabili e semafori abbiamo bisogno? Come deve essere fatto il processo scrittore? Di cosa deve tenere conto? Come deve essere fatto il processo lettore? a.a. 2012/

91 Lettori e Scrittori con Semafori Sono necessarie le seguenti strutture dati: semaphore mutex = 1, wrt = 1; int readcount = 0; Lettore do { wait(wrt); // writing... signal(wrt); while (true) Scrittore do { wait(mutex) ; readcount++ ; if (readcount == 1) wait(wrt) ; signal(mutex) // reading... wait (mutex) ; readcount ; if (readcount == 0) signal(wrt) ; signal(mutex) ; while (true); a.a. 2012/

92 Lettori e Scrittori con Semafori: Problemi La soluzione precedente presenta un problema di starvation, possibile sia per i lettori che per gli scrittori Come è possibile risolvere questo problema? Come deve essere modificato il codice? In quali parti? Di cosa bisogna tenere conto? a.a. 2012/