-il rilascio si può eseguire con una chiamata ad \func{unlink}.
-
-Questa tecnica ha però parecchi problemi, che non la rendono una alternativa
-praticabile; anzitutto anche in questo caso in caso di terminazione imprevista
-del processo lascia allocata la risorsa (il file di lock) che deve comunque
-essere cancellata esplicitamente. Inoltre il controllo della disponibilità può
-essere fatto solo con una tecnica di polling, che è molto inefficiente.
-Modalità alternative prevedono l'uso di \func{link}, che fallisce se il nome
-esiste già, ma i problemi sono gli stessi.
-
-Per questo motivo la tecnica più pulita è quella di utilizzare \func{fcntl} su
-un file creato per l'occazione per ottenere un write lock sul primo byte del
-file (che non è detto debba esistere); in questo modo potremo usare il lock
-come un \textit{mutex}: per bloccare la risorsa basterà acquisire il lock, per
-sbloccarla basterà rilasciare il lock; l'accesso sarà controllabile, senza
-necessità di ricorrere al \textit{polling}\index{polling}.
-
-
-
-Una possibile alternativa all'uso dei semafori come meccanismo di
-sincronizzazione è quello di fare ricorso al \textit{file locking} visto in
-\secref{sec:file_locking}.
+il rilascio si può eseguire con una chiamata ad
+\func{unlink}.\footnote{abbiamo già accennato in \secref{sec:file_open} che
+ questa tecnica può non funzionare se il filesystem su cui si va ad operare è
+ su NFS; in tal caso si può adottare una tecnica alternativa che prevede
+ l'uso di \func{link} per creare come file di lock un hard link ad un file
+ esistente; se il link esiste già e la funzione fallisce, la risorsa
+ significa che la risorsa è bloccata e potrà essere sbloccata solo con un
+ \func{unlink}, altrimenti il link è creato ed il lock acquisito; il
+ controllo e l'eventuale acquisizione sono atomici; il difetto di questa
+ soluzione è che funziona solo se si opera all'interno di uno stesso
+ filesystem.}
+
+L'uso di un file di lock presenta però parecchi problemi, che non lo rendono
+una alternativa praticabile per la sincronizzazione:\footnote{ma può essere
+ una tecnica usata con successo quando l'esigenza è solo quella di segnalare
+ l'occupazione di una risorsa, senza necessità di attendere che questa si
+ liberi; ad esempio la si usa spesso per evitare interferenze sull'uso delle
+ porte seriali da parte di più programmi: qualora trovi un file di lock il
+ programma che cerca di accedere alla seriale si limita a segnalare che la
+ risorsa non è disponibile.} anzitutto anche in questo caso in caso di
+terminazione imprevista del processo lascia allocata la risorsa (il file di
+lock) e questa deve essere sempre cancellata esplicitamente. Inoltre il
+controllo della disponibilità può essere fatto solo con una tecnica di
+polling\index{polling}, che è molto inefficiente.
+
+Per questo motivo la tecnica alternativa più pulita è quella di fare ricorso
+al \textit{file locking} visto in \secref{sec:file_locking} ed utilizzare
+\func{fcntl} su un file creato per l'occazione per ottenere un write lock; in
+questo modo potremo usare il lock come un \textit{mutex}: per bloccare la
+risorsa basterà acquisire il lock, per sbloccarla basterà rilasciare il lock;
+una richiesta fatta con un write lock metterà automaticamente il processo in
+stato di attesa, senza necessità di ricorrere al
+\textit{polling}\index{polling} per determimanare la dispobilità della
+risorsa, e al rilascio della stessa da parte del processo che la occupava si
+otterrà il nuovo lock atomicamente.
+
+Questo approccio presenta il notevole vantaggio che alla terminazione di un
+processo tutti i lock acquisiti vengono rilasciati automaticamente (alla
+chiusura dei relativi file) e non ci si deve preoccupare di niente, e non
+consuma risorse di sistema, lo svantaggio è che dovendo fare ricorso a delle
+operazioni sul filesystem esso è in genere leggermente più lento.