I Thread. I Thread. Se creiamo un nuovo processo con la fork, questo erediterà dal padre

Transcript

1 I Thread 1 Ad un generico processo, sono associati i seguenti dati e le seguenti informazioni: codice del programma in esecuzione un area di memoria contenente le strutture dati dichiarate nel programma in esecuzione file aperti stack (per le chiamate di procedure e funzioni) contenuto dei registri della CPU I Thread 2 Se creiamo un nuovo processo con la fork, questo erediterà dal padre il codice, ma questo potrà essere sostituito da nuovo codice, mediante la system call execl una copia delle strutture dati una copia della User File Table 1

2 I Thread 3 Consideriamo due processi che devono lavorare sugli stessi dati. Come possono fare, se ogni processo ha la propria area dati (ossia, gli spazi di indirizzamento sono separati)? i dati possono essere scambiati mediante messaggi o tenuti in memoria condivisa i dati possono essere tenuti in un file che viene acceduto a turno dai due processi. Non sarebbe comodo poter avere processi che possano automaticamente lavorare sugli stessi dati, senza usare meccanismi espliciti di condivisione/comunicazione? I Thread 4 Ad esempio, in un editor di testo: un processo gestisce l input e i comandi di formattazione dell utente un altro processo esegue il controllo automatico di errore I due processi dovrebbero lavorare sullo stesso testo La copia corrente del testo è mantenuta in MP, ma come fanno i due processi a condividere la stessa copia, se ogni processo ha un diverso spazio di indirizzamento? 2

3 I Thread 5 Il context switch tra processi richiede molto lavoro al SO: oltre a cambiare il valore dei vari registri, deve spostarsi dalle aree dati e di codice del processo uscente, a quelle del processo entrante. Se dati e codice di quest ultimo erano stati swappati in memoria secondaria, occorre prima riportarli in memoria primaria. Se due (o più) processi potessero condividere dati e codice, il context switch fra di loro sarebbe molto più veloce Per soddisfare questo tipo di esigenza è nato il concetto di thread I Thread 6 Un normale processo è contraddistinto da un unico Thread (filo) di computazione: la sequenza di istruzioni eseguite (che ovviamente può cambiare da un esecuzione all altra, se cambiano, ad esempio, i dati di input). codice dati file registri stack thread 3

4 I Thread 7 Un processo Multi-Thread è fatto di più thread, detti peer thread. Un insieme dei peer thread è detto task. I Thread 8 Ad ogni thread è associato in modo esclusivo il suo stato della computazione, fatto da: valore del program counter e degli altri registri della CPU uno stack Ma un thread condivide con i suoi peer thread: il codice in esecuzione i dati i file aperti 4

5 I Thread 9 I context switch avviene anche tra ognuno dei peer thread che formano task, in modo che tutti possano portare avanti la computazione Ma il context switch fra peer thread richiede il salvataggio e il ripristino solo dei registri della CPU e dello stack (che sono diversi per ogni thread) Codice, dati e file aperti sono gli stessi per tutti, e non devono essere cambiati: IL CONTEXT SWITCH TRA PEER THREAD E MOLTO PIU VELOCE I Thread 10 Il context switch tra processi è molto più oneroso per il SO del context switch tra peer thread, perché nel primo caso sono coinvolte più informazioni da cambiare. Per questa ragione, i normali processi (quelli che abbiamo imparato ad usare in unix fino ad ora) sono spesso chiamati: heavy-weight process (HWP) Mentre per un singolo thread è usato spesso il termine: light-weight process (LWP) 5

6 I Thread 11 Ma come si fa a distinguere tra i thread di un task (in modo da far fare a ciascuno una cosa diversa), se questi condividono lo stesso codice? con delle opportune system call, che all interno del codice permettono di creare i thread necessari, e specificano per ciascun thread quale pezzo di codice deve eseguire quel thread Naturalmente, altre system call permetteranno ai thread di sincronizzarsi fra di loro (in modo simile a come i processi possono sincronizzarsi fra di loro usando i semafori). POSIX Threads (pthreads) 12 Portable Operating System Interface Threads: lo standard POSIX per la programmazione con threads Vari sistemi operativi e versioni di sistemi operativi supportano i POSIX Threads (pthread d ora in poi), anche Solaris. (Poi spesso aggiungono qualcosa in più...) I Pthreads, essendo uno standard riconosciuto, sono portabili da un sistema ad un altro. Riferimenti: Butenhof, Programming with POSIX threads, Addison-Wesley. Multithreaded Programming Guide, SUN microsystem. (ne trovate una copia in formato pdf sulle pagine del corso di laboratorio). 6

