Come accennato nell'introduzione in un sistema Unix tutte le operazioni
vengono svolte tramite opportuni processi. In sostanza questi ultimi vengono
-a costituire l'unità base per l'allocazione e l'uso delle risorse del sistema.
+a costituire l'unità base per l'allocazione e l'uso delle risorse del sistema.
Nel precedente capitolo abbiamo esaminato il funzionamento di un processo come
-unità a se stante, in questo esamineremo il funzionamento dei processi
-all'interno del sistema. Saranno cioè affrontati i dettagli della creazione e
+unità a se stante, in questo esamineremo il funzionamento dei processi
+all'interno del sistema. Saranno cioè affrontati i dettagli della creazione e
della terminazione dei processi, della gestione dei loro attributi e
privilegi, e di tutte le funzioni a questo connesse. Infine nella sezione
finale introdurremo alcune problematiche generiche della programmazione in
\label{sec:proc_hierarchy}
A differenza di quanto avviene in altri sistemi (ad esempio nel VMS la
-generazione di nuovi processi è un'operazione privilegiata) una delle
-caratteristiche di Unix (che esamineremo in dettaglio più avanti) è che
-qualunque processo può a sua volta generarne altri, detti processi figli
-(\textit{child process}). Ogni processo è identificato presso il sistema da un
-numero univoco, il cosiddetto \textit{process identifier} o, più brevemente,
+generazione di nuovi processi è un'operazione privilegiata) una delle
+caratteristiche di Unix (che esamineremo in dettaglio più avanti) è che
+qualunque processo può a sua volta generarne altri, detti processi figli
+(\textit{child process}). Ogni processo è identificato presso il sistema da un
+numero univoco, il cosiddetto \textit{process identifier} o, più brevemente,
\acr{pid}, assegnato in forma progressiva (vedi sez.~\ref{sec:proc_pid})
quando il processo viene creato.
-Una seconda caratteristica di un sistema Unix è che la generazione di un
-processo è un'operazione separata rispetto al lancio di un programma. In
-genere la sequenza è sempre quella di creare un nuovo processo, il quale
-eseguirà, in un passo successivo, il programma desiderato: questo è ad esempio
+Una seconda caratteristica di un sistema Unix è che la generazione di un
+processo è un'operazione separata rispetto al lancio di un programma. In
+genere la sequenza è sempre quella di creare un nuovo processo, il quale
+eseguirà, in un passo successivo, il programma desiderato: questo è ad esempio
quello che fa la shell quando mette in esecuzione il programma che gli
indichiamo nella linea di comando.
-Una terza caratteristica è che ogni processo è sempre stato generato da un
+Una terza caratteristica è che ogni processo è sempre stato generato da un
altro, che viene chiamato processo padre (\textit{parent process}). Questo
vale per tutti i processi, con una sola eccezione: dato che ci deve essere un
-punto di partenza esiste un processo speciale (che normalmente è
+punto di partenza esiste un processo speciale (che normalmente è
\cmd{/sbin/init}), che viene lanciato dal kernel alla conclusione della fase
di avvio; essendo questo il primo processo lanciato dal sistema ha sempre il
-\acr{pid} uguale a 1 e non è figlio di nessun altro processo.
+\acr{pid} uguale a 1 e non è figlio di nessun altro processo.
-Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
+Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
partire tutti gli altri processi necessari al funzionamento del sistema,
-inoltre \cmd{init} è essenziale per svolgere una serie di compiti
+inoltre \cmd{init} è essenziale per svolgere una serie di compiti
amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di
-essi in sez.~\ref{sec:proc_termination}) e non può mai essere terminato. La
+essi in sez.~\ref{sec:proc_termination}) e non può mai essere terminato. La
struttura del sistema comunque consente di lanciare al posto di \cmd{init}
qualunque altro programma, e in casi di emergenza (ad esempio se il file di
-\cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
+\cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio.
\begin{figure}[!htb]
|-snort
`-wwwoffled
\end{verbatim} %$
- \caption{L'albero dei processi, così come riportato dal comando
+ \caption{L'albero dei processi, così come riportato dal comando
\cmd{pstree}.}
\label{fig:proc_tree}
\end{figure}
Dato che tutti i processi attivi nel sistema sono comunque generati da
-\cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
+\cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
vero, in Linux ci sono alcuni processi speciali che pur comparendo come
- figli di \cmd{init}, o con \acr{pid} successivi, sono in realtà generati
+ figli di \cmd{init}, o con \acr{pid} successivi, sono in realtà generati
direttamente dal kernel, (come \cmd{keventd}, \cmd{kswapd}, ecc.).} si
possono classificare i processi con la relazione padre/figlio in
un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
organizzati in un albero di directory (si veda
-sez.~\ref{sec:file_organization}); in fig.~\ref{fig:proc_tree} si è mostrato il
+sez.~\ref{sec:file_organization}); in fig.~\ref{fig:proc_tree} si è mostrato il
risultato del comando \cmd{pstree} che permette di visualizzare questa
-struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri
+struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri
processi.
Il kernel mantiene una tabella dei processi attivi, la cosiddetta
processo. Tutte le strutture usate a questo scopo sono dichiarate nell'header
file \file{linux/sched.h}, ed uno schema semplificato, che riporta la
struttura delle principali informazioni contenute nella \struct{task\_struct}
-(che in seguito incontreremo a più riprese), è mostrato in
+(che in seguito incontreremo a più riprese), è mostrato in
fig.~\ref{fig:proc_task_struct}.
\begin{figure}[htb]
\label{fig:proc_task_struct}
\end{figure}
-% TODO la task_struct è cambiata per qualche dettaglio vedi anche
+% TODO la task_struct è cambiata per qualche dettaglio vedi anche
% http://www.ibm.com/developerworks/linux/library/l-linux-process-management/
% TODO completare la parte su quando viene chiamato lo scheduler.
-Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \itindex{scheduler}
+Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \itindex{scheduler}
\textit{scheduler} che decide quale processo mettere in esecuzione; esso viene
-eseguito ad ogni system call ed ad ogni interrupt,\footnote{più in una serie
- di altre occasioni.} ma può essere anche attivato esplicitamente. Il timer
+eseguito ad ogni system call ed ad ogni interrupt,\footnote{più in una serie
+ di altre occasioni.} ma può essere anche attivato esplicitamente. Il timer
di sistema provvede comunque a che esso sia invocato periodicamente; generando
un interrupt periodico secondo la frequenza specificata dalla costante
\const{HZ},\footnote{fino al kernel 2.4 il valore di \const{HZ} era 100 su
- tutte le architetture tranne l'alpha, per cui era 1000, nel 2.6 è stato
- portato a 1000 su tutte; dal 2.6.13 lo si può impostare in fase di
+ tutte le architetture tranne l'alpha, per cui era 1000, nel 2.6 è stato
+ portato a 1000 su tutte; dal 2.6.13 lo si può impostare in fase di
compilazione del kernel, con un default di 250 e valori possibili di 100,
- 250, 1000 e dal 2.6.20 anche 300 (che è divisibile per le frequenze di
+ 250, 1000 e dal 2.6.20 anche 300 (che è divisibile per le frequenze di
refresh della televisione); occorre fare attenzione a non confondere questo
valore con quello dei \itindex{clock~tick} \textit{clock tick} (vedi
sez.~\ref{sec:sys_unix_time}).} definita in \file{asm/param.h}, ed il cui
-valore è espresso in Hertz.\footnote{a partire dal kernel 2.6.21 è stato
+valore è espresso in Hertz.\footnote{a partire dal kernel 2.6.21 è stato
introdotto (a cura di Ingo Molnar) un meccanismo completamente diverso,
- detto \textit{tickless}, in cui non c'è più una interruzione periodica con
+ detto \textit{tickless}, in cui non c'è più una interruzione periodica con
frequenza prefissata, ma ad ogni chiamata del timer viene programmata
l'interruzione successiva sulla base di una stima; in questo modo si evita
di dover eseguire un migliaio di interruzioni al secondo anche su macchine
che non stanno facendo nulla, con un forte risparmio nell'uso dell'energia
- da parte del processore che può essere messo in stato di sospensione anche
+ da parte del processore che può essere messo in stato di sospensione anche
per lunghi periodi di tempo.}
Ogni volta che viene eseguito, lo \itindex{scheduler} \textit{scheduler}
-effettua il calcolo delle priorità dei vari processi attivi (torneremo su
+effettua il calcolo delle priorità dei vari processi attivi (torneremo su
questo in sez.~\ref{sec:proc_priority}) e stabilisce quale di essi debba
essere posto in esecuzione fino alla successiva invocazione.
Tradizionalmente in un sistema unix-like i processi vengono sempre creati da
altri processi tramite la funzione \func{fork}; il nuovo processo (che viene
-chiamato \textsl{figlio}) creato dalla \func{fork} è una copia identica del
+chiamato \textsl{figlio}) creato dalla \func{fork} è una copia identica del
processo processo originale (detto \textsl{padre}), ma ha un nuovo \acr{pid} e
viene eseguito in maniera indipendente (le differenze fra padre e figlio sono
affrontate in dettaglio in sez.~\ref{sec:proc_fork}).
abbastanza limitata sulle cause della terminazione del processo figlio.
Quando un processo ha concluso il suo compito o ha incontrato un errore non
-risolvibile esso può essere terminato con la funzione \func{exit} (si veda
-quanto discusso in sez.~\ref{sec:proc_conclusion}). La vita del processo però
+risolvibile esso può essere terminato con la funzione \func{exit} (si veda
+quanto discusso in sez.~\ref{sec:proc_conclusion}). La vita del processo però
termina completamente solo quando la notifica della sua conclusione viene
ricevuta dal processo padre, a quel punto tutte le risorse allocate nel
sistema ad esso associate vengono rilasciate.
-Avere due processi che eseguono esattamente lo stesso codice non è molto
+Avere due processi che eseguono esattamente lo stesso codice non è molto
utile, normalmente si genera un secondo processo per affidargli l'esecuzione
-di un compito specifico (ad esempio gestire una connessione dopo che questa è
+di un compito specifico (ad esempio gestire una connessione dopo che questa è
stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per
quest'ultimo caso si usa la seconda funzione fondamentale per programmazione
-coi processi che è la \func{exec}.
+coi processi che è la \func{exec}.
Il programma che un processo sta eseguendo si chiama immagine del processo (o
\textit{process image}), le funzioni della famiglia \func{exec} permettono di
caricare un altro programma da disco sostituendo quest'ultimo all'immagine
-corrente; questo fa sì che l'immagine precedente venga completamente
+corrente; questo fa sì che l'immagine precedente venga completamente
cancellata. Questo significa che quando il nuovo programma termina, anche il
-processo termina, e non si può tornare alla precedente immagine.
+processo termina, e non si può tornare alla precedente immagine.
Per questo motivo la \func{fork} e la \func{exec} sono funzioni molto
particolari con caratteristiche uniche rispetto a tutte le altre, infatti la
Come accennato nell'introduzione, ogni processo viene identificato dal sistema
da un numero identificativo univoco, il \textit{process ID} o \acr{pid};
-quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
-intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
+quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
+intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
\ctyp{int}).
Il \acr{pid} viene assegnato in forma progressiva\footnote{in genere viene
assegnato il numero successivo a quello usato per l'ultimo processo creato,
- a meno che questo numero non sia già utilizzato per un altro \acr{pid},
+ a meno che questo numero non sia già utilizzato per un altro \acr{pid},
\acr{pgid} o \acr{sid} (vedi sez.~\ref{sec:sess_proc_group}).} ogni volta
che un nuovo processo viene creato, fino ad un limite che, essendo il
\acr{pid} un numero positivo memorizzato in un intero a 16 bit, arriva ad un
-massimo di 32768. Oltre questo valore l'assegnazione riparte dal numero più
+massimo di 32768. Oltre questo valore l'assegnazione riparte dal numero più
basso disponibile a partire da un minimo di 300,\footnote{questi valori, fino
al kernel 2.4.x, sono definiti dalla macro \const{PID\_MAX} in
\file{threads.h} e direttamente in \file{fork.c}, con il kernel 2.5.x e la
nuova interfaccia per i \itindex{thread} \textit{thread} creata da Ingo
- Molnar anche il meccanismo di allocazione dei \acr{pid} è stato modificato;
- il valore massimo è impostabile attraverso il file
+ Molnar anche il meccanismo di allocazione dei \acr{pid} è stato modificato;
+ il valore massimo è impostabile attraverso il file
\procfile{/proc/sys/kernel/pid\_max} e di default vale 32768.} che serve a
-riservare i \acr{pid} più bassi ai processi eseguiti direttamente dal kernel.
+riservare i \acr{pid} più bassi ai processi eseguiti direttamente dal kernel.
Per questo motivo, come visto in sez.~\ref{sec:proc_hierarchy}, il processo di
avvio (\cmd{init}) ha sempre il \acr{pid} uguale a uno.
Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende un
candidato per generare ulteriori indicatori associati al processo di cui
-diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
+diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
funzione \func{tempnam} (si veda sez.~\ref{sec:file_temp_file}) usa il
\acr{pid} per generare un \itindex{pathname} \textit{pathname} univoco, che
-non potrà essere replicato da un altro processo che usi la stessa funzione.
+non potrà essere replicato da un altro processo che usi la stessa funzione.
Tutti i processi figli dello stesso processo padre sono detti
-\textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
+\textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
cap.~\ref{cha:session}, dove esamineremo gli altri identificativi associati ad
Oltre al \acr{pid} e al \acr{ppid}, (e a quelli che vedremo in
sez.~\ref{sec:sess_proc_group}, relativi al controllo di sessione), ad ogni
processo vengono associati degli altri identificatori che vengono usati per il
-controllo di accesso. Questi servono per determinare se un processo può
+controllo di accesso. Questi servono per determinare se un processo può
eseguire o meno le operazioni richieste, a seconda dei privilegi e
-dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà
+dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà
affrontato in dettaglio in sez.~\ref{sec:proc_perms}.
\subsection{La funzione \func{fork} e le funzioni di creazione dei processi}
\label{sec:proc_fork}
-La funzione \funcd{fork} è la funzione fondamentale della gestione dei
-processi: come si è detto tradizionalmente l'unico modo di creare un nuovo
-processo era attraverso l'uso di questa funzione,\footnote{in realtà oggi la
- system call usata più comunemente da Linux per creare nuovi processi è
- \func{clone} (vedi \ref{sec:process_clone}) , anche perché a partire dalle
- \acr{glibc} 2.3.3 non viene più usata la system call originale, ma la stessa
+La funzione \funcd{fork} è la funzione fondamentale della gestione dei
+processi: come si è detto tradizionalmente l'unico modo di creare un nuovo
+processo era attraverso l'uso di questa funzione,\footnote{in realtà oggi la
+ system call usata più comunemente da Linux per creare nuovi processi è
+ \func{clone} (vedi \ref{sec:process_clone}) , anche perché a partire dalle
+ \acr{glibc} 2.3.3 non viene più usata la system call originale, ma la stessa
\func{fork} viene implementata tramite \func{clone}, cosa che consente una
migliore interazione coi \textit{thread}.} essa quindi riveste un ruolo
centrale tutte le volte che si devono scrivere programmi che usano il
multitasking.\footnote{oggi questa rilevanza, con la diffusione dell'uso dei
- \textit{thread} che tratteremo al cap.~\ref{cha:threads}, è in parte minore,
+ \textit{thread} che tratteremo al cap.~\ref{cha:threads}, è in parte minore,
ma \func{fork} resta comunque la funzione principale per la creazione di
- processi.} Il prototipo della funzione è:
+ processi.} Il prototipo della funzione è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{unistd.h}
\bodydesc{In caso di successo restituisce il \acr{pid} del figlio al padre e
zero al figlio; ritorna -1 al padre (senza creare il figlio) in caso di
- errore; \var{errno} può assumere i valori:
+ errore; \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{EAGAIN}] non ci sono risorse sufficienti per creare un altro
processo (per allocare la tabella delle pagine e le strutture del task) o
- si è esaurito il numero di processi disponibili.
- \item[\errcode{ENOMEM}] non è stato possibile allocare la memoria per le
+ si è esaurito il numero di processi disponibili.
+ \item[\errcode{ENOMEM}] non è stato possibile allocare la memoria per le
strutture necessarie al kernel per creare il nuovo processo.
\end{errlist}}
\end{functions}
Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
il processo figlio continuano ad essere eseguiti normalmente a partire
-dall'istruzione successiva alla \func{fork}; il processo figlio è però una
+dall'istruzione successiva alla \func{fork}; il processo figlio è però una
copia del padre, e riceve una copia dei \index{segmento!testo} segmenti di
testo, \itindex{stack} \textit{stack} e \index{segmento!dati} dati (vedi
sez.~\ref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del
-padre. Si tenga presente però che la memoria è copiata, non condivisa,
+padre. Si tenga presente però che la memoria è copiata, non condivisa,
pertanto padre e figlio vedono variabili diverse.
Per quanto riguarda la gestione della memoria, in generale il
-\index{segmento!testo} segmento di testo, che è identico per i due processi, è
+\index{segmento!testo} segmento di testo, che è identico per i due processi, è
condiviso e tenuto in read-only per il padre e per i figli. Per gli altri
segmenti Linux utilizza la tecnica del \itindex{copy~on~write} \textit{copy on
write}; questa tecnica comporta che una pagina di memoria viene
effettivamente copiata per il nuovo processo solo quando ci viene effettuata
sopra una scrittura (e si ha quindi una reale differenza fra padre e figlio).
-In questo modo si rende molto più efficiente il meccanismo della creazione di
-un nuovo processo, non essendo più necessaria la copia di tutto lo spazio
+In questo modo si rende molto più efficiente il meccanismo della creazione di
+un nuovo processo, non essendo più necessaria la copia di tutto lo spazio
degli indirizzi virtuali del padre, ma solo delle pagine di memoria che sono
state modificate, e solo al momento della modifica stessa.
-La differenza che si ha nei due processi è che nel processo padre il valore di
-ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
-nel figlio è zero; in questo modo il programma può identificare se viene
+La differenza che si ha nei due processi è che nel processo padre il valore di
+ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
+nel figlio è zero; in questo modo il programma può identificare se viene
eseguito dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni
\textbf{due} volte: una nel padre e una nel figlio.
-La scelta di questi valori di ritorno non è casuale, un processo infatti può
-avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
+La scelta di questi valori di ritorno non è casuale, un processo infatti può
+avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
permette di identificare quello appena creato; al contrario un figlio ha
-sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
+sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
\func{getppid}, vedi sez.~\ref{sec:proc_pid}) per cui si usa il valore nullo,
-che non è il \acr{pid} di nessun processo.
+che non è il \acr{pid} di nessun processo.
\begin{figure}[!htb]
\footnotesize \centering
\label{fig:proc_fork_code}
\end{figure}
-Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci
-sono già troppi processi nel sistema (il che di solito è sintomo che
-qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
+Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci
+sono già troppi processi nel sistema (il che di solito è sintomo che
+qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
sul numero totale di processi permessi all'utente (vedi
sez.~\ref{sec:sys_resource_limit}, ed in particolare
tab.~\ref{tab:sys_rlimit_values}).
-L'uso di \func{fork} avviene secondo due modalità principali; la prima è
+L'uso di \func{fork} avviene secondo due modalità principali; la prima è
quella in cui all'interno di un programma si creano processi figli cui viene
affidata l'esecuzione di una certa sezione di codice, mentre il processo padre
-ne esegue un'altra. È il caso tipico dei programmi server (il modello
-\textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}) in cui il
+ne esegue un'altra. È il caso tipico dei programmi server (il modello
+\textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}) in cui il
padre riceve ed accetta le richieste da parte dei programmi client, per
-ciascuna delle quali pone in esecuzione un figlio che è incaricato di fornire
+ciascuna delle quali pone in esecuzione un figlio che è incaricato di fornire
il servizio.
-La seconda modalità è quella in cui il processo vuole eseguire un altro
-programma; questo è ad esempio il caso della shell. In questo caso il processo
-crea un figlio la cui unica operazione è quella di fare una \func{exec} (di
+La seconda modalità è quella in cui il processo vuole eseguire un altro
+programma; questo è ad esempio il caso della shell. In questo caso il processo
+crea un figlio la cui unica operazione è quella di fare una \func{exec} (di
cui parleremo in sez.~\ref{sec:proc_exec}) subito dopo la \func{fork}.
Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa
-seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
-operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
-scelto di mantenere questa separazione, dato che, come per la prima modalità
-d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
+seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
+operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
+scelto di mantenere questa separazione, dato che, come per la prima modalità
+d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
aver bisogno di eseguire una \func{exec}. Inoltre, anche nel caso della
-seconda modalità d'uso, avere le due funzioni separate permette al figlio di
+seconda modalità d'uso, avere le due funzioni separate permette al figlio di
cambiare gli attributi del processo (maschera dei segnali, redirezione
-dell'output, identificatori) prima della \func{exec}, rendendo così
-relativamente facile intervenire sulle le modalità di esecuzione del nuovo
+dell'output, identificatori) prima della \func{exec}, rendendo così
+relativamente facile intervenire sulle le modalità di esecuzione del nuovo
programma.
-In fig.~\ref{fig:proc_fork_code} è riportato il corpo del codice del programma
+In fig.~\ref{fig:proc_fork_code} è riportato il corpo del codice del programma
di esempio \cmd{forktest}, che permette di illustrare molte caratteristiche
dell'uso della funzione \func{fork}. Il programma crea un numero di figli
specificato da linea di comando, e prende anche alcune opzioni per indicare
degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
\func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
descrizione delle opzioni); il codice completo, compresa la parte che gestisce
-le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
+le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
distribuito insieme agli altri sorgenti degli esempi su
\href{http://gapil.truelite.it/gapil_source.tgz}
{\textsf{http://gapil.truelite.it/gapil\_source.tgz}}.
specificato e scrivere un messaggio prima di uscire. Il processo padre invece
(\texttt{\small 36--38}) stampa un messaggio di creazione, eventualmente
attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
-alla conclusione del ciclo, prima di uscire, può essere specificato un altro
+alla conclusione del ciclo, prima di uscire, può essere specificato un altro
periodo di attesa.
-Se eseguiamo il comando\footnote{che è preceduto dall'istruzione \code{export
+Se eseguiamo il comando\footnote{che è preceduto dall'istruzione \code{export
LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche.}
-senza specificare attese (come si può notare in (\texttt{\small 17--19}) i
+senza specificare attese (come si può notare in (\texttt{\small 17--19}) i
valori predefiniti specificano di non attendere), otterremo come output sul
terminale:
\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
\end{Verbatim}
%$
-Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
-si può dire quale processo fra il padre ed il figlio venga eseguito per primo
-dopo la chiamata a \func{fork}; dall'esempio si può notare infatti come nei
+Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
+si può dire quale processo fra il padre ed il figlio venga eseguito per primo
+dopo la chiamata a \func{fork}; dall'esempio si può notare infatti come nei
primi due cicli sia stato eseguito per primo il padre (con la stampa del
\acr{pid} del nuovo processo) per poi passare all'esecuzione del figlio
(completata con i due avvisi di esecuzione ed uscita), e tornare
all'esecuzione del padre (con la stampa del passaggio al ciclo successivo),
-mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione)
+mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione)
e poi il padre.
-In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
+In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
\itindex{scheduler} scheduling usato dal kernel, dalla particolare situazione
in cui si trova la macchina al momento della chiamata, risultando del tutto
-impredicibile. Eseguendo più volte il programma di prova e producendo un
+impredicibile. Eseguendo più volte il programma di prova e producendo un
numero diverso di figli, si sono ottenute situazioni completamente diverse,
-compreso il caso in cui il processo padre ha eseguito più di una \func{fork}
+compreso il caso in cui il processo padre ha eseguito più di una \func{fork}
prima che uno dei figli venisse messo in esecuzione.
-Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
-istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
-essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
-occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
+Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
+istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
+essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
+occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
rischio di incorrere nelle cosiddette \itindex{race~condition} \textit{race
condition} (vedi sez.~\ref{sec:proc_race_cond}).
-In realtà a partire dal kernel 2.5.2-pre10 il nuovo \itindex{scheduler}
+In realtà a partire dal kernel 2.5.2-pre10 il nuovo \itindex{scheduler}
\textit{scheduler} di Ingo Molnar esegue sempre per primo il
figlio;\footnote{i risultati precedenti sono stati ottenuti usando un kernel
- della serie 2.4.} questa è una ottimizzazione che serve a evitare che il
+ della serie 2.4.} questa è una ottimizzazione che serve a evitare che il
padre, effettuando per primo una operazione di scrittura in memoria, attivi il
meccanismo del \itindex{copy~on~write} \textit{copy on write}. Questa
operazione infatti potrebbe risultare del tutto inutile qualora il figlio
% prima il padre per questioni di caching nella CPU
Eseguendo sempre per primo il figlio la \func{exec} verrebbe effettuata subito
-avendo così la certezza che il \itindex{copy~on~write} \textit{copy on write}
+avendo così la certezza che il \itindex{copy~on~write} \textit{copy on write}
viene utilizzato solo quando necessario. Quanto detto in precedenza vale
-allora soltanto per i kernel fino al 2.4; per mantenere la portabilità è però
+allora soltanto per i kernel fino al 2.4; per mantenere la portabilità è però
opportuno non fare affidamento su questo comportamento, che non si riscontra
in altri Unix e nelle versioni del kernel precedenti a quella indicata.
alcun effetto sul valore che le stesse variabili hanno nel processo padre (ed
in eventuali altri processi figli che eseguano lo stesso codice).
-Un secondo aspetto molto importante nella creazione dei processi figli è
+Un secondo aspetto molto importante nella creazione dei processi figli è
quello dell'interazione dei vari processi con i file; per illustrarlo meglio
proviamo a redirigere su un file l'output del nostro programma di test, quello
-che otterremo è:
+che otterremo è:
\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
[piccardi@selidor sources]$ ./forktest 3 > output
[piccardi@selidor sources]$ cat output
Spawned 3 child, pid 1970
Go to next child
\end{Verbatim}
-che come si vede è completamente diverso da quanto ottenevamo sul terminale.
+che come si vede è completamente diverso da quanto ottenevamo sul terminale.
-Il comportamento delle varie funzioni di interfaccia con i file è analizzato
+Il comportamento delle varie funzioni di interfaccia con i file è analizzato
in gran dettaglio in cap.~\ref{cha:file_unix_interface} e in
cap.~\ref{cha:files_std_interface}. Qui basta accennare che si sono usate le
funzioni standard della libreria del C che prevedono l'output bufferizzato; e
Nel primo esempio allora avevamo che ad ogni chiamata a \func{printf} il
buffer veniva scaricato, e le singole righe erano stampate a video subito dopo
l'esecuzione della \func{printf}. Ma con la redirezione su file la scrittura
-non avviene più alla fine di ogni riga e l'output resta nel buffer. Dato che
-ogni figlio riceve una copia della memoria del padre, esso riceverà anche
-quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte dal
-padre fino allora. Così quando il buffer viene scritto su disco all'uscita del
+non avviene più alla fine di ogni riga e l'output resta nel buffer. Dato che
+ogni figlio riceve una copia della memoria del padre, esso riceverà anche
+quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte dal
+padre fino allora. Così quando il buffer viene scritto su disco all'uscita del
figlio, troveremo nel file anche tutto quello che il processo padre aveva
scritto prima della sua creazione. E alla fine del file (dato che in questo
caso il padre esce per ultimo) troveremo anche l'output completo del padre.
L'esempio ci mostra un altro aspetto fondamentale dell'interazione con i file,
-valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
+valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
solo processi diversi possono scrivere in contemporanea sullo stesso file
-(l'argomento della condivisione dei file è trattato in dettaglio in
+(l'argomento della condivisione dei file è trattato in dettaglio in
sez.~\ref{sec:file_sharing}), ma anche che, a differenza di quanto avviene per
-le variabili, la posizione corrente sul file è condivisa fra il padre e tutti
+le variabili, la posizione corrente sul file è condivisa fra il padre e tutti
i processi figli.
-Quello che succede è che quando lo standard output del padre viene rediretto
-come si è fatto nell'esempio, lo stesso avviene anche per tutti i figli; la
+Quello che succede è che quando lo standard output del padre viene rediretto
+come si è fatto nell'esempio, lo stesso avviene anche per tutti i figli; la
funzione \func{fork} infatti ha la caratteristica di duplicare nei processi
figli tutti i file descriptor aperti nel processo padre (allo stesso modo in
cui lo fa la funzione \func{dup}, trattata in sez.~\ref{sec:file_dup}), il che
comporta che padre e figli condividono le stesse voci della
\itindex{file~table} \textit{file table} (per la spiegazione di questi termini
-si veda sez.~\ref{sec:file_sharing}) fra cui c'è anche la posizione corrente
+si veda sez.~\ref{sec:file_sharing}) fra cui c'è anche la posizione corrente
nel file.
-In questo modo se un processo scrive sul file aggiornerà la posizione corrente
+In questo modo se un processo scrive sul file aggiornerà la posizione corrente
sulla \itindex{file~table} \textit{file table}, e tutti gli altri processi,
che vedono la stessa \itindex{file~table} \textit{file table}, vedranno il
nuovo valore. In questo modo si evita, in casi come quello appena mostrato in
cui diversi processi scrivono sullo stesso file, che l'output successivo di un
-processo vada a sovrapporsi a quello dei precedenti: l'output potrà risultare
+processo vada a sovrapporsi a quello dei precedenti: l'output potrà risultare
mescolato, ma non ci saranno parti perdute per via di una sovrascrittura.
-Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
+Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
crea un figlio e attende la sua conclusione per proseguire, ed entrambi
-scrivono sullo stesso file; un caso tipico è la shell quando lancia un
+scrivono sullo stesso file; un caso tipico è la shell quando lancia un
programma, il cui output va sullo standard output. In questo modo, anche se
-l'output viene rediretto, il padre potrà sempre continuare a scrivere in coda
-a quanto scritto dal figlio in maniera automatica; se così non fosse ottenere
+l'output viene rediretto, il padre potrà sempre continuare a scrivere in coda
+a quanto scritto dal figlio in maniera automatica; se così non fosse ottenere
questo comportamento sarebbe estremamente complesso necessitando di una
qualche forma di comunicazione fra i due processi per far riprendere al padre
la scrittura al punto giusto.
-In generale comunque non è buona norma far scrivere più processi sullo stesso
+In generale comunque non è buona norma far scrivere più processi sullo stesso
file senza una qualche forma di sincronizzazione in quanto, come visto anche
con il nostro esempio, le varie scritture risulteranno mescolate fra loro in
-una sequenza impredicibile. Per questo le modalità con cui in genere si usano
+una sequenza impredicibile. Per questo le modalità con cui in genere si usano
i file dopo una \func{fork} sono sostanzialmente due:
\begin{enumerate*}
\item Il processo padre aspetta la conclusione del figlio. In questo caso non
- è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
+ è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
della posizione corrente dopo eventuali operazioni di lettura e scrittura
- effettuate dal figlio è automatica.
+ effettuate dal figlio è automatica.
\item L'esecuzione di padre e figlio procede indipendentemente. In questo caso
ciascuno dei due processi deve chiudere i file che non gli servono una volta
- che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
+ che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
\end{enumerate*}
Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
-proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
-comune dopo l'esecuzione di una \func{fork} è la seguente:
+proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
+comune dopo l'esecuzione di una \func{fork} è la seguente:
\begin{itemize*}
\item i file aperti e gli eventuali flag di \itindex{close-on-exec}
\textit{close-on-exec} impostati (vedi sez.~\ref{sec:proc_exec} e
\item i segmenti di memoria condivisa agganciati al processo (vedi
sez.~\ref{sec:ipc_sysv_shm});
\item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
-\item il valori di \textit{nice}, le priorità real-time e le affinità di
+\item il valori di \textit{nice}, le priorità real-time e le affinità di
processore (vedi sez.~\ref{sec:proc_sched_stand},
sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess});
\item le variabili di ambiente (vedi sez.~\ref{sec:proc_environ}).
\end{itemize*}
Le differenze fra padre e figlio dopo la \func{fork} invece sono:\footnote{a
- parte le ultime quattro, relative a funzionalità specifiche di Linux, le
+ parte le ultime quattro, relative a funzionalità specifiche di Linux, le
altre sono esplicitamente menzionate dallo standard POSIX.1-2001.}
\begin{itemize*}
\item il valore di ritorno di \func{fork};
sez.~\ref{sec:file_memory_map}) che non vengono ereditate dal figlio;
\item l'impostazione con \func{prctl} (vedi sez.~\ref{sec:prctl_xxx}) che
notifica al figlio la terminazione del padre viene cancellata;
-\item il segnale di terminazione del figlio è sempre \const{SIGCHLD} anche
+\item il segnale di terminazione del figlio è sempre \const{SIGCHLD} anche
qualora nel padre fosse stato modificato (vedi sez.~\ref{sec:process_clone}).
\end{itemize*}
-Una seconda funzione storica usata per la creazione di un nuovo processo è
-\func{vfork}, che è esattamente identica a \func{fork} ed ha la stessa
-semantica e gli stessi errori; la sola differenza è che non viene creata la
-tabella delle pagine né la struttura dei task per il nuovo processo. Il
-processo padre è posto in attesa fintanto che il figlio non ha eseguito una
-\func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la
+Una seconda funzione storica usata per la creazione di un nuovo processo è
+\func{vfork}, che è esattamente identica a \func{fork} ed ha la stessa
+semantica e gli stessi errori; la sola differenza è che non viene creata la
+tabella delle pagine né la struttura dei task per il nuovo processo. Il
+processo padre è posto in attesa fintanto che il figlio non ha eseguito una
+\func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la
memoria del padre (e modifiche possono avere effetti imprevedibili) e non deve
ritornare o uscire con \func{exit} ma usare esplicitamente \func{\_exit}.
-Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una
+Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una
\func{fork} comportava anche la copia completa del segmento dati del processo
padre, che costituiva un inutile appesantimento in tutti quei casi in cui la
\func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione
venne introdotta in BSD per migliorare le prestazioni.
Dato che Linux supporta il \itindex{copy~on~write} \textit{copy on write} la
-perdita di prestazioni è assolutamente trascurabile, e l'uso di questa
+perdita di prestazioni è assolutamente trascurabile, e l'uso di questa
funzione, che resta un caso speciale della system call \func{clone} (che
-tratteremo in dettaglio in sez.~\ref{sec:process_clone}) è deprecato; per
+tratteremo in dettaglio in sez.~\ref{sec:process_clone}) è deprecato; per
questo eviteremo di trattarla ulteriormente.
\subsection{La conclusione di un processo}
\label{sec:proc_termination}
-In sez.~\ref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
+In sez.~\ref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
chiudere un programma, ma dall'interno del programma stesso; avendo a che fare
con un sistema multitasking resta da affrontare l'argomento dal punto di vista
di come il sistema gestisce la conclusione dei processi.
-Abbiamo visto in sez.~\ref{sec:proc_conclusion} le tre modalità con cui un
+Abbiamo visto in sez.~\ref{sec:proc_conclusion} le tre modalità con cui un
programma viene terminato in maniera normale: la chiamata di \func{exit} (che
esegue le funzioni registrate per l'uscita e chiude gli stream), il ritorno
dalla funzione \func{main} (equivalente alla chiamata di \func{exit}), e la
terminazione del processo da parte del kernel).
Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle
-modalità di conclusione anomala; queste sono in sostanza due: il programma può
+modalità di conclusione anomala; queste sono in sostanza due: il programma può
chiamare la funzione \func{abort} per invocare una chiusura anomala, o essere
terminato da un segnale (torneremo sui segnali in cap.~\ref{cha:signals}). In
-realtà anche la prima modalità si riconduce alla seconda, dato che
+realtà anche la prima modalità si riconduce alla seconda, dato che
\func{abort} si limita a generare il segnale \const{SIGABRT}.
-Qualunque sia la modalità di conclusione di un processo, il kernel esegue
+Qualunque sia la modalità di conclusione di un processo, il kernel esegue
comunque una serie di operazioni: chiude tutti i file aperti, rilascia la
-memoria che stava usando, e così via; l'elenco completo delle operazioni
-eseguite alla chiusura di un processo è il seguente:
+memoria che stava usando, e così via; l'elenco completo delle operazioni
+eseguite alla chiusura di un processo è il seguente:
\begin{itemize*}
\item tutti i file descriptor sono chiusi;
\item viene memorizzato lo stato di terminazione del processo;
\cmd{init});
\item viene inviato il segnale \const{SIGCHLD} al processo padre (vedi
sez.~\ref{sec:sig_sigchld});
-\item se il processo è un leader di sessione ed il suo terminale di controllo
- è quello della sessione viene mandato un segnale di \const{SIGHUP} a tutti i
+\item se il processo è un leader di sessione ed il suo terminale di controllo
+ è quello della sessione viene mandato un segnale di \const{SIGHUP} a tutti i
processi del gruppo di \textit{foreground} e il terminale di controllo viene
disconnesso (vedi sez.~\ref{sec:sess_ctrl_term});
\item se la conclusione di un processo rende orfano un \textit{process
(vedi ancora sez.~\ref{sec:sess_ctrl_term}).
\end{itemize*}
-Oltre queste operazioni è però necessario poter disporre di un meccanismo
-ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
+Oltre queste operazioni è però necessario poter disporre di un meccanismo
+ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
un sistema unix-like tutto viene gestito attraverso i processi, il meccanismo
scelto consiste nel riportare lo stato di terminazione (il cosiddetto
\textit{termination status}) al processo padre.
Nel caso di conclusione normale, abbiamo visto in
sez.~\ref{sec:proc_conclusion} che lo stato di uscita del processo viene
-caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
+caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
valore passato alle funzioni \func{exit} o \func{\_exit} (o dal valore di
ritorno per \func{main}). Ma se il processo viene concluso in maniera anomala
-il programma non può specificare nessun \textit{exit status}, ed è il kernel
+il programma non può specificare nessun \textit{exit status}, ed è il kernel
che deve generare autonomamente il \textit{termination status} per indicare le
ragioni della conclusione anomala.
Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
quello che contraddistingue lo stato di chiusura del processo e viene
riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
-sez.~\ref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale
+sez.~\ref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale
il kernel usa il primo (nel codice eseguito da \func{\_exit}) per produrre il
secondo.
La scelta di riportare al padre lo stato di terminazione dei figli, pur
essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
-alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
-che sia così alla sua conclusione, dato che il padre potrebbe essere già
-terminato; si potrebbe avere cioè quello che si chiama un processo
+alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
+che sia così alla sua conclusione, dato che il padre potrebbe essere già
+terminato; si potrebbe avere cioè quello che si chiama un processo
\textsl{orfano}.
Questa complicazione viene superata facendo in modo che il processo orfano
-venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
-termina, il kernel controlla se è il padre di altri processi in esecuzione: in
+venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
+termina, il kernel controlla se è il padre di altri processi in esecuzione: in
caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito
-con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
-avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo})
+con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
+avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo})
cui riportare il suo stato di terminazione. Come verifica di questo
comportamento possiamo eseguire il nostro programma \cmd{forktest} imponendo a
-ciascun processo figlio due secondi di attesa prima di uscire, il risultato è:
+ciascun processo figlio due secondi di attesa prima di uscire, il risultato è:
\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
[piccardi@selidor sources]$ ./forktest -c2 3
Process 1972: forking 3 child
Child 2, parent 1, exiting
Child 1, parent 1, exiting
\end{Verbatim}
-come si può notare in questo caso il processo padre si conclude prima dei
+come si può notare in questo caso il processo padre si conclude prima dei
figli, tornando alla shell, che stampa il prompt sul terminale: circa due
secondi dopo viene stampato a video anche l'output dei tre figli che
-terminano, e come si può notare in questo caso, al contrario di quanto visto
+terminano, e come si può notare in questo caso, al contrario di quanto visto
in precedenza, essi riportano 1 come \acr{ppid}.
-Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
-perché non è detto che il padre possa ricevere immediatamente lo stato di
-terminazione, quindi il kernel deve comunque conservare una certa quantità di
+Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
+perché non è detto che il padre possa ricevere immediatamente lo stato di
+terminazione, quindi il kernel deve comunque conservare una certa quantità di
informazioni riguardo ai processi che sta terminando.
Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
dal processo (vedi sez.~\ref{sec:sys_unix_time}) e lo stato di terminazione,
mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. I
-processi che sono terminati, ma il cui stato di terminazione non è stato
+processi che sono terminati, ma il cui stato di terminazione non è stato
ancora ricevuto dal padre sono chiamati \index{zombie} \textit{zombie}, essi
restano presenti nella tabella dei processi ed in genere possono essere
identificati dall'output di \cmd{ps} per la presenza di una \texttt{Z} nella
colonna che ne indica lo stato (vedi tab.~\ref{tab:proc_proc_states}). Quando
-il padre effettuerà la lettura dello stato di uscita anche questa
-informazione, non più necessaria, verrà scartata e la terminazione potrà dirsi
+il padre effettuerà la lettura dello stato di uscita anche questa
+informazione, non più necessaria, verrà scartata e la terminazione potrà dirsi
completamente conclusa.
Possiamo utilizzare il nostro programma di prova per analizzare anche questa
572 pts/0 R 0:00 ps T
\end{Verbatim}
%$
-e come si vede, dato che non si è fatto nulla per riceverne lo
+e come si vede, dato che non si è fatto nulla per riceverne lo
stato di terminazione, i tre processi figli sono ancora presenti pur essendosi
conclusi, con lo stato di \index{zombie} \textit{zombie} e l'indicazione che
sono stati terminati.
-La possibilità di avere degli \index{zombie} \textit{zombie} deve essere
+La possibilità di avere degli \index{zombie} \textit{zombie} deve essere
tenuta sempre presente quando si scrive un programma che deve essere mantenuto
in esecuzione a lungo e creare molti figli. In questo caso si deve sempre
avere cura di far leggere l'eventuale stato di uscita di tutti i figli (in
genere questo si fa attraverso un apposito \textit{signal handler}, che chiama
la funzione \func{wait}, vedi sez.~\ref{sec:sig_sigchld} e
-sez.~\ref{sec:proc_wait}). Questa operazione è necessaria perché anche se gli
+sez.~\ref{sec:proc_wait}). Questa operazione è necessaria perché anche se gli
\index{zombie} \textit{zombie} non consumano risorse di memoria o processore,
occupano comunque una voce nella tabella dei processi, che a lungo andare
potrebbe esaurirsi.
Si noti che quando un processo adottato da \cmd{init} termina, esso non
-diviene uno \index{zombie} \textit{zombie}; questo perché una delle funzioni
-di \cmd{init} è appunto quella di chiamare la funzione \func{wait} per i
-processi cui fa da padre, completandone la terminazione. Questo è quanto
+diviene uno \index{zombie} \textit{zombie}; questo perché una delle funzioni
+di \cmd{init} è appunto quella di chiamare la funzione \func{wait} per i
+processi cui fa da padre, completandone la terminazione. Questo è quanto
avviene anche quando, come nel caso del precedente esempio con \cmd{forktest},
il padre termina con dei figli in stato di \index{zombie} \textit{zombie}:
alla sua terminazione infatti tutti i suoi figli (compresi gli \index{zombie}
-\textit{zombie}) verranno adottati da \cmd{init}, il quale provvederà a
+\textit{zombie}) verranno adottati da \cmd{init}, il quale provvederà a
completarne la terminazione.
Si tenga presente infine che siccome gli \index{zombie} \textit{zombie} sono
-processi già usciti, non c'è modo di eliminarli con il comando \cmd{kill};
-l'unica possibilità di cancellarli dalla tabella dei processi è quella di
+processi già usciti, non c'è modo di eliminarli con il comando \cmd{kill};
+l'unica possibilità di cancellarli dalla tabella dei processi è quella di
terminare il processo che li ha generati, in modo che \cmd{init} possa
adottarli e provvedere a concluderne la terminazione.
di uscita}
\label{sec:proc_wait}
-Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
+Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
consiste nella creazione di programmi di tipo server, in cui un processo
principale attende le richieste che vengono poi soddisfatte da una serie di
-processi figli. Si è già sottolineato al paragrafo precedente come in questo
+processi figli. Si è già sottolineato al paragrafo precedente come in questo
caso diventi necessario gestire esplicitamente la conclusione dei figli onde
evitare di riempire di \index{zombie} \textit{zombie} la tabella dei processi;
le funzioni deputate a questo compito sono principalmente due, \funcd{wait} e
-\func{waitpid}. La prima, il cui prototipo è:
+\func{waitpid}. La prima, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/wait.h}
\funcdecl{pid\_t wait(int *status)}
-Sospende il processo corrente finché un figlio non è uscito, o finché un
+Sospende il processo corrente finché un figlio non è uscito, o finché un
segnale termina il processo o chiama una funzione di gestione.
\bodydesc{La funzione restituisce il \acr{pid} del figlio in caso di successo
- e -1 in caso di errore; \var{errno} può assumere i valori:
+ e -1 in caso di errore; \var{errno} può assumere i valori:
\begin{errlist}
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\end{errlist}}
\end{functions}
\noindent
-è presente fin dalle prime versioni di Unix; la funzione ritorna non appena un
-processo figlio termina. Se un figlio è già terminato la funzione ritorna
-immediatamente, se più di un figlio è terminato occorre chiamare la funzione
-più volte se si vuole recuperare lo stato di terminazione di tutti quanti.
+è presente fin dalle prime versioni di Unix; la funzione ritorna non appena un
+processo figlio termina. Se un figlio è già terminato la funzione ritorna
+immediatamente, se più di un figlio è terminato occorre chiamare la funzione
+più volte se si vuole recuperare lo stato di terminazione di tutti quanti.
Al ritorno della funzione lo stato di terminazione del figlio viene salvato
nella variabile puntata da \param{status} e tutte le risorse del kernel
relative al processo (vedi sez.~\ref{sec:proc_termination}) vengono rilasciate.
-Nel caso un processo abbia più figli il valore di ritorno (il \acr{pid} del
-figlio) permette di identificare qual è quello che è uscito.
+Nel caso un processo abbia più figli il valore di ritorno (il \acr{pid} del
+figlio) permette di identificare qual è quello che è uscito.
Questa funzione ha il difetto di essere poco flessibile, in quanto ritorna
-all'uscita di un qualunque processo figlio. Nelle occasioni in cui è
+all'uscita di un qualunque processo figlio. Nelle occasioni in cui è
necessario attendere la conclusione di un processo specifico occorrerebbe
-predisporre un meccanismo che tenga conto dei processi già terminati, e
+predisporre un meccanismo che tenga conto dei processi già terminati, e
provvedere a ripetere la chiamata alla funzione nel caso il processo cercato
sia ancora attivo.
Per questo motivo lo standard POSIX.1 ha introdotto la funzione
\funcd{waitpid} che effettua lo stesso servizio, ma dispone di una serie di
-funzionalità più ampie, legate anche al controllo di sessione (si veda
-sez.~\ref{sec:sess_job_control}). Dato che è possibile ottenere lo stesso
+funzionalità più ampie, legate anche al controllo di sessione (si veda
+sez.~\ref{sec:sess_job_control}). Dato che è possibile ottenere lo stesso
comportamento di \func{wait}\footnote{in effetti il codice
- \code{wait(\&status)} è del tutto equivalente a \code{waitpid(WAIT\_ANY,
+ \code{wait(\&status)} è del tutto equivalente a \code{waitpid(WAIT\_ANY,
\&status, 0)}.} si consiglia di utilizzare sempre questa funzione, il cui
-prototipo è:
+prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/wait.h}
\funcdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
Attende la conclusione di un processo figlio.
-\bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se
- è stata specificata l'opzione \const{WNOHANG} e il processo non è uscito e
- -1 per un errore, nel qual caso \var{errno} assumerà i valori:
+\bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se
+ è stata specificata l'opzione \const{WNOHANG} e il processo non è uscito e
+ -1 per un errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
- la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
+ la funzione è stata interrotta da un segnale.
\item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
- non è figlio del processo chiamante.
- \item[\errcode{EINVAL}] si è specificato un valore non valido per
+ non è figlio del processo chiamante.
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per
l'argomento \param{options}.
\end{errlist}}
\end{functions}
-La prima differenza fra le due funzioni è che con \func{waitpid} si può
+La prima differenza fra le due funzioni è che con \func{waitpid} si può
specificare in maniera flessibile quale processo attendere, sulla base del
-valore fornito dall'argomento \param{pid}, questo può assumere diversi valori,
+valore fornito dall'argomento \param{pid}, questo può assumere diversi valori,
secondo lo specchietto riportato in tab.~\ref{tab:proc_waidpid_pid}, dove si
sono riportate anche le costanti definite per indicare alcuni di essi.
\hline
$<-1$& -- & Attende per un figlio il cui
\itindex{process~group} \textit{process group}
- (vedi sez.~\ref{sec:sess_proc_group}) è uguale
+ (vedi sez.~\ref{sec:sess_proc_group}) è uguale
al valore assoluto di \param{pid}. \\
$-1$&\const{WAIT\_ANY} & Attende per un figlio qualsiasi, usata in
questa maniera senza specificare nessuna opzione
- è equivalente a \func{wait}.\\
+ è equivalente a \func{wait}.\\
$ 0$&\const{WAIT\_MYPGRP}&Attende per un figlio il cui
\itindex{process~group} \textit{process group}
- (vedi sez.~\ref{sec:sess_proc_group}) è
+ (vedi sez.~\ref{sec:sess_proc_group}) è
uguale a quello del processo chiamante. \\
- $>0$& -- & Attende per un figlio il cui \acr{pid} è uguale
+ $>0$& -- & Attende per un figlio il cui \acr{pid} è uguale
al valore di \param{pid}.\\
\hline
\end{tabular}
\label{tab:proc_waidpid_pid}
\end{table}
-Il comportamento di \func{waitpid} può inoltre essere modificato passando alla
+Il comportamento di \func{waitpid} può inoltre essere modificato passando alla
funzione delle opportune opzioni tramite l'argomento \param{options}; questo
deve essere specificato come maschera binaria dei flag riportati nella prima
parte in tab.~\ref{tab:proc_waitpid_options} che possono essere combinati fra
loro con un OR aritmetico. Nella seconda parte della stessa tabella si sono
riportati anche alcuni valori non standard specifici di Linux, che consentono
-un controllo più dettagliato per i processi creati con la system call generica
+un controllo più dettagliato per i processi creati con la system call generica
\func{clone} (vedi sez.~\ref{sec:process_clone}) usati principalmente per la
gestione della terminazione dei \itindex{thread} \textit{thread} (vedi
sez.~\ref{sec:thread_xxx}).
\textbf{Macro} & \textbf{Descrizione}\\
\hline
\hline
- \const{WNOHANG} & La funzione ritorna immediatamente anche se non è
+ \const{WNOHANG} & La funzione ritorna immediatamente anche se non è
terminato nessun processo figlio. \\
- \const{WUNTRACED} & Ritorna anche se un processo figlio è stato fermato. \\
+ \const{WUNTRACED} & Ritorna anche se un processo figlio è stato fermato. \\
\const{WCONTINUED}& Ritorna anche quando un processo figlio che era stato
fermato ha ripreso l'esecuzione.\footnotemark \\
\hline
L'uso dell'opzione \const{WNOHANG} consente di prevenire il blocco della
funzione qualora nessun figlio sia uscito (o non si siano verificate le altre
-condizioni per l'uscita della funzione); in tal caso la funzione ritornerà un
-valore nullo anziché positivo.\footnote{anche in questo caso un valore
- positivo indicherà il \acr{pid} del processo di cui si è ricevuto lo stato
+condizioni per l'uscita della funzione); in tal caso la funzione ritornerà un
+valore nullo anziché positivo.\footnote{anche in questo caso un valore
+ positivo indicherà il \acr{pid} del processo di cui si è ricevuto lo stato
ed un valore negativo un errore.}
Le altre due opzioni \const{WUNTRACED} e \const{WCONTINUED} consentono
Nel caso di \const{WUNTRACED} la funzione ritorna, restituendone il \acr{pid},
quando un processo figlio entra nello stato \textit{stopped}\footnote{in
- realtà viene notificato soltanto il caso in cui il processo è stato fermato
+ realtà viene notificato soltanto il caso in cui il processo è stato fermato
da un segnale di stop (vedi sez.~\ref{sec:sess_ctrl_term}), e non quello in
- cui lo stato \textit{stopped} è dovuto all'uso di \func{ptrace} (vedi
+ cui lo stato \textit{stopped} è dovuto all'uso di \func{ptrace} (vedi
sez.~\ref{sec:xxx_ptrace}).} (vedi tab.~\ref{tab:proc_proc_states}), mentre
con \const{WCONTINUED} la funzione ritorna quando un processo in stato
\textit{stopped} riprende l'esecuzione per la ricezione del segnale
-\const{SIGCONT} (l'uso di questi segnali per il controllo di sessione è
+\const{SIGCONT} (l'uso di questi segnali per il controllo di sessione è
dettagliato in sez.~\ref{sec:sess_ctrl_term}).
-La terminazione di un processo figlio (così come gli altri eventi osservabili
-con \func{waitpid}) è chiaramente un evento asincrono rispetto all'esecuzione
-di un programma e può avvenire in un qualunque momento. Per questo motivo,
+La terminazione di un processo figlio (così come gli altri eventi osservabili
+con \func{waitpid}) è chiaramente un evento asincrono rispetto all'esecuzione
+di un programma e può avvenire in un qualunque momento. Per questo motivo,
come accennato nella sezione precedente, una delle azioni prese dal kernel
-alla conclusione di un processo è quella di mandare un segnale di
+alla conclusione di un processo è quella di mandare un segnale di
\const{SIGCHLD} al padre. L'azione predefinita (si veda
-sez.~\ref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua
+sez.~\ref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua
generazione costituisce il meccanismo di comunicazione asincrona con cui il
-kernel avverte il processo padre che uno dei suoi figli è terminato.
+kernel avverte il processo padre che uno dei suoi figli è terminato.
-Il comportamento delle funzioni è però cambiato nel passaggio dal kernel 2.4
-al kernel 2.6, quest'ultimo infatti si è adeguato alle prescrizioni dello
+Il comportamento delle funzioni è però cambiato nel passaggio dal kernel 2.4
+al kernel 2.6, quest'ultimo infatti si è adeguato alle prescrizioni dello
standard POSIX.1-2001,\footnote{una revisione del 2001 dello standard POSIX.1
che ha aggiunto dei requisiti e delle nuove funzioni, come \func{waitid}.}
e come da esso richiesto se \const{SIGCHLD} viene ignorato, o se si imposta il
sez.~\ref{sec:sig_sigaction}) i processi figli che terminano non diventano
\textit{zombie} e sia \func{wait} che \func{waitpid} si bloccano fintanto che
tutti i processi figli non sono terminati, dopo di che falliscono con un
-errore di \errcode{ENOCHLD}.\footnote{questo è anche il motivo per cui le
+errore di \errcode{ENOCHLD}.\footnote{questo è anche il motivo per cui le
opzioni \const{WUNTRACED} e \const{WCONTINUED} sono utilizzabili soltanto
qualora non si sia impostato il flag di \const{SA\_NOCLDSTOP} per il segnale
\const{SIGCHLD}.}
\macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello
stato di uscita del processo (passato attraverso
\func{\_exit}, \func{exit} o come valore di
- ritorno di \func{main}); può essere valutata solo
+ ritorno di \func{main}); può essere valutata solo
se \val{WIFEXITED} ha restituito un valore non
nullo.\\
- \macro{WIFSIGNALED(s)} & Condizione vera se il processo figlio è terminato
+ \macro{WIFSIGNALED(s)} & Condizione vera se il processo figlio è terminato
in maniera anomala a causa di un segnale che non
- è stato catturato (vedi
+ è stato catturato (vedi
sez.~\ref{sec:sig_notification}).\\
\macro{WTERMSIG(s)} & Restituisce il numero del segnale che ha causato
- la terminazione anomala del processo; può essere
+ la terminazione anomala del processo; può essere
valutata solo se \val{WIFSIGNALED} ha restituito
un valore non nullo.\\
\macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un
file di \itindex{core~dump} \textit{core
- dump}; può essere valutata solo se
+ dump}; può essere valutata solo se
\val{WIFSIGNALED} ha restituito un valore non
nullo.\footnotemark \\
\macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di
- \func{waitpid} è bloccato; l'uso è possibile solo
+ \func{waitpid} è bloccato; l'uso è possibile solo
con \func{waitpid} avendo specificato l'opzione
\const{WUNTRACED}.\\
\macro{WSTOPSIG(s)} & Restituisce il numero del segnale che ha bloccato
- il processo; può essere valutata solo se
+ il processo; può essere valutata solo se
\val{WIFSTOPPED} ha restituito un valore non
nullo. \\
- \macro{WIFCONTINUED(s)}& Vera se il processo che ha causato il ritorno è
+ \macro{WIFCONTINUED(s)}& Vera se il processo che ha causato il ritorno è
stato riavviato da un
\const{SIGCONT}.\footnotemark \\
\hline
\label{tab:proc_status_macro}
\end{table}
-\footnotetext[20]{questa macro non è definita dallo standard POSIX.1-2001, ma è
+\footnotetext[20]{questa macro non è definita dallo standard POSIX.1-2001, ma è
presente come estensione sia in Linux che in altri Unix, deve essere
- pertanto utilizzata con attenzione (ad esempio è il caso di usarla in un
+ pertanto utilizzata con attenzione (ad esempio è il caso di usarla in un
blocco \texttt{\#ifdef WCOREDUMP ... \#endif}.}
-\footnotetext{è presente solo a partire dal kernel 2.6.10.}
+\footnotetext{è presente solo a partire dal kernel 2.6.10.}
In generale in un programma non si vuole essere forzati ad attendere la
conclusione di un processo figlio per proseguire l'esecuzione, specie se tutto
questo serve solo per leggerne lo stato di chiusura (ed evitare eventualmente
la presenza di \index{zombie} \textit{zombie}).
-Per questo la modalità più comune di chiamare queste funzioni è quella di
+Per questo la modalità più comune di chiamare queste funzioni è quella di
utilizzarle all'interno di un \textit{signal handler} (vedremo un esempio di
come gestire \const{SIGCHLD} con i segnali in sez.~\ref{sec:sig_example}). In
-questo caso infatti, dato che il segnale è generato dalla terminazione di un
-figlio, avremo la certezza che la chiamata a \func{waitpid} non si bloccherà.
+questo caso infatti, dato che il segnale è generato dalla terminazione di un
+figlio, avremo la certezza che la chiamata a \func{waitpid} non si bloccherà.
Come accennato sia \func{wait} che \func{waitpid} restituiscono lo stato di
terminazione del processo tramite il puntatore \param{status} (se non
-interessa memorizzare lo stato si può passare un puntatore nullo). Il valore
+interessa memorizzare lo stato si può passare un puntatore nullo). Il valore
restituito da entrambe le funzioni dipende dall'implementazione, ma
tradizionalmente alcuni bit (in genere 8) sono riservati per memorizzare lo
stato di uscita, e altri per indicare il segnale che ha causato la
-terminazione (in caso di conclusione anomala), uno per indicare se è stato
+terminazione (in caso di conclusione anomala), uno per indicare se è stato
generato un \itindex{core~dump} \textit{core dump}, ecc.\footnote{le
definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
questo file non deve mai essere usato direttamente, esso viene incluso
da \func{wait} o \func{waitpid}.
Si tenga conto che nel caso di conclusione anomala il valore restituito da
-\val{WTERMSIG} può essere confrontato con le costanti che identificano i
+\val{WTERMSIG} può essere confrontato con le costanti che identificano i
segnali definite in \file{signal.h} ed elencate in
tab.~\ref{tab:sig_signal_list}, e stampato usando le apposite funzioni
trattate in sez.~\ref{sec:sig_strsignal}.
-A partire dal kernel 2.6.9, sempre in conformità allo standard POSIX.1-2001, è
+A partire dal kernel 2.6.9, sempre in conformità allo standard POSIX.1-2001, è
stata introdotta una nuova funzione di attesa che consente di avere un
-controllo molto più preciso sui possibili cambiamenti di stato dei processi
-figli e più dettagli sullo stato di uscita; la funzione è \funcd{waitid} ed il
-suo prototipo è:
+controllo molto più preciso sui possibili cambiamenti di stato dei processi
+figli e più dettagli sullo stato di uscita; la funzione è \funcd{waitid} ed il
+suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
Attende la conclusione di un processo figlio.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore,
- nel qual caso \var{errno} assumerà i valori:
+ nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EINTR}] se non è stata specificata l'opzione \const{WNOHANG} e
- la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINTR}] se non è stata specificata l'opzione \const{WNOHANG} e
+ la funzione è stata interrotta da un segnale.
\item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
- non è figlio del processo chiamante.
- \item[\errcode{EINVAL}] si è specificato un valore non valido per
+ non è figlio del processo chiamante.
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per
l'argomento \param{options}.
\end{errlist}}
\end{functions}
Come per \func{waitpid} anche il comportamento di \func{waitid} viene
controllato dall'argomento \param{options}, da specificare come maschera
-binaria dei valori riportati in tab.~\ref{tab:proc_waitid_options}. Benché
+binaria dei valori riportati in tab.~\ref{tab:proc_waitid_options}. Benché
alcuni di questi siano identici come significato ed effetto ai precedenti di
tab.~\ref{tab:proc_waitpid_options}, ci sono delle differenze significative:
-in questo caso si dovrà specificare esplicitamente l'attesa della terminazione
+in questo caso si dovrà specificare esplicitamente l'attesa della terminazione
di un processo impostando l'opzione \const{WEXITED}, mentre il precedente
-\const{WUNTRACED} è sostituito da \const{WSTOPPED}. Infine è stata aggiunta
+\const{WUNTRACED} è sostituito da \const{WSTOPPED}. Infine è stata aggiunta
l'opzione \const{WNOWAIT} che consente una lettura dello stato mantenendo il
-processo in attesa di ricezione, così che una successiva chiamata possa di
+processo in attesa di ricezione, così che una successiva chiamata possa di
nuovo riceverne lo stato.
\begin{table}[!htb]
\textbf{Macro} & \textbf{Descrizione}\\
\hline
\hline
- \const{WEXITED} & Ritorna quando un processo figlio è terminato.\\
- \const{WNOHANG} & Ritorna immediatamente anche se non c'è niente da
+ \const{WEXITED} & Ritorna quando un processo figlio è terminato.\\
+ \const{WNOHANG} & Ritorna immediatamente anche se non c'è niente da
notificare.\\
- \const{WSTOPPED} & Ritorna quando un processo figlio è stato fermato.\\
+ \const{WSTOPPED} & Ritorna quando un processo figlio è stato fermato.\\
\const{WCONTINUED}& Ritorna quando un processo figlio che era stato
fermato ha ripreso l'esecuzione.\\
- \const{WNOWAIT} & Lascia il processo ancora in attesa di ricezione, così
+ \const{WNOWAIT} & Lascia il processo ancora in attesa di ricezione, così
che una successiva chiamata possa di nuovo riceverne
lo stato.\\
\hline
\end{table}
La funzione \func{waitid} restituisce un valore nullo in caso di successo, e
-$-1$ in caso di errore; viene restituito un valore nullo anche se è stata
-specificata l'opzione \const{WNOHANG} e la funzione è ritornata immediatamente
+$-1$ in caso di errore; viene restituito un valore nullo anche se è stata
+specificata l'opzione \const{WNOHANG} e la funzione è ritornata immediatamente
senza che nessun figlio sia terminato. Pertanto per verificare il motivo del
ritorno della funzione occorre analizzare le informazioni che essa
restituisce; queste, al contrario delle precedenti \func{wait} e
\item[\var{si\_code}] con uno fra \const{CLD\_EXITED}, \const{CLD\_KILLED},
\const{CLD\_STOPPED}, \const{CLD\_CONTINUED}, \const{CLD\_TRAPPED} e
\const{CLD\_DUMPED} a indicare la ragione del ritorno della funzione, il cui
- significato è, nell'ordine: uscita normale, terminazione da segnale,
+ significato è, nell'ordine: uscita normale, terminazione da segnale,
processo fermato, processo riavviato, processo terminato in \textit{core
dump}.
\end{basedescript}
Infine Linux, seguendo un'estensione di BSD, supporta altre due funzioni per
la lettura dello stato di terminazione di un processo, analoghe alle
precedenti ma che prevedono un ulteriore argomento attraverso il quale il
-kernel può restituire al padre informazioni sulle risorse (vedi
+kernel può restituire al padre informazioni sulle risorse (vedi
sez.~\ref{sec:sys_res_limits}) usate dal processo terminato e dai vari figli.
Le due funzioni sono \funcd{wait3} e \funcd{wait4}, che diventano accessibili
definendo la macro \macro{\_USE\_BSD}; i loro prototipi sono:
\funcdecl{pid\_t wait4(pid\_t pid, int *status, int options, struct rusage
*rusage)}
- È identica a \func{waitpid} sia per comportamento che per i valori degli
+ È identica a \func{waitpid} sia per comportamento che per i valori degli
argomenti, ma restituisce in \param{rusage} un sommario delle risorse usate
dal processo.
\funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
- Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
+ Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
ormai deprecata in favore di \func{wait4}.
\end{functions}
\noindent
-la struttura \struct{rusage} è definita in \file{sys/resource.h}, e viene
+la struttura \struct{rusage} è definita in \file{sys/resource.h}, e viene
utilizzata anche dalla funzione \func{getrusage} (vedi
sez.~\ref{sec:sys_resource_use}) per ottenere le risorse di sistema usate da un
-processo; la sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct}.
+processo; la sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct}.
\subsection{La funzione \func{exec} e le funzioni di esecuzione dei programmi}
\label{sec:proc_exec}
-Abbiamo già detto che una delle modalità principali con cui si utilizzano i
-processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
+Abbiamo già detto che una delle modalità principali con cui si utilizzano i
+processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
processo chiama una di queste funzioni esso viene completamente sostituito dal
nuovo programma; il \acr{pid} del processo non cambia, dato che non viene
\index{segmento!dati} dati ed il \index{segmento!testo} testo del processo
corrente con un nuovo programma letto da disco.
-Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
-famiglia di funzioni) che possono essere usate per questo compito, in realtà
+Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
+famiglia di funzioni) che possono essere usate per questo compito, in realtà
(come mostrato in fig.~\ref{fig:proc_exec_relat}), sono tutte un front-end a
-\funcd{execve}. Il prototipo di quest'ultima è:
+\funcd{execve}. Il prototipo di quest'ultima è:
\begin{prototype}{unistd.h}
{int execve(const char *filename, char *const argv[], char *const envp[])}
Esegue il programma contenuto nel file \param{filename}.
\bodydesc{La funzione ritorna solo in caso di errore, restituendo -1; nel
- qual caso \var{errno} può assumere i valori:
+ qual caso \var{errno} può assumere i valori:
\begin{errlist}
- \item[\errcode{EACCES}] il file non è eseguibile, oppure il filesystem è
- montato in \cmd{noexec}, oppure non è un file regolare o un interprete.
+ \item[\errcode{EACCES}] il file non è eseguibile, oppure il filesystem è
+ montato in \cmd{noexec}, oppure non è un file regolare o un interprete.
\item[\errcode{EPERM}] il file ha i bit \itindex{suid~bit} \acr{suid} o
- \itindex{sgid~bit} \acr{sgid}, l'utente non è root, il processo viene
- tracciato, o il filesystem è montato con l'opzione \cmd{nosuid}.
- \item[\errcode{ENOEXEC}] il file è in un formato non eseguibile o non
+ \itindex{sgid~bit} \acr{sgid}, l'utente non è root, il processo viene
+ tracciato, o il filesystem è montato con l'opzione \cmd{nosuid}.
+ \item[\errcode{ENOEXEC}] il file è in un formato non eseguibile o non
riconosciuto come tale, o compilato per un'altra architettura.
\item[\errcode{ENOENT}] il file o una delle librerie dinamiche o l'interprete
necessari per eseguirlo non esistono.
- \item[\errcode{ETXTBSY}] l'eseguibile è aperto in scrittura da uno o più
+ \item[\errcode{ETXTBSY}] l'eseguibile è aperto in scrittura da uno o più
processi.
- \item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento
- \const{PF\_INTERP}, cioè chiede di essere eseguito da più di un
+ \item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento
+ \const{PF\_INTERP}, cioè chiede di essere eseguito da più di un
interprete.
- \item[\errcode{ELIBBAD}] un interprete ELF non è in un formato
+ \item[\errcode{ELIBBAD}] un interprete ELF non è in un formato
riconoscibile.
- \item[\errcode{E2BIG}] la lista degli argomenti è troppo grande.
+ \item[\errcode{E2BIG}] la lista degli argomenti è troppo grande.
\end{errlist}
ed inoltre anche \errval{EFAULT}, \errval{ENOMEM}, \errval{EIO},
\errval{ENAMETOOLONG}, \errval{ELOOP}, \errval{ENOTDIR}, \errval{ENFILE},
e come ambiente la lista di stringhe indicata da \param{envp}; entrambe le
liste devono essere terminate da un puntatore nullo. I vettori degli
argomenti e dell'ambiente possono essere acceduti dal nuovo programma
-quando la sua funzione \func{main} è dichiarata nella forma
+quando la sua funzione \func{main} è dichiarata nella forma
\code{main(int argc, char *argv[], char *envp[])}.
Le altre funzioni della famiglia servono per fornire all'utente una serie di
linea di comando e l'ambiente ricevuti dal nuovo processo.
\bodydesc{Queste funzioni ritornano solo in caso di errore, restituendo -1;
- nel qual caso \var{errno} assumerà i valori visti in precedenza per
+ nel qual caso \var{errno} assumerà i valori visti in precedenza per
\func{execve}.}
\end{functions}
-Per capire meglio le differenze fra le funzioni della famiglia si può fare
+Per capire meglio le differenze fra le funzioni della famiglia si può fare
riferimento allo specchietto riportato in tab.~\ref{tab:proc_exec_scheme}. La
-prima differenza riguarda le modalità di passaggio dei valori che poi andranno
-a costituire gli argomenti a linea di comando (cioè i valori di
+prima differenza riguarda le modalità di passaggio dei valori che poi andranno
+a costituire gli argomenti a linea di comando (cioè i valori di
\param{argv} e \param{argc} visti dalla funzione \func{main} del programma
chiamato).
-Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
+Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
\includecodesnip{listati/char_list.c}
che deve essere terminata da un puntatore nullo. In entrambi i casi vale la
convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
-per indicare il nome del file che contiene il programma che verrà eseguito.
+per indicare il nome del file che contiene il programma che verrà eseguito.
\begin{table}[!htb]
\footnotesize
\label{tab:proc_exec_scheme}
\end{table}
-La seconda differenza fra le funzioni riguarda le modalità con cui si
+La seconda differenza fra le funzioni riguarda le modalità con cui si
specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si
indicano le due funzioni che replicano il comportamento della shell nello
specificare il comando da eseguire; quando l'argomento \param{file} non
contiene una ``\texttt{/}'' esso viene considerato come un nome di programma,
e viene eseguita automaticamente una ricerca fra i file presenti nella lista
di directory specificate dalla variabile di ambiente \var{PATH}. Il file che
-viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
-relativo a permessi di accesso insufficienti (cioè l'esecuzione della
+viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
+relativo a permessi di accesso insufficienti (cioè l'esecuzione della
sottostante \func{execve} ritorna un \errcode{EACCES}), la ricerca viene
proseguita nelle eventuali ulteriori directory indicate in \var{PATH}; solo se
non viene trovato nessun altro file viene finalmente restituito
\label{fig:proc_exec_relat}
\end{figure}
-La terza differenza è come viene passata la lista delle variabili di ambiente.
+La terza differenza è come viene passata la lista delle variabili di ambiente.
Con lo mnemonico \texttt{e} vengono indicate quelle funzioni che necessitano
di un vettore di parametri \var{envp[]} analogo a quello usato per gli
argomenti a riga di comando (terminato quindi da un \val{NULL}), le altre
l'ambiente.
Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da
-\func{exec} mantiene la gran parte delle proprietà del processo chiamante; una
-lista delle più significative è la seguente:
+\func{exec} mantiene la gran parte delle proprietà del processo chiamante; una
+lista delle più significative è la seguente:
\begin{itemize*}
\item il \textit{process id} (\acr{pid}) ed il \textit{parent process id}
(\acr{ppid});
\item i valori delle variabili \var{tms\_utime}, \var{tms\_stime};
\var{tms\_cutime}, \var{tms\_ustime} (vedi sez.~\ref{sec:sys_cpu_times});
% TODO ===========Importante=============
-% TODO questo sotto è incerto, verificare
+% TODO questo sotto è incerto, verificare
% TODO ===========Importante=============
\item la maschera dei segnali (si veda sez.~\ref{sec:sig_sigmask}).
\end{itemize*}
-Una serie di proprietà del processo originale, che non avrebbe senso mantenere
+Una serie di proprietà del processo originale, che non avrebbe senso mantenere
in un programma che esegue un codice completamente diverso in uno spazio di
indirizzi totalmente indipendente e ricreato da zero, vengono perse con
l'esecuzione di \func{exec}; lo standard POSIX.1-2001 prevede che le seguenti
-proprietà non vengano preservate:
+proprietà non vengano preservate:
\begin{itemize*}
\item l'insieme dei segnali pendenti (vedi sez.~\ref{sec:sig_gen_beha}), che
viene cancellato;
I segnali che sono stati impostati per essere ignorati nel processo chiamante
mantengono la stessa impostazione pure nel nuovo programma, ma tutti gli altri
-segnali, ed in particolare quelli per i quali è stato installato un gestore
+segnali, ed in particolare quelli per i quali è stato installato un gestore
vengono impostati alla loro azione predefinita (vedi
-sez.~\ref{sec:sig_gen_beha}). Un caso speciale è il segnale \const{SIGCHLD}
+sez.~\ref{sec:sig_gen_beha}). Un caso speciale è il segnale \const{SIGCHLD}
che, quando impostato a \const{SIG\_IGN}, potrebbe anche essere reimpostato a
\const{SIG\_DFL}, anche se questo con Linux non avviene.\footnote{lo standard
POSIX.1-2001 prevede che questo comportamento sia deciso dalla singola
- implementazione, quella di Linux è di non modificare l'impostazione
+ implementazione, quella di Linux è di non modificare l'impostazione
precedente.}
Oltre alle precedenti che sono completamente generali e disponibili anche su
-altri sistemi unix-like, esistono altre proprietà dei processi, attinenti
+altri sistemi unix-like, esistono altre proprietà dei processi, attinenti
caratteristiche specifiche di Linux, che non vengono preservate
nell'esecuzione della funzione \func{exec}, queste sono:
\begin{itemize*}
La gestione dei file aperti nel passaggio al nuovo programma lanciato con
\func{exec} dipende dal valore che ha il flag di \itindex{close-on-exec}
\textit{close-on-exec} (vedi anche sez.~\ref{sec:file_fcntl}) per ciascun file
-descriptor. I file per cui è impostato vengono chiusi, tutti gli altri file
-restano aperti. Questo significa che il comportamento predefinito è che i file
+descriptor. I file per cui è impostato vengono chiusi, tutti gli altri file
+restano aperti. Questo significa che il comportamento predefinito è che i file
restano aperti attraverso una \func{exec}, a meno di una chiamata esplicita a
\func{fcntl} che imposti il suddetto flag. Per le directory, lo standard
POSIX.1 richiede che esse vengano chiuse attraverso una \func{exec}, in genere
-questo è fatto dalla funzione \func{opendir} (vedi
+questo è fatto dalla funzione \func{opendir} (vedi
sez.~\ref{sec:file_dir_read}) che effettua da sola l'impostazione del flag di
\itindex{close-on-exec} \textit{close-on-exec} sulle directory che apre, in
maniera trasparente all'utente.
Il comportamento della funzione in relazione agli identificatori relativi al
-controllo di accesso verrà trattato in dettaglio in sez.~\ref{sec:proc_perms},
-qui è sufficiente anticipare (si faccia riferimento a
+controllo di accesso verrà trattato in dettaglio in sez.~\ref{sec:proc_perms},
+qui è sufficiente anticipare (si faccia riferimento a
sez.~\ref{sec:proc_access_id} per la definizione di questi identificatori)
come l'\textsl{user-ID reale} ed il \textsl{group-ID reale} restano sempre gli
stessi, mentre l'\textsl{user-ID salvato} ed il \textsl{group-ID salvato}
effettivo} vengono impostati rispettivamente all'utente o al gruppo cui il
file appartiene.
-Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
+Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
condivise, viene lanciato il \textit{linker} dinamico \cmd{/lib/ld.so} prima
del programma per caricare le librerie necessarie ed effettuare il link
-dell'eseguibile.\footnote{il formato è ormai in completo disuso, per cui è
+dell'eseguibile.\footnote{il formato è ormai in completo disuso, per cui è
molto probabile che non il relativo supporto non sia disponibile.} Se il
-programma è in formato ELF per caricare le librerie dinamiche viene usato
+programma è in formato ELF per caricare le librerie dinamiche viene usato
l'interprete indicato nel segmento \const{PT\_INTERP} previsto dal formato
-stesso, in genere questo è \sysfile{/lib/ld-linux.so.1} per programmi
+stesso, in genere questo è \sysfile{/lib/ld-linux.so.1} per programmi
collegati con le \acr{libc5}, e \sysfile{/lib/ld-linux.so.2} per programmi
collegati con le \acr{glibc}.
Infine nel caso il file sia uno script esso deve iniziare con una linea nella
forma \cmd{\#!/path/to/interpreter [argomenti]} dove l'interprete indicato
-deve essere un programma valido (binario, non un altro script) che verrà
+deve essere un programma valido (binario, non un altro script) che verrà
chiamato come se si fosse eseguito il comando \cmd{interpreter [argomenti]
filename}.\footnote{si tenga presente che con Linux quanto viene scritto
come \texttt{argomenti} viene passato all'interprete come un unico argomento
con una unica stringa di lunghezza massima di 127 caratteri e se questa
dimensione viene ecceduta la stringa viene troncata; altri Unix hanno
dimensioni massime diverse, e diversi comportamenti, ad esempio FreeBSD
- esegue la scansione della riga e la divide nei vari argomenti e se è troppo
+ esegue la scansione della riga e la divide nei vari argomenti e se è troppo
lunga restituisce un errore di \const{ENAMETOOLONG}, una comparazione dei
vari comportamenti si trova su
\href{http://www.in-ulm.de/~mascheck/various/shebang/}
{\textsf{http://www.in-ulm.de/\tild mascheck/various/shebang/}}.}
-Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
+Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo
processo, con \func{exec} si lancia un nuovo programma, con \func{exit} e
\func{wait} si effettua e verifica la conclusione dei processi. Tutte le
\label{sec:proc_access_id}
Come accennato in sez.~\ref{sec:intro_multiuser} il modello base\footnote{in
- realtà già esistono estensioni di questo modello base, che lo rendono più
+ realtà già esistono estensioni di questo modello base, che lo rendono più
flessibile e controllabile, come le \itindex{capabilities}
\textit{capabilities} illustrate in sez.~\ref{sec:proc_capabilities}, le ACL
per i file (vedi sez.~\ref{sec:file_ACL}) o il
\itindex{Mandatory~Access~Control~(MAC)} \textit{Mandatory Access Control}
di \index{SELinux} SELinux; inoltre basandosi sul lavoro effettuato con
- SELinux, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una
+ SELinux, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una
infrastruttura di sicurezza, i \itindex{Linux~Security~Modules}
\textit{Linux Security Modules}, o LSM, in grado di fornire diversi agganci
a livello del kernel per modularizzare tutti i possibili controlli di
- accesso.} di sicurezza di un sistema unix-like è fondato sui concetti di
+ accesso.} di sicurezza di un sistema unix-like è fondato sui concetti di
utente e gruppo, e sulla separazione fra l'amministratore (\textsl{root},
-detto spesso anche \textit{superuser}) che non è sottoposto a restrizioni, ed
+detto spesso anche \textit{superuser}) che non è sottoposto a restrizioni, ed
il resto degli utenti, per i quali invece vengono effettuati i vari controlli
di accesso.
-Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
+Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
identificatori univoci, lo user-ID ed il group-ID; questi servono al kernel per
identificare uno specifico utente o un gruppo di utenti, per poi poter
controllare che essi siano autorizzati a compiere le operazioni richieste. Ad
appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati dal
kernel nella gestione dei permessi di accesso.
-Dato che tutte le operazioni del sistema vengono compiute dai processi, è
+Dato che tutte le operazioni del sistema vengono compiute dai processi, è
evidente che per poter implementare un controllo sulle operazioni occorre
-anche poter identificare chi è che ha lanciato un certo programma, e pertanto
-anche a ciascun processo dovrà essere associato un utente e un gruppo.
+anche poter identificare chi è che ha lanciato un certo programma, e pertanto
+anche a ciascun processo dovrà essere associato un utente e un gruppo.
Un semplice controllo di una corrispondenza fra identificativi non garantisce
-però sufficiente flessibilità per tutti quei casi in cui è necessario poter
+però sufficiente flessibilità per tutti quei casi in cui è necessario poter
disporre di privilegi diversi, o dover impersonare un altro utente per un
limitato insieme di operazioni. Per questo motivo in generale tutti gli Unix
prevedono che i processi abbiano almeno due gruppi di identificatori, chiamati
-rispettivamente \textit{real} ed \textit{effective} (cioè \textsl{reali} ed
+rispettivamente \textit{real} ed \textit{effective} (cioè \textsl{reali} ed
\textsl{effettivi}). Nel caso di Linux si aggiungono poi altri due gruppi, il
\textit{saved} (\textsl{salvati}) ed il \textit{filesystem} (\textsl{di
filesystem}), secondo la situazione illustrata in
& Indicano gli ulteriori gruppi cui l'utente appartiene.\\
\hline
-- & \textit{saved} & \textsl{user-ID salvato}
- & È una copia dell'\acr{euid} iniziale.\\
+ & È una copia dell'\acr{euid} iniziale.\\
-- & '' & \textsl{group-ID salvato}
- & È una copia dell'\acr{egid} iniziale.\\
+ & È una copia dell'\acr{egid} iniziale.\\
\hline
\acr{fsuid} & \textit{filesystem} &\textsl{user-ID di filesystem}
& Indica l'utente effettivo per l'accesso al filesystem. \\
reale}: questi vengono impostati al login ai valori corrispondenti
all'utente con cui si accede al sistema (e relativo gruppo principale).
Servono per l'identificazione dell'utente e normalmente non vengono mai
-cambiati. In realtà vedremo (in sez.~\ref{sec:proc_setuid}) che è possibile
+cambiati. In realtà vedremo (in sez.~\ref{sec:proc_setuid}) che è possibile
modificarli, ma solo ad un processo che abbia i privilegi di amministratore;
-questa possibilità è usata proprio dal programma \cmd{login} che, una volta
+questa possibilità è usata proprio dal programma \cmd{login} che, una volta
completata la procedura di autenticazione, lancia una shell per la quale
imposta questi identificatori ai valori corrispondenti all'utente che entra
nel sistema.
Questi identificatori normalmente sono identici ai corrispondenti del gruppo
\textit{real} tranne nel caso in cui, come accennato in
-sez.~\ref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i
+sez.~\ref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i
bit \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid} impostati
-(il significato di questi bit è affrontato in dettaglio in
+(il significato di questi bit è affrontato in dettaglio in
sez.~\ref{sec:file_special_perm}). In questo caso essi saranno impostati
all'utente e al gruppo proprietari del file. Questo consente, per programmi in
-cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
+cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
di un altro (o dell'amministratore).
Come nel caso del \acr{pid} e del \acr{ppid}, anche tutti questi
\bodydesc{Queste funzioni non riportano condizioni di errore.}
\end{functions}
-In generale l'uso di privilegi superiori deve essere limitato il più
+In generale l'uso di privilegi superiori deve essere limitato il più
possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
un meccanismo che consenta ad un programma di rilasciare gli eventuali
maggiori privilegi necessari, una volta che si siano effettuate le operazioni
servano di nuovo.
Questo in Linux viene fatto usando altri due gruppi di identificatori, il
-\textit{saved} ed il \textit{filesystem}. Il primo gruppo è lo stesso usato in
-SVr4, e previsto dallo standard POSIX quando è definita la costante
-\macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la portabilità
- del programma su altri Unix è buona norma controllare sempre la
- disponibilità di queste funzioni controllando se questa costante è
- definita.} il secondo gruppo è specifico di Linux e viene usato per
+\textit{saved} ed il \textit{filesystem}. Il primo gruppo è lo stesso usato in
+SVr4, e previsto dallo standard POSIX quando è definita la costante
+\macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la portabilità
+ del programma su altri Unix è buona norma controllare sempre la
+ disponibilità di queste funzioni controllando se questa costante è
+ definita.} il secondo gruppo è specifico di Linux e viene usato per
migliorare la sicurezza con NFS.
L'\textsl{user-ID salvato} ed il \textsl{group-ID salvato} sono copie
all'inizio dell'esecuzione di un nuovo programma.
L'\textsl{user-ID di filesystem} e il \textsl{group-ID di filesystem} sono
-un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
+un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
(torneremo sull'argomento in sez.~\ref{sec:proc_setuid}). Essi sono una
replica dei corrispondenti identificatori del gruppo \textit{effective}, ai
quali si sostituiscono per tutte le operazioni di verifica dei permessi
relativi ai file (trattate in sez.~\ref{sec:file_perm_overview}). Ogni
cambiamento effettuato sugli identificatori effettivi viene automaticamente
-riportato su di essi, per cui in condizioni normali si può tranquillamente
+riportato su di essi, per cui in condizioni normali si può tranquillamente
ignorarne l'esistenza, in quanto saranno del tutto equivalenti ai precedenti.
\subsection{Le funzioni di gestione degli identificatori dei processi}
\label{sec:proc_setuid}
-Le due funzioni più comuni che vengono usate per cambiare identità (cioè
+Le due funzioni più comuni che vengono usate per cambiare identità (cioè
utente e gruppo di appartenenza) ad un processo sono rispettivamente
\funcd{setuid} e \funcd{setgid}; come accennato in
sez.~\ref{sec:proc_access_id} in Linux esse seguono la semantica POSIX che
corrente.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
- di fallimento: l'unico errore possibile è \errval{EPERM}.}
+ di fallimento: l'unico errore possibile è \errval{EPERM}.}
\end{functions}
-Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
+Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
la prima; la seconda si comporta esattamente allo stesso modo facendo
riferimento al \textsl{group-ID} invece che all'\textsl{user-ID}. Gli
eventuali \textsl{group-ID supplementari} non vengono modificati.
-L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
-l'\textsl{user-ID effettivo} è zero (cioè è quello dell'amministratore di
+L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
+l'\textsl{user-ID effettivo} è zero (cioè è quello dell'amministratore di
sistema) allora tutti gli identificatori (\textit{real}, \textit{effective} e
\textit{saved}) vengono impostati al valore specificato da \param{uid},
altrimenti viene impostato solo l'\textsl{user-ID effettivo}, e soltanto se il
all'\textsl{user-ID salvato}. Negli altri casi viene segnalato un errore (con
\errcode{EPERM}).
-Come accennato l'uso principale di queste funzioni è quello di poter
+Come accennato l'uso principale di queste funzioni è quello di poter
consentire ad un programma con i bit \itindex{suid~bit} \acr{suid} o
\itindex{sgid~bit} \acr{sgid} impostati (vedi sez.~\ref{sec:file_special_perm})
di riportare l'\textsl{user-ID effettivo} a quello dell'utente che ha lanciato
Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
viene gestito l'accesso al file \sysfile{/var/log/utmp}. In questo file viene
-registrato chi sta usando il sistema al momento corrente; chiaramente non può
+registrato chi sta usando il sistema al momento corrente; chiaramente non può
essere lasciato aperto in scrittura a qualunque utente, che potrebbe
falsificare la registrazione. Per questo motivo questo file (e l'analogo
\sysfile{/var/log/wtmp} su cui vengono registrati login e logout) appartengono
il bit \acr{sgid} impostato.
Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
-situazione degli identificatori è la seguente:
+situazione degli identificatori è la seguente:
\begin{eqnarray*}
\label{eq:1}
\textsl{group-ID reale} &=& \textrm{\acr{gid} (del chiamante)} \\
\textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
\textsl{group-ID salvato} &=& \textrm{\acr{utmp}}
\end{eqnarray*}
-in questo modo, dato che il \textsl{group-ID effettivo} è quello giusto, il
-programma può accedere a \sysfile{/var/log/utmp} in scrittura ed aggiornarlo.
-A questo punto il programma può eseguire una \code{setgid(getgid())} per
+in questo modo, dato che il \textsl{group-ID effettivo} è quello giusto, il
+programma può accedere a \sysfile{/var/log/utmp} in scrittura ed aggiornarlo.
+A questo punto il programma può eseguire una \code{setgid(getgid())} per
impostare il \textsl{group-ID effettivo} a quello dell'utente (e dato che il
-\textsl{group-ID reale} corrisponde la funzione avrà successo), in questo modo
-non sarà possibile lanciare dal terminale programmi che modificano detto file,
+\textsl{group-ID reale} corrisponde la funzione avrà successo), in questo modo
+non sarà possibile lanciare dal terminale programmi che modificano detto file,
in tal caso infatti la situazione degli identificatori sarebbe:
\begin{eqnarray*}
\label{eq:2}
\end{eqnarray*}
e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
\textsl{group-ID effettivo}. All'uscita dal terminale, per poter di nuovo
-aggiornare lo stato di \sysfile{/var/log/utmp} il programma eseguirà una
-\code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
+aggiornare lo stato di \sysfile{/var/log/utmp} il programma eseguirà una
+\code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
\acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
in questo caso il valore richiesto corrisponde al \textsl{group-ID salvato} la
-funzione avrà successo e riporterà la situazione a:
+funzione avrà successo e riporterà la situazione a:
\begin{eqnarray*}
\label{eq:3}
\textsl{group-ID reale} &=& \textrm{\acr{gid} (invariato)} \\
\end{eqnarray*}
consentendo l'accesso a \sysfile{/var/log/utmp}.
-Occorre però tenere conto che tutto questo non è possibile con un processo con
+Occorre però tenere conto che tutto questo non è possibile con un processo con
i privilegi di amministratore, in tal caso infatti l'esecuzione di una
\func{setuid} comporta il cambiamento di tutti gli identificatori associati al
processo, rendendo impossibile riguadagnare i privilegi di amministratore.
-Questo comportamento è corretto per l'uso che ne fa \cmd{login} una volta che
+Questo comportamento è corretto per l'uso che ne fa \cmd{login} una volta che
crea una nuova shell per l'utente; ma quando si vuole cambiare soltanto
l'\textsl{user-ID effettivo} del processo per cedere i privilegi occorre
ricorrere ad altre funzioni.
specificati da \param{rgid} e \param{egid}.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
- di fallimento: l'unico errore possibile è \errval{EPERM}.}
+ di fallimento: l'unico errore possibile è \errval{EPERM}.}
\end{functions}
-La due funzioni sono analoghe ed il loro comportamento è identico; quanto
+La due funzioni sono analoghe ed il loro comportamento è identico; quanto
detto per la prima riguardo l'user-ID, si applica immediatamente alla seconda
per il group-ID. I processi non privilegiati possono impostare solo i valori
del loro user-ID effettivo o reale; valori diversi comportano il fallimento
-della chiamata; l'amministratore invece può specificare un valore qualunque.
-Specificando un argomento di valore -1 l'identificatore corrispondente verrà
+della chiamata; l'amministratore invece può specificare un valore qualunque.
+Specificando un argomento di valore -1 l'identificatore corrispondente verrà
lasciato inalterato.
Con queste funzioni si possono scambiare fra loro gli user-ID reale e
-effettivo, e pertanto è possibile implementare un comportamento simile a
+effettivo, e pertanto è possibile implementare un comportamento simile a
quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo
scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un secondo
scambio.
-In questo caso però occorre porre molta attenzione quando si creano nuovi
+In questo caso però occorre porre molta attenzione quando si creano nuovi
processi nella fase intermedia in cui si sono scambiati gli identificatori, in
-questo caso infatti essi avranno un user-ID reale privilegiato, che dovrà
+questo caso infatti essi avranno un user-ID reale privilegiato, che dovrà
essere esplicitamente eliminato prima di porre in esecuzione un nuovo
-programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e
+programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e
prima della \func{exec} per uniformare l'user-ID reale a quello effettivo) in
caso contrario il nuovo programma potrebbe a sua volta effettuare uno scambio
e riottenere privilegi non previsti.
Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
si pone per l'user-ID salvato: questa funzione deriva da un'implementazione che
-non ne prevede la presenza, e quindi non è possibile usarla per correggere la
+non ne prevede la presenza, e quindi non è possibile usarla per correggere la
situazione come nel caso precedente. Per questo motivo in Linux tutte le volte
che si imposta un qualunque valore diverso da quello dall'user-ID reale
corrente, l'user-ID salvato viene automaticamente uniformato al valore
corrente a \param{gid}.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
- di fallimento: l'unico errore è \errval{EPERM}.}
+ di fallimento: l'unico errore è \errval{EPERM}.}
\end{functions}
Come per le precedenti le due funzioni sono identiche, per cui tratteremo solo
la prima. Gli utenti normali possono impostare l'user-ID effettivo solo al
-valore dell'user-ID reale o dell'user-ID salvato, l'amministratore può
+valore dell'user-ID reale o dell'user-ID salvato, l'amministratore può
specificare qualunque valore. Queste funzioni sono usate per permettere
all'amministratore di impostare solo l'user-ID effettivo, dato che l'uso
normale di \func{setuid} comporta l'impostazione di tutti gli identificatori.
\param{sgid}.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
- di fallimento: l'unico errore è \errval{EPERM}.}
+ di fallimento: l'unico errore è \errval{EPERM}.}
\end{functions}
Le due funzioni sono identiche, quanto detto per la prima riguardo gli user-ID
si applica alla seconda per i group-ID. I processi non privilegiati possono
cambiare uno qualunque degli user-ID solo ad un valore corrispondente o
all'user-ID reale, o a quello effettivo o a quello salvato, l'amministratore
-può specificare i valori che vuole; un valore di -1 per un qualunque argomento
+può specificare i valori che vuole; un valore di -1 per un qualunque argomento
lascia inalterato l'identificatore corrispondente.
Per queste funzioni esistono anche due controparti che permettono di leggere
corrente.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
- fallimento: l'unico errore possibile è \errval{EFAULT} se gli indirizzi delle
+ fallimento: l'unico errore possibile è \errval{EFAULT} se gli indirizzi delle
variabili di ritorno non sono validi.}
\end{functions}
Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
nessun privilegio. I valori sono restituiti negli argomenti, che vanno
-specificati come puntatori (è un altro esempio di
+specificati come puntatori (è un altro esempio di
\itindex{value~result~argument} \textit{value result argument}). Si noti che
queste funzioni sono le uniche in grado di leggere gli identificatori del
gruppo \textit{saved}.
Infine le funzioni \func{setfsuid} e \func{setfsgid} servono per impostare gli
identificatori del gruppo \textit{filesystem} che sono usati da Linux per il
-controllo dell'accesso ai file. Come già accennato in
+controllo dell'accesso ai file. Come già accennato in
sez.~\ref{sec:proc_access_id} Linux definisce questo ulteriore gruppo di
identificatori, che in circostanze normali sono assolutamente equivalenti a
quelli del gruppo \textit{effective}, dato che ogni cambiamento di questi
ultimi viene immediatamente riportato su di essi.
-C'è un solo caso in cui si ha necessità di introdurre una differenza fra gli
-identificatori dei gruppi \textit{effective} e \textit{filesystem}, ed è per
+C'è un solo caso in cui si ha necessità di introdurre una differenza fra gli
+identificatori dei gruppi \textit{effective} e \textit{filesystem}, ed è per
ovviare ad un problema di sicurezza che si presenta quando si deve
implementare un server NFS.
Il server NFS infatti deve poter cambiare l'identificatore con cui accede ai
-file per assumere l'identità del singolo utente remoto, ma se questo viene
+file per assumere l'identità del singolo utente remoto, ma se questo viene
fatto cambiando l'user-ID effettivo o l'user-ID reale il server si espone alla
ricezione di eventuali segnali ostili da parte dell'utente di cui ha
-temporaneamente assunto l'identità. Cambiando solo l'user-ID di filesystem si
+temporaneamente assunto l'identità. Cambiando solo l'user-ID di filesystem si
ottengono i privilegi necessari per accedere ai file, mantenendo quelli
-originari per quanto riguarda tutti gli altri controlli di accesso, così che
+originari per quanto riguarda tutti gli altri controlli di accesso, così che
l'utente non possa inviare segnali al server NFS.
Le due funzioni usate per cambiare questi identificatori sono \funcd{setfsuid}
processo corrente a \param{fsgid}.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
- di fallimento: l'unico errore possibile è \errval{EPERM}.}
+ di fallimento: l'unico errore possibile è \errval{EPERM}.}
\end{functions}
\noindent queste funzioni hanno successo solo se il processo chiamante ha i
privilegi di amministratore o, per gli altri utenti, se il valore specificato
\label{sec:proc_setgroups}
Le ultime funzioni che esamineremo sono quelle che permettono di operare sui
-gruppi supplementari cui un utente può appartenere. Ogni processo può avere
+gruppi supplementari cui un utente può appartenere. Ogni processo può avere
almeno \const{NGROUPS\_MAX} gruppi supplementari\footnote{il numero massimo di
- gruppi secondari può essere ottenuto con \func{sysconf} (vedi
+ gruppi secondari può essere ottenuto con \func{sysconf} (vedi
sez.~\ref{sec:sys_sysconf}), leggendo il parametro
\texttt{\_SC\_NGROUPS\_MAX}.} in aggiunta al gruppo primario; questi vengono
ereditati dal processo padre e possono essere cambiati con queste funzioni.
La funzione che permette di leggere i gruppi supplementari associati ad un
-processo è \funcd{getgroups}; questa funzione è definita nello standard
-POSIX.1, ed il suo prototipo è:
+processo è \funcd{getgroups}; questa funzione è definita nello standard
+POSIX.1, ed il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{unistd.h}
Legge gli identificatori dei gruppi supplementari.
\bodydesc{La funzione restituisce il numero di gruppi letti in caso di
- successo e -1 in caso di fallimento, nel qual caso \var{errno} assumerà
+ successo e -1 in caso di fallimento, nel qual caso \var{errno} assumerà
i valori:
\begin{errlist}
\item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
- \item[\errcode{EINVAL}] il valore di \param{size} è diverso da zero ma
+ \item[\errcode{EINVAL}] il valore di \param{size} è diverso da zero ma
minore del numero di gruppi supplementari del processo.
\end{errlist}}
\end{functions}
La funzione legge gli identificatori dei gruppi supplementari del processo sul
-vettore \param{list} di dimensione \param{size}. Non è specificato se la
+vettore \param{list} di dimensione \param{size}. Non è specificato se la
funzione inserisca o meno nella lista il group-ID effettivo del processo. Se si
specifica un valore di \param{size} uguale a 0 \param{list} non viene
modificato, ma si ottiene il numero di gruppi supplementari.
-Una seconda funzione, \funcd{getgrouplist}, può invece essere usata per
-ottenere tutti i gruppi a cui appartiene un certo utente; il suo prototipo è:
+Una seconda funzione, \funcd{getgrouplist}, può invece essere usata per
+ottenere tutti i gruppi a cui appartiene un certo utente; il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{grp.h}
La funzione legge i gruppi supplementari dell'utente specificato da
\param{user}, eseguendo una scansione del database dei gruppi (si veda
sez.~\ref{sec:sys_user_group}). Ritorna poi in \param{groups} la lista di
-quelli a cui l'utente appartiene. Si noti che \param{ngroups} è passato come
-puntatore perché, qualora il valore specificato sia troppo piccolo, la
+quelli a cui l'utente appartiene. Si noti che \param{ngroups} è passato come
+puntatore perché, qualora il valore specificato sia troppo piccolo, la
funzione ritorna -1, passando indietro il numero dei gruppi trovati.
Per impostare i gruppi supplementari di un processo ci sono due funzioni, che
possono essere usate solo se si hanno i privilegi di amministratore. La prima
-delle due è \funcd{setgroups}, ed il suo prototipo è:
+delle due è \funcd{setgroups}, ed il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{grp.h}
Imposta i gruppi supplementari del processo.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- fallimento, nel qual caso \var{errno} assumerà i valori:
+ fallimento, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
- \item[\errcode{EINVAL}] il valore di \param{size} è maggiore del valore
+ \item[\errcode{EINVAL}] il valore di \param{size} è maggiore del valore
massimo consentito.
\end{errlist}}
\end{functions}
La funzione imposta i gruppi supplementari del processo corrente ai valori
specificati nel vettore passato con l'argomento \param{list}, di dimensioni
-date dall'argomento \param{size}. Il numero massimo di gruppi supplementari è
-un parametro di sistema, che può essere ricavato con le modalità spiegate in
+date dall'argomento \param{size}. Il numero massimo di gruppi supplementari è
+un parametro di sistema, che può essere ricavato con le modalità spiegate in
sez.~\ref{sec:sys_characteristics}.
Se invece si vogliono impostare i gruppi supplementari del processo a quelli di
-un utente specifico, si può usare \funcd{initgroups} il cui prototipo è:
+un utente specifico, si può usare \funcd{initgroups} il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{grp.h}
Inizializza la lista dei gruppi supplementari.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- fallimento, nel qual caso \var{errno} assumerà gli stessi valori di
- \func{setgroups} più \errval{ENOMEM} quando non c'è memoria sufficiente
+ fallimento, nel qual caso \var{errno} assumerà gli stessi valori di
+ \func{setgroups} più \errval{ENOMEM} quando non c'è memoria sufficiente
per allocare lo spazio per informazioni dei gruppi.}
\end{functions}
La funzione esegue la scansione del database dei gruppi (usualmente
-\conffile{/etc/group}) cercando i gruppi di cui è membro l'utente \param{user}
+\conffile{/etc/group}) cercando i gruppi di cui è membro l'utente \param{user}
con cui costruisce una lista di gruppi supplementari, a cui aggiunge anche
\param{group}, infine imposta questa lista per il processo corrente usando
\func{setgroups}. Si tenga presente che sia \func{setgroups} che
\func{initgroups} non sono definite nello standard POSIX.1 e che pertanto non
-è possibile utilizzarle quando si definisce \macro{\_POSIX\_SOURCE} o si
-compila con il flag \cmd{-ansi}, è pertanto meglio evitarle se si vuole
+è possibile utilizzarle quando si definisce \macro{\_POSIX\_SOURCE} o si
+compila con il flag \cmd{-ansi}, è pertanto meglio evitarle se si vuole
scrivere codice portabile.
-\section{La gestione della priorità dei processi}
+\section{La gestione della priorità dei processi}
\label{sec:proc_priority}
-In questa sezione tratteremo più approfonditamente i meccanismi con il quale
+In questa sezione tratteremo più approfonditamente i meccanismi con il quale
lo \itindex{scheduler} \textit{scheduler} assegna la CPU ai vari processi
attivi. In particolare prenderemo in esame i vari meccanismi con cui viene
gestita l'assegnazione del tempo di CPU, ed illustreremo le varie funzioni di
-gestione. Tratteremo infine anche le altre priorità dei processi (come quelle
-per l'accesso a disco) divenute disponibili con i kernel più recenti.
+gestione. Tratteremo infine anche le altre priorità dei processi (come quelle
+per l'accesso a disco) divenute disponibili con i kernel più recenti.
\subsection{I meccanismi di \textit{scheduling}}
\itindbeg{scheduler}
La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
-il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
+il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
ed oggetto di numerose ricerche; in generale essa dipende in maniera
essenziale anche dal tipo di utilizzo che deve essere fatto del sistema, per
cui non esiste un meccanismo che sia valido per tutti gli usi.
-La caratteristica specifica di un sistema multitasking come Linux è quella del
+La caratteristica specifica di un sistema multitasking come Linux è quella del
cosiddetto \itindex{preemptive~multitasking} \textit{preemptive
multitasking}: questo significa che al contrario di altri sistemi (che usano
invece il cosiddetto \itindex{cooperative~multitasking} \textit{cooperative
multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
quando la CPU deve essere passata ad un altro processo. Come accennato in
sez.~\ref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione
-apposita del kernel, lo \textit{scheduler}, il cui scopo è quello di
+apposita del kernel, lo \textit{scheduler}, il cui scopo è quello di
distribuire al meglio il tempo di CPU fra i vari processi.
-La cosa è resa ancora più complicata dal fatto che con le architetture
-multi-processore si deve anche scegliere quale sia la CPU più opportuna da
-utilizzare.\footnote{nei processori moderni la presenza di ampie cache può
+La cosa è resa ancora più complicata dal fatto che con le architetture
+multi-processore si deve anche scegliere quale sia la CPU più opportuna da
+utilizzare.\footnote{nei processori moderni la presenza di ampie cache può
rendere poco efficiente trasferire l'esecuzione di un processo da una CPU ad
- un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
+ un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
banale.} Tutto questo comunque appartiene alle sottigliezze
dell'implementazione del kernel; dal punto di vista dei programmi che girano
-in user space, anche quando si hanno più processori (e dei processi che sono
+in user space, anche quando si hanno più processori (e dei processi che sono
eseguiti davvero in contemporanea), le politiche di scheduling riguardano
semplicemente l'allocazione della risorsa \textsl{tempo di esecuzione}, la cui
-assegnazione sarà governata dai meccanismi di scelta delle priorità che
+assegnazione sarà governata dai meccanismi di scelta delle priorità che
restano gli stessi indipendentemente dal numero di processori.
Si tenga conto poi che i processi non devono solo eseguire del codice: ad
esempio molto spesso saranno impegnati in operazioni di I/O, o potranno
venire bloccati da un comando dal terminale, o sospesi per un certo periodo di
-tempo. In tutti questi casi la CPU diventa disponibile ed è compito dello
+tempo. In tutti questi casi la CPU diventa disponibile ed è compito dello
kernel provvedere a mettere in esecuzione un altro processo.
-Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
-processo, in Linux un processo può trovarsi in uno degli stati riportati in
+Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
+processo, in Linux un processo può trovarsi in uno degli stati riportati in
tab.~\ref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
\textbf{Runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
-sia la sua priorità, un processo non potrà mai essere messo in esecuzione
+sia la sua priorità, un processo non potrà mai essere messo in esecuzione
fintanto che esso si trova in uno qualunque degli altri stati.
\begin{table}[htb]
\textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
\hline
\hline
- \textbf{Runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
- essere eseguito (cioè è in attesa che gli
+ \textbf{Runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
+ essere eseguito (cioè è in attesa che gli
venga assegnata la CPU).\\
- \textbf{Sleep} & \texttt{S} & Il processo è in attesa di un
- risposta dal sistema, ma può essere
+ \textbf{Sleep} & \texttt{S} & Il processo è in attesa di un
+ risposta dal sistema, ma può essere
interrotto da un segnale.\\
- \textbf{Uninterrutible Sleep}& \texttt{D} & Il processo è in
+ \textbf{Uninterrutible Sleep}& \texttt{D} & Il processo è in
attesa di un risposta dal sistema (in
- genere per I/O), e non può essere
+ genere per I/O), e non può essere
interrotto in nessuna circostanza.\\
- \textbf{Stopped} & \texttt{T} & Il processo è stato fermato con un
- \const{SIGSTOP}, o è tracciato.\\
- \textbf{Zombie}\index{zombie} & \texttt{Z} & Il processo è terminato ma il
- suo stato di terminazione non è ancora
+ \textbf{Stopped} & \texttt{T} & Il processo è stato fermato con un
+ \const{SIGSTOP}, o è tracciato.\\
+ \textbf{Zombie}\index{zombie} & \texttt{Z} & Il processo è terminato ma il
+ suo stato di terminazione non è ancora
stato letto dal padre.\\
\textbf{Killable}& \texttt{D} & Un nuovo stato introdotto con il kernel
2.6.25, sostanzialmente identico
all'\textbf{Uninterrutible Sleep} con la
- sola differenza che il processo può
+ sola differenza che il processo può
terminato con \const{SIGKILL} (usato per
- lo più per NFS).\\
+ lo più per NFS).\\
\hline
\end{tabular}
\caption{Elenco dei possibili stati di un processo in Linux, nella colonna
- \texttt{STAT} si è riportata la corrispondente lettera usata dal comando
+ \texttt{STAT} si è riportata la corrispondente lettera usata dal comando
\cmd{ps} nell'omonimo campo.}
\label{tab:proc_proc_states}
\end{table}
-Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
+Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
risorse che sono necessarie per l'esecuzione di un programma, e a seconda
-dello scopo del programma non è detto neanche che sia la più importante (molti
-programmi dipendono in maniera molto più critica dall'I/O). Per questo motivo
-non è affatto detto che dare ad un programma la massima priorità di esecuzione
+dello scopo del programma non è detto neanche che sia la più importante (molti
+programmi dipendono in maniera molto più critica dall'I/O). Per questo motivo
+non è affatto detto che dare ad un programma la massima priorità di esecuzione
abbia risultati significativi in termini di prestazioni.
Il meccanismo tradizionale di scheduling di Unix (che tratteremo in
-sez.~\ref{sec:proc_sched_stand}) è sempre stato basato su delle
-\textsl{priorità dinamiche}, in modo da assicurare che tutti i processi, anche
+sez.~\ref{sec:proc_sched_stand}) è sempre stato basato su delle
+\textsl{priorità dinamiche}, in modo da assicurare che tutti i processi, anche
i meno importanti, possano ricevere un po' di tempo di CPU. In sostanza quando
-un processo ottiene la CPU la sua priorità viene diminuita. In questo modo
-alla fine, anche un processo con priorità iniziale molto bassa, finisce per
-avere una priorità sufficiente per essere eseguito.
+un processo ottiene la CPU la sua priorità viene diminuita. In questo modo
+alla fine, anche un processo con priorità iniziale molto bassa, finisce per
+avere una priorità sufficiente per essere eseguito.
-Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
- assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
-alla normale priorità dinamica), per tenere conto dei sistemi
+Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
+ assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
+alla normale priorità dinamica), per tenere conto dei sistemi
real-time,\footnote{per sistema real-time si intende un sistema in grado di
eseguire operazioni in un tempo ben determinato; in genere si tende a
- distinguere fra l'\textit{hard real-time} in cui è necessario che i tempi di
+ distinguere fra l'\textit{hard real-time} in cui è necessario che i tempi di
esecuzione di un programma siano determinabili con certezza assoluta (come
nel caso di meccanismi di controllo di macchine, dove uno sforamento dei
tempi avrebbe conseguenze disastrose), e \textit{soft-real-time} in cui un
- occasionale sforamento è ritenuto accettabile.} in cui è vitale che i
+ occasionale sforamento è ritenuto accettabile.} in cui è vitale che i
processi che devono essere eseguiti in un determinato momento non debbano
-aspettare la conclusione di altri che non hanno questa necessità.
+aspettare la conclusione di altri che non hanno questa necessità.
-Il concetto di priorità assoluta dice che quando due processi si contendono
-l'esecuzione, vince sempre quello con la priorità assoluta più alta.
+Il concetto di priorità assoluta dice che quando due processi si contendono
+l'esecuzione, vince sempre quello con la priorità assoluta più alta.
Ovviamente questo avviene solo per i processi che sono pronti per essere
-eseguiti (cioè nello stato \textit{runnable}). La priorità assoluta viene in
-genere indicata con un numero intero, ed un valore più alto comporta una
-priorità maggiore. Su questa politica di scheduling torneremo in
+eseguiti (cioè nello stato \textit{runnable}). La priorità assoluta viene in
+genere indicata con un numero intero, ed un valore più alto comporta una
+priorità maggiore. Su questa politica di scheduling torneremo in
sez.~\ref{sec:proc_real_time}.
-In generale quello che succede in tutti gli Unix moderni è che ai processi
-normali viene sempre data una priorità assoluta pari a zero, e la decisione di
-assegnazione della CPU è fatta solo con il meccanismo tradizionale della
-priorità dinamica. In Linux tuttavia è possibile assegnare anche una priorità
-assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di
-priorità inferiore, che saranno eseguiti solo quando quest'ultimo non avrà
+In generale quello che succede in tutti gli Unix moderni è che ai processi
+normali viene sempre data una priorità assoluta pari a zero, e la decisione di
+assegnazione della CPU è fatta solo con il meccanismo tradizionale della
+priorità dinamica. In Linux tuttavia è possibile assegnare anche una priorità
+assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di
+priorità inferiore, che saranno eseguiti solo quando quest'ultimo non avrà
bisogno della CPU.
A meno che non si abbiano esigenze specifiche,\footnote{per alcune delle quali
sono state introdotte delle varianti specifiche.} l'unico meccanismo di
-scheduling con il quale si avrà a che fare è quello tradizionale, che prevede
-solo priorità dinamiche. È di questo che, di norma, ci si dovrà preoccupare
+scheduling con il quale si avrà a che fare è quello tradizionale, che prevede
+solo priorità dinamiche. È di questo che, di norma, ci si dovrà preoccupare
nella programmazione. Come accennato in Linux i processi ordinari hanno tutti
-una priorità assoluta nulla; quello che determina quale, fra tutti i processi
-in attesa di esecuzione, sarà eseguito per primo, è la cosiddetta
-\textsl{priorità dinamica},\footnote{quella che viene mostrata nella colonna
- \texttt{PR} del comando \texttt{top}.} che è chiamata così proprio perché
+una priorità assoluta nulla; quello che determina quale, fra tutti i processi
+in attesa di esecuzione, sarà eseguito per primo, è la cosiddetta
+\textsl{priorità dinamica},\footnote{quella che viene mostrata nella colonna
+ \texttt{PR} del comando \texttt{top}.} che è chiamata così proprio perché
varia nel corso dell'esecuzione di un processo.
-Il meccanismo usato da Linux è in realtà piuttosto complesso,\footnote{e
+Il meccanismo usato da Linux è in realtà piuttosto complesso,\footnote{e
dipende strettamente dalla versione di kernel; in particolare a partire
- dalla serie 2.6.x lo scheduler è stato riscritto completamente, con molte
+ dalla serie 2.6.x lo scheduler è stato riscritto completamente, con molte
modifiche susseguitesi per migliorarne le prestazioni, per un certo periodo
- ed è stata anche introdotta la possibilità di usare diversi algoritmi,
- selezionabili sia in fase di compilazione, che, nelle versioni più recenti,
- all'avvio (addirittura è stato ideato un sistema modulare che permette di
- cambiare lo scheduler a sistema attivo).} ma a grandi linee si può dire che
-ad ogni processo è assegnata una \textit{time-slice}, cioè un intervallo di
+ ed è stata anche introdotta la possibilità di usare diversi algoritmi,
+ selezionabili sia in fase di compilazione, che, nelle versioni più recenti,
+ all'avvio (addirittura è stato ideato un sistema modulare che permette di
+ cambiare lo scheduler a sistema attivo).} ma a grandi linee si può dire che
+ad ogni processo è assegnata una \textit{time-slice}, cioè un intervallo di
tempo (letteralmente una fetta) per il quale, a meno di eventi esterni, esso
-viene eseguito senza essere interrotto. Inoltre la priorità dinamica viene
+viene eseguito senza essere interrotto. Inoltre la priorità dinamica viene
calcolata dallo scheduler a partire da un valore iniziale che viene
-\textsl{diminuito} tutte le volte che un processo è in stato \textbf{Runnable}
-ma non viene posto in esecuzione.\footnote{in realtà il calcolo della priorità
+\textsl{diminuito} tutte le volte che un processo è in stato \textbf{Runnable}
+ma non viene posto in esecuzione.\footnote{in realtà il calcolo della priorità
dinamica e la conseguente scelta di quale processo mettere in esecuzione
- avviene con un algoritmo molto più complicato, che tiene conto anche della
- \textsl{interattività} del processo, utilizzando diversi fattori, questa è
+ avviene con un algoritmo molto più complicato, che tiene conto anche della
+ \textsl{interattività} del processo, utilizzando diversi fattori, questa è
una brutale semplificazione per rendere l'idea del funzionamento, per una
- trattazione più dettagliata, anche se non aggiornatissima, dei meccanismi di
+ trattazione più dettagliata, anche se non aggiornatissima, dei meccanismi di
funzionamento dello scheduler si legga il quarto capitolo di
\cite{LinKernDev}.} Lo scheduler infatti mette sempre in esecuzione, fra
tutti i processi in stato \textbf{Runnable}, quello che ha il valore di
-priorità dinamica più basso.\footnote{con le priorità dinamiche il significato
- del valore numerico ad esse associato è infatti invertito, un valore più
- basso significa una priorità maggiore.} Il fatto che questo valore venga
+priorità dinamica più basso.\footnote{con le priorità dinamiche il significato
+ del valore numerico ad esse associato è infatti invertito, un valore più
+ basso significa una priorità maggiore.} Il fatto che questo valore venga
diminuito quando un processo non viene posto in esecuzione pur essendo pronto,
-significa che la priorità dei processi che non ottengono l'uso del processore
-viene progressivamente incrementata, così che anche questi alla fine hanno la
-possibilità di essere eseguiti.
+significa che la priorità dei processi che non ottengono l'uso del processore
+viene progressivamente incrementata, così che anche questi alla fine hanno la
+possibilità di essere eseguiti.
Sia la dimensione della \textit{time-slice} che il valore di partenza della
-priorità dinamica sono determinate dalla cosiddetta \textit{nice} (o
-\textit{niceness}) del processo.\footnote{questa è una delle tante proprietà
+priorità dinamica sono determinate dalla cosiddetta \textit{nice} (o
+\textit{niceness}) del processo.\footnote{questa è una delle tante proprietà
che ciascun processo si porta dietro, essa viene ereditata dai processi
figli e mantenuta attraverso una \func{exec}; fino alla serie 2.4 essa era
mantenuta nell'omonimo campo \texttt{nice} della \texttt{task\_struct}, con
la riscrittura dello scheduler eseguita nel 2.6 viene mantenuta nel campo
- \texttt{static\_prio} come per le priorità statiche.} L'origine del nome di
+ \texttt{static\_prio} come per le priorità statiche.} L'origine del nome di
questo parametro sta nel fatto che generalmente questo viene usato per
-\textsl{diminuire} la priorità di un processo, come misura di cortesia nei
+\textsl{diminuire} la priorità di un processo, come misura di cortesia nei
confronti degli altri. I processi infatti vengono creati dal sistema con un
-valore di \var{nice} nullo e nessuno è privilegiato rispetto agli altri;
-specificando un valore positivo si avrà una \textit{time-slice} più breve ed
-un valore di priorità dinamica iniziale più alto, mentre un valore negativo
-darà una \textit{time-slice} più lunga ed un valore di priorità dinamica
-iniziale più basso.
+valore di \var{nice} nullo e nessuno è privilegiato rispetto agli altri;
+specificando un valore positivo si avrà una \textit{time-slice} più breve ed
+un valore di priorità dinamica iniziale più alto, mentre un valore negativo
+darà una \textit{time-slice} più lunga ed un valore di priorità dinamica
+iniziale più basso.
Esistono diverse funzioni che consentono di modificare la \textit{niceness} di
-un processo; la più semplice è funzione \funcd{nice}, che opera sul processo
-corrente, il suo prototipo è:
+un processo; la più semplice è funzione \funcd{nice}, che opera sul processo
+corrente, il suo prototipo è:
\begin{prototype}{unistd.h}
{int nice(int inc)}
Aumenta il valore di \var{nice} per il processo corrente.
\bodydesc{La funzione ritorna zero o il nuovo valore di \var{nice} in caso
- di successo e -1 in caso di errore, nel qual caso \var{errno} può assumere
+ di successo e -1 in caso di errore, nel qual caso \var{errno} può assumere
i valori:
\begin{errlist}
\item[\errcode{EPERM}] non si ha il permesso di specificare un valore
\end{prototype}
L'argomento \param{inc} indica l'incremento da effettuare rispetto al valore
-di \var{nice} corrente: quest'ultimo può assumere valori compresi fra
+di \var{nice} corrente: quest'ultimo può assumere valori compresi fra
\const{PRIO\_MIN} e \const{PRIO\_MAX}; nel caso di Linux sono fra $-20$ e
-$19$,\footnote{in realtà l'intervallo varia a seconda delle versioni di
- kernel, ed è questo a partire dal kernel 1.3.43, anche se oggi si può avere
- anche l'intervallo fra $-20$ e $20$.} ma per \param{inc} si può specificare
-un valore qualunque, positivo o negativo, ed il sistema provvederà a troncare
+$19$,\footnote{in realtà l'intervallo varia a seconda delle versioni di
+ kernel, ed è questo a partire dal kernel 1.3.43, anche se oggi si può avere
+ anche l'intervallo fra $-20$ e $20$.} ma per \param{inc} si può specificare
+un valore qualunque, positivo o negativo, ed il sistema provvederà a troncare
il risultato nell'intervallo consentito. Valori positivi comportano maggiore
-\textit{cortesia} e cioè una diminuzione della priorità, valori negativi
-comportano invece un aumento della priorità. Con i kernel precedenti il
+\textit{cortesia} e cioè una diminuzione della priorità, valori negativi
+comportano invece un aumento della priorità. Con i kernel precedenti il
2.6.12 solo l'amministratore\footnote{o un processo con la
\itindex{capabilities} \textit{capability} \const{CAP\_SYS\_NICE}, vedi
- sez.~\ref{sec:proc_capabilities}.} può specificare valori negativi
-di \param{inc} che permettono di aumentare la priorità di un processo, a
-partire da questa versione è consentito anche agli utenti normali alzare
-(entro certi limiti, che vedremo più avanti) la priorità dei propri processi.
+ sez.~\ref{sec:proc_capabilities}.} può specificare valori negativi
+di \param{inc} che permettono di aumentare la priorità di un processo, a
+partire da questa versione è consentito anche agli utenti normali alzare
+(entro certi limiti, che vedremo più avanti) la priorità dei propri processi.
Gli standard SUSv2 e POSIX.1 prevedono che la funzione ritorni il nuovo valore
di \var{nice} del processo; tuttavia la system call di Linux non segue questa
convenzione e restituisce sempre 0 in caso di successo e $-1$ in caso di
-errore; questo perché $-1$ è un valore di \var{nice} legittimo e questo
+errore; questo perché $-1$ è un valore di \var{nice} legittimo e questo
comporta una confusione con una eventuale condizione di errore. La system call
originaria inoltre non consente, se non dotati di adeguati privilegi, di
diminuire un valore di \var{nice} precedentemente innalzato.
Fino alle \acr{glibc} 2.2.4 la funzione di libreria riportava direttamente il
risultato dalla system call, violando lo standard, per cui per ottenere il
nuovo valore occorreva una successiva chiamata alla funzione
-\func{getpriority}. A partire dalla \acr{glibc} 2.2.4 \func{nice} è stata
-reimplementata e non viene più chiamata la omonima system call, con questa
+\func{getpriority}. A partire dalla \acr{glibc} 2.2.4 \func{nice} è stata
+reimplementata e non viene più chiamata la omonima system call, con questa
versione viene restituito come valore di ritorno il valore di \var{nice}, come
richiesto dallo standard.\footnote{questo viene fatto chiamando al suo interno
\func{setpriority}, che tratteremo a breve.} In questo caso l'unico modo
-per rilevare in maniera affidabile una condizione di errore è quello di
+per rilevare in maniera affidabile una condizione di errore è quello di
azzerare \var{errno} prima della chiamata della funzione e verificarne il
valore quando \func{nice} restituisce $-1$.
Per leggere il valore di \textit{nice} di un processo occorre usare la
-funzione \funcd{getpriority}, derivata da BSD; il suo prototipo è:
+funzione \funcd{getpriority}, derivata da BSD; il suo prototipo è:
\begin{prototype}{sys/resource.h}
{int getpriority(int which, int who)}
Restituisce il valore di \var{nice} per l'insieme dei processi specificati.
- \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} può assumere i valori:
+ \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
+ errore, nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
- \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
+ \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
\param{which} e \param{who}.
- \item[\errcode{EINVAL}] il valore di \param{which} non è valido.
+ \item[\errcode{EINVAL}] il valore di \param{which} non è valido.
\end{errlist}}
\end{prototype}
-\noindent nelle vecchie versioni può essere necessario includere anche
-\file{<sys/time.h>}, questo non è più necessario con versioni recenti delle
-librerie, ma è comunque utile per portabilità.
+\noindent nelle vecchie versioni può essere necessario includere anche
+\file{<sys/time.h>}, questo non è più necessario con versioni recenti delle
+librerie, ma è comunque utile per portabilità.
La funzione permette, a seconda del valore di \param{which}, di leggere la
-priorità di un processo, di un gruppo di processi (vedi
+priorità di un processo, di un gruppo di processi (vedi
sez.~\ref{sec:sess_proc_group}) o di un utente, specificando un corrispondente
valore per \param{who} secondo la legenda di tab.~\ref{tab:proc_getpriority};
un valore nullo di quest'ultimo indica il processo, il gruppo di processi o
\label{tab:proc_getpriority}
\end{table}
-La funzione restituisce la priorità più alta (cioè il valore più basso) fra
-quelle dei processi specificati; di nuovo, dato che $-1$ è un valore
-possibile, per poter rilevare una condizione di errore è necessario cancellare
+La funzione restituisce la priorità più alta (cioè il valore più basso) fra
+quelle dei processi specificati; di nuovo, dato che $-1$ è un valore
+possibile, per poter rilevare una condizione di errore è necessario cancellare
sempre \var{errno} prima della chiamata alla funzione per verificare che essa
resti uguale a zero.
-Analoga a \func{getpriority} è la funzione \funcd{setpriority} che permette di
-impostare la priorità di uno o più processi; il suo prototipo è:
+Analoga a \func{getpriority} è la funzione \funcd{setpriority} che permette di
+impostare la priorità di uno o più processi; il suo prototipo è:
\begin{prototype}{sys/resource.h}
{int setpriority(int which, int who, int prio)}
- Imposta la priorità per l'insieme dei processi specificati.
+ Imposta la priorità per l'insieme dei processi specificati.
\bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
- nel qual caso \var{errno} può assumere i valori:
+ nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
- \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
+ \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
\param{which} e \param{who}.
- \item[\errcode{EINVAL}] il valore di \param{which} non è valido.
- \item[\errcode{EACCES}] si è richiesto un aumento di priorità senza avere
+ \item[\errcode{EINVAL}] il valore di \param{which} non è valido.
+ \item[\errcode{EACCES}] si è richiesto un aumento di priorità senza avere
sufficienti privilegi.
\item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
- cercato di modificare la priorità di un processo di un altro utente.
+ cercato di modificare la priorità di un processo di un altro utente.
\end{errlist}}
\end{prototype}
-La funzione imposta la priorità al valore specificato da \param{prio} per
+La funzione imposta la priorità al valore specificato da \param{prio} per
tutti i processi indicati dagli argomenti \param{which} e \param{who}. In
questo caso come valore di \param{prio} deve essere specificato il valore di
\textit{nice} da assegnare, e non un incremento (positivo o negativo) come nel
\var{errno} prima della chiamata della funzione, essendo $-1$ un valore di
\textit{nice} valido.
-Si tenga presente che solo l'amministratore\footnote{o più precisamente un
+Si tenga presente che solo l'amministratore\footnote{o più precisamente un
processo con la \itindex{capabilities} \textit{capability}
\const{CAP\_SYS\_NICE}, vedi sez.~\ref{sec:proc_capabilities}.} ha la
-possibilità di modificare arbitrariamente le priorità di qualunque
-processo. Un utente normale infatti può modificare solo la priorità dei suoi
+possibilità di modificare arbitrariamente le priorità di qualunque
+processo. Un utente normale infatti può modificare solo la priorità dei suoi
processi ed in genere soltanto diminuirla. Fino alla versione di kernel
2.6.12 Linux ha seguito le specifiche dello standard SUSv3, e come per tutti i
sistemi derivati da SysV veniva richiesto che l'user-ID reale o quello
effettivo del processo chiamante corrispondessero all'user-ID reale (e solo a
-quello) del processo di cui si intendeva cambiare la priorità. A partire dalla
-versione 2.6.12 è stata adottata la semantica in uso presso i sistemi derivati
-da BSD (SunOS, Ultrix, *BSD), in cui la corrispondenza può essere anche con
+quello) del processo di cui si intendeva cambiare la priorità. A partire dalla
+versione 2.6.12 è stata adottata la semantica in uso presso i sistemi derivati
+da BSD (SunOS, Ultrix, *BSD), in cui la corrispondenza può essere anche con
l'user-ID effettivo.
-Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti
-ordinari poter aumentare la priorità dei propri processi specificando un
-valore di \param{prio} negativo. Questa operazione non è possibile però in
-maniera indiscriminata, ed in particolare può essere effettuata solo
+Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti
+ordinari poter aumentare la priorità dei propri processi specificando un
+valore di \param{prio} negativo. Questa operazione non è possibile però in
+maniera indiscriminata, ed in particolare può essere effettuata solo
nell'intervallo consentito dal valore del limite \const{RLIMIT\_NICE}
(torneremo su questo in sez.~\ref{sec:sys_resource_limit}).
\label{sec:proc_real_time}
Come spiegato in sez.~\ref{sec:proc_sched} lo standard POSIX.1b ha introdotto
-le priorità assolute per permettere la gestione di processi real-time. In
-realtà nel caso di Linux non si tratta di un vero hard real-time, in quanto in
+le priorità assolute per permettere la gestione di processi real-time. In
+realtà nel caso di Linux non si tratta di un vero hard real-time, in quanto in
presenza di eventuali interrupt il kernel interrompe l'esecuzione di un
-processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
- siano installate le patch di RTLinux, RTAI o Adeos, con i quali è possibile
+processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
+ siano installate le patch di RTLinux, RTAI o Adeos, con i quali è possibile
ottenere un sistema effettivamente hard real-time. In tal caso infatti gli
interrupt vengono intercettati dall'interfaccia real-time (o nel caso di
Adeos gestiti dalle code del nano-kernel), in modo da poterli controllare
- direttamente qualora ci sia la necessità di avere un processo con priorità
- più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
+ direttamente qualora ci sia la necessità di avere un processo con priorità
+ più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
\itindex{page~fault} \textit{page fault} si possono avere ritardi non
-previsti. Se l'ultimo problema può essere aggirato attraverso l'uso delle
+previsti. Se l'ultimo problema può essere aggirato attraverso l'uso delle
funzioni di controllo della memoria virtuale (vedi
-sez.~\ref{sec:proc_mem_lock}), il primo non è superabile e può comportare
+sez.~\ref{sec:proc_mem_lock}), il primo non è superabile e può comportare
ritardi non prevedibili riguardo ai tempi di esecuzione di qualunque processo.
Nonostante questo, ed in particolare con una serie di miglioramenti che sono
stati introdotti nello sviluppo del kernel,\footnote{in particolare a partire
dalla versione 2.6.18 sono stati inserite nel kernel una serie di modifiche
- che consentono di avvicinarsi sempre di più ad un vero e proprio sistema
+ che consentono di avvicinarsi sempre di più ad un vero e proprio sistema
\textit{real-time} estendendo il concetto di \textit{preemption} alle
- operazioni dello stesso kernel; esistono vari livelli a cui questo può
+ operazioni dello stesso kernel; esistono vari livelli a cui questo può
essere fatto, ottenibili attivando in fase di compilazione una fra le
opzioni \texttt{CONFIG\_PREEMPT\_NONE}, \texttt{CONFIG\_PREEMPT\_VOLUNTARY}
- e \texttt{CONFIG\_PREEMPT\_DESKTOP}.} si può arrivare ad una ottima
-approssimazione di sistema real-time usando le priorità assolute; occorre
-farlo però con molta attenzione: se si dà ad un processo una priorità assoluta
-e questo finisce in un loop infinito, nessun altro processo potrà essere
-eseguito, ed esso sarà mantenuto in esecuzione permanentemente assorbendo
-tutta la CPU e senza nessuna possibilità di riottenere l'accesso al
-sistema. Per questo motivo è sempre opportuno, quando si lavora con processi
-che usano priorità assolute, tenere attiva una shell cui si sia assegnata la
-massima priorità assoluta, in modo da poter essere comunque in grado di
+ e \texttt{CONFIG\_PREEMPT\_DESKTOP}.} si può arrivare ad una ottima
+approssimazione di sistema real-time usando le priorità assolute; occorre
+farlo però con molta attenzione: se si dà ad un processo una priorità assoluta
+e questo finisce in un loop infinito, nessun altro processo potrà essere
+eseguito, ed esso sarà mantenuto in esecuzione permanentemente assorbendo
+tutta la CPU e senza nessuna possibilità di riottenere l'accesso al
+sistema. Per questo motivo è sempre opportuno, quando si lavora con processi
+che usano priorità assolute, tenere attiva una shell cui si sia assegnata la
+massima priorità assoluta, in modo da poter essere comunque in grado di
rientrare nel sistema.
-Quando c'è un processo con priorità assoluta lo scheduler lo metterà in
-esecuzione prima di ogni processo normale. In caso di più processi sarà
-eseguito per primo quello con priorità assoluta più alta. Quando ci sono più
-processi con la stessa priorità assoluta questi vengono tenuti in una coda e
+Quando c'è un processo con priorità assoluta lo scheduler lo metterà in
+esecuzione prima di ogni processo normale. In caso di più processi sarà
+eseguito per primo quello con priorità assoluta più alta. Quando ci sono più
+processi con la stessa priorità assoluta questi vengono tenuti in una coda e
tocca al kernel decidere quale deve essere eseguito. Il meccanismo con cui
-vengono gestiti questi processi dipende dalla politica di scheduling che si è
+vengono gestiti questi processi dipende dalla politica di scheduling che si è
scelta; lo standard ne prevede due:
\begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
\item[\textsf{FIFO}] \textit{First In First Out}. Il processo viene eseguito
fintanto che non cede volontariamente la CPU (con \func{sched\_yield}), si
- blocca, finisce o viene interrotto da un processo a priorità più alta. Se il
- processo viene interrotto da uno a priorità più alta esso resterà in cima
- alla lista e sarà il primo ad essere eseguito quando i processi a priorità
- più alta diverranno inattivi. Se invece lo si blocca volontariamente sarà
- posto in coda alla lista (ed altri processi con la stessa priorità potranno
+ blocca, finisce o viene interrotto da un processo a priorità più alta. Se il
+ processo viene interrotto da uno a priorità più alta esso resterà in cima
+ alla lista e sarà il primo ad essere eseguito quando i processi a priorità
+ più alta diverranno inattivi. Se invece lo si blocca volontariamente sarà
+ posto in coda alla lista (ed altri processi con la stessa priorità potranno
essere eseguiti).
-\item[\textsf{RR}] \textit{Round Robin}. Il comportamento è del tutto analogo
+\item[\textsf{RR}] \textit{Round Robin}. Il comportamento è del tutto analogo
a quello precedente, con la sola differenza che ciascun processo viene
eseguito al massimo per un certo periodo di tempo (la cosiddetta
\textit{time-slice}) dopo di che viene automaticamente posto in fondo alla
- coda dei processi con la stessa priorità. In questo modo si ha comunque una
+ coda dei processi con la stessa priorità. In questo modo si ha comunque una
esecuzione a turno di tutti i processi, da cui il nome della politica. Solo
- i processi con la stessa priorità ed in stato \textbf{Runnable} entrano nel
+ i processi con la stessa priorità ed in stato \textbf{Runnable} entrano nel
\textsl{girotondo}.
\end{basedescript}
Lo standard POSIX.1-2001 prevede una funzione che consenta sia di modificare
le politiche di scheduling, passando da real-time a ordinarie o viceversa, che
-di specificare, in caso di politiche real-time, la eventuale priorità statica;
-la funzione è \funcd{sched\_setscheduler} ed il suo prototipo è:
+di specificare, in caso di politiche real-time, la eventuale priorità statica;
+la funzione è \funcd{sched\_setscheduler} ed il suo prototipo è:
\begin{prototype}{sched.h}
{int sched\_setscheduler(pid\_t pid, int policy, const struct sched\_param *p)}
- Imposta priorità e politica di scheduling.
+ Imposta priorità e politica di scheduling.
\bodydesc{La funzione ritorna 0 in caso di successo e $-$1 in caso di
- errore, nel qual caso \var{errno} può assumere i valori:
+ errore, nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\item[\errcode{EINVAL}] il valore di \param{policy} non esiste o il
- relativo valore di \param{p} non è valido.
+ relativo valore di \param{p} non è valido.
\item[\errcode{EPERM}] il processo non ha i privilegi per attivare la
politica richiesta.
\end{errlist}}
La funzione esegue l'impostazione per il processo specificato dall'argomento
\param{pid}; un valore nullo di questo argomento esegue l'impostazione per il
-processo corrente. La politica di scheduling è specificata
+processo corrente. La politica di scheduling è specificata
dall'argomento \param{policy} i cui possibili valori sono riportati in
tab.~\ref{tab:proc_sched_policy}; la parte alta della tabella indica le
politiche real-time, quella bassa le politiche ordinarie. Un valore negativo
\const{SCHED\_OTHER}& Scheduling ordinario.\\
\const{SCHED\_BATCH}& Scheduling ordinario con l'assunzione ulteriore di
lavoro \textit{CPU intensive}.\footnotemark\\
- \const{SCHED\_IDLE} & Scheduling di priorità estremamente
+ \const{SCHED\_IDLE} & Scheduling di priorità estremamente
bassa.\footnotemark\\
\hline
\end{tabular}
\footnotetext[44]{introdotto con il kernel 2.6.16.}
\footnotetext{introdotto con il kernel 2.6.23.}
-Con le versioni più recenti del kernel sono state introdotte anche delle
+Con le versioni più recenti del kernel sono state introdotte anche delle
varianti sulla politica di scheduling tradizionale per alcuni carichi di
lavoro specifici, queste due nuove politiche sono specifiche di Linux e non
devono essere usate se si vogliono scrivere programmi portabili.
-La politica \const{SCHED\_BATCH} è una variante della politica ordinaria con
+La politica \const{SCHED\_BATCH} è una variante della politica ordinaria con
la sola differenza che i processi ad essa soggetti non ottengono, nel calcolo
-delle priorità dinamiche fatto dallo scheduler, il cosiddetto bonus di
-interattività che mira a favorire i processi che si svegliano dallo stato di
+delle priorità dinamiche fatto dallo scheduler, il cosiddetto bonus di
+interattività che mira a favorire i processi che si svegliano dallo stato di
\textbf{Sleep}.\footnote{cosa che accade con grande frequenza per i processi
interattivi, dato che essi sono per la maggior parte del tempo in attesa di
dati in ingresso da parte dell'utente.} La si usa pertanto, come indica il
devono rispondere a dei dati in ingresso, pur non perdendo il loro valore di
\textit{nice}.
-La politica \const{SCHED\_IDLE} invece è una politica dedicata ai processi che
-si desidera siano eseguiti con la più bassa priorità possibile, ancora più
+La politica \const{SCHED\_IDLE} invece è una politica dedicata ai processi che
+si desidera siano eseguiti con la più bassa priorità possibile, ancora più
bassa di un processo con il minimo valore di \textit{nice}. In sostanza la si
-può utilizzare per processi che devono essere eseguiti se non c'è niente altro
+può utilizzare per processi che devono essere eseguiti se non c'è niente altro
da fare. Va comunque sottolineato che anche un processo \const{SCHED\_IDLE}
-avrà comunque una sua possibilità di utilizzo della CPU, sia pure in
+avrà comunque una sua possibilità di utilizzo della CPU, sia pure in
percentuale molto bassa.
-Qualora si sia richiesta una politica real-time il valore della priorità
+Qualora si sia richiesta una politica real-time il valore della priorità
statica viene impostato attraverso la struttura \struct{sched\_param},
riportata in fig.~\ref{fig:sig_sched_param}, il cui solo campo attualmente
-definito è \var{sched\_priority}. Il campo deve contenere il valore della
-priorità statica da assegnare al processo; lo standard prevede che questo
+definito è \var{sched\_priority}. Il campo deve contenere il valore della
+priorità statica da assegnare al processo; lo standard prevede che questo
debba essere assegnato all'interno di un intervallo fra un massimo ed un
minimo che nel caso di Linux sono rispettivamente 1 e 99.
\end{figure}
I processi con politica di scheduling ordinaria devono sempre specificare un
-valore nullo di \var{sched\_priority} altrimenti si avrà un errore
+valore nullo di \var{sched\_priority} altrimenti si avrà un errore
\errcode{EINVAL}, questo valore infatti non ha niente a che vedere con la
-priorità dinamica determinata dal valore di \textit{nice}, che deve essere
+priorità dinamica determinata dal valore di \textit{nice}, che deve essere
impostato con le funzioni viste in precedenza.
Lo standard POSIX.1b prevede comunque che i due valori della massima e minima
-priorità statica possano essere ottenuti, per ciascuna delle politiche di
+priorità statica possano essere ottenuti, per ciascuna delle politiche di
scheduling \textit{real-time}, tramite le due funzioni
\funcd{sched\_get\_priority\_max} e \funcd{sched\_get\_priority\_min}, i cui
prototipi sono:
\headdecl{sched.h}
\funcdecl{int sched\_get\_priority\_max(int policy)} Legge il valore
- massimo della priorità statica per la politica di scheduling \param{policy}.
+ massimo della priorità statica per la politica di scheduling \param{policy}.
\funcdecl{int sched\_get\_priority\_min(int policy)} Legge il valore minimo
- della priorità statica per la politica di scheduling \param{policy}.
+ della priorità statica per la politica di scheduling \param{policy}.
- \bodydesc{La funzioni ritornano il valore della priorità in caso di successo
- e $-1$ in caso di errore, nel qual caso \var{errno} può assumere i valori:
+ \bodydesc{La funzioni ritornano il valore della priorità in caso di successo
+ e $-1$ in caso di errore, nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
- \item[\errcode{EINVAL}] il valore di \param{policy} non è valido.
+ \item[\errcode{EINVAL}] il valore di \param{policy} non è valido.
\end{errlist}}
\end{functions}
Si tenga presente che quando si imposta una politica di scheduling real-time
-per un processo o se ne cambia la priorità statica questo viene messo in cima
-alla lista dei processi con la stessa priorità; questo comporta che verrà
-eseguito subito, interrompendo eventuali altri processi con la stessa priorità
+per un processo o se ne cambia la priorità statica questo viene messo in cima
+alla lista dei processi con la stessa priorità; questo comporta che verrà
+eseguito subito, interrompendo eventuali altri processi con la stessa priorità
in quel momento in esecuzione.
-Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed
+Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed
esegue sempre il primo della lista, mentre un nuovo processo che torna in
stato \textbf{Runnable} viene sempre inserito in coda alla lista. Se la
-politica scelta è \const{SCHED\_FIFO} quando il processo viene eseguito viene
+politica scelta è \const{SCHED\_FIFO} quando il processo viene eseguito viene
automaticamente rimesso in coda alla lista, e la sua esecuzione continua
fintanto che non viene bloccato da una richiesta di I/O, o non rilascia
volontariamente la CPU (in tal caso, tornando nello stato \textbf{Runnable}
-sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo
-nel caso che esso sia stato interrotto da un processo a priorità più alta.
+sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo
+nel caso che esso sia stato interrotto da un processo a priorità più alta.
-Solo un processo con i privilegi di amministratore\footnote{più precisamente
- con la \itindex{capabilities} capacità \const{CAP\_SYS\_NICE}, vedi
- sez.~\ref{sec:proc_capabilities}.} può impostare senza restrizioni priorità
+Solo un processo con i privilegi di amministratore\footnote{più precisamente
+ con la \itindex{capabilities} capacità \const{CAP\_SYS\_NICE}, vedi
+ sez.~\ref{sec:proc_capabilities}.} può impostare senza restrizioni priorità
assolute diverse da zero o politiche \const{SCHED\_FIFO} e
-\const{SCHED\_RR}. Un utente normale può modificare solo le priorità di
-processi che gli appartengono; è cioè richiesto che l'user-ID effettivo del
+\const{SCHED\_RR}. Un utente normale può modificare solo le priorità di
+processi che gli appartengono; è cioè richiesto che l'user-ID effettivo del
processo chiamante corrisponda all'user-ID reale o effettivo del processo
indicato con \param{pid}.
Fino al kernel 2.6.12 gli utenti normali non potevano impostare politiche
-real-time o modificare la eventuale priorità statica di un loro processo. A
-partire da questa versione è divenuto possibile anche per gli utenti normali
-usare politiche real-time fintanto che la priorità assoluta che si vuole
-impostare è inferiore al limite \const{RLIMIT\_RTPRIO} (vedi
+real-time o modificare la eventuale priorità statica di un loro processo. A
+partire da questa versione è divenuto possibile anche per gli utenti normali
+usare politiche real-time fintanto che la priorità assoluta che si vuole
+impostare è inferiore al limite \const{RLIMIT\_RTPRIO} (vedi
sez.~\ref{sec:sys_resource_limit}) ad essi assegnato. Unica eccezione a questa
-possibilità sono i processi \const{SCHED\_IDLE}, che non possono cambiare
+possibilità sono i processi \const{SCHED\_IDLE}, che non possono cambiare
politica di scheduling indipendentemente dal valore di
-\const{RLIMIT\_RTPRIO}. Inoltre, in caso di processo già sottoposto ad una
-politica real-time, un utente può sempre, indipendentemente dal valore di
-\const{RLIMIT\_RTPRIO}, diminuirne la priorità o portarlo ad una politica
+\const{RLIMIT\_RTPRIO}. Inoltre, in caso di processo già sottoposto ad una
+politica real-time, un utente può sempre, indipendentemente dal valore di
+\const{RLIMIT\_RTPRIO}, diminuirne la priorità o portarlo ad una politica
ordinaria.
-Se si intende operare solo sulla priorità statica di un processo si possono
+Se si intende operare solo sulla priorità statica di un processo si possono
usare le due funzioni \funcd{sched\_setparam} e \funcd{sched\_getparam} che
consentono rispettivamente di impostarne e leggerne il valore, i loro
prototipi sono:
\headdecl{sched.h}
\funcdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *param)}
- Imposta la priorità statica del processo \param{pid}.
+ Imposta la priorità statica del processo \param{pid}.
\funcdecl{int sched\_getparam(pid\_t pid, struct sched\_param *param)}
- Legge la priorità statica del processo \param{pid}.
+ Legge la priorità statica del processo \param{pid}.
\bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e $-1$ in
- caso di errore, nel qual caso \var{errno} può assumere i valori:
+ caso di errore, nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\item[\errcode{EINVAL}] il valore di \param{param} non ha senso per la
\end{functions}
L'uso di \func{sched\_setparam}, compresi i controlli di accesso che vi si
-applicano, è del tutto equivalente a quello di \func{sched\_setscheduler} con
+applicano, è del tutto equivalente a quello di \func{sched\_setscheduler} con
argomento \param{policy} uguale a -1. Come per \func{sched\_setscheduler}
specificando 0 come valore dell'argomento \param{pid} si opera sul processo
-corrente. Benché la funzione sia utilizzabile anche con processi sottoposti a
+corrente. Benché la funzione sia utilizzabile anche con processi sottoposti a
politica ordinaria essa ha senso soltanto per quelli real-time, dato che per i
-primi la priorità statica può essere soltanto nulla. La disponibilità di
-entrambe le funzioni può essere verificata controllando la macro
-\macro{\_POSIX\_PRIORITY\_SCHEDULING} che è definita nell'header
+primi la priorità statica può essere soltanto nulla. La disponibilità di
+entrambe le funzioni può essere verificata controllando la macro
+\macro{\_POSIX\_PRIORITY\_SCHEDULING} che è definita nell'header
\file{sched.h}.
-Se invece si vuole sapere quale è politica di scheduling di un processo si può
-usare la funzione \funcd{sched\_getscheduler}, il cui prototipo è:
+Se invece si vuole sapere quale è politica di scheduling di un processo si può
+usare la funzione \funcd{sched\_getscheduler}, il cui prototipo è:
\begin{prototype}{sched.h}
{int sched\_getscheduler(pid\_t pid)}
Legge la politica di scheduling per il processo \param{pid}.
\bodydesc{La funzione ritorna la politica di scheduling in caso di successo
- e $-1$ in caso di errore, nel qual caso \var{errno} può assumere i valori:
+ e $-1$ in caso di errore, nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire
La funzione restituisce il valore, secondo quanto elencato in
tab.~\ref{tab:proc_sched_policy}, della politica di scheduling per il processo
-specificato; se l'argomento \param{pid} è nullo viene restituito il valore
+specificato; se l'argomento \param{pid} è nullo viene restituito il valore
relativo al processo chiamante.
L'ultima funzione che permette di leggere le informazioni relative ai processi
-real-time è \funcd{sched\_rr\_get\_interval}, che permette di ottenere la
+real-time è \funcd{sched\_rr\_get\_interval}, che permette di ottenere la
lunghezza della \textit{time-slice} usata dalla politica \textit{round robin};
-il suo prototipo è:
+il suo prototipo è:
\begin{prototype}{sched.h}
{int sched\_rr\_get\_interval(pid\_t pid, struct timespec *tp)} Legge in
\param{tp} la durata della \textit{time-slice} per il processo \param{pid}.
\bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
- nel qual caso \var{errno} può assumere i valori:
+ nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
- \item[\errcode{ENOSYS}] la system call non è stata implementata.
+ \item[\errcode{ENOSYS}] la system call non è stata implementata.
\end{errlist}}
\end{prototype}
La funzione restituisce il valore dell'intervallo di tempo usato per la
politica \textit{round robin} in una struttura \struct{timespec}, (la cui
-definizione si può trovare in fig.~\ref{fig:sys_timeval_struct}). In realtà
-dato che in Linux questo intervallo di tempo è prefissato e non modificabile,
+definizione si può trovare in fig.~\ref{fig:sys_timeval_struct}). In realtà
+dato che in Linux questo intervallo di tempo è prefissato e non modificabile,
questa funzione ritorna sempre un valore di 150 millisecondi, e non importa
specificare il PID di un processo reale.
-Come accennato ogni processo può rilasciare volontariamente la CPU in modo da
+Come accennato ogni processo può rilasciare volontariamente la CPU in modo da
consentire agli altri processi di essere eseguiti; la funzione che consente di
-fare tutto ciò è \funcd{sched\_yield}, il cui prototipo è:
+fare tutto ciò è \funcd{sched\_yield}, il cui prototipo è:
\begin{prototype}{sched.h}
{int sched\_yield(void)}
\end{prototype}
Questa funzione ha un utilizzo effettivo soltanto quando si usa lo scheduling
-real-time, e serve a far sì che il processo corrente rilasci la CPU, in modo
-da essere rimesso in coda alla lista dei processi con la stessa priorità per
-permettere ad un altro di essere eseguito; se però il processo è l'unico ad
-essere presente sulla coda l'esecuzione non sarà interrotta. In genere usano
+real-time, e serve a far sì che il processo corrente rilasci la CPU, in modo
+da essere rimesso in coda alla lista dei processi con la stessa priorità per
+permettere ad un altro di essere eseguito; se però il processo è l'unico ad
+essere presente sulla coda l'esecuzione non sarà interrotta. In genere usano
questa funzione i processi con politica \const{SCHED\_FIFO}, per permettere
-l'esecuzione degli altri processi con pari priorità quando la sezione più
-urgente è finita.
+l'esecuzione degli altri processi con pari priorità quando la sezione più
+urgente è finita.
-La funzione può essere utilizzata anche con processi che usano lo scheduling
-ordinario, ma in questo caso il comportamento non è ben definito, e dipende
+La funzione può essere utilizzata anche con processi che usano lo scheduling
+ordinario, ma in questo caso il comportamento non è ben definito, e dipende
dall'implementazione. Fino al kernel 2.6.23 questo comportava che i processi
-venissero messi in fondo alla coda di quelli attivi, con la possibilità di
+venissero messi in fondo alla coda di quelli attivi, con la possibilità di
essere rimessi in esecuzione entro breve tempo, con l'introduzione del
-\textit{Completely Fair Scheduler} questo comportamento è cambiato ed un
+\textit{Completely Fair Scheduler} questo comportamento è cambiato ed un
processo che chiama la funzione viene inserito nella lista dei processi
-inattivo, con un tempo molto maggiore.\footnote{è comunque possibile
+inattivo, con un tempo molto maggiore.\footnote{è comunque possibile
ripristinare un comportamento analogo al precedente scrivendo il valore 1
nel file \texttt{/proc/sys/kernel/sched\_compat\_yield}.}
\label{sec:proc_sched_multiprocess}
Infine con il supporto dei sistemi multiprocessore sono state introdotte delle
-funzioni che permettono di controllare in maniera più dettagliata la scelta di
+funzioni che permettono di controllare in maniera più dettagliata la scelta di
quale processore utilizzare per eseguire un certo programma. Uno dei problemi
-che si pongono nei sistemi multiprocessore è infatti quello del cosiddetto
-\index{effetto~ping-pong} \textsl{effetto ping-pong}. Può accadere cioè che lo
+che si pongono nei sistemi multiprocessore è infatti quello del cosiddetto
+\index{effetto~ping-pong} \textsl{effetto ping-pong}. Può accadere cioè che lo
scheduler, quando riavvia un processo precedentemente interrotto scegliendo il
primo processore disponibile, lo faccia eseguire da un processore diverso
rispetto a quello su cui era stato eseguito in precedenza. Se il processo
di frequente con i kernel della seria 2.4.x) si ha l'\textsl{effetto
ping-pong}.
-Questo tipo di comportamento può generare dei seri problemi di prestazioni;
+Questo tipo di comportamento può generare dei seri problemi di prestazioni;
infatti tutti i processori moderni utilizzano una memoria interna (la
-\textit{cache}) contenente i dati più usati, che permette di evitare di
-eseguire un accesso (molto più lento) alla memoria principale sulla scheda
-madre. Chiaramente un processo sarà favorito se i suoi dati sono nella cache
-del processore, ma è ovvio che questo può essere vero solo per un processore
-alla volta, perché in presenza di più copie degli stessi dati su più
+\textit{cache}) contenente i dati più usati, che permette di evitare di
+eseguire un accesso (molto più lento) alla memoria principale sulla scheda
+madre. Chiaramente un processo sarà favorito se i suoi dati sono nella cache
+del processore, ma è ovvio che questo può essere vero solo per un processore
+alla volta, perché in presenza di più copie degli stessi dati su più
processori, non si potrebbe determinare quale di questi ha la versione dei
dati aggiornata rispetto alla memoria principale.
Questo comporta che quando un processore inserisce un dato nella sua cache,
tutti gli altri processori che hanno lo stesso dato devono invalidarlo, e
-questa operazione è molto costosa in termini di prestazioni. Il problema
+questa operazione è molto costosa in termini di prestazioni. Il problema
diventa serio quando si verifica l'\textsl{effetto ping-pong}, in tal caso
infatti un processo \textsl{rimbalza} continuamente da un processore all'altro
e si ha una continua invalidazione della cache, che non diventa mai
\itindbeg{CPU~affinity}
-Per ovviare a questo tipo di problemi è nato il concetto di \textsl{affinità
- di processore} (o \textit{CPU affinity}); la possibilità cioè di far sì che
+Per ovviare a questo tipo di problemi è nato il concetto di \textsl{affinità
+ di processore} (o \textit{CPU affinity}); la possibilità cioè di far sì che
un processo possa essere assegnato per l'esecuzione sempre allo stesso
processore. Lo scheduler dei kernel della serie 2.4.x aveva una scarsa
\textit{CPU affinity}, e \index{effetto~ping-pong} l'effetto ping-pong era
-comune; con il nuovo scheduler dei kernel della 2.6.x questo problema è stato
-risolto ed esso cerca di mantenere il più possibile ciascun processo sullo
+comune; con il nuovo scheduler dei kernel della 2.6.x questo problema è stato
+risolto ed esso cerca di mantenere il più possibile ciascun processo sullo
stesso processore.
-In certi casi però resta l'esigenza di poter essere sicuri che un processo sia
+In certi casi però resta l'esigenza di poter essere sicuri che un processo sia
sempre eseguito dallo stesso processore,\footnote{quella che viene detta
\textit{hard CPU affinity}, in contrasto con quella fornita dallo scheduler,
detta \textit{soft CPU affinity}, che di norma indica solo una preferenza,
non un requisito assoluto.} e per poter risolvere questo tipo di
problematiche nei nuovi kernel\footnote{le due system call per la gestione
della \textit{CPU affinity} sono state introdotte nel kernel 2.5.8, e le
- funzioni di libreria nelle \textsl{glibc} 2.3.} è stata introdotta
+ funzioni di libreria nelle \textsl{glibc} 2.3.} è stata introdotta
l'opportuna infrastruttura ed una nuova system call che permette di impostare
su quali processori far eseguire un determinato processo attraverso una
-\textsl{maschera di affinità}. La corrispondente funzione di libreria è
-\funcd{sched\_setaffinity} ed il suo prototipo è:
+\textsl{maschera di affinità}. La corrispondente funzione di libreria è
+\funcd{sched\_setaffinity} ed il suo prototipo è:
\begin{prototype}{sched.h}
{int sched\_setaffinity (pid\_t pid, unsigned int cpusetsize, const
cpu\_set\_t *cpuset)}
- Imposta la maschera di affinità del processo \param{pid}.
+ Imposta la maschera di affinità del processo \param{pid}.
\bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
- nel qual caso \var{errno} può assumere i valori:
+ nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\item[\errcode{EINVAL}] il valore di \param{cpuset} contiene riferimenti a
maschera binaria. Quando le funzioni vennero incluse nelle \acr{glibc}
assunsero invece il prototipo appena mostrato. A complicare la cosa si
aggiunge il fatto che nella versione 2.3.3 delle \acr{glibc} l'argomento
-\param{cpusetsize} è stato eliminato, per poi essere ripristinato nella
-versione 2.3.4.\footnote{pertanto se la vostra pagina di manuale non è
+\param{cpusetsize} è stato eliminato, per poi essere ripristinato nella
+versione 2.3.4.\footnote{pertanto se la vostra pagina di manuale non è
aggiornata, o usate quella particolare versione delle \acr{glibc}, potrete
- trovare indicazioni diverse, il prototipo illustrato è quello riportato
+ trovare indicazioni diverse, il prototipo illustrato è quello riportato
nella versione corrente (maggio 2008) delle pagine di manuale e
corrispondente alla definizione presente in \file{sched.h}.}
processo identificato tramite il valore passato in \param{pid}. Come in
precedenza il valore nullo di \param{pid} indica il processo corrente. Per
poter utilizzare questa funzione sono richiesti i privilegi di amministratore
-(è necessaria la capacità \const{CAP\_SYS\_NICE}) altrimenti essa fallirà con
-un errore di \errcode{EPERM}. Una volta impostata una maschera di affinità,
+(è necessaria la capacità \const{CAP\_SYS\_NICE}) altrimenti essa fallirà con
+un errore di \errcode{EPERM}. Una volta impostata una maschera di affinità,
questa viene ereditata attraverso una \func{fork}, in questo modo diventa
possibile legare automaticamente un gruppo di processi ad un singolo
processore.
Nell'uso comune, almeno con i kernel della serie 2.6.x, l'uso di questa
-funzione non è necessario, in quanto è lo scheduler stesso che provvede a
-mantenere al meglio l'affinità di processore. Esistono però esigenze
-particolari, ad esempio quando un processo (o un gruppo di processi) è
+funzione non è necessario, in quanto è lo scheduler stesso che provvede a
+mantenere al meglio l'affinità di processore. Esistono però esigenze
+particolari, ad esempio quando un processo (o un gruppo di processi) è
utilizzato per un compito importante (ad esempio per applicazioni real-time o
-la cui risposta è critica) e si vuole la massima velocità, con questa
+la cui risposta è critica) e si vuole la massima velocità, con questa
interfaccia diventa possibile selezionare gruppi di processori utilizzabili in
maniera esclusiva. Lo stesso dicasi quando l'accesso a certe risorse (memoria
-o periferiche) può avere un costo diverso a seconda del processore, come
+o periferiche) può avere un costo diverso a seconda del processore, come
avviene nelle architetture NUMA (\textit{Non-Uniform Memory Access}).
Infine se un gruppo di processi accede alle stesse risorse condivise (ad
-esempio una applicazione con più \itindex{thread} \textit{thread}) può avere
+esempio una applicazione con più \itindex{thread} \textit{thread}) può avere
senso usare lo stesso processore in modo da sfruttare meglio l'uso della sua
cache; questo ovviamente riduce i benefici di un sistema multiprocessore
nell'esecuzione contemporanea dei \itindex{thread} \textit{thread}, ma in
certi casi (quando i \itindex{thread} \textit{thread} sono inerentemente
serializzati nell'accesso ad una risorsa) possono esserci sufficienti vantaggi
-nell'evitare la perdita della cache da rendere conveniente l'uso dell'affinità
+nell'evitare la perdita della cache da rendere conveniente l'uso dell'affinità
di processore.
Per facilitare l'uso dell'argomento \param{cpuset} le \acr{glibc} hanno
-introdotto un apposito dato di tipo, \ctyp{cpu\_set\_t},\footnote{questa è una
+introdotto un apposito dato di tipo, \ctyp{cpu\_set\_t},\footnote{questa è una
estensione specifica delle \acr{glibc}, da attivare definendo la macro
\macro{\_GNU\_SOURCE}, non esiste infatti una standardizzazione per
questo tipo di interfaccia e POSIX al momento non prevede nulla al
- riguardo.} che permette di identificare un insieme di processori. Il dato è
-una maschera binaria: in generale è un intero a 32 bit in cui ogni bit
+ riguardo.} che permette di identificare un insieme di processori. Il dato è
+una maschera binaria: in generale è un intero a 32 bit in cui ogni bit
corrisponde ad un processore, ma dato che per architetture particolari il
-numero di bit di un intero può non essere sufficiente, è stata creata questa
-che è una interfaccia generica che permette di usare a basso livello un tipo
+numero di bit di un intero può non essere sufficiente, è stata creata questa
+che è una interfaccia generica che permette di usare a basso livello un tipo
di dato qualunque rendendosi indipendenti dal numero di bit e dalla loro
disposizione.
Questa interfaccia, oltre alla definizione del tipo di dato apposito, prevede
anche una serie di macro di preprocessore per la manipolazione dello stesso,
che consentono di svuotare un insieme, aggiungere o togliere un processore da
-esso o verificare se vi è già presente:
+esso o verificare se vi è già presente:
\begin{functions}
\headdecl{sched.h}
\funcdecl{void \macro{CPU\_ZERO}(cpu\_set\_t *set)}
Rimuove il processore \param{cpu} nell'insieme.
\funcdecl{int \macro{CPU\_ISSET}(int cpu, cpu\_set\_t *set)}
- Controlla se il processore \param{cpu} è nell'insieme.
+ Controlla se il processore \param{cpu} è nell'insieme.
\end{functions}
Oltre a queste macro, simili alle analoghe usate per gli insiemi di file
-descriptor (vedi sez.~\ref{sec:file_select}) è definita la costante
+descriptor (vedi sez.~\ref{sec:file_select}) è definita la costante
\const{CPU\_SETSIZE} che indica il numero massimo di processori che possono
far parte dell'insieme, e che costituisce un limite massimo al valore
dell'argomento \param{cpu}.
-In generale la maschera di affinità è preimpostata in modo che un processo
-possa essere eseguito su qualunque processore, se può comunque leggere il
+In generale la maschera di affinità è preimpostata in modo che un processo
+possa essere eseguito su qualunque processore, se può comunque leggere il
valore per un processo specifico usando la funzione
-\funcd{sched\_getaffinity}, il suo prototipo è:
+\funcd{sched\_getaffinity}, il suo prototipo è:
\begin{prototype}{sched.h}
{int sched\_getaffinity (pid\_t pid, unsigned int cpusetsize,
const cpu\_set\_t *cpuset)}
- Legge la maschera di affinità del processo \param{pid}.
+ Legge la maschera di affinità del processo \param{pid}.
\bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
- nel qual caso \var{errno} può assumere i valori:
+ nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
- \item[\errcode{EFAULT}] il valore di \param{cpuset} non è un indirizzo
+ \item[\errcode{EFAULT}] il valore di \param{cpuset} non è un indirizzo
valido.
\end{errlist} }
\end{prototype}
-La funzione restituirà all'indirizzo specificato da \param{cpuset} il valore
-della maschera di affinità del processo, così da poterla riutilizzare per una
+La funzione restituirà all'indirizzo specificato da \param{cpuset} il valore
+della maschera di affinità del processo, così da poterla riutilizzare per una
successiva reimpostazione. In questo caso non sono necessari privilegi
particolari.
-È chiaro che queste funzioni per la gestione dell'affinità hanno significato
+È chiaro che queste funzioni per la gestione dell'affinità hanno significato
soltanto su un sistema multiprocessore, esse possono comunque essere
-utilizzate anche in un sistema con un processore singolo, nel qual caso però
+utilizzate anche in un sistema con un processore singolo, nel qual caso però
non avranno alcun risultato effettivo.
\itindend{scheduler}
\itindend{CPU~affinity}
-\subsection{Le priorità per le operazioni di I/O}
+\subsection{Le priorità per le operazioni di I/O}
\label{sec:io_priority}
-A lungo l'unica priorità usata per i processi è stata quella relativa
-all'assegnazione dell'uso del processore. Ma il processore non è l'unica
+A lungo l'unica priorità usata per i processi è stata quella relativa
+all'assegnazione dell'uso del processore. Ma il processore non è l'unica
risorsa che i processi devono contendersi, un'altra, altrettanto importante
-per le prestazioni, è quella dell'accesso a disco. Per questo motivo sono
+per le prestazioni, è quella dell'accesso a disco. Per questo motivo sono
stati introdotti diversi \textit{I/O scheduler} in grado di distribuire in
maniera opportuna questa risorsa ai vari processi. Fino al kernel 2.6.17 era
possibile soltanto differenziare le politiche generali di gestione, scegliendo
di usare un diverso \textit{I/O scheduler}; a partire da questa versione, con
-l'introduzione dello scheduler CFQ (\textit{Completely Fair Queuing}) è
+l'introduzione dello scheduler CFQ (\textit{Completely Fair Queuing}) è
divenuto possibile, qualora si usi questo scheduler, impostare anche delle
-diverse priorità di accesso per i singoli processi.\footnote{al momento
- (kernel 2.6.31), le priorità di I/O sono disponibili soltanto per questo
+diverse priorità di accesso per i singoli processi.\footnote{al momento
+ (kernel 2.6.31), le priorità di I/O sono disponibili soltanto per questo
scheduler.}
-La scelta dello scheduler di I/O si può fare in maniera generica a livello di
+La scelta dello scheduler di I/O si può fare in maniera generica a livello di
avvio del kernel assegnando il nome dello stesso al parametro
-\texttt{elevator}, mentre se ne può indicare uno per l'accesso al singolo
+\texttt{elevator}, mentre se ne può indicare uno per l'accesso al singolo
disco scrivendo nel file \texttt{/sys/block/\textit{dev}/queue/scheduler}
-(dove \texttt{\textit{dev}} è il nome del dispositivo associato al disco); gli
+(dove \texttt{\textit{dev}} è il nome del dispositivo associato al disco); gli
scheduler disponibili sono mostrati dal contenuto dello stesso file che
riporta fra parentesi quadre quello attivo, il default in tutti i kernel
-recenti è proprio il \texttt{cfq},\footnote{nome con cui si indica appunto lo
- scheduler \textit{Completely Fair Queuing}.} che supporta le priorità. Per i
+recenti è proprio il \texttt{cfq},\footnote{nome con cui si indica appunto lo
+ scheduler \textit{Completely Fair Queuing}.} che supporta le priorità. Per i
dettagli sulle caratteristiche specifiche degli altri scheduler, la cui
discussione attiene a problematiche di ambito sistemistico, si consulti la
documentazione nella directory \texttt{Documentation/block/} dei sorgenti del
kernel.
Una volta che si sia impostato lo scheduler CFQ ci sono due specifiche system
-call, specifiche di Linux, che consentono di leggere ed impostare le priorità
+call, specifiche di Linux, che consentono di leggere ed impostare le priorità
di I/O.\footnote{se usate in corrispondenza ad uno scheduler diverso il loro
- utilizzo non avrà alcun effetto.} Dato che non esiste una interfaccia
-diretta nelle \acr{glibc} per queste due funzioni occorrerà invocarle tramite
+ utilizzo non avrà alcun effetto.} Dato che non esiste una interfaccia
+diretta nelle \acr{glibc} per queste due funzioni occorrerà invocarle tramite
la funzione \func{syscall} (come illustrato in
sez.~\ref{sec:intro_syscall}). Le due funzioni sono \funcd{ioprio\_get} ed
\funcd{ioprio\_set}; i rispettivi prototipi sono:
\funcdecl{int ioprio\_get(int which, int who)}
\funcdecl{int ioprio\_set(int which, int who, int ioprio)}
- Rileva o imposta la priorità di I/O di un processo.
+ Rileva o imposta la priorità di I/O di un processo.
\bodydesc{Le funzioni ritornano rispettivamente un intero positivo
- (indicante la priorità) o 0 in caso di successo e $-1$ in caso di errore,
- nel qual caso \var{errno} può assumere i valori:
+ (indicante la priorità) o 0 in caso di successo e $-1$ in caso di errore,
+ nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{ESRCH}] non esiste il processo indicato.
\item[\errcode{EINVAL}] i valori di \param{which} e \param{who} non sono
\end{errlist} }
\end{functions}
-Le funzioni leggono o impostano la priorità di I/O sulla base dell'indicazione
+Le funzioni leggono o impostano la priorità di I/O sulla base dell'indicazione
dei due argomenti \param{which} e \param{who} che hanno lo stesso significato
-già visto per gli omonimi argomenti di \func{getpriority} e
+già visto per gli omonimi argomenti di \func{getpriority} e
\func{setpriority}. Anche in questo caso si deve specificare il valore
di \param{which} tramite le opportune costanti riportate in
tab.~\ref{tab:ioprio_args} che consentono di indicare un singolo processo, i
\end{table}
In caso di successo \func{ioprio\_get} restituisce un intero positivo che
-esprime il valore della priorità di I/O, questo valore è una maschera binaria
+esprime il valore della priorità di I/O, questo valore è una maschera binaria
composta da due parti, una che esprime la \textsl{classe} di scheduling di I/O
del processo, l'altra che esprime, quando la classe di scheduling lo prevede,
-la priorità del processo all'interno della classe stessa. Questo stesso
-formato viene utilizzato per indicare il valore della priorità da impostare
+la priorità del processo all'interno della classe stessa. Questo stesso
+formato viene utilizzato per indicare il valore della priorità da impostare
con l'argomento \param{ioprio} di \func{ioprio\_set}.
-Per la gestione dei valori che esprimono le priorità di I/O sono state
+Per la gestione dei valori che esprimono le priorità di I/O sono state
definite delle opportune macro di preprocessore, riportate in
-tab.~\ref{tab:IOsched_class_macro}. I valori delle priorità si ottengono o si
+tab.~\ref{tab:IOsched_class_macro}. I valori delle priorità si ottengono o si
impostano usando queste macro. Le prime due si usano con il valore restituito
da \func{ioprio\_get} e per ottenere rispettivamente la classe di
scheduling\footnote{restituita dalla macro con i valori di
- tab.~\ref{tab:IOsched_class}.} e l'eventuale valore della priorità. La terza
-macro viene invece usata per creare un valore di priorità da usare come
+ tab.~\ref{tab:IOsched_class}.} e l'eventuale valore della priorità. La terza
+macro viene invece usata per creare un valore di priorità da usare come
argomento di \func{ioprio\_set} per eseguire una impostazione.
\begin{table}[htb]
\hline
\hline
\macro{IOPRIO\_PRIO\_CLASS}\texttt{(\textit{value})}
- & dato il valore di una priorità come
+ & dato il valore di una priorità come
restituito da \func{ioprio\_get} estrae il
valore della classe.\\
\macro{IOPRIO\_PRIO\_DATA}\texttt{(\textit{value})}
- & dato il valore di una priorità come
+ & dato il valore di una priorità come
restituito da \func{ioprio\_get} estrae il
- valore della priorità.\\
+ valore della priorità.\\
\macro{IOPRIO\_PRIO\_VALUE}\texttt{(\textit{class},\textit{prio})}
- & dato un valore di priorità ed una classe
+ & dato un valore di priorità ed una classe
ottiene il valore numerico da passare a
\func{ioprio\_set}.\\
\hline
\end{table}
Le classi di scheduling previste dallo scheduler CFQ sono tre, e ricalcano tre
-diverse modalità di distribuzione delle risorse analoghe a quelle già adottate
-anche nel funzionamento dello scheduler del processore. Ciascuna di esse è
+diverse modalità di distribuzione delle risorse analoghe a quelle già adottate
+anche nel funzionamento dello scheduler del processore. Ciascuna di esse è
identificata tramite una opportuna costante, secondo quanto riportato in
tab.~\ref{tab:IOsched_class}.
-La classe di priorità più bassa è \const{IOPRIO\_CLASS\_IDLE}; i processi in
+La classe di priorità più bassa è \const{IOPRIO\_CLASS\_IDLE}; i processi in
questa classe riescono ad accedere a disco soltanto quando nessun altro
processo richiede l'accesso. Occorre pertanto usarla con molta attenzione,
-perché un processo in questa classe può venire completamente bloccato quando
+perché un processo in questa classe può venire completamente bloccato quando
ci sono altri processi in una qualunque delle altre due classi che stanno
accedendo al disco. Quando si usa questa classe non ha senso indicare un
-valore di priorità, dato che in questo caso non esiste nessuna gerarchia e la
-priorità è identica, la minima possibile, per tutti i processi.
+valore di priorità, dato che in questo caso non esiste nessuna gerarchia e la
+priorità è identica, la minima possibile, per tutti i processi.
\begin{table}[htb]
\centering
\hline
\const{IOPRIO\_CLASS\_RT} & Scheduling di I/O \textit{real time}.\\
\const{IOPRIO\_CLASS\_BE} & Scheduling di I/O ordinario.\\
- \const{IOPRIO\_CLASS\_IDLE}& Scheduling di I/O di priorità minima.\\
+ \const{IOPRIO\_CLASS\_IDLE}& Scheduling di I/O di priorità minima.\\
\hline
\end{tabular}
\caption{Costanti che identificano le classi di scheduling di I/O.}
\label{tab:IOsched_class}
\end{table}
-La seconda classe di priorità di I/O è \const{IOPRIO\_CLASS\_BE} (il nome sta
-per \textit{best-effort}) che è quella usata ordinariamente da tutti
-processi. In questo caso esistono priorità diverse che consentono di
+La seconda classe di priorità di I/O è \const{IOPRIO\_CLASS\_BE} (il nome sta
+per \textit{best-effort}) che è quella usata ordinariamente da tutti
+processi. In questo caso esistono priorità diverse che consentono di
assegnazione di una maggiore banda passante nell'accesso a disco ad un
processo rispetto agli altri, con meccanismo simile a quello dei valori di
-\textit{nice} in cui si evita che un processo a priorità più alta possa
-bloccare indefinitamente quelli a priorità più bassa. In questo caso però le
-diverse priorità sono soltanto otto, indicate da un valore numerico fra 0 e 7
-e come per \textit{nice} anche in questo caso un valore più basso indica una
-priorità maggiore.
+\textit{nice} in cui si evita che un processo a priorità più alta possa
+bloccare indefinitamente quelli a priorità più bassa. In questo caso però le
+diverse priorità sono soltanto otto, indicate da un valore numerico fra 0 e 7
+e come per \textit{nice} anche in questo caso un valore più basso indica una
+priorità maggiore.
-Infine la classe di priorità di I/O \textit{real-time}
-\const{IOPRIO\_CLASS\_RT} ricalca le omonime priorità di processore: un
+Infine la classe di priorità di I/O \textit{real-time}
+\const{IOPRIO\_CLASS\_RT} ricalca le omonime priorità di processore: un
processo in questa classe ha sempre la precedenza nell'accesso a disco
rispetto a tutti i processi delle altre classi e di un processo nella stessa
-classe ma con priorità inferiore, ed è pertanto in grado di bloccare
-completamente tutti gli altri. Anche in questo caso ci sono 8 priorità diverse
-con un valore numerico fra 0 e 7, con una priorità più elevata per valori più
+classe ma con priorità inferiore, ed è pertanto in grado di bloccare
+completamente tutti gli altri. Anche in questo caso ci sono 8 priorità diverse
+con un valore numerico fra 0 e 7, con una priorità più elevata per valori più
bassi.
-In generale nel funzionamento ordinario la priorità di I/O di un processo
+In generale nel funzionamento ordinario la priorità di I/O di un processo
viene impostata in maniera automatica nella classe \const{IOPRIO\_CLASS\_BE}
con un valore ottenuto a partire dal corrispondente valore di \textit{nice}
tramite la formula: $\mathtt{\mathit{prio}}=(\mathtt{\mathit{nice}}+20)/5$. Un
-utente ordinario può modificare con \func{ioprio\_set} soltanto le priorità
-dei processi che gli appartengono,\footnote{per la modifica delle priorità di
+utente ordinario può modificare con \func{ioprio\_set} soltanto le priorità
+dei processi che gli appartengono,\footnote{per la modifica delle priorità di
altri processi occorrono privilegi amministrativi, ed in particolare la
- capacità \const{CAP\_SYS\_NICE} (vedi sez.~\ref{sec:proc_capabilities}).}
-cioè quelli il cui user-ID reale corrisponde all'user-ID reale o effettivo del
-chiamante. Data la possibilità di ottenere un blocco totale dello stesso, solo
-l'amministratore\footnote{o un processo con la capacità
- \const{CAP\_SYS\_ADMIN} (vedi sez.~\ref{sec:proc_capabilities}).} può
-impostare un processo ad una priorità di I/O nella classe
+ capacità \const{CAP\_SYS\_NICE} (vedi sez.~\ref{sec:proc_capabilities}).}
+cioè quelli il cui user-ID reale corrisponde all'user-ID reale o effettivo del
+chiamante. Data la possibilità di ottenere un blocco totale dello stesso, solo
+l'amministratore\footnote{o un processo con la capacità
+ \const{CAP\_SYS\_ADMIN} (vedi sez.~\ref{sec:proc_capabilities}).} può
+impostare un processo ad una priorità di I/O nella classe
\const{IOPRIO\_CLASS\_RT} o \const{IOPRIO\_CLASS\_IDLE}.
%TODO verificare http://lwn.net/Articles/355987/
-%TODO trattare le funzionalità per il NUMA
+%TODO trattare le funzionalità per il NUMA
% vedi man numa e le pagine di manuale relative
% vedere anche dove metterle...
\section{Problematiche di programmazione multitasking}
\label{sec:proc_multi_prog}
-Benché i processi siano strutturati in modo da apparire il più possibile come
+Benché i processi siano strutturati in modo da apparire il più possibile come
indipendenti l'uno dall'altro, nella programmazione in un sistema multitasking
occorre tenere conto di una serie di problematiche che normalmente non
esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
programma alla volta.
-Pur essendo questo argomento di carattere generale, ci è parso opportuno
-introdurre sinteticamente queste problematiche, che ritroveremo a più riprese
+Pur essendo questo argomento di carattere generale, ci è parso opportuno
+introdurre sinteticamente queste problematiche, che ritroveremo a più riprese
in capitoli successivi, in questa sezione conclusiva del capitolo in cui
abbiamo affrontato la gestione dei processi.
\label{sec:proc_atom_oper}
La nozione di \textsl{operazione atomica} deriva dal significato greco della
-parola atomo, cioè indivisibile; si dice infatti che un'operazione è atomica
+parola atomo, cioè indivisibile; si dice infatti che un'operazione è atomica
quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi
-che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
+che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
di interruzione in una fase intermedia.
-In un ambiente multitasking il concetto è essenziale, dato che un processo può
+In un ambiente multitasking il concetto è essenziale, dato che un processo può
essere interrotto in qualunque momento dal kernel che mette in esecuzione un
altro processo o dalla ricezione di un segnale; occorre pertanto essere
accorti nei confronti delle possibili \itindex{race~condition} \textit{race
condition} (vedi sez.~\ref{sec:proc_race_cond}) derivanti da operazioni
interrotte in una fase in cui non erano ancora state completate.
-Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
-occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
+Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
+occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
cap.~\ref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
sez.~\ref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
-funzioni di libreria per compiere le operazioni necessarie è garanzia
-sufficiente di atomicità in quanto le system call con cui esse sono realizzate
+funzioni di libreria per compiere le operazioni necessarie è garanzia
+sufficiente di atomicità in quanto le system call con cui esse sono realizzate
non possono essere interrotte (o subire interferenze pericolose) da altri
processi.
-Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
+Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
stesso processo, e pure alcune system call, possono essere interrotti in
qualunque momento, e le operazioni di un eventuale \textit{signal handler}
sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
-il solo accesso o l'assegnazione di una variabile possono non essere più
+il solo accesso o l'assegnazione di una variabile possono non essere più
operazioni atomiche (torneremo su questi aspetti in
sez.~\ref{sec:sig_adv_control}).
In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
-il cui accesso è assicurato essere atomico. In pratica comunque si può
-assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
+il cui accesso è assicurato essere atomico. In pratica comunque si può
+assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
\ctyp{int}, gli altri interi di dimensione inferiore ed i puntatori sono
-atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
-maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
-le strutture. In tutti questi casi è anche opportuno marcare come
+atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
+maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
+le strutture. In tutti questi casi è anche opportuno marcare come
\direct{volatile} le variabili che possono essere interessate ad accesso
condiviso, onde evitare problemi con le ottimizzazioni del codice.
Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
diversi operano su una risorsa comune, ed in cui il risultato viene a
dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso
-tipico è quello di un'operazione che viene eseguita da un processo in più
-passi, e può essere compromessa dall'intervento di un altro processo che
+tipico è quello di un'operazione che viene eseguita da un processo in più
+passi, e può essere compromessa dall'intervento di un altro processo che
accede alla stessa risorsa quando ancora non tutti i passi sono stati
completati.
-Dato che in un sistema multitasking ogni processo può essere interrotto in
-qualunque momento per farne subentrare un altro in esecuzione, niente può
+Dato che in un sistema multitasking ogni processo può essere interrotto in
+qualunque momento per farne subentrare un altro in esecuzione, niente può
assicurare un preciso ordine di esecuzione fra processi diversi o che una
sezione di un programma possa essere eseguita senza interruzioni da parte di
altri. Queste situazioni comportano pertanto errori estremamente subdoli e
difficili da tracciare, in quanto nella maggior parte dei casi tutto
-funzionerà regolarmente, e solo occasionalmente si avranno degli errori.
+funzionerà regolarmente, e solo occasionalmente si avranno degli errori.
Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
-che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
-gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di
+che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
+gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di
\textit{race condition} si hanno quando diversi processi accedono allo stesso
file, o nell'accesso a meccanismi di intercomunicazione come la memoria
-condivisa. In questi casi, se non si dispone della possibilità di eseguire
+condivisa. In questi casi, se non si dispone della possibilità di eseguire
atomicamente le operazioni necessarie, occorre che quelle parti di codice in
cui si compiono le operazioni sulle risorse condivise (le cosiddette
\index{sezione~critica} \textsl{sezioni critiche}) del programma, siano
Un caso particolare di \textit{race condition} sono poi i cosiddetti
\textit{deadlock}, particolarmente gravi in quanto comportano spesso il blocco
completo di un servizio, e non il fallimento di una singola operazione. Per
-definizione un \textit{deadlock} è una situazione in cui due o più processi
-non sono più in grado di proseguire perché ciascuno aspetta il risultato di
+definizione un \textit{deadlock} è una situazione in cui due o più processi
+non sono più in grado di proseguire perché ciascuno aspetta il risultato di
una operazione che dovrebbe essere eseguita dall'altro.
-L'esempio tipico di una situazione che può condurre ad un
-\textit{deadlock} è quello in cui un flag di
+L'esempio tipico di una situazione che può condurre ad un
+\textit{deadlock} è quello in cui un flag di
``\textsl{occupazione}'' viene rilasciato da un evento asincrono (come un
-segnale o un altro processo) fra il momento in cui lo si è controllato
+segnale o un altro processo) fra il momento in cui lo si è controllato
(trovandolo occupato) e la successiva operazione di attesa per lo sblocco. In
-questo caso, dato che l'evento di sblocco del flag è avvenuto senza che ce ne
+questo caso, dato che l'evento di sblocco del flag è avvenuto senza che ce ne
accorgessimo proprio fra il controllo e la messa in attesa, quest'ultima
-diventerà perpetua (da cui il nome di \textit{deadlock}).
+diventerà perpetua (da cui il nome di \textit{deadlock}).
-In tutti questi casi è di fondamentale importanza il concetto di atomicità
+In tutti questi casi è di fondamentale importanza il concetto di atomicità
visto in sez.~\ref{sec:proc_atom_oper}; questi problemi infatti possono essere
risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile
eseguire in maniera atomica le operazioni necessarie.
\index{funzioni!rientranti|(}
-Si dice \textsl{rientrante} una funzione che può essere interrotta in
+Si dice \textsl{rientrante} una funzione che può essere interrotta in
qualunque punto della sua esecuzione ed essere chiamata una seconda volta da
un altro \itindex{thread} \textit{thread} di esecuzione senza che questo
-comporti nessun problema nell'esecuzione della stessa. La problematica è
+comporti nessun problema nell'esecuzione della stessa. La problematica è
comune nella programmazione \itindex{thread} \textit{multi-thread}, ma si
hanno gli stessi problemi quando si vogliono chiamare delle funzioni
all'interno dei gestori dei segnali.
-Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
+Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
queste infatti vengono allocate nello \itindex{stack} \textit{stack}, ed
un'altra invocazione non fa altro che allocarne un'altra copia. Una funzione
-può non essere rientrante quando opera su memoria che non è nello
-\itindex{stack} \textit{stack}. Ad esempio una funzione non è mai rientrante
+può non essere rientrante quando opera su memoria che non è nello
+\itindex{stack} \textit{stack}. Ad esempio una funzione non è mai rientrante
se usa una variabile globale o statica.
Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
-cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
-ogni volta e ritornato indietro la funzione può essere rientrante, se invece
+cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
+ogni volta e ritornato indietro la funzione può essere rientrante, se invece
esso viene individuato dalla funzione stessa due chiamate alla stessa funzione
potranno interferire quando entrambe faranno riferimento allo stesso oggetto.
-Allo stesso modo una funzione può non essere rientrante se usa e modifica un
+Allo stesso modo una funzione può non essere rientrante se usa e modifica un
oggetto che le viene fornito dal chiamante: due chiamate possono interferire
se viene passato lo stesso oggetto; in tutti questi casi occorre molta cura da
parte del programmatore.
In genere le funzioni di libreria non sono rientranti, molte di esse ad
-esempio utilizzano variabili statiche, le \acr{glibc} però mettono a
+esempio utilizzano variabili statiche, le \acr{glibc} però mettono a
disposizione due macro di compilatore,\footnote{si ricordi quanto illustrato
in sez.~\ref{sec:intro_gcc_glibc_std}.} \macro{\_REENTRANT} e
\macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di
projects / gapil.git / blobdiff