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 \figref{fig:proc_task_struct}.
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, fino al kernel 2.4.x,
223 sono definiti dalla macro \macro{PID\_MAX} in \file{threads.h} e
224 direttamente in \file{fork.c}, con il kernel 2.5.x e la nuova interfaccia
225 per i thread creata da Ingo Molnar anche il meccanismo di allocazione dei
226 \acr{pid} è stato modificato.} che serve a riservare i \acr{pid} più bassi
227 ai processi eseguiti dal direttamente dal kernel. Per questo motivo, come
228 visto in \secref{sec:proc_hierarchy}, il processo di avvio (\cmd{init}) ha
229 sempre il \acr{pid} uguale a uno.
231 Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
232 sono stati creati, questo viene chiamato in genere \acr{ppid} (da
233 \textit{parent process id}). Questi due identificativi possono essere
234 ottenuti da programma usando le funzioni:
236 \headdecl{sys/types.h} \headdecl{unistd.h} \funcdecl{pid\_t getpid(void)}
237 Restituisce il \acr{pid} del processo corrente. \funcdecl{pid\_t
238 getppid(void)} Restituisce il \acr{pid} del padre del processo corrente.
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_proc_group}, relativi al controllo di sessione), ad ogni
262 processo 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, identificatori) prima della \func{exec}, rendendo così
409 relativamente facile intervenire sulle le modalità di esecuzione del nuovo
412 In \figref{fig:proc_fork_code} si è riportato il corpo del codice del
413 programma di esempio \cmd{forktest}, che ci permette di illustrare molte
414 caratteristiche dell'uso della funzione \func{fork}. Il programma permette di
415 creare un numero di figli specificato da linea di comando, e prende anche
416 alcune opzioni per indicare degli eventuali tempi di attesa in secondi
417 (eseguiti tramite la funzione \func{sleep}) per il padre ed il figlio (con
418 \cmd{forktest -h} si ottiene la descrizione delle opzioni); il codice
419 completo, compresa la parte che gestisce le opzioni a riga di comando, è
420 disponibile nel file \file{ForkTest.c}, distribuito insieme agli altri
421 sorgenti degli esempi su \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 predefiniti 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} impostati
605 (vedi \secref{sec:proc_exec} e \secref{sec:file_fcntl}).
606 \item gli identificatori per il controllo di accesso: l'\textsl{userid reale},
607 il \textsl{groupid reale}, l'\textsl{userid effettivo}, il \textsl{groupid
608 effettivo} ed i \textit{groupid supplementari} (vedi
609 \secref{sec:proc_access_id}).
610 \item gli identificatori per il controllo di sessione: il \textit{process
611 groupid} e il \textit{session id} ed il terminale di controllo (vedi
612 \secref{sec:sess_proc_group}).
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_sysv_shm}).
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 \acr{pid} (\textit{process id}).
627 \item il \acr{ppid} (\textit{parent process id}), quello del figlio viene
628 impostato al \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 ed il suo terminale di controllo
695 è quello della sessione viene mandato un segnale di \macro{SIGHUP} a tutti i
696 processi del gruppo di foreground e il terminale di controllo viene
697 disconnesso (vedi \secref{sec:sess_ctrl_term}).
698 \item se la conclusione di un processo rende orfano un \textit{process
699 group} ciascun membro del gruppo viene bloccato, e poi gli vengono
700 inviati in successione i segnali \macro{SIGHUP} e \macro{SIGCONT}
701 (vedi ancora \secref{sec:sess_ctrl_term}).
704 Oltre queste operazioni è però necessario poter disporre di un meccanismo
705 ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
706 un sistema unix-like tutto viene gestito attraverso i processi, il meccanismo
707 scelto consiste nel riportare lo stato di terminazione (il cosiddetto
708 \textit{termination status}) al processo padre.
710 Nel caso di conclusione normale, abbiamo visto in \secref{sec:proc_conclusion}
711 che lo stato di uscita del processo viene caratterizzato tramite il valore del
712 cosiddetto \textit{exit status}, cioè il valore passato alle funzioni
713 \func{exit} o \func{\_exit} (o dal valore di ritorno per \func{main}). Ma se
714 il processo viene concluso in maniera anomala il programma non può specificare
715 nessun \textit{exit status}, ed è il kernel che deve generare autonomamente il
716 \textit{termination status} per indicare le ragioni della conclusione anomala.
718 Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
719 quello che contraddistingue lo stato di chiusura del processo e viene
720 riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
721 \secref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale
722 il kernel usa il primo (nel codice eseguito da \func{\_exit}) per produrre il
725 La scelta di riportare al padre lo stato di terminazione dei figli, pur
726 essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
727 alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
728 che sia così alla sua conclusione, dato che il padre potrebbe essere già
729 terminato (si potrebbe avere cioè quello che si chiama un processo
732 Questa complicazione viene superata facendo in modo che il processo orfano
733 venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
734 termina, il kernel controlla se è il padre di altri processi in esecuzione: in
735 caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito
736 con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
737 avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo})
738 cui riportare il suo stato di terminazione. Come verifica di questo
739 comportamento possiamo eseguire il nostro programma \cmd{forktest} imponendo a
740 ciascun processo figlio due secondi di attesa prima di uscire, il risultato è:
744 [piccardi@selidor sources]$ ./forktest -c2 3
745 Process 1972: forking 3 child
746 Spawned 1 child, pid 1973
747 Child 1 successfully executing
749 Spawned 2 child, pid 1974
750 Child 2 successfully executing
752 Child 3 successfully executing
753 Spawned 3 child, pid 1975
755 [piccardi@selidor sources]$ Child 3, parent 1, exiting
756 Child 2, parent 1, exiting
757 Child 1, parent 1, exiting
760 come si può notare in questo caso il processo padre si conclude prima dei
761 figli, tornando alla shell, che stampa il prompt sul terminale: circa due
762 secondi dopo viene stampato a video anche l'output dei tre figli che
763 terminano, e come si può notare in questo caso, al contrario di quanto visto
764 in precedenza, essi riportano 1 come \acr{ppid}.
766 Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
767 perché non è detto che il padre possa ricevere immediatamente lo stato di
768 terminazione, quindi il kernel deve comunque conservare una certa quantità di
769 informazioni riguardo ai processi che sta terminando.
771 Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
772 memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
773 dal processo (vedi \secref{sec:sys_unix_time}) e lo stato di terminazione,
774 mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. I
775 processi che sono terminati, ma il cui stato di terminazione non è stato
776 ancora ricevuto dal padre sono chiamati \textit{zombie}, essi restano presenti
777 nella tabella dei processi ed in genere possono essere identificati
778 dall'output di \cmd{ps} per la presenza di una \texttt{Z} nella colonna che ne
779 indica lo stato (vedi \tabref{tab:proc_proc_states}). Quando il padre
780 effettuerà la lettura dello stato di uscita anche questa informazione, non più
781 necessaria, verrà scartata e la terminazione potrà dirsi completamente
784 Possiamo utilizzare il nostro programma di prova per analizzare anche questa
785 condizione: lanciamo il comando \cmd{forktest} in background, indicando al
786 processo padre di aspettare 10 secondi prima di uscire; in questo caso, usando
787 \cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi)
792 [piccardi@selidor sources]$ ps T
793 PID TTY STAT TIME COMMAND
794 419 pts/0 S 0:00 bash
795 568 pts/0 S 0:00 ./forktest -e10 3
796 569 pts/0 Z 0:00 [forktest <defunct>]
797 570 pts/0 Z 0:00 [forktest <defunct>]
798 571 pts/0 Z 0:00 [forktest <defunct>]
799 572 pts/0 R 0:00 ps T
802 e come si vede, dato che non si è fatto nulla per riceverne lo stato di
803 terminazione, i tre processi figli sono ancora presenti pur essendosi
804 conclusi, con lo stato di zombie e l'indicazione che sono stati terminati.
806 La possibilità di avere degli zombie deve essere tenuta sempre presente quando
807 si scrive un programma che deve essere mantenuto in esecuzione a lungo e
808 creare molti figli. In questo caso si deve sempre avere cura di far leggere
809 l'eventuale stato di uscita di tutti i figli (in genere questo si fa
810 attraverso un apposito \textit{signal handler}, che chiama la funzione
811 \func{wait}, vedi \secref{sec:sig_sigchld} e \secref{sec:proc_wait}). Questa
812 operazione è necessaria perché anche se gli \textit{zombie} non consumano
813 risorse di memoria o processore, occupano comunque una voce nella tabella dei
814 processi, che a lungo andare potrebbe esaurirsi.
816 Si noti che quando un processo adottato da \cmd{init} termina, esso non
817 diviene uno \textit{zombie}; questo perché una delle funzioni di \cmd{init} è
818 appunto quella di chiamare la funzione \func{wait} per i processi cui fa da
819 padre, completandone la terminazione. Questo è quanto avviene anche quando,
820 come nel caso del precedente esempio con \cmd{forktest}, il padre termina con
821 dei figli in stato di zombie: alla sua terminazione infatti tutti i suoi figli
822 (compresi gli zombie) verranno adottati da \cmd{init}, il quale provvederà a
823 completarne la terminazione.
825 Si tenga presente infine che siccome gli zombie sono processi già usciti, non
826 c'è modo di eliminarli con il comando \cmd{kill}; l'unica possibilità di
827 cancellarli dalla tabella dei processi è quella di terminare il processo che
828 li ha generati, in modo che \cmd{init} possa adottarli e provvedere a
829 concluderne la terminazione.
832 \subsection{Le funzioni \func{wait} e \func{waitpid}}
833 \label{sec:proc_wait}
835 Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
836 consiste nella creazione di programmi di tipo server, in cui un processo
837 principale attende le richieste che vengono poi soddisfatte da una serie di
838 processi figli. Si è già sottolineato al paragrafo precedente come in questo
839 caso diventi necessario gestire esplicitamente la conclusione dei figli onde
840 evitare di riempire di \textit{zombie} la tabella dei processi; le funzioni
841 deputate a questo compito sono sostanzialmente due, \func{wait} e
842 \func{waitpid}. La prima, il cui prototipo è:
844 \headdecl{sys/types.h}
845 \headdecl{sys/wait.h}
846 \funcdecl{pid\_t wait(int *status)}
848 Sospende il processo corrente finché un figlio non è uscito, o finché un
849 segnale termina il processo o chiama una funzione di gestione.
851 \bodydesc{La funzione restituisce il \acr{pid} del figlio in caso di successo
852 e -1 in caso di errore; \var{errno} può assumere i valori:
854 \item[\macro{EINTR}] la funzione è stata interrotta da un segnale.
858 è presente fin dalle prime versioni di Unix; la funzione ritorna non appena un
859 processo figlio termina. Se un figlio è già terminato la funzione ritorna
862 Al ritorno lo stato di terminazione del processo viene salvato nella
863 variabile puntata da \var{status} e tutte le informazioni relative al
864 processo (vedi \secref{sec:proc_termination}) vengono rilasciate. Nel
865 caso un processo abbia più figli il valore di ritorno permette di
866 identificare qual'è quello che è uscito.
868 Questa funzione ha il difetto di essere poco flessibile, in quanto
869 ritorna all'uscita di un figlio qualunque. Nelle occasioni in cui è
870 necessario attendere la conclusione di un processo specifico occorre
871 predisporre un meccanismo che tenga conto dei processi già terminati, e
872 provveda a ripetere la chiamata alla funzione nel caso il processo
873 cercato sia ancora attivo.
875 Per questo motivo lo standard POSIX.1 ha introdotto la funzione \func{waitpid}
876 che effettua lo stesso servizio, ma dispone di una serie di funzionalità più
877 ampie, legate anche al controllo di sessione (si veda
878 \ref{sec:sess_job_control}). Dato che è possibile ottenere lo stesso
879 comportamento di \func{wait} si consiglia di utilizzare sempre questa
880 funzione, il cui prototipo è:
882 \headdecl{sys/types.h}
883 \headdecl{sys/wait.h}
884 \funcdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
885 Attende la conclusione di un processo figlio.
887 \bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se
888 è stata specificata l'opzione \macro{WNOHANG} e il processo non è uscito e
889 -1 per un errore, nel qual caso \var{errno} assumerà i valori:
891 \item[\macro{EINTR}] se non è stata specificata l'opzione \macro{WNOHANG} e
892 la funzione è stata interrotta da un segnale.
893 \item[\macro{ECHILD}] il processo specificato da \param{pid} non esiste o
894 non è figlio del processo chiamante.
898 Le differenze principali fra le due funzioni sono che \func{wait} si blocca
899 sempre fino a che un processo figlio non termina, mentre \func{waitpid} ha la
900 possibilità si specificare un'opzione \macro{WNOHANG} che ne previene il
901 blocco; inoltre \func{waitpid} può specificare quale processo attendere sulla
902 base del valore fornito dall'argomento \param{pid}, secondo lo
903 specchietto riportato in \tabref{tab:proc_waidpid_pid}:
907 \begin{tabular}[c]{|c|c|p{8cm}|}
909 \textbf{Valore} & \textbf{Macro} &\textbf{Significato}\\
912 $<-1$& -- & attende per un figlio il cui \textit{process group} (vedi
913 \secref{sec:sess_proc_group}) è uguale al
914 valore assoluto di \var{pid}. \\
915 $-1$ & \macro{WAIT\_ANY} & attende per un figlio qualsiasi, usata in
916 questa maniera è equivalente a \func{wait}.\\
917 $0$ & \macro{WAIT\_MYPGRP} & attende per un figlio il cui \textit{process
918 group} è uguale a quello del processo chiamante. \\
919 $>0$ & -- &attende per un figlio il cui \acr{pid} è uguale al
920 valore di \var{pid}.\\
923 \caption{Significato dei valori del parametro \var{pid} della funzione
925 \label{tab:proc_waidpid_pid}
928 Il comportamento di \func{waitpid} può inoltre essere modificato passando
929 delle opportune opzioni tramite l'argomento \param{option}. I valori possibili
930 sono il già citato \macro{WNOHANG}, che previene il blocco della funzione
931 quando il processo figlio non è terminato, e \macro{WUNTRACED}. Quest'ultimo
932 viene generalmente usato per il controllo di sessione, (trattato in
933 \secref{sec:sess_job_control}) in quanto permette di identificare i processi
934 bloccati. La funzione infatti in tal caso ritorna, restituendone il \acr{pid},
935 se c'è un processo figlio che è entrato in stato di sleep (vedi
936 \tabref{tab:proc_proc_states}) di cui non si è ancora letto lo stato (con
937 questa stessa opzione). Il valore dell'opzione deve essere specificato come
938 maschera binaria ottenuta con l'OR delle suddette costanti con zero. In Linux
939 sono previste altre opzioni non standard relative al comportamento con i
940 thread, che saranno trattate in \secref{sec:thread_xxx}.
942 La terminazione di un processo figlio è chiaramente un evento asincrono
943 rispetto all'esecuzione di un programma e può avvenire in un qualunque
944 momento. Per questo motivo, come accennato nella sezione precedente, una delle
945 azioni prese dal kernel alla conclusione di un processo è quella di mandare un
946 segnale di \macro{SIGCHLD} al padre. L'azione predefinita (si veda
947 \secref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua
948 generazione costituisce il meccanismo di comunicazione asincrona con cui il
949 kernel avverte il processo padre che uno dei suoi figli è terminato.
951 In genere in un programma non si vuole essere forzati ad attendere la
952 conclusione di un processo per proseguire, specie se tutto questo serve solo
953 per leggerne lo stato di chiusura (ed evitare la presenza di \textit{zombie}),
954 per questo la modalità più usata per chiamare queste funzioni è quella di
955 utilizzarle all'interno di un \textit{signal handler} (vedremo un esempio di
956 come gestire \macro{SIGCHLD} con i segnali in \secref{sec:sig_example}). In
957 questo caso infatti, dato che il segnale è generato dalla terminazione di un
958 figlio, avremo la certezza che la chiamata a \func{wait} non si bloccherà.
963 \begin{tabular}[c]{|c|p{10cm}|}
965 \textbf{Macro} & \textbf{Descrizione}\\
968 \macro{WIFEXITED(s)} & Condizione vera (valore non nullo) per un processo
969 figlio che sia terminato normalmente. \\
970 \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello
971 stato di uscita del processo (passato attraverso \func{\_exit}, \func{exit}
972 o come valore di ritorno di \func{main}). Può essere valutata solo se
973 \macro{WIFEXITED} ha restituito un valore non nullo.\\
974 \macro{WIFSIGNALED(s)} & Vera se il processo figlio è terminato
975 in maniera anomala a causa di un segnale che non è stato catturato (vedi
976 \secref{sec:sig_notification}).\\
977 \macro{WTERMSIG(s)} & restituisce il numero del segnale che ha causato
978 la terminazione anomala del processo. Può essere valutata solo se
979 \macro{WIFSIGNALED} ha restituito un valore non nullo.\\
980 \macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un
981 file si \textit{core dump}. Può essere valutata solo se
982 \macro{WIFSIGNALED} ha restituito un valore non nullo.\footnote{questa
983 macro non è definita dallo standard POSIX.1, ma è presente come estensione
984 sia in Linux che in altri Unix.}\\
985 \macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di
986 \func{waitpid} è bloccato. L'uso è possibile solo avendo specificato
987 l'opzione \macro{WUNTRACED}. \\
988 \macro{WSTOPSIG(s)} & restituisce il numero del segnale che ha bloccato
989 il processo, Può essere valutata solo se \macro{WIFSTOPPED} ha
990 restituito un valore non nullo. \\
993 \caption{Descrizione delle varie macro di preprocessore utilizzabili per
994 verificare lo stato di terminazione \var{s} di un processo.}
995 \label{tab:proc_status_macro}
998 Entrambe le funzioni di attesa restituiscono lo stato di terminazione del
999 processo tramite il puntatore \param{status} (se non interessa memorizzare lo
1000 stato si può passare un puntatore nullo). Il valore restituito da entrambe le
1001 funzioni dipende dall'implementazione, e tradizionalmente alcuni bit (in
1002 genere 8) sono riservati per memorizzare lo stato di uscita, e altri per
1003 indicare il segnale che ha causato la terminazione (in caso di conclusione
1004 anomala), uno per indicare se è stato generato un core file, ecc.\footnote{le
1005 definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
1006 questo file non deve mai essere usato direttamente, esso viene incluso
1007 attraverso \file{<sys/wait.h>}.}
1009 Lo standard POSIX.1 definisce una serie di macro di preprocessore da usare per
1010 analizzare lo stato di uscita. Esse sono definite sempre in
1011 \file{<sys/wait.h>} ed elencate in \tabref{tab:proc_status_macro} (si tenga
1012 presente che queste macro prendono come parametro la variabile di tipo
1013 \ctyp{int} puntata da \var{status}).
1015 Si tenga conto che nel caso di conclusione anomala il valore restituito da
1016 \macro{WTERMSIG} può essere confrontato con le costanti definite in
1017 \file{signal.h} ed elencate in \tabref{tab:sig_signal_list}, e stampato usando
1018 le apposite funzioni trattate in \secref{sec:sig_strsignal}.
1021 \subsection{Le funzioni \func{wait3} e \func{wait4}}
1022 \label{sec:proc_wait4}
1024 Linux, seguendo un'estensione di BSD, supporta altre due funzioni per la
1025 lettura dello stato di terminazione di un processo \func{wait3} e
1026 \func{wait4}, analoghe alle precedenti ma che prevedono un ulteriore
1027 parametro attraverso il quale il kernel può restituire al padre informazioni
1028 sulle risorse usate dal processo terminato e dai vari figli. I prototipi di
1029 queste funzioni, che diventano accessibili definendo la costante
1030 \macro{\_USE\_BSD}, sono:
1032 \headdecl{sys/times.h} \headdecl{sys/types.h} \headdecl{sys/wait.h}
1033 \headdecl{sys/resource.h}
1035 \funcdecl{pid\_t wait4(pid\_t pid, int * status, int options, struct rusage
1037 È identica a \func{waitpid} sia per comportamento che per i valori dei
1038 parametri, ma restituisce in \param{rusage} un sommario delle risorse usate
1041 \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
1042 Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
1043 ormai deprecata in favore di \func{wait4}.
1046 la struttura \type{rusage} è definita in \file{sys/resource.h}, e viene
1047 utilizzata anche dalla funzione \func{getrusage} (vedi
1048 \secref{sec:sys_resource_use}) per ottenere le risorse di sistema usate da un
1049 processo; la sua definizione è riportata in \figref{fig:sys_rusage_struct}.
1052 \subsection{Le funzioni \func{exec}}
1053 \label{sec:proc_exec}
1055 Abbiamo già detto che una delle modalità principali con cui si utilizzano i
1056 processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
1057 fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
1058 processo chiama una di queste funzioni esso viene completamente sostituito dal
1059 nuovo programma; il \acr{pid} del processo non cambia, dato che non viene
1060 creato un nuovo processo, la funzione semplicemente rimpiazza lo stack, lo
1061 heap, i dati ed il testo del processo corrente con un nuovo programma letto da
1064 Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
1065 famiglia di funzioni) che possono essere usate per questo compito, in realtà
1066 (come mostrato in \figref{fig:proc_exec_relat}), sono tutte un front-end a
1067 \func{execve}. Il prototipo di quest'ultima è:
1068 \begin{prototype}{unistd.h}
1069 {int execve(const char *filename, char *const argv[], char *const envp[])}
1070 Esegue il programma contenuto nel file \param{filename}.
1072 \bodydesc{La funzione ritorna solo in caso di errore, restituendo -1; nel
1073 qual caso \var{errno} può assumere i valori:
1075 \item[\macro{EACCES}] il file non è eseguibile, oppure il filesystem è
1076 montato in \cmd{noexec}, oppure non è un file regolare o un interprete.
1077 \item[\macro{EPERM}] il file ha i bit \acr{suid} o \acr{sgid}, l'utente non
1078 è root, e o il processo viene tracciato, o il filesystem è montato con
1079 l'opzione \cmd{nosuid}.
1080 \item[\macro{ENOEXEC}] il file è in un formato non eseguibile o non
1081 riconosciuto come tale, o compilato per un'altra architettura.
1082 \item[\macro{ENOENT}] il file o una delle librerie dinamiche o l'interprete
1083 necessari per eseguirlo non esistono.
1084 \item[\macro{ETXTBSY}] L'eseguibile è aperto in scrittura da uno o più
1086 \item[\macro{EINVAL}] L'eseguibile ELF ha più di un segmento
1087 \macro{PF\_INTERP}, cioè chiede di essere eseguito da più di un
1089 \item[\macro{ELIBBAD}] Un interprete ELF non è in un formato
1092 ed inoltre anche \macro{EFAULT}, \macro{ENOMEM}, \macro{EIO},
1093 \macro{ENAMETOOLONG}, \macro{E2BIG}, \macro{ELOOP}, \macro{ENOTDIR},
1094 \macro{ENFILE}, \macro{EMFILE}.}
1097 La funzione \func{exec} esegue il file o lo script indicato da
1098 \var{filename}, passandogli la lista di argomenti indicata da \var{argv}
1099 e come ambiente la lista di stringhe indicata da \var{envp}; entrambe le
1100 liste devono essere terminate da un puntatore nullo. I vettori degli
1101 argomenti e dell'ambiente possono essere acceduti dal nuovo programma
1102 quando la sua funzione \func{main} è dichiarata nella forma
1103 \code{main(int argc, char *argv[], char *envp[])}.
1105 Le altre funzioni della famiglia servono per fornire all'utente una serie
1106 possibile di diverse interfacce per la creazione di un nuovo processo. I loro
1110 \funcdecl{int execl(const char *path, const char *arg, ...)}
1111 \funcdecl{int execv(const char *path, char *const argv[])}
1112 \funcdecl{int execle(const char *path, const char *arg, ..., char
1114 \funcdecl{int execlp(const char *file, const char *arg, ...)}
1115 \funcdecl{int execvp(const char *file, char *const argv[])}
1117 Sostituiscono l'immagine corrente del processo con quella indicata nel primo
1118 argomento. I parametri successivi consentono di specificare gli argomenti a
1119 linea di comando e l'ambiente ricevuti dal nuovo processo.
1121 \bodydesc{Queste funzioni ritornano solo in caso di errore, restituendo -1;
1122 nel qual caso \var{errno} assumerà i valori visti in precedenza per
1126 Per capire meglio le differenze fra le funzioni della famiglia si può fare
1127 riferimento allo specchietto riportato in \ntab. La prima differenza riguarda
1128 le modalità di passaggio dei parametri che poi andranno a costituire gli
1129 argomenti a linea di comando (cioè i valori di \var{argv} e \var{argc} visti
1130 dalla funzione \func{main} del programma chiamato).
1132 Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
1133 che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
1134 gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
1135 stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
1136 questo vettore \emph{deve} essere terminato da un puntatore nullo.
1138 Nel secondo caso le stringhe degli argomenti sono passate alla funzione come
1139 lista di puntatori, nella forma:
1140 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
1141 char *arg0, char *arg1, ..., char *argn, NULL
1143 che deve essere terminata da un puntatore nullo. In entrambi i casi vale la
1144 convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
1145 per indicare il nome del file che contiene il programma che verrà eseguito.
1150 \begin{tabular}[c]{|l|c|c|c||c|c|c|}
1152 \multicolumn{1}{|c|}{\textbf{Caratteristiche}} &
1153 \multicolumn{6}{|c|}{\textbf{Funzioni}} \\
1155 &\func{execl\ }&\func{execlp}&\func{execle}
1156 &\func{execv\ }& \func{execvp}& \func{execve} \\
1159 argomenti a lista &$\bullet$&$\bullet$&$\bullet$&&& \\
1160 argomenti a vettore &&&&$\bullet$&$\bullet$&$\bullet$\\
1162 filename completo &&$\bullet$&&&$\bullet$& \\
1163 ricerca su \var{PATH}&$\bullet$&&$\bullet$&$\bullet$&&$\bullet$ \\
1165 ambiente a vettore &&&$\bullet$&&&$\bullet$ \\
1166 uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\
1169 \caption{Confronto delle caratteristiche delle varie funzioni della
1170 famiglia \func{exec}.}
1171 \label{tab:proc_exec_scheme}
1174 La seconda differenza fra le funzioni riguarda le modalità con cui si
1175 specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si
1176 indicano le due funzioni che replicano il comportamento della shell nello
1177 specificare il comando da eseguire; quando il parametro \var{file} non
1178 contiene una \file{/} esso viene considerato come un nome di programma, e
1179 viene eseguita automaticamente una ricerca fra i file presenti nella lista di
1180 directory specificate dalla variabile di ambiente \var{PATH}. Il file che
1181 viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
1182 relativo a permessi di accesso insufficienti (cioè l'esecuzione della
1183 sottostante \func{execve} ritorna un \macro{EACCESS}), la ricerca viene
1184 proseguita nelle eventuali ulteriori directory indicate in \var{PATH}; solo se
1185 non viene trovato nessun altro file viene finalmente restituito
1188 Le altre quattro funzioni si limitano invece a cercare di eseguire il file
1189 indicato dal parametro \var{path}, che viene interpretato come il
1190 \textit{pathname} del programma.
1194 \includegraphics[width=15cm]{img/exec_rel}
1195 \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
1196 \label{fig:proc_exec_relat}
1199 La terza differenza è come viene passata la lista delle variabili di ambiente.
1200 Con lo mnemonico \code{e} vengono indicate quelle funzioni che necessitano di
1201 un vettore di parametri \var{envp[]} analogo a quello usato per gli argomenti
1202 a riga di comando (terminato quindi da un \macro{NULL}), le altre usano il
1203 valore della variabile \var{environ} (vedi \secref{sec:proc_environ}) del
1204 processo di partenza per costruire l'ambiente.
1206 Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da
1207 \func{exec} assume anche una serie di altre proprietà del processo chiamante;
1208 la lista completa è la seguente:
1210 \item il \textit{process id} (\acr{pid}) ed il \textit{parent process id}
1212 \item l'\textsl{userid reale}, il \textit{groupid reale} ed i \textsl{groupid
1213 supplementari} (vedi \secref{sec:proc_access_id}).
1214 \item il \textit{session id} (\acr{sid}) ed il \textit{process groupid}
1215 (\acr{pgid}), vedi \secref{sec:sess_proc_group}.
1216 \item il terminale di controllo (vedi \secref{sec:sess_ctrl_term}).
1217 \item il tempo restante ad un allarme (vedi \secref{sec:sig_alarm_abort}).
1218 \item la directory radice e la directory di lavoro corrente (vedi
1219 \secref{sec:file_work_dir}).
1220 \item la maschera di creazione dei file (\var{umask}, vedi
1221 \secref{sec:file_umask}) ed i \textit{lock} sui file (vedi
1222 \secref{sec:file_locking}).
1223 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
1224 \secref{sec:sig_sigmask}).
1225 \item i limiti sulle risorse (vedi \secref{sec:sys_resource_limit}).
1226 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
1227 \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:sys_cpu_times}).
1230 Inoltre i segnali che sono stati impostati per essere ignorati nel processo
1231 chiamante mantengono la stessa impostazione pure nel nuovo programma, tutti
1232 gli altri segnali vengono impostati alla loro azione predefinita. Un caso
1233 speciale è il segnale \macro{SIGCHLD} che, quando impostato a
1234 \macro{SIG\_IGN}, può anche non essere reimpostato a \macro{SIG\_DFL} (si veda
1235 \secref{sec:sig_gen_beha}).
1237 La gestione dei file aperti dipende dal valore che ha il flag di
1238 \textit{close-on-exec} (trattato in \secref{sec:file_fcntl}) per ciascun file
1239 descriptor. I file per cui è impostato vengono chiusi, tutti gli altri file
1240 restano aperti. Questo significa che il comportamento predefinito è che i file
1241 restano aperti attraverso una \func{exec}, a meno di una chiamata esplicita a
1242 \func{fcntl} che imposti il suddetto flag.
1244 Per le directory, lo standard POSIX.1 richiede che esse vengano chiuse
1245 attraverso una \func{exec}, in genere questo è fatto dalla funzione
1246 \func{opendir} (vedi \secref{sec:file_dir_read}) che effettua da sola
1247 l'impostazione del flag di \textit{close-on-exec} sulle directory che apre, in
1248 maniera trasparente all'utente.
1250 Abbiamo detto che l'\textsl{userid reale} ed il \textsl{groupid reale} restano
1251 gli stessi all'esecuzione di \func{exec}; lo stesso vale per l'\textsl{userid
1252 effettivo} ed il \textsl{groupid effettivo} (il significato di questi
1253 identificatori è trattato in \secref{sec:proc_access_id}), tranne quando il
1254 file che si va ad eseguire abbia o il \acr{suid} bit o lo \acr{sgid} bit
1255 impostato, in questo caso l'\textsl{userid effettivo} ed il \textsl{groupid
1256 effettivo} vengono impostati rispettivamente all'utente o al gruppo cui il
1257 file appartiene (per i dettagli vedi \secref{sec:proc_perms}).
1259 Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
1260 condivise, viene lanciato il \textit{linker} dinamico \cmd{ld.so} prima del
1261 programma per caricare le librerie necessarie ed effettuare il link
1262 dell'eseguibile. Se il programma è in formato ELF per caricare le librerie
1263 dinamiche viene usato l'interprete indicato nel segmento \macro{PT\_INTERP},
1264 in genere questo è \file{/lib/ld-linux.so.1} per programmi linkati con le
1265 \acr{libc5}, e \file{/lib/ld-linux.so.2} per programmi linkati con le
1266 \acr{glibc}. Infine nel caso il file sia uno script esso deve iniziare con
1267 una linea nella forma \cmd{\#!/path/to/interpreter} dove l'interprete indicato
1268 deve esse un valido programma (binario, non un altro script) che verrà
1269 chiamato come se si fosse eseguito il comando \cmd{interpreter [arg]
1272 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
1273 basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo
1274 processo, con \func{exec} si avvia un nuovo programma, con \func{exit} e
1275 \func{wait} si effettua e verifica la conclusione dei programmi. Tutte le
1276 altre funzioni sono ausiliarie e servono la lettura e l'impostazione dei vari
1277 parametri connessi ai processi.
1281 \section{Il controllo di accesso}
1282 \label{sec:proc_perms}
1284 In questa sezione esamineremo le problematiche relative al controllo di
1285 accesso dal punto di vista del processi; vedremo quali sono gli identificatori
1286 usati, come questi possono essere modificati nella creazione e nel lancio di
1287 nuovi processi, le varie funzioni per la loro manipolazione diretta e tutte le
1288 problematiche connesse ad una gestione accorta dei privilegi.
1291 \subsection{Gli identificatori del controllo di accesso}
1292 \label{sec:proc_access_id}
1294 Come accennato in \secref{sec:intro_multiuser} il modello base\footnote{in
1295 realtà già esistono estensioni di questo modello base, che lo rendono più
1296 flessibile e controllabile, come le \textit{capabilities}, le ACL per i file
1297 o il \textit{Mandatory Access Control} di SELinux; inoltre basandosi sul
1298 lavoro effettuato con SELinux, a partire dal kernel 2.5.x, è iniziato lo
1299 sviluppo di una infrastruttura di sicurezza, il \textit{Linux Security
1300 Modules}, ol LSM, in grado di fornire diversi agganci a livello del kernel
1301 per modularizzare tutti i possibili controlli di accesso.} di sicurezza di
1302 un sistema unix-like è fondato sui concetti di utente e gruppo, e sulla
1303 separazione fra l'amministratore (\textsl{root}, detto spesso anche
1304 \textit{superuser}) che non è sottoposto a restrizioni, ed il resto degli
1305 utenti, per i quali invece vengono effettuati i vari controlli di accesso.
1307 %Benché il sistema sia piuttosto semplice (è basato su un solo livello di
1308 % separazione) il sistema permette una
1309 %notevole flessibilità,
1311 Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
1312 identificatori univoci, lo userid ed il groupid; questi servono al kernel per
1313 identificare uno specifico utente o un gruppo di utenti, per poi poter
1314 controllare che essi siano autorizzati a compiere le operazioni richieste. Ad
1315 esempio in \secref{sec:file_access_control} vedremo come ad ogni file vengano
1316 associati un utente ed un gruppo (i suoi \textsl{proprietari}, indicati
1317 appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati dal
1318 kernel nella gestione dei permessi di accesso.
1320 Dato che tutte le operazioni del sistema vengono compiute dai processi, è
1321 evidente che per poter implementare un controllo sulle operazioni occorre
1322 anche poter identificare chi è che ha lanciato un certo programma, e pertanto
1323 anche a ciascun processo dovrà essere associato ad un utente e ad un gruppo.
1325 Un semplice controllo di una corrispondenza fra identificativi non garantisce
1326 però sufficiente flessibilità per tutti quei casi in cui è necessario poter
1327 disporre di privilegi diversi, o dover impersonare un altro utente per un
1328 limitato insieme di operazioni. Per questo motivo in generale tutti gli Unix
1329 prevedono che i processi abbiano almeno due gruppi di identificatori, chiamati
1330 rispettivamente \textit{real} ed \textit{effective} (cioè \textsl{reali} ed
1331 \textsl{effettivi}). Nel caso di Linux si aggiungono poi altri due gruppi, il
1332 \textit{saved} (\textsl{salvati}) ed il \textit{filesystem} (\textsl{di
1333 filesystem}), secondo la situazione illustrata in \tabref{tab:proc_uid_gid}.
1338 \begin{tabular}[c]{|c|c|l|p{7.3cm}|}
1340 \textbf{Suffisso} & \textbf{Gruppo} & \textbf{Denominazione}
1341 & \textbf{Significato} \\
1344 \acr{uid} & \textit{real} & \textsl{userid reale}
1345 & indica l'utente che ha lanciato il programma\\
1346 \acr{gid} & '' &\textsl{groupid reale}
1347 & indica il gruppo principale dell'utente che ha lanciato
1350 \acr{euid} & \textit{effective} &\textsl{userid effettivo}
1351 & indica l'utente usato nel controllo di accesso \\
1352 \acr{egid} & '' & \textsl{groupid effettivo}
1353 & indica il gruppo usato nel controllo di accesso \\
1354 -- & -- & \textsl{groupid supplementari}
1355 & indicano gli ulteriori gruppi cui l'utente appartiene \\
1357 -- & \textit{saved} & \textsl{userid salvato}
1358 & è una copia dell'\acr{euid} iniziale\\
1359 -- & '' & \textsl{groupid salvato}
1360 & è una copia dell'\acr{egid} iniziale \\
1362 \acr{fsuid} & \textit{filesystem} &\textsl{userid di filesystem}
1363 & indica l'utente effettivo per l'accesso al filesystem \\
1364 \acr{fsgid} & '' & \textsl{groupid di filesystem}
1365 & indica il gruppo effettivo per l'accesso al filesystem \\
1368 \caption{Identificatori di utente e gruppo associati a ciascun processo con
1369 indicazione dei suffissi usati dalle varie funzioni di manipolazione.}
1370 \label{tab:proc_uid_gid}
1373 Al primo gruppo appartengono l'\textsl{userid reale} ed il \textsl{groupid
1374 reale}: questi vengono impostati al login ai valori corrispondenti
1375 all'utente con cui si accede al sistema (e relativo gruppo principale).
1376 Servono per l'identificazione dell'utente e normalmente non vengono mai
1377 cambiati. In realtà vedremo (in \secref{sec:proc_setuid}) che è possibile
1378 modificarli, ma solo ad un processo che abbia i privilegi di amministratore;
1379 questa possibilità è usata proprio dal programma \cmd{login} che, una volta
1380 completata la procedura di autenticazione, lancia una shell per la quale
1381 imposta questi identificatori ai valori corrispondenti all'utente che entra
1384 Al secondo gruppo appartengono l'\textsl{userid effettivo} e l'\textsl{groupid
1385 effettivo} (a cui si aggiungono gli eventuali \textsl{groupid supplementari}
1386 dei gruppi dei quali l'utente fa parte). Questi sono invece gli
1387 identificatori usati nella verifiche dei permessi del processo e per il
1388 controllo di accesso ai file (argomento affrontato in dettaglio in
1389 \secref{sec:file_perm_overview}).
1391 Questi identificatori normalmente sono identici ai corrispondenti del gruppo
1392 \textit{real} tranne nel caso in cui, come accennato in
1393 \secref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit
1394 \acr{suid} o \acr{sgid} impostati (il significato di questi bit è affrontato
1395 in dettaglio in \secref{sec:file_suid_sgid}). In questo caso essi saranno
1396 impostati all'utente e al gruppo proprietari del file. Questo consente, per
1397 programmi in cui ci sia necessità, di dare a qualunque utente normale
1398 privilegi o permessi di un'altro (o dell'amministratore).
1400 Come nel caso del \acr{pid} e del \acr{ppid} tutti questi identificatori
1401 possono essere letti dal processo attraverso delle opportune funzioni, i cui
1402 prototipi sono i seguenti:
1405 \headdecl{sys/types.h}
1406 \funcdecl{uid\_t getuid(void)} Restituisce l'\textsl{userid reale} del
1409 \funcdecl{uid\_t geteuid(void)} Restituisce l'\textsl{userid effettivo} del
1412 \funcdecl{gid\_t getgid(void)} Restituisce il \textsl{groupid reale} del
1415 \funcdecl{gid\_t getegid(void)} Restituisce il \textsl{groupid effettivo}
1416 del processo corrente.
1418 \bodydesc{Queste funzioni non riportano condizioni di errore.}
1421 In generale l'uso di privilegi superiori deve essere limitato il più
1422 possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
1423 un meccanismo che consenta ad un programma di rilasciare gli eventuali
1424 maggiori privilegi necessari, una volta che si siano effettuate le operazioni
1425 per i quali erano richiesti, e a poterli eventualmente recuperare in caso
1428 Questo in Linux viene fatto usando altri gli altri due gruppi di
1429 identificatori, il \textit{saved} ed il \textit{filesystem}. Il primo gruppo è
1430 lo stesso usato in SVr4, e previsto dallo standard POSIX quando è definita la
1431 costante \macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la
1432 portabilità del programma su altri Unix è buona norma controllare sempre la
1433 disponibilità di queste funzioni controllando se questa costante è
1434 definita.} il secondo gruppo è specifico di Linux e viene usato per
1435 migliorare la sicurezza con NFS.
1437 L'\textsl{userid salvato} ed il \textsl{groupid salvato} sono copie
1438 dell'\textsl{userid effettivo} e del \textsl{groupid effettivo} del processo
1439 padre, e vengono impostati dalla funzione \func{exec} all'avvio del processo,
1440 come copie dell'\textsl{userid effettivo} e del \textsl{groupid effettivo}
1441 dopo che questo sono stati impostati tenendo conto di eventuali \acr{suid} o
1442 \acr{sgid}. Essi quindi consentono di tenere traccia di quale fossero utente
1443 e gruppo effettivi all'inizio dell'esecuzione di un nuovo programma.
1445 L'\textsl{userid di filesystem} e il \textsl{groupid di filesystem} sono
1446 un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
1447 (torneremo sull'argomento in \secref{sec:proc_setfsuid}). Essi sono una
1448 replica dei corrispondenti identificatori del gruppo \textit{effective}, ai
1449 quali si sostituiscono per tutte le operazioni di verifica dei permessi
1450 relativi ai file (trattate in \secref{sec:file_perm_overview}). Ogni
1451 cambiamento effettuato sugli identificatori effettivi viene automaticamente
1452 riportato su di essi, per cui in condizioni normali si può tranquillamente
1453 ignorarne l'esistenza, in quanto saranno del tutto equivalenti ai precedenti.
1456 \subsection{Le funzioni \func{setuid} e \func{setgid}}
1457 \label{sec:proc_setuid}
1459 Le due funzioni che vengono usate per cambiare identità (cioè utente e gruppo
1460 di appartenenza) ad un processo sono rispettivamente \func{setuid} e
1461 \func{setgid}; come accennato in \secref{sec:proc_access_id} in Linux esse
1462 seguono la semantica POSIX che prevede l'esistenza dell'\textit{userid
1463 salvato} e del \textit{groupid salvato}; i loro prototipi sono:
1466 \headdecl{sys/types.h}
1468 \funcdecl{int setuid(uid\_t uid)} Imposta l'\textsl{userid} del processo
1471 \funcdecl{int setgid(gid\_t gid)} Imposta il \textsl{groupid} del processo
1474 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1475 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1478 Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
1479 la prima; la seconda si comporta esattamente allo stesso modo facendo
1480 riferimento al \textsl{groupid} invece che all'\textsl{userid}. Gli
1481 eventuali \textsl{groupid supplementari} non vengono modificati.
1483 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
1484 l'\textsl{userid effettivo} è zero (cioè è quello dell'amministratore di
1485 sistema) allora tutti gli identificatori (\textit{real}, \textit{effective} e
1486 \textit{saved}) vengono impostati al valore specificato da \var{uid},
1487 altrimenti viene impostato solo l'\textsl{userid effettivo}, e soltanto se il
1488 valore specificato corrisponde o all'\textsl{userid reale} o
1489 all'\textsl{userid salvato}. Negli altri casi viene segnalato un errore (con
1492 Come accennato l'uso principale di queste funzioni è quello di poter
1493 consentire ad un programma con i bit \acr{suid} o \acr{sgid} impostati di
1494 riportare l'\textsl{userid effettivo} a quello dell'utente che ha lanciato il
1495 programma, effettuare il lavoro che non necessita di privilegi aggiuntivi, ed
1496 eventualmente tornare indietro.
1498 Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
1499 viene gestito l'accesso al file \file{/var/log/utmp}. In questo file viene
1500 registrato chi sta usando il sistema al momento corrente; chiaramente non può
1501 essere lasciato aperto in scrittura a qualunque utente, che potrebbe
1502 falsificare la registrazione. Per questo motivo questo file (e l'analogo
1503 \file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad
1504 un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad
1505 esempio tutti i programmi di terminale in X, o il programma \cmd{screen} che
1506 crea terminali multipli su una console) appartengono a questo gruppo ed hanno
1507 il bit \acr{sgid} impostato.
1509 Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
1510 situazione degli identificatori è la seguente:
1513 \textsl{groupid reale} &=& \textrm{\acr{gid} (del chiamante)} \\
1514 \textsl{groupid effettivo} &=& \textrm{\acr{utmp}} \\
1515 \textsl{groupid salvato} &=& \textrm{\acr{utmp}}
1517 in questo modo, dato che il \textsl{groupid effettivo} è quello giusto, il
1518 programma può accedere a \file{/var/log/utmp} in scrittura ed aggiornarlo. A
1519 questo punto il programma può eseguire una \code{setgid(getgid())} per
1520 impostare il \textsl{groupid effettivo} a quello dell'utente (e dato che il
1521 \textsl{groupid reale} corrisponde la funzione avrà successo), in questo modo
1522 non sarà possibile lanciare dal terminale programmi che modificano detto file,
1523 in tal caso infatti la situazione degli identificatori sarebbe:
1526 \textsl{groupid reale} &=& \textrm{\acr{gid} (invariato)} \\
1527 \textsl{groupid effettivo} &=& \textrm{\acr{gid}} \\
1528 \textsl{groupid salvato} &=& \textrm{\acr{utmp} (invariato)}
1530 e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
1531 \textsl{groupid effettivo}. All'uscita dal terminale, per poter di nuovo
1532 aggiornare lo stato di \file{/var/log/utmp} il programma eseguirà una
1533 \code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
1534 \acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
1535 in questo caso il valore richiesto corrisponde al \textsl{groupid salvato} la
1536 funzione avrà successo e riporterà la situazione a:
1539 \textsl{groupid reale} &=& \textrm{\acr{gid} (invariato)} \\
1540 \textsl{groupid effettivo} &=& \textrm{\acr{utmp}} \\
1541 \textsl{groupid salvato} &=& \textrm{\acr{utmp} (invariato)}
1543 consentendo l'accesso a \file{/var/log/utmp}.
1545 Occorre però tenere conto che tutto questo non è possibile con un processo con
1546 i privilegi di root, in tal caso infatti l'esecuzione una \func{setuid}
1547 comporta il cambiamento di tutti gli identificatori associati al processo,
1548 rendendo impossibile riguadagnare i privilegi di amministratore. Questo
1549 comportamento è corretto per l'uso che ne fa \cmd{login} una volta che crea
1550 una nuova shell per l'utente; ma quando si vuole cambiare soltanto
1551 l'\textsl{userid effettivo} del processo per cedere i privilegi occorre
1552 ricorrere ad altre funzioni (si veda ad esempio \secref{sec:proc_seteuid}).
1555 \subsection{Le funzioni \func{setreuid} e \func{setresuid}}
1556 \label{sec:proc_setreuid}
1558 Queste due funzioni derivano da BSD che, non supportando\footnote{almeno fino
1559 alla versione 4.3+BSD TODO, FIXME verificare e aggiornare la nota.} gli
1560 identificatori del gruppo \textit{saved}, le usa per poter scambiare fra di
1561 loro \textit{effective} e \textit{real}. I loro prototipi sono:
1564 \headdecl{sys/types.h}
1566 \funcdecl{int setreuid(uid\_t ruid, uid\_t euid)} Imposta l'\textsl{userid
1567 reale} e l'\textsl{userid effettivo} del processo corrente ai valori
1568 specificati da \var{ruid} e \var{euid}.
1570 \funcdecl{int setregid(gid\_t rgid, gid\_t egid)} Imposta il \textsl{groupid
1571 reale} ed il \textsl{groupid effettivo} del processo corrente ai valori
1572 specificati da \var{rgid} e \var{egid}.
1574 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1575 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1578 La due funzioni sono analoghe ed il loro comportamento è identico; quanto
1579 detto per la prima prima riguardo l'userid, si applica immediatamente alla
1580 seconda per il groupid. I processi non privilegiati possono impostare solo i
1581 valori del loro userid effettivo o reale; valori diversi comportano il
1582 fallimento della chiamata; l'amministratore invece può specificare un valore
1583 qualunque. Specificando un argomento di valore -1 l'identificatore
1584 corrispondente verrà lasciato inalterato.
1586 Con queste funzione si possono scambiare fra loro gli userid reale e
1587 effettivo, e pertanto è possibile implementare un comportamento simile a
1588 quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo
1589 scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un secondo
1592 In questo caso però occorre porre molta attenzione quando si creano nuovi
1593 processi nella fase intermedia in cui si sono scambiati gli identificatori, in
1594 questo caso infatti essi avranno un userid reale privilegiato, che dovrà
1595 essere esplicitamente eliminato prima di porre in esecuzione un nuovo
1596 programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e
1597 prima della \func{exec} per uniformare l'userid reale a quello effettivo) in
1598 caso contrario il nuovo programma potrebbe a sua volta effettuare uno scambio
1599 e riottenere privilegi non previsti.
1601 Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
1602 si pone per l'userid salvato: questa funzione deriva da un'implementazione che
1603 non ne prevede la presenza, e quindi non è possibile usarla per correggere la
1604 situazione come nel caso precedente. Per questo motivo in Linux tutte le volte
1605 che si imposta un qualunque valore diverso da quello dall'userid reale
1606 corrente, l'userid salvato viene automaticamente uniformato al valore
1607 dell'userid effettivo.
1610 \subsection{Le funzioni \func{seteuid} e \func{setegid}}
1611 \label{sec:proc_seteuid}
1613 Queste funzioni sono un'estensione allo standard POSIX.1 (ma sono comunque
1614 supportate dalla maggior parte degli Unix) e vengono usate per cambiare gli
1615 identificatori del gruppo \textit{effective}; i loro prototipi sono:
1618 \headdecl{sys/types.h}
1620 \funcdecl{int seteuid(uid\_t uid)} Imposta l'userid effettivo del processo
1621 corrente a \var{uid}.
1623 \funcdecl{int setegid(gid\_t gid)} Imposta il groupid effettivo del processo
1624 corrente a \var{gid}.
1626 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1627 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1630 Come per le precedenti le due funzioni sono identiche, per cui tratteremo solo
1631 la prima. Gli utenti normali possono impostare l'userid effettivo solo al
1632 valore dell'userid reale o dell'userid salvato, l'amministratore può
1633 specificare qualunque valore. Queste funzioni sono usate per permettere
1634 all'amministratore di impostare solo l'userid effettivo, dato che l'uso
1635 normale di \func{setuid} comporta l'impostazione di tutti gli identificatori.
1638 \subsection{Le funzioni \func{setresuid} e \func{setresgid}}
1639 \label{sec:proc_setresuid}
1641 Queste due funzioni sono un'estensione introdotta in Linux dal kernel 2.1.44,
1642 e permettono un completo controllo su tutti gli identificatori (\textit{real},
1643 \textit{effective} e \textit{saved}), i prototipi sono:
1646 \headdecl{sys/types.h}
1648 \funcdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} Imposta
1649 l'userid reale, l'userid effettivo e l'userid salvato del processo corrente
1650 ai valori specificati rispettivamente da \var{ruid}, \var{euid} e \var{suid}.
1652 \funcdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} Imposta il
1653 groupid reale, il groupid effettivo ed il groupid salvato del processo
1654 corrente ai valori specificati rispettivamente da \var{rgid}, \var{egid} e
1657 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1658 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1661 Le due funzioni sono identiche, quanto detto per la prima riguardo gli userid
1662 si applica alla seconda per i groupid. I processi non privilegiati possono
1663 cambiare uno qualunque degli userid solo ad un valore corripondente o
1664 all'userid reale, o a quello effettivo o a quello salvato, l'amministratore
1665 può specificare i valori che vuole; un valore di -1 per un qualunque parametro
1666 lascia inalterato l'identificatore corrispondente.
1668 Per queste funzioni esistono anche due controparti che permettono di leggere
1669 in blocco i vari identificatori: \func{getresuid} e \func{getresgid}; i loro
1673 \headdecl{sys/types.h}
1675 \funcdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)} Legge
1676 l'userid reale, l'userid effettivo e l'userid salvato del processo corrente.
1678 \funcdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)} Legge il
1679 groupid reale, il groupid effettivo e il groupid salvato del processo
1682 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
1683 fallimento: l'unico errore possibile è \macro{EFAULT} se gli indirizzi delle
1684 variabili di ritorno non sono validi.}
1687 Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
1688 nessun privilegio. I valori sono restituiti negli argomenti, che vanno
1689 specificati come puntatori (è un'altro esempio di \textit{value result
1690 argument}). Si noti che queste funzioni sono le uniche in grado di leggere
1691 gli identificatori del gruppo \textit{saved}.
1694 \subsection{Le funzioni \func{setfsuid} e \func{setfsgid}}
1695 \label{sec:proc_setfsuid}
1697 Queste funzioni sono usate per impostare gli identificatori del gruppo
1698 \textit{filesystem} che usati da Linux per il controllo dell'accesso ai file.
1699 Come già accennato in \secref{sec:proc_access_id} Linux definisce questo
1700 ulteriore gruppo di identificatori, che di norma sono assolutamente
1701 equivalenti a quelli del gruppo \textit{effective}, dato che ogni cambiamento
1702 di questi ultimi viene immediatamente riportato su di essi.
1704 C'è un solo caso in cui si ha necessità di introdurre una differenza fra gli
1705 identificatori dei gruppi \textit{effective} e \textit{filesystem}, ed è per
1706 ovviare ad un problema di sicurezza che si presenta quando si deve
1707 implementare un server NFS. Il server NFS infatti deve poter cambiare
1708 l'identificatore con cui accede ai file per assumere l'identità del singolo
1709 utente remoto, ma se questo viene fatto cambiando l'userid effettivo o
1710 l'userid reale il server si espone alla ricezione di eventuali segnali ostili
1711 da parte dell'utente di cui ha temporaneamente assunto l'identità. Cambiando
1712 solo l'userid di filesystem si ottengono i privilegi necessari per accedere ai
1713 file, mantenendo quelli originari per quanto riguarda tutti gli altri
1714 controlli di accesso, così che l'utente non possa inviare segnali al server
1717 Le due funzioni usate per cambiare questi identificatori sono \func{setfsuid}
1718 e \func{setfsgid}, ovviamente sono specifiche di Linux e non devono essere
1719 usate se si intendono scrivere programmi portabili; i loro prototipi sono:
1721 \headdecl{sys/fsuid.h}
1723 \funcdecl{int setfsuid(uid\_t fsuid)} Imposta l'userid di filesystem del
1724 processo corrente a \var{fsuid}.
1726 \funcdecl{int setfsgid(gid\_t fsgid)} Imposta il groupid di filesystem del
1727 processo corrente a \var{fsgid}.
1729 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1730 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1732 \noindent queste funzioni hanno successo solo se il processo chiamante ha i
1733 privilegi di amministratore o, per gli altri utenti, se il valore specificato
1734 coincide con uno dei di quelli del gruppo \textit{real}, \textit{effective} o
1738 \subsection{Le funzioni \func{setgroups} e \func{getgroups}}
1739 \label{sec:proc_setgroups}
1741 Le ultime funzioni che esamineremo sono quelle che permettono di operare sui
1742 gruppi supplementari. Ogni processo può avere fino a \macro{NGROUPS\_MAX}
1743 gruppi supplementari in aggiunta al gruppo primario, questi vengono ereditati
1744 dal processo padre e possono essere cambiati con queste funzioni.
1746 La funzione che permette di leggere i gruppi supplementari è \func{getgroups};
1747 questa funzione è definita nello standard POSIX ed il suo prototipo è:
1749 \headdecl{sys/types.h}
1752 \funcdecl{int getgroups(int size, gid\_t list[])} Legge gli identificatori
1753 dei gruppi supplementari del processo sul vettore \param{list} di dimensione
1756 \bodydesc{La funzione restituisce il numero di gruppi letti in caso di
1757 successo e -1 in caso di fallimento, nel qual caso \var{errno} assumerà
1760 \item[\macro{EFAULT}] \param{list} non ha un indirizzo valido.
1761 \item[\macro{EINVAL}] il valore di \param{size} è diverso da zero ma
1762 minore del numero di gruppi supplementari del processo.
1765 \noindent non è specificato se la funzione inserisca o meno nella lista
1766 il groupid effettivo del processo. Se si specifica un valore di \param{size}
1767 uguale a 0 \param{list} non viene modificato, ma si ottiene il numero di
1768 gruppi supplementari.
1770 Una seconda funzione, \func{getgrouplist}, può invece essere usata per
1771 ottenere tutti i gruppi a cui appartiene un utente; il suo prototipo è:
1773 \headdecl{sys/types.h}
1776 \funcdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups,
1777 int *ngroups)} Legge i gruppi supplementari dell'utente \param{user}.
1779 \bodydesc{La funzione legge fino ad un massimo di \param{ngroups} valori,
1780 restituisce 0 in caso di successo e -1 in caso di fallimento.}
1782 \noindent la funzione esegue una scansione del database dei gruppi (si veda
1783 \secref{sec:sys_user_group}) e ritorna in \param{groups} la lista di quelli a
1784 cui l'utente appartiene. Si noti che \param{ngroups} è passato come puntatore
1785 perché qualora il valore specificato sia troppo piccolo la funzione ritorna
1786 -1, passando indietro il numero dei gruppi trovati.
1788 Per impostare i gruppi supplementari di un processo ci sono due funzioni, che
1789 possono essere usate solo se si hanno i privilegi di amministratore. La prima
1790 delle due è \func{setgroups}, ed il suo prototipo è:
1792 \headdecl{sys/types.h}
1795 \funcdecl{int setgroups(size\_t size, gid\_t *list)} Imposta i gruppi
1796 supplementari del processo ai valori specificati in \param{list}.
1798 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1799 fallimento, nel qual caso \var{errno} assumerà i valori:
1801 \item[\macro{EFAULT}] \param{list} non ha un indirizzo valido.
1802 \item[\macro{EPERM}] il processo non ha i privilegi di amministratore.
1803 \item[\macro{EINVAL}] il valore di \param{size} è maggiore del valore
1804 massimo (\macro{NGROUPS}, che per Linux è 32).
1808 Se invece si vogliono impostare i gruppi supplementari del processo a quelli di
1809 un utente specifico, si può usare \func{initgroups} il cui prototipo è:
1811 \headdecl{sys/types.h}
1814 \funcdecl{int initgroups(const char *user, gid\_t group)} Imposta i gruppi
1815 supplementari del processo a quelli di cui è membro l'utente \param{user},
1816 aggiungendo il gruppo addizionale \param{group}.
1818 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1819 fallimento, nel qual caso \var{errno} assumerà gli stessi valori di
1820 \func{setgroups} più \macro{ENOMEM} quando non c'è memoria sufficiente per
1821 allocare lo spazio per informazioni dei gruppi.}
1824 La funzione esegue la scansione del database dei gruppi (usualmente
1825 \file{/etc/groups}) cercando i gruppi di cui è membro \param{user} e
1826 costruendo una lista di gruppi supplementari a cui aggiunge \param{group}, che
1827 poi imposta usando \func{setgroups}.
1828 Si tenga presente che sia \func{setgroups} che \func{initgroups} non sono
1829 definite nello standard POSIX.1 e che pertanto non è possibile utilizzarle
1830 quando si definisce \macro{\_POSIX\_SOURCE} o si compila con il flag
1834 \section{La gestione della priorità di esecuzione}
1835 \label{sec:proc_priority}
1837 In questa sezione tratteremo più approfonditamente i meccanismi con il quale
1838 lo \textit{scheduler} assegna la CPU ai vari processi attivi. In particolare
1839 prenderemo in esame i vari meccanismi con cui viene gestita l'assegnazione del
1840 tempo di CPU, ed illustreremo le varie funzioni di gestione.
1843 \subsection{I meccanismi di \textit{scheduling}}
1844 \label{sec:proc_sched}
1846 La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
1847 il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
1848 ed oggetto di numerose ricerche; in generale essa dipende in maniera
1849 essenziale anche dal tipo di utilizzo che deve essere fatto del sistema, per
1850 cui non esiste un meccanismo che sia valido per tutti gli usi.
1852 La caratteristica specifica di un sistema multitasking come Linux è quella del
1853 cosiddetto \textit{prehemptive multitasking}: questo significa che al
1854 contrario di altri sistemi (che usano invece il cosiddetto \textit{cooperative
1855 multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
1856 quando la CPU deve essere passata ad un altro processo. Come accennato in
1857 \secref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione
1858 apposita del kernel, lo \textit{scheduler}, il cui scopo è quello di
1859 distribuire al meglio il tempo di CPU fra i vari processi.
1861 La cosa è resa ancora più complicata dal fatto che con le architetture
1862 multi-processore si deve anche scegliere quale sia la CPU più opportuna da
1863 utilizzare.\footnote{nei processori moderni la presenza di ampie cache può
1864 rendere poco efficiente trasferire l'esecuzione di un processo da una CPU ad
1865 un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
1866 banale.} Tutto questo comunque appartiene alle sottigliezze
1867 dell'implementazione del kernel; dal punto di vista dei programmi che girano
1868 in user space, anche quando si hanno più processori (e dei processi che sono
1869 eseguiti davvero in contemporanea), le politiche di scheduling riguardano
1870 semplicemente l'allocazione della risorsa \textsl{tempo di esecuzione}, la cui
1871 assegnazione sarà governata dai meccanismi di scelta delle priorità che
1872 restano gli stessi indipendentemente dal numero di processori.
1874 Si tenga conto poi che i processi non devono solo eseguire del codice: ad
1875 esempio molto spesso saranno impegnati in operazioni di I/O, o potranno
1876 venire bloccati da un comando dal terminale, o sospesi per un certo periodo di
1877 tempo. In tutti questi casi la CPU diventa disponibile ed è compito dello
1878 kernel provvedere a mettere in esecuzione un altro processo.
1880 Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
1881 processo, in Linux un processo può trovarsi in uno degli stati riportati in
1882 \tabref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
1883 \textit{runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
1884 sia la sua priorità, un processo non potrà mai essere messo in esecuzione
1885 fintanto che esso si trova in uno qualunque degli altri stati.
1890 \begin{tabular}[c]{|p{2.8cm}|c|p{10cm}|}
1892 \textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
1895 \textbf{Runnable} & \texttt{R} & Il processo è in esecuzione o è pronto ad
1896 essere eseguito (cioè è in attesa che gli venga assegnata la CPU). \\
1897 \textbf{Sleep} & \texttt{S} & Il processo processo è in attesa di un
1898 risposta dal sistema, ma può essere interrotto da un segnale. \\
1899 \textbf{Uninterrutible Sleep} & \texttt{D} & Il processo è in
1900 attesa di un risposta dal sistema (in genere per I/O), e non può essere
1901 interrotto in nessuna circostanza. \\
1902 \textbf{Stopped} & \texttt{T} & Il processo è stato fermato con un
1903 \macro{SIGSTOP}, o è tracciato.\\
1904 \textbf{Zombie} & \texttt{Z} & Il processo è terminato ma il suo stato di
1905 terminazione non è ancora stato letto dal padre. \\
1908 \caption{Elenco dei possibili stati di un processo in Linux, nella colonna
1909 \texttt{STAT} si è riportata la corrispondente lettera usata dal comando
1910 \cmd{ps} nell'omonimo campo.}
1911 \label{tab:proc_proc_states}
1914 Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
1915 risorse che sono necessarie per l'esecuzione di un programma, e a seconda
1916 dello scopo del programma non è detto neanche che sia la più importante (molti
1917 programmi dipendono in maniera molto più critica dall'I/O). Per questo motivo
1918 non è affatto detto che dare ad un programma la massima priorità di esecuzione
1919 abbia risultati significativi in termini di prestazioni.
1921 Il meccanismo tradizionale di scheduling di Unix (che tratteremo in
1922 \secref{sec:proc_sched_stand}) è sempre stato basato su delle \textsl{priorità
1923 dinamiche}, in modo da assicurare che tutti i processi, anche i meno
1924 importanti, possano ricevere un po' di tempo di CPU. In sostanza quando un
1925 processo ottiene la CPU la sua priorità viene diminuita. In questo modo alla
1926 fine, anche un processo con priorità iniziale molto bassa, finisce per avere
1927 una priorità sufficiente per essere eseguito.
1929 Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
1930 assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
1931 alla normale priorità dinamica), per tenere conto dei sistemi
1932 real-time,\footnote{per sistema real-time si intende un sistema in grado di
1933 eseguire operazioni in un tempo ben determinato; in genere si tende a
1934 distinguere fra l'\textit{hard real-time} in cui è necessario che i tempi di
1935 esecuzione di un programma siano determinabili con certezza assoluta (come
1936 nel caso di meccanismi di controllo di macchine, dove uno sforamento dei
1937 tempi avrebbe conseguenze disastrose), e \textit{soft-real-time} in cui un
1938 occasionale sforamento è ritenuto accettabile.} in cui è vitale che i
1939 processi che devono essere eseguiti in un determinato momento non debbano
1940 aspettare la conclusione di altri che non hanno questa necessità.
1942 Il concetto di priorità assoluta dice che quando due processi si contendono
1943 l'esecuzione, vince sempre quello con la priorità assoluta più alta, anche
1944 quando l'altro è in esecuzione (grazie al \textit{prehemptive scheduling}).
1945 Ovviamente questo avviene solo per i processi che sono pronti per essere
1946 eseguiti (cioè nello stato \textit{runnable}). La priorità assoluta viene in
1947 genere indicata con un numero intero, ed un valore più alto comporta una
1948 priorità maggiore. Su questa politica di scheduling torneremo in
1949 \secref{sec:proc_real_time}.
1951 In generale quello che succede in tutti gli Unix moderni è che ai processi
1952 normali viene sempre data una priorità assoluta pari a zero, e la decisione di
1953 assegnazione della CPU è fatta solo con il meccanismo tradizionale della
1954 priorità dinamica. In Linux tuttavia è possibile assegnare anche una priorità
1955 assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di
1956 priorità inferiore, che saranno eseguiti solo quando quest'ultimo non avrà
1960 \subsection{Il meccanismo di \textit{scheduling} standard}
1961 \label{sec:proc_sched_stand}
1963 A meno che non si abbiano esigenze specifiche, l'unico meccanismo di
1964 scheduling con il quale si avrà a che fare è quello tradizionale, che prevede
1965 solo priorità dinamiche. È di questo che, di norma, ci si dovrà preoccupare
1966 nella programmazione.
1968 Come accennato in Linux tutti i processi ordinari hanno la stessa priorità
1969 assoluta. Quello che determina quale, fra tutti i processi in attesa di
1970 esecuzione, sarà eseguito per primo, è la priorità dinamica, che è chiamata
1971 così proprio perché varia nel corso dell'esecuzione di un processo. Oltre a
1972 questo la priorità dinamica determina quanto a lungo un processo continuerà ad
1973 essere eseguito, e quando un processo potrà subentrare ad un altro
1976 Il meccanismo usato da Linux è piuttosto semplice, ad ogni processo è
1977 assegnata una \textit{time-slice}, cioè in intervallo di tempo (letteralmente
1978 una fetta) per il quale esso deve essere eseguito. Il valore della
1979 \textit{time-slice} è controllato dalla cosiddetta \textit{nice} (o
1980 \textit{niceness}) del processo. Essa è contenuta nel campo \var{nice} di
1981 \var{task\_struct}; tutti i processi vengono creati con lo stesso valore, ed
1982 essa specifica il valore della durata iniziale della \textit{time-slice} che
1983 viene assegnato ad un altro campo della struttura (\var{counter}) quando il
1984 processo viene eseguito per la prima volta e diminuito progressivamente ad
1985 ogni interruzione del timer.
1987 Quando lo scheduler viene eseguito scandisce la coda dei processi in stato
1988 \textit{runnable} associando, sulla base del valore di \var{counter}, un peso
1989 a ciascun processo in attesa di esecuzione,\footnote{il calcolo del peso in
1990 realtà è un po' più complicato, ad esempio nei sistemi multiprocessore viene
1991 favorito un processo che è eseguito sulla stessa CPU, e a parità del valore
1992 di \var{counter} viene favorito chi ha una priorità più elevata.} chi ha il
1993 peso più alto verrà posto in esecuzione, ed il precedente processo sarà
1994 spostato in fondo alla coda. Dato che ad ogni interruzione del timer il
1995 valore di \var{counter} del processo corrente viene diminuito, questo assicura
1996 che anche i processi con priorità più bassa verranno messi in esecuzione.
1998 La priorità di un processo è così controllata attraverso il valore di
1999 \var{nice}, che stabilisce la durata della \textit{time-slice}; per il
2000 meccanismo appena descritto infatti un valore più lungo infatti assicura una
2001 maggiore attribuzione di CPU. L'origine del nome di questo parametro sta nel
2002 fatto che in genere esso viene generalmente usato per diminuire la priorità di
2003 un processo, come misura di cortesia nei confronti degli altri.
2004 I processi infatti vengono creati dal sistema con lo stesso valore di
2005 \var{nice} (nullo) e nessuno è privilegiato rispetto agli altri; il valore può
2006 essere modificato solo attraverso la funzione \func{nice}, il cui prototipo è:
2007 \begin{prototype}{unistd.h}
2009 Aumenta il valore di \var{nice} per il processo corrente.
2011 \bodydesc{La funzione ritorna zero in caso di successo e -1 in caso di
2012 errore, nel qual caso \var{errno} può assumere i valori:
2014 \item[\macro{EPERM}] un processo senza i privilegi di amministratore ha
2015 specificato un valore di \param{inc} negativo.
2019 L'argomento \param{inc} indica l'incremento del valore di \var{nice}:
2020 quest'ultimo può assumere valori compresi fra \macro{PRIO\_MIN} e
2021 \macro{PRIO\_MAX} (che nel caso di Linux sono $-19$ e $20$), ma per
2022 \param{inc} si può specificare un valore qualunque, positivo o negativo, ed il
2023 sistema provvederà a troncare il risultato nell'intervallo consentito. Valori
2024 positivi comportano maggiore \textit{cortesia} e cioè una diminuzione della
2025 priorità, ogni utente può solo innalzare il valore di un suo processo. Solo
2026 l'amministratore può specificare valori negativi che permettono di aumentare
2027 la priorità di un processo.
2029 In SUSv2 la funzione ritorna il nuovo valore di \var{nice}; Linux non segue
2030 questa convenzione, e per leggere il nuovo valore occorre invece usare la
2031 funzione \func{getpriority}, derivata da BSD, il cui prototipo è:
2032 \begin{prototype}{sys/resource.h}
2033 {int getpriority(int which, int who)}
2035 Restituisce il valore di \var{nice} per l'insieme dei processi specificati.
2037 \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
2038 errore, nel qual caso \var{errno} può assumere i valori:
2040 \item[\macro{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2041 \param{which} e \param{who}.
2042 \item[\macro{EINVAL}] il valore di \param{which} non è valido.
2045 \noindent (in vecchie versioni può essere necessario includere anche
2046 \file{<sys/time.h>}, questo non è più necessario con versioni recenti delle
2047 librerie, ma è comunque utile per portabilità).
2049 La funzione permette di leggere la priorità di un processo, di un gruppo di
2050 processi (vedi \secref{sec:sess_proc_group}) o di un utente, a seconda del
2051 valore di \param{which}, secondo la legenda di \tabref{tab:proc_getpriority},
2052 specificando un corrispondente valore per \param{who}; un valore nullo di
2053 quest'ultimo indica il processo, il gruppo di processi o l'utente correnti.
2058 \begin{tabular}[c]{|c|c|l|}
2060 \param{which} & \param{who} & \textbf{Significato} \\
2063 \macro{PRIO\_PROCESS} & \type{pid\_t} & processo \\
2064 \macro{PRIO\_PRGR} & \type{pid\_t} & process group \\
2065 \macro{PRIO\_USER} & \type{uid\_t} & utente \\
2068 \caption{Legenda del valore dell'argomento \param{which} e del tipo
2069 dell'argomento \param{who} delle funzioni \func{getpriority} e
2070 \func{setpriority} per le tre possibili scelte.}
2071 \label{tab:proc_getpriority}
2074 La funzione restituisce la priorità più alta (cioè il valore più basso) fra
2075 quelle dei processi specificati; dato che -1 è un valore possibile, per poter
2076 rilevare una condizione di errore è necessario cancellare sempre \var{errno}
2077 prima della chiamata alla funzione, per verificare che essa resti uguale a
2080 Analoga a \func{getpriority} la funzione \func{setpriority} permette di
2081 impostare la priorità di uno o più processi; il suo prototipo è:
2082 \begin{prototype}{sys/resource.h}
2083 {int setpriority(int which, int who, int prio)}
2084 Imposta la priorità per l'insieme dei processi specificati.
2086 \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
2087 errore, nel qual caso \var{errno} può assumere i valori:
2089 \item[\macro{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2090 \param{which} e \param{who}.
2091 \item[\macro{EINVAL}] il valore di \param{which} non è valido.
2092 \item[\macro{EPERM}] un processo senza i privilegi di amministratore ha
2093 specificato un valore di \param{inc} negativo.
2094 \item[\macro{EACCESS}] un processo senza i privilegi di amministratore ha
2095 cercato di modificare la priorità di un processo di un altro utente.
2099 La funzione imposta la priorità al valore specificato da \param{prio} per
2100 tutti i processi indicati dagli argomenti \param{which} e \param{who}. La
2101 gestione dei permessi dipende dalle varie implementazioni; in Linux, secondo
2102 le specifiche dello standard SUSv3, e come avviene per tutti i sistemi che
2103 derivano da SYSV, è richiesto che l'userid reale o effettivo del processo
2104 chiamante corrispondano al real user id (e solo quello) del processo di cui si
2105 vuole cambiare la priorità; per i sistemi derivati da BSD invece (SunOS,
2106 Ultrix, *BSD) la corrispondenza può essere anche con l'userid effettivo.
2110 \subsection{Il meccanismo di \textit{scheduling real-time}}
2111 \label{sec:proc_real_time}
2113 Come spiegato in \secref{sec:proc_sched} lo standard POSIX.1b ha introdotto le
2114 priorità assolute per permettere la gestione di processi real-time. In realtà
2115 nel caso di Linux non si tratta di un vero hard real-time, in quanto in
2116 presenza di eventuali interrupt il kernel interrompe l'esecuzione di un
2117 processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
2118 siano installate le patch di RTLinux o RTAI, con i quali è possibile
2119 ottenere un sistema effettivamente hard real-time. In tal caso infatti gli
2120 interrupt vengono intercettati dall'interfaccia real-time, e gestiti
2121 direttamente qualora ci sia la necessità di avere un processo con priorità
2122 più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
2123 page fault\index{page fault} si possono avere ritardi non previsti. Se
2124 l'ultimo problema può essere aggirato attraverso l'uso delle funzioni di
2125 controllo della memoria virtuale (vedi \secref{sec:proc_mem_lock}), il primo
2126 non è superabile e può comportare ritardi non prevedibili riguardo ai tempi di
2127 esecuzione di qualunque processo.
2129 In ogni caso occorre usare le priorità assolute con molta attenzione: se si dà
2130 ad un processo una priorità assoluta e questo finisce in un loop infinito,
2131 nessun altro processo potrà essere eseguito, ed esso sarà mantenuto in
2132 esecuzione permanentemente assorbendo tutta la CPU e senza nessuna possibilità
2133 di riottenere l'accesso al sistema. Per questo motivo è sempre opportuno,
2134 quando si lavora con processi che usano priorità assolute, tenere attiva una
2135 shell cui si sia assegnata la massima priorità assoluta, in modo da poter
2136 essere comunque in grado di rientrare nel sistema.
2138 Quando c'è un processo con priorità assoluta lo scheduler lo metterà in
2139 esecuzione prima di ogni processo normale. In caso di più processi sarà
2140 eseguito per primo quello con priorità assoluta più alta. Quando ci sono più
2141 processi con la stessa priorità assoluta questi vengono tenuti in una coda
2142 tocca al kernel decidere quale deve essere eseguito.
2146 Il meccanismo con cui vengono gestiti questi processi dipende dalla politica
2147 di scheduling che si è scelto; lo standard ne prevede due:
2148 \begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
2149 \item[\textit{FIFO}] il processo viene eseguito fintanto che non cede
2150 volontariamente la CPU, si blocca, finisce o viene interrotto da un processo
2151 a priorità più alta.
2152 \item[\textit{Round Robin}] ciascun processo viene eseguito a turno per un
2153 certo periodo di tempo (una \textit{time slice}). Solo i processi con la
2154 stessa priorità ed in stato \textit{runnable} entrano nel circolo.
2157 La funzione per impostare le politiche di scheduling (sia real-time che
2158 ordinarie) ed i relativi parametri è \func{sched\_setscheduler}; il suo
2160 \begin{prototype}{sched.h}
2161 {int sched\_setscheduler(pid\_t pid, int policy, const struct sched\_param *p)}
2162 Imposta priorità e politica di scheduling per il processo \param{pid}.
2164 \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
2165 errore, nel qual caso \var{errno} può assumere i valori:
2167 \item[\macro{ESRCH}] il processo \param{pid} non esiste.
2168 \item[\macro{EINVAL}] il valore di \param{policy} non esiste o il relativo
2169 valore di \param{p} non è valido.
2170 \item[\macro{EPERM}] il processo non ha i privilegi per attivare la
2171 politica richiesta (vale solo per \macro{SCHED\_FIFO} e
2176 La funzione esegue l'impostazione per il processo specificato; un valore nullo
2177 di \param{pid} esegue l'impostazione per il processo corrente, solo un
2178 processo con i privilegi di amministratore può impostare delle priorità
2179 assolute diverse da zero. La politica di scheduling è specificata
2180 dall'argomento \param{policy} i cui possibili valori sono riportati in
2181 \tabref{tab:proc_sched_policy}; un valore negativo per \param{policy} mantiene
2182 la politica di scheduling corrente.
2187 \begin{tabular}[c]{|c|l|}
2189 \textbf{Policy} & \textbf{Significato} \\
2192 \macro{SCHED\_FIFO} & Scheduling real-time con politica \textit{FIFO} \\
2193 \macro{SCHED\_RR} & Scheduling real-time con politica \textit{Round
2195 \macro{SCHED\_OTHER}& Scheduling ordinario\\
2198 \caption{Valori dell'argomento \param{policy} per la funzione
2199 \func{sched\_setscheduler}. }
2200 \label{tab:proc_sched_policy}
2203 Il valore della priorità è passato attraverso la struttura \var{sched\_param}
2204 (riportata in \figref{fig:sig_sched_param}), il cui solo campo attualmente
2205 definito è \var{sched\_priority}, che nel caso delle priorità assolute deve
2206 essere specificato nell'intervallo fra un valore massimo ed uno minimo, che
2207 nel caso sono rispettivamente 1 e 99 (il valore zero è legale, ma indica i
2210 \begin{figure}[!htb]
2211 \footnotesize \centering
2212 \begin{minipage}[c]{15cm}
2213 \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
2214 struct sched_param {
2220 \caption{La struttura \var{sched\_param}.}
2221 \label{fig:sig_sched_param}
2226 Lo standard POSIX.1b prevede comunque che i due valori della massima e minima
2227 priorità statica possano essere ottenuti, per ciascuna delle politiche di
2228 scheduling realtime, tramite le due funzioni \func{sched\_get\_priority\_max}
2229 e \func{sched\_get\_priority\_min}, i cui prototipi sono:
2233 \funcdecl{int sched\_get\_priority\_max(int policy)} Legge il valore
2234 massimo della priorità statica per la politica di scheduling \param{policy}.
2237 \funcdecl{int sched\_get\_priority\_min(int policy)} Legge il valore minimo
2238 della priorità statica per la politica di scheduling \param{policy}.
2240 \bodydesc{La funzioni ritornano il valore della priorità in caso di successo
2241 e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
2243 \item[\macro{EINVAL}] il valore di \param{policy} è invalido.
2248 I processi con politica di scheduling \macro{SCHED\_OTHER} devono specificare
2249 un valore nullo (altrimenti si avrà un errore \macro{EINVAL}), questo valore
2250 infatti non ha niente a che vedere con la priorità dinamica determinata dal
2251 valore di \var{nice}, che deve essere impostato con le funzioni viste in
2254 Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed
2255 esegue sempre il primo della lista, mentre un nuovo processo che torna in
2256 stato \textit{runnable} viene sempre inserito in coda alla lista. Se la
2257 politica scelta è \macro{SCHED\_FIFO} quando il processo viene eseguito viene
2258 automaticamente rimesso in coda alla lista, e la sua esecuzione continua
2259 fintanto che non viene bloccato da una richiesta di I/O, o non rilascia
2260 volontariamente la CPU (in tal caso, tornando nello stato \textit{runnable}
2261 sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo
2262 nel caso che esso sia stato interrotto da un processo a priorità più alta.
2264 La priorità assoluta può essere riletta indietro dalla funzione
2265 \func{sched\_getscheduler}, il cui prototipo è:
2266 \begin{prototype}{sched.h}
2267 {int sched\_getscheduler(pid\_t pid)}
2268 Legge la politica di scheduling per il processo \param{pid}.
2270 \bodydesc{La funzione ritorna la politica di scheduling in caso di successo
2271 e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
2273 \item[\macro{ESRCH}] il processo \param{pid} non esiste.
2274 \item[\macro{EINVAL}] il valore di \param{pid} è negativo.
2278 La funzione restituisce il valore (secondo la quanto elencato in
2279 \tabref{tab:proc_sched_policy}) della politica di scheduling per il processo
2280 specificato; se \param{pid} è nullo viene restituito quello del processo
2283 Se si intende operare solo sulla priorità assoluta di un processo si possono
2284 usare le funzioni \func{sched\_setparam} e \func{sched\_getparam}, i cui
2290 \funcdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *p)}
2291 Imposta la priorità assoluta del processo \param{pid}.
2294 \funcdecl{int sched\_getparam(pid\_t pid, struct sched\_param *p)}
2295 Legge la priorità assoluta del processo \param{pid}.
2297 \bodydesc{La funzione ritorna la priorità in caso di successo
2298 e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
2300 \item[\macro{ESRCH}] il processo \param{pid} non esiste.
2301 \item[\macro{EINVAL}] il valore di \param{pid} è negativo.
2305 L'uso di \func{sched\_setparam} che è del tutto equivalente a
2306 \func{sched\_setscheduler} con \param{priority} uguale a -1. Come per
2307 \func{sched\_setscheduler} specificando 0 come valore di \param{pid} si opera
2308 sul processo corrente. La disponibilità di entrambe le funzioni può essere
2309 verificata controllando la macro \macro{\_POSIX\_PRIORITY\_SCHEDULING} che è
2310 definita nell'header \macro{sched.h}.
2312 L'ultima funzione che permette di leggere le informazioni relative ai processi
2313 real-time è \func{sched\_rr\_get\_interval}, che permette di ottenere la
2314 lunghezza della \textit{time slice} usata dalla politica \textit{round robin};
2316 \begin{prototype}{sched.h}
2317 {int sched\_rr\_get\_interval(pid\_t pid, struct timespec *tp)} Legge in
2318 \param{tp} la durata della \textit{time slice} per il processo \param{pid}.
2320 \bodydesc{La funzione ritorna 0in caso di successo e -1 in caso di errore,
2321 nel qual caso \var{errno} può assumere i valori:
2323 \item[\macro{ESRCH}] il processo \param{pid} non esiste.
2324 \item[\macro{ENOSYS}] la system call non è stata implementata.
2328 La funzione restituisce il valore dell'intervallo di tempo usato per la
2329 politica \textit{round robin} in una struttura \var{timespec}, (la cui
2330 definizione si può trovare in \figref{fig:sys_timeval_struct}).
2333 Come accennato ogni processo che usa lo scheduling real-time può rilasciare
2334 volontariamente la CPU; questo viene fatto attraverso la funzione
2335 \func{sched\_yield}, il cui prototipo è:
2336 \begin{prototype}{sched.h}
2337 {int sched\_yield(void)}
2339 Rilascia volontariamente l'esecuzione.
2341 \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
2342 nel qual caso \var{errno} viene impostata opportunamente.}
2345 La funzione fa si che il processo rilasci la CPU, in modo da essere rimesso in
2346 coda alla lista dei processi da eseguire, e permettere l'esecuzione di un
2347 altro processo; se però il processo è l'unico ad essere presente sulla coda
2348 l'esecuzione non sarà interrotta. In genere usano questa funzione i processi
2349 in modalità \textit{fifo}, per permettere l'esecuzione degli altri processi
2350 con pari priorità quando la sezione più urgente è finita.
2353 \section{Problematiche di programmazione multitasking}
2354 \label{sec:proc_multi_prog}
2356 Benché i processi siano strutturati in modo da apparire il più possibile come
2357 indipendenti l'uno dall'altro, nella programmazione in un sistema multitasking
2358 occorre tenere conto di una serie di problematiche che normalmente non
2359 esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
2360 programma alla volta.
2362 Pur essendo questo argomento di carattere generale, ci è parso opportuno
2363 introdurre sinteticamente queste problematiche, che ritroveremo a più riprese
2364 in capitoli successivi, in questa sezione conclusiva del capitolo in cui
2365 abbiamo affrontato la gestione dei processi.
2368 \subsection{Le operazioni atomiche}
2369 \label{sec:proc_atom_oper}
2371 La nozione di \textsl{operazione atomica} deriva dal significato greco della
2372 parola atomo, cioè indivisibile; si dice infatti che un'operazione è atomica
2373 quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi
2374 che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
2375 di interruzione in una fase intermedia.
2377 In un ambiente multitasking il concetto è essenziale, dato che un processo può
2378 essere interrotto in qualunque momento dal kernel che mette in esecuzione un
2379 altro processo o dalla ricezione di un segnale; occorre pertanto essere
2380 accorti nei confronti delle possibili
2381 \textit{race condition}\index{race condition} (vedi
2382 \secref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase in
2383 cui non erano ancora state completate.
2385 Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
2386 occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
2387 fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
2388 \capref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
2389 \secref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
2390 funzioni di libreria per compiere le operazioni necessarie è garanzia
2391 sufficiente di atomicità in quanto le system call con cui esse sono realizzate
2392 non possono essere interrotte (o subire interferenze pericolose) da altri
2395 Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
2396 stesso processo, e pure alcune system call, possono essere interrotti in
2397 qualunque momento, e le operazioni di un eventuale \textit{signal handler}
2398 sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
2399 il solo accesso o l'assegnazione di una variabile possono non essere più
2400 operazioni atomiche (torneremo su questi aspetti in
2401 \secref{sec:sig_control}).
2403 In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
2404 il cui accesso è assicurato essere atomico. In pratica comunque si può
2405 assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
2406 \ctyp{int}, gli altri interi di dimensione inferiore ed i puntatori sono
2407 atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
2408 maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
2409 le strutture. In tutti questi casi è anche opportuno marcare come
2410 \ctyp{volatile} le variabili che possono essere interessate ad accesso
2411 condiviso, onde evitare problemi con le ottimizzazioni del codice.
2415 \subsection{Le \textit{race condition}\index{race condition} e i
2417 \label{sec:proc_race_cond}
2419 Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
2420 diversi operano su una risorsa comune, ed in cui il risultato viene a
2421 dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso
2422 tipico è quello di un'operazione che viene eseguita da un processo in più
2423 passi, e può essere compromessa dall'intervento di un altro processo che
2424 accede alla stessa risorsa quando ancora non tutti i passi sono stati
2427 Dato che in un sistema multitasking ogni processo può essere interrotto in
2428 qualunque momento per farne subentrare un'altro in esecuzione, niente può
2429 assicurare un preciso ordine di esecuzione fra processi diversi o che una
2430 sezione di un programma possa essere eseguita senza interruzioni da parte di
2431 altri. Queste situazioni comportano pertanto errori estremamente subdoli e
2432 difficili da tracciare, in quanto nella maggior parte dei casi tutto
2433 funzionerà regolarmente, e solo occasionalmente si avranno degli errori.
2435 Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
2436 che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
2437 gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di
2438 \textit{race condition} si hanno quando diversi processi accedono allo stesso
2439 file, o nell'accesso a meccanismi di intercomunicazione come la memoria
2440 condivisa. In questi casi, se non si dispone della possibilità di eseguire
2441 atomicamente le operazioni necessarie, occorre che quelle parti di codice in
2442 cui si compiono le operazioni sulle risorse condivise (le cosiddette
2443 \textsl{sezioni critiche}\index{sezioni critiche}) del programma, siano
2444 opportunamente protette da meccanismi di sincronizzazione (torneremo su queste
2445 problematiche di questo tipo in \capref{cha:IPC}).
2447 Un caso particolare di \textit{race condition} sono poi i cosiddetti
2448 \textit{deadlock}, particolarmente gravi in quanto comportano spesso il blocco
2449 completo di un servizio, e non il fallimento di una singola operazione.
2450 L'esempio tipico di una situazione che può condurre ad un \textit{deadlock} è
2451 quello in cui un flag di ``occupazione'' viene rilasciato da un evento
2452 asincrono (come un segnale o un altro processo) fra il momento in cui lo si è
2453 controllato (trovandolo occupato) e la successiva operazione di attesa per lo
2454 sblocco. In questo caso, dato che l'evento di sblocco del flag è avvenuto
2455 senza che ce ne accorgessimo proprio fra il controllo e la messa in attesa,
2456 quest'ultima diventerà perpetua (da cui il nome di \textit{deadlock}).
2458 In tutti questi casi è di fondamentale importanza il concetto di atomicità
2459 visto in \secref{sec:proc_atom_oper}; questi problemi infatti possono essere
2460 risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile
2461 eseguire in maniera atomica le operazioni necessarie.
2464 \subsection{Le funzioni rientranti}
2465 \label{sec:proc_reentrant}
2467 Si dice \textsl{rientrante} una funzione che può essere interrotta in
2468 qualunque punto della sua esecuzione ed essere chiamata una seconda volta da
2469 un altro thread di esecuzione senza che questo comporti nessun problema
2470 nell'esecuzione della stessa. La problematica è comune nella programmazione
2471 multi-thread, ma si hanno gli stessi problemi quando si vogliono chiamare
2472 delle funzioni all'interno dei manipolatori dei segnali.
2474 Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
2475 queste infatti vengono allocate nello stack, e un'altra invocazione non fa
2476 altro che allocarne un'altra copia. Una funzione può non essere rientrante
2477 quando opera su memoria che non è nello stack. Ad esempio una funzione non è
2478 mai rientrante se usa una variabile globale o statica.
2480 Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
2481 cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
2482 ogni volta e ritornato indietro la funzione può essere rientrante, se invece
2483 esso viene individuato dalla funzione stessa due chiamate alla stessa funzione
2484 potranno interferire quando entrambe faranno riferimento allo stesso oggetto.
2485 Allo stesso modo una funzione può non essere rientrante se usa e modifica un
2486 oggetto che le viene fornito dal chiamante: due chiamate possono interferire
2487 se viene passato lo stesso oggetto; in tutti questi casi occorre molta cura da
2488 parte del programmatore.
2490 In genere le funzioni di libreria non sono rientranti, molte di esse ad
2491 esempio utilizzano variabili statiche, le \acr{glibc} però mettono a
2492 disposizione due macro di compilatore, \macro{\_REENTRANT} e
2493 \macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di
2494 varie funzioni di libreria, che sono identificate aggiungendo il suffisso
2495 \code{\_r} al nome della versione normale.
2499 %%% Local Variables:
2501 %%% TeX-master: "gapil"