Correzioni ulteriori, segnalate da Vosti.

diff --git a/fileadv.tex b/fileadv.tex
index 222fcaefe2258967239008ab6dfd71c3ebc482e6..9d084a86285ba36c4018a419088209987e2172cd 100644 (file)
--- a/fileadv.tex
+++ b/fileadv.tex
@@ -1,5 +1,5 @@
 \chapter{I/O avanzato}
 \chapter{I/O avanzato}

-\label{sec:file_advanced}
+\label{cha:file_advanced}

 
 
 
 
 
 

diff --git a/filedir.tex b/filedir.tex
index be2d5c67cf2de5f3dd1927e39ac09b060993bb5f..04c30b31a31bad29e45fd5dd445d8a9097e86664 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -142,9 +142,9 @@ restrizioni 
 
 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
 della nome dalla directory e l'incremento/decremento del numero di riferimenti
 
 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
 della nome dalla directory e l'incremento/decremento del numero di riferimenti

-nell'inode deve essere una operazione atomica (cioè non interrompibile da
-altri processi), per questo entrambe queste funzioni sono realizzate tramite
-una singola system call.
+nell'inode deve essere una operazione atomica (si veda
+\secref{cha:proc_atom_oper}), per questo entrambe queste funzioni sono
+realizzate tramite una singola system call.

 
 Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
 i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
 
 Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
 i riferimenti ad esso sono stati cancellati, solo quando il \textit{link

diff --git a/fileunix.tex b/fileunix.tex
index 7ae7ce633e5cd39b040b2c48cbabe2d71147afde..3001194b17762a7e3b4c5d321e6e9e98d873fe28 100644 (file)
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -297,16 +297,16 @@ cio
 
 \footnotetext[3]{Denial of Service, si chiamano così attacchi miranti ad
   impedire un servizio causando una qualche forma di carico eccessivo per il
 
 \footnotetext[3]{Denial of Service, si chiamano così attacchi miranti ad
   impedire un servizio causando una qualche forma di carico eccessivo per il

-  sistema, che resta bloccato nelle risposte all'attacco}
+  sistema, che resta bloccato nelle risposte all'attacco.}

 
 \footnotetext[4]{il problema è che NFS non supporta la scrittura in append, ed
   il kernel deve simularla, ma questo comporta la possibilità di una race
 
 \footnotetext[4]{il problema è che NFS non supporta la scrittura in append, ed
   il kernel deve simularla, ma questo comporta la possibilità di una race

-  condition}
+  condition, vedi \secref{sec:file_atomic}.}

 
 \footnotetext[5]{l'opzione origina da SVr4, dove però causava il ritorno da
   una \func{read} con un valore nullo e non con un errore, questo introduce
   una ambiguità, dato che come vedremo in \secref{sec:file_read} il ritorno di
 
 \footnotetext[5]{l'opzione origina da SVr4, dove però causava il ritorno da
   una \func{read} con un valore nullo e non con un errore, questo introduce
   una ambiguità, dato che come vedremo in \secref{sec:file_read} il ritorno di

-  zero da parte di \func{read} ha il significato di una end-of-file}
+  zero da parte di \func{read} ha il significato di una end-of-file.}

 
 
 Il nuovo file descriptor non è condiviso con nessun altro processo, (torneremo
 
 
 Il nuovo file descriptor non è condiviso con nessun altro processo, (torneremo


@@ -465,9 +465,8 @@ Si tenga presente inoltre che usare \macro{SEEK\_END} non assicura affatto che
 successiva scrittura avvenga alla fine del file, infatti se questo è stato
 aperto anche da un altro processo che vi ha scritto, la fine del file può
 essersi spostata, ma noi scriveremo alla posizione settata in precedenza.
 successiva scrittura avvenga alla fine del file, infatti se questo è stato
 aperto anche da un altro processo che vi ha scritto, la fine del file può
 essersi spostata, ma noi scriveremo alla posizione settata in precedenza.

-Questa è una potenziale sorgente di \textit{race condition}, e quando si vuole
-essere sicuri di scrivere alla fine del file questo deve essere posto in
-modalità \macro{O\_APPEND}.
+(questa è una potenziale sorgente di \textit{race condition}, vedi
+\secref{sec:file_atomic}).

 
 Non tutti i file supportano la capacità di eseguire una \func{lseek}, in
 questo caso la funzione ritorna l'errore \macro{EPIPE}. Questo, oltre che per
 
 Non tutti i file supportano la capacità di eseguire una \func{lseek}, in
 questo caso la funzione ritorna l'errore \macro{EPIPE}. Questo, oltre che per


@@ -726,11 +725,43 @@ vengono toccati anche in caso di condivisione della voce della \textit{file
 
 Come si è visto in un sistema unix è sempre possibile per più processi
 accedere in contemporanea allo stesso file, e che le operazioni di lettura e
 
 Come si è visto in un sistema unix è sempre possibile per più processi
 accedere in contemporanea allo stesso file, e che le operazioni di lettura e

-scrittura saranno fatte in base alla posizione corrente nel file. Ovviamente
-senza prevedere opportuni meccanismi di sincronizzazione le operazioni
-potranno mescolarsi in maniera imprevedibile. L'unica garanzia è che se si è
-in modalità \macro{O\_APPEND} il sistema assicura che si scriva (con il
-procedimento appena esposto) sempre alla fine del file.
+scrittura possono essere fatte da ogni processo in maniera autonoma in base
+ad una posizione corrente nel file che è locale a ciascuno di essi.
+
+Se dal punto di vista della lettura dei dati questo non comporta nessun
+problema, quando si andrà a scrivere le operazioni potranno mescolarsi in
+maniera imprevedibile.  Il sistema però fornisce in alcuni casi la possibilità
+di eseguire alcune operazioni di scrittura in maniera coordinata anche senza
+utilizzare meccanismi di sincronizzazione più complessi (come il \textit{file
+  locking}, che esamineremo in \secref{cha:file_advanced}).
+
+Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui
+vari processi devono scrivere alla fine di un file (ad esempio un file di
+log). Come accennato in \secref{sec:file_lseek} settare la posizione alla fine
+del file e poi scrivere può condurre ad una \textit{race condition}: infatti
+può succedere che un secondo processo scriva alla fine del file fra la
+\func{lseek} e la \func{write}; in questo caso, come abbiamo appena visto, il
+file sarà esteso, ma il nostro primo processo avrà ancora la posizione
+corrente settata con la \func{lseek} che non corrisponde più alla fine del
+file, e la successiva \func{write} sovrascriverà i dati del secondo processo.
+
+Il problema è che usare due system call in successione non è una operazione
+atomica; il problema è stato risolto introducendo la modalità
+\macro{O\_APPEND}, in questo caso infatti, come abbiamo visto, è il kernel che
+aggiorna automaticamente la posizione alla fine del file prima di effettuare
+la scrittura, e poi estende il file. Tutto questo avviene all'interno di una
+singola system call (la \func{write}) che non essendo interrompibile da un
+altro processo costituisce una operazione atomica.
+
+Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
+creare un file di lock, bloccandosi se il file esiste. In questo caso la
+sequenza logica porterebbe a verificare prima l'esistenza del file con una
+\func{stat} per poi crearlo con una \func{creat}; di nuovo avremmo la
+possibilità di una race condition da parte di un altro processo che crea lo
+stesso file fra il controllo e la creazione.
+
+Per questo motivo sono stati introdotti i flag \macro{O\_CREAT}
+\macro{O\_EXCL}

 
 
 
 
 
 

diff --git a/prochand.tex b/prochand.tex
index f5decd7429d5e028e978b0980fef1d5961f26f57..2316a5b693dac5fced1752ba66a6f93aa6794716 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -1690,11 +1690,11 @@ non possono essere interrotte (o subire interferenze pericolose) da altri
 processi.
 
 Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
 processi.
 
 Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo

-stesso processo può essere interrotto in qualunque momento, e le operazioni di
-un eventuale \textit{signal handler} saranno compiute nello stesso spazio di
-indirizzi. Per questo anche solo il solo accesso o l'assegnazione di una
-variabile possono non essere più operazioni atomiche (torneremo su questi
-aspetti in \secref{sec:sign_xxx}).
+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
+solo il solo accesso o l'assegnazione di una variabile possono non essere più
+operazioni atomiche (torneremo su questi aspetti in \secref{sec:sign_xxx}).

 
 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ò
 
 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ò


@@ -1728,9 +1728,9 @@ condivise siano opportunamente protette da meccanismi di sincronizzazione
 Un caso particolare di \textit{race condition} sono poi i cosiddetti
 \textit{deadlock}; l'esempio tipico è quello di un flag di ``occupazione'' che
 viene rilasciato da un evento asincrono fra il controllo (in cui viene trovato
 Un caso particolare di \textit{race condition} sono poi i cosiddetti
 \textit{deadlock}; l'esempio tipico è quello di un flag di ``occupazione'' che
 viene rilasciato da un evento asincrono fra il controllo (in cui viene trovato

-occupato) e la successiva messa in attesa, attesa che a questo punto diventerà
+occupato) e la successiva messa in attesa, che a questo punto diventerà

 perpetua (da cui il nome di \textit{deadlock}) in quanto l'evento di sblocco
 perpetua (da cui il nome di \textit{deadlock}) in quanto l'evento di sblocco

-di questa è stato perso.
+del flag è stato perso fra il controllo e la messa in attesa.

 
 
 \subsection{Le funzioni rientranti}
 
 
 \subsection{Le funzioni rientranti}