alternativi.
La prima possibilità, utilizzata fin dalle origini di Unix, è quella di usare
-dei \textsl{file di lock} (per i quali esiste anche una opportuna directory,
-\file{/var/lock}, nel filesystem standard). Per questo si usa la
-caratteristica della funzione \func{open} (illustrata in
+dei \textsl{file di lock}\index{file di lock} (per i quali esiste anche una
+opportuna directory, \file{/var/lock}, nel filesystem standard). Per questo si
+usa la caratteristica della funzione \func{open} (illustrata in
\secref{sec:file_open}) che prevede\footnote{questo è quanto dettato dallo
standard POSIX.1, ciò non toglie che in alcune implementazioni questa
tecnica possa non funzionare; in particolare per Linux, nel caso di NFS, si
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.}
+ esistente; se il link esiste già e la funzione fallisce, 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 si 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
-\textit{polling}\index{polling}, che è molto inefficiente.
-
-Per questo motivo la tecnica alternativa più pulita è quella di fare ricorso
-al \textit{file locking} trattato in \secref{sec:file_locking} ed utilizzare
-\func{fcntl} su un file creato per l'occasione 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 determinare la disponibilità della
-risorsa, e al rilascio della stessa da parte del processo che la occupava si
-otterrà il nuovo lock atomicamente.
+una alternativa praticabile per la sincronizzazione: 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 \textit{polling}\index{polling}, che è molto
+inefficiente.
+
+La tecnica può comunque essere 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 si trovi un
+file di lock il programma che cerca di accedere alla seriale si limita a
+segnalare che la risorsa non è disponibile; sempre in \file{wrapper.h} si sono
+predisposte due funzioni, \func{LockFile} e \func{UnlockFile}, da utilizzare
+allo scopo.
+
+Dato che i file di lock presentano gli inconvenienti illustrati in precedenza,
+la tecnica alternativa più comune è quella di fare ricorso al \textit{file
+ locking} (trattato in \secref{sec:file_locking}) usando \func{fcntl} su un
+file creato per l'occasione 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
+determinare la disponibilità 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 permanentemente allocate nel sistema, lo svantaggio è che
+chiusura dei relativi file) e non ci si deve preoccupare di niente, inoltre
+non consuma risorse permanentemente allocate nel sistema, lo svantaggio è che
dovendo fare ricorso a delle operazioni sul filesystem esso è in genere
leggermente più lento.
-Il codice per implementare un mutex utilizzando il file locking è riportato in
+\begin{figure}[!bht]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}{}
+
+ \end{lstlisting}
+ \end{minipage}
+ \normalsize
+ \caption{Il codice delle funzioni che permettono di creare un
+ \textit{mutex} utilizzando il file locking.}
+ \label{fig:ipc_flock_mutex}
+\end{figure}
+Il codice per implementare un mutex utilizzando il file locking è riportato in
+\figref{fig:ipc_flock_mutex}; come nel precedente caso dei mutex implementato
+con i semafori le funzioni sono tre
utilizzabili con Linux è quella del \textit{memory mapping}
anonimo\footnote{in altri sistemi una funzionalità simile a questa viene
implementata mappando il file speciale \file{/dev/zero}.}, in tal caso
-infatti
+infatti
\section{La comunicazione fra processi di POSIX}