Correzioni e commenti ai mutex con il file locking

[gapil.git] / ipc.tex

diff --git a/ipc.tex b/ipc.tex
index 6cb8cc482a4bdbd2811d480609a84c2f882b8854..4613f8d912cdb0b9d81e4ee8dd5a65f1002906d3 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -3364,23 +3364,23 @@ disponibile.\index{file!di lock|)}
 \subsection{La sincronizzazione con il \textit{file locking}}
 \label{sec:ipc_lock_file}
 
 \subsection{La sincronizzazione con il \textit{file locking}}
 \label{sec:ipc_lock_file}
 

-Dato che i file di lock presentano gli inconvenienti illustrati in precedenza,
-la tecnica alternativa di sincronizzazione più comune è quella di fare ricorso
-al \textit{file locking}\index{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.
+Dato che i file di lock\index{file!di lock} presentano gli inconvenienti
+illustrati in precedenza, la tecnica alternativa di sincronizzazione più
+comune è quella di fare ricorso al \textit{file locking}\index{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
 
 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, inoltre
-non consuma risorse permanentemente allocate nel sistema, lo svantaggio è che
-dovendo fare ricorso a delle operazioni sul filesystem esso è in genere
+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.
 
 \begin{figure}[!htb]
 leggermente più lento.
 
 \begin{figure}[!htb]


@@ -3446,37 +3446,59 @@ int ReadMutex(int fd)
     \end{lstlisting}
   \end{minipage} 
   \normalsize 
     \end{lstlisting}
   \end{minipage} 
   \normalsize 

-  \caption{Il codice delle funzioni che permettono di creare un
-    \textit{mutex} utilizzando il file locking\index{file!locking}.}
+  \caption{Il codice delle funzioni che permettono per la gestione dei 
+    \textit{mutex} con il file locking\index{file!locking}.}

   \label{fig:ipc_flock_mutex}
 \end{figure}
 
   \label{fig:ipc_flock_mutex}
 \end{figure}
 

-Il codice delle varie funzioni definite per implementare un mutex utilizzando
-il file locking\index{file!locking} è riportato in
-\figref{fig:ipc_flock_mutex}; si è mantenuta una struttura analoga a quelle
-viste in precedenza, anche se le due interfacce non possono essere
-completamente equivalenti, specie per quanto riguarda la rimozione del mutex.
-
-
-
-
-La prima funzione (\texttt{\small 1--22}) serve per acquisire il mutex.
-Anzitutto si apre (\texttt{\small 9--11}), creandolo se non esiste, il file
-specificato dall'argomento \param{pathname}. In caso di errore si ritorna
-immediatamente, altrimenti si prosegue impostando (\texttt{\small 12--16}) la
-struttura \var{lock} in modo da poter acquisire un write lock sul file.
-Infine si richiede (\texttt{\small 17--20}) il file lock (restituendo il
-codice di ritorno di \func{fcntl} caso di errore). Se il file è libero il lock
-è acquisito e la funzione ritorna immediatamente; altrimenti \func{fcntl} si
-bloccherà (si noti che la si è chiamata con \func{F\_SETLKW}) fino al rilascio
-del lock.
-
-La seconda funzione (\texttt{\small 23--44}) serve a rilasciare il mutex. Di
-nuovo si apre (\texttt{\small 30--33}) il file specificato dall'argomento
-\param{pathname} (che stavolta deve esistere), ritornando immediatamente in
-caso di errore. Poi si passa ad inizializzare (\texttt{\small 34--38}) la
-struttura \var{lock} per il rilascio del lock, che viene effettuato
-(\texttt{\small 39--42}) subito dopo.
+Il codice delle varie funzioni usate per implementare un mutex utilizzando il
+file locking\index{file!locking} è riportato in \figref{fig:ipc_flock_mutex};
+si è mantenuta volutamente una struttura analoga alle precedenti funzioni che
+usano i semafori, anche se le due interfacce non possono essere completamente
+equivalenti, specie per quanto riguarda la rimozione del mutex.
+
+La prima funzione (\texttt{\small 1--5}) è \func{CreateMutex}, e serve a
+creare il mutex; la funzione è estremamente semplice, si limita
+(\texttt{\small 4}) a creare, con una opportuna chiamata ad \func{open}, il
+file che sarà usato per il successivo file locking, assicurandosi che non
+esista già (nel qual caso segnala un errore); poi restituisce il file
+descriptor che sarà usato dalle altre funzioni per acquisire e rilasciare il
+mutex.  
+
+La seconda funzione (\texttt{\small 6--10}) è \func{FindMutex}, che, come la
+precedente, si è definita solo per mantenere una analogia con l'analoga
+funzione basata sui semafori, anch'essa si limita (\texttt{\small 9}) ad
+aprire il file da usare per il file locking, solo che in questo caso le
+opzioni di \func{open} sono tali che il file in questione deve esistere di
+già.
+
+La terza funzione (\texttt{\small 11--23}) è \func{LockMutex} e serve per
+acquisire il mutex. La funzione definisce (\texttt{\small 14} e inizializza
+(\texttt{\small 17--20}) la struttura \var{lock} per poter acquisire un write
+lock sul file, che poi (\texttt{\small 21}) viene richiesto con \func{fcntl}
+(restituendo il codice di ritorno). Se il file è libero il lock è acquisito e
+la funzione ritorna immediatamente; altrimenti \func{fcntl} si bloccherà (si
+noti che la si è chiamata con \func{F\_SETLKW}) fino al rilascio del lock.
+
+La quarta funzione (\texttt{\small 24--35}) è \func{UnlockMutex} e serve a
+rilasciare il mutex. La funzione è analoga alla precedente, solo che in questo
+caso si inizializza (\texttt{\small 29--32}) la struttura \var{lock} per il
+rilascio del lock, che viene effettuato (\texttt{\small 34}) con la opportuna
+chiamata a \func{fcntl}.
+
+La quinta funzione \texttt{\small 36--40}) è \func{RemoveMutex} e serve a
+cancellare il mutex. Anche questa funzione è definita per mantenere una
+analogia con le funzioni basate sui semafori, e si limita a cancellare
+\texttt{\small 39}) il file con una chiamata ad \func{unlink}. Si noti che in
+questo caso la funzione non ha effetto sui mutex già ottenuti, con precedenti
+chiamate a \func{FindMutex} o \func{CreateMutex}, che continueranno ad essere
+disponibili fintanto che i relativi file descriptor saranno aperti.
+
+Basandosi sulla semantica dei file lock POSIX valgono tutte le precisazioni
+relative al comportamento di questi ultimi fatte in
+\secref{sec:file_posix_lock}; questo significa che, al contrario di quanto
+avveniva con l'altra interfaccia basata sui semafori, chiamate multiple a
+\func{UnlockMutex} o \func{LockMutex} non hanno nessun inconveniente.

 
 
 \subsection{Il \textit{memory mapping} anonimo}
 
 
 \subsection{Il \textit{memory mapping} anonimo}