7 POSIX Threads (pthreads) 13 per usare i pthreads in un programma C, è necessario includere la libreria: <pthread.h> Per compilare un programma che usa i pthreads occorre linkare la libreria libpthread, usando l opzione -lpthread: $> gcc prog.c -o prog -lpthread Creazione di un thread 14 Un thread ha vari attributi, che possono essere cambiati, ad esempio: la sua priorità (che influenza la frequenza con cui verrà schedulato) la dimensione del suo stack (che specifica la quantità massima di argomenti che gli si possono passare, la profondità delle chiamate ricorsive, e così via) Noi però vedremo sempre thread con gli attributi di default 7

8 Creazione di un thread 15 Gli attributi di un thread sono contenuti in un oggetto di tipo pthread_attr_t la syscall: int pthread_attr_init(pthread_attr_t *attr); inizializza con i valori di default un contenitore di attributi *attr, che potrà poi essere passato alla system call che crea un nuovo thread. Creazione di un thread 16 Un nuovo thread viene creato con la syscall intera pthread_create che accetta quattro argomenti: una varibile di tipo pthread_t, che conterrà l identificativo del thread che viene creato un oggetto *attr, che conterrà gli attributi da dare al thread creato. Se si vuole creare un thread con attributi di default, si può anche semplicemente usare NULL un puntatore alla routine che contiene il codice che dovrà essere eseguito dal thread un puntatore all eventuale argomento che si vuole passare alla routine stessa 8

9 Terminazione di un thread 17 Un thread termina quanto finisce il codice della routine specificata all atto della creazione del thread stesso, oppure quando, nel codice della routine, chiama la syscall di terminazione: void pthread_exit(void *value_ptr); Quando termina, il thread restituisce il valore di return specificato nella routine, oppure, se chiama la pthread_exit, il valore passato a questa syscall come argomento. Sincronizzazione fra thread 18 Un thread può sospendersi, in attesa della terminazione di un altro thread chiamando la syscall: int pthread_join(pthread_t thread, void **value_ptr); identificativo del thread di cui si attende la terminazione. Naturalmente deve essere un thread appartenente allo stesso task. valore restituito dal thread che termina 9

10 il primo esempio: t1.c 19 #include <pthread.h> #include <stdio.h> funzione che contiene il codice di un peer thread void *tbody(void *arg) { int j; printf(" ciao sono un thread, mi hanno appena creato\n"); *(int *)arg = 10; sleep(2) /* faccio aspettare un pò il mio creatore, poi termino */ pthread_exit((int *)50); /* oppure return ((int *)50); */ } main(int argc, char **argv) { int i; pthread_t mythread; void *result; printf( sono il primo thread, ora ne creo un altro \n"); pthread_create(&mythread, NULL, tbody, (void *) &i); printf( ora aspetto la terminazione del thread che ho creato \n"); pthread_join(mythread, &result); printf("il thread creato ha assegnato %d ad i\n",i); printf("il thread ha restituito %d \n",result); } 20 10

11 il primo esempio: t1.c 21 provate a stampare mythread come intero. Che valore ha? E se create altri thread (mythread1, mythread2,...) che valore viene assegnato alle rispettive variabili? Provate anche ad usare la funzione che restituisce l id di un thread: pthread_t thread_id thread_id = pthread_self(); // id del thread chiamante il thread main ha generato un secondo thread tbody. Poi main si è messo in attesa della terminazione del thread creato (con pthread_join), ed è terminato lui stesso. Ma che differenza c è rispetto ad usare fork e wait (eventualmente con una execl)? condivisione dello spazio logico 22 I due thread condividono lo stesso spazio di indirizzamento, e quindi vedono le stesse variabili: se uno dei due modifica una variabile, la modifica è vista anche dall altro thread. Nel codice di t1, il main passa al thread tbody il puntatore alla variabile i dichiarata nel main. il thread tbody modifica la variabile, e questa modifica è vista da main. Nel caso dei processi tradizionali, una cosa simile è ottenibile solo usando esplicitamente un segmento di memoria condivisa. 11

