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 univoco, il cosiddetto \textit{process identifier} o, più brevemente,
36 \acr{pid}, assengnato in forma progressiva (vedi \secref{sec:proc_pid}) quando
37 il processo viene creato.
39 Una seconda caratteristica di un sistema Unix è che la generazione di un
40 processo è un'operazione separata rispetto al lancio di un programma. In
41 genere la sequenza è sempre quella di creare un nuovo processo, il quale
42 eseguirà, in un passo successivo, il programma desiderato: questo è ad esempio
43 quello che fa la shell quando mette in esecuzione il programma che gli
44 indichiamo nella linea di comando.
46 Una terza caratteristica è che ogni processo è sempre stato generato da un
47 altro, che viene chiamato processo padre (\textit{parent process}). Questo
48 vale per tutti i processi, con una sola eccezione: dato che ci deve essere un
49 punto di partenza esiste un processo speciale (che normalmente è
50 \cmd{/sbin/init}), che viene lanciato dal kernel alla conclusione della fase
51 di avvio; essendo questo il primo processo lanciato dal sistema ha sempre il
52 \acr{pid} uguale a 1 e non è figlio di nessun altro processo.
54 Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
55 partire tutti gli altri processi necessari al funzionamento del sistema,
56 inoltre \cmd{init} è essenziale per svolgere una serie di compiti
57 amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di
58 essi in \secref{sec:proc_termination}) e non può mai essere terminato. La
59 struttura del sistema comunque consente di lanciare al posto di \cmd{init}
60 qualunque altro programma, e in casi di emergenza (ad esempio se il file di
61 \cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
62 posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio.
67 [piccardi@gont piccardi]$ pstree -n
84 |-bash---startx---xinit-+-XFree86
85 | `-WindowMaker-+-ssh-agent
93 | |-wterm---bash---pstree
94 | `-wterm---bash-+-emacs
100 \caption{L'albero dei processi, così come riportato dal comando
102 \label{fig:proc_tree}
105 Dato che tutti i processi attivi nel sistema sono comunque generati da
106 \cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
107 vero, in Linux ci sono alcuni processi speciali che pur comparendo come
108 figli di \cmd{init}, o con \acr{pid} successivi, sono in realtà generati
109 direttamente dal kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.).} si
110 possono classificare i processi con la relazione padre/figlio in
111 un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
112 organizzati in un albero di directory (si veda
113 \secref{sec:file_organization}); in \figref{fig:proc_tree} si è mostrato il
114 risultato del comando \cmd{pstree} che permette di visualizzare questa
115 struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri
118 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
119 \textit{process table}; per ciascun processo viene mantenuta una voce nella
120 tabella dei processi costituita da una struttura \type{task\_struct}, che
121 contiene tutte le informazioni rilevanti per quel processo. Tutte le strutture
122 usate a questo scopo sono dichiarate nell'header file \file{linux/sched.h}, ed
123 uno schema semplificato, che riporta la struttura delle principali informazioni
124 contenute nella \type{task\_struct} (che in seguito incontreremo a più
125 riprese), è mostrato in \figref{fig:proc_task_struct}.
129 \includegraphics[width=13cm]{img/task_struct}
130 \caption{Schema semplificato dell'architettura delle strutture usate dal
131 kernel nella gestione dei processi.}
132 \label{fig:proc_task_struct}
136 Come accennato in \secref{sec:intro_unix_struct} è lo
137 \textit{scheduler}\index{scheduler} che decide quale processo mettere in
138 esecuzione; esso viene eseguito ad ogni system call ed ad ogni
139 interrupt,\footnote{più in una serie di altre occasioni. NDT completare questa
140 parte.} (ma può essere anche attivato esplicitamente). Il timer di sistema
141 provvede comunque a che esso sia invocato periodicamente, generando un
142 interrupt periodico secondo la frequenza specificata dalla costante
143 \macro{HZ}, definita in \file{asm/param.h}, ed il cui valore è espresso in
144 Hertz.\footnote{Il valore usuale di questa costante è 100, per tutte le
145 architetture eccetto l'alpha, per la quale è 1000. Occorre fare attenzione a
146 non confondere questo valore con quello dei clock tick (vedi
147 \secref{sec:sys_unix_time}).}
148 %Si ha cioè un interrupt dal timer ogni centesimo di secondo.
150 Ogni volta che viene eseguito, lo \textit{scheduler}\index{scheduler} effettua
151 il calcolo delle priorità dei vari processi attivi (torneremo su questo in
152 \secref{sec:proc_priority}) e stabilisce quale di essi debba essere posto in
153 esecuzione fino alla successiva invocazione.
156 \subsection{Una panoramica sulle funzioni fondamentali}
157 \label{sec:proc_handling_intro}
159 I processi vengono creati dalla funzione \func{fork}; in molti unix questa è
160 una system call, Linux però usa un'altra nomenclatura, e la funzione
161 \func{fork} è basata a sua volta sulla system call \func{\_\_clone}, che viene
162 usata anche per generare i \textit{thread}. Il processo figlio creato dalla
163 \func{fork} è una copia identica del processo processo padre, ma ha un nuovo
164 \acr{pid} e viene eseguito in maniera indipendente (le differenze fra padre e
165 figlio sono affrontate in dettaglio in \secref{sec:proc_fork}).
167 Se si vuole che il processo padre si fermi fino alla conclusione del processo
168 figlio questo deve essere specificato subito dopo la \func{fork} chiamando la
169 funzione \func{wait} o la funzione \func{waitpid} (si veda
170 \secref{sec:proc_wait}); queste funzioni restituiscono anche un'informazione
171 abbastanza limitata sulle cause della terminazione del processo figlio.
173 Quando un processo ha concluso il suo compito o ha incontrato un errore non
174 risolvibile esso può essere terminato con la funzione \func{exit} (si veda
175 quanto discusso in \secref{sec:proc_conclusion}). La vita del processo però
176 termina solo quando la notifica della sua conclusione viene ricevuta dal
177 processo padre, a quel punto tutte le risorse allocate nel sistema ad esso
178 associate vengono rilasciate.
180 Avere due processi che eseguono esattamente lo stesso codice non è molto
181 utile, normalmente si genera un secondo processo per affidargli l'esecuzione
182 di un compito specifico (ad esempio gestire una connessione dopo che questa è
183 stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per
184 quest'ultimo caso si usa la seconda funzione fondamentale per programmazione
185 coi processi che è la \func{exec}.
187 Il programma che un processo sta eseguendo si chiama immagine del processo (o
188 \textit{process image}), le funzioni della famiglia \func{exec} permettono di
189 caricare un'altro programma da disco sostituendo quest'ultimo all'immagine
190 corrente; questo fa sì che l'immagine precedente venga completamente
191 cancellata. Questo significa che quando il nuovo programma termina, anche il
192 processo termina, e non si può tornare alla precedente immagine.
194 Per questo motivo la \func{fork} e la \func{exec} sono funzioni molto
195 particolari con caratteristiche uniche rispetto a tutte le altre, infatti la
196 prima ritorna due volte (nel processo padre e nel figlio) mentre la seconda
197 non ritorna mai (in quanto con essa viene eseguito un altro programma).
201 \section{Le funzioni di base}% della gestione dei processi}
202 \label{sec:proc_handling}
204 In questa sezione tratteremo le problematiche della gestione dei processi
205 all'interno del sistema, illustrandone tutti i dettagli. Inizieremo con le
206 funzioni elementari che permettono di leggerne gli identificatori, per poi
207 passare alla spiegazione delle funzioni base che si usano per la creazione e
208 la terminazione dei processi, e per la messa in esecuzione degli altri
212 \subsection{Gli identificatori dei processi}
215 Come accennato nell'introduzione, ogni processo viene identificato dal sistema
216 da un numero identificativo univoco, il \textit{process id} o \acr{pid};
217 quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
218 intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
221 Il \acr{pid} viene assegnato in forma progressiva\footnote{in genere viene
222 assegnato il numero successivo a quello usato per l'ultimo processo creato,
223 a meno che questo numero non sia già utilizzato per un altro \acr{pid},
224 \acr{pgid} o \acr{sid} (vedi \secref{sec:sess_proc_group}).} ogni volta che
225 un nuovo processo viene creato, fino ad un limite che, essendo il \acr{pid} un
226 numero positivo memorizzato in un intero a 16 bit, arriva ad un massimo di
227 32768. Oltre questo valore l'assegnazione riparte dal numero più basso
228 disponibile a partire da un minimo di 300,\footnote{questi valori, fino al
229 kernel 2.4.x, sono definiti dalla macro \macro{PID\_MAX} in \file{threads.h}
230 e direttamente in \file{fork.c}, con il kernel 2.5.x e la nuova interfaccia
231 per i thread creata da Ingo Molnar anche il meccanismo di allocazione dei
232 \acr{pid} è stato modificato.} che serve a riservare i \acr{pid} più bassi
233 ai processi eseguiti dal direttamente dal kernel. Per questo motivo, come
234 visto in \secref{sec:proc_hierarchy}, il processo di avvio (\cmd{init}) ha
235 sempre il \acr{pid} uguale a uno.
237 Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
238 sono stati creati, questo viene chiamato in genere \acr{ppid} (da
239 \textit{parent process id}). Questi due identificativi possono essere
240 ottenuti da programma usando le funzioni:
242 \headdecl{sys/types.h} \headdecl{unistd.h} \funcdecl{pid\_t getpid(void)}
243 Restituisce il \acr{pid} del processo corrente. \funcdecl{pid\_t
244 getppid(void)} Restituisce il \acr{pid} del padre del processo corrente.
246 \bodydesc{Entrambe le funzioni non riportano condizioni di errore.}
248 \noindent esempi dell'uso di queste funzioni sono riportati in
249 \figref{fig:proc_fork_code}, nel programma di esempio \file{ForkTest.c}.
251 Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende un
252 candidato per generare ulteriori indicatori associati al processo di cui
253 diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
254 funzione \func{tmpname} (si veda \secref{sec:file_temp_file}) usa il \acr{pid}
255 per generare un pathname univoco, che non potrà essere replicato da un'altro
256 processo che usi la stessa funzione.
258 Tutti i processi figli dello stesso processo padre sono detti
259 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
260 sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
261 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
262 \secref{cha:session}, dove esamineremo gli altri identificativi associati ad
263 un processo e le varie relazioni fra processi utilizzate per definire una
266 Oltre al \acr{pid} e al \acr{ppid}, (e a quelli che vedremo in
267 \secref{sec:sess_proc_group}, relativi al controllo di sessione), ad ogni
268 processo vengono associati degli altri identificatori che vengono usati per il
269 controllo di accesso. Questi servono per determinare se un processo può
270 eseguire o meno le operazioni richieste, a seconda dei privilegi e
271 dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà
272 affrontato in dettaglio in \secref{sec:proc_perms}.
275 \subsection{La funzione \func{fork}}
276 \label{sec:proc_fork}
278 La funzione \func{fork} è la funzione fondamentale della gestione dei
279 processi: come si è detto l'unico modo di creare un nuovo processo è
280 attraverso l'uso di questa funzione, essa quindi riveste un ruolo centrale
281 tutte le volte che si devono scrivere programmi che usano il multitasking. Il
282 prototipo della funzione è:
284 \headdecl{sys/types.h}
286 \funcdecl{pid\_t fork(void)}
287 Crea un nuovo processo.
289 \bodydesc{In caso di successo restituisce il \acr{pid} del figlio al padre e
290 zero al figlio; ritorna -1 al padre (senza creare il figlio) in caso di
291 errore; \var{errno} può assumere i valori:
293 \item[\macro{EAGAIN}] non ci sono risorse sufficienti per creare un'altro
294 processo (per allocare la tabella delle pagine e le strutture del task) o
295 si è esaurito il numero di processi disponibili.
296 \item[\macro{ENOMEM}] non è stato possibile allocare la memoria per le
297 strutture necessarie al kernel per creare il nuovo processo.
301 Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
302 il processo figlio continuano ad essere eseguiti normalmente a partire
303 dall'istruzione seccessiva alla \func{fork}; il processo figlio è però una
304 copia del padre, e riceve una copia dei segmenti di testo, stack e dati (vedi
305 \secref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del
306 padre. Si tenga presente però che la memoria è copiata, non condivisa,
307 pertanto padre e figlio vedono variabili diverse.
309 Per quanto riguarda la gestione della memoria, in generale il segmento di
310 testo, che è identico per i due processi, è condiviso e tenuto in read-only
311 per il padre e per i figli. Per gli altri segmenti Linux utilizza la tecnica
312 del \textit{copy on write}\index{copy on write}; questa tecnica comporta che
313 una pagina di memoria viene effettivamente copiata per il nuovo processo solo
314 quando ci viene effettuata sopra una scrittura (e si ha quindi una reale
315 differenza fra padre e figlio). In questo modo si rende molto più efficiente
316 il meccanismo della creazione di un nuovo processo, non essendo più necessaria
317 la copia di tutto lo spazio degli indirizzi virtuali del padre, ma solo delle
318 pagine di memoria che sono state modificate, e solo al momento della modifica
321 La differenza che si ha nei due processi è che nel processo padre il valore di
322 ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
323 nel figlio è zero; in questo modo il programma può identificare se viene
324 eseguito dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni
325 \textbf{due} volte: una nel padre e una nel figlio.
327 La scelta di questi valori di ritorno non è casuale, un processo infatti può
328 avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
329 permette di identificare quello appena creato; al contrario un figlio ha
330 sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
331 \func{getppid}, vedi \secref{sec:proc_pid}) per cui si usa il valore nullo,
332 che non è il \acr{pid} di nessun processo.
337 #include <errno.h> /* error definitions and routines */
338 #include <stdlib.h> /* C standard library */
339 #include <unistd.h> /* unix standard library */
340 #include <stdio.h> /* standard I/O library */
341 #include <string.h> /* string functions */
343 /* Help printing routine */
346 int main(int argc, char *argv[])
349 * Variables definition
356 ... /* handling options */
357 nchild = atoi(argv[optind]);
358 printf("Test for forking %d child\n", nchild);
359 /* loop to fork children */
360 for (i=0; i<nchild; i++) {
361 if ( (pid = fork()) < 0) {
363 printf("Error on %d child creation, %s\n", i+1, strerror(errno));
366 if (pid == 0) { /* child */
367 printf("Child %d successfully executing\n", ++i);
368 if (wait_child) sleep(wait_child);
369 printf("Child %d, parent %d, exiting\n", i, getppid());
371 } else { /* parent */
372 printf("Spawned %d child, pid %d \n", i+1, pid);
373 if (wait_parent) sleep(wait_parent);
374 printf("Go to next child \n");
378 if (wait_end) sleep(wait_end);
382 \caption{Esempio di codice per la creazione di nuovi processi.}
383 \label{fig:proc_fork_code}
386 Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci
387 sono già troppi processi nel sistema (il che di solito è sintomo che
388 qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
389 sul numero totale di processi permessi all'utente (vedi
390 \secref{sec:sys_resource_limit}, ed in particolare
391 \tabref{tab:sys_rlimit_values}).
393 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
394 quella in cui all'interno di un programma si creano processi figli cui viene
395 affidata l'esecuzione di una certa sezione di codice, mentre il processo padre
396 ne esegue un'altra. È il caso tipico dei programmi server (il modello
397 \textit{client-server} è illustrato in \secref{sec:net_cliserv}) in cui il
398 padre riceve ed accetta le richieste da parte dei programmi client, per
399 ciascuna delle quali pone in esecuzione un figlio che è incaricato di fornire
402 La seconda modalità è quella in cui il processo vuole eseguire un altro
403 programma; questo è ad esempio il caso della shell. In questo caso il processo
404 crea un figlio la cui unica operazione è quella di fare una \func{exec} (di
405 cui parleremo in \secref{sec:proc_exec}) subito dopo la \func{fork}.
407 Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa
408 seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
409 operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
410 scelto di mantenere questa separazione, dato che, come per la prima modalità
411 d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
412 aver bisogno di eseguire una \func{exec}. Inoltre, anche nel caso della
413 seconda modalità d'uso, avere le due funzioni separate permette al figlio di
414 cambiare gli attributi del processo (maschera dei segnali, redirezione
415 dell'output, identificatori) prima della \func{exec}, rendendo così
416 relativamente facile intervenire sulle le modalità di esecuzione del nuovo
419 In \figref{fig:proc_fork_code} è riportato il corpo del codice del programma
420 di esempio \cmd{forktest}, che permette di illustrare molte caratteristiche
421 dell'uso della funzione \func{fork}. Il programma crea un numero di figli
422 specificato da linea di comando, e prende anche alcune opzioni per indicare
423 degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
424 \func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
425 descrizione delle opzioni); il codice completo, compresa la parte che gestisce
426 le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
427 distribuito insieme agli altri sorgenti degli esempi su
428 \href{http://gapil.firenze.linux.it/gapil_source.tgz}
429 {\texttt{http://gapil.firenze.linux.it/gapil\_source.tgz}}.
431 Decifrato il numero di figli da creare, il ciclo principale del programma
432 (\texttt{\small 24--40}) esegue in successione la creazione dei processi figli
433 controllando il successo della chiamata a \func{fork} (\texttt{\small
434 25--29}); ciascun figlio (\texttt{\small 31--34}) si limita a stampare il
435 suo numero di successione, eventualmente attendere il numero di secondi
436 specificato e scrivere un messaggio prima di uscire. Il processo padre invece
437 (\texttt{\small 36--38}) stampa un messaggio di creazione, eventualmente
438 attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
439 alla conclusione del ciclo, prima di uscire, può essere specificato un altro
442 Se eseguiamo il comando senza specificare attese (come si può notare in
443 \texttt{\small 17--19} i valori predefiniti specificano di non attendere),
444 otterremo come output sul terminale:
448 [piccardi@selidor sources]$ ./forktest 3
449 Process 1963: forking 3 child
450 Spawned 1 child, pid 1964
451 Child 1 successfully executing
452 Child 1, parent 1963, exiting
454 Spawned 2 child, pid 1965
455 Child 2 successfully executing
456 Child 2, parent 1963, exiting
458 Child 3 successfully executing
459 Child 3, parent 1963, exiting
460 Spawned 3 child, pid 1966
465 Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
466 si può dire quale processo fra il padre ed il figlio venga eseguito per
467 primo\footnote{a partire dal kernel 2.5.2-pre10 è stato introdotto il nuovo
468 scheduler\index{scheduler} di Ingo Molnar che esegue sempre per primo il
469 figlio; per mantenere la portabilità è opportuno non fare comunque
470 affidamento su questo comportamento.} dopo la chiamata a \func{fork};
471 dall'esempio si può notare infatti come nei primi due cicli sia stato eseguito
472 per primo il padre (con la stampa del \acr{pid} del nuovo processo) per poi
473 passare all'esecuzione del figlio (completata con i due avvisi di esecuzione
474 ed uscita), e tornare all'esecuzione del padre (con la stampa del passaggio al
475 ciclo successivo), mentre la terza volta è stato prima eseguito il figlio
476 (fino alla conclusione) e poi il padre.
478 In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
479 scheduling usato dal kernel, dalla particolare situazione in si trova la
480 macchina al momento della chiamata, risultando del tutto impredicibile.
481 Eseguendo più volte il programma di prova e producendo un numero diverso di
482 figli, si sono ottenute situazioni completamente diverse, compreso il caso in
483 cui il processo padre ha eseguito più di una \func{fork} prima che uno dei
484 figli venisse messo in esecuzione.
486 Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
487 istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
488 essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
489 occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
490 rischio di incorrere nelle cosiddette
491 \textit{race condition}\index{race condition}
492 (vedi \secref{sec:proc_race_cond}).
494 Si noti inoltre che essendo i segmenti di memoria utilizzati dai singoli
495 processi completamente separati, le modifiche delle variabili nei processi
496 figli (come l'incremento di \var{i} in \texttt{\small 31}) sono visibili solo
497 a loro (ogni processo vede solo la propria copia della memoria), e non hanno
498 alcun effetto sul valore che le stesse variabili hanno nel processo padre (ed
499 in eventuali altri processi figli che eseguano lo stesso codice).
501 Un secondo aspetto molto importante nella creazione dei processi figli è
502 quello dell'interazione dei vari processi con i file; per illustrarlo meglio
503 proviamo a redirigere su un file l'output del nostro programma di test, quello
508 [piccardi@selidor sources]$ ./forktest 3 > output
509 [piccardi@selidor sources]$ cat output
510 Process 1967: forking 3 child
511 Child 1 successfully executing
512 Child 1, parent 1967, exiting
513 Test for forking 3 child
514 Spawned 1 child, pid 1968
516 Child 2 successfully executing
517 Child 2, parent 1967, exiting
518 Test for forking 3 child
519 Spawned 1 child, pid 1968
521 Spawned 2 child, pid 1969
523 Child 3 successfully executing
524 Child 3, parent 1967, exiting
525 Test for forking 3 child
526 Spawned 1 child, pid 1968
528 Spawned 2 child, pid 1969
530 Spawned 3 child, pid 1970
534 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
536 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
537 in gran dettaglio in \capref{cha:file_unix_interface} e in
538 \secref{cha:files_std_interface}. Qui basta accennare che si sono usate le
539 funzioni standard della libreria del C che prevedono l'output bufferizzato; e
540 questa bufferizzazione (trattata in dettaglio in \secref{sec:file_buffering})
541 varia a seconda che si tratti di un file su disco (in cui il buffer viene
542 scaricato su disco solo quando necessario) o di un terminale (nel qual caso il
543 buffer viene scaricato ad ogni carattere di a capo).
545 Nel primo esempio allora avevamo che ad ogni chiamata a \func{printf} il
546 buffer veniva scaricato, e le singole righe erano stampate a video subito dopo
547 l'esecuzione della \func{printf}. Ma con la redirezione su file la scrittura
548 non avviene più alla fine di ogni riga e l'output resta nel buffer. Dato che
549 ogni figlio riceve una copia della memoria del padre, esso riceverà anche
550 quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte dal
551 padre fino allora. Così quando il buffer viene scritto su disco all'uscita del
552 figlio, troveremo nel file anche tutto quello che il processo padre aveva
553 scritto prima della sua creazione. E alla fine del file (dato che in questo
554 caso il padre esce per ultimo) troveremo anche l'output completo del padre.
556 L'esempio ci mostra un'altro aspetto fondamentale dell'interazione con i file,
557 valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
558 solo processi diversi possono scrivere in contemporanea sullo stesso file
559 (l'argomento della condivisione dei file è trattato in dettaglio in
560 \secref{sec:file_sharing}), ma anche che, a differenza di quanto avviene per
561 le variabili, la posizione corrente sul file è condivisa fra il padre e tutti
564 Quello che succede è che quando lo standard output del padre viene rediretto,
565 lo stesso avviene anche per tutti i figli; la funzione \func{fork} infatti ha
566 la caratteristica di duplicare (allo stesso modo in cui lo fa la funzione
567 \func{dup}, trattata in \secref{sec:file_dup}) nei figli tutti i file
568 descriptor aperti nel padre, il che comporta che padre e figli condividono le
569 stesse voci della \textit{file table} (per la spiegazione di questi termini si
570 veda \secref{sec:file_sharing}) e fra cui c'è anche la posizione corrente nel
573 In questo modo se un processo scrive sul file aggiornerà la posizione corrente
574 sulla \textit{file table}, e tutti gli altri processi, che vedono la stessa
575 \textit{file table}, vedranno il nuovo valore. In questo modo si evita, in
576 casi come quello appena mostrato in cui diversi processi scrivono sullo stesso
577 file, che l'output successivo di un processo vada a sovrapporsi a quello dei
578 precedenti: l'output potrà risultare mescolato, ma non ci saranno parti
579 perdute per via di una sovrascrittura.
581 Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
582 crea un figlio e attende la sua conclusione per proseguire, ed entrambi
583 scrivono sullo stesso file (un caso tipico è la shell quando lancia un
584 programma, il cui output va sullo standard output).
586 In questo modo, anche se l'output viene rediretto, il padre potrà sempre
587 continuare a scrivere in coda a quanto scritto dal figlio in maniera
588 automatica; se così non fosse ottenere questo comportamento sarebbe
589 estremamente complesso necessitando di una qualche forma di comunicazione fra
590 i due processi per far riprendere al padre la scrittura al punto giusto.
592 In generale comunque non è buona norma far scrivere più processi sullo stesso
593 file senza una qualche forma di sincronizzazione in quanto, come visto anche
594 con il nostro esempio, le varie scritture risulteranno mescolate fra loro in
595 una sequenza impredicibile. Per questo le modalità con cui in genere si usano
596 i file dopo una \func{fork} sono sostanzialmente due:
598 \item Il processo padre aspetta la conclusione del figlio. In questo caso non
599 è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
600 della posizione corrente dopo eventuali operazioni di lettura e scrittura
601 effettuate dal figlio è automatica.
602 \item L'esecuzione di padre e figlio procede indipendentemente. In questo caso
603 ciascuno dei due processi deve chiudere i file che non gli servono una volta
604 che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
607 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
608 proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
609 comune dopo l'esecuzione di una \func{fork} è la seguente:
611 \item i file aperti e gli eventuali flag di \textit{close-on-exec} impostati
612 (vedi \secref{sec:proc_exec} e \secref{sec:file_fcntl}).
613 \item gli identificatori per il controllo di accesso: l'\textsl{userid reale},
614 il \textsl{groupid reale}, l'\textsl{userid effettivo}, il \textsl{groupid
615 effettivo} ed i \textit{groupid supplementari} (vedi
616 \secref{sec:proc_access_id}).
617 \item gli identificatori per il controllo di sessione: il \textit{process
618 groupid} e il \textit{session id} ed il terminale di controllo (vedi
619 \secref{sec:sess_proc_group}).
620 \item la directory di lavoro e la directory radice (vedi
621 \secref{sec:file_work_dir} e \secref{sec:file_chroot}).
622 \item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}).
623 \item la maschera dei segnali bloccati (vedi \secref{sec:sig_sigmask}) e le
624 azioni installate (vedi \secref{sec:sig_gen_beha}).
625 \item i segmenti di memoria condivisa agganciati al processo (vedi
626 \secref{sec:ipc_sysv_shm}).
627 \item i limiti sulle risorse (vedi \secref{sec:sys_resource_limit}).
628 \item le variabili di ambiente (vedi \secref{sec:proc_environ}).
630 le differenze fra padre e figlio dopo la \func{fork} invece sono:
632 \item il valore di ritorno di \func{fork}.
633 \item il \acr{pid} (\textit{process id}).
634 \item il \acr{ppid} (\textit{parent process id}), quello del figlio viene
635 impostato al \acr{pid} del padre.
636 \item i valori dei tempi di esecuzione della struttura \var{tms} (vedi
637 \secref{sec:sys_cpu_times}) che nel figlio sono posti a zero.
638 \item i \textit{file lock} (vedi \secref{sec:file_locking}), che non
639 vengono ereditati dal figlio.
640 \item gli allarmi ed i segnali pendenti (vedi \secref{sec:sig_gen_beha}), che
641 per il figlio vengono cancellati.
645 \subsection{La funzione \func{vfork}}
646 \label{sec:proc_vfork}
648 La funzione \func{vfork} è esattamente identica a \func{fork} ed ha la stessa
649 semantica e gli stessi errori; la sola differenza è che non viene creata la
650 tabella delle pagine né la struttura dei task per il nuovo processo. Il
651 processo padre è posto in attesa fintanto che il figlio non ha eseguito una
652 \func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la
653 memoria del padre (e modifiche possono avere effetti imprevedibili) e non deve
654 ritornare o uscire con \func{exit} ma usare esplicitamente \func{\_exit}.
656 Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una
657 \func{fork} comportava anche la copia completa del segmento dati del processo
658 padre, che costituiva un inutile appesantimento in tutti quei casi in cui la
659 \func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione
660 venne introdotta in BSD per migliorare le prestazioni.
662 Dato che Linux supporta il \textit{copy on write}\index{copy on write} la
663 perdita di prestazioni è assolutamente trascurabile, e l'uso di questa
664 funzione (che resta un caso speciale della funzione \func{clone}), è
665 deprecato; per questo eviteremo di trattarla ulteriormente.
668 \subsection{La conclusione di un processo.}
669 \label{sec:proc_termination}
671 In \secref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
672 chiudere un programma, ma dall'interno del programma stesso; avendo a che fare
673 con un sistema multitasking resta da affrontare l'argomento dal punto di vista
674 di come il sistema gestisce la conclusione dei processi.
676 Abbiamo visto in \secref{sec:proc_conclusion} le tre modalità con cui un
677 programma viene terminato in maniera normale: la chiamata di \func{exit} (che
678 esegue le funzioni registrate per l'uscita e chiude gli stream), il ritorno
679 dalla funzione \func{main} (equivalente alla chiamata di \func{exit}), e la
680 chiamata ad \func{\_exit} (che passa direttamente alle operazioni di
681 terminazione del processo da parte del kernel).
683 Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle
684 modalità di conclusione anomala; queste sono in sostanza due: il programma può
685 chiamare la funzione \func{abort} per invocare una chiusura anomala, o essere
686 terminato da un segnale. In realtà anche la prima modalità si riconduce alla
687 seconda, dato che \func{abort} si limita a generare il segnale
690 Qualunque sia la modalità di conclusione di un processo, il kernel esegue
691 comunque una serie di operazioni: chiude tutti i file aperti, rilascia la
692 memoria che stava usando, e così via; l'elenco completo delle operazioni
693 eseguite alla chiusura di un processo è il seguente:
695 \item tutti i file descriptor sono chiusi.
696 \item viene memorizzato lo stato di terminazione del processo.
697 \item ad ogni processo figlio viene assegnato un nuovo padre (in genere
699 \item viene inviato il segnale \macro{SIGCHLD} al processo padre (vedi
700 \secref{sec:sig_sigchld}).
701 \item se il processo è un leader di sessione ed il suo terminale di controllo
702 è quello della sessione viene mandato un segnale di \macro{SIGHUP} a tutti i
703 processi del gruppo di foreground e il terminale di controllo viene
704 disconnesso (vedi \secref{sec:sess_ctrl_term}).
705 \item se la conclusione di un processo rende orfano un \textit{process
706 group} ciascun membro del gruppo viene bloccato, e poi gli vengono
707 inviati in successione i segnali \macro{SIGHUP} e \macro{SIGCONT}
708 (vedi ancora \secref{sec:sess_ctrl_term}).
711 Oltre queste operazioni è però necessario poter disporre di un meccanismo
712 ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
713 un sistema unix-like tutto viene gestito attraverso i processi, il meccanismo
714 scelto consiste nel riportare lo stato di terminazione (il cosiddetto
715 \textit{termination status}) al processo padre.
717 Nel caso di conclusione normale, abbiamo visto in \secref{sec:proc_conclusion}
718 che lo stato di uscita del processo viene caratterizzato tramite il valore del
719 cosiddetto \textit{exit status}, cioè il valore passato alle funzioni
720 \func{exit} o \func{\_exit} (o dal valore di ritorno per \func{main}). Ma se
721 il processo viene concluso in maniera anomala il programma non può specificare
722 nessun \textit{exit status}, ed è il kernel che deve generare autonomamente il
723 \textit{termination status} per indicare le ragioni della conclusione anomala.
725 Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
726 quello che contraddistingue lo stato di chiusura del processo e viene
727 riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
728 \secref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale
729 il kernel usa il primo (nel codice eseguito da \func{\_exit}) per produrre il
732 La scelta di riportare al padre lo stato di terminazione dei figli, pur
733 essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
734 alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
735 che sia così alla sua conclusione, dato che il padre potrebbe essere già
736 terminato (si potrebbe avere cioè quello che si chiama un processo
739 Questa complicazione viene superata facendo in modo che il processo orfano
740 venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
741 termina, il kernel controlla se è il padre di altri processi in esecuzione: in
742 caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito
743 con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
744 avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo})
745 cui riportare il suo stato di terminazione. Come verifica di questo
746 comportamento possiamo eseguire il nostro programma \cmd{forktest} imponendo a
747 ciascun processo figlio due secondi di attesa prima di uscire, il risultato è:
751 [piccardi@selidor sources]$ ./forktest -c2 3
752 Process 1972: forking 3 child
753 Spawned 1 child, pid 1973
754 Child 1 successfully executing
756 Spawned 2 child, pid 1974
757 Child 2 successfully executing
759 Child 3 successfully executing
760 Spawned 3 child, pid 1975
762 [piccardi@selidor sources]$ Child 3, parent 1, exiting
763 Child 2, parent 1, exiting
764 Child 1, parent 1, exiting
767 come si può notare in questo caso il processo padre si conclude prima dei
768 figli, tornando alla shell, che stampa il prompt sul terminale: circa due
769 secondi dopo viene stampato a video anche l'output dei tre figli che
770 terminano, e come si può notare in questo caso, al contrario di quanto visto
771 in precedenza, essi riportano 1 come \acr{ppid}.
773 Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
774 perché non è detto che il padre possa ricevere immediatamente lo stato di
775 terminazione, quindi il kernel deve comunque conservare una certa quantità di
776 informazioni riguardo ai processi che sta terminando.
778 Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
779 memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
780 dal processo (vedi \secref{sec:sys_unix_time}) e lo stato di terminazione,
781 mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. I
782 processi che sono terminati, ma il cui stato di terminazione non è stato
783 ancora ricevuto dal padre sono chiamati \textit{zombie}, essi restano presenti
784 nella tabella dei processi ed in genere possono essere identificati
785 dall'output di \cmd{ps} per la presenza di una \texttt{Z} nella colonna che ne
786 indica lo stato (vedi \tabref{tab:proc_proc_states}). Quando il padre
787 effettuerà la lettura dello stato di uscita anche questa informazione, non più
788 necessaria, verrà scartata e la terminazione potrà dirsi completamente
791 Possiamo utilizzare il nostro programma di prova per analizzare anche questa
792 condizione: lanciamo il comando \cmd{forktest} in background, indicando al
793 processo padre di aspettare 10 secondi prima di uscire; in questo caso, usando
794 \cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi)
799 [piccardi@selidor sources]$ ps T
800 PID TTY STAT TIME COMMAND
801 419 pts/0 S 0:00 bash
802 568 pts/0 S 0:00 ./forktest -e10 3
803 569 pts/0 Z 0:00 [forktest <defunct>]
804 570 pts/0 Z 0:00 [forktest <defunct>]
805 571 pts/0 Z 0:00 [forktest <defunct>]
806 572 pts/0 R 0:00 ps T
809 e come si vede, dato che non si è fatto nulla per riceverne lo stato di
810 terminazione, i tre processi figli sono ancora presenti pur essendosi
811 conclusi, con lo stato di zombie e l'indicazione che sono stati terminati.
813 La possibilità di avere degli zombie deve essere tenuta sempre presente quando
814 si scrive un programma che deve essere mantenuto in esecuzione a lungo e
815 creare molti figli. In questo caso si deve sempre avere cura di far leggere
816 l'eventuale stato di uscita di tutti i figli (in genere questo si fa
817 attraverso un apposito \textit{signal handler}, che chiama la funzione
818 \func{wait}, vedi \secref{sec:sig_sigchld} e \secref{sec:proc_wait}). Questa
819 operazione è necessaria perché anche se gli \textit{zombie} non consumano
820 risorse di memoria o processore, occupano comunque una voce nella tabella dei
821 processi, che a lungo andare potrebbe esaurirsi.
823 Si noti che quando un processo adottato da \cmd{init} termina, esso non
824 diviene uno \textit{zombie}; questo perché una delle funzioni di \cmd{init} è
825 appunto quella di chiamare la funzione \func{wait} per i processi cui fa da
826 padre, completandone la terminazione. Questo è quanto avviene anche quando,
827 come nel caso del precedente esempio con \cmd{forktest}, il padre termina con
828 dei figli in stato di zombie: alla sua terminazione infatti tutti i suoi figli
829 (compresi gli zombie) verranno adottati da \cmd{init}, il quale provvederà a
830 completarne la terminazione.
832 Si tenga presente infine che siccome gli zombie sono processi già usciti, non
833 c'è modo di eliminarli con il comando \cmd{kill}; l'unica possibilità di
834 cancellarli dalla tabella dei processi è quella di terminare il processo che
835 li ha generati, in modo che \cmd{init} possa adottarli e provvedere a
836 concluderne la terminazione.
839 \subsection{Le funzioni \func{wait} e \func{waitpid}}
840 \label{sec:proc_wait}
842 Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
843 consiste nella creazione di programmi di tipo server, in cui un processo
844 principale attende le richieste che vengono poi soddisfatte da una serie di
845 processi figli. Si è già sottolineato al paragrafo precedente come in questo
846 caso diventi necessario gestire esplicitamente la conclusione dei figli onde
847 evitare di riempire di \textit{zombie} la tabella dei processi; le funzioni
848 deputate a questo compito sono sostanzialmente due, \func{wait} e
849 \func{waitpid}. La prima, il cui prototipo è:
851 \headdecl{sys/types.h}
852 \headdecl{sys/wait.h}
853 \funcdecl{pid\_t wait(int *status)}
855 Sospende il processo corrente finché un figlio non è uscito, o finché un
856 segnale termina il processo o chiama una funzione di gestione.
858 \bodydesc{La funzione restituisce il \acr{pid} del figlio in caso di successo
859 e -1 in caso di errore; \var{errno} può assumere i valori:
861 \item[\macro{EINTR}] la funzione è stata interrotta da un segnale.
865 è presente fin dalle prime versioni di Unix; la funzione ritorna non appena un
866 processo figlio termina. Se un figlio è già terminato la funzione ritorna
869 Al ritorno, lo stato di terminazione del processo viene salvato nella
870 variabile puntata da \var{status} e tutte le informazioni relative al
871 processo (vedi \secref{sec:proc_termination}) vengono rilasciate. Nel
872 caso un processo abbia più figli il valore di ritorno permette di
873 identificare qual'è quello che è uscito.
875 Questa funzione ha il difetto di essere poco flessibile, in quanto
876 ritorna all'uscita di un figlio qualunque. Nelle occasioni in cui è
877 necessario attendere la conclusione di un processo specifico occorre
878 predisporre un meccanismo che tenga conto dei processi già terminati, e
879 provveda a ripetere la chiamata alla funzione nel caso il processo
880 cercato sia ancora attivo.
882 Per questo motivo lo standard POSIX.1 ha introdotto la funzione \func{waitpid}
883 che effettua lo stesso servizio, ma dispone di una serie di funzionalità più
884 ampie, legate anche al controllo di sessione (si veda
885 \ref{sec:sess_job_control}). Dato che è possibile ottenere lo stesso
886 comportamento di \func{wait} si consiglia di utilizzare sempre questa
887 funzione, il cui prototipo è:
889 \headdecl{sys/types.h}
890 \headdecl{sys/wait.h}
891 \funcdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
892 Attende la conclusione di un processo figlio.
894 \bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se
895 è stata specificata l'opzione \macro{WNOHANG} e il processo non è uscito e
896 -1 per un errore, nel qual caso \var{errno} assumerà i valori:
898 \item[\macro{EINTR}] se non è stata specificata l'opzione \macro{WNOHANG} e
899 la funzione è stata interrotta da un segnale.
900 \item[\macro{ECHILD}] il processo specificato da \param{pid} non esiste o
901 non è figlio del processo chiamante.
905 Le differenze principali fra le due funzioni sono che \func{wait} si blocca
906 sempre fino a che un processo figlio non termina, mentre \func{waitpid} ha la
907 possibilità si specificare un'opzione \macro{WNOHANG} che ne previene il
908 blocco; inoltre \func{waitpid} può specificare quale processo attendere sulla
909 base del valore fornito dall'argomento \param{pid}, secondo lo
910 specchietto riportato in \tabref{tab:proc_waidpid_pid}:
914 \begin{tabular}[c]{|c|c|p{8cm}|}
916 \textbf{Valore} & \textbf{Macro} &\textbf{Significato}\\
919 $<-1$& -- & attende per un figlio il cui \textit{process group} (vedi
920 \secref{sec:sess_proc_group}) è uguale al
921 valore assoluto di \var{pid}. \\
922 $-1$ & \macro{WAIT\_ANY} & attende per un figlio qualsiasi, usata in
923 questa maniera è equivalente a \func{wait}.\\
924 $0$ & \macro{WAIT\_MYPGRP} & attende per un figlio il cui \textit{process
925 group} è uguale a quello del processo chiamante. \\
926 $>0$ & -- &attende per un figlio il cui \acr{pid} è uguale al
927 valore di \var{pid}.\\
930 \caption{Significato dei valori del parametro \var{pid} della funzione
932 \label{tab:proc_waidpid_pid}
935 Il comportamento di \func{waitpid} può inoltre essere modificato passando
936 delle opportune opzioni tramite l'argomento \param{option}. I valori possibili
937 sono il già citato \macro{WNOHANG}, che previene il blocco della funzione
938 quando il processo figlio non è terminato, e \macro{WUNTRACED}. Quest'ultimo
939 viene generalmente usato per il controllo di sessione, (trattato in
940 \secref{sec:sess_job_control}) in quanto permette di identificare i processi
941 bloccati. La funzione infatti in tal caso ritorna, restituendone il \acr{pid},
942 se c'è un processo figlio che è entrato in stato di sleep (vedi
943 \tabref{tab:proc_proc_states}) di cui non si è ancora letto lo stato (con
944 questa stessa opzione). Il valore dell'opzione deve essere specificato come
945 maschera binaria ottenuta con l'OR delle suddette costanti con zero. In Linux
946 sono previste altre opzioni non standard relative al comportamento con i
947 thread, che saranno trattate in \secref{sec:thread_xxx}.
949 La terminazione di un processo figlio è chiaramente un evento asincrono
950 rispetto all'esecuzione di un programma e può avvenire in un qualunque
951 momento. Per questo motivo, come accennato nella sezione precedente, una delle
952 azioni prese dal kernel alla conclusione di un processo è quella di mandare un
953 segnale di \macro{SIGCHLD} al padre. L'azione predefinita (si veda
954 \secref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua
955 generazione costituisce il meccanismo di comunicazione asincrona con cui il
956 kernel avverte il processo padre che uno dei suoi figli è terminato.
958 In genere in un programma non si vuole essere forzati ad attendere la
959 conclusione di un processo per proseguire, specie se tutto questo serve solo
960 per leggerne lo stato di chiusura (ed evitare la presenza di \textit{zombie}),
961 per questo la modalità più usata per chiamare queste funzioni è quella di
962 utilizzarle all'interno di un \textit{signal handler} (vedremo un esempio di
963 come gestire \macro{SIGCHLD} con i segnali in \secref{sec:sig_example}). In
964 questo caso infatti, dato che il segnale è generato dalla terminazione di un
965 figlio, avremo la certezza che la chiamata a \func{wait} non si bloccherà.
970 \begin{tabular}[c]{|c|p{10cm}|}
972 \textbf{Macro} & \textbf{Descrizione}\\
975 \macro{WIFEXITED(s)} & Condizione vera (valore non nullo) per un processo
976 figlio che sia terminato normalmente. \\
977 \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello
978 stato di uscita del processo (passato attraverso \func{\_exit}, \func{exit}
979 o come valore di ritorno di \func{main}). Può essere valutata solo se
980 \macro{WIFEXITED} ha restituito un valore non nullo.\\
981 \macro{WIFSIGNALED(s)} & Vera se il processo figlio è terminato
982 in maniera anomala a causa di un segnale che non è stato catturato (vedi
983 \secref{sec:sig_notification}).\\
984 \macro{WTERMSIG(s)} & restituisce il numero del segnale che ha causato
985 la terminazione anomala del processo. Può essere valutata solo se
986 \macro{WIFSIGNALED} ha restituito un valore non nullo.\\
987 \macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un
988 file si \textit{core dump}. Può essere valutata solo se
989 \macro{WIFSIGNALED} ha restituito un valore non nullo.\footnote{questa
990 macro non è definita dallo standard POSIX.1, ma è presente come estensione
991 sia in Linux che in altri Unix.}\\
992 \macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di
993 \func{waitpid} è bloccato. L'uso è possibile solo avendo specificato
994 l'opzione \macro{WUNTRACED}. \\
995 \macro{WSTOPSIG(s)} & restituisce il numero del segnale che ha bloccato
996 il processo, Può essere valutata solo se \macro{WIFSTOPPED} ha
997 restituito un valore non nullo. \\
1000 \caption{Descrizione delle varie macro di preprocessore utilizzabili per
1001 verificare lo stato di terminazione \var{s} di un processo.}
1002 \label{tab:proc_status_macro}
1005 Entrambe le funzioni di attesa restituiscono lo stato di terminazione del
1006 processo tramite il puntatore \param{status} (se non interessa memorizzare lo
1007 stato si può passare un puntatore nullo). Il valore restituito da entrambe le
1008 funzioni dipende dall'implementazione, e tradizionalmente alcuni bit (in
1009 genere 8) sono riservati per memorizzare lo stato di uscita, e altri per
1010 indicare il segnale che ha causato la terminazione (in caso di conclusione
1011 anomala), uno per indicare se è stato generato un core file, ecc.\footnote{le
1012 definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
1013 questo file non deve mai essere usato direttamente, esso viene incluso
1014 attraverso \file{<sys/wait.h>}.}
1016 Lo standard POSIX.1 definisce una serie di macro di preprocessore da usare per
1017 analizzare lo stato di uscita. Esse sono definite sempre in
1018 \file{<sys/wait.h>} ed elencate in \tabref{tab:proc_status_macro} (si tenga
1019 presente che queste macro prendono come parametro la variabile di tipo
1020 \ctyp{int} puntata da \var{status}).
1022 Si tenga conto che nel caso di conclusione anomala il valore restituito da
1023 \macro{WTERMSIG} può essere confrontato con le costanti definite in
1024 \file{signal.h} ed elencate in \tabref{tab:sig_signal_list}, e stampato usando
1025 le apposite funzioni trattate in \secref{sec:sig_strsignal}.
1028 \subsection{Le funzioni \func{wait3} e \func{wait4}}
1029 \label{sec:proc_wait4}
1031 Linux, seguendo un'estensione di BSD, supporta altre due funzioni per la
1032 lettura dello stato di terminazione di un processo \func{wait3} e
1033 \func{wait4}, analoghe alle precedenti ma che prevedono un ulteriore
1034 parametro attraverso il quale il kernel può restituire al padre informazioni
1035 sulle risorse usate dal processo terminato e dai vari figli. I prototipi di
1036 queste funzioni, che diventano accessibili definendo la costante
1037 \macro{\_USE\_BSD}, sono:
1039 \headdecl{sys/times.h} \headdecl{sys/types.h} \headdecl{sys/wait.h}
1040 \headdecl{sys/resource.h}
1042 \funcdecl{pid\_t wait4(pid\_t pid, int * status, int options, struct rusage
1044 È identica a \func{waitpid} sia per comportamento che per i valori dei
1045 parametri, ma restituisce in \param{rusage} un sommario delle risorse usate
1048 \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
1049 Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
1050 ormai deprecata in favore di \func{wait4}.
1053 la struttura \type{rusage} è definita in \file{sys/resource.h}, e viene
1054 utilizzata anche dalla funzione \func{getrusage} (vedi
1055 \secref{sec:sys_resource_use}) per ottenere le risorse di sistema usate da un
1056 processo; la sua definizione è riportata in \figref{fig:sys_rusage_struct}.
1059 \subsection{Le funzioni \func{exec}}
1060 \label{sec:proc_exec}
1062 Abbiamo già detto che una delle modalità principali con cui si utilizzano i
1063 processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
1064 fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
1065 processo chiama una di queste funzioni esso viene completamente sostituito dal
1066 nuovo programma; il \acr{pid} del processo non cambia, dato che non viene
1067 creato un nuovo processo, la funzione semplicemente rimpiazza lo stack, lo
1068 heap, i dati ed il testo del processo corrente con un nuovo programma letto da
1071 Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
1072 famiglia di funzioni) che possono essere usate per questo compito, in realtà
1073 (come mostrato in \figref{fig:proc_exec_relat}), sono tutte un front-end a
1074 \func{execve}. Il prototipo di quest'ultima è:
1075 \begin{prototype}{unistd.h}
1076 {int execve(const char *filename, char *const argv[], char *const envp[])}
1077 Esegue il programma contenuto nel file \param{filename}.
1079 \bodydesc{La funzione ritorna solo in caso di errore, restituendo -1; nel
1080 qual caso \var{errno} può assumere i valori:
1082 \item[\macro{EACCES}] il file non è eseguibile, oppure il filesystem è
1083 montato in \cmd{noexec}, oppure non è un file regolare o un interprete.
1084 \item[\macro{EPERM}] il file ha i bit \acr{suid} o \acr{sgid}, l'utente non
1085 è root, e o il processo viene tracciato, o il filesystem è montato con
1086 l'opzione \cmd{nosuid}.
1087 \item[\macro{ENOEXEC}] il file è in un formato non eseguibile o non
1088 riconosciuto come tale, o compilato per un'altra architettura.
1089 \item[\macro{ENOENT}] il file o una delle librerie dinamiche o l'interprete
1090 necessari per eseguirlo non esistono.
1091 \item[\macro{ETXTBSY}] L'eseguibile è aperto in scrittura da uno o più
1093 \item[\macro{EINVAL}] L'eseguibile ELF ha più di un segmento
1094 \macro{PF\_INTERP}, cioè chiede di essere eseguito da più di un
1096 \item[\macro{ELIBBAD}] Un interprete ELF non è in un formato
1099 ed inoltre anche \macro{EFAULT}, \macro{ENOMEM}, \macro{EIO},
1100 \macro{ENAMETOOLONG}, \macro{E2BIG}, \macro{ELOOP}, \macro{ENOTDIR},
1101 \macro{ENFILE}, \macro{EMFILE}.}
1104 La funzione \func{exec} esegue il file o lo script indicato da
1105 \var{filename}, passandogli la lista di argomenti indicata da \var{argv}
1106 e come ambiente la lista di stringhe indicata da \var{envp}; entrambe le
1107 liste devono essere terminate da un puntatore nullo. I vettori degli
1108 argomenti e dell'ambiente possono essere acceduti dal nuovo programma
1109 quando la sua funzione \func{main} è dichiarata nella forma
1110 \code{main(int argc, char *argv[], char *envp[])}.
1112 Le altre funzioni della famiglia servono per fornire all'utente una serie
1113 possibile di diverse interfacce per la creazione di un nuovo processo. I loro
1117 \funcdecl{int execl(const char *path, const char *arg, ...)}
1118 \funcdecl{int execv(const char *path, char *const argv[])}
1119 \funcdecl{int execle(const char *path, const char *arg, ..., char
1121 \funcdecl{int execlp(const char *file, const char *arg, ...)}
1122 \funcdecl{int execvp(const char *file, char *const argv[])}
1124 Sostituiscono l'immagine corrente del processo con quella indicata nel primo
1125 argomento. I parametri successivi consentono di specificare gli argomenti a
1126 linea di comando e l'ambiente ricevuti dal nuovo processo.
1128 \bodydesc{Queste funzioni ritornano solo in caso di errore, restituendo -1;
1129 nel qual caso \var{errno} assumerà i valori visti in precedenza per
1133 Per capire meglio le differenze fra le funzioni della famiglia si può fare
1134 riferimento allo specchietto riportato in \tabref{tab:proc_exec_scheme}. La
1135 prima differenza riguarda le modalità di passaggio dei parametri che poi
1136 andranno a costituire gli argomenti a linea di comando (cioè i valori di
1137 \var{argv} e \var{argc} visti dalla funzione \func{main} del programma
1140 Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
1141 che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
1142 gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
1143 stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
1144 questo vettore \emph{deve} essere terminato da un puntatore nullo.
1146 Nel secondo caso le stringhe degli argomenti sono passate alla funzione come
1147 lista di puntatori, nella forma:
1148 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
1149 char *arg0, char *arg1, ..., char *argn, NULL
1151 che deve essere terminata da un puntatore nullo. In entrambi i casi vale la
1152 convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
1153 per indicare il nome del file che contiene il programma che verrà eseguito.
1158 \begin{tabular}[c]{|l|c|c|c||c|c|c|}
1160 \multicolumn{1}{|c|}{\textbf{Caratteristiche}} &
1161 \multicolumn{6}{|c|}{\textbf{Funzioni}} \\
1163 &\func{execl\ }&\func{execlp}&\func{execle}
1164 &\func{execv\ }& \func{execvp}& \func{execve} \\
1167 argomenti a lista &$\bullet$&$\bullet$&$\bullet$&&& \\
1168 argomenti a vettore &&&&$\bullet$&$\bullet$&$\bullet$\\
1170 filename completo &&$\bullet$&&&$\bullet$& \\
1171 ricerca su \var{PATH}&$\bullet$&&$\bullet$&$\bullet$&&$\bullet$ \\
1173 ambiente a vettore &&&$\bullet$&&&$\bullet$ \\
1174 uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\
1177 \caption{Confronto delle caratteristiche delle varie funzioni della
1178 famiglia \func{exec}.}
1179 \label{tab:proc_exec_scheme}
1182 La seconda differenza fra le funzioni riguarda le modalità con cui si
1183 specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si
1184 indicano le due funzioni che replicano il comportamento della shell nello
1185 specificare il comando da eseguire; quando il parametro \var{file} non
1186 contiene una \file{/} esso viene considerato come un nome di programma, e
1187 viene eseguita automaticamente una ricerca fra i file presenti nella lista di
1188 directory specificate dalla variabile di ambiente \var{PATH}. Il file che
1189 viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
1190 relativo a permessi di accesso insufficienti (cioè l'esecuzione della
1191 sottostante \func{execve} ritorna un \macro{EACCESS}), la ricerca viene
1192 proseguita nelle eventuali ulteriori directory indicate in \var{PATH}; solo se
1193 non viene trovato nessun altro file viene finalmente restituito
1196 Le altre quattro funzioni si limitano invece a cercare di eseguire il file
1197 indicato dal parametro \var{path}, che viene interpretato come il
1198 \textit{pathname} del programma.
1202 \includegraphics[width=15cm]{img/exec_rel}
1203 \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
1204 \label{fig:proc_exec_relat}
1207 La terza differenza è come viene passata la lista delle variabili di ambiente.
1208 Con lo mnemonico \code{e} vengono indicate quelle funzioni che necessitano di
1209 un vettore di parametri \var{envp[]} analogo a quello usato per gli argomenti
1210 a riga di comando (terminato quindi da un \macro{NULL}), le altre usano il
1211 valore della variabile \var{environ} (vedi \secref{sec:proc_environ}) del
1212 processo di partenza per costruire l'ambiente.
1214 Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da
1215 \func{exec} assume anche una serie di altre proprietà del processo chiamante;
1216 la lista completa è la seguente:
1218 \item il \textit{process id} (\acr{pid}) ed il \textit{parent process id}
1220 \item l'\textsl{userid reale}, il \textit{groupid reale} ed i \textsl{groupid
1221 supplementari} (vedi \secref{sec:proc_access_id}).
1222 \item il \textit{session id} (\acr{sid}) ed il \textit{process groupid}
1223 (\acr{pgid}), vedi \secref{sec:sess_proc_group}.
1224 \item il terminale di controllo (vedi \secref{sec:sess_ctrl_term}).
1225 \item il tempo restante ad un allarme (vedi \secref{sec:sig_alarm_abort}).
1226 \item la directory radice e la directory di lavoro corrente (vedi
1227 \secref{sec:file_work_dir}).
1228 \item la maschera di creazione dei file (\var{umask}, vedi
1229 \secref{sec:file_umask}) ed i \textit{lock} sui file (vedi
1230 \secref{sec:file_locking}).
1231 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
1232 \secref{sec:sig_sigmask}).
1233 \item i limiti sulle risorse (vedi \secref{sec:sys_resource_limit}).
1234 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
1235 \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:sys_cpu_times}).
1238 Inoltre i segnali che sono stati impostati per essere ignorati nel processo
1239 chiamante mantengono la stessa impostazione pure nel nuovo programma, tutti
1240 gli altri segnali vengono impostati alla loro azione predefinita. Un caso
1241 speciale è il segnale \macro{SIGCHLD} che, quando impostato a
1242 \macro{SIG\_IGN}, può anche non essere reimpostato a \macro{SIG\_DFL} (si veda
1243 \secref{sec:sig_gen_beha}).
1245 La gestione dei file aperti dipende dal valore che ha il flag di
1246 \textit{close-on-exec} (trattato in \secref{sec:file_fcntl}) per ciascun file
1247 descriptor. I file per cui è impostato vengono chiusi, tutti gli altri file
1248 restano aperti. Questo significa che il comportamento predefinito è che i file
1249 restano aperti attraverso una \func{exec}, a meno di una chiamata esplicita a
1250 \func{fcntl} che imposti il suddetto flag.
1252 Per le directory, lo standard POSIX.1 richiede che esse vengano chiuse
1253 attraverso una \func{exec}, in genere questo è fatto dalla funzione
1254 \func{opendir} (vedi \secref{sec:file_dir_read}) che effettua da sola
1255 l'impostazione del flag di \textit{close-on-exec} sulle directory che apre, in
1256 maniera trasparente all'utente.
1258 Abbiamo detto che l'\textsl{userid reale} ed il \textsl{groupid reale} restano
1259 gli stessi all'esecuzione di \func{exec}; lo stesso vale per l'\textsl{userid
1260 effettivo} ed il \textsl{groupid effettivo} (il significato di questi
1261 identificatori è trattato in \secref{sec:proc_access_id}), tranne quando il
1262 file che si va ad eseguire abbia o il \acr{suid} bit o lo \acr{sgid} bit
1263 impostato, in questo caso l'\textsl{userid effettivo} ed il \textsl{groupid
1264 effettivo} vengono impostati rispettivamente all'utente o al gruppo cui il
1265 file appartiene (per i dettagli vedi \secref{sec:proc_perms}).
1267 Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
1268 condivise, viene lanciato il \textit{linker} dinamico \cmd{ld.so} prima del
1269 programma per caricare le librerie necessarie ed effettuare il link
1270 dell'eseguibile. Se il programma è in formato ELF per caricare le librerie
1271 dinamiche viene usato l'interprete indicato nel segmento \macro{PT\_INTERP},
1272 in genere questo è \file{/lib/ld-linux.so.1} per programmi linkati con le
1273 \acr{libc5}, e \file{/lib/ld-linux.so.2} per programmi linkati con le
1274 \acr{glibc}. Infine nel caso il file sia uno script esso deve iniziare con
1275 una linea nella forma \cmd{\#!/path/to/interpreter} dove l'interprete indicato
1276 deve esse un valido programma (binario, non un altro script) che verrà
1277 chiamato come se si fosse eseguito il comando \cmd{interpreter [arg]
1280 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
1281 basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo
1282 processo, con \func{exec} si lancia un nuovo programma, con \func{exit} e
1283 \func{wait} si effettua e verifica la conclusione dei processi. Tutte le
1284 altre funzioni sono ausiliarie e servono per la lettura e l'impostazione dei
1285 vari parametri connessi ai processi.
1289 \section{Il controllo di accesso}
1290 \label{sec:proc_perms}
1292 In questa sezione esamineremo le problematiche relative al controllo di
1293 accesso dal punto di vista del processi; vedremo quali sono gli identificatori
1294 usati, come questi possono essere modificati nella creazione e nel lancio di
1295 nuovi processi, le varie funzioni per la loro manipolazione diretta e tutte le
1296 problematiche connesse ad una gestione accorta dei privilegi.
1299 \subsection{Gli identificatori del controllo di accesso}
1300 \label{sec:proc_access_id}
1302 Come accennato in \secref{sec:intro_multiuser} il modello base\footnote{in
1303 realtà già esistono estensioni di questo modello base, che lo rendono più
1304 flessibile e controllabile, come le \textit{capabilities}, le ACL per i file
1305 o il \textit{Mandatory Access Control} di SELinux; inoltre basandosi sul
1306 lavoro effettuato con SELinux, a partire dal kernel 2.5.x, è iniziato lo
1307 sviluppo di una infrastruttura di sicurezza, il \textit{Linux Security
1308 Modules}, ol LSM, in grado di fornire diversi agganci a livello del kernel
1309 per modularizzare tutti i possibili controlli di accesso.} di sicurezza di
1310 un sistema unix-like è fondato sui concetti di utente e gruppo, e sulla
1311 separazione fra l'amministratore (\textsl{root}, detto spesso anche
1312 \textit{superuser}) che non è sottoposto a restrizioni, ed il resto degli
1313 utenti, per i quali invece vengono effettuati i vari controlli di accesso.
1315 %Benché il sistema sia piuttosto semplice (è basato su un solo livello di
1316 % separazione) il sistema permette una
1317 %notevole flessibilità,
1319 Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
1320 identificatori univoci, lo userid ed il groupid; questi servono al kernel per
1321 identificare uno specifico utente o un gruppo di utenti, per poi poter
1322 controllare che essi siano autorizzati a compiere le operazioni richieste. Ad
1323 esempio in \secref{sec:file_access_control} vedremo come ad ogni file vengano
1324 associati un utente ed un gruppo (i suoi \textsl{proprietari}, indicati
1325 appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati dal
1326 kernel nella gestione dei permessi di accesso.
1328 Dato che tutte le operazioni del sistema vengono compiute dai processi, è
1329 evidente che per poter implementare un controllo sulle operazioni occorre
1330 anche poter identificare chi è che ha lanciato un certo programma, e pertanto
1331 anche a ciascun processo dovrà essere associato ad un utente e ad un gruppo.
1333 Un semplice controllo di una corrispondenza fra identificativi non garantisce
1334 però sufficiente flessibilità per tutti quei casi in cui è necessario poter
1335 disporre di privilegi diversi, o dover impersonare un altro utente per un
1336 limitato insieme di operazioni. Per questo motivo in generale tutti gli Unix
1337 prevedono che i processi abbiano almeno due gruppi di identificatori, chiamati
1338 rispettivamente \textit{real} ed \textit{effective} (cioè \textsl{reali} ed
1339 \textsl{effettivi}). Nel caso di Linux si aggiungono poi altri due gruppi, il
1340 \textit{saved} (\textsl{salvati}) ed il \textit{filesystem} (\textsl{di
1341 filesystem}), secondo la situazione illustrata in \tabref{tab:proc_uid_gid}.
1346 \begin{tabular}[c]{|c|c|l|p{7.3cm}|}
1348 \textbf{Suffisso} & \textbf{Gruppo} & \textbf{Denominazione}
1349 & \textbf{Significato} \\
1352 \acr{uid} & \textit{real} & \textsl{userid reale}
1353 & indica l'utente che ha lanciato il programma\\
1354 \acr{gid} & '' &\textsl{groupid reale}
1355 & indica il gruppo principale dell'utente che ha lanciato
1358 \acr{euid} & \textit{effective} &\textsl{userid effettivo}
1359 & indica l'utente usato nel controllo di accesso \\
1360 \acr{egid} & '' & \textsl{groupid effettivo}
1361 & indica il gruppo usato nel controllo di accesso \\
1362 -- & -- & \textsl{groupid supplementari}
1363 & indicano gli ulteriori gruppi cui l'utente appartiene \\
1365 -- & \textit{saved} & \textsl{userid salvato}
1366 & è una copia dell'\acr{euid} iniziale\\
1367 -- & '' & \textsl{groupid salvato}
1368 & è una copia dell'\acr{egid} iniziale \\
1370 \acr{fsuid} & \textit{filesystem} &\textsl{userid di filesystem}
1371 & indica l'utente effettivo per l'accesso al filesystem \\
1372 \acr{fsgid} & '' & \textsl{groupid di filesystem}
1373 & indica il gruppo effettivo per l'accesso al filesystem \\
1376 \caption{Identificatori di utente e gruppo associati a ciascun processo con
1377 indicazione dei suffissi usati dalle varie funzioni di manipolazione.}
1378 \label{tab:proc_uid_gid}
1381 Al primo gruppo appartengono l'\textsl{userid reale} ed il \textsl{groupid
1382 reale}: questi vengono impostati al login ai valori corrispondenti
1383 all'utente con cui si accede al sistema (e relativo gruppo principale).
1384 Servono per l'identificazione dell'utente e normalmente non vengono mai
1385 cambiati. In realtà vedremo (in \secref{sec:proc_setuid}) che è possibile
1386 modificarli, ma solo ad un processo che abbia i privilegi di amministratore;
1387 questa possibilità è usata proprio dal programma \cmd{login} che, una volta
1388 completata la procedura di autenticazione, lancia una shell per la quale
1389 imposta questi identificatori ai valori corrispondenti all'utente che entra
1392 Al secondo gruppo appartengono lo \textsl{userid effettivo} ed il
1393 \textsl{groupid effettivo} (a cui si aggiungono gli eventuali \textsl{groupid
1394 supplementari} dei gruppi dei quali l'utente fa parte). Questi sono invece
1395 gli identificatori usati nella verifiche dei permessi del processo e per il
1396 controllo di accesso ai file (argomento affrontato in dettaglio in
1397 \secref{sec:file_perm_overview}).
1399 Questi identificatori normalmente sono identici ai corrispondenti del gruppo
1400 \textit{real} tranne nel caso in cui, come accennato in
1401 \secref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit
1402 \acr{suid} o \acr{sgid} impostati (il significato di questi bit è affrontato
1403 in dettaglio in \secref{sec:file_suid_sgid}). In questo caso essi saranno
1404 impostati all'utente e al gruppo proprietari del file. Questo consente, per
1405 programmi in cui ci sia necessità, di dare a qualunque utente normale
1406 privilegi o permessi di un'altro (o dell'amministratore).
1408 Come nel caso del \acr{pid} e del \acr{ppid} tutti questi identificatori
1409 possono essere letti dal processo attraverso delle opportune funzioni, i cui
1410 prototipi sono i seguenti:
1413 \headdecl{sys/types.h}
1414 \funcdecl{uid\_t getuid(void)} Restituisce l'\textsl{userid reale} del
1417 \funcdecl{uid\_t geteuid(void)} Restituisce l'\textsl{userid effettivo} del
1420 \funcdecl{gid\_t getgid(void)} Restituisce il \textsl{groupid reale} del
1423 \funcdecl{gid\_t getegid(void)} Restituisce il \textsl{groupid effettivo}
1424 del processo corrente.
1426 \bodydesc{Queste funzioni non riportano condizioni di errore.}
1429 In generale l'uso di privilegi superiori deve essere limitato il più
1430 possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
1431 un meccanismo che consenta ad un programma di rilasciare gli eventuali
1432 maggiori privilegi necessari, una volta che si siano effettuate le operazioni
1433 per i quali erano richiesti, e a poterli eventualmente recuperare in caso
1436 Questo in Linux viene fatto usando altri gli altri due gruppi di
1437 identificatori, il \textit{saved} ed il \textit{filesystem}. Il primo gruppo è
1438 lo stesso usato in SVr4, e previsto dallo standard POSIX quando è definita la
1439 costante \macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la
1440 portabilità del programma su altri Unix è buona norma controllare sempre la
1441 disponibilità di queste funzioni controllando se questa costante è
1442 definita.} il secondo gruppo è specifico di Linux e viene usato per
1443 migliorare la sicurezza con NFS.
1445 L'\textsl{userid salvato} ed il \textsl{groupid salvato} sono copie
1446 dell'\textsl{userid effettivo} e del \textsl{groupid effettivo} del processo
1447 padre, e vengono impostati dalla funzione \func{exec} all'avvio del processo,
1448 come copie dell'\textsl{userid effettivo} e del \textsl{groupid effettivo}
1449 dopo che questo sono stati impostati tenendo conto di eventuali \acr{suid} o
1450 \acr{sgid}. Essi quindi consentono di tenere traccia di quale fossero utente
1451 e gruppo effettivi all'inizio dell'esecuzione di un nuovo programma.
1453 L'\textsl{userid di filesystem} e il \textsl{groupid di filesystem} sono
1454 un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
1455 (torneremo sull'argomento in \secref{sec:proc_setfsuid}). Essi sono una
1456 replica dei corrispondenti identificatori del gruppo \textit{effective}, ai
1457 quali si sostituiscono per tutte le operazioni di verifica dei permessi
1458 relativi ai file (trattate in \secref{sec:file_perm_overview}). Ogni
1459 cambiamento effettuato sugli identificatori effettivi viene automaticamente
1460 riportato su di essi, per cui in condizioni normali si può tranquillamente
1461 ignorarne l'esistenza, in quanto saranno del tutto equivalenti ai precedenti.
1464 \subsection{Le funzioni \func{setuid} e \func{setgid}}
1465 \label{sec:proc_setuid}
1467 Le due funzioni che vengono usate per cambiare identità (cioè utente e gruppo
1468 di appartenenza) ad un processo sono rispettivamente \func{setuid} e
1469 \func{setgid}; come accennato in \secref{sec:proc_access_id} in Linux esse
1470 seguono la semantica POSIX che prevede l'esistenza dell'\textit{userid
1471 salvato} e del \textit{groupid salvato}; i loro prototipi sono:
1474 \headdecl{sys/types.h}
1476 \funcdecl{int setuid(uid\_t uid)} Imposta l'\textsl{userid} del processo
1479 \funcdecl{int setgid(gid\_t gid)} Imposta il \textsl{groupid} del processo
1482 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1483 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1486 Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
1487 la prima; la seconda si comporta esattamente allo stesso modo facendo
1488 riferimento al \textsl{groupid} invece che all'\textsl{userid}. Gli
1489 eventuali \textsl{groupid supplementari} non vengono modificati.
1491 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
1492 l'\textsl{userid effettivo} è zero (cioè è quello dell'amministratore di
1493 sistema) allora tutti gli identificatori (\textit{real}, \textit{effective} e
1494 \textit{saved}) vengono impostati al valore specificato da \var{uid},
1495 altrimenti viene impostato solo l'\textsl{userid effettivo}, e soltanto se il
1496 valore specificato corrisponde o all'\textsl{userid reale} o
1497 all'\textsl{userid salvato}. Negli altri casi viene segnalato un errore (con
1500 Come accennato l'uso principale di queste funzioni è quello di poter
1501 consentire ad un programma con i bit \acr{suid} o \acr{sgid} impostati (vedi
1502 \secref{sec:file_suid_sgid}) di riportare l'\textsl{userid effettivo} a quello
1503 dell'utente che ha lanciato il programma, effettuare il lavoro che non
1504 necessita di privilegi aggiuntivi, ed eventualmente tornare indietro.
1506 Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
1507 viene gestito l'accesso al file \file{/var/log/utmp}. In questo file viene
1508 registrato chi sta usando il sistema al momento corrente; chiaramente non può
1509 essere lasciato aperto in scrittura a qualunque utente, che potrebbe
1510 falsificare la registrazione. Per questo motivo questo file (e l'analogo
1511 \file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad
1512 un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad
1513 esempio tutti i programmi di terminale in X, o il programma \cmd{screen} che
1514 crea terminali multipli su una console) appartengono a questo gruppo ed hanno
1515 il bit \acr{sgid} impostato.
1517 Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
1518 situazione degli identificatori è la seguente:
1521 \textsl{groupid reale} &=& \textrm{\acr{gid} (del chiamante)} \\
1522 \textsl{groupid effettivo} &=& \textrm{\acr{utmp}} \\
1523 \textsl{groupid salvato} &=& \textrm{\acr{utmp}}
1525 in questo modo, dato che il \textsl{groupid effettivo} è quello giusto, il
1526 programma può accedere a \file{/var/log/utmp} in scrittura ed aggiornarlo. A
1527 questo punto il programma può eseguire una \code{setgid(getgid())} per
1528 impostare il \textsl{groupid effettivo} a quello dell'utente (e dato che il
1529 \textsl{groupid reale} corrisponde la funzione avrà successo), in questo modo
1530 non sarà possibile lanciare dal terminale programmi che modificano detto file,
1531 in tal caso infatti la situazione degli identificatori sarebbe:
1534 \textsl{groupid reale} &=& \textrm{\acr{gid} (invariato)} \\
1535 \textsl{groupid effettivo} &=& \textrm{\acr{gid}} \\
1536 \textsl{groupid salvato} &=& \textrm{\acr{utmp} (invariato)}
1538 e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
1539 \textsl{groupid effettivo}. All'uscita dal terminale, per poter di nuovo
1540 aggiornare lo stato di \file{/var/log/utmp} il programma eseguirà una
1541 \code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
1542 \acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
1543 in questo caso il valore richiesto corrisponde al \textsl{groupid salvato} la
1544 funzione avrà successo e riporterà la situazione a:
1547 \textsl{groupid reale} &=& \textrm{\acr{gid} (invariato)} \\
1548 \textsl{groupid effettivo} &=& \textrm{\acr{utmp}} \\
1549 \textsl{groupid salvato} &=& \textrm{\acr{utmp} (invariato)}
1551 consentendo l'accesso a \file{/var/log/utmp}.
1553 Occorre però tenere conto che tutto questo non è possibile con un processo con
1554 i privilegi di root, in tal caso infatti l'esecuzione una \func{setuid}
1555 comporta il cambiamento di tutti gli identificatori associati al processo,
1556 rendendo impossibile riguadagnare i privilegi di amministratore. Questo
1557 comportamento è corretto per l'uso che ne fa \cmd{login} una volta che crea
1558 una nuova shell per l'utente; ma quando si vuole cambiare soltanto
1559 l'\textsl{userid effettivo} del processo per cedere i privilegi occorre
1560 ricorrere ad altre funzioni (si veda ad esempio \secref{sec:proc_seteuid}).
1563 \subsection{Le funzioni \func{setreuid} e \func{setresuid}}
1564 \label{sec:proc_setreuid}
1566 Queste due funzioni derivano da BSD che, non supportando\footnote{almeno fino
1567 alla versione 4.3+BSD TODO, FIXME verificare e aggiornare la nota.} gli
1568 identificatori del gruppo \textit{saved}, le usa per poter scambiare fra di
1569 loro \textit{effective} e \textit{real}. I loro prototipi sono:
1572 \headdecl{sys/types.h}
1574 \funcdecl{int setreuid(uid\_t ruid, uid\_t euid)} Imposta l'\textsl{userid
1575 reale} e l'\textsl{userid effettivo} del processo corrente ai valori
1576 specificati da \var{ruid} e \var{euid}.
1578 \funcdecl{int setregid(gid\_t rgid, gid\_t egid)} Imposta il \textsl{groupid
1579 reale} ed il \textsl{groupid effettivo} del processo corrente ai valori
1580 specificati da \var{rgid} e \var{egid}.
1582 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1583 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1586 La due funzioni sono analoghe ed il loro comportamento è identico; quanto
1587 detto per la prima prima riguardo l'userid, si applica immediatamente alla
1588 seconda per il groupid. I processi non privilegiati possono impostare solo i
1589 valori del loro userid effettivo o reale; valori diversi comportano il
1590 fallimento della chiamata; l'amministratore invece può specificare un valore
1591 qualunque. Specificando un argomento di valore -1 l'identificatore
1592 corrispondente verrà lasciato inalterato.
1594 Con queste funzioni si possono scambiare fra loro gli userid reale e
1595 effettivo, e pertanto è possibile implementare un comportamento simile a
1596 quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo
1597 scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un secondo
1600 In questo caso però occorre porre molta attenzione quando si creano nuovi
1601 processi nella fase intermedia in cui si sono scambiati gli identificatori, in
1602 questo caso infatti essi avranno un userid reale privilegiato, che dovrà
1603 essere esplicitamente eliminato prima di porre in esecuzione un nuovo
1604 programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e
1605 prima della \func{exec} per uniformare l'userid reale a quello effettivo) in
1606 caso contrario il nuovo programma potrebbe a sua volta effettuare uno scambio
1607 e riottenere privilegi non previsti.
1609 Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
1610 si pone per l'userid salvato: questa funzione deriva da un'implementazione che
1611 non ne prevede la presenza, e quindi non è possibile usarla per correggere la
1612 situazione come nel caso precedente. Per questo motivo in Linux tutte le volte
1613 che si imposta un qualunque valore diverso da quello dall'userid reale
1614 corrente, l'userid salvato viene automaticamente uniformato al valore
1615 dell'userid effettivo.
1618 \subsection{Le funzioni \func{seteuid} e \func{setegid}}
1619 \label{sec:proc_seteuid}
1621 Queste funzioni sono un'estensione allo standard POSIX.1 (ma sono comunque
1622 supportate dalla maggior parte degli Unix) e vengono usate per cambiare gli
1623 identificatori del gruppo \textit{effective}; i loro prototipi sono:
1626 \headdecl{sys/types.h}
1628 \funcdecl{int seteuid(uid\_t uid)} Imposta l'userid effettivo del processo
1629 corrente a \var{uid}.
1631 \funcdecl{int setegid(gid\_t gid)} Imposta il groupid effettivo del processo
1632 corrente a \var{gid}.
1634 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1635 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1638 Come per le precedenti le due funzioni sono identiche, per cui tratteremo solo
1639 la prima. Gli utenti normali possono impostare l'userid effettivo solo al
1640 valore dell'userid reale o dell'userid salvato, l'amministratore può
1641 specificare qualunque valore. Queste funzioni sono usate per permettere
1642 all'amministratore di impostare solo l'userid effettivo, dato che l'uso
1643 normale di \func{setuid} comporta l'impostazione di tutti gli identificatori.
1646 \subsection{Le funzioni \func{setresuid} e \func{setresgid}}
1647 \label{sec:proc_setresuid}
1649 Queste due funzioni sono un'estensione introdotta in Linux dal kernel 2.1.44,
1650 e permettono un completo controllo su tutti gli identificatori (\textit{real},
1651 \textit{effective} e \textit{saved}), i prototipi sono:
1654 \headdecl{sys/types.h}
1656 \funcdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} Imposta
1657 l'userid reale, l'userid effettivo e l'userid salvato del processo corrente
1658 ai valori specificati rispettivamente da \var{ruid}, \var{euid} e \var{suid}.
1660 \funcdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} Imposta il
1661 groupid reale, il groupid effettivo ed il groupid salvato del processo
1662 corrente ai valori specificati rispettivamente da \var{rgid}, \var{egid} e
1665 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1666 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1669 Le due funzioni sono identiche, quanto detto per la prima riguardo gli userid
1670 si applica alla seconda per i groupid. I processi non privilegiati possono
1671 cambiare uno qualunque degli userid solo ad un valore corripondente o
1672 all'userid reale, o a quello effettivo o a quello salvato, l'amministratore
1673 può specificare i valori che vuole; un valore di -1 per un qualunque parametro
1674 lascia inalterato l'identificatore corrispondente.
1676 Per queste funzioni esistono anche due controparti che permettono di leggere
1677 in blocco i vari identificatori: \func{getresuid} e \func{getresgid}; i loro
1681 \headdecl{sys/types.h}
1683 \funcdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)} Legge
1684 l'userid reale, l'userid effettivo e l'userid salvato del processo corrente.
1686 \funcdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)} Legge il
1687 groupid reale, il groupid effettivo e il groupid salvato del processo
1690 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
1691 fallimento: l'unico errore possibile è \macro{EFAULT} se gli indirizzi delle
1692 variabili di ritorno non sono validi.}
1695 Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
1696 nessun privilegio. I valori sono restituiti negli argomenti, che vanno
1697 specificati come puntatori (è un'altro esempio di \textit{value result
1698 argument}). Si noti che queste funzioni sono le uniche in grado di leggere
1699 gli identificatori del gruppo \textit{saved}.
1702 \subsection{Le funzioni \func{setfsuid} e \func{setfsgid}}
1703 \label{sec:proc_setfsuid}
1705 Queste funzioni sono usate per impostare gli identificatori del gruppo
1706 \textit{filesystem} che usati da Linux per il controllo dell'accesso ai file.
1707 Come già accennato in \secref{sec:proc_access_id} Linux definisce questo
1708 ulteriore gruppo di identificatori, che di norma sono assolutamente
1709 equivalenti a quelli del gruppo \textit{effective}, dato che ogni cambiamento
1710 di questi ultimi viene immediatamente riportato su di essi.
1712 C'è un solo caso in cui si ha necessità di introdurre una differenza fra gli
1713 identificatori dei gruppi \textit{effective} e \textit{filesystem}, ed è per
1714 ovviare ad un problema di sicurezza che si presenta quando si deve
1715 implementare un server NFS. Il server NFS infatti deve poter cambiare
1716 l'identificatore con cui accede ai file per assumere l'identità del singolo
1717 utente remoto, ma se questo viene fatto cambiando l'userid effettivo o
1718 l'userid reale il server si espone alla ricezione di eventuali segnali ostili
1719 da parte dell'utente di cui ha temporaneamente assunto l'identità. Cambiando
1720 solo l'userid di filesystem si ottengono i privilegi necessari per accedere ai
1721 file, mantenendo quelli originari per quanto riguarda tutti gli altri
1722 controlli di accesso, così che l'utente non possa inviare segnali al server
1725 Le due funzioni usate per cambiare questi identificatori sono \func{setfsuid}
1726 e \func{setfsgid}, ovviamente sono specifiche di Linux e non devono essere
1727 usate se si intendono scrivere programmi portabili; i loro prototipi sono:
1729 \headdecl{sys/fsuid.h}
1731 \funcdecl{int setfsuid(uid\_t fsuid)} Imposta l'userid di filesystem del
1732 processo corrente a \var{fsuid}.
1734 \funcdecl{int setfsgid(gid\_t fsgid)} Imposta il groupid di filesystem del
1735 processo corrente a \var{fsgid}.
1737 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1738 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1740 \noindent queste funzioni hanno successo solo se il processo chiamante ha i
1741 privilegi di amministratore o, per gli altri utenti, se il valore specificato
1742 coincide con uno dei di quelli del gruppo \textit{real}, \textit{effective} o
1746 \subsection{Le funzioni \func{setgroups} e \func{getgroups}}
1747 \label{sec:proc_setgroups}
1749 Le ultime funzioni che esamineremo sono quelle che permettono di operare sui
1750 gruppi supplementari. Ogni processo può avere fino a \macro{NGROUPS\_MAX}
1751 gruppi supplementari in aggiunta al gruppo primario, questi vengono ereditati
1752 dal processo padre e possono essere cambiati con queste funzioni.
1754 La funzione che permette di leggere i gruppi supplementari è \func{getgroups};
1755 questa funzione è definita nello standard POSIX ed il suo prototipo è:
1757 \headdecl{sys/types.h}
1760 \funcdecl{int getgroups(int size, gid\_t list[])} Legge gli identificatori
1761 dei gruppi supplementari del processo sul vettore \param{list} di dimensione
1764 \bodydesc{La funzione restituisce il numero di gruppi letti in caso di
1765 successo e -1 in caso di fallimento, nel qual caso \var{errno} assumerà
1768 \item[\macro{EFAULT}] \param{list} non ha un indirizzo valido.
1769 \item[\macro{EINVAL}] il valore di \param{size} è diverso da zero ma
1770 minore del numero di gruppi supplementari del processo.
1773 \noindent non è specificato se la funzione inserisca o meno nella lista
1774 il groupid effettivo del processo. Se si specifica un valore di \param{size}
1775 uguale a 0 \param{list} non viene modificato, ma si ottiene il numero di
1776 gruppi supplementari.
1778 Una seconda funzione, \func{getgrouplist}, può invece essere usata per
1779 ottenere tutti i gruppi a cui appartiene un utente; il suo prototipo è:
1781 \headdecl{sys/types.h}
1784 \funcdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups,
1785 int *ngroups)} Legge i gruppi supplementari dell'utente \param{user}.
1787 \bodydesc{La funzione legge fino ad un massimo di \param{ngroups} valori,
1788 restituisce 0 in caso di successo e -1 in caso di fallimento.}
1790 \noindent la funzione esegue una scansione del database dei gruppi (si veda
1791 \secref{sec:sys_user_group}) e ritorna in \param{groups} la lista di quelli a
1792 cui l'utente appartiene. Si noti che \param{ngroups} è passato come puntatore
1793 perché qualora il valore specificato sia troppo piccolo la funzione ritorna
1794 -1, passando indietro il numero dei gruppi trovati.
1796 Per impostare i gruppi supplementari di un processo ci sono due funzioni, che
1797 possono essere usate solo se si hanno i privilegi di amministratore. La prima
1798 delle due è \func{setgroups}, ed il suo prototipo è:
1800 \headdecl{sys/types.h}
1803 \funcdecl{int setgroups(size\_t size, gid\_t *list)} Imposta i gruppi
1804 supplementari del processo ai valori specificati in \param{list}.
1806 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1807 fallimento, nel qual caso \var{errno} assumerà i valori:
1809 \item[\macro{EFAULT}] \param{list} non ha un indirizzo valido.
1810 \item[\macro{EPERM}] il processo non ha i privilegi di amministratore.
1811 \item[\macro{EINVAL}] il valore di \param{size} è maggiore del valore
1812 massimo (\macro{NGROUPS}, che per Linux è 32).
1816 Se invece si vogliono impostare i gruppi supplementari del processo a quelli di
1817 un utente specifico, si può usare \func{initgroups} il cui prototipo è:
1819 \headdecl{sys/types.h}
1822 \funcdecl{int initgroups(const char *user, gid\_t group)} Imposta i gruppi
1823 supplementari del processo a quelli di cui è membro l'utente \param{user},
1824 aggiungendo il gruppo addizionale \param{group}.
1826 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1827 fallimento, nel qual caso \var{errno} assumerà gli stessi valori di
1828 \func{setgroups} più \macro{ENOMEM} quando non c'è memoria sufficiente per
1829 allocare lo spazio per informazioni dei gruppi.}
1832 La funzione esegue la scansione del database dei gruppi (usualmente
1833 \file{/etc/groups}) cercando i gruppi di cui è membro \param{user} e
1834 costruendo una lista di gruppi supplementari a cui aggiunge \param{group}, che
1835 poi imposta usando \func{setgroups}.
1836 Si tenga presente che sia \func{setgroups} che \func{initgroups} non sono
1837 definite nello standard POSIX.1 e che pertanto non è possibile utilizzarle
1838 quando si definisce \macro{\_POSIX\_SOURCE} o si compila con il flag
1842 \section{La gestione della priorità di esecuzione}
1843 \label{sec:proc_priority}
1845 In questa sezione tratteremo più approfonditamente i meccanismi con il quale
1846 lo \textit{scheduler}\index{scheduler} assegna la CPU ai vari processi attivi.
1847 In particolare prenderemo in esame i vari meccanismi con cui viene gestita
1848 l'assegnazione del tempo di CPU, ed illustreremo le varie funzioni di
1852 \subsection{I meccanismi di \textit{scheduling}}
1853 \label{sec:proc_sched}
1855 La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
1856 il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
1857 ed oggetto di numerose ricerche; in generale essa dipende in maniera
1858 essenziale anche dal tipo di utilizzo che deve essere fatto del sistema, per
1859 cui non esiste un meccanismo che sia valido per tutti gli usi.
1861 La caratteristica specifica di un sistema multitasking come Linux è quella del
1862 cosiddetto \textit{prehemptive multitasking}: questo significa che al
1863 contrario di altri sistemi (che usano invece il cosiddetto \textit{cooperative
1864 multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
1865 quando la CPU deve essere passata ad un altro processo. Come accennato in
1866 \secref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione
1867 apposita del kernel, lo \textit{scheduler}\index{scheduler}, il cui scopo è
1868 quello di distribuire al meglio il tempo di CPU fra i vari processi.
1870 La cosa è resa ancora più complicata dal fatto che con le architetture
1871 multi-processore si deve anche scegliere quale sia la CPU più opportuna da
1872 utilizzare.\footnote{nei processori moderni la presenza di ampie cache può
1873 rendere poco efficiente trasferire l'esecuzione di un processo da una CPU ad
1874 un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
1875 banale.} Tutto questo comunque appartiene alle sottigliezze
1876 dell'implementazione del kernel; dal punto di vista dei programmi che girano
1877 in user space, anche quando si hanno più processori (e dei processi che sono
1878 eseguiti davvero in contemporanea), le politiche di scheduling riguardano
1879 semplicemente l'allocazione della risorsa \textsl{tempo di esecuzione}, la cui
1880 assegnazione sarà governata dai meccanismi di scelta delle priorità che
1881 restano gli stessi indipendentemente dal numero di processori.
1883 Si tenga conto poi che i processi non devono solo eseguire del codice: ad
1884 esempio molto spesso saranno impegnati in operazioni di I/O, o potranno
1885 venire bloccati da un comando dal terminale, o sospesi per un certo periodo di
1886 tempo. In tutti questi casi la CPU diventa disponibile ed è compito dello
1887 kernel provvedere a mettere in esecuzione un altro processo.
1889 Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
1890 processo, in Linux un processo può trovarsi in uno degli stati riportati in
1891 \tabref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
1892 \textit{runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
1893 sia la sua priorità, un processo non potrà mai essere messo in esecuzione
1894 fintanto che esso si trova in uno qualunque degli altri stati.
1899 \begin{tabular}[c]{|p{2.8cm}|c|p{10cm}|}
1901 \textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
1904 \textbf{Runnable} & \texttt{R} & Il processo è in esecuzione o è pronto ad
1905 essere eseguito (cioè è in attesa che gli venga assegnata la CPU). \\
1906 \textbf{Sleep} & \texttt{S} & Il processo processo è in attesa di un
1907 risposta dal sistema, ma può essere interrotto da un segnale. \\
1908 \textbf{Uninterrutible Sleep} & \texttt{D} & Il processo è in
1909 attesa di un risposta dal sistema (in genere per I/O), e non può essere
1910 interrotto in nessuna circostanza. \\
1911 \textbf{Stopped} & \texttt{T} & Il processo è stato fermato con un
1912 \macro{SIGSTOP}, o è tracciato.\\
1913 \textbf{Zombie} & \texttt{Z} & Il processo è terminato ma il suo stato di
1914 terminazione non è ancora stato letto dal padre. \\
1917 \caption{Elenco dei possibili stati di un processo in Linux, nella colonna
1918 \texttt{STAT} si è riportata la corrispondente lettera usata dal comando
1919 \cmd{ps} nell'omonimo campo.}
1920 \label{tab:proc_proc_states}
1923 Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
1924 risorse che sono necessarie per l'esecuzione di un programma, e a seconda
1925 dello scopo del programma non è detto neanche che sia la più importante (molti
1926 programmi dipendono in maniera molto più critica dall'I/O). Per questo motivo
1927 non è affatto detto che dare ad un programma la massima priorità di esecuzione
1928 abbia risultati significativi in termini di prestazioni.
1930 Il meccanismo tradizionale di scheduling di Unix (che tratteremo in
1931 \secref{sec:proc_sched_stand}) è sempre stato basato su delle \textsl{priorità
1932 dinamiche}, in modo da assicurare che tutti i processi, anche i meno
1933 importanti, possano ricevere un po' di tempo di CPU. In sostanza quando un
1934 processo ottiene la CPU la sua priorità viene diminuita. In questo modo alla
1935 fine, anche un processo con priorità iniziale molto bassa, finisce per avere
1936 una priorità sufficiente per essere eseguito.
1938 Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
1939 assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
1940 alla normale priorità dinamica), per tenere conto dei sistemi
1941 real-time,\footnote{per sistema real-time si intende un sistema in grado di
1942 eseguire operazioni in un tempo ben determinato; in genere si tende a
1943 distinguere fra l'\textit{hard real-time} in cui è necessario che i tempi di
1944 esecuzione di un programma siano determinabili con certezza assoluta (come
1945 nel caso di meccanismi di controllo di macchine, dove uno sforamento dei
1946 tempi avrebbe conseguenze disastrose), e \textit{soft-real-time} in cui un
1947 occasionale sforamento è ritenuto accettabile.} in cui è vitale che i
1948 processi che devono essere eseguiti in un determinato momento non debbano
1949 aspettare la conclusione di altri che non hanno questa necessità.
1951 Il concetto di priorità assoluta dice che quando due processi si contendono
1952 l'esecuzione, vince sempre quello con la priorità assoluta più alta.
1953 Ovviamente questo avviene solo per i processi che sono pronti per essere
1954 eseguiti (cioè nello stato \textit{runnable}). La priorità assoluta viene in
1955 genere indicata con un numero intero, ed un valore più alto comporta una
1956 priorità maggiore. Su questa politica di scheduling torneremo in
1957 \secref{sec:proc_real_time}.
1959 In generale quello che succede in tutti gli Unix moderni è che ai processi
1960 normali viene sempre data una priorità assoluta pari a zero, e la decisione di
1961 assegnazione della CPU è fatta solo con il meccanismo tradizionale della
1962 priorità dinamica. In Linux tuttavia è possibile assegnare anche una priorità
1963 assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di
1964 priorità inferiore, che saranno eseguiti solo quando quest'ultimo non avrà
1968 \subsection{Il meccanismo di \textit{scheduling} standard}
1969 \label{sec:proc_sched_stand}
1971 A meno che non si abbiano esigenze specifiche, l'unico meccanismo di
1972 scheduling con il quale si avrà a che fare è quello tradizionale, che prevede
1973 solo priorità dinamiche. È di questo che, di norma, ci si dovrà preoccupare
1974 nella programmazione.
1976 Come accennato in Linux tutti i processi ordinari hanno la stessa priorità
1977 assoluta. Quello che determina quale, fra tutti i processi in attesa di
1978 esecuzione, sarà eseguito per primo, è la priorità dinamica, che è chiamata
1979 così proprio perché varia nel corso dell'esecuzione di un processo. Oltre a
1980 questo la priorità dinamica determina quanto a lungo un processo continuerà ad
1981 essere eseguito, e quando un processo potrà subentrare ad un altro
1984 Il meccanismo usato da Linux è piuttosto semplice, ad ogni processo è
1985 assegnata una \textit{time-slice}, cioè in intervallo di tempo (letteralmente
1986 una fetta) per il quale esso deve essere eseguito. Il valore della
1987 \textit{time-slice} è controllato dalla cosiddetta \textit{nice} (o
1988 \textit{niceness}) del processo. Essa è contenuta nel campo \var{nice} di
1989 \var{task\_struct}; tutti i processi vengono creati con lo stesso valore, ed
1990 essa specifica il valore della durata iniziale della \textit{time-slice} che
1991 viene assegnato ad un altro campo della struttura (\var{counter}) quando il
1992 processo viene eseguito per la prima volta e diminuito progressivamente ad
1993 ogni interruzione del timer.
1995 Quando lo scheduler\index{scheduler} viene eseguito scandisce la coda dei
1996 processi in stato \textit{runnable} associando, sulla base del valore di
1997 \var{counter}, un peso a ciascun processo in attesa di esecuzione,\footnote{il
1998 calcolo del peso in realtà è un po' più complicato, ad esempio nei sistemi
1999 multiprocessore viene favorito un processo che è eseguito sulla stessa CPU,
2000 e a parità del valore di \var{counter} viene favorito chi ha una priorità
2001 più elevata.} chi ha il peso più alto verrà posto in esecuzione, ed il
2002 precedente processo sarà spostato in fondo alla coda. Dato che ad ogni
2003 interruzione del timer il valore di \var{counter} del processo corrente viene
2004 diminuito, questo assicura che anche i processi con priorità più bassa
2005 verranno messi in esecuzione.
2007 La priorità di un processo è così controllata attraverso il valore di
2008 \var{nice}, che stabilisce la durata della \textit{time-slice}; per il
2009 meccanismo appena descritto infatti un valore più lungo infatti assicura una
2010 maggiore attribuzione di CPU. L'origine del nome di questo parametro sta nel
2011 fatto che generalmente questo viene usato per diminuire la priorità di un
2012 processo, come misura di cortesia nei confronti degli altri. I processi
2013 infatti vengono creati dal sistema con lo stesso valore di \var{nice} (nullo)
2014 e nessuno è privilegiato rispetto agli altri; il valore può essere modificato
2015 solo attraverso la funzione \func{nice}, il cui prototipo è:
2016 \begin{prototype}{unistd.h}
2018 Aumenta il valore di \var{nice} per il processo corrente.
2020 \bodydesc{La funzione ritorna zero in caso di successo e -1 in caso di
2021 errore, nel qual caso \var{errno} può assumere i valori:
2023 \item[\macro{EPERM}] un processo senza i privilegi di amministratore ha
2024 specificato un valore di \param{inc} negativo.
2028 L'argomento \param{inc} indica l'incremento del valore di \var{nice}:
2029 quest'ultimo può assumere valori compresi fra \macro{PRIO\_MIN} e
2030 \macro{PRIO\_MAX} (che nel caso di Linux sono $-19$ e $20$), ma per
2031 \param{inc} si può specificare un valore qualunque, positivo o negativo, ed il
2032 sistema provvederà a troncare il risultato nell'intervallo consentito. Valori
2033 positivi comportano maggiore \textit{cortesia} e cioè una diminuzione della
2034 priorità, ogni utente può solo innalzare il valore di un suo processo. Solo
2035 l'amministratore può specificare valori negativi che permettono di aumentare
2036 la priorità di un processo.
2038 In SUSv2 la funzione ritorna il nuovo valore di \var{nice}; Linux non segue
2039 questa convenzione, e per leggere il nuovo valore occorre invece usare la
2040 funzione \func{getpriority}, derivata da BSD, il cui prototipo è:
2041 \begin{prototype}{sys/resource.h}
2042 {int getpriority(int which, int who)}
2044 Restituisce il valore di \var{nice} per l'insieme dei processi specificati.
2046 \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
2047 errore, nel qual caso \var{errno} può assumere i valori:
2049 \item[\macro{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2050 \param{which} e \param{who}.
2051 \item[\macro{EINVAL}] il valore di \param{which} non è valido.
2054 \noindent (in vecchie versioni può essere necessario includere anche
2055 \file{<sys/time.h>}, questo non è più necessario con versioni recenti delle
2056 librerie, ma è comunque utile per portabilità).
2058 La funzione permette di leggere la priorità di un processo, di un gruppo di
2059 processi (vedi \secref{sec:sess_proc_group}) o di un utente, a seconda del
2060 valore di \param{which}, secondo la legenda di \tabref{tab:proc_getpriority},
2061 specificando un corrispondente valore per \param{who}; un valore nullo di
2062 quest'ultimo indica il processo, il gruppo di processi o l'utente correnti.
2067 \begin{tabular}[c]{|c|c|l|}
2069 \param{which} & \param{who} & \textbf{Significato} \\
2072 \macro{PRIO\_PROCESS} & \type{pid\_t} & processo \\
2073 \macro{PRIO\_PRGR} & \type{pid\_t} & process group \\
2074 \macro{PRIO\_USER} & \type{uid\_t} & utente \\
2077 \caption{Legenda del valore dell'argomento \param{which} e del tipo
2078 dell'argomento \param{who} delle funzioni \func{getpriority} e
2079 \func{setpriority} per le tre possibili scelte.}
2080 \label{tab:proc_getpriority}
2083 La funzione restituisce la priorità più alta (cioè il valore più basso) fra
2084 quelle dei processi specificati; dato che -1 è un valore possibile, per poter
2085 rilevare una condizione di errore è necessario cancellare sempre \var{errno}
2086 prima della chiamata alla funzione, per verificare che essa resti uguale a
2089 Analoga a \func{getpriority} la funzione \func{setpriority} permette di
2090 impostare la priorità di uno o più processi; il suo prototipo è:
2091 \begin{prototype}{sys/resource.h}
2092 {int setpriority(int which, int who, int prio)}
2093 Imposta la priorità per l'insieme dei processi specificati.
2095 \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
2096 errore, nel qual caso \var{errno} può assumere i valori:
2098 \item[\macro{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2099 \param{which} e \param{who}.
2100 \item[\macro{EINVAL}] il valore di \param{which} non è valido.
2101 \item[\macro{EPERM}] un processo senza i privilegi di amministratore ha
2102 specificato un valore di \param{inc} negativo.
2103 \item[\macro{EACCESS}] un processo senza i privilegi di amministratore ha
2104 cercato di modificare la priorità di un processo di un altro utente.
2108 La funzione imposta la priorità al valore specificato da \param{prio} per
2109 tutti i processi indicati dagli argomenti \param{which} e \param{who}. La
2110 gestione dei permessi dipende dalle varie implementazioni; in Linux, secondo
2111 le specifiche dello standard SUSv3, e come avviene per tutti i sistemi che
2112 derivano da SYSV, è richiesto che l'userid reale o effettivo del processo
2113 chiamante corrispondano al real user id (e solo quello) del processo di cui si
2114 vuole cambiare la priorità; per i sistemi derivati da BSD invece (SunOS,
2115 Ultrix, *BSD) la corrispondenza può essere anche con l'userid effettivo.
2119 \subsection{Il meccanismo di \textit{scheduling real-time}}
2120 \label{sec:proc_real_time}
2122 Come spiegato in \secref{sec:proc_sched} lo standard POSIX.1b ha introdotto le
2123 priorità assolute per permettere la gestione di processi real-time. In realtà
2124 nel caso di Linux non si tratta di un vero hard real-time, in quanto in
2125 presenza di eventuali interrupt il kernel interrompe l'esecuzione di un
2126 processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
2127 siano installate le patch di RTLinux, RTAI o Adeos, con i quali è possibile
2128 ottenere un sistema effettivamente hard real-time. In tal caso infatti gli
2129 interrupt vengono intercettati dall'interfaccia real-time (o nel caso di
2130 Adeos gestiti dalle code del nano-kernel), in modo da poterlo controllare
2131 direttamente qualora ci sia la necessità di avere un processo con priorità
2132 più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
2133 page fault\index{page fault} si possono avere ritardi non previsti. Se
2134 l'ultimo problema può essere aggirato attraverso l'uso delle funzioni di
2135 controllo della memoria virtuale (vedi \secref{sec:proc_mem_lock}), il primo
2136 non è superabile e può comportare ritardi non prevedibili riguardo ai tempi di
2137 esecuzione di qualunque processo.
2139 In ogni caso occorre usare le priorità assolute con molta attenzione: se si dà
2140 ad un processo una priorità assoluta e questo finisce in un loop infinito,
2141 nessun altro processo potrà essere eseguito, ed esso sarà mantenuto in
2142 esecuzione permanentemente assorbendo tutta la CPU e senza nessuna possibilità
2143 di riottenere l'accesso al sistema. Per questo motivo è sempre opportuno,
2144 quando si lavora con processi che usano priorità assolute, tenere attiva una
2145 shell cui si sia assegnata la massima priorità assoluta, in modo da poter
2146 essere comunque in grado di rientrare nel sistema.
2148 Quando c'è un processo con priorità assoluta lo scheduler\index{scheduler} lo
2149 metterà in esecuzione prima di ogni processo normale. In caso di più processi
2150 sarà eseguito per primo quello con priorità assoluta più alta. Quando ci sono
2151 più processi con la stessa priorità assoluta questi vengono tenuti in una coda
2152 tocca al kernel decidere quale deve essere eseguito.
2154 Il meccanismo con cui vengono gestiti questi processi dipende dalla politica
2155 di scheduling che si è scelto; lo standard ne prevede due:
2156 \begin{basedescript}{\desclabelwidth{2cm}\desclabelstyle{\nextlinelabel}}
2157 \item[\textit{FIFO}] \textit{First In First Out}. Il processo viene eseguito
2158 fintanto che non cede volontariamente la CPU, si blocca, finisce o viene
2159 interrotto da un processo a priorità più alta.
2160 \item[\textit{RR}] \textit{Round Robin}. Ciascun processo viene eseguito a
2161 turno per un certo periodo di tempo (una \textit{time slice}). Solo i
2162 processi con la stessa priorità ed in stato \textit{runnable} entrano nel
2166 La funzione per impostare le politiche di scheduling (sia real-time che
2167 ordinarie) ed i relativi parametri è \func{sched\_setscheduler}; il suo
2169 \begin{prototype}{sched.h}
2170 {int sched\_setscheduler(pid\_t pid, int policy, const struct sched\_param *p)}
2171 Imposta priorità e politica di scheduling per il processo \param{pid}.
2173 \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
2174 errore, nel qual caso \var{errno} può assumere i valori:
2176 \item[\macro{ESRCH}] il processo \param{pid} non esiste.
2177 \item[\macro{EINVAL}] il valore di \param{policy} non esiste o il relativo
2178 valore di \param{p} non è valido.
2179 \item[\macro{EPERM}] il processo non ha i privilegi per attivare la
2180 politica richiesta (vale solo per \macro{SCHED\_FIFO} e
2185 La funzione esegue l'impostazione per il processo specificato; un valore nullo
2186 di \param{pid} esegue l'impostazione per il processo corrente, solo un
2187 processo con i privilegi di amministratore può impostare delle priorità
2188 assolute diverse da zero. La politica di scheduling è specificata
2189 dall'argomento \param{policy} i cui possibili valori sono riportati in
2190 \tabref{tab:proc_sched_policy}; un valore negativo per \param{policy} mantiene
2191 la politica di scheduling corrente.
2196 \begin{tabular}[c]{|c|l|}
2198 \textbf{Policy} & \textbf{Significato} \\
2201 \macro{SCHED\_FIFO} & Scheduling real-time con politica \textit{FIFO} \\
2202 \macro{SCHED\_RR} & Scheduling real-time con politica \textit{Round
2204 \macro{SCHED\_OTHER}& Scheduling ordinario\\
2207 \caption{Valori dell'argomento \param{policy} per la funzione
2208 \func{sched\_setscheduler}. }
2209 \label{tab:proc_sched_policy}
2212 Il valore della priorità è passato attraverso la struttura \var{sched\_param}
2213 (riportata in \figref{fig:sig_sched_param}), il cui solo campo attualmente
2214 definito è \var{sched\_priority}, che nel caso delle priorità assolute deve
2215 essere specificato nell'intervallo fra un valore massimo ed uno minimo, che
2216 nel caso sono rispettivamente 1 e 99 (il valore zero è legale, ma indica i
2219 \begin{figure}[!htb]
2220 \footnotesize \centering
2221 \begin{minipage}[c]{15cm}
2222 \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
2223 struct sched_param {
2229 \caption{La struttura \var{sched\_param}.}
2230 \label{fig:sig_sched_param}
2235 Lo standard POSIX.1b prevede comunque che i due valori della massima e minima
2236 priorità statica possano essere ottenuti, per ciascuna delle politiche di
2237 scheduling realtime, tramite le due funzioni \func{sched\_get\_priority\_max}
2238 e \func{sched\_get\_priority\_min}, i cui prototipi sono:
2242 \funcdecl{int sched\_get\_priority\_max(int policy)} Legge il valore
2243 massimo della priorità statica per la politica di scheduling \param{policy}.
2246 \funcdecl{int sched\_get\_priority\_min(int policy)} Legge il valore minimo
2247 della priorità statica per la politica di scheduling \param{policy}.
2249 \bodydesc{La funzioni ritornano il valore della priorità in caso di successo
2250 e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
2252 \item[\macro{EINVAL}] il valore di \param{policy} è invalido.
2257 I processi con politica di scheduling \macro{SCHED\_OTHER} devono specificare
2258 un valore nullo (altrimenti si avrà un errore \macro{EINVAL}), questo valore
2259 infatti non ha niente a che vedere con la priorità dinamica determinata dal
2260 valore di \var{nice}, che deve essere impostato con le funzioni viste in
2263 Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed
2264 esegue sempre il primo della lista, mentre un nuovo processo che torna in
2265 stato \textit{runnable} viene sempre inserito in coda alla lista. Se la
2266 politica scelta è \macro{SCHED\_FIFO} quando il processo viene eseguito viene
2267 automaticamente rimesso in coda alla lista, e la sua esecuzione continua
2268 fintanto che non viene bloccato da una richiesta di I/O, o non rilascia
2269 volontariamente la CPU (in tal caso, tornando nello stato \textit{runnable}
2270 sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo
2271 nel caso che esso sia stato interrotto da un processo a priorità più alta.
2273 La priorità assoluta può essere riletta indietro dalla funzione
2274 \func{sched\_getscheduler}, il cui prototipo è:
2275 \begin{prototype}{sched.h}
2276 {int sched\_getscheduler(pid\_t pid)}
2277 Legge la politica di scheduling per il processo \param{pid}.
2279 \bodydesc{La funzione ritorna la politica di scheduling in caso di successo
2280 e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
2282 \item[\macro{ESRCH}] il processo \param{pid} non esiste.
2283 \item[\macro{EINVAL}] il valore di \param{pid} è negativo.
2287 La funzione restituisce il valore (secondo la quanto elencato in
2288 \tabref{tab:proc_sched_policy}) della politica di scheduling per il processo
2289 specificato; se \param{pid} è nullo viene restituito quello del processo
2292 Se si intende operare solo sulla priorità assoluta di un processo si possono
2293 usare le funzioni \func{sched\_setparam} e \func{sched\_getparam}, i cui
2299 \funcdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *p)}
2300 Imposta la priorità assoluta del processo \param{pid}.
2303 \funcdecl{int sched\_getparam(pid\_t pid, struct sched\_param *p)}
2304 Legge la priorità assoluta del processo \param{pid}.
2306 \bodydesc{La funzione ritorna la priorità in caso di successo
2307 e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
2309 \item[\macro{ESRCH}] il processo \param{pid} non esiste.
2310 \item[\macro{EINVAL}] il valore di \param{pid} è negativo.
2314 L'uso di \func{sched\_setparam} che è del tutto equivalente a
2315 \func{sched\_setscheduler} con \param{priority} uguale a -1. Come per
2316 \func{sched\_setscheduler} specificando 0 come valore di \param{pid} si opera
2317 sul processo corrente. La disponibilità di entrambe le funzioni può essere
2318 verificata controllando la macro \macro{\_POSIX\_PRIORITY\_SCHEDULING} che è
2319 definita nell'header \macro{sched.h}.
2321 L'ultima funzione che permette di leggere le informazioni relative ai processi
2322 real-time è \func{sched\_rr\_get\_interval}, che permette di ottenere la
2323 lunghezza della \textit{time slice} usata dalla politica \textit{round robin};
2325 \begin{prototype}{sched.h}
2326 {int sched\_rr\_get\_interval(pid\_t pid, struct timespec *tp)} Legge in
2327 \param{tp} la durata della \textit{time slice} per il processo \param{pid}.
2329 \bodydesc{La funzione ritorna 0in caso di successo e -1 in caso di errore,
2330 nel qual caso \var{errno} può assumere i valori:
2332 \item[\macro{ESRCH}] il processo \param{pid} non esiste.
2333 \item[\macro{ENOSYS}] la system call non è stata implementata.
2337 La funzione restituisce il valore dell'intervallo di tempo usato per la
2338 politica \textit{round robin} in una struttura \var{timespec}, (la cui
2339 definizione si può trovare in \figref{fig:sys_timeval_struct}).
2342 Come accennato ogni processo che usa lo scheduling real-time può rilasciare
2343 volontariamente la CPU; questo viene fatto attraverso la funzione
2344 \func{sched\_yield}, il cui prototipo è:
2345 \begin{prototype}{sched.h}
2346 {int sched\_yield(void)}
2348 Rilascia volontariamente l'esecuzione.
2350 \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
2351 nel qual caso \var{errno} viene impostata opportunamente.}
2354 La funzione fa sì che il processo rilasci la CPU, in modo da essere rimesso in
2355 coda alla lista dei processi da eseguire, e permettere l'esecuzione di un
2356 altro processo; se però il processo è l'unico ad essere presente sulla coda
2357 l'esecuzione non sarà interrotta. In genere usano questa funzione i processi
2358 in modalità \textit{fifo}, per permettere l'esecuzione degli altri processi
2359 con pari priorità quando la sezione più urgente è finita.
2362 \section{Problematiche di programmazione multitasking}
2363 \label{sec:proc_multi_prog}
2365 Benché i processi siano strutturati in modo da apparire il più possibile come
2366 indipendenti l'uno dall'altro, nella programmazione in un sistema multitasking
2367 occorre tenere conto di una serie di problematiche che normalmente non
2368 esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
2369 programma alla volta.
2371 Pur essendo questo argomento di carattere generale, ci è parso opportuno
2372 introdurre sinteticamente queste problematiche, che ritroveremo a più riprese
2373 in capitoli successivi, in questa sezione conclusiva del capitolo in cui
2374 abbiamo affrontato la gestione dei processi.
2377 \subsection{Le operazioni atomiche}
2378 \label{sec:proc_atom_oper}
2380 La nozione di \textsl{operazione atomica} deriva dal significato greco della
2381 parola atomo, cioè indivisibile; si dice infatti che un'operazione è atomica
2382 quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi
2383 che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
2384 di interruzione in una fase intermedia.
2386 In un ambiente multitasking il concetto è essenziale, dato che un processo può
2387 essere interrotto in qualunque momento dal kernel che mette in esecuzione un
2388 altro processo o dalla ricezione di un segnale; occorre pertanto essere
2389 accorti nei confronti delle possibili
2390 \textit{race condition}\index{race condition} (vedi
2391 \secref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase in
2392 cui non erano ancora state completate.
2394 Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
2395 occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
2396 fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
2397 \capref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
2398 \secref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
2399 funzioni di libreria per compiere le operazioni necessarie è garanzia
2400 sufficiente di atomicità in quanto le system call con cui esse sono realizzate
2401 non possono essere interrotte (o subire interferenze pericolose) da altri
2404 Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
2405 stesso processo, e pure alcune system call, possono essere interrotti in
2406 qualunque momento, e le operazioni di un eventuale \textit{signal handler}
2407 sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
2408 il solo accesso o l'assegnazione di una variabile possono non essere più
2409 operazioni atomiche (torneremo su questi aspetti in
2410 \secref{sec:sig_control}).
2412 In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
2413 il cui accesso è assicurato essere atomico. In pratica comunque si può
2414 assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
2415 \ctyp{int}, gli altri interi di dimensione inferiore ed i puntatori sono
2416 atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
2417 maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
2418 le strutture. In tutti questi casi è anche opportuno marcare come
2419 \ctyp{volatile} le variabili che possono essere interessate ad accesso
2420 condiviso, onde evitare problemi con le ottimizzazioni del codice.
2424 \subsection{Le \textit{race condition}\index{race condition} e i
2426 \label{sec:proc_race_cond}
2428 Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
2429 diversi operano su una risorsa comune, ed in cui il risultato viene a
2430 dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso
2431 tipico è quello di un'operazione che viene eseguita da un processo in più
2432 passi, e può essere compromessa dall'intervento di un altro processo che
2433 accede alla stessa risorsa quando ancora non tutti i passi sono stati
2436 Dato che in un sistema multitasking ogni processo può essere interrotto in
2437 qualunque momento per farne subentrare un'altro in esecuzione, niente può
2438 assicurare un preciso ordine di esecuzione fra processi diversi o che una
2439 sezione di un programma possa essere eseguita senza interruzioni da parte di
2440 altri. Queste situazioni comportano pertanto errori estremamente subdoli e
2441 difficili da tracciare, in quanto nella maggior parte dei casi tutto
2442 funzionerà regolarmente, e solo occasionalmente si avranno degli errori.
2444 Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
2445 che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
2446 gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di
2447 \textit{race condition} si hanno quando diversi processi accedono allo stesso
2448 file, o nell'accesso a meccanismi di intercomunicazione come la memoria
2449 condivisa. In questi casi, se non si dispone della possibilità di eseguire
2450 atomicamente le operazioni necessarie, occorre che quelle parti di codice in
2451 cui si compiono le operazioni sulle risorse condivise (le cosiddette
2452 \textsl{sezioni critiche}\index{sezioni critiche}) del programma, siano
2453 opportunamente protette da meccanismi di sincronizzazione (torneremo su queste
2454 problematiche di questo tipo in \capref{cha:IPC}).
2456 Un caso particolare di \textit{race condition} sono poi i cosiddetti
2457 \textit{deadlock}, particolarmente gravi in quanto comportano spesso il blocco
2458 completo di un servizio, e non il fallimento di una singola operazione. Per
2459 definizione un \textit{deadlock} è una situazione in cui due o più processi
2460 non sono più in grado di proseguire perché ciascuno aspetta il risultato di
2461 una operazione che dovrebbe essere eseguita dall'altro.
2464 L'esempio tipico di una situazione che può condurre ad un \textit{deadlock} è
2465 quello in cui un flag di ``occupazione'' viene rilasciato da un evento
2466 asincrono (come un segnale o un altro processo) fra il momento in cui lo si è
2467 controllato (trovandolo occupato) e la successiva operazione di attesa per lo
2468 sblocco. In questo caso, dato che l'evento di sblocco del flag è avvenuto
2469 senza che ce ne accorgessimo proprio fra il controllo e la messa in attesa,
2470 quest'ultima diventerà perpetua (da cui il nome di \textit{deadlock}).
2472 In tutti questi casi è di fondamentale importanza il concetto di atomicità
2473 visto in \secref{sec:proc_atom_oper}; questi problemi infatti possono essere
2474 risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile
2475 eseguire in maniera atomica le operazioni necessarie.
2478 \subsection{Le funzioni rientranti}
2479 \label{sec:proc_reentrant}
2481 Si dice \textsl{rientrante} una funzione che può essere interrotta in
2482 qualunque punto della sua esecuzione ed essere chiamata una seconda volta da
2483 un altro thread di esecuzione senza che questo comporti nessun problema
2484 nell'esecuzione della stessa. La problematica è comune nella programmazione
2485 multi-thread, ma si hanno gli stessi problemi quando si vogliono chiamare
2486 delle funzioni all'interno dei manipolatori dei segnali.
2488 Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
2489 queste infatti vengono allocate nello stack, e un'altra invocazione non fa
2490 altro che allocarne un'altra copia. Una funzione può non essere rientrante
2491 quando opera su memoria che non è nello stack. Ad esempio una funzione non è
2492 mai rientrante se usa una variabile globale o statica.
2494 Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
2495 cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
2496 ogni volta e ritornato indietro la funzione può essere rientrante, se invece
2497 esso viene individuato dalla funzione stessa due chiamate alla stessa funzione
2498 potranno interferire quando entrambe faranno riferimento allo stesso oggetto.
2499 Allo stesso modo una funzione può non essere rientrante se usa e modifica un
2500 oggetto che le viene fornito dal chiamante: due chiamate possono interferire
2501 se viene passato lo stesso oggetto; in tutti questi casi occorre molta cura da
2502 parte del programmatore.
2504 In genere le funzioni di libreria non sono rientranti, molte di esse ad
2505 esempio utilizzano variabili statiche, le \acr{glibc} però mettono a
2506 disposizione due macro di compilatore, \macro{\_REENTRANT} e
2507 \macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di
2508 varie funzioni di libreria, che sono identificate aggiungendo il suffisso
2509 \code{\_r} al nome della versione normale.
2513 %%% Local Variables:
2515 %%% TeX-master: "gapil"