1 \chapter{La gestione dei processi}
2 \label{cha:process_handling}
4 Come accennato nell'introduzione in un sistema Unix tutte le operazioni
5 vengono svolte tramite opportuni processi. In sostanza questi ultimi vengono
6 a costituire l'unità base per l'allocazione e l'uso delle risorse del sistema.
8 Nel precedente capitolo abbiamo esaminato il funzionamento di un processo come
9 unità a se stante, in questo esamineremo il funzionamento dei processi
10 all'interno del sistema. Saranno cioè affrontati i dettagli della creazione e
11 della terminazione dei processi, della gestione dei loro attributi e
12 privilegi, e di tutte le funzioni a questo connesse. Infine nella sezione
13 finale introdurremo alcune problematiche generiche della programmazione in
14 ambiente multitasking.
17 \section{Introduzione}
20 Inizieremo con un'introduzione generale ai concetti che stanno alla base della
21 gestione dei processi in un sistema unix-like. Introdurremo in questa sezione
22 l'architettura della gestione dei processi e le sue principali
23 caratteristiche, dando una panoramica sull'uso delle principali funzioni di
27 \subsection{L'architettura della gestione dei processi}
28 \label{sec:proc_hierarchy}
30 A differenza di quanto avviene in altri sistemi (ad esempio nel VMS la
31 generazione di nuovi processi è un'operazione privilegiata) una delle
32 caratteristiche di Unix (che esamineremo in dettaglio più avanti) è che
33 qualunque processo può a sua volta generarne altri, detti processi figli
34 (\textit{child process}). Ogni processo è identificato presso il sistema da un
35 numero unico, il cosiddetto \textit{process identifier} o, più brevemente,
38 Una seconda caratteristica di un sistema Unix è che la generazione di un
39 processo è un'operazione separata rispetto al lancio di un programma. In
40 genere la sequenza è sempre quella di creare un nuovo processo, il quale
41 eseguirà, in un passo successivo, il programma desiderato: questo è ad esempio
42 quello che fa la shell quando mette in esecuzione il programma che gli
43 indichiamo nella linea di comando.
45 Una terza caratteristica è che ogni processo è sempre stato generato da un
46 altro, che viene chiamato processo padre (\textit{parent process}). Questo
47 vale per tutti i processi, con una sola eccezione: dato che ci deve essere un
48 punto di partenza esiste un processo speciale (che normalmente è
49 \cmd{/sbin/init}), che viene lanciato dal kernel alla conclusione della fase
50 di avvio; essendo questo il primo processo lanciato dal sistema ha sempre il
51 \acr{pid} uguale a 1 e non è figlio di nessun altro processo.
53 Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
54 partire tutti gli altri processi necessari al funzionamento del sistema,
55 inoltre \cmd{init} è essenziale per svolgere una serie di compiti
56 amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di
57 essi in \secref{sec:proc_termination}) e non può mai essere terminato. La
58 struttura del sistema comunque consente di lanciare al posto di \cmd{init}
59 qualunque altro programma, e in casi di emergenza (ad esempio se il file di
60 \cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
61 posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio.
66 [piccardi@gont piccardi]$ pstree -n
83 |-bash---startx---xinit-+-XFree86
84 | `-WindowMaker-+-ssh-agent
92 | |-wterm---bash---pstree
93 | `-wterm---bash-+-emacs
99 \caption{L'albero dei processi, così come riportato dal comando
101 \label{fig:proc_tree}
104 Dato che tutti i processi attivi nel sistema sono comunque generati da
105 \cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
106 vero, in Linux ci sono alcuni processi speciali che pur comparendo come
107 figli di \cmd{init}, o con \acr{pid} successivi, sono in realtà generati
108 direttamente dal kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.).} si
109 possono classificare i processi con la relazione padre/figlio in
110 un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
111 organizzati in un albero di directory (si veda
112 \secref{sec:file_organization}); in \curfig\ si è mostrato il risultato del
113 comando \cmd{pstree} che permette di visualizzare questa struttura, alla cui
114 base c'è \cmd{init} che è progenitore di tutti gli altri processi.
116 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
117 \textit{process table}; per ciascun processo viene mantenuta una voce nella
118 tabella dei processi costituita da una struttura \type{task\_struct}, che
119 contiene tutte le informazioni rilevanti per quel processo. Tutte le strutture
120 usate a questo scopo sono dichiarate nell'header file \file{linux/sched.h}, ed
121 uno schema semplificato, che riporta la struttura delle principali informazioni
122 contenute nella \type{task\_struct} (che in seguito incontreremo a più
123 riprese), è mostrato in \nfig.
127 \includegraphics[width=13cm]{img/task_struct}
128 \caption{Schema semplificato dell'architettura delle strutture usate dal
129 kernel nella gestione dei processi.}
130 \label{fig:proc_task_struct}
134 Come accennato in \secref{sec:intro_unix_struct} è lo \textit{scheduler} che
135 decide quale processo mettere in esecuzione; esso viene eseguito ad ogni
136 system call ed ad ogni interrupt,\footnote{più in una serie di altre
137 occasioni. NDT completare questa parte.} (ma può essere anche attivato
138 esplicitamente). Il timer di sistema provvede comunque a che esso sia invocato
139 periodicamente, generando un interrupt periodico secondo la frequenza
140 specificata dalla costante \macro{HZ}, definita in \file{asm/param.h}, ed il
141 cui valore è espresso in Hertz.\footnote{Il valore usuale di questa costante è
142 100, per tutte le architetture eccetto l'alpha, per la quale è 1000. Occorre
143 fare attenzione a non confondere questo valore con quello dei clock tick
144 (vedi \secref{sec:sys_unix_time}).}
145 %Si ha cioè un interrupt dal timer ogni centesimo di secondo.
147 Ogni volta che viene eseguito, lo \textit{scheduler} effettua il calcolo delle
148 priorità dei vari processi attivi (torneremo su questo in
149 \secref{sec:proc_priority}) e stabilisce quale di essi debba essere posto in
150 esecuzione fino alla successiva invocazione.
153 \subsection{Una panoramica sulle funzioni fondamentali}
154 \label{sec:proc_handling_intro}
156 I processi vengono creati dalla funzione \func{fork}; in molti unix questa è
157 una system call, Linux però usa un'altra nomenclatura, e la funzione
158 \func{fork} è basata a sua volta sulla system call \func{\_\_clone}, che viene
159 usata anche per generare i \textit{thread}. Il processo figlio creato dalla
160 \func{fork} è una copia identica del processo processo padre, ma ha nuovo
161 \acr{pid} e viene eseguito in maniera indipendente (le differenze fra padre e
162 figlio sono affrontate in dettaglio in \secref{sec:proc_fork}).
164 Se si vuole che il processo padre si fermi fino alla conclusione del processo
165 figlio questo deve essere specificato subito dopo la \func{fork} chiamando la
166 funzione \func{wait} o la funzione \func{waitpid} (si veda
167 \secref{sec:proc_wait}); queste funzioni restituiscono anche un'informazione
168 abbastanza limitata sulle cause della terminazione del processo figlio.
170 Quando un processo ha concluso il suo compito o ha incontrato un errore non
171 risolvibile esso può essere terminato con la funzione \func{exit} (si veda
172 quanto discusso in \secref{sec:proc_conclusion}). La vita del processo però
173 termina solo quando la notifica della sua conclusione viene ricevuta dal
174 processo padre, a quel punto tutte le risorse allocate nel sistema ad esso
175 associate vengono rilasciate.
177 Avere due processi che eseguono esattamente lo stesso codice non è molto
178 utile, normalmente si genera un secondo processo per affidargli l'esecuzione
179 di un compito specifico (ad esempio gestire una connessione dopo che questa è
180 stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per
181 quest'ultimo caso si usa la seconda funzione fondamentale per programmazione
182 coi processi che è la \func{exec}.
184 Il programma che un processo sta eseguendo si chiama immagine del processo (o
185 \textit{process image}), le funzioni della famiglia \func{exec} permettono di
186 caricare un'altro programma da disco sostituendo quest'ultimo all'immagine
187 corrente; questo fa sì che l'immagine precedente venga completamente
188 cancellata. Questo significa che quando il nuovo programma esce, anche il
189 processo termina, e non si può tornare alla precedente immagine.
191 Per questo motivo la \func{fork} e la \func{exec} sono funzioni molto
192 particolari con caratteristiche uniche rispetto a tutte le altre, infatti la
193 prima ritorna due volte (nel processo padre e nel figlio) mentre la seconda
194 non ritorna mai (in quanto con essa viene eseguito un altro programma).
198 \section{Le funzioni di base}% della gestione dei processi}
199 \label{sec:proc_handling}
201 In questa sezione tratteremo le problematiche della gestione dei processi
202 all'interno del sistema, illustrandone tutti i dettagli. Inizieremo con le
203 funzioni elementari che permettono di leggerne gli identificatori, per poi
204 passare alla spiegazione delle funzioni base che si usano per la creazione e
205 la terminazione dei processi, e per la messa in esecuzione degli altri
209 \subsection{Gli identificatori dei processi}
212 Come accennato nell'introduzione, ogni processo viene identificato dal sistema
213 da un numero identificativo unico, il \textit{process id} o \acr{pid};
214 quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
215 intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
218 Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
219 processo viene creato, fino ad un limite che, essendo il \acr{pid} un numero
220 positivo memorizzato in un intero a 16 bit, arriva ad un massimo di 32767.
221 Oltre questo valore l'assegnazione riparte dal numero più basso disponibile a
222 partire da un minimo di 300,\footnote{questi valori sono definiti dalla macro
223 \macro{PID\_MAX} in \file{threads.h} e direttamente in \file{fork.c} nei
224 sorgenti del kernel.} che serve a riservare i \acr{pid} più bassi ai processi
225 eseguiti dal direttamente dal kernel. Per questo motivo, come visto in
226 \secref{sec:proc_hierarchy}, il processo di avvio (\cmd{init}) ha sempre il
227 \acr{pid} uguale a uno.
229 Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
230 sono stati creati, questo viene chiamato in genere \acr{ppid} (da
231 \textit{parent process id}). Questi due identificativi possono essere
232 ottenuti da programma usando le funzioni:
234 \headdecl{sys/types.h}
236 \funcdecl{pid\_t getpid(void)} Restituisce il pid del processo corrente.
237 \funcdecl{pid\_t getppid(void)} Restituisce il pid del padre del processo
240 \bodydesc{Entrambe le funzioni non riportano condizioni di errore.}
242 \noindent esempi dell'uso di queste funzioni sono riportati in
243 \figref{fig:proc_fork_code}, nel programma di esempio \file{ForkTest.c}.
245 Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende un
246 candidato per generare ulteriori indicatori associati al processo di cui
247 diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
248 funzione \func{tmpname} (si veda \secref{sec:file_temp_file}) usa il \acr{pid}
249 per generare un pathname univoco, che non potrà essere replicato da un'altro
250 processo che usi la stessa funzione.
252 Tutti i processi figli dello stesso processo padre sono detti
253 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
254 sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
255 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
256 \secref{cha:session}, dove esamineremo gli altri identificativi associati ad
257 un processo e le varie relazioni fra processi utilizzate per definire una
260 Oltre al \acr{pid} e al \acr{ppid}, (e a quelli che vedremo in
261 \secref{sec:sess_xxx}, relativi al controllo di sessione), ad ogni processo
262 vengono associati degli altri identificatori che vengono usati per il
263 controllo di accesso. Questi servono per determinare se un processo può
264 eseguire o meno le operazioni richieste, a seconda dei privilegi e
265 dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà
266 affrontato in dettaglio in \secref{sec:proc_perms}.
269 \subsection{La funzione \func{fork}}
270 \label{sec:proc_fork}
272 La funzione \func{fork} è la funzione fondamentale della gestione dei
273 processi: come si è detto l'unico modo di creare un nuovo processo è
274 attraverso l'uso di questa funzione, essa quindi riveste un ruolo centrale
275 tutte le volte che si devono scrivere programmi che usano il multitasking. Il
276 prototipo della funzione è:
278 \headdecl{sys/types.h}
280 \funcdecl{pid\_t fork(void)}
281 Crea un nuovo processo.
283 \bodydesc{In caso di successo restituisce il \acr{pid} del figlio al padre e
284 zero al figlio; ritorna -1 al padre (senza creare il figlio) in caso di
285 errore; \var{errno} può assumere i valori:
287 \item[\macro{EAGAIN}] non ci sono risorse sufficienti per creare un'altro
288 processo (per allocare la tabella delle pagine e le strutture del task) o
289 si è esaurito il numero di processi disponibili.
290 \item[\macro{ENOMEM}] non è stato possibile allocare la memoria per le
291 strutture necessarie al kernel per creare il nuovo processo.
295 Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
296 il processo figlio continuano ad essere eseguiti normalmente all'istruzione
297 seguente la \func{fork}; il processo figlio è però una copia del padre, e
298 riceve una copia dei segmenti di testo, stack e dati (vedi
299 \secref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del
300 padre. Si tenga presente però che la memoria è copiata, non condivisa,
301 pertanto padre e figlio vedono variabili diverse.
303 Per quanto riguarda la gestione della memoria in generale il segmento di
304 testo, che è identico, è condiviso e tenuto in read-only per il padre e per i
305 figli. Per gli altri segmenti Linux utilizza la tecnica del \textit{copy on
306 write}\index{copy on write}; questa tecnica comporta che una pagina di
307 memoria viene effettivamente copiata per il nuovo processo solo quando ci
308 viene effettuata sopra una scrittura (e si ha quindi una reale differenza fra
309 padre e figlio). In questo modo si rende molto più efficiente il meccanismo
310 della creazione di un nuovo processo, non essendo più necessaria la copia di
311 tutto lo spazio degli indirizzi virtuali del padre, ma solo delle pagine di
312 memoria che sono state modificate, e solo al momento della modifica stessa.
314 La differenza che si ha nei due processi è che nel processo padre il valore di
315 ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
316 nel figlio è zero; in questo modo il programma può identificare se viene
317 eseguito dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni
318 \textbf{due} volte: una nel padre e una nel figlio.
320 La scelta di questi valori di ritorno non è casuale, un processo infatti può
321 avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
322 permette di identificare quello appena creato; al contrario un figlio ha
323 sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
324 \func{getppid}, vedi \secref{sec:proc_pid}) per cui si usa il valore nullo,
325 che non è il \acr{pid} di nessun processo.
330 #include <errno.h> /* error definitions and routines */
331 #include <stdlib.h> /* C standard library */
332 #include <unistd.h> /* unix standard library */
333 #include <stdio.h> /* standard I/O library */
334 #include <string.h> /* string functions */
336 /* Help printing routine */
339 int main(int argc, char *argv[])
342 * Variables definition
349 ... /* handling options */
350 nchild = atoi(argv[optind]);
351 printf("Test for forking %d child\n", nchild);
352 /* loop to fork children */
353 for (i=0; i<nchild; i++) {
354 if ( (pid = fork()) < 0) {
356 printf("Error on %d child creation, %s\n", i+1, strerror(errno));
359 if (pid == 0) { /* child */
360 printf("Child %d successfully executing\n", ++i);
361 if (wait_child) sleep(wait_child);
362 printf("Child %d, parent %d, exiting\n", i, getppid());
364 } else { /* parent */
365 printf("Spawned %d child, pid %d \n", i+1, pid);
366 if (wait_parent) sleep(wait_parent);
367 printf("Go to next child \n");
371 if (wait_end) sleep(wait_end);
375 \caption{Esempio di codice per la creazione di nuovi processi.}
376 \label{fig:proc_fork_code}
379 Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci
380 sono già troppi processi nel sistema (il che di solito è sintomo che
381 qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
382 sul numero totale di processi permessi all'utente (vedi
383 \secref{sec:sys_resource_limit}, ed in particolare
384 \tabref{tab:sys_rlimit_values}).
386 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
387 quella in cui all'interno di un programma si creano processi figli cui viene
388 affidata l'esecuzione di una certa sezione di codice, mentre il processo padre
389 ne esegue un'altra. È il caso tipico dei server (il modello
390 \textit{client-server} è illustrato in \secref{sec:net_cliserv}) di rete in
391 cui il padre riceve ed accetta le richieste da parte dei client, per ciascuna
392 delle quali pone in esecuzione un figlio che è incaricato di fornire il
395 La seconda modalità è quella in cui il processo vuole eseguire un altro
396 programma; questo è ad esempio il caso della shell. In questo caso il processo
397 crea un figlio la cui unica operazione è quella fare una \func{exec} (di cui
398 parleremo in \secref{sec:proc_exec}) subito dopo la \func{fork}.
400 Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa
401 seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
402 operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
403 scelto di mantenere questa separazione, dato che, come per la prima modalità
404 d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
405 aver bisogno di eseguire una \func{exec}. Inoltre, anche nel caso della
406 seconda modalità d'uso, avere le due funzioni separate permette al figlio di
407 cambiare gli attributi del processo (maschera dei segnali, redirezione
408 dell'output, \textit{user id}) prima della \func{exec}, rendendo così
409 relativamente facile intervenire sulle le modalità di esecuzione del nuovo
412 In \curfig\ si è riportato il corpo del codice del programma di esempio
413 \cmd{forktest}, che ci permette di illustrare molte caratteristiche dell'uso
414 della funzione \func{fork}. Il programma permette di creare un numero di figli
415 specificato da linea di comando, e prende anche alcune opzioni per indicare
416 degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
417 \func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
418 descrizione delle opzioni); il codice completo, compresa la parte che gestisce
419 le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
420 distribuito insieme agli altri sorgenti degli esempi su
421 \href{http://gapil.firenze.linux.it/gapil_source.tgz}
422 {\texttt{http://gapil.firenze.linux.it/gapil\_source.tgz}}.
424 Decifrato il numero di figli da creare, il ciclo principale del programma
425 (\texttt{\small 24--40}) esegue in successione la creazione dei processi figli
426 controllando il successo della chiamata a \func{fork} (\texttt{\small
427 25--29}); ciascun figlio (\texttt{\small 31--34}) si limita a stampare il
428 suo numero di successione, eventualmente attendere il numero di secondi
429 specificato e scrivere un messaggio prima di uscire. Il processo padre invece
430 (\texttt{\small 36--38}) stampa un messaggio di creazione, eventualmente
431 attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
432 alla conclusione del ciclo, prima di uscire, può essere specificato un altro
435 Se eseguiamo il comando senza specificare attese (come si può notare in
436 \texttt{\small 17--19} i valori di default specificano di non attendere),
437 otterremo come output sul terminale:
441 [piccardi@selidor sources]$ ./forktest 3
442 Process 1963: forking 3 child
443 Spawned 1 child, pid 1964
444 Child 1 successfully executing
445 Child 1, parent 1963, exiting
447 Spawned 2 child, pid 1965
448 Child 2 successfully executing
449 Child 2, parent 1963, exiting
451 Child 3 successfully executing
452 Child 3, parent 1963, exiting
453 Spawned 3 child, pid 1966
458 Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
459 si può dire quale processo fra il padre ed il figlio venga eseguito per
460 primo\footnote{a partire dal kernel 2.5.2-pre10 è stato introdotto il nuovo
461 scheduler di Ingo Molnar che esegue sempre per primo il figlio; per
462 mantenere la portabilità è opportuno non fare comunque affidamento su questo
463 comportamento.} dopo la chiamata a \func{fork}; dall'esempio si può notare
464 infatti come nei primi due cicli sia stato eseguito per primo il padre (con la
465 stampa del \acr{pid} del nuovo processo) per poi passare all'esecuzione del
466 figlio (completata con i due avvisi di esecuzione ed uscita), e tornare
467 all'esecuzione del padre (con la stampa del passaggio al ciclo successivo),
468 mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione)
471 In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
472 scheduling usato dal kernel, dalla particolare situazione in si trova la
473 macchina al momento della chiamata, risultando del tutto impredicibile.
474 Eseguendo più volte il programma di prova e producendo un numero diverso di
475 figli, si sono ottenute situazioni completamente diverse, compreso il caso in
476 cui il processo padre ha eseguito più di una \func{fork} prima che uno dei
477 figli venisse messo in esecuzione.
479 Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
480 istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
481 essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
482 occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
483 rischio di incorrere nelle cosiddette
484 \textit{race condition}\index{race condition}
485 (vedi \secref{sec:proc_race_cond}).
487 Si noti inoltre che essendo i segmenti di memoria utilizzati dai singoli
488 processi completamente separati, le modifiche delle variabili nei processi
489 figli (come l'incremento di \var{i} in \texttt{\small 31}) sono visibili solo
490 a loro (ogni processo vede solo la propria copia della memoria), e non hanno
491 alcun effetto sul valore che le stesse variabili hanno nel processo padre (ed
492 in eventuali altri processi figli che eseguano lo stesso codice).
494 Un secondo aspetto molto importante nella creazione dei processi figli è
495 quello dell'interazione dei vari processi con i file; per illustrarlo meglio
496 proviamo a redirigere su un file l'output del nostro programma di test, quello
501 [piccardi@selidor sources]$ ./forktest 3 > output
502 [piccardi@selidor sources]$ cat output
503 Process 1967: forking 3 child
504 Child 1 successfully executing
505 Child 1, parent 1967, exiting
506 Test for forking 3 child
507 Spawned 1 child, pid 1968
509 Child 2 successfully executing
510 Child 2, parent 1967, exiting
511 Test for forking 3 child
512 Spawned 1 child, pid 1968
514 Spawned 2 child, pid 1969
516 Child 3 successfully executing
517 Child 3, parent 1967, exiting
518 Test for forking 3 child
519 Spawned 1 child, pid 1968
521 Spawned 2 child, pid 1969
523 Spawned 3 child, pid 1970
527 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
529 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
530 in gran dettaglio in \capref{cha:file_unix_interface} e in
531 \secref{cha:files_std_interface}. Qui basta accennare che si sono usate le
532 funzioni standard della libreria del C che prevedono l'output bufferizzato; e
533 questa bufferizzazione (trattata in dettaglio in \secref{sec:file_buffering})
534 varia a seconda che si tratti di un file su disco (in cui il buffer viene
535 scaricato su disco solo quando necessario) o di un terminale (nel qual caso il
536 buffer viene scaricato ad ogni carattere di a capo).
538 Nel primo esempio allora avevamo che ad ogni chiamata a \func{printf} il
539 buffer veniva scaricato, e le singole righe erano stampate a video subito dopo
540 l'esecuzione della \func{printf}. Ma con la redirezione su file la scrittura
541 non avviene più alla fine di ogni riga e l'output resta nel buffer. Dato che
542 ogni figlio riceve una copia della memoria del padre, esso riceverà anche
543 quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte dal
544 padre fino allora. Così quando il buffer viene scritto su disco all'uscita del
545 figlio, troveremo nel file anche tutto quello che il processo padre aveva
546 scritto prima della sua creazione. E alla fine del file (dato che in questo
547 caso il padre esce per ultimo) troveremo anche l'output completo del padre.
549 L'esempio ci mostra un'altro aspetto fondamentale dell'interazione con i file,
550 valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
551 solo processi diversi possono scrivere in contemporanea sullo stesso file
552 (l'argomento della condivisione dei file è trattato in dettaglio in
553 \secref{sec:file_sharing}), ma anche che, a differenza di quanto avviene per
554 le variabili, la posizione corrente sul file è condivisa fra il padre e tutti
557 Quello che succede è che quando lo standard output del padre viene rediretto,
558 lo stesso avviene anche per tutti i figli; la funzione \func{fork} infatti ha
559 la caratteristica di duplicare (allo stesso modo in cui lo fa la funzione
560 \func{dup}, trattata in \secref{sec:file_dup}) nei figli tutti i file
561 descriptor aperti nel padre, il che comporta che padre e figli condividono le
562 stesse voci della \textit{file table} (per la spiegazione di questi termini si
563 veda \secref{sec:file_sharing}) e fra cui c'è anche la posizione corrente nel
566 In questo modo se un processo scrive sul file aggiornerà la posizione corrente
567 sulla \textit{file table}, e tutti gli altri processi, che vedono la stessa
568 \textit{file table}, vedranno il nuovo valore. In questo modo si evita, in
569 casi come quello appena mostrato in cui diversi processi scrivono sullo stesso
570 file, che l'output successivo di un processo vada a sovrapporsi a quello dei
571 precedenti: l'output potrà risultare mescolato, ma non ci saranno parti
572 perdute per via di una sovrascrittura.
574 Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
575 crea un figlio e attende la sua conclusione per proseguire, ed entrambi
576 scrivono sullo stesso file (un caso tipico è la shell quando lancia un
577 programma, il cui output va sullo standard output).
579 In questo modo, anche se l'output viene rediretto, il padre potrà sempre
580 continuare a scrivere in coda a quanto scritto dal figlio in maniera
581 automatica; se così non fosse ottenere questo comportamento sarebbe
582 estremamente complesso necessitando di una qualche forma di comunicazione fra
583 i due processi per far riprendere al padre la scrittura al punto giusto.
585 In generale comunque non è buona norma far scrivere più processi sullo stesso
586 file senza una qualche forma di sincronizzazione in quanto, come visto anche
587 con il nostro esempio, le varie scritture risulteranno mescolate fra loro in
588 una sequenza impredicibile. Per questo le modalità con cui in genere si usano
589 i file dopo una \func{fork} sono sostanzialmente due:
591 \item Il processo padre aspetta la conclusione del figlio. In questo caso non
592 è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
593 della posizione corrente dopo eventuali operazioni di lettura e scrittura
594 effettuate dal figlio è automatica.
595 \item L'esecuzione di padre e figlio procede indipendentemente. In questo caso
596 ciascuno dei due processi deve chiudere i file che non gli servono una volta
597 che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
600 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
601 proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
602 comune dopo l'esecuzione di una \func{fork} è la seguente:
604 \item i file aperti e gli eventuali flag di \textit{close-on-exec} settati
605 (vedi \secref{sec:proc_exec} e \secref{sec:file_fcntl}).
606 \item gli identificatori per il controllo di accesso: il \textit{real user
607 id}, il \textit{real group id}, l'\textit{effective user id},
608 l'\textit{effective group id} ed i \textit{supplementary group id} (vedi
609 \secref{sec:proc_access_id}).
610 \item gli identificatori per il controllo di sessione: il \textit{process
611 group id} e il \textit{session id} ed il terminale di controllo (vedi
612 \secref{sec:sess_xxx} e \secref{sec:sess_xxx}).
613 \item la directory di lavoro e la directory radice (vedi
614 \secref{sec:file_work_dir} e \secref{sec:file_chroot}).
615 \item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}).
616 \item la maschera dei segnali bloccati (vedi \secref{sec:sig_sigmask}) e le
617 azioni installate (vedi \secref{sec:sig_gen_beha}).
618 \item i segmenti di memoria condivisa agganciati al processo (vedi
619 \secref{sec:ipc_shar_mem}).
620 \item i limiti sulle risorse (vedi \secref{sec:sys_resource_limit}).
621 \item le variabili di ambiente (vedi \secref{sec:proc_environ}).
623 le differenze fra padre e figlio dopo la \func{fork} invece sono:
625 \item il valore di ritorno di \func{fork}.
626 \item il \textit{process id}.
627 \item il \textit{parent process id} (quello del figlio viene settato al
628 \acr{pid} del padre).
629 \item i valori dei tempi di esecuzione della struttura \var{tms} (vedi
630 \secref{sec:sys_cpu_times}) che nel figlio sono posti a zero.
631 \item i \textit{file lock} (vedi \secref{sec:file_locking}), che non
632 vengono ereditati dal figlio.
633 \item gli allarmi ed i segnali pendenti (vedi \secref{sec:sig_gen_beha}), che
634 per il figlio vengono cancellati.
638 \subsection{La funzione \func{vfork}}
639 \label{sec:proc_vfork}
641 La funzione \func{vfork} è esattamente identica a \func{fork} ed ha la stessa
642 semantica e gli stessi errori; la sola differenza è che non viene creata la
643 tabella delle pagine né la struttura dei task per il nuovo processo. Il
644 processo padre è posto in attesa fintanto che il figlio non ha eseguito una
645 \func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la
646 memoria del padre (e modifiche possono avere effetti imprevedibili) e non deve
647 ritornare o uscire con \func{exit} ma usare esplicitamente \func{\_exit}.
649 Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una
650 \func{fork} comportava anche la copia completa del segmento dati del processo
651 padre, che costituiva un inutile appesantimento in tutti quei casi in cui la
652 \func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione
653 venne introdotta in BSD per migliorare le prestazioni.
655 Dato che Linux supporta il \textit{copy on write}\index{copy on write} la
656 perdita di prestazioni è assolutamente trascurabile, e l'uso di questa
657 funzione (che resta un caso speciale della funzione \func{clone}), è
658 deprecato; per questo eviteremo di trattarla ulteriormente.
661 \subsection{La conclusione di un processo.}
662 \label{sec:proc_termination}
664 In \secref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
665 chiudere un programma, ma dall'interno del programma stesso; avendo a che fare
666 con un sistema multitasking resta da affrontare l'argomento dal punto di vista
667 di come il sistema gestisce la conclusione dei processi.
669 Abbiamo visto in \secref{sec:proc_conclusion} le tre modalità con cui un
670 programma viene terminato in maniera normale: la chiamata di \func{exit} (che
671 esegue le funzioni registrate per l'uscita e chiude gli stream), il ritorno
672 dalla funzione \func{main} (equivalente alla chiamata di \func{exit}), e la
673 chiamata ad \func{\_exit} (che passa direttamente alle operazioni di
674 terminazione del processo da parte del kernel).
676 Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle
677 modalità di conclusione anomala; queste sono in sostanza due: il programma può
678 chiamare la funzione \func{abort} per invocare una chiusura anomala, o essere
679 terminato da un segnale. In realtà anche la prima modalità si riconduce alla
680 seconda, dato che \func{abort} si limita a generare il segnale
683 Qualunque sia la modalità di conclusione di un processo, il kernel esegue
684 comunque una serie di operazioni: chiude tutti i file aperti, rilascia la
685 memoria che stava usando, e così via; l'elenco completo delle operazioni
686 eseguite alla chiusura di un processo è il seguente:
688 \item tutti i file descriptor sono chiusi.
689 \item viene memorizzato lo stato di terminazione del processo.
690 \item ad ogni processo figlio viene assegnato un nuovo padre (in genere
692 \item viene inviato il segnale \macro{SIGCHLD} al processo padre (vedi
693 \secref{sec:sig_sigchld}).
694 \item se il processo è un leader di sessione viene mandato un segnale di
695 \macro{SIGHUP} a tutti i processi in background e il terminale di
696 controllo viene disconnesso (vedi \secref{sec:sess_xxx}).
697 \item se la conclusione di un processo rende orfano un \textit{process
698 group} ciascun membro del gruppo viene bloccato, e poi gli vengono
699 inviati in successione i segnali \macro{SIGHUP} e \macro{SIGCONT}
700 (vedi \secref{sec:sess_xxx}).
703 Oltre queste operazioni è però necessario poter disporre di un meccanismo
704 ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
705 un sistema unix-like tutto viene gestito attraverso i processi, il meccanismo
706 scelto consiste nel riportare lo stato di terminazione (il cosiddetto
707 \textit{termination status}) al processo padre.
709 Nel caso di conclusione normale, abbiamo visto in \secref{sec:proc_conclusion}
710 che lo stato di uscita del processo viene caratterizzato tramite il valore del
711 cosiddetto \textit{exit status}, cioè il valore passato alle funzioni
712 \func{exit} o \func{\_exit} (o dal valore di ritorno per \func{main}). Ma se
713 il processo viene concluso in maniera anomala il programma non può specificare
714 nessun \textit{exit status}, ed è il kernel che deve generare autonomamente il
715 \textit{termination status} per indicare le ragioni della conclusione anomala.
717 Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
718 quello che contraddistingue lo stato di chiusura del processo e viene
719 riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
720 \secref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale
721 il kernel usa il primo (nel codice eseguito da \func{\_exit}) per produrre il
724 La scelta di riportare al padre lo stato di terminazione dei figli, pur
725 essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
726 alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
727 che sia così alla sua conclusione, dato che il padre potrebbe essere già
728 terminato (si potrebbe avere cioè quello che si chiama un processo
731 Questa complicazione viene superata facendo in modo che il processo orfano
732 venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
733 termina, il kernel controlla se è il padre di altri processi in esecuzione: in
734 caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito
735 con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
736 avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo})
737 cui riportare il suo stato di terminazione. Come verifica di questo
738 comportamento possiamo eseguire il nostro programma \cmd{forktest} imponendo a
739 ciascun processo figlio due secondi di attesa prima di uscire, il risultato è:
743 [piccardi@selidor sources]$ ./forktest -c2 3
744 Process 1972: forking 3 child
745 Spawned 1 child, pid 1973
746 Child 1 successfully executing
748 Spawned 2 child, pid 1974
749 Child 2 successfully executing
751 Child 3 successfully executing
752 Spawned 3 child, pid 1975
754 [piccardi@selidor sources]$ Child 3, parent 1, exiting
755 Child 2, parent 1, exiting
756 Child 1, parent 1, exiting
759 come si può notare in questo caso il processo padre si conclude prima dei
760 figli, tornando alla shell, che stampa il prompt sul terminale: circa due
761 secondi dopo viene stampato a video anche l'output dei tre figli che
762 terminano, e come si può notare in questo caso, al contrario di quanto visto
763 in precedenza, essi riportano 1 come \acr{ppid}.
765 Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
766 perché non è detto che il padre possa ricevere immediatamente lo stato di
767 terminazione, quindi il kernel deve comunque conservare una certa quantità di
768 informazioni riguardo ai processi che sta terminando.
770 Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
771 memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
772 dal processo (vedi \secref{sec:sys_unix_time}) e lo stato di
773 terminazione\footnote{NdA verificare esattamente cosa c'è!}, mentre la memoria
774 in uso ed i file aperti vengono rilasciati immediatamente. I processi che sono
775 terminati, ma il cui stato di terminazione non è stato ancora ricevuto dal
776 padre sono chiamati \textit{zombie}, essi restano presenti nella tabella dei
777 processi ed in genere possono essere identificati dall'output di \cmd{ps} per
778 la presenza di una \texttt{Z} nella colonna che ne indica lo stato. Quando il
779 padre effettuerà la lettura dello stato di uscita anche questa informazione,
780 non più necessaria, verrà scartata e la terminazione potrà dirsi completamente
783 Possiamo utilizzare il nostro programma di prova per analizzare anche questa
784 condizione: lanciamo il comando \cmd{forktest} in background, indicando al
785 processo padre di aspettare 10 secondi prima di uscire; in questo caso, usando
786 \cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi)
791 [piccardi@selidor sources]$ ps T
792 PID TTY STAT TIME COMMAND
793 419 pts/0 S 0:00 bash
794 568 pts/0 S 0:00 ./forktest -e10 3
795 569 pts/0 Z 0:00 [forktest <defunct>]
796 570 pts/0 Z 0:00 [forktest <defunct>]
797 571 pts/0 Z 0:00 [forktest <defunct>]
798 572 pts/0 R 0:00 ps T
801 e come si vede, dato che non si è fatto nulla per riceverne lo stato di
802 terminazione, i tre processi figli sono ancora presenti pur essendosi
803 conclusi, con lo stato di zombie e l'indicazione che sono stati terminati.
805 La possibilità di avere degli zombie deve essere tenuta sempre presente quando
806 si scrive un programma che deve essere mantenuto in esecuzione a lungo e
807 creare molti figli. In questo caso si deve sempre avere cura di far leggere
808 l'eventuale stato di uscita di tutti i figli (in genere questo si fa
809 attraverso un apposito \textit{signal handler}, che chiama la funzione
810 \func{wait}, vedi \secref{sec:sig_sigchld} e \secref{sec:proc_wait}). Questa
811 operazione è necessaria perché anche se gli \textit{zombie} non consumano
812 risorse di memoria o processore, occupano comunque una voce nella tabella dei
813 processi, che a lungo andare potrebbe esaurirsi.
815 Si noti che quando un processo adottato da \cmd{init} termina, esso non
816 diviene uno \textit{zombie}; questo perché una delle funzioni di \cmd{init} è
817 appunto quella di chiamare la funzione \func{wait} per i processi cui fa da
818 padre, completandone la terminazione. Questo è quanto avviene anche quando,
819 come nel caso del precedente esempio con \cmd{forktest}, il padre termina con
820 dei figli in stato di zombie: alla sua terminazione infatti tutti i suoi figli
821 (compresi gli zombie) verranno adottati da \cmd{init}, il quale provvederà a
822 completarne la terminazione.
824 Si tenga presente infine che siccome gli zombie sono processi già usciti, non
825 c'è modo di eliminarli con il comando \cmd{kill}; l'unica possibilità di
826 cancellarli dalla tabella dei processi è quella di terminare il processo che
827 li ha generati, in modo che \cmd{init} possa adottarli e provvedere a
828 concluderne la terminazione.
831 \subsection{Le funzioni \func{wait} e \func{waitpid}}
832 \label{sec:proc_wait}
834 Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
835 consiste nella creazione di programmi di tipo server, in cui un processo
836 principale attende le richieste che vengono poi soddisfatte da una serie di
837 processi figli. Si è già sottolineato al paragrafo precedente come in questo
838 caso diventi necessario gestire esplicitamente la conclusione dei figli onde
839 evitare di riempire di \textit{zombie} la tabella dei processi; le funzioni
840 deputate a questo compito sono sostanzialmente due, \func{wait} e
841 \func{waitpid}. La prima, il cui prototipo è:
843 \headdecl{sys/types.h}
844 \headdecl{sys/wait.h}
845 \funcdecl{pid\_t wait(int *status)}
847 Sospende il processo corrente finché un figlio non è uscito, o finché un
848 segnale termina il processo o chiama una funzione di gestione.
850 \bodydesc{La funzione restituisce il \acr{pid} del figlio in caso di successo
851 e -1 in caso di errore; \var{errno} può assumere i valori:
853 \item[\macro{EINTR}] la funzione è stata interrotta da un segnale.
857 è presente fin dalle prime versioni di Unix; la funzione ritorna non appena un
858 processo figlio termina. Se un figlio è già terminato la funzione ritorna
861 Al ritorno lo stato di terminazione del processo viene salvato nella
862 variabile puntata da \var{status} e tutte le informazioni relative al
863 processo (vedi \secref{sec:proc_termination}) vengono rilasciate. Nel
864 caso un processo abbia più figli il valore di ritorno permette di
865 identificare qual'è quello che è uscito.
867 Questa funzione ha il difetto di essere poco flessibile, in quanto
868 ritorna all'uscita di un figlio qualunque. Nelle occasioni in cui è
869 necessario attendere la conclusione di un processo specifico occorre
870 predisporre un meccanismo che tenga conto dei processi già terminati, e
871 provveda a ripetere la chiamata alla funzione nel caso il processo
872 cercato sia ancora attivo.
874 Per questo motivo lo standard POSIX.1 ha introdotto la funzione \func{waitpid}
875 che effettua lo stesso servizio, ma dispone di una serie di funzionalità più
876 ampie, legate anche al controllo di sessione. Dato che è possibile ottenere
877 lo stesso comportamento di \func{wait} si consiglia di utilizzare sempre
878 questa funzione, il cui prototipo è:
880 \headdecl{sys/types.h}
881 \headdecl{sys/wait.h}
882 \funcdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
883 Attende la conclusione di un processo figlio.
885 \bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se
886 è stata specificata l'opzione \macro{WNOHANG} e il processo non è uscito e
887 -1 per un errore, nel qual caso \var{errno} assumerà i valori:
889 \item[\macro{EINTR}] se non è stata specificata l'opzione \macro{WNOHANG} e
890 la funzione è stata interrotta da un segnale.
891 \item[\macro{ECHILD}] il processo specificato da \param{pid} non esiste o
892 non è figlio del processo chiamante.
896 Le differenze principali fra le due funzioni sono che \func{wait} si blocca
897 sempre fino a che un processo figlio non termina, mentre \func{waitpid} ha la
898 possibilità si specificare un'opzione \macro{WNOHANG} che ne previene il
899 blocco; inoltre \func{waitpid} può specificare quale processo attendere sulla
900 base del valore fornito dall'argomento \param{pid}, secondo lo
901 specchietto riportato in \ntab:
905 \begin{tabular}[c]{|c|c|p{8cm}|}
907 \textbf{Valore} & \textbf{Macro} &\textbf{Significato}\\
910 $<-1$& -- & attende per un figlio il cui \textit{process group} è uguale al
911 valore assoluto di \var{pid}. \\
912 $-1$ & \macro{WAIT\_ANY} & attende per un figlio qualsiasi, usata in
913 questa maniera è equivalente a \func{wait}.\\
914 $0$ & \macro{WAIT\_MYPGRP} & attende per un figlio il cui \textit{process
915 group} è uguale a quello del processo chiamante. \\
916 $>0$ & -- &attende per un figlio il cui \acr{pid} è uguale al
917 valore di \var{pid}.\\
920 \caption{Significato dei valori del parametro \var{pid} della funzione
922 \label{tab:proc_waidpid_pid}
925 Il comportamento di \func{waitpid} può inoltre essere modificato passando
926 delle opportune opzioni tramite l'argomento \param{option}. I valori possibili
927 sono il già citato \macro{WNOHANG}, che previene il blocco della funzione
928 quando il processo figlio non è terminato, e \macro{WUNTRACED} (usata per il
929 controllo di sessione, trattato in \capref{cha:session}) che fa ritornare la
930 funzione anche per i processi figli che sono bloccati ed il cui stato non è
931 stato ancora riportato al padre. Il valore dell'opzione deve essere
932 specificato come maschera binaria ottenuta con l'OR delle suddette costanti
935 La terminazione di un processo figlio è chiaramente un evento asincrono
936 rispetto all'esecuzione di un programma e può avvenire in un qualunque
937 momento. Per questo motivo, come accennato nella sezione precedente, una delle
938 azioni prese dal kernel alla conclusione di un processo è quella di mandare un
939 segnale di \macro{SIGCHLD} al padre. L'azione di default (si veda
940 \secref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua
941 generazione costituisce il meccanismo di comunicazione asincrona con cui il
942 kernel avverte il processo padre che uno dei suoi figli è terminato.
944 In genere in un programma non si vuole essere forzati ad attendere la
945 conclusione di un processo per proseguire, specie se tutto questo serve solo
946 per leggerne lo stato di chiusura (ed evitare la presenza di \textit{zombie}),
947 per questo la modalità più usata per chiamare queste funzioni è quella di
948 utilizzarle all'interno di un \textit{signal handler} (vedremo un esempio di
949 come gestire \macro{SIGCHLD} con i segnali in \secref{sec:sig_example}). In
950 questo caso infatti, dato che il segnale è generato dalla terminazione di un
951 figlio, avremo la certezza che la chiamata a \func{wait} non si bloccherà.
956 \begin{tabular}[c]{|c|p{10cm}|}
958 \textbf{Macro} & \textbf{Descrizione}\\
961 \macro{WIFEXITED(s)} & Condizione vera (valore non nullo) per un processo
962 figlio che sia terminato normalmente. \\
963 \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello
964 stato di uscita del processo (passato attraverso \func{\_exit}, \func{exit}
965 o come valore di ritorno di \func{main}). Può essere valutata solo se
966 \macro{WIFEXITED} ha restituito un valore non nullo.\\
967 \macro{WIFSIGNALED(s)} & Vera se il processo figlio è terminato
968 in maniera anomala a causa di un segnale che non è stato catturato (vedi
969 \secref{sec:sig_notification}).\\
970 \macro{WTERMSIG(s)} & restituisce il numero del segnale che ha causato
971 la terminazione anomala del processo. Può essere valutata solo se
972 \macro{WIFSIGNALED} ha restituito un valore non nullo.\\
973 \macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un
974 file si \textit{core dump}. Può essere valutata solo se
975 \macro{WIFSIGNALED} ha restituito un valore non nullo.\footnote{questa
976 macro non è definita dallo standard POSIX.1, ma è presente come estensione
977 sia in Linux che in altri Unix.}\\
978 \macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di
979 \func{waitpid} è bloccato. L'uso è possibile solo avendo specificato
980 l'opzione \macro{WUNTRACED}. \\
981 \macro{WSTOPSIG(s)} & restituisce il numero del segnale che ha bloccato
982 il processo, Può essere valutata solo se \macro{WIFSTOPPED} ha
983 restituito un valore non nullo. \\
986 \caption{Descrizione delle varie macro di preprocessore utilizzabili per
987 verificare lo stato di terminazione \var{s} di un processo.}
988 \label{tab:proc_status_macro}
991 Entrambe le funzioni di attesa restituiscono lo stato di terminazione del
992 processo tramite il puntatore \param{status} (se non interessa memorizzare lo
993 stato si può passare un puntatore nullo). Il valore restituito da entrambe le
994 funzioni dipende dall'implementazione, e tradizionalmente alcuni bit (in
995 genere 8) sono riservati per memorizzare lo stato di uscita, e altri per
996 indicare il segnale che ha causato la terminazione (in caso di conclusione
997 anomala), uno per indicare se è stato generato un core file, ecc.\footnote{le
998 definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
999 questo file non deve mai essere usato direttamente, esso viene incluso
1000 attraverso \file{<sys/wait.h>}.}
1002 Lo standard POSIX.1 definisce una serie di macro di preprocessore da usare per
1003 analizzare lo stato di uscita. Esse sono definite sempre in
1004 \file{<sys/wait.h>} ed elencate in \tabref{tab:proc_status_macro} (si tenga
1005 presente che queste macro prendono come parametro la variabile di tipo
1006 \ctyp{int} puntata da \var{status}).
1008 Si tenga conto che nel caso di conclusione anomala il valore restituito da
1009 \macro{WTERMSIG} può essere confrontato con le costanti definite in
1010 \file{signal.h} ed elencate in \tabref{tab:sig_signal_list}, e stampato usando
1011 le apposite funzioni trattate in \secref{sec:sig_strsignal}.
1014 \subsection{Le funzioni \func{wait3} e \func{wait4}}
1015 \label{sec:proc_wait4}
1017 Linux, seguendo un'estensione di BSD, supporta altre due funzioni per la
1018 lettura dello stato di terminazione di un processo \func{wait3} e
1019 \func{wait4}, analoghe alle precedenti ma che prevedono un ulteriore
1020 parametro attraverso il quale il kernel può restituire al padre informazioni
1021 sulle risorse usate dal processo terminato e dai vari figli. I prototipi di
1022 queste funzioni, che diventano accessibili definendo la costante
1023 \macro{\_USE\_BSD}, sono:
1025 \headdecl{sys/times.h} \headdecl{sys/types.h} \headdecl{sys/wait.h}
1026 \headdecl{sys/resource.h}
1028 \funcdecl{pid\_t wait4(pid\_t pid, int * status, int options, struct rusage
1030 È identica a \func{waitpid} sia per comportamento che per i valori dei
1031 parametri, ma restituisce in \param{rusage} un sommario delle risorse usate
1034 \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
1035 Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
1036 ormai deprecata in favore di \func{wait4}.
1039 la struttura \type{rusage} è definita in \file{sys/resource.h}, e viene
1040 utilizzata anche dalla funzione \func{getrusage} (vedi
1041 \secref{sec:sys_resource_use}) per ottenere le risorse di sistema usate da un
1042 processo; la sua definizione è riportata in \figref{fig:sys_rusage_struct}.
1045 \subsection{Le funzioni \func{exec}}
1046 \label{sec:proc_exec}
1048 Abbiamo già detto che una delle modalità principali con cui si utilizzano i
1049 processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
1050 fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
1051 processo chiama una di queste funzioni esso viene completamente sostituito dal
1052 nuovo programma; il \acr{pid} del processo non cambia, dato che non viene
1053 creato un nuovo processo, la funzione semplicemente rimpiazza lo stack, lo
1054 heap, i dati ed il testo del processo corrente con un nuovo programma letto da
1057 Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
1058 famiglia di funzioni) che possono essere usate per questo compito, in realtà
1059 (come mostrato in \figref{fig:proc_exec_relat}), sono tutte un front-end a
1060 \func{execve}. Il prototipo di quest'ultima è:
1061 \begin{prototype}{unistd.h}
1062 {int execve(const char *filename, char *const argv[], char *const envp[])}
1063 Esegue il programma contenuto nel file \param{filename}.
1065 \bodydesc{La funzione ritorna solo in caso di errore, restituendo -1; nel
1066 qual caso \var{errno} può assumere i valori:
1068 \item[\macro{EACCES}] il file non è eseguibile, oppure il filesystem è
1069 montato in \cmd{noexec}, oppure non è un file normale o un interprete.
1070 \item[\macro{EPERM}] il file ha i bit \acr{suid} o \acr{sgid}, l'utente non
1071 è root, e o il processo viene tracciato, o il filesystem è montato con
1072 l'opzione \cmd{nosuid}.
1073 \item[\macro{ENOEXEC}] il file è in un formato non eseguibile o non
1074 riconosciuto come tale, o compilato per un'altra architettura.
1075 \item[\macro{ENOENT}] il file o una delle librerie dinamiche o l'interprete
1076 necessari per eseguirlo non esistono.
1077 \item[\macro{ETXTBSY}] L'eseguibile è aperto in scrittura da uno o più
1079 \item[\macro{EINVAL}] L'eseguibile ELF ha più di un segmento
1080 \macro{PF\_INTERP}, cioè chiede di essere eseguito da più di un
1082 \item[\macro{ELIBBAD}] Un interprete ELF non è in un formato
1085 ed inoltre anche \macro{EFAULT}, \macro{ENOMEM}, \macro{EIO},
1086 \macro{ENAMETOOLONG}, \macro{E2BIG}, \macro{ELOOP}, \macro{ENOTDIR},
1087 \macro{ENFILE}, \macro{EMFILE}.}
1090 La funzione \func{exec} esegue il file o lo script indicato da
1091 \var{filename}, passandogli la lista di argomenti indicata da \var{argv}
1092 e come ambiente la lista di stringhe indicata da \var{envp}; entrambe le
1093 liste devono essere terminate da un puntatore nullo. I vettori degli
1094 argomenti e dell'ambiente possono essere acceduti dal nuovo programma
1095 quando la sua funzione \func{main} è dichiarata nella forma
1096 \code{main(int argc, char *argv[], char *envp[])}.
1098 Le altre funzioni della famiglia servono per fornire all'utente una serie
1099 possibile di diverse interfacce per la creazione di un nuovo processo. I loro
1103 \funcdecl{int execl(const char *path, const char *arg, ...)}
1104 \funcdecl{int execv(const char *path, char *const argv[])}
1105 \funcdecl{int execle(const char *path, const char *arg, ..., char
1107 \funcdecl{int execlp(const char *file, const char *arg, ...)}
1108 \funcdecl{int execvp(const char *file, char *const argv[])}
1110 Sostituiscono l'immagine corrente del processo con quella indicata nel primo
1111 argomento. I parametri successivi consentono di specificare gli argomenti a
1112 linea di comando e l'ambiente ricevuti dal nuovo processo.
1114 \bodydesc{Queste funzioni ritornano solo in caso di errore, restituendo
1115 -1; nel qual caso \var{errno} andrà ad assumere i valori visti in
1116 precedenza per \func{execve}.}
1119 Per capire meglio le differenze fra le funzioni della famiglia si può fare
1120 riferimento allo specchietto riportato in \ntab. La prima differenza riguarda
1121 le modalità di passaggio dei parametri che poi andranno a costituire gli
1122 argomenti a linea di comando (cioè i valori di \var{argv} e \var{argc} visti
1123 dalla funzione \func{main} del programma chiamato).
1125 Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
1126 che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
1127 gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
1128 stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
1129 questo vettore \emph{deve} essere terminato da un puntatore nullo.
1131 Nel secondo caso le stringhe degli argomenti sono passate alla funzione come
1132 lista di puntatori, nella forma:
1133 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
1134 char *arg0, char *arg1, ..., char *argn, NULL
1136 che deve essere terminata da un puntatore nullo. In entrambi i casi vale la
1137 convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
1138 per indicare il nome del file che contiene il programma che verrà eseguito.
1143 \begin{tabular}[c]{|l|c|c|c||c|c|c|}
1145 \multicolumn{1}{|c|}{\textbf{Caratteristiche}} &
1146 \multicolumn{6}{|c|}{\textbf{Funzioni}} \\
1148 &\func{execl\ }&\func{execlp}&\func{execle}
1149 &\func{execv\ }& \func{execvp}& \func{execve} \\
1152 argomenti a lista &$\bullet$&$\bullet$&$\bullet$&&& \\
1153 argomenti a vettore &&&&$\bullet$&$\bullet$&$\bullet$\\
1155 filename completo &&$\bullet$&&&$\bullet$& \\
1156 ricerca su \var{PATH}&$\bullet$&&$\bullet$&$\bullet$&&$\bullet$ \\
1158 ambiente a vettore &&&$\bullet$&&&$\bullet$ \\
1159 uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\
1162 \caption{Confronto delle caratteristiche delle varie funzioni della
1163 famiglia \func{exec}.}
1164 \label{tab:proc_exec_scheme}
1167 La seconda differenza fra le funzioni riguarda le modalità con cui si
1168 specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si
1169 indicano le due funzioni che replicano il comportamento della shell nello
1170 specificare il comando da eseguire; quando il parametro \var{file} non
1171 contiene una \file{/} esso viene considerato come un nome di programma, e
1172 viene eseguita automaticamente una ricerca fra i file presenti nella lista di
1173 directory specificate dalla variabile di ambiente \var{PATH}. Il file che
1174 viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
1175 relativo a permessi di accesso insufficienti (cioè l'esecuzione della
1176 sottostante \func{execve} ritorna un \macro{EACCESS}), la ricerca viene
1177 proseguita nelle eventuali ulteriori directory indicate in \var{PATH}; solo se
1178 non viene trovato nessun altro file viene finalmente restituito
1181 Le altre quattro funzioni si limitano invece a cercare di eseguire il file
1182 indicato dal parametro \var{path}, che viene interpretato come il
1183 \textit{pathname} del programma.
1187 \includegraphics[width=13cm]{img/exec_rel}
1188 \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
1189 \label{fig:proc_exec_relat}
1192 La terza differenza è come viene passata la lista delle variabili di ambiente.
1193 Con lo mnemonico \code{e} vengono indicate quelle funzioni che necessitano di
1194 un vettore di parametri \var{envp[]} analogo a quello usato per gli argomenti
1195 a riga di comando (terminato quindi da un \macro{NULL}), le altre usano il
1196 valore della variabile \var{environ} (vedi \secref{sec:proc_environ}) del
1197 processo di partenza per costruire l'ambiente.
1199 Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da
1200 \func{exec} assume anche una serie di altre proprietà del processo chiamante;
1201 la lista completa è la seguente:
1203 \item il \textit{process id} (\acr{pid}) ed il \textit{parent process id}
1205 \item il \textit{real user id} ed il \textit{real group id} (vedi
1206 \secref{sec:proc_access_id}).
1207 \item i \textit{supplementary group id} (vedi \secref{sec:proc_access_id}).
1208 \item il \textit{session id} ed il \textit{process group id} (vedi
1209 \secref{sec:sess_xxx}).
1210 \item il terminale di controllo (vedi \secref{sec:sess_xxx}).
1211 \item il tempo restante ad un allarme (vedi \secref{sec:sig_alarm_abort}).
1212 \item la directory radice e la directory di lavoro corrente (vedi
1213 \secref{sec:file_work_dir}).
1214 \item la maschera di creazione dei file (\var{umask}, vedi
1215 \secref{sec:file_umask}) ed i \textit{lock} sui file (vedi
1216 \secref{sec:file_locking}).
1217 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
1218 \secref{sec:sig_sigmask}).
1219 \item i limiti sulle risorse (vedi \secref{sec:sys_resource_limit}).
1220 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
1221 \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:sys_cpu_times}).
1224 Inoltre i segnali che sono stati settati per essere ignorati nel processo
1225 chiamante mantengono lo stesso settaggio pure nel nuovo programma, tutti gli
1226 altri segnali vengono settati alla loro azione di default. Un caso speciale è
1227 il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN}, può anche
1228 non essere resettato a \macro{SIG\_DFL} (si veda \secref{sec:sig_gen_beha}).
1230 La gestione dei file aperti dipende dal valore che ha il flag di
1231 \textit{close-on-exec} (trattato in \secref{sec:file_fcntl}) per ciascun file
1232 descriptor. I file per cui è settato vengono chiusi, tutti gli altri file
1233 restano aperti. Questo significa che il comportamento di default è che i file
1234 restano aperti attraverso una \func{exec}, a meno di una chiamata esplicita a
1235 \func{fcntl} che setti il suddetto flag.
1237 Per le directory, lo standard POSIX.1 richiede che esse vengano chiuse
1238 attraverso una \func{exec}, in genere questo è fatto dalla funzione
1239 \func{opendir} (vedi \secref{sec:file_dir_read}) che effettua da sola il
1240 settaggio del flag di \textit{close-on-exec} sulle directory che apre, in
1241 maniera trasparente all'utente.
1243 Abbiamo detto che il \textit{real user id} ed il \textit{real group id}
1244 restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per
1245 l'\textit{effective user id} ed l'\textit{effective group id}, tranne quando
1246 il file che si va ad eseguire abbia o il \acr{suid} bit o lo \acr{sgid} bit
1247 settato, in questo caso l'\textit{effective user id} e l'\textit{effective
1248 group id} vengono settati rispettivamente all'utente o al gruppo cui il file
1249 appartiene (per i dettagli vedi \secref{sec:proc_perms}).
1251 Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
1252 condivise, viene lanciato il \textit{linker} dinamico \cmd{ld.so} prima del
1253 programma per caricare le librerie necessarie ed effettuare il link
1254 dell'eseguibile. Se il programma è in formato ELF per caricare le librerie
1255 dinamiche viene usato l'interprete indicato nel segmento \macro{PT\_INTERP},
1256 in genere questo è \file{/lib/ld-linux.so.1} per programmi linkati con le
1257 \emph{libc5}, e \file{/lib/ld-linux.so.2} per programmi linkati con le
1258 \emph{glibc}. Infine nel caso il file sia uno script esso deve iniziare con
1259 una linea nella forma \cmd{\#!/path/to/interpreter} dove l'interprete indicato
1260 deve esse un valido programma (binario, non un altro script) che verrà
1261 chiamato come se si fosse eseguito il comando \cmd{interpreter [arg]
1264 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
1265 basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo
1266 processo, con \func{exec} si avvia un nuovo programma, con \func{exit} e
1267 \func{wait} si effettua e verifica la conclusione dei programmi. Tutte le
1268 altre funzioni sono ausiliarie e servono la lettura e il settaggio dei vari
1269 parametri connessi ai processi.
1273 \section{Il controllo di accesso}
1274 \label{sec:proc_perms}
1276 In questa sezione esamineremo le problematiche relative al controllo di
1277 accesso dal punto di vista del processi; vedremo quali sono gli identificatori
1278 usati, come questi possono essere modificati nella creazione e nel lancio di
1279 nuovi processi, le varie funzioni per la loro manipolazione diretta e tutte le
1280 problematiche connesse ad una gestione accorta dei privilegi.
1283 \subsection{Gli identificatori del controllo di accesso}
1284 \label{sec:proc_access_id}
1286 Come accennato in \secref{sec:intro_multiuser} il modello base\footnote{in
1287 realtà già esistono estensioni di questo modello base, che lo rendono più
1288 flessibile e controllabile, come le \textit{capabilities}, le ACL per i file
1289 o il \textit{Mandatory Access Control} di SELinux.} di sicurezza di un
1290 sistema unix-like è fondato sui concetti di utente e gruppo, e sulla
1291 separazione fra l'amministratore (\textsl{root}, detto spesso anche
1292 \textit{superuser}) che non è sottoposto a restrizioni, ed il resto degli
1293 utenti, per i quali invece vengono effettuati i vari controlli di accesso.
1295 %Benché il sistema sia piuttosto semplice (è basato su un solo livello di
1296 % separazione) il sistema permette una
1297 %notevole flessibilità,
1299 Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
1300 identificatori univoci, lo \acr{uid} e il \acr{gid}; questi servono al kernel
1301 per identificare uno specifico utente o un gruppo di utenti, per poi poter
1302 controllare che essi siano autorizzati a compiere le operazioni richieste. Ad
1303 esempio in \secref{sec:file_access_control} vedremo come ad ogni file vengano
1304 associati un utente ed un gruppo (i suoi \textsl{proprietari}, indicati
1305 appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati dal
1306 kernel nella gestione dei permessi di accesso.
1308 Dato che tutte le operazioni del sistema vengono compiute dai processi, è
1309 evidente che per poter implementare un controllo sulle operazioni occorre
1310 anche poter identificare chi è che ha lanciato un certo programma, e pertanto
1311 anche a ciascun processo è associato un utente e a un gruppo.
1313 Un semplice controllo di una corrispondenza fra identificativi non garantisce
1314 però sufficiente flessibilità per tutti quei casi in cui è necessario poter
1315 disporre di privilegi diversi, o dover impersonare un altro utente per un
1316 limitato insieme di operazioni. Per questo motivo in generale tutti gli Unix
1317 prevedono che i processi abbiano almeno due gruppi di identificatori, chiamati
1318 rispettivamente \textit{real} ed \textit{effective}.
1323 \begin{tabular}[c]{|c|l|p{6.5cm}|}
1325 \textbf{Suffisso} & \textbf{Significato} & \textbf{Utilizzo} \\
1328 \acr{uid} & \textit{real user id} & indica l'utente che ha lanciato
1330 \acr{gid} & \textit{real group id} & indica il gruppo dell'utente
1331 che ha lanciato il programma \\
1333 \acr{euid} & \textit{effective user id} & indica l'utente usato
1334 dal programma nel controllo di accesso \\
1335 \acr{egid} & \textit{effective group id} & indica il gruppo
1336 usato dal programma nel controllo di accesso \\
1337 -- & \textit{supplementary group id} & indica i gruppi cui
1338 l'utente appartiene \\
1340 -- & \textit{saved user id} & copia dell'\acr{euid} iniziale\\
1341 -- & \textit{saved group id} & copia dell'\acr{egid} iniziale \\
1343 \acr{fsuid} & \textit{filesystem user id} & indica l'utente effettivo per
1345 \acr{fsgid} & \textit{filesystem group id} & indica il gruppo effettivo
1346 per il filesystem \\
1349 \caption{Identificatori di utente e gruppo associati a ciascun processo con
1350 indicazione dei suffissi usati dalle varie funzioni di manipolazione.}
1351 \label{tab:proc_uid_gid}
1354 Al primo gruppo appartengono il \textit{real user id} e il \textit{real group
1355 id}: questi vengono settati al login ai valori corrispondenti all'utente con
1356 cui si accede al sistema (e relativo gruppo di default). Servono per
1357 l'identificazione dell'utente e normalmente non vengono mai cambiati. In
1358 realtà vedremo (in \secref{sec:proc_setuid}) che è possibile modificarli, ma
1359 solo ad un processo che abbia i privilegi di amministratore; questa
1360 possibilità è usata ad esempio da \cmd{login} che, una volta completata la
1361 procedura di autenticazione, lancia una shell per la quale setta questi
1362 identificatori ai valori corrispondenti all'utente che entra nel sistema.
1364 Al secondo gruppo appartengono l'\textit{effective user id} e
1365 l'\textit{effective group id} (a cui si aggiungono gli eventuali
1366 \textit{supplementary group id} dei gruppi dei quali l'utente fa parte).
1367 Questi sono invece gli identificatori usati nella verifiche dei permessi del
1368 processo e per il controllo di accesso ai file (argomento affrontato in
1369 dettaglio in \secref{sec:file_perm_overview}).
1371 Questi identificatori normalmente sono identici ai corrispondenti del gruppo
1372 \textit{real} tranne nel caso in cui, come accennato in
1373 \secref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit
1374 \acr{suid} o \acr{sgid} settati (il significato di questi bit è affrontato in
1375 dettaglio in \secref{sec:file_suid_sgid}). In questo caso essi saranno settati
1376 all'utente e al gruppo proprietari del file. Questo consente, per programmi in
1377 cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
1378 di un'altro (o dell'amministratore).
1380 Come nel caso del \acr{pid} e del \acr{ppid} tutti questi identificatori
1381 possono essere letti dal processo attraverso delle opportune funzioni, i cui
1382 prototipi sono i seguenti:
1385 \headdecl{sys/types.h}
1386 \funcdecl{uid\_t getuid(void)} Restituisce il \textit{real user id} del
1389 \funcdecl{uid\_t geteuid(void)} Restituisce l'\textit{effective user id} del
1392 \funcdecl{gid\_t getgid(void)} Restituisce il \textit{real group id} del
1395 \funcdecl{gid\_t getegid(void)} Restituisce l'\textit{effective group id} del
1398 \bodydesc{Queste funzioni non riportano condizioni di errore.}
1401 In generale l'uso di privilegi superiori deve essere limitato il più
1402 possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
1403 un meccanismo che consenta ad un programma di rilasciare gli eventuali
1404 maggiori privilegi necessari, una volta che si siano effettuate le operazioni
1405 per i quali erano richiesti, e a poterli eventualmente recuperare in caso
1408 Questo in Linux viene fatto usando altri due gruppi di identificatori, il
1409 \textit{saved} ed il \textit{filesystem}, analoghi ai precedenti. Il primo
1410 gruppo è lo stesso usato in SVr4, e previsto dallo standard POSIX quando è
1411 definita la costante \macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a
1412 cuore la portabilità del programma su altri Unix è buona norma controllare
1413 sempre la disponibilità di queste funzioni controllando se questa costante è
1414 definita.} il secondo gruppo è specifico di Linux e viene usato per
1415 migliorare la sicurezza con NFS.
1417 Il \textit{saved user id} e il \textit{saved group id} sono copie
1418 dell'\textit{effective user id} e dell'\textit{effective group id} del
1419 processo padre, e vengono settati dalla funzione \func{exec} all'avvio del
1420 processo, come copie dell'\textit{effective user id} e dell'\textit{effective
1421 group id} dopo che questo sono stati settati tenendo conto di eventuali
1422 \acr{suid} o \acr{sgid}. Essi quindi consentono di tenere traccia di quale
1423 fossero utente e gruppo effettivi all'inizio dell'esecuzione di un nuovo
1426 Il \textit{filesystem user id} e il \textit{filesystem group id} sono
1427 un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
1428 (torneremo sull'argomento in \secref{sec:proc_setfsuid}). Essi sono una
1429 replica dei corrispondenti \textit{effective id}, ai quali si sostituiscono
1430 per tutte le operazioni di verifica dei permessi relativi ai file (trattate in
1431 \secref{sec:file_perm_overview}). Ogni cambiamento effettuato sugli
1432 \textit{effective id} viene automaticamente riportato su di essi, per cui in
1433 condizioni normali se ne può tranquillamente ignorare l'esistenza, in quanto
1434 saranno del tutto equivalenti ai precedenti.
1436 Uno specchietto riassuntivo, contenente l'elenco completo degli identificatori
1437 di utente e gruppo associati dal kernel ad ogni processo, è riportato in
1438 \tabref{tab:proc_uid_gid}.
1441 \subsection{Le funzioni \func{setuid} e \func{setgid}}
1442 \label{sec:proc_setuid}
1444 Le due funzioni che vengono usate per cambiare identità (cioè utente e gruppo
1445 di appartenenza) ad un processo sono rispettivamente \func{setuid} e
1446 \func{setgid}; come accennato in \secref{sec:proc_access_id} in Linux esse
1447 seguono la semantica POSIX che prevede l'esistenza del \textit{saved user id}
1448 e del \textit{saved group id}; i loro prototipi sono:
1451 \headdecl{sys/types.h}
1453 \funcdecl{int setuid(uid\_t uid)} Setta l'\textit{user id} del processo
1456 \funcdecl{int setgid(gid\_t gid)} Setta il \textit{group id} del processo
1459 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1460 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1463 Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
1464 la prima; la seconda si comporta esattamente allo stesso modo facendo
1465 riferimento al \textit{group id} invece che all'\textit{user id}. Gli
1466 eventuali \textit{supplementary group id} non vengono modificati.
1469 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
1470 l'\textit{effective user id} è zero (cioè è quello dell'amministratore di
1471 sistema) allora tutti gli identificatori (\textit{real}, \textit{effective}
1472 e \textit{saved}) vengono settati al valore specificato da \var{uid},
1473 altrimenti viene settato solo l'\textit{effective user id}, e soltanto se il
1474 valore specificato corrisponde o al \textit{real user id} o al \textit{saved
1475 user id}. Negli altri casi viene segnalato un errore (con \macro{EPERM}).
1477 Come accennato l'uso principale di queste funzioni è quello di poter
1478 consentire ad un programma con i bit \acr{suid} o \acr{sgid} settati di
1479 riportare l'\textit{effective user id} a quello dell'utente che ha lanciato il
1480 programma, effettuare il lavoro che non necessita di privilegi aggiuntivi, ed
1481 eventualmente tornare indietro.
1483 Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
1484 viene gestito l'accesso al file \file{/var/log/utmp}. In questo file viene
1485 registrato chi sta usando il sistema al momento corrente; chiaramente non può
1486 essere lasciato aperto in scrittura a qualunque utente, che potrebbe
1487 falsificare la registrazione. Per questo motivo questo file (e l'analogo
1488 \file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad
1489 un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad
1490 esempio tutti i programmi di terminale in X, o il programma \cmd{screen} che
1491 crea terminali multipli su una console) appartengono a questo gruppo ed hanno
1492 il bit \acr{sgid} settato.
1494 Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
1495 situazione degli identificatori è la seguente:
1498 \textit{real group id} &=& \textrm{\acr{gid} (del chiamante)} \\
1499 \textit{effective group id} &=& \textrm{\acr{utmp}} \\
1500 \textit{saved group id} &=& \textrm{\acr{utmp}}
1502 in questo modo, dato che l'\textit{effective group id} è quello giusto, il
1503 programma può accedere a \file{/var/log/utmp} in scrittura ed aggiornarlo. A
1504 questo punto il programma può eseguire una \code{setgid(getgid())} per settare
1505 l'\textit{effective group id} a quello dell'utente (e dato che il \textit{real
1506 group id} corrisponde la funzione avrà successo), in questo modo non sarà
1507 possibile lanciare dal terminale programmi che modificano detto file, in tal
1508 caso infatti la situazione degli identificatori sarebbe:
1511 \textit{real group id} &=& \textrm{\acr{gid} (invariato)} \\
1512 \textit{effective group id} &=& \textrm{\acr{gid}} \\
1513 \textit{saved group id} &=& \textrm{\acr{utmp} (invariato)}
1515 e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
1516 \textit{effective group id}. All'uscita dal terminale, per poter di nuovo
1517 aggiornare lo stato di \file{/var/log/utmp} il programma eseguirà una
1518 \code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
1519 \acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
1520 in questo caso il valore richiesto corrisponde al \textit{saved group id} la
1521 funzione avrà successo e riporterà la situazione a:
1524 \textit{real group id} &=& \textrm{\acr{gid} (invariato)} \\
1525 \textit{effective group id} &=& \textrm{\acr{utmp}} \\
1526 \textit{saved group id} &=& \textrm{\acr{utmp} (invariato)}
1528 consentendo l'accesso a \file{/var/log/utmp}.
1530 Occorre però tenere conto che tutto questo non è possibile con un processo con
1531 i privilegi di root, in tal caso infatti l'esecuzione una \func{setuid}
1532 comporta il cambiamento di tutti gli identificatori associati al processo,
1533 rendendo impossibile riguadagnare i privilegi di amministratore. Questo
1534 comportamento è corretto per l'uso che ne fa \cmd{login} una volta che crea
1535 una nuova shell per l'utente; ma quando si vuole cambiare soltanto
1536 l'\textit{effective user id} del processo per cedere i privilegi occorre
1537 ricorrere ad altre funzioni (si veda ad esempio \secref{sec:proc_seteuid}).
1540 \subsection{Le funzioni \func{setreuid} e \func{setresuid}}
1541 \label{sec:proc_setreuid}
1543 Queste due funzioni derivano da BSD che, non supportando\footnote{almeno fino
1544 alla versione 4.3+BSD TODO, FIXME verificare e aggiornare la nota.} i
1545 \textit{saved id}, le usava per poter scambiare fra di loro \textit{effective}
1546 e \textit{real id}. I loro prototipi sono:
1549 \headdecl{sys/types.h}
1551 \funcdecl{int setreuid(uid\_t ruid, uid\_t euid)} Setta il \textit{real user
1552 id} e l'\textit{effective user id} del processo corrente ai valori
1553 specificati da \var{ruid} e \var{euid}.
1555 \funcdecl{int setregid(gid\_t rgid, gid\_t egid)} Setta il \textit{real group
1556 id} e l'\textit{effective group id} del processo corrente ai valori
1557 specificati da \var{rgid} e \var{egid}.
1559 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1560 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1563 I processi non privilegiati possono settare i \textit{real id} soltanto ai
1564 valori dei loro \textit{effective id} o \textit{real id} e gli
1565 \textit{effective id} ai valori dei loro \textit{real id}, \textit{effective
1566 id} o \textit{saved id}; valori diversi comportano il fallimento della
1567 chiamata; l'amministratore invece può specificare un valore qualunque.
1568 Specificando un valore di -1 l'identificatore corrispondente viene lasciato
1571 Con queste funzione si possono scambiare fra loro \textit{real id} e
1572 \textit{effective id}, e pertanto è possibile implementare un comportamento
1573 simile a quello visto in precedenza per \func{setgid}, cedendo i privilegi con
1574 un primo scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un
1577 In questo caso però occorre porre molta attenzione quando si creano nuovi
1578 processi nella fase intermedia in cui si sono scambiati gli identificatori, in
1579 questo caso infatti essi avranno un \textit{real id} privilegiato, che dovrà
1580 essere esplicitamente eliminato prima di porre in esecuzione un nuovo
1581 programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork}, e
1582 prima della \func{exec} per uniformare i \textit{real id} agli
1583 \textit{effective id}) in caso contrario quest'ultimo potrebbe a sua volta
1584 effettuare uno scambio e riottenere privilegi non previsti.
1586 Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
1587 si porrebbe per i \textit{saved id}: queste funzioni derivano da
1588 un'implementazione che non ne prevede la presenza, e quindi non è possibile
1589 usarle per correggere la situazione come nel caso precedente. Per questo
1590 motivo in Linux tutte le volte che tali funzioni vengono usate per modificare
1591 uno degli identificatori ad un valore diverso dal \textit{real id} precedente,
1592 il \textit{saved id} viene sempre settato al valore dell'\textit{effective
1597 \subsection{Le funzioni \func{seteuid} e \func{setegid}}
1598 \label{sec:proc_seteuid}
1600 Queste funzioni sono un'estensione allo standard POSIX.1 (ma sono comunque
1601 supportate dalla maggior parte degli Unix) e usate per cambiare gli
1602 \textit{effective id}; i loro prototipi sono:
1605 \headdecl{sys/types.h}
1607 \funcdecl{int seteuid(uid\_t uid)} Setta l'\textit{effective user id} del
1608 processo corrente a \var{uid}.
1610 \funcdecl{int setegid(gid\_t gid)} Setta l'\textit{effective group id} del
1611 processo corrente a \var{gid}.
1613 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1614 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1617 Gli utenti normali possono settare l'\textit{effective id} solo al valore del
1618 \textit{real id} o del \textit{saved id}, l'amministratore può specificare
1619 qualunque valore. Queste funzioni sono usate per permettere a root di settare
1620 solo l'\textit{effective id}, dato che l'uso normale di \func{setuid} comporta
1621 il settaggio di tutti gli identificatori.
1624 \subsection{Le funzioni \func{setresuid} e \func{setresgid}}
1625 \label{sec:proc_setresuid}
1627 Queste due funzioni sono un'estensione introdotta in Linux dal kernel 2.1.44,
1628 e permettono un completo controllo su tutti gli identificatori (\textit{real},
1629 \textit{effective} e \textit{saved}), i prototipi sono:
1632 \headdecl{sys/types.h}
1634 \funcdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} Setta il
1635 \textit{real user id}, l'\textit{effective user id} e il \textit{saved user
1636 id} del processo corrente ai valori specificati rispettivamente da
1637 \var{ruid}, \var{euid} e \var{suid}.
1639 \funcdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} Setta il
1640 \textit{real group id}, l'\textit{effective group id} e il \textit{saved group
1641 id} del processo corrente ai valori specificati rispettivamente da
1642 \var{rgid}, \var{egid} e \var{sgid}.
1644 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1645 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1648 I processi non privilegiati possono cambiare uno qualunque degli
1649 identificatori usando uno qualunque dei valori correnti di \textit{real id},
1650 \textit{effective id} o \textit{saved id}, l'amministratore può specificare i
1651 valori che vuole; un valore di -1 per un qualunque parametro lascia inalterato
1652 l'identificatore corrispondente.
1654 Per queste funzioni esistono anche due controparti che permettono di leggere
1655 in blocco i vari identificatori: \func{getresuid} e \func{getresgid}; i loro
1659 \headdecl{sys/types.h}
1661 \funcdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)} Legge il
1662 \textit{real user id}, l'\textit{effective user id} e il \textit{saved user
1663 id} del processo corrente.
1665 \funcdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)} Legge il
1666 \textit{real group id}, l'\textit{effective group id} e il \textit{saved group
1667 id} del processo corrente.
1669 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
1670 fallimento: l'unico errore possibile è \macro{EFAULT} se gli indirizzi delle
1671 variabili di ritorno non sono validi.}
1674 Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
1675 nessun privilegio. I valori sono restituiti negli argomenti, che vanno
1676 specificati come puntatori (è un'altro esempio di \textit{value result
1677 argument}). Si noti che queste funzioni sono le uniche in grado di leggere i
1681 \subsection{Le funzioni \func{setfsuid} e \func{setfsgid}}
1682 \label{sec:proc_setfsuid}
1684 Queste funzioni sono usate per settare gli identificatori usati da Linux per
1685 il controllo dell'accesso ai file. Come già accennato in
1686 \secref{sec:proc_access_id} in Linux è definito questo ulteriore gruppo di
1687 identificatori, che di norma sono assolutamente equivalenti agli
1688 \textit{effective id}, dato che ogni cambiamento di questi ultimi viene
1689 immediatamente riportato sui \textit{filesystem id}.
1691 C'è un solo caso in cui si ha necessità di introdurre una differenza fra
1692 \textit{effective id} e \textit{filesystem id}, ed è per ovviare ad un
1693 problema di sicurezza che si presenta quando si deve implementare un server
1694 NFS. Il server NFS infatti deve poter cambiare l'identificatore con cui accede
1695 ai file per assumere l'identità del singolo utente remoto, ma se questo viene
1696 fatto cambiando l'\textit{effective id} o il \textit{real id} il server si
1697 espone alla ricezione di eventuali segnali ostili da parte dell'utente di cui
1698 ha temporaneamente assunto l'identità. Cambiando solo il \textit{filesystem
1699 id} si ottengono i privilegi necessari per accedere ai file, mantenendo
1700 quelli originari per quanto riguarda tutti gli altri controlli di accesso,
1701 così che l'utente non possa inviare segnali al server NFS.
1703 Le due funzioni usate per cambiare questi identificatori sono \func{setfsuid}
1704 e \func{setfsgid}, ovviamente sono specifiche di Linux e non devono essere
1705 usate se si intendono scrivere programmi portabili; i loro prototipi sono:
1707 \headdecl{sys/fsuid.h}
1709 \funcdecl{int setfsuid(uid\_t fsuid)} Setta il \textit{filesystem user id} del
1710 processo corrente a \var{fsuid}.
1712 \funcdecl{int setfsgid(gid\_t fsgid)} Setta l'\textit{filesystem group id} del
1713 processo corrente a \var{fsgid}.
1715 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1716 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1718 \noindent queste funzioni hanno successo solo se il processo chiamante ha i
1719 privilegi di amministratore o, per gli altri utenti, se il valore specificato
1720 coincide con uno dei \textit{real}, \textit{effective} o \textit{saved id}.
1723 \subsection{Le funzioni \func{setgroups} e \func{getgroups}}
1724 \label{sec:proc_setgroups}
1726 Le ultime funzioni che esamineremo sono quelle che permettono di operare sui
1727 gruppi supplementari. Ogni processo può avere fino a \macro{NGROUPS\_MAX}
1728 gruppi supplementari in aggiunta al gruppo primario, questi vengono ereditati
1729 dal processo padre e possono essere cambiati con queste funzioni.
1731 La funzione che permette di leggere i gruppi supplementari è \func{getgroups};
1732 questa funzione è definita nello standard POSIX ed il suo prototipo è:
1734 \headdecl{sys/types.h}
1737 \funcdecl{int getgroups(int size, gid\_t list[])} Legge gli identificatori
1738 dei gruppi supplementari del processo sul vettore \param{list} di dimensione
1741 \bodydesc{La funzione restituisce il numero di gruppi letti in caso di
1742 successo e -1 in caso di fallimento, nel qual caso \var{errno} viene
1745 \item[\macro{EFAULT}] \param{list} non ha un indirizzo valido.
1746 \item[\macro{EINVAL}] il valore di \param{size} è diverso da zero ma
1747 minore del numero di gruppi supplementari del processo.
1750 \noindent non è specificato se la funzione inserisca o meno nella lista
1751 l'\textit{effective user id} del processo. Se si specifica un valore di
1752 \param{size} uguale a 0 \param{list} non viene modificato, ma si ottiene il
1753 numero di gruppi supplementari.
1755 Una seconda funzione, \func{getgrouplist}, può invece essere usata per
1756 ottenere tutti i gruppi a cui appartiene un utente; il suo prototipo è:
1758 \headdecl{sys/types.h}
1761 \funcdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups,
1762 int *ngroups)} Legge i gruppi supplementari dell'utente \param{user}.
1764 \bodydesc{La funzione legge fino ad un massimo di \param{ngroups} valori,
1765 restituisce 0 in caso di successo e -1 in caso di fallimento.}
1767 \noindent la funzione esegue una scansione del database dei gruppi (si veda
1768 \secref{sec:sys_user_group}) e ritorna in \param{groups} la lista di quelli a
1769 cui l'utente appartiene. Si noti che \param{ngroups} è passato come puntatore
1770 perché qualora il valore specificato sia troppo piccolo la funzione ritorna
1771 -1, passando indietro il numero dei gruppi trovati.
1773 Per settare i gruppi supplementari di un processo ci sono due funzioni, che
1774 possono essere usate solo se si hanno i privilegi di amministratore. La prima
1775 delle due è \func{setgroups}, ed il suo prototipo è:
1777 \headdecl{sys/types.h}
1780 \funcdecl{int setgroups(size\_t size, gid\_t *list)} Setta i gruppi
1781 supplementari del processo ai valori specificati in \param{list}.
1783 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1784 fallimento, nel qual caso \var{errno} viene settata a:
1786 \item[\macro{EFAULT}] \param{list} non ha un indirizzo valido.
1787 \item[\macro{EPERM}] il processo non ha i privilegi di amministratore.
1788 \item[\macro{EINVAL}] il valore di \param{size} è maggiore del valore
1789 massimo (\macro{NGROUPS}, che per Linux è 32).
1793 Se invece si vogliono settare i gruppi supplementari del processo a quelli di
1794 un utente specifico, si può usare \func{initgroups} il cui prototipo è:
1796 \headdecl{sys/types.h}
1799 \funcdecl{int initgroups(const char *user, gid\_t group)} Setta i gruppi
1800 supplementari del processo a quelli di cui è membro l'utente \param{user},
1801 aggiungendo il gruppo addizionale \param{group}.
1803 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1804 fallimento, nel qual caso \var{errno} viene settata agli stessi valori di
1805 \func{setgroups} più \macro{ENOMEM} quando non c'è memoria sufficiente per
1806 allocare lo spazio per informazioni dei gruppi.}
1809 La funzione esegue la scansione del database dei gruppi (usualmente
1810 \file{/etc/groups}) cercando i gruppi di cui è membro \param{user} e
1811 costruendo una lista di gruppi supplementari a cui aggiunge \param{group}, che
1812 poi setta usando \func{setgroups}.
1814 Si tenga presente che sia \func{setgroups} che \func{initgroups} non sono
1815 definite nello standard POSIX.1 e che pertanto non è possibile utilizzarle
1816 quando si definisce \macro{\_POSIX\_SOURCE} o si compila con il flag
1820 \section{La gestione della priorità di esecuzione}
1821 \label{sec:proc_priority}
1823 In questa sezione tratteremo più approfonditamente i meccanismi con il quale
1824 lo \textit{scheduler} assegna la CPU ai vari processi attivi. In particolare
1825 prenderemo in esame i vari meccanismi con cui viene gestita l'assegnazione del
1826 tempo di CPU, ed illustreremo le varie funzioni di gestione.
1829 \subsection{I meccanismi di \textit{scheduling}}
1830 \label{sec:proc_sched}
1832 La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
1833 il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
1834 ed oggetto di numerose ricerche; in generale essa dipende in maniera
1835 essenziale anche dal tipo di utilizzo che deve essere fatto del sistema, per
1836 cui non esiste un meccanismo che sia valido per tutti gli usi.
1838 La caratteristica specifica di un sistema multitasking come Linux è quella del
1839 cosiddetto \textit{prehemptive multitasking}: questo significa che al
1840 contrario di altri sistemi (che usano invece il cosiddetto \textit{cooperative
1841 multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
1842 quando la CPU deve essere passata ad un altro processo. Come accennato in
1843 \secref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione
1844 apposita del kernel, lo \textit{scheduler}, il cui scopo è quello di
1845 distribuire al meglio il tempo di CPU fra i vari processi.
1847 La cosa è resa ancora più complicata dal fatto che con le architetture
1848 multi-processore si deve anche scegliere quale sia la CPU più opportuna da
1849 utilizzare.\footnote{nei processori moderni la presenza di ampie cache può
1850 rendere poco efficiente trasferire l'esecuzione di un processo da una CPU ad
1851 un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
1852 banale.} Tutto questo comunque appartiene alle sottigliezze
1853 dell'implementazione del kernel; dal punto di vista dei programmi che girano
1854 in user space, anche quando si hanno più processori (e dei processi che sono
1855 eseguiti davvero in contemporanea), le politiche di scheduling riguardano
1856 semplicemente l'allocazione della risorsa \textsl{tempo di esecuzione}, la cui
1857 assegnazione sarà governata dai meccanismi di scelta delle priorità che
1858 restano gli stessi indipendentemente dal numero di processori.
1860 Si tenga conto poi che i processi non devono solo eseguire del codice: ad
1861 esempio molto spesso saranno impegnati in operazioni di I/O, o potranno
1862 venire bloccati da un comando dal terminale, o sospesi per un certo periodo di
1863 tempo. In tutti questi casi la CPU diventa disponibile ed è compito dello
1864 kernel provvedere a mettere in esecuzione un altro processo.
1866 Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
1867 processo, in Linux un processo può trovarsi in uno degli stati riportati in
1868 \tabref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
1869 \textit{runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
1870 sia la sua priorità, un processo non potrà mai essere messo in esecuzione
1871 fintanto che esso si trova in uno qualunque degli altri stati.
1875 \begin{tabular}[c]{|p{3cm}|c|p{8cm}|}
1877 \textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
1880 \textbf{Runnable} & \texttt{R} & Il processo è in esecuzione o è pronto ad
1881 essere eseguito (cioè è in attesa che gli venga assegnata la CPU). \\
1882 \textbf{Sleep} & \texttt{S} & Il processo processo è in attesa di un
1883 risposta dal sistema, ma può essere interrotto da un segnale. \\
1884 \textbf{Uninterrutible Sleep} & \texttt{D} & Il processo è in
1885 attesa di un risposta dal sistema (in genere per I/O), e non può essere
1886 interrotto in nessuna circostanza. \\
1887 \textbf{Stopped} & \texttt{T} & Il processo è stato fermato con un
1888 \macro{SIGSTOP}, o è tracciato.\\
1889 \textbf{Zombie} & \texttt{Z} & Il processo è terminato ma il suo stato di
1890 terminazione non è ancora stato letto dal padre. \\
1893 \caption{Elenco dei possibili stati di un processo in Linux, nella colonna
1894 \texttt{STAT} si è riportata la corrispondente lettera usata dal comando
1895 \cmd{ps} nell'omonimo campo.}
1896 \label{tab:proc_proc_states}
1899 Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
1900 risorse che sono necessarie per l'esecuzione di un programma, e a seconda
1901 dello scopo del programma non è detto neanche che sia la più importante (molti
1902 programmi dipendono in maniera molto più critica dall'I/O). Per questo motivo
1903 non è affatto detto che dare ad un programma la massima priorità di esecuzione
1904 abbia risultati significativi in termini di prestazioni.
1906 Il meccanismo tradizionale di scheduling di Unix (che tratteremo in
1907 \secref{sec:proc_sched_stand}) è sempre stato basato su delle \textsl{priorità
1908 dinamiche}, in modo da assicurare che tutti i processi, anche i meno
1909 importanti, possano ricevere un po' di tempo di CPU. In sostanza quando un
1910 processo ottiene la CPU la sua priorità viene diminuita. In questo modo alla
1911 fine, anche un processo con priorità iniziale molto bassa, finisce per avere
1912 una priorità sufficiente per essere eseguito.
1914 Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
1915 assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
1916 alla normale priorità dinamica), per tenere conto dei sistemi
1917 real-time,\footnote{per sistema real-time si intende un sistema in grado di
1918 eseguire operazioni in un tempo ben determinato; in genere si tende a
1919 distinguere fra l'\textit{hard real-time} in cui è necessario che i tempi di
1920 esecuzione di un programma siano determinabili con certezza assoluta (come
1921 nel caso di meccanismi di controllo di macchine, dove uno sforamento dei
1922 tempi avrebbe conseguenze disastrose), e \textit{soft-real-time} in cui un
1923 occasionale sforamento è ritenuto accettabile.} in cui è vitale che i
1924 processi che devono essere eseguiti in un determinato momento non debbano
1925 aspettare la conclusione di altri che non hanno questa necessità.
1927 Il concetto di priorità assoluta dice che quando due processi si contendono
1928 l'esecuzione, vince sempre quello con la priorità assoluta più alta, anche
1929 quando l'altro è in esecuzione (grazie al \textit{prehemptive scheduling}).
1930 Ovviamente questo avviene solo per i processi che sono pronti per essere
1931 eseguiti (cioè nello stato \textit{runnable}). La priorità assoluta viene in
1932 genere indicata con un numero intero, ed un valore più alto comporta una
1933 priorità maggiore. Su questa politica di scheduling torneremo in
1934 \secref{sec:proc_real_time}.
1936 In generale quello che succede in tutti gli Unix moderni è che ai processi
1937 normali viene sempre data una priorità assoluta pari a zero, e la decisione di
1938 assegnazione della CPU è fatta solo con il meccanismo tradizionale della
1939 priorità dinamica. In Linux tuttavia è possibile assegnare anche una priorità
1940 assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di
1941 priorità inferiore, che saranno eseguiti solo quando quest'ultimo non avrà
1945 \subsection{Il meccanismo di \textit{scheduling} standard}
1946 \label{sec:proc_sched_stand}
1948 A meno che non si abbiano esigenze specifiche, l'unico meccanismo di
1949 scheduling con il quale si avrà a che fare è quello tradizionale, che prevede
1950 solo priorità dinamiche. È di questo che, di norma, ci si dovrà preoccupare
1951 nella programmazione.
1953 Come accennato in Linux tutti i processi ordinari hanno la stessa priorità
1954 assoluta. Quello che determina quale, fra tutti i processi in attesa di
1955 esecuzione, sarà eseguito per primo, è la priorità dinamica, che è chiamata
1956 così proprio perché varia nel corso dell'esecuzione di un processo. Oltre a
1957 questo la priorità dinamica determina quanto a lungo un processo continuerà ad
1958 essere eseguito, e quando un processo potrà subentrare ad un altro
1961 Il meccanismo usato da Linux è piuttosto semplice, ad ogni processo è
1962 assegnata una \textit{time-slice}, cioè in intervallo di tempo (letteralmente
1963 una fetta) per il quale esso deve essere eseguito. Il valore della
1964 \textit{time-slice} è controllato dalla cosiddetta \textit{nice} (o
1965 \textit{niceness}) del processo. Essa è contenuta nel campo \var{nice} di
1966 \var{task\_struct}; tutti i processi vengono creati con lo stesso valore, ed
1967 essa specifica il valore della durata iniziale della \textit{time-slice} che
1968 viene assegnato ad un altro campo della struttura (\var{counter}) quando il
1969 processo viene eseguito per la prima volta e diminuito progressivamente ad
1970 ogni interruzione del timer.
1972 Quando lo scheduler viene eseguito scandisce la coda dei processi in stato
1973 \textit{runnable} associando, sulla base del valore di \var{counter}, un peso
1974 a ciascun processo in attesa di esecuzione,\footnote{il calcolo del peso in
1975 realtà è un po' più complicato, ad esempio nei sistemi multiprocessore viene
1976 favorito un processo che è eseguito sulla stessa CPU, e a parità del valore
1977 di \var{counter} viene favorito chi ha una priorità più elevata.} chi ha il
1978 peso più alto verrà posto in esecuzione, ed il precedente processo sarà
1979 spostato in fondo alla coda. Dato che ad ogni interruzione del timer il
1980 valore di \var{counter} del processo corrente viene diminuito, questo assicura
1981 che anche i processi con priorità più bassa verranno messi in esecuzione.
1983 La priorità di un processo è così controllata attraverso il valore di
1984 \var{nice}, che stabilisce la durata della \textit{time-slice}; per il
1985 meccanismo appena descritto infatti un valore più lungo infatti assicura una
1986 maggiore attribuzione di CPU. L'origine del nome di questo parametro sta nel
1987 fatto che in genere esso viene generalmente usato per diminuire la priorità di
1988 un processo, come misura di cortesia nei confronti degli altri.
1990 I processi infatti vengono creati dal sistema con lo stesso valore di
1991 \var{nice} (nullo) e nessuno è privilegiato rispetto agli altri; il valore può
1992 essere modificato solo attraverso la funzione \func{nice}, il cui prototipo è:
1993 \begin{prototype}{unistd.h}
1995 Aumenta il valore di \var{nice} per il processo corrente.
1997 \bodydesc{La funzione ritorna zero in caso di successo e -1 in caso di
1998 errore, nel qual caso \var{errno} può assumere i valori:
2000 \item[\macro{EPERM}] un processo senza i privilegi di amministratore ha
2001 specificato un valore di \param{inc} negativo.
2005 L'argomento \param{inc} indica l'incremento del valore di \var{nice}:
2006 quest'ultimo può assumere valori compresi fra \macro{PRIO\_MIN} e
2007 \macro{PRIO\_MAX} (che nel caso di Linux sono $-19$ e $20$), ma per
2008 \param{inc} si può specificare un valore qualunque, positivo o negativo, ed il
2009 sistema provvederà a troncare il risultato nell'intervallo consentito. Valori
2010 positivi comportano maggiore \textit{cortesia} e cioè una diminuzione della
2011 priorità, ogni utente può solo innalzare il valore di un suo processo. Solo
2012 l'amministratore può specificare valori negativi che permettono di aumentare
2013 la priorità di un processo.
2015 In SUSv2 la funzione ritorna il nuovo valore di \var{nice}; Linux non segue
2016 questa convenzione, e per leggere il nuovo valore occorre invece usare la
2017 funzione \func{getpriority}, derivata da BSD, il cui prototipo è:
2018 \begin{prototype}{sys/resource.h}
2019 {int getpriority(int which, int who)}
2021 Restituisce il valore di \var{nice} per l'insieme dei processi specificati.
2023 \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
2024 errore, nel qual caso \var{errno} può assumere i valori:
2026 \item[\macro{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2027 \param{which} e \param{who}.
2028 \item[\macro{EINVAL}] il valore di \param{which} non è valido.
2031 \noindent (in vecchie versioni può essere necessario includere anche
2032 \file{<sys/time.h>}, questo non è più necessario con versioni recenti delle
2033 librerie, ma è comunque utile per portabilità).
2035 La funzione permette di leggere la priorità di un processo, di un gruppo di
2036 processi (vedi \secref{sec:sess_proc_group}) o di un utente, a seconda del
2037 valore di \param{which}, secondo la legenda di \tabref{tab:proc_getpriority},
2038 specificando un corrispondente valore per \param{who}; un valore nullo di
2039 quest'ultimo indica il processo, il gruppo di processi o l'utente correnti.
2044 \begin{tabular}[c]{|c|c|l|}
2046 \param{which} & \param{who} & \textbf{Significato} \\
2049 \macro{PRIO\_PROCESS} & \type{pid\_t} & processo \\
2050 \macro{PRIO\_PRGR} & \type{pid\_t} & process group \\
2051 \macro{PRIO\_USER} & \type{uid\_t} & utente \\
2054 \caption{Legenda del valore dell'argomento \param{which} e del tipo
2055 dell'argomento \param{who} delle funzioni \func{getpriority} e
2056 \func{setpriority} per le tre possibili scelte.}
2057 \label{tab:proc_getpriority}
2060 La funzione restituisce la priorità più alta (cioè il valore più basso) fra
2061 quelle dei processi specificati; dato che -1 è un valore possibile, per poter
2062 rilevare una condizione di errore è necessario cancellare sempre \var{errno}
2063 prima della chiamata alla funzione, per verificare che essa resti uguale a
2066 Analoga a \func{getpriority} la funzione \func{setpriority} permette di
2067 settare la priorità di uno o più processi; il suo prototipo è:
2068 \begin{prototype}{sys/resource.h}
2069 {int setpriority(int which, int who, int prio)}
2070 Setta la priorità per l'insieme dei processi specificati.
2072 \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
2073 errore, nel qual caso \var{errno} può assumere i valori:
2075 \item[\macro{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2076 \param{which} e \param{who}.
2077 \item[\macro{EINVAL}] il valore di \param{which} non è valido.
2078 \item[\macro{EPERM}] un processo senza i privilegi di amministratore ha
2079 specificato un valore di \param{inc} negativo.
2080 \item[\macro{EACCESS}] un processo senza i privilegi di amministratore ha
2081 cercato di modificare la priorità di un processo di un altro utente.
2085 La funzione setta la priorità al valore specificato da \param{prio} per tutti
2086 i processi indicati dagli argomenti \param{which} e \param{who}. La gestione
2087 dei permessi dipende dalle varie implementazioni; in Linux, secondo le
2088 specifiche dello standard SUSv3, e come avviene per tutti i sistemi che
2089 derivano da SYSV, è richiesto che il real o l'effective user id del processo
2090 chiamante corrispondano al real user id (e solo quello) del processo di cui si
2091 vuole cambiare la priorità; per i sistemi derivati da BSD invece (SunOS,
2092 Ultrix, *BSD) la corrispondenza può essere anche con l'effective user id.
2096 \subsection{Il meccanismo di \textit{scheduling real-time}}
2097 \label{sec:proc_real_time}
2099 Come spiegato in \secref{sec:proc_sched} lo standard POSIX.1b ha introdotto le
2100 priorità assolute per permettere la gestione di processi real-time. In realtà
2101 nel caso di Linux non si tratta di un vero hard real-time, in quanto in
2102 presenza di eventuali interrupt il kernel interrompe l'esecuzione di un
2103 processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
2104 siano installate le patch di RTLinux o RTAI, con i quali è possibile
2105 ottenere un sistema effettivamente hard real-time. In tal caso infatti gli
2106 interrupt vengono intercettati dall'interfaccia real-time, e gestiti
2107 direttamente qualora ci sia la necessità di avere un processo con priorità
2108 più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
2109 page fault\index{page fault} si possono avere ritardi non previsti. Se
2110 l'ultimo problema può essere aggirato attraverso l'uso delle funzioni di
2111 controllo della memoria virtuale (vedi \secref{sec:proc_mem_lock}), il primo
2112 non è superabile e può comportare ritardi non prevedibili riguardo ai tempi di
2113 esecuzione di qualunque processo.
2115 In ogni caso occorre usare le priorità assolute con molta attenzione: se si dà
2116 ad un processo una priorità assoluta e questo finisce in un loop infinito,
2117 nessun altro processo potrà essere eseguito, ed esso sarà mantenuto in
2118 esecuzione permanentemente assorbendo tutta la CPU e senza nessuna possibilità
2119 di riottenere l'accesso al sistema. Per questo motivo è sempre opportuno,
2120 quando si lavora con processi che usano priorità assolute, tenere attiva una
2121 shell cui si sia assegnata la massima priorità assoluta, in modo da poter
2122 essere comunque in grado di rientrare nel sistema.
2124 Quando c'è un processo con priorità assoluta lo scheduler lo metterà in
2125 esecuzione prima di ogni processo normale. In caso di più processi sarà
2126 eseguito per primo quello con priorità assoluta più alta. Quando ci sono più
2127 processi con la stessa priorità assoluta questi vengono tenuti in una coda
2128 tocca al kernel decidere quale deve essere eseguito.
2132 Il meccanismo con cui vengono gestiti questi processi dipende dalla politica
2133 di scheduling che si è scelto; lo standard ne prevede due:
2134 \begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
2135 \item[\textit{FIFO}] il processo viene eseguito fintanto che non cede
2136 volontariamente la CPU, si blocca, finisce o viene interrotto da un processo
2137 a priorità più alta.
2138 \item[\textit{Round Robin}] ciascun processo viene eseguito a turno per un
2139 certo periodo di tempo (una \textit{time slice}). Solo i processi con la
2140 stessa priorità ed in stato \textit{runnable} entrano nel circolo.
2143 La funzione per settare le politiche di scheduling (sia real-time che
2144 ordinarie) ed i relativi parametri è \func{sched\_setscheduler}; il suo
2146 \begin{prototype}{sched.h}
2147 {int sched\_setscheduler(pid\_t pid, int policy, const struct sched\_param *p)}
2148 Setta priorità e politica di scheduling per il processo \param{pid}.
2150 \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
2151 errore, nel qual caso \var{errno} può assumere i valori:
2153 \item[\macro{ESRCH}] il processo \param{pid} non esiste.
2154 \item[\macro{EINVAL}] il valore di \param{policy} non esiste o il relativo
2155 valore di \param{p} non è valido.
2156 \item[\macro{EPERM}] il processo non ha i privilegi per attivare la
2157 politica richiesta (vale solo per \macro{SCHED\_FIFO} e
2162 La funzione esegue il settaggio per il processo specificato; un valore nullo
2163 di \param{pid} esegue il settaggio per il processo corrente, solo un processo
2164 con i privilegi di amministratore può settare delle priorità assolute diverse
2165 da zero. La politica di scheduling è specificata dall'argomento \param{policy}
2166 i cui possibili valori sono riportati in \tabref{tab:proc_sched_policy}; un
2167 valore negativo per \param{policy} mantiene la politica di scheduling
2173 \begin{tabular}[c]{|c|l|}
2175 \textbf{Policy} & \textbf{Significato} \\
2178 \macro{SCHED\_FIFO} & Scheduling real-time con politica \textit{FIFO} \\
2179 \macro{SCHED\_RR} & Scheduling real-time con politica \textit{Round
2181 \macro{SCHED\_OTHER}& Scheduling ordinario\\
2184 \caption{Valori dell'argomento \param{policy} per la funzione
2185 \func{sched\_setscheduler}. }
2186 \label{tab:proc_sched_policy}
2189 Il valore della priorità è passato attraverso la struttura \var{sched\_param}
2190 (riportata in \figref{fig:sig_sched_param}), il cui solo campo attualmente
2191 definito è \var{sched\_priority}, che nel caso delle priorità assolute deve
2192 essere specificato nell'intervallo fra 1 e 99 (il valore zero è legale, ma
2193 indica i processi normali). Lo standard POSIX.1b prevede comunque che questi
2194 due valori possano essere ottenuti per ciascuna politica di scheduling dalle
2195 funzioni \func{sched\_get\_priority\_max} e \func{sched\_get\_priority\_min},
2196 i cui prototipi sono:
2200 \funcdecl{int sched\_get\_priority\_max(int policy)} Legge il valore
2201 massimo della priorità statica per la politica di scheduling \param{policy}.
2204 \funcdecl{int sched\_get\_priority\_min(int policy)} Legge il valore minimo
2205 della priorità statica per la politica di scheduling \param{policy}.
2207 \bodydesc{La funzioni ritornano il valore della priorità in caso di successo
2208 e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
2210 \item[\macro{EINVAL}] il valore di \param{policy} è invalido.
2215 I processi con politica di scheduling \macro{SCHED\_OTHER} devono specificare
2216 un valore nullo (altrimenti si avrà un errore \macro{EINVAL}), questo valore
2217 infatti non ha niente a che vedere con la priorità dinamica determinata dal
2218 valore di \var{nice}, che deve essere settato con le funzioni viste in
2221 \begin{figure}[!htb]
2222 \footnotesize \centering
2223 \begin{minipage}[c]{15cm}
2224 \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
2225 struct sched_param {
2231 \caption{La struttura \var{sched\_param}.}
2232 \label{fig:sig_sched_param}
2235 Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed
2236 esegue sempre il primo della lista, mentre un nuovo processo che torna in
2237 stato \textit{runnable} viene sempre inserito in coda alla lista. Se la
2238 politica scelta è \macro{SCHED\_FIFO} quando il processo viene eseguito viene
2239 automaticamente rimesso in coda alla lista, e la sua esecuzione continua
2240 fintanto che non viene bloccato da una richiesta di I/O, o non rilascia
2241 volontariamente la CPU (in tal caso, tornando nello stato \textit{runnable}
2242 sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo
2243 nel caso che esso sia stato interrotto da un processo a priorità più alta.
2245 La priorità assoluta può essere riletta indietro dalla funzione
2246 \func{sched\_getscheduler}, il cui prototipo è:
2247 \begin{prototype}{sched.h}
2248 {int sched\_getscheduler(pid\_t pid)}
2249 Legge la politica di scheduling per il processo \param{pid}.
2251 \bodydesc{La funzione ritorna la politica di scheduling in caso di successo
2252 e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
2254 \item[\macro{ESRCH}] il processo \param{pid} non esiste.
2255 \item[\macro{EINVAL}] il valore di \param{pid} è negativo.
2259 La funzione restituisce il valore (secondo la quanto elencato in
2260 \tabref{tab:proc_sched_policy}) della politica di scheduling per il processo
2261 specificato; se \param{pid} è nullo viene restituito quello del processo
2264 Se si intende operare solo sulla priorità assoluta di un processo si possono
2265 usare le funzioni \func{sched\_setparam} e \func{sched\_getparam}, i cui
2271 \funcdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *p)}
2272 Setta la priorità assoluta del processo \param{pid}.
2275 \funcdecl{int sched\_getparam(pid\_t pid, struct sched\_param *p)}
2276 Legge la priorità assoluta del processo \param{pid}.
2278 \bodydesc{La funzione ritorna la priorità in caso di successo
2279 e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
2281 \item[\macro{ESRCH}] il processo \param{pid} non esiste.
2282 \item[\macro{EINVAL}] il valore di \param{pid} è negativo.
2286 L'uso di \func{sched\_setparam} che è del tutto equivalente a
2287 \func{sched\_setscheduler} con \param{priority} uguale a -1. Come per
2288 \func{sched\_setscheduler} specificando 0 come valore di \param{pid} si opera
2289 sul processo corrente. La disponibilità di entrambe le funzioni può essere
2290 verificata controllando la macro \macro{\_POSIX\_PRIORITY\_SCHEDULING} che è
2291 definita nell'header \macro{sched.h}.
2293 L'ultima funzione che permette di leggere le informazioni relative ai processi
2294 real-time è \func{sched\_rr\_get\_interval}, che permette di ottenere la
2295 lunghezza della \textit{time slice} usata dalla politica \textit{round robin};
2297 \begin{prototype}{sched.h}
2298 {int sched\_rr\_get\_interval(pid\_t pid, struct timespec *tp)} Legge in
2299 \param{tp} la durata della \textit{time slice} per il processo \param{pid}.
2301 \bodydesc{La funzione ritorna 0in caso di successo e -1 in caso di errore,
2302 nel qual caso \var{errno} può assumere i valori:
2304 \item[\macro{ESRCH}] il processo \param{pid} non esiste.
2305 \item[\macro{ENOSYS}] la system call non è stata implementata.
2309 La funzione restituisce il valore dell'intervallo di tempo usato per la
2310 politica \textit{round robin} in una struttura \var{timespec}, (la cui
2311 definizione si può trovare in \figref{fig:sys_timeval_struct}).
2314 Come accennato ogni processo che usa lo scheduling real-time può rilasciare
2315 volontariamente la CPU; questo viene fatto attraverso la funzione
2316 \func{sched\_yield}, il cui prototipo è:
2317 \begin{prototype}{sched.h}
2318 {int sched\_yield(void)}
2320 Rilascia volontariamente l'esecuzione.
2322 \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
2323 nel qual caso \var{errno} viene settata opportunamente.}
2326 La funzione fa si che il processo rilasci la CPU, in modo da essere rimesso in
2327 coda alla lista dei processi da eseguire, e permettere l'esecuzione di un
2328 altro processo; se però il processo è l'unico ad essere presente sulla coda
2329 l'esecuzione non sarà interrotta. In genere usano questa funzione i processi
2330 in modalità \textit{fifo}, per permettere l'esecuzione degli altri processi
2331 con pari priorità quando la sezione più urgente è finita.
2334 \section{Problematiche di programmazione multitasking}
2335 \label{sec:proc_multi_prog}
2337 Benché i processi siano strutturati in modo da apparire il più possibile come
2338 indipendenti l'uno dall'altro, nella programmazione in un sistema multitasking
2339 occorre tenere conto di una serie di problematiche che normalmente non
2340 esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
2341 programma alla volta.
2343 Pur essendo questo argomento di carattere generale, ci è parso opportuno
2344 introdurre sinteticamente queste problematiche, che ritroveremo a più riprese
2345 in capitoli successivi, in questa sezione conclusiva del capitolo in cui
2346 abbiamo affrontato la gestione dei processi.
2349 \subsection{Le operazioni atomiche}
2350 \label{sec:proc_atom_oper}
2352 La nozione di \textsl{operazione atomica} deriva dal significato greco della
2353 parola atomo, cioè indivisibile; si dice infatti che un'operazione è atomica
2354 quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi
2355 che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
2356 di interruzione in una fase intermedia.
2358 In un ambiente multitasking il concetto è essenziale, dato che un processo può
2359 essere interrotto in qualunque momento dal kernel che mette in esecuzione un
2360 altro processo o dalla ricezione di un segnale; occorre pertanto essere
2361 accorti nei confronti delle possibili
2362 \textit{race condition}\index{race condition} (vedi
2363 \secref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase in
2364 cui non erano ancora state completate.
2366 Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
2367 occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
2368 fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
2369 \capref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
2370 \secref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
2371 funzioni di libreria per compiere le operazioni necessarie è garanzia
2372 sufficiente di atomicità in quanto le system call con cui esse sono realizzate
2373 non possono essere interrotte (o subire interferenze pericolose) da altri
2376 Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
2377 stesso processo, e pure alcune system call, possono essere interrotti in
2378 qualunque momento, e le operazioni di un eventuale \textit{signal handler}
2379 sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
2380 il solo accesso o l'assegnazione di una variabile possono non essere più
2381 operazioni atomiche (torneremo su questi aspetti in
2382 \secref{sec:sig_control}).
2384 In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
2385 il cui accesso è assicurato essere atomico. In pratica comunque si può
2386 assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
2387 \ctyp{int}, gli altri interi di dimensione inferiore ed i puntatori sono
2388 atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
2389 maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
2390 le strutture. In tutti questi casi è anche opportuno marcare come
2391 \ctyp{volatile} le variabili che possono essere interessate ad accesso
2392 condiviso, onde evitare problemi con le ottimizzazioni del codice.
2396 \subsection{Le \textit{race condition}\index{race condition} e i
2398 \label{sec:proc_race_cond}
2400 Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
2401 diversi operano su una risorsa comune, ed in cui il risultato viene a
2402 dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso
2403 tipico è quello di un'operazione che viene eseguita da un processo in più
2404 passi, e può essere compromessa dall'intervento di un altro processo che
2405 accede alla stessa risorsa quando ancora non tutti i passi sono stati
2408 Dato che in un sistema multitasking ogni processo può essere interrotto in
2409 qualunque momento per farne subentrare un'altro in esecuzione, niente può
2410 assicurare un preciso ordine di esecuzione fra processi diversi o che una
2411 sezione di un programma possa essere eseguita senza interruzioni da parte di
2412 altri. Queste situazioni comportano pertanto errori estremamente subdoli e
2413 difficili da tracciare, in quanto nella maggior parte dei casi tutto
2414 funzionerà regolarmente, e solo occasionalmente si avranno degli errori.
2416 Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
2417 che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
2418 gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di
2419 \textit{race condition} si hanno quando diversi processi accedono allo stesso
2420 file, o nell'accesso a meccanismi di intercomunicazione come la memoria
2421 condivisa. In questi casi, se non si dispone della possibilità di eseguire
2422 atomicamente le operazioni necessarie, occorre che quelle parti di codice in
2423 cui si compiono le operazioni sulle risorse condivise (le cosiddette
2424 \textsl{sezioni critiche}) del programma, siano opportunamente protette da
2425 meccanismi di sincronizzazione (torneremo su queste problematiche di questo
2426 tipo in \secref{sec:ipc_semaph}).
2428 Un caso particolare di \textit{race condition} sono poi i cosiddetti
2429 \textit{deadlock}, particolarmente gravi in quanto comportano spesso il blocco
2430 completo di un servizio, e non il fallimento di una singola operazione.
2431 L'esempio tipico di una situazione che può condurre ad un \textit{deadlock} è
2432 quello in cui un flag di ``occupazione'' viene rilasciato da un evento
2433 asincrono (come un segnale o un altro processo) fra il momento in cui lo si è
2434 controllato (trovandolo occupato) e la successiva operazione di attesa per lo
2435 sblocco. In questo caso, dato che l'evento di sblocco del flag è avvenuto
2436 senza che ce ne accorgessimo proprio fra il controllo e la messa in attesa,
2437 quest'ultima diventerà perpetua (da cui il nome di \textit{deadlock}).
2439 In tutti questi casi è di fondamentale importanza il concetto di atomicità
2440 visto in \secref{sec:proc_atom_oper}; questi problemi infatti possono essere
2441 risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile
2442 eseguire in maniera atomica le operazioni necessarie.
2445 \subsection{Le funzioni rientranti}
2446 \label{sec:proc_reentrant}
2448 Si dice \textsl{rientrante} una funzione che può essere interrotta in
2449 qualunque punto della sua esecuzione ed essere chiamata una seconda volta da
2450 un altro thread di esecuzione senza che questo comporti nessun problema
2451 nell'esecuzione della stessa. La problematica è comune nella programmazione
2452 multi-thread, ma si hanno gli stessi problemi quando si vogliono chiamare
2453 delle funzioni all'interno dei manipolatori dei segnali.
2455 Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
2456 queste infatti vengono allocate nello stack, e un'altra invocazione non fa
2457 altro che allocarne un'altra copia. Una funzione può non essere rientrante
2458 quando opera su memoria che non è nello stack. Ad esempio una funzione non è
2459 mai rientrante se usa una variabile globale o statica.
2461 Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
2462 cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
2463 ogni volta e ritornato indietro la funzione può essere rientrante, se invece
2464 esso viene individuato dalla funzione stessa due chiamate alla stessa funzione
2465 potranno interferire quando entrambe faranno riferimento allo stesso oggetto.
2466 Allo stesso modo una funzione può non essere rientrante se usa e modifica un
2467 oggetto che le viene fornito dal chiamante: due chiamate possono interferire
2468 se viene passato lo stesso oggetto; in tutti questi casi occorre molta cura da
2469 parte del programmatore.
2471 In genere le funzioni di libreria non sono rientranti, molte di esse ad
2472 esempio utilizzano variabili statiche, le \acr{glibc} però mettono a
2473 disposizione due macro di compilatore, \macro{\_REENTRANT} e
2474 \macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di
2475 varie funzioni di libreria, che sono identificate aggiungendo il suffisso
2476 \code{\_r} al nome della versione normale.
2480 %%% Local Variables:
2482 %%% TeX-master: "gapil"