Correzioni minime

[gapil.git] / prochand.tex

diff --git a/prochand.tex b/prochand.tex
index 59eb4042a70957ff77e3324727dbccd860733f8b..22da5c0194b660c71df60ba5a39403221ef5c9c3 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -208,25 +208,131 @@ ritorno della funzione fork 
 figlio è zero; in questo modo il programma può identificare se viene eseguito
 dal padre o dal figlio.
 
 figlio è zero; in questo modo il programma può identificare se viene eseguito
 dal padre o dal figlio.
 

-Si noti come la funzione \fucn{fork} ritorni \textbf{due} volte: nel padre e
-nel figlio. La sola differenza che si ha nei due processi è il valore di
+\begin{figure}[!htb]
+  \footnotesize
+  \begin{lstlisting}{}
+#include <errno.h>       /* error definitions and routines */ 
+#include <stdlib.h>      /* C standard library */
+#include <unistd.h>      /* unix standard library */
+#include <stdio.h>       /* standard I/O library */
+#include <string.h>      /* string functions */
+
+/* Help printing routine */
+void usage(void);
+
+int main(int argc, char *argv[])
+{
+/* 
+ * Variables definition  
+ */
+    int i;
+    int nchild;
+    pid_t pid;
+
+    ...        /* handling options */
+
+    /* There must be remaing parameters */
+    if (optind == argc) {
+        usage();
+    }
+    nchild = atoi(argv[optind]);
+    printf("Test for forking %d child\n", nchild);
+    /* loop to fork children */
+    for (i=0; i<nchild; i++) {
+        if ( (pid = fork()) < 0) {
+            printf("Error on %d child creation, %s\n", i, strerror(errno));
+        }
+        if (pid == 0) {   /* child */
+            printf("Child %d successfully executing\n", i++);
+            sleep(2);
+            printf("Child %d exiting\n", i);
+            exit(0);
+        } else {          /* parent */
+            printf("Spawned %d child, pid %d \n", i, pid);
+        }
+    }
+    /* normal exit */
+    return 0;
+}
+  \end{lstlisting}
+  \caption{Esempio di codice per la creazione di nuovi processi.}
+  \label{fig:proc_fork_code}
+\end{figure}
+
+Si noti come la funzione \func{fork} ritorni \textbf{due} volte: una nel padre
+e una nel figlio. La sola differenza che si ha nei due processi è il valore di

 ritorno restituito dalla funzione, che nel padre è il \acr{pid} del figlio
 mentre nel figlio è zero; in questo modo il programma può identificare se
 ritorno restituito dalla funzione, che nel padre è il \acr{pid} del figlio
 mentre nel figlio è zero; in questo modo il programma può identificare se

-viene eseguito dal padre o dal figlio. La scelta di questi valori comunque non
-è casuale, un processo infatti può avere più figli, ed il valore di ritorno di
-\func{fork} è l'unico modo che permette di idenficare quello appena creato; al
-contrario un figlio ha sempre un solo padre (il cui \acr{pid} può sempre
-essere ottenuto con \func{getppid}, vista in \secref{sec:proc_pid}) e si usa
-il valore nullo, che non può essere il \acr{pid} di nessun processo.
-
-In generale non si può dire se il quale fra il padre ed il figlio venga
-eseguito per primo\footnote{anche se nel kernel 2.4.x è stato introdotto un
+viene eseguito dal padre o dal figlio. 
+
+La scelta di questi valori comunque non è casuale, un processo infatti può
+avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che
+permette di identificare quello appena creato; al contrario un figlio ha
+sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
+\func{getppid}, vista in \secref{sec:proc_pid}) e si usa il valore nullo, che
+non può essere il \acr{pid} di nessun processo.
+
+In \curfig\ si è riportato il corpo del codice dell'esempio \cmd{forktest},
+che ci permette di illustrare l'uso della funzione \func{fork}, creando un
+numero di figli specificato a linea di comando; il codice completo, compresa
+la parte che gestisce le opzioni a riga di comando, è disponibile nel file
+\file{ForkTest.c}.
+
+Decifrato il numero di figli da creare, il ciclo principale del programma
+(\texttt{\small 28--40}) esegue in successione la creazione dei processi figli
+controllando il successo della chiamata a \func{fork} (\texttt{\small
+  29--31}); ciascun figlio (\texttt{\small 29--31}) si limita a stampare il
+suo numero di successione, attendere 3 secondi e scrivere un messaggio prima
+di uscire. Il processo padre invece (\texttt{\small 29--31}) stampa un
+messaggio di creazione e procede nell'esecuzione del ciclo. Se eseguiamo il
+comando otterremo come output sul terminale:
+\begin{verbatim}
+[piccardi@selidor sources]$ ./forktest 5
+Test for forking 5 child
+Spawned 1 child, pid 840 
+Child 1 successfully executing
+Child 2 successfully executing
+Spawned 2 child, pid 841 
+Spawned 3 child, pid 842 
+Child 3 successfully executing
+Spawned 4 child, pid 843 
+Child 4 successfully executing
+Child 5 successfully executing
+Spawned 5 child, pid 844 
+[piccardi@selidor sources]$ Child 2 exiting
+Child 1 exiting
+Child 4 exiting
+Child 3 exiting
+Child 5 exiting
+\end{verbatim}
+
+Come si vede non si può dire quale processo fra il padre ed il figlio venga
+eseguito per primo\footnote{anche se nel kernel 2.4.x era stato introdotto un

   meccanismo che metteva in esecuzione sempre il xxx per primo (TODO
   meccanismo che metteva in esecuzione sempre il xxx per primo (TODO

-  recuperare le informazioni esatte)}, per cui se i due processi devono essere
-sincronizzati occorre ricorrere ad un qualche meccanismo di
-intercomunicazione.
-
-
+  recuperare le informazioni esatte)} dopo la chiamata a \func{fork}, nel caso
+mostrato sopra ad esempio si può notare come dopo la creazione il secondo ed
+il quinto figlio sia stato stati eseguiti per primi, mantre per gli altri
+figli è stato eseguito per primo il padre. 
+
+In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
+scheduling usato dal kernel, dalla particolare situazione in si trova la
+macchina al momento della chiamata, risultando del tutto impredicibile.
+Eseguendo più volte il programma di prova, si sono ottenute situazioni
+completamente diverse, compreso 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, e se è necessaria una qualche forma
+di precedenza occorrerà provvedere ad espliciti meccanismi di
+sincronizzazione, pena il rischio di incorrere nelle cosiddette \textit{race
+  conditions}.
+
+Si ricordi inoltre che come accennato, essendo i segmenti di memoria
+utilizzati dai singoli processi completamente separati, le modifiche delle
+variabili nei processi figli (come l'incremento di \var{i} in \texttt{\small
+  33}) saranno effettive solo per essi, e non hanno alcun effetto sul valore
+che le stesse variabili hanno nel processo padre.

 
 
 \subsection{Le funzioni \texttt{wait} e  \texttt{waitpid}}
 
 
 \subsection{Le funzioni \texttt{wait} e  \texttt{waitpid}}