Corso di Sistemi Operativi

Транскрипт

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/

93 Lettori e scrittori: Variabili Semaphore mutex=1; Semaphore lettori=0, Semaphore scrittori=0; int let_sosp=0; int scr_sosp=0; int let_attivi =0; bool scr_attivi=0; Scrittore do { ric_scrittura(); // writing... fine_scrittura(); while (true) Lettore do { ric_lettura(); // writing... fine_lettura(); while (true) a.a. 2012/

94 Richiesta scrittura e fine lettura void richiesta_scrittura() { wait(mutex); if (lettori_attivi > 0 scrittore_attivo) { scr_sosp++; signal(mutex); wait(scrittori); scr_sosp ; void fine_lettura() { wait(mutex); let_attivi ; if (lettori_attivi == 0 && scrittori_attivo) signal(scrittori); else signal(mutex); scr_attivo = true; signal(mutex); a.a. 2012/

95 Richiesta lettura e fine scrittura void richiesta_lettura() { wait(mutex); if (scr_sosp > 0 scrittore_attivo) { let_sosp++; signal(mutex); wait(lettori); let_sosp ; let_attivi++; if (let_sospesi > 0) signal(lettori); else signal(mutex); void fine_scrittura() { wait(mutex); scrittore_attivo = false; if (let_sosp) signal(lettori); else signal(mutex); Attiva tutti i lettori, uno dopo l'altro a.a. 2012/

96 Il problema dei cinque filosofi Ogni bacchetta può essere rappresentata da un semaforo (inizializzati a 1): semaphore chopstick[5]; a.a. 2012/

97 Codice del i-esimo filosofo do { wait ( chopstick[i] ); wait ( chopstick[ (i + 1) % 5] ); // eat signal ( chopstick[i] ); signal (chopstick[ (i + 1) % 5] ); // think while (true); a.a. 2012/

98 Problema dei filosofi: Soluzione corretta process Philo[0] { while (true) { think chopstick[1].wait(); chopstick[0].wait(); eat chopstick[1].signal(); chopstick[0].signal(); process Philo[i] { /* i = */ while (true) { think chopstick[i].wait(); chopstick[(i+1)%5].wait(); eat chopstick[i].wait(); chopstick[(i+1)%5].wait(); a.a. 2012/

99 Filosofi: soluzioni alternative Altre possibili soluzioni sono i filosofi di indice pari sono mancini, gli altri destri in caso di collisione, un filosofo deve attendere che i due vicini abbiano terminato al più quattro filosofi possono sedersi a tavola (variabile contatore) le bacchette devono essere prese insieme (semafori su coppie di bacchhette) Cosa dire rispetto a starvation? a.a. 2012/

100 Linux: Kernel Syncronizaction La sincronizzazione è un aspetto di fondamentale importanza all'interno di ogni kernel di un SO I kernel UNIX sono rientranti (reentrant kernels): Più processi possono essere eseguiti in kernel mode contemporaneamente Questa feature implica l'utilizzazione di meccanismi di mutua esclusione (locking mechanims) Bisogna impedire che più processi in kernel mode agiscano conteporanemente su strutture dati condivise a.a. 2012/

101 Meccanismi di sincronizzazizone del kernel Il kernel di Linux prevede diversi meccanismi di sincronizzazione Disabilitazione della prelazione del kernel (kernel preemption disabling) Disabilitazione degli interrupt (interrupt disabling) Operazioni atomiche (atomic operations) Spin locks Semafori a.a. 2012/

102 Disabilitazione della prelazione del kernel Il kernel Linux è prelazionabile (preemptable Kernel): Un processo che esegue in modalità kernel non può essere arbitrariamente sospeso e interrotto con un altro processo È efficace su sistemi uniprocessore: non c'è accesso concorrente da parte del kernel Disable kernel preemption Critical section Enable kernel preemption NOTA La consistenza dei dati spetta direttamente al processo a.a. 2012/

103 Disabilitazione degli interrupt È realizzabile solo su sistemi monoprocessore Comunque se la regione critica è molto lunga la disabilitazione degli interrupt porta ad una drastica riduzione dell'utilizzazione delle periferiche (ES. tastiera, mouse, ecc.) a.a. 2012/

104 Operazioni atomiche Molte istruzioni assembly sono del tipo read-modify-write Prevedono cioè due accessi in memoria: Il primo per leggere il valore attualmente presente Il secondo per scrivere quello nuovo Molti SO prevedono appunto istruzioni atomiche, basate sul hardware. L'assembly x86 prevede il prefisso LOCK (lock byte 0xf0) per rendere atomico l'istruzione che segue Esempio d'uso: contatore condiviso (produttore/ consumatore) È definita dal tipo atomic_t a.a. 2012/

105 Spin locks Sono dei semafori busy wait: Se il lock è bloccato allora esso esegue un ciclo vuoto (spins) Sono utili in sistemi multiprocessori Nel kernel sono molto utili: molte risorse del kernel sono bloccate per pochissimo tempo (anche frazioni di un millisecondo) In questi casi la sospensione è più dispendiosa! ES: code di attesa struct wait_queue_head { spinlock_t lock; struct list_head task_list; a.a. 2012/

106 Read/write spin locks Rappresentano un ottimizzazione degli spin locks, aumentando il grado di concorrenza del kernel Distinguono tra le operazioni di lettura e quelle di scrittura Consentono accessi multipli in lettura e singoli in scrittura Le scritture sono consentite solo se non ci sono letture in corso a.a. 2012/

107 Semafori Per sistemi multiprocessori A differenza degli spin locks sospendono il processo che richiede un semaforo già bloccato Non possono essere usati da funzioni che non possono essere sospese (interrupt handler) Anche in questo caso esiste la versione Read/write a.a. 2012/

108 Monitor* (*)la parte senguente è riservata agli studenti della LM in Ing. Informatica a.a. 2012/

109 Semafori: Problemi signal(mutex); // critical section wait(mutex) wait(mutex); // critical section wait(mutex) NO MUTUA ESCLUSIONE! STALLO! Cosa succede se un programma omette wait(), signal() o entrambi? NOTA È difficile scoprire questi errori: le condizioni di errore non sono facilmente riproducibili! a.a. 2012/

110 I Monitor Un monitor è un modulo software costituito da: dati locali una sequenza di inizializzazione una o più "procedure" Le caratteristiche principali sono: i dati locali sono accessibili solo alle procedure del modulo stesso un processo entra in un monitor invocando una delle sue procedure solo un processo alla volta può essere all'interno del monitor; gli altri processi che invocano il monitor sono sospesi, in attesa che il monitor diventi disponibile a.a. 2012/

111 Schema di un Monitor a.a. 2012/

112 Monitor - Sintassi monitor name { variable declarations... type procedurename1(args...) {... variabili private del monitor procedure visibili all'esterno type procedurename2(args...) {... procedure private name(args...) {... inizializzazione a.a. 2012/2013

113 Monitor - Caratteristiche base Solo un processo alla volta può essere all'interno del monitor il monitor fornisce un semplice meccanismo di mutua esclusione strutture dati condivise possono essere messe all'interno del monitor È necessario un meccanismo di sincronizzazione per: sospendere i processi in attesa di qualche condizione far uscire i processi dalla mutua esclusione mentre sono in attesa permettergli di rientrare quando la condizione è verificata a.a. 2012/2013

114 Monitor - Meccanismi di sincronizzazione Dichiarazione di variabili di condizione (CV) condition c; Le operazioni definite sulle CV sono: c.wait() attende il verificarsi della condizione c.signal() segnala che la condizione è vera a.a. 2012/2013

115 Monitor - Politica signal urgent c.wait() viene rilasciata la mutua esclusione il processo che chiama c.wait() viene sospeso in una coda di attesa della condizione c c.signal() causa la riattivazione immediata di un processo (secondo una politica FIFO) il chiamante viene posto in attesa verrà riattivato quando il processo risvegliato avrà rilasciato la mutua esclusione se non ci sono processi in attesa sulla variabile c, allora la chiamata non avrà nessun effetto a.a. 2012/2013

116 Monitor - Rappresentazione intuitiva Urgent queue Coda di input Monitor Variabili di condizione enqueue: invocazione di procedure entry dequeue: il monitor è vuoto urgent queue è vuoto enqueue: c.wait() dequeue: c.signal() a.a. 2012/2013

117 Politiche di Signaling Signal urgent (SU) è la politica "classica" di signaling Ne esistono altre: SW - signal wait no urgent stack, il segnalante viene messo nella entry queue SR - signal and return dopo la signal si esce subito dal monitor SC - signal and continue la signal segnala solamente che un processo può continuare, il chiamante prosegue l'esecuzione quando lascia il monitor viene riattivato il processo segnalato a.a. 2012/2013

118 Signal all E possibile anche risvegliare tutti i processi sospesi sulla variabile condizione utilizzando la: signal_all È una variante della signal_and_continue. Tutti i processi risvegliati vengono messi nella entry_queue dalla quale, uno alla volta potranno rientrare nel monitor. a.a. 2012/2013

119 Condition vs semafori Quali sono le differenze tra semafori e condition? Wait: condition: è sempre bloccante Semafori: NO (se il semaforo ha valore positivo) Signal: Condition: non ha alcun effetto se nessun processo sta attendendo la condizione Semafori: "memorizza" il verificarsi degli eventi il processo risvegliato dalla signal viene eseguito per primo a.a. 2012/

120 Soluzione del problema dei filosofi con i monitor monitor DP { enum { THINKING, HUNGRY, EATING state[5] ; condition self[5]; void pickup (int i) { state[i] = HUNGRY; test(i); if (state[i]!= EATING) self[i].wait(); void putdown (int i) { state[i] = THINKING; // test left and right neighbors test((i + 4) % 5); test((i + 1) % 5); a.a. 2012/

121 Soluzione del problema dei filosofi con i monitor void test (int i) { if ((state[(i + 4) % 5]!= EATING) && (state[i] == HUNGRY) && (state[(i + 1) % 5]!= EATING) ) { state[i] = EATING ; self[i].signal() ; void init() { int i; for (i = 0; i < 5; i++) state[i] = THINKING; a.a. 2012/

122 L'i-esimo filosofo L'i-esimo filosofo invocherà le operazioni pickup() e pickdown(): DP DiningPhilosophers;... DiningPhilosophers.pickup(i); // EAT DiningPhilosophers.putdown(i); a.a. 2012/

123 Produttore/Consumatore tramite Monitor monitor Prod_Cons { // variabili Object[] buffer; condition okread, okwrite; int count, rear, front, size; // procedure Prod_Cons(int size); Object read(); void write(object val); a.a. 2012/2013

124 Consumatore Object Prod_Cons::read() { Object retval; if (count == 0) okread.wait(); retval = buffer[rear]; cont ; rear = (rear+1) % buffer.length; okwrite.signal(); return retval; a.a. 2012/2013

125 Produttore Prod_Cons::write(Object val) { if (count == buffer.length) okwrite.wait(); buffer[front] = val; count++; front = (front+1) % buffer.length; okread.signal(); a.a. 2012/2013

126 Monitor con i semafori: urgent wait È possibile implementare i monitor con i semafori: semaphore mutex; // (initially = 1) La variabile mutex assicura la mutua esclusione all'interno del monitor Oltre a mutex è necessario anche un altro semaforo, per sospendere i processi che effettuano una signal su una variabile condition interna al monitor: semaphore urgent; // (initially = 0) int u count = 0; a.a. 2012/

127 Monitor con i semafori: urgent wait Le procedure del monitor saranno del tipo: type Monitor_name::procedurename(args...) { wait(mutex); // body of F; if (u count > 0) signal(urgent) else signal(mutex);... In uscita bisogna controllare se ci sono altri processi (all'interno del monitor), sospesi sul semaforo urgent. In tal caso devono essere risvegliati. In caso contrario si rilascia il mutex di accesso al montior a.a. 2012/

128 semafori urgent wait: Variabili condition Per ogni variabile condition x sono variabili: semaphore x_sem; // (initially = 0) int x count = 0; necessarie due void wait(condition cond) { x count++; if (u count > 0) signal(urgent); else signal(mutex); wait(x_sem); x count ; return; void signal(condition cond) u count++; if (x count > 0) { u count++; signal(x_sem); wait(urgent); u count ; return; a.a. 2012/

129 Monitor con i semafori: signal and continue Le procedure del monitor saranno del tipo: type Monitor_name::procedurename(args...) { wait(mutex); // body of F; signal(mutex); a.a. 2012/

130 Monitor con i semafori: signal and continue Per ogni variabile condition x sono variabili: semaphore x_sem; // (initially = 0) int x count = 0; necessarie due void wait(condition cond) { x count++; signal(mutex); wait(x_sem); wait(mutex); return; void signal(condition cond) { if (x count > 0) { x count ; signal(x_sem); return; a.a. 2012/

131 Monitor con i semafori: signal and wait Le procedure del monitor saranno del tipo: type Monitor_name::procedurename(args...) { wait(mutex); // body of F; signal(mutex); a.a. 2012/

132 Monitor con i semafori: signal and wait Per ogni variabile condition x sono variabili: semaphore x_sem; // (initially = 0) int x count = 0; necessarie due void wait(condition cond) { x count++; signal(mutex); wait(x_sem); return; void wait(condition cond) { if (x count > 0) { x count ; signal(x_sem); wait(mutex); return; a.a. 2012/

133 Monitor con i semafori: signal and return Le procedure del monitor saranno del tipo: type Monitor_name::procedurename(args...) { wait(mutex); // body of F; Se la funzione NON contiene signal allora l'epilogo sarà signal(mutex) Altrimenti sarà signal(x) a.a. 2012/

134 Monitor con i semafori: signal and return Per ogni variabile condition x sono necessarie due variabili: semaphore x_sem; // (initially = 0) int x count = 0; void wait(condition cond) { x count++; signal(mutex); wait(x_sem); x count ; void signal(condition cond) { if (x count > 0) { signal(x_sem); signal(mutex); return; return; a.a. 2012/

135 Monitor: esempio In un ambiente multiprogrammato, il sistema operativo deve servire le richieste di processi che competono per l'accesso a dischi. Disco a testina mobile: la testina si sposta radialmente lungo N tracce [0,..N-1]: dalla traccia piu` esterna (0) verso l'interno (direzione SU) nella direzione opposta (GIU) L'algoritmo SCAN e` una possibile politica di scheduling delle richieste di accesso al disco, che ha come obiettivo la minimizzazione del numero dei cambiamenti di direzione del braccio del disco. a.a. 2012/

136 Algoritmo SCAN ogni richiesta e` caratterizzata da una traccia T, che individua la destinazione della testina, quando la richiesta verra` servita: se la testina si muove verso l interno (SU), verranno servite tutte le richieste con T raggiungibile in quella direzione (T>posizione corrente) se la testina si muove verso l esterno (GIU), verranno servite tutte le richieste con T raggiungibile in quella direzione (T<posizione corrente) le richieste sono servite secondo l ordine di vicinanza alla richiesta corrente. Quando nella direzione scelta non ci sono più richieste da servire, la direzione del braccio viene invertita ed il procedimento è ripetuto. a.a. 2012/

137 Algoritmo SCAN: Monitor Definiamo un monitor, il cui compito e` realizzare la politica di servizio mediante le due procedure entry: Richiesta(T): viene invocata dai processi per ottenere l'accesso al disco sulla traccia T se il disco è occupato, la richiesta del processo viene accodata in funzione dello stato corrente del disco (direzione del braccio e numero di traccia interessata) in una coda associata ad una direzione in modo da rispettare la politica di risveglio scelta. Rilascio: viene invocata dai processi per rilasciare il disco: se vi sono richieste in attesa sulla stessa direzione, verra` risvegliata la prima (la piu` vicina alla posizione corrente della testina); altrimenti, la direzione della testina verra` invertita e verra` risvegliato il primo processo in attesa nella nuova direzione. a.a. 2012/

138 Variabili Il monitor e` caratterizzato dalle seguenti variabili: occupato: indica se vi e` un processo che sta accedendo al disco; direzione: indica la direzione corrente della testina (SU, GIU) posizione: indica la destinazione corrente dir_su, dir_giu: condition associate alle due direzioni, sulle quali si sospenderanno i processi in attesa di servizio. a.a. 2012/

139 typedef int traccia; typedef enum{su,giudir; monitor disk_scan { traccia posizione=0; boolean occupato=false; dir direzione=su; condition dir_su,dir _GIU; void Richiesta(traccia dest); void Rilascio(); a.a. 2012/

140 void disk_scan::richiesta(traccia dest) { if (occupato==true) if ((direzione==su)&& (dest<posizione)) dir_giu.wait(dest); else dir_su.wait(n dest); occupato=true; posizione=dest; a.a. 2012/

141 void disk_scan::rilascio() { occupato=false; if (direzione==su) if (dir_su.queue) dir_su.signal; else { direzione=giu; dir_giu.signal; else if (dir_giu.queue) dir_giu.signal; else { direzione=su; dir_su.signal; a.a. 2012/