Gestione dei processi. Marco Bonola Lezione tratta da

Transcript

1 Gestione dei processi Marco Bonola Lezione tratta da

2 ARCHITETTURA Una delle caratteristiche di linux è che qualunque processo può a sua volta generarne altri, detti processi figli (child process) la generazione di un processo è un'operazione separata rispetto al lancio di un programma ogni processo è sempre stato generato da un altro, che viene chiamato processo padre (parent process) una sola eccezione: dato che ci deve essere un punto di partenza esiste un processo speciale (che normalmente è /sbin/init), che viene lanciato dal kernel alla conclusione della fase di avvio; essendo questo il primo processo lanciato dal sistema ha sempre il pid uguale a 1 e non è figlio di nessun altro processo

3 ARCHITETTURA Dato che tutti i processi attivi nel sistema sono comunque generati da init o da uno dei suoi figli1 si possono classificare i processi con la relazione padre/figlio in un'organizzazione gerarchica ad albero

4 UNA PANORAMICA SULLE FUNZIONI FONDAMENTALI In un sistema unix-like i processi vengono sempre creati da altri processi tramite la funzione fork; il nuovo processo (che viene chiamato figlio) creato dalla fork è una copia identica del processo processo originale (detto padre), ma ha un nuovo pid e viene eseguito in maniera indipendente) Se si vuole che il processo padre si fermi fino alla conclusione del processo figlio questo deve essere specificato subito dopo la fork chiamando la funzione wait o la funzione waitpid Quando un processo ha concluso il suo compito o ha incontrato un errore non risolvibile esso può essere terminato con la funzione exit normalmente si genera un secondo processo per affidargli l'esecuzione di un compito specifico (ad esempio gestire una connessione dopo che questa è stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per quest'ultimo caso si usa la seconda funzione fondamentale per programmazione coi processi che è la exec

5 PROCESS ID Ogni processo viene identificato dal sistema da un numero identificativo univoco, il process ID o pid Il pid viene assegnato in forma progressiva4 ogni volta che un nuovo processo viene creato, fino ad un limite che, essendo il pid un numero positivo memorizzato in un intero a 16 bit, arriva ad un massimo di Tutti i processi inoltre memorizzano anche il pid del genitore da cui sono stati creati, questo viene chiamato in genere ppid (da parent process ID). Questi due identificativi possono essere ottenuti usando le due funzioni getpid e getppid

6 GETPID E GETPPID #include <sys/types.h> #include <unistd.h> pid_t getpid(void) Restituisce il pid del processo corrente. pid_t getppid(void) Restituisce il pid del padre del processo corrente. Entrambe le funzioni non riportano condizioni di errore.

7 LA FUNZIONE FORK #include <sys/types.h> #include <unistd.h> pid_t fork(void) Crea un nuovo processo. In caso di successo restituisce il pid del figlio al padre e zero al figlio; ritorna -1 al padre (senza creare il figlio) in caso di errore; errno può assumere i valori: EAGAIN non ci sono risorse sufficienti per creare un altro processo (per allocare la tabella delle pagine e le strutture del task) o si è esaurito il numero di processi disponibili ENOMEM non è stato possibile allocare la memoria per le strutture necessarie al kernel per creare il nuovo processo.

8 LA FUNZIONE FORK Riveste un ruolo centrale tutte le volte che si devono scrivere programmi che usano il multitasking Dopo il successo dell'esecuzione di una fork sia il processo padre che il processo figlio continuano ad essere eseguiti normalmente a partire dall'istruzione successiva alla fork Il processo figlio è però una copia del padre, e riceve una copia dei segmenti di testo, stack e dati ed esegue esattamente lo stesso codice del padre la memoria è copiata, non condivisa, pertanto padre e figlio vedono variabili diverse La differenza che si ha nei due processi è che nel processo padre il valore di ritorno della funzione fork è il pid del processo figlio, mentre nel figlio è zero un processo infatti può avere più figli, ed il valore di ritorno di fork è l'unico modo che gli permette di identificare quello appena creato al contrario un figlio ha sempre un solo padre, per cui si usa il valore nullo, che non è il pid di nessun processo