12 condivisione dello spazio logico 23 Ma i thread di un task possono condividere variabili in maniera ancora più semplice, usando variabili globali. #include <pthread.h> #include <stdio.h> int global_var = 5; void *tbody(void *arg) { printf(" ciao sono un thread, ora modifico una var globale\n"); global_var = 27; *(int *)arg = 10; pthread_exit((int *)50); /* oppure return ((int *)50); */ } main(int argc, char **argv) { pthread_t mythread; void *result; pthread_create(&mythread, NULL, tbody, (void *) &i); printf( ora aspetto la terminazione del thread che ho creato \n"); pthread_join(mythread, &result); printf( ora global_var vale: %d \n",global_var); } tuttavia un thread può anche avere variabili proprie, viste solo dal thread stesso usando la classe di variabili thread_specific_data, che però noi non vedremo 24 12

13 Sincronizzazione fra thread 25 Diversi strumenti sono disponibili per sincronizzare fra loro i thread di un task, fra questi anche i semafori. In realtà i semafori non fanno parte dell ultima versione dello standard POSIX, ma della precedente. Tuttavia sono normalmente disponibili in tutte le versioni correnti dei pthread. I pthread mettono anche a disposizione meccanismi di sincronizzazione strutturati, quali le variabili condizionali, che però noi non vedremo. Semafori nei thread 26 per usare i semafori nei thread occorre includere: #include <semaphore.h> un semaforo si dichiara semplicemente con: sem_t mysemaphore e si inizializza con: sem_init(&mysemaphore, 0, val); dove il secondo argomento, se vale 0, significa che il semforo può essere usato solo dai thread appartenenti al processo che lo ha creato, e val è il valore iniziale da assegnare al semaforo. 13

14 Semafori nei thread 27 le due operazioni fondamentali sui semafori sono: sem_wait(&mysemaphore); (che è ovviamente l equivalente della operazione di wait/down/p che abbiamo visto a teoria) sem_post(&mysemaphore); (che è l equivalente della operazione di signal/up/v che abbiamo visto a teoria) #include <pthread.h> #include <stdio.h> #include <semaphore.h> 28 char glob_var[100]; /* variabile condivisa dai thread */ sem_t mutex; /* semaforo usato per la mutua esclusione su glob_var */ void *thread1(void *arg) { int i; for(i = 0; i < 5; i++) { sleep(random_time); sem_wait(&mutex); printf("mi hanno scritto: %s\n",glob_var); sprintf(glob_var,"ho ASPETTATO %d SECONDI\n",ran); sem_post(&mutex); } pthread_exit(null); /* oppure return(null); */ } sezione critica 14

15 void *thread2(void *arg) { int i; for(i = 0; i < 5; i++){ sleep(random_time); sem_wait(&mutex); printf("they wrote me: %s\n",glob_var); sezione critica sprintf(glob_var,"i WAITED %d SECONDS\n",ran); sem_post(&mutex); } pthread_exit(null); /* oppure return(null); */ } int main(int argc, char *argv[]) { int i; void *result; pthread_t t1,t2; sem_init(&mutex,0,1); /* inizializzazione del semaforo */ pthread_create(&t1, NULL, thread1, (void *) &i); pthread_create(&t2, NULL, thread2, (void *) &i); pthread_join(t1, &result); pthread_join(t2, &result);} 29 Scheduling dei thread 30 Come viene distribuito il tempo di CPU fra in vari peer thread all interno di un task, e tra i thread appartenenti a task diversi? Lo standard POSIX non specifica nulla a riguardo, e diversi (realizzazioni di) sistemi operativi possono a tal proposito compiere scelte implementative differenti. Uno stesso sistema operativo, può anche permettere all utente di specificare la politica di scheduling preferita per le proprie applicazioni che utilizzino i thread. 15

16 Scheduling: Thread a livello utente 31 Il SO non sa dell esistenza dei threads. Si dice che i thread esistono solo a livello utente. Il context switch da un peer thread all altro (all interno quindi dello stesso task) avviene mediante opportune funzioni di libreria chiamate all interno del codice dei thread stessi. Quando un thread sta per fermarsi, specifica prima quale peer thread deve proseguire la computazione Scheduling: Thread a livello utente 32 Il SO vede un task fatto di più thread come un normale processo, e gli assegna la CPU secondo il criterio di scheduling adottato per l intero sistema (ad esempio, RR). All interno del task, il tempo di CPU è suddiviso tra i vari peer thread a seconda del codice che eseguono. Se il codice di un thread è scritto male, e il thread si blocca senza farne partire un altro, tutto il tempo di CPU assegnato a quel task (e quindi a tutti i peer thread) viene sprecato 16

