Esercitazione E9 Sincronizzazione

Transcript

1 Esercitazione E9 Sincronizzazione Sistemi Operativi (9 CFU), CdL Informatica, A. A. 2013/2014 Dipartimento di Scienze Fisiche, Informatiche e Matematiche Università di Modena e Reggio Emilia 1

2 Quote of the day (Meditate, gente, meditate...) 2

3 API GNU/LINUX 3

4 Sincronizzazione padre-figli (Chiamata di sistema wait()) Il processo padre può sincronizzarsi con l'andamento di uno dei processi figli. Si usa la chiamata di sistema wait(). wait() blocca il processo invocante (il padre) fino a che il processo figlio non termina. Quando il processo figlio termina l'esecuzione, ritorna un codice di uscita (exit status) al SO. Il kernel consegna tale codice di uscita alla chiamata wait() e risveglia il processo invocante (il padre). 4

5 wait(): chiamata tempestiva (Il padre invoca wait() prima che il figlio termini) Il processo padre invoca fork() ed esegue concorrentemente con il figlio. Il processo padre invoca la wait() tempestivamente, prima della terminazione del processo figlio. si blocca in attesa che un figlio termini. Ad un certo punto, il processo figlio termina la sua esecuzione. Solo in quel momento, il kernel risveglia il processo padre. File E9-scenari-wait_luc.pdf. 5

6 wait(): chiamata tardiva (Il padre invoca wait() dopo che il figlio è terminato) Il processo padre invoca fork() ed esegue concorrentemente con il figlio. Il processo figlio termina la sua esecuzione. Il processo padre invoca la wait() solo in questo momento. Non viene sospeso; la wait() ritorna subito. File E9-scenari-wait_luc.pdf. 6

7 wait(): chiamata mai effettuata (Il padre non invoca la wait()) Il processo padre invoca fork() ed esegue concorrentemente con il figlio. Il processo figlio termina la sua esecuzione. Il processo padre non invoca mai la wait(). Prosegue ininterrotto la sua traccia di esecuzione. File E9-scenari-wait_luc.pdf. 7

8 Sincronizzazione con processi figli (Chiamata di sistema wait()) La chiamata di sistema wait() sospende l'esecuzione del processo invocante fino a che almeno uno dei processi figli termina. Parametri in ingresso. Il puntatore ad una variabile intera utilizzata per memorizzare lo stato di uscita del processo. Valore di ritorno. In caso di successo: il PID del processo figlio terminato. In caso di errore: -1. Esempio d'uso: sorgente wait.c contenuto nell'archivio E9-esempi.tar.bz2. 8

9 Esercizi (5 min.) 1.Si provi ad eliminare il ritorno a capo nella prima printf() effettuata dal processo padre. Cosa succede e perché succede? 9

10 Soluzioni 1.Entrambe le stampe su STDOUT del padre vengono effettuate insieme, dopo l'esecuzione del figlio. Ciò è dovuto al fatto che la gestione degli stream di I/O è bufferizzata. 10

11 Sincronizzazione fra thread (Diversi meccanismi) La sincronizzazione fra thread può avvenire in maniera simile a quella fra processi. Il thread (o il processo) invocante si blocca fino a quando un thread specificato termina (pthread_join()). Si possono utilizzare anche meccanismi per l'accesso in mutua esclusione a variabili condivise. Uso di mutex (pthread_mutex_*()). Queste funzioni di libreria sono rese disponibili dalla libreria dei POSIX thread (la compilazione va effettuata con l'opzione -pthread). 11

12 Sincronizzazione fra thread (Funzione di libreria pthread_join()) La funzione di libreria pthread_join() sospende l'esecuzione del thread invocante fino a che un determinato thread termina. Parametri in ingresso. Un descrittore di thread. Un puntatore doppio allo stato di uscita del thread. Valore di ritorno. In caso di successo: 0. In caso di errore: un valore positivo. Esempio d'uso: sorgente pthread_join.c contenuto nell'archivio E9-esempi.tar.bz2. 12

13 (Non) sincronizzazione fra thread (Funzione di libreria pthread_detach()) Di default, un thread A è creato joinable. Se un thread B invoca la pthread_join(), si blocca fino a quando A non termina. Alle volte, si preferisce fare sì che un thread esegua in modo indipendente dagli altri. Se un thread B invoca la pthread_join(), ritorna immediatamente. A può eseguire per i fatti suoi, e B non può più aspettarlo. Si usa la funzione di libreria pthread_detach(). man 3 pthread_detach per tutti i dettagli. 13

14 Creazione di un mutex (Funzione di libreria pthread_mutex_init()) La funzione di libreria pthread_mutex_init() inizializza un mutex. Parametri in ingresso. Il puntatore ad una struttura di tipo pthread_mutex_t. Il puntatore ad una struttura pthreads_mutexattr_t rappresentante gli attributi del mutex, o NULL per quelli di default. Valore di ritorno: sempre 0. 14

15 Accesso in mutua esclusione (Funzione di libreria pthread_mutex_lock()) La funzione di libreria pthread_mutex_lock() ottiene accesso in mutua esclusione alla risorsa protetta da un pthread_mutex_t. Parametri in ingresso. Il puntatore ad una struttura di tipo pthread_mutex_t. Valore di ritorno. In caso di successo: 0. In caso di errore: un codice di errore (un numero positivo). 15