9 ESEMPIO

10 LA FUNZIONE FORK Normalmente la chiamata a fork può fallire solo per due ragioni, o ci sono già troppi processi nel sistema (il che di solito è sintomo che qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite sul numero totale di processi permessi all'utente L'uso di fork avviene secondo due modalità principali la prima è quella in cui all'interno di un programma si creano processi figli cui viene affidata l'esecuzione di una certa sezione di codice, mentre il processo padre ne esegue un'altra. È il caso tipico dei programmi server in cui il padre riceve ed accetta le richieste da parte dei programmi client, per ciascuna delle quali pone in esecuzione un figlio che è incaricato di fornire il servizio. La seconda modalità è quella in cui il processo vuole eseguire un altro programma; questo è ad esempio il caso della shell. In questo caso il processo crea un figlio la cui unica operazione è quella di fare una exec subito dopo la fork.

11 LA FUNZIONE FORK Non si può dire quale processo fra il padre ed il figlio venga eseguito per primo In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di scheduling usato dal kernel, dalla particolare situazione in cui si trova la macchina al momento della chiamata, risultando del tutto impredicibile Non si può fare nessuna assunzione sulla sequenza di esecuzione delle istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno essere messi in esecuzione. Se è necessaria una qualche forma di precedenza occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il rischio di incorrere nelle cosiddette race condition Essendo i segmenti di memoria utilizzati dai singoli processi completamente separati, le modifiche delle variabili nei processi figli sono visibili solo a loro (ogni processo vede solo la propria copia della memoria), e non hanno alcun effetto sul valore che le stesse variabili hanno nel processo padre (ed in eventuali altri processi figli che eseguano lo stesso codice)

12 LA FUNZIONE FORK la lista dettagliata delle proprietà che padre e figlio hanno in comune dopo l'esecuzione di una fork è la seguente: i file aperti e gli eventuali flag di close-on-exec impostati Gli identificatori per il controllo di accesso: l'user-id reale, il group-id reale, l'user-id effettivo, il group-id effettivo ed i group-id supplementari gli identificatori per il controllo di sessione: il process group-id e il session id ed il terminale di controllo la directory di lavoro e la directory radice la maschera dei permessi di creazione la maschera dei segnali bloccati (vedi sez ) e le azioni installate i segmenti di memoria condivisa agganciati al processo i limiti sulle risorse le variabili di ambiente le differenze fra padre e figlio dopo la fork invece sono: il valore di ritorno di fork il pid (process id) il ppid (parent process id), quello del figlio viene impostato al pid del padre i valori dei tempi di esecuzione della struttura tms che nel figlio sono posti a zero. i lock sui file, che non vengono ereditati dal figlio. gli allarmi ed i segnali pendenti, che per il figlio vengono cancellati.

13 CHIUSURA DI UN PROCESSO Qualunque sia la modalità di conclusione di un processo, il kernel esegue comunque una serie di operazioni: chiude tutti i file aperti, rilascia la memoria che stava usando, e così via; l'elenco completo delle operazioni eseguite alla chiusura di un processo è il seguente: tutti i file descriptor sono chiusi. viene memorizzato lo stato di terminazione del processo. ad ogni processo figlio viene assegnato un nuovo padre (in genere init). viene inviato il segnale SIGCHLD al processo padre se il processo è un leader di sessione ed il suo terminale di controllo è quello della sessione viene mandato un segnale di SIGHUP a tutti i processi del gruppo di foreground e il terminale di controllo viene disconnesso se la conclusione di un processo rende orfano un process group ciascun membro del gruppo viene bloccato, e poi gli vengono inviati in successione i segnali SIGHUP e SIGCONT è però necessario poter disporre di un meccanismo ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in un sistema unix-like tutto viene gestito attraverso i processi, il meccanismo scelto consiste nel riportare lo stato di terminazione (il cosiddetto termination status) al processo padre. quello che contraddistingue lo stato di chiusura del processo e viene riportato attraverso le funzioni wait o waitpid

14 CHIUSURA DI UN PROCESSO La scelta di riportare al padre lo stato di terminazione dei figli, pur essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto che sia così alla sua conclusione, dato che il padre potrebbe essere già terminato (si potrebbe avere cioè quello che si chiama un processo orfano) Questa complicazione viene superata facendo in modo che il processo orfano venga adottato da init. Come già accennato quando un processo termina, il kernel controlla se è il padre di altri processi in esecuzione: in caso positivo allora il ppid di tutti questi processi viene sostituito con il pid di init (e cioè con 1) Altrettanto rilevante è il caso in cui il figlio termina prima del padre, perché non è detto che il padre possa ricevere immediatamente lo stato di terminazione I processi che sono terminati, ma il cui stato di terminazione non è stato ancora ricevuto dal padre sono chiamati zombie, essi restano presenti nella tabella dei processi

15 TEST PROCESSI ORFANI E ZOMBIE Per generare processi orfani basta nel programma di test imponendo a ciascun processo figlio due secondi di attesa prima di uscire Per generare processi zombie lanciamo il comando forktest in background, indicando al processo padre di aspettare 10 secondi prima di uscire in questo caso, usando ps sullo stesso terminale (prima dello scadere dei 10 secondi)

16 LA FUNZIONE WAIT #include <sys/types.h> #include <sys/wait.h> pid_t wait(int *status) Sospende il processo corrente finché un figlio non è uscito, o finché un segnale termina il processo o chiama una funzione di gestione. La funzione restituisce il pid del figlio in caso di successo e -1 in caso di errore; errno può assumere i valori: EINTR la funzione è stata interrotta da un segnale.

17 LA FUNZIONE WAIT Al ritorno della funzione lo stato di terminazione del figlio viene salvato nella variabile puntata da status e tutte le risorse del kernel relative al processo vengono rilasciate. Nel caso un processo abbia più figli il valore di ritorno (il pid del figlio) permette di identificare qual è quello che è uscito. Questa funzione ha il difetto di essere poco flessibile, in quanto ritorna all'uscita di un qualunque processo figlio Nelle occasioni in cui è necessario attendere la conclusione di un processo specifico occorrerebbe predisporre un meccanismo che tenga conto dei processi già terminati, e provvedere a ripetere la chiamata alla funzione nel caso il processo cercato sia ancora attivo

18 LA FUNZIONE WAITPID #include <sys/types.h> #include <sys/wait.h> pid_t waitpid(pid_t pid, int *status, int options) Attende la conclusione di un processo figlio. La funzione restituisce il pid del processo che è uscito, 0 se è stata specificata l'opzione WNOHANG e il processo non è uscito e -1 per un errore, nel qual caso errno assumerà i valori: EINTR se non è stata specificata l'opzione WNOHANG e la funzione è stata interrotta da un segnale. ECHILD il processo specificato da pid non esiste o non è figlio del processo chiamante.

19 LA FUNZIONE WAITPID La terminazione di un processo figlio è chiaramente un evento asincrono rispetto all'esecuzione di un programma e può avvenire in un qualunque momento Per questo motivo, una delle azioni prese dal kernel alla conclusione di un processo è quella di mandare un segnale di SIGCHLD al padre. L'azione predefinita per questo segnale è di essere ignorato, ma la sua generazione costituisce il meccanismo di comunicazione asincrona con cui il kernel avverte il processo padre che uno dei suoi figli è terminato. In genere in un programma non si vuole essere forzati ad attendere la conclusione di un processo per proseguire, specie se tutto questo serve solo per leggerne lo stato di chiusura (ed evitare la presenza di zombie) la modalità più usata per chiamare queste funzioni è quella di utilizzarle all'interno di un signal handler. In questo caso infatti, dato che il segnale è generato dalla terminazione di un figlio, avremo la certezza che la chiamata a wait non si bloccherà.

20 LA FUNZIONE EXEC una delle modalità principali con cui si utilizzano i processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene fatto attraverso una delle funzioni della famiglia exec Quando un processo chiama una di queste funzioni esso viene completamente sostituito dal nuovo programma; il pid del processo non cambia, dato che non viene creato un nuovo processo, la funzione semplicemente rimpiazza lo stack, lo heap, i dati ed il testo del processo corrente con un nuovo programma letto da disco. Ci sono sei diverse versioni di exec (per questo la si è chiamata famiglia di funzioni) che possono essere usate per questo compito, in realtà (come mostrato in fig. 3.4), sono tutte un front-end a execve

21 LA FUNZIONE EXEC #include <unistd.h> int execve(const char *filename, char *const argv[], char *const envp[]) La funzione exec esegue il file o lo script indicato da filename, passandogli la lista di argomenti indicata da argv e come ambiente la lista di stringhe indicata da envp; entrambe le liste devono essere terminate da un puntatore nullo. I vettori degli argomenti e dell'ambiente possono essere acceduti dal nuovo programma quando la sua funzione main è dichiarata nella forma main(int argc, char *argv[], char *envp[]) La funzione ritorna solo in caso di errore, restituendo -1; nel qual caso errno può assumere i valori: EACCES il file non è eseguibile, oppure il filesystem è montato in noexec, oppure non è un file

22 La gestione del segnale SIGCHLD

23 SEGNALI I segnali sono usati per notificare ad un processo l'occorrenza di un qualche evento un breve elenco di possibili cause per l'emissione di un segnale è il seguente: un errore del programma, come una divisione per zero o un tentativo di accesso alla memoria fuori dai limiti validi. la terminazione di un processo figlio. la scadenza di un timer o di un allarme. il tentativo di effettuare un'operazione di input/output che non può essere eseguita. una richiesta dell'utente di terminare o fermare il programma. In genere si realizza attraverso un segnale mandato dalla shell in corrispondenza della pressione di tasti del terminale come C-c o C-z.1 l'esecuzione di una kill

24 TIPI DI SEGNALE I segnali sono identificati da MACRO definite in signal.h Lista di alcuni segnali

25 HANDLER DI SEGNALI I segnali sono eventi asincroni che possono essere generati in qualunque momento da cause interne ed esterne al processo Per poter gesitre un segnale bisogna definire una funzione chiamata handler Questo viene fatto con la seguente chiamata (esempio nel caso del segnale SIGINT) #include <signal.h> signal(sigint, sig_handler); Dove la sig_handler è una funzione che deve essere definita nel programma e che deve ritornare un intero

26 GESTIONE DEL SIGCHLD Come già detto non è sempre possibile che un processo padre possa fermarsi ad attendere lo stato di terminazione dei suoi figli Per questo motivo risolta opportuno chiamare la funzione wait all interno dell handler del segnale SIGCHLD All avvio del processo settiamo l handler per il segnale SIGCHLD Il processo padre può quindi continuare la sua esecuzione (per esempio attendere input da tastiera, attendere nuove connessioni, ecc.) Quando il padre ricede il segnale, viene quindi chiamata l handler Una volta completata la funzione di handler, il padre ritorna al punto in cui è stato interrotto

27 GESTIONE DEL SIGCHLD

28 Comunicazione tra processi attraverso POSIX shared memory

29 LA COMUNICAZIONE TRA PROCESSI Sia nel caso di processi padre figlio, sia nel caso di processi indipendenti, possiamo aver bisogno di un meccanismo di comunicazione Esistono molti meccanismi diversi Pipe, named pipe, socket locali, SYSV IPC, POSIX IPC In questa sezione vediamo le basi del meccanismo di shared memory Posix La memoria condivisa è l'unico degli oggetti di IPC POSIX già presente nel kernel ufficiale; in realtà il supporto a questo tipo di oggetti è realizzato attraverso il filesystem tmpfs, uno speciale filesystem che mantiene tutti i suoi contenuti in memoria, che viene attivato abilitando l'opzione CONFIG_TMPFS in fase di compilazione del kernel Per poter utilizzare la shared memory POSIX bisogna compilare il programma con l opzione -lrt

30 APERTURA DI UN SEGMENTO DI MEMORIA CONDIVISA #include <mqueue.h> int shm_open(const char *name, int oflag, mode_t mode) Apre un segmento di memoria condivisa. La funzione restituisce un file descriptor positivo in caso di successo e -1 in caso di errore; nel quel caso errno assumerà gli stessi valori riportati da open La funzione è del tutto analoga ad open ed analoghi sono i valori che possono essere specificati per oflag, che deve essere specificato come maschera binaria comprendente almeno uno dei due valori O_RDONLY e O_RDWR E possibile verificare la creazione del segmento di shared memory all interno della directory /dev/shm/

31 APERTURA DI UN SEGMENTO DI MEMORIA CONDIVISA Possibili valori di oflag: O_RDONLY Apre il file descriptor associato al segmento di memoria condivisa per l'accesso in sola lettura. O_RDWR Apre il file descriptor associato al segmento di memoria condivisa per l'accesso in lettura e scrittura. O_CREAT Necessario qualora si debba creare il segmento di memoria condivisa se esso non esiste; in questo caso viene usato il valore di mode per impostare i permessi, che devono essere compatibili con le modalità con cui si è aperto il file. O_EXCL Se usato insieme a O_CREAT fa fallire la chiamata a shm_open se il segmento esiste già, altrimenti esegue la creazione atomicamente. O_TRUNC Se il segmento di memoria condivisa esiste già, ne tronca le dimensioni a 0 byte.

32 APERTURA DI UN SEGMENTO DI MEMORIA CONDIVISA Chiamate multiple a shm_open usando lo stesso nome da più processi restituiranno file descriptor associati allo stesso segmento (così come, nel caso di file di dati, essi sono associati allo stesso inode) In questo modo è possibile effettuare una chiamata ad mmap sul file descriptor restituito da shm_open ed i processi vedranno lo stesso segmento di memoria condivisa Quando il nome non esiste il segmento può essere creato specificando O_CREAT; in tal caso il segmento avrà (così come i nuovi file) lunghezza nulla. Dato che un segmento di lunghezza nulla è di scarsa utilità, per impostarne la dimensione si deve usare ftruncate prima di mapparlo in memoria con mmap

33 MAPPATURA DI UN SEGMENTO DI MEMORIA CONDIVISA Una volta creato un segmento di memoria condivisa, questa memoria deve essere mappata all interno della memoria del processo che ha chiamato la funzione shm_open Questo viene effettuato attraverso la funzione mmap #include <sys/mman.h> void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset); Senza entrare nei dettagli, per mappare un segmento shm si effettua la seguente chiamata mmap(null, shm_size, PROT_WRITE PROT_READ, MAP_SHARED, fd, 0); Dove, fd è il file descriptor dell inode che rappresenta il segmento shm e shm_size è la grandezza del segmento

34 RIMOZIONE DI UN SEGMENTO DI MEMORIA CONDIVISA Come per i file, quando si vuole effettivamente rimuovere segmento di memoria condivisa, occorre usare la funzione shm_unlink #include <mqueue.h> int shm_unlink(const char *name) Rimuove un segmento di memoria condivisa. La funzione restituisce 0 in caso di successo e -1 in caso di errore

35 SEMPLICE INTERFACCIA ALLE CHIAMATE POSIX SHM

36 SEMPLICE INTERFACCIA ALLE CHIAMATE POSIX SHM

37 SEMPLICE INTERFACCIA ALLE CHIAMATE POSIX SHM

38 SEMPLICE INTERFACCIA ALLE CHIAMATE POSIX SHM

39 ESERCITAZIONE IN CLASSE Estendiamo la console per l esecuzione degli algoritmi di sorting come segue: 1) l algoritmo di sorting viene eseguito in un processo figlio. Il controllo ritorna alla console 2) È possibile controllare da console la percentuale di esecuzione dell algoritmo di sorting attraverso la lettura di una area di memoria condivisa 3) È possibile interrompere l esecuzione dell algoritmo tramite console 4) La console permette di lanciare un solo algoritmo alla volta

40 POSSIBILI ESTENSIONI PER CASA 1) Percentuale di completamento dell algoritmo merge sort 2) Esecuzione diversi algoritmi in parallelo 3) Permettere l esecuzione solo di un istanza dello algoritmo contemporaneamente