X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileunix.tex;h=8a39680d6b15b37490483be0781370264c3ba0e3;hp=d5221ca500ea6330369c59035836f2e36d9b3b62;hb=4263734ffe237b1a7249c1f8121bb7ebe8b60a50;hpb=d34e0d693aad24483caafaf540b162323dd0ba21

diff --git a/fileunix.tex b/fileunix.tex
index d5221ca..8a39680 100644
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -295,10 +295,10 @@ sempre il file descriptor con il valore pi
 
 \footnotetext[2]{la pagina di manuale di \func{open} segnala che questa
   opzione è difettosa su NFS, e che i programmi che la usano per stabilire un
-  file di lock (vedi \secref{sec:ipc_file_lock}) possono incorrere in una race
+  \textsl{file di lock}\index{file di lock} possono incorrere in una race
   condition\index{race condition}.  Si consiglia come alternativa di usare un
   file con un nome univoco e la funzione \func{link} per verificarne
-  l'esistenza.}
+  l'esistenza (vedi \secref{sec:ipc_file_lock}).}
 
 \footnotetext[3]{\textit{Denial of Service}, si chiamano così attacchi miranti
   ad impedire un servizio causando una qualche forma di carico eccessivo per
@@ -767,7 +767,7 @@ problema, quando si andr
 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}).
+  locking}, che esamineremo in \secref{sec:file_locking}).
 
 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
@@ -789,17 +789,19 @@ avviene all'interno di una singola system call (la \func{write}) che non
 essendo interrompibile da un altro processo costituisce un'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\index{race condition} da parte di un altro
-processo che crea lo stesso file fra il controllo e la creazione.
+creare un \textsl{file di lock}\index{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\index{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 per \func{open} i due flag
 \macro{O\_CREAT} e \macro{O\_EXCL}. In questo modo l'operazione di controllo
 dell'esistenza del file (con relativa uscita dalla funzione con un errore) e
 creazione in caso di assenza, diventa atomica essendo svolta tutta all'interno
-di una singola system call.
+di una singola system call (per i dettagli sull'uso di questa caratteristica
+si veda \secref{sec:ipc_file_lock}).
 
 
 \subsection{La funzioni \func{sync} e \func{fsync}}