Rifinitura degli indici, correzioni ortografiche varie.
[gapil.git] / prochand.tex
index 0bcc2a0..f3be05d 100644 (file)
@@ -646,7 +646,7 @@ le differenze fra padre e figlio dopo la \func{fork} invece sono:
   impostato al \acr{pid} del padre.
 \item i valori dei tempi di esecuzione della struttura \var{tms} (vedi
   \secref{sec:sys_cpu_times}) che nel figlio sono posti a zero.
-\item i \textit{file lock} (vedi \secref{sec:file_locking}), che non
+\item i \textit{lock} sui file (vedi \secref{sec:file_locking}), che non
   vengono ereditati dal figlio.
 \item gli allarmi ed i segnali pendenti (vedi \secref{sec:sig_gen_beha}), che
   per il figlio vengono cancellati.
@@ -816,35 +816,35 @@ otterremo:
   571 pts/0    Z      0:00 [forktest <defunct>]
   572 pts/0    R      0:00 ps T
 \end{verbatim} %$
-\normalsize 
-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 zombie e l'indicazione che sono stati terminati.
-
-La possibilità di avere degli 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
+\normalsize 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 zombie\index{zombie} e l'indicazione che sono stati
+terminati.
+
+La possibilità di avere degli zombie\index{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 \secref{sec:sig_sigchld} e \secref{sec:proc_wait}). Questa
-operazione è necessaria perché anche se gli \textit{zombie} non consumano
-risorse di memoria o processore, occupano comunque una voce nella tabella dei
-processi, che a lungo andare potrebbe esaurirsi.
+operazione è necessaria perché anche se gli \textit{zombie}\index{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 \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 zombie: alla sua terminazione infatti tutti i suoi figli
-(compresi gli zombie) verranno adottati da \cmd{init}, il quale provvederà a
-completarne la terminazione.
+diviene uno \textit{zombie}\index{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 zombie\index{zombie}: alla sua terminazione
+infatti tutti i suoi figli (compresi gli zombie\index{zombie}) verranno
+adottati da \cmd{init}, il quale provvederà a completarne la terminazione.
 
-Si tenga presente infine che siccome gli 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 terminare il processo che
-li ha generati, in modo che \cmd{init} possa adottarli e provvedere a
-concluderne la terminazione.
+Si tenga presente infine che siccome gli zombie\index{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 terminare il
+processo che li ha generati, in modo che \cmd{init} possa adottarli e
+provvedere a concluderne la terminazione.
 
 
 \subsection{Le funzioni \func{wait} e  \func{waitpid}}
@@ -855,8 +855,8 @@ 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
 caso diventi necessario gestire esplicitamente la conclusione dei figli onde
-evitare di riempire di \textit{zombie} la tabella dei processi; le funzioni
-deputate a questo compito sono sostanzialmente due, \func{wait} e
+evitare di riempire di \textit{zombie}\index{zombie} la tabella dei processi;
+le funzioni deputate a questo compito sono sostanzialmente due, \func{wait} e
 \func{waitpid}. La prima, il cui prototipo è:
 \begin{functions}
 \headdecl{sys/types.h}
@@ -971,12 +971,13 @@ kernel avverte il processo padre che uno dei suoi figli 
 
 In genere in un programma non si vuole essere forzati ad attendere la
 conclusione di un processo per proseguire, specie se tutto questo serve solo
-per leggerne lo stato di chiusura (ed evitare la presenza di \textit{zombie}),
-per questo la modalità più usata per 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 \secref{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{wait} non si bloccherà.
+per leggerne lo stato di chiusura (ed evitare la presenza di
+\textit{zombie}\index{zombie}), per questo la modalità più usata per 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 \secref{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{wait} non si bloccherà.
 
 \begin{table}[!htb]
   \centering
@@ -1916,17 +1917,21 @@ fintanto che esso si trova in uno qualunque degli altri stati.
     \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 venga assegnata la CPU).   \\
-    \textbf{Sleep} & \texttt{S} & Il processo processo è in attesa di un
-    risposta dal sistema, ma può essere interrotto da un segnale. \\
-    \textbf{Uninterrutible Sleep} & \texttt{D} & Il  processo è in
-    attesa di un risposta dal sistema (in genere per I/O), e non può essere
-    interrotto in nessuna circostanza. \\
+    \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 processo è in attesa di un
+                                    risposta dal sistema, ma può essere 
+                                    interrotto da un segnale. \\
+    \textbf{Uninterrutible Sleep}& \texttt{D} & Il  processo è in
+                                    attesa di un risposta dal sistema (in 
+                                    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} & \texttt{Z} & Il processo è terminato ma il suo stato di
-    terminazione non è ancora stato letto dal padre. \\
+                                    \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. \\
     \hline
   \end{tabular}
   \caption{Elenco dei possibili stati di un processo in Linux, nella colonna
@@ -2437,7 +2442,7 @@ condiviso, onde evitare problemi con le ottimizzazioni del codice.
 
 
 \subsection{Le \textit{race condition}\index{race condition} e i 
-  \textit{deadlock}}
+  \textit{deadlock}\index{deadlock}}
 \label{sec:proc_race_cond}
 
 Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
@@ -2469,20 +2474,22 @@ opportunamente protette da meccanismi di sincronizzazione (torneremo su queste
 problematiche di questo tipo in \capref{cha:IPC}).
 
 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
-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 ``occupazione'' viene rilasciato da un evento
-asincrono (come un 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 accorgessimo proprio fra il controllo e la messa in attesa,
-quest'ultima diventerà perpetua (da cui il nome di \textit{deadlock}).
+\textit{deadlock}\index{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}\index{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}\index{deadlock} è quello in cui un flag di ``occupazione''
+viene rilasciato da un evento asincrono (come un 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 accorgessimo proprio
+fra il controllo e la messa in attesa, quest'ultima diventerà perpetua (da cui
+il nome di \textit{deadlock}\index{deadlock}).
 
 In tutti questi casi è di fondamentale importanza il concetto di atomicità
 visto in \secref{sec:proc_atom_oper}; questi problemi infatti possono essere