Aggiunte minimali

[gapil.git] / prochand.tex

diff --git a/prochand.tex b/prochand.tex
index 41d7a348c2e7a9702ea2f4a97d2786cc41e66d1f..22da5c0194b660c71df60ba5a39403221ef5c9c3 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -282,10 +282,10 @@ 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 2 secondi e scrivere un messaggio prima
+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:
+comando otterremo come output sul terminale:
 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest 5
 Test for forking 5 child
@@ -306,26 +306,33 @@ 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
   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à dalla situazione particolare in si trova la macchina al momento
-della chiamata, risultando del tutto impredicibile, per questo motivo se i due
-processi devono essere sincronizzati occorrerà ricorrere ad un opportuno
-meccanismo di intercomunicazione.
-
-Si ricordi inoltre che, 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.
-
-
+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}}