16 Rilascio della risorsa (Funzione di libreria pthread_mutex_unlock()) La funzione di libreria pthread_mutex_unlock() rilascia il lock su una risorsa condivisa protetta da un pthread_mutex_t. Parametri in ingresso. Il puntatore ad una struttura di tipo pthread_mutex_t. Valore di ritorno. In caso di successo: 0. In caso di errore: un codice di errore (un numero positivo). 16

17 Distruzione di un mutex (Funzione di libreria pthread_mutex_destroy()) La funzione di libreria pthread_mutex_destroy() distrugge un mutex. Parametri in ingresso. Il puntatore ad una struttura di tipo pthread_mutex_t. Valore di ritorno. In caso di successo: 0. In caso di errore: un codice di errore (un numero positivo). Esempio d'uso: sorgente pthread_mutex.c contenuto nell'archivio E9-esempi.tar.bz2. 17

18 Dopo aver imparato ad usare i mutex... (...bisogna imparare ad evitare i deadlock) Come si fa a capire quale porzione di codice introduce un deadlock? Punto di partenza: l'applicazione con il protocollo di locking sbagliato. Si carica l'applicazione con un debugger. Si esegue l'applicazione all'interno del debugger fino al deadlock. Si esamina lo stato dell'applicazione in condizioni di deadlock. Si identifica la causa del deadlock. Si rimuove la causa del deadlock. 18

19 Debugging di un eseguibile (Tramite debugger gdb) È necessario esaminare lo stato di un processo in deadlock. Si compili il programma con i simboli di debug e lo si esegua con un debugger (ad es., gdb). Il debugger gdb, ad esempio, può risalire ai punti di attesa dei vari thread o processi. Tali punti di attesa sono, con tutta probabilità, dovuti ai tentativi (falliti) di acquisizione di un lock. 19

20 Una applicazione di esempio (Su cui applicare la metodologia appena vista) Si consideri l'applicazione di esempio deadlock_abba_mutex.c contenuta nell'archivio E9-esempi.tar.bz2. Cosa fa tale applicazione? Un processo crea due thread oltre al principale li chiameremo Thread2 e Thread3. I due thread hanno bisogno entrambi di prendere due lock (implementati con mutex), locka e lockb. Tuttavia, l'ordine in cui i due thread prendono i lock è sbagliato. 20

21 L'ordine di locking errato (Deadlock ABBA) Thread2 prende locka. Thread3 prende lockb. Thread2 vorrebbe prendere lockb, ma è tenuto da Thread3. Thread3 vorrebbe prendere locka, ma è tenuto da Thread2. STALLO di entrambi i thread! Pattern di deadlock chiamato ABBA File E9-simulazione-ABBA_luc.pdf. 21

22 Esecuzione fino al deadlock (Passo passo) Si compili il programma con la tabella dei simboli di debug. gcc -g -pthread -o deadlock_abba_mutex deadlock_abba_mutex.c Si esegua l'applicazione dal debugger. gdb./deadlock_abba_mutex Si mandi in esecuzione il programma. run 22

23 Analisi backtrace: Thread 1 (Lo si può trascurare) Sono presenti tre thread: Thread 1, Thread 2 e Thread 3. Thread 1 sembra essere il programma principale. Nel momento in cui è stato interrotto, Thread 1 stava eseguendo main() pthread_join() Thread 1 aspetta due thread in deadlock fra loro; lui non partecipa al deadlock. Si può trascurarlo. 23

24 Analisi backtrace: Thread 2, Thread 3 (Sono in deadlock fra loro) Si osservino le backtrace di Thread 2 e Thread 3, che sono i due thread coinvolti nel deadlock. Si verifichi, grazie alla backtrace, dove la loro esecuzione si è fermata. Nella funzione do_work() del file deadlock_abba_mutex.c alla riga...? Si confronti tale indicazione con il codice sorgente dell'applicazione. In questo modo, si riesce a ricostruire l'ordine errato di accesso ai lock. 24

25 Esercizi (2 min.) 2.Per quale motivo il simbolo della funzione sulla quale i Thread 2 e 3 si sono bloccati (l'ultima invocata, insomma) non è disponibile? 25

26 Soluzioni 2.Il debugger non è riuscito a trovare il codice sorgente della libreria del C; di conseguenza, non ha modo di individuare il simbolo corretto. 26

27 Correzione del protocollo di lock (Rimuove il deadlock) In che modo è possibile correggere l'errore nel protocollo di locking? Si rifletta sul protocollo sbagliato. Entrambi i thread prendono, in modo idealmente contemporaneo, un lock... che è successivamente necessario all'altro thread! Il problema si può facilmente evitare facendo sì che entrambi seguano il medesimo ordine di lock. AABB e non ABBA. 27

28 Deadlock doppio lock (Più semplice rispetto all'abba) Un altro pattern di lock errato molto comune, che porta a deadlock, è quello del doppio lock. Un thread prende un lock, quindi cerca di riprenderlo; rimane all'infinito in attesa di se stesso. Spesso la causa del deadlock doppio lock è l'assenza dell'invocazione di una *_unlock() dopo una *_lock(). La soluzione è aggiungere l'invocazione della *_unlock() mancante. File E9-simulazione-doppio-lock_luc.pdf. 28