17 Scheduling: Thread a livello kernel 33 Il SO deve mantere delle strutture dati per gestire sia i normali processi che tutti i peer thread di un task Quando un thread si blocca volontariamente, o termina il suo quanto di tempo, è il SO che assegna la CPU: a un altro thread dello stesso task a un altro thread di un altro task a un altro processo normale Quindi il SO gestisce ogni singolo thread secondo il modello time-sharing Scheduling dei thread 34 Come si fa a sapere qual è il tipo di scheduling (di default) adottato da un certo sistema operativo che supporta i thread? Possiamo scrivere un semplice programma fatto da due thread che utilizzano una variabile condivisa myvar: il primo thread, thread-1 esegue delle operazioni CPU bound non specificate (chiamiamole CPU-OP) e poi modifica il valore di myvar e termina. Il secondo thread, thread-2, creato dal primo, stampa myvar e termina 17

18 Scheduling dei thread 35 Si possono quindi verificare due casi: se lo scheduling è a livello utente, allora thread-2 ottiene la CPU solo quando thread-1 la abbandona, e quindi il valore di myvar stampato sarà quello dovuto alla modifica operata da thread-1 prima di terminare. se lo scheduling è a livello kernel: 1) se CPU-OP dura più del quanto di tempo, la CPU potrà essere assegnata a thread-2 prima della terminazione di thread-1, e il valore di myvar stampato sarà quello assegnatogli inizialmente. Se 2) CPU-OP dura meno del quanto di tempo, il valore stampato sarà quello assegnato da thread-1. Scheduling dei thread 36 #include <pthread.h> #include <stdio.h> int flag=0; void *tbody(void *arg) { printf("flag = %d \n",flag); pthread_exit(null); } int main(int argc, char *argv[]) { int c,h; pthread_t t; void *status; if (argc!= 2) exit(1); 18

19 Scheduling dei thread 37 c=atoi(argv[1]); pthread_create(&t, NULL, tbody, NULL); for (h=0;h<c;h++); /* usa la CPU per del tempo, a seconda del valore dell'argomento 2 e della velocita' del processore */ flag = 1; pthread_join(t, &status); } ora basta lanciare il programma con diversi valori in input (10, 100, 1000) e vedere se valore di myvar stampato in output rimane lo stesso o cambia. user-level thread 38 VANTAGGI Tempo di context switch (fra thread di uno stesso processo) molto basso SVANTAGGI È difficile evitare che quando un thread ha bisogno di eseguire una system call bloccante, non vengano bloccati anche gli altri thread nello stesso processo Puo' essere implementato al di sopra di qualsiasi sistema operativo Non potrà mai esserci piu' di un thread running per processo anche se il sistema possiede molte CPU 19

20 kernel-level thread 39 VANTAGGI In un sistema con molte CPU e possibile avere piu' di un thread running per processo Il sistema e' sempre in grado di schedulare i thread pronti ad eseguire anche se uno o piu' altri thread nello stesso task sono bloccati in attesa di un evento. SVANTAGGI Il tempo di context switch fra thread di uno stesso processo, anche se meno costoso di un context switch fra processi diversi, e' comunque costoso perche' richiede il passaggio a modalita' kernel Il SO deve predisporre strutture dati per tutti i thread: questo pone limitazioni sul numero massimo di thread che possono essere attivati all'interno di un processo e complessivamente nel sistema Vantaggi nell uso dei thread 40 Efficienza: in Solaris, creare un LWP richiede circa 30 volte meno tempo che creare un HWP. Il context switch tra peer thread richiede 5 volte meno tempo del context switch tra processi Condivisione di dati e risorse: più thread possono lavorare su dati condivisi in maniera efficiente (ma devono sincronizzarsi in maniera adeguata) Uso di architetture con più CPU: i thread sono naturalmente adatti per lavorare in parallelo su più CPU che condividono la stessa MP 20