X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=7bf418608b81f17be4eaf00503d9878574f86576;hp=ce4842e602ec37500c52304567dc7bc919a4b483;hb=78a82bdb333ca71e395ba39a5c03745761341150;hpb=4263734ffe237b1a7249c1f8121bb7ebe8b60a50

diff --git a/ipc.tex b/ipc.tex
index ce4842e..7bf4186 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -2968,38 +2968,56 @@ il rilascio si pu
   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
 
 
 
@@ -3012,7 +3030,7 @@ contenuto di un file nella memoria di un processo. Una della opzioni possibili
 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}