X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=084f783b64f561fb0f5928646d3fd508a60f5be8;hp=8ec9dc39ef9fe88d52bc17969c4ba5830fb2ea73;hb=7b2cb0e324ea5531d490add25c6ffb2097f67099;hpb=796a9f553337f614a14cbbcec7a112334d6b20da

diff --git a/fileadv.tex b/fileadv.tex
index 8ec9dc3..084f783 100644
--- a/fileadv.tex
+++ b/fileadv.tex
@@ -1250,13 +1250,6 @@ eventuale blocco, e che sta ai vari processi controllare esplicitamente lo
 stato dei file condivisi prima di accedervi, implementando un opportuno
 protocollo.
 
-In Linux sono disponibili due interfacce per utilizzare l'\textit{advisory
-  locking}, la prima è quella derivata da BSD, che è basata sulla funzione
-\func{flock}, la seconda è quella standardizzata da POSIX.1 (derivata da
-System V), che è basata sulla funzione \func{fcntl}.  I \textit{file lock}
-sono implementati in maniera completamente indipendente nelle due interfacce,
-che pertanto possono coesistere senza interferenze.
-
 In generale si distinguono due tipologie di blocco per un file: la prima è il
 cosiddetto \textit{shared lock}, detto anche \textit{read lock} in quanto
 serve a bloccare l'accesso in scrittura su un file affinché non venga
@@ -1271,16 +1264,31 @@ scrivendo. Si parla di \textsl{blocco esclusivo} appunto perch
 processo alla volta può richiedere un \textit{exclusive lock} su un file per
 proteggere il suo accesso in scrittura.
 
-Entrambe le interfacce garantiscono che quando si richiede un \textit{file
-  lock} su un file su cui ne sia già presente un altro che non ne consente
-l'acquisizione (uno \textit{shared lock} su un file con un \textit{exclusive
-  lock} attivo, o un \textit{exclusive lock} su un file con un qualunque
-blocco attivo) la funzione blocca il processo fintanto che \textit{file lock}
-preesistente non viene rimosso.
+In Linux sono disponibili due interfacce per utilizzare l'\textit{advisory
+  locking}, la prima è quella derivata da BSD, che è basata sulla funzione
+\func{flock}, la seconda è quella standardizzata da POSIX.1 (derivata da
+System V), che è basata sulla funzione \func{fcntl}.  I \textit{file lock}
+sono implementati in maniera completamente indipendente nelle due interfacce,
+che pertanto possono coesistere senza interferenze.
 
-La prima interfaccia, quella derivata da BSD, permette di eseguire il blocco
-solo su di un intero file; funzione usata per richiedere e rimuovere un
-\textit{file lock} è \func{flock}, ed il suo prototipo è:
+Entrambe le interfacce prevedono la stessa procedura di funzionamento: si
+inizia sempre con il richiere l'opportuno \textit{file lock} (un
+\textit{exclusive lock} per una scrittura, uno \textit{shared lock} per una
+lettura) prima di eseguire l'accesso ad un file.  Se il lock viene acquisito
+il processo prosegue l'esecuzione, altrimenti (a meno di non aver richiesto un
+comportamento non bloccante) viene posto in stato di sleep. Una volta finite
+le operazioni sul file si deve provvedere a rimuovere il lock.  Si ricordi che
+la condizione per acquisire uno \textit{shared lock} è che il file non abbia
+già un \textit{exclusive lock} attivo, mentre per acquisire un
+\textit{exclusive lock} non deve essere presente nessun tipo di blocco.
+
+
+\subsection{La funzione \func{flock}}
+\label{sec:file_flock}
+
+La prima interfaccia per il file locking, quella derivata da BSD, permette di
+eseguire un blocco solo su un intero file; la funzione usata per richiedere e
+rimuovere un \textit{file lock} è \func{flock}, ed il suo prototipo è:
 \begin{prototype}{sys/file.h}{int flock(int fd, int operation)}
   
   Applica o rimuove un \textit{file lock} sul file \param{fd}.
@@ -1296,8 +1304,8 @@ solo su di un intero file; funzione usata per richiedere e rimuovere un
 
 La funzione può essere usata per acquisire o rilasciare un blocco a seconda di
 quanto specificato tramite il valore dell'argomento \param{operation}, questo
-deve essere passato come maschera binaria dei valori riportati in
-\tabref{tab:file_flock_operation}.
+viene interpretato come maschera binaria, e deve essere passato utilizzando le
+costanti riportate in \tabref{tab:file_flock_operation}.
 
 \begin{table}[htb]
   \centering
@@ -1318,22 +1326,100 @@ deve essere passato come maschera binaria dei valori riportati in
   \label{tab:file_flock_operation}
 \end{table}
 
-Si tenga presente che la funzione blocca direttamente un file (cioè, rispetto
-allo schema di \secref{fig:file_stat_struct}, il blocco è mantenuto in
-riferimento alla struttura \var{file}, e non al file descriptor). Pertanto sia
-\func{dup} che \func{fork} non creano ulteriori istanze di un \textit{file
-  lock} quanto piuttosto degli ulteriori riferimenti allo stesso. Questo
-comporta che un \textit{file lock} può essere rimosso su uno qualunque dei
-file descriptor che fanno riferimento allo stesso file: quindi se si toglie il
-blocco in un processo figlio o su un file descriptor duplicato, questo sarà
-cancellato rispettivamente anche nel processo padre e sul file descriptor
-originario.
+I primi due valori, \macro{LOCK\_SH} e \macro{LOCK\_EX} permettono di
+richiedere un \textit{file lock}, ed ovviamente devono essere usati in maniera
+alternativa. Se si specifica anche \macro{LOCK\_NB} la funzione non si
+bloccherà qualora il lock non possa essere aqcuisito, ma ritornerà subito con
+un errore di \macro{EWOULDBLOCK}. Per rilasciare un lock si dovrà invece usare
+\macro{LOCK\_NB}.
+
+La semantica del file locking di BSD è diversa da quella del file locking
+POSIX, in particolare per quanto riguarda il comportamento dei lock nei
+confronti delle due funzioni \func{dup} e \func{fork}.  Per capire queste
+differenze occore prima descrivere con maggiore dettaglio come viene
+realizzato il file locking nel kernel.
+
+In \figref{fig:file_flock_struct} si è riportato uno schema essenziale
+dell'implementazione del file locking in Linux; il punto fondamentale da
+capire è che un lock, qualunque sia l'interfaccia che si usa, anche se
+richiesto attraverso un file descriptor, agisce sempre su un file; perciò le
+informazioni relative agli eventuali \textit{file lock} sono mantenute a
+livello di inode,\footnote{in particolare, come accennato in
+  \figref{fig:file_flock_struct}, i \textit{file lock} sono mantenuti un una
+  \textit{linked list}\index{linked list} di strutture \var{file\_lock}. La
+  lista è referenziata dall'indirizzo di partenza mantenuto dal campo
+  \var{i\_flock} della struttura \var{inode} (per le definizioni esatte si
+  faccia riferimento al file \file{fs.h} nei sorgenti del kernel).  Un bit del
+  campo \var{fl\_flags} di specifica se si tratta di un lock in semantica BSD
+  (\macro{FL\_FLOCK}) o POSIX (\macro{FL\_POSIX}).} dato che questo è l'unico
+riferimento in comune che possono avere due processi diversi che aprono lo
+stesso file.
+
+\begin{figure}[htb]
+  \centering
+  \includegraphics[width=13cm]{img/file_flock}
+  \caption{Schema dell'architettura del file locking, nel caso particolare  
+    del suo utilizzo da parte dalla funzione \func{flock}.}
+  \label{fig:file_flock_struct}
+\end{figure}
+
+La richiesta di un file lock prevede una scansione della lista per determinare
+se l'acquisizione è possibile, ed in caso positivo l'aggiunta di un nuovo
+elemento.\footnote{cioè una nuova struttura \var{file\_lock}.}  Nel caso dei
+lock creati con \func{flock} la semantica della funzione prevede che sia
+\func{dup} che \func{fork} non creino ulteriori istanze di un \textit{file
+  lock} quanto piuttosto degli ulteriori riferimenti allo stesso. Questo viene
+realizzato dal kernel associando ad ogni nuovo \textit{file lock} un
+puntatore\footnote{il puntatore è mantenuto nel campo \var{fl\_file} di
+  \var{file\_lock}, e viene utilizzato solo per i lock creati con la semantica
+  BSD.} alla voce nella \textit{file table} da cui si è richiesto il blocco,
+che così ne identifica il titolare.
+
+Questa struttura comporta che, quando si richiede la rimozione di un file
+lock, il kernel acconsenta solo se la richiesta proviene da un file descriptor
+che fa riferimento ad una voce nella file table corrispondente a quella
+registrata nel blocco.  Allora se ricordiamo quanto visto in
+\secref{sec:file_dup} e \secref{sec:file_sharing}, e cioè che i file
+descriptor duplicati e quelli ereditati in un processo figlio puntano sempre
+alla stessa voce nella file table, si può capire immediatamente quali sono le
+conseguenze nei confronti delle funzioni \func{dup} e \func{fork}.
+
+Sarà cioè possibile rimuovere un file lock attraverso uno qualunque dei file
+descriptor che fanno riferimento alla stessa voce nella file table, quindi
+anche se questo è diverso da quello con cui lo si è
+creato,\footnote{attenzione, questo non vale se il file descriptor fa
+  riferimento allo stesso file, ma attraverso una voce diversa della file
+  table, come accade tutte le volte che si apre più volte lo stesso file.} o
+se si esegue la rimozione in un processo figlio; inoltre una volta tolto un
+file lock, la rimozione avrà effetto su tutti i file descriptor che
+condividono la stessa voce nella file table, e quindi, nel caso di file
+descriptor ereditati attraverso una \func{fork}, anche su processi diversi.
+
+Infine, per evitare che la terminazione imprevista di un processo lasci attivi
+dei file lock, quando un file viene chiuso il kernel provveda anche a
+rimuovere tutti i lock ad esso associati. Anche in questo caso occorre tenere
+presente cosa succede quando si hanno file descriptor duplicati; in tal caso
+infatti il file non verrà effettivamente chiuso (ed il lock rimosso) fintanto
+che non viene rilasciata la relativa voce nella file table; la rimozione cioè
+avverrà solo quando tutti i file descriptor che fanno riferimento alla stessa
+voce sono stati chiusi, quindi, nel caso ci siano processi figli che
+mantengono ancora aperto un file descriptor, il lock non sarà rilasciato.
+
+Si tenga presente che \func{flock} non è in grado di funzionare per i file
+mantenuti su NFS, in questo caso, se si ha la necessità di eseguire il
+\textit{file locking}, occorre usare l'interfaccia basata su \func{fcntl} che
+può funzionare anche attraverso NFS, a condizione che sia il client che il
+server supportino questa funzionalità.
+ 
+
+\subsection{Il file locking POSIX}
+\label{sec:file_posix_lock}
 
 La seconda interfaccia per l'\textit{advisory locking} disponibile in Linux è
 quella standardizzata da POSIX, basata sulla funzione \func{fcntl}. Abbiamo
 già trattato questa funzione nelle sue molteplici funzionalità in
-\secref{sec:file_fcntl}, quando la si impiega per il \textit{file locking}
-però essa viene usata secondo il prototipo:
+\secref{sec:file_fcntl}; quando la si impiega per il \textit{file locking}
+però essa viene usata solo secondo il prototipo:
 \begin{prototype}{fcntl.h}{int fcntl(int fd, int cmd, struct flock *lock)}
   
   Applica o rimuove un \textit{file lock} sul file \param{fd}.
@@ -1358,21 +1444,13 @@ per
   }
 \end{prototype}
 
-Si tenga presente che \func{flock} non è in grado di funzionare per i file
-manetenuti su NFS, in questo caso, se si ha la necessità di eseguire il
-\textit{file locking}, occorre usare l'interfaccia basata su \func{fcntl} che
-può funzionare anche attraverso NFS, a condizione che sia il client che il
-server supportino questa funzionalità.
- 
-La standardizzatione operata con POSIX.1 ha adottato le API per il
-\textit{file locking} originarie di System V, basate sulla funzione 
-
-
-
-Al contrario di \func{flock} con \func{fcntl} è possibile bloccare anche solo
-delle sezioni di un file. La funzione prende come argomento una struttura
-\var{flock} la cui definizione è riportata in \figref{fig:struct_flock}.
-
+Al contrario di quanto avviene con l'interfaccia basata su \func{flock} con
+\func{fcntl} è possibile bloccare anche delle singole sezioni di un file;
+inoltre la funzione permette di leggere le informazioni relative ai blocchi
+esistenti.  Per poter fare tutto questo la funzione utilizza come terzo
+argomento una apposita struttura \var{flock} (la cui definizione è riportata
+in \figref{fig:struct_flock}) che contiene tutte le specifiche di un dato file
+lock.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -1393,7 +1471,139 @@ struct flock {
   \label{fig:struct_flock}
 \end{figure}
 
+L'operazione effettivamente svolta dalla funzione è stabilita dal valore
+dall'argomento \param{cmd} che, come già riportato in \secref{sec:file_fcntl},
+specifica l'azione da compiere; i valori relativi al file loking sono tre:
+\begin{basedescript}{\desclabelwidth{2.0cm}}
+\item[\macro{F\_GETLK}] verifica se il file lock specificato dalla struttura
+  puntata da \param{lock} non è bloccato da qualche altro lock: in caso
+  affermativo sovrascrive la struttura con i valori relativi a quest'ultimo,
+  altrimenti si limita a impostarne il campo \var{l\_type} con
+  \macro{F\_UNLCK}.
+\item[\macro{F\_SETLK}] se il campo \var{l\_type} della struttura puntata da
+  \param{lock} è \macro{F\_RDLCK} o \macro{F\_WRLCK} richiede il
+  corrispondente file lock, se è \macro{F\_UNLCK} lo rilascia. Nel caso la
+  richiesta non possa essere soddisfatta a causa di un lock preesistente la
+  funzione ritorna immediatamente con un errore di \macro{EACCES} o di
+  \macro{EAGAIN}.
+\item[\macro{F\_SETLKW}] è identica a \macro{F\_SETLK}, ma se la richiesta di
+  un lock non può essere soddisfatta per la presenza di un altro blocco, mette
+  il processo in stato di attesa fintanto che il lock precedente non viene
+  rilasciato. Se l'attesa viene interrotta da un segnale la funzione ritorna
+  con un errore di \macro{EINTR}.
+\end{basedescript}
+
+Come accennato nell'interfaccia POSIX ogni file lock viene associato ad una
+struttura \func{flock}; i tre campi \var{l\_whence}, \var{l\_start} e
+\var{l\_len}, servono a specificare la sezione del file a cui fa riferimento
+il lock, \var{l\_start} specifica il byte di partenza, e \var{l\_len} la
+lunghezza della sezione; \var{l\_whence} infine imposta il riferimento da cui
+contare \var{l\_start} e segue la stessa semantica dell'omonimo argomento di
+\func{lseek}, coi tre possibili valori \macro{SEEK\_SET}, \macro{SEEK\_CUR} e
+\macro{SEEK\_END} (si vedano le relative descrizioni in
+\secref{sec:file_lseek}).
+
+Si tenga presente che un lock può essere richiesto anche per una regione al di
+là della corrente fine del file, così che una eventuale estensione dello
+stesso resti coperta dal blocco. Se si specifica un valore nullo per
+\var{l\_len} il blocco si considera esteso fino alla dimensione massima del
+file; in questo modo è possibile bloccare una qualunque regione a partire da
+un certo punto fino alla fine del file, coprendo automaticamente quanto
+eventualmente aggiunto in coda allo stesso.
+
+\begin{table}[htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|l|l|}
+    \hline
+    \textbf{Valore} & \textbf{Significato} \\
+    \hline
+    \hline
+    \macro{F\_RDLCK} & Richiede un blocco condiviso (\textit{read lock}).\\
+    \macro{F\_WRLCK} & Richiede un blocco esclusivo (\textit{write lock}).\\
+    \macro{F\_UNLCK} & Richiede l'eliminazione di un lock.\\
+    \hline    
+  \end{tabular}
+  \caption{Valori possibili per il campo \var{l\_type} di \func{flock}.}
+  \label{tab:file_flock_type}
+\end{table}
+
+Il tipo di file lock richiesto viene specificato dal campo \var{l\_type}, esso
+può assumere i tre valori riportati in \tabref{tab:file_flock_type}, che
+permettono di richiedere rispettivamente uno \textit{shared lock}, un
+\textit{esclusive lock}, e la rimozione di un lock precedentemente acquisito.
+
+\begin{figure}[htb]
+  \centering
+  \includegraphics[width=13cm]{img/file_posix_lock}
+  \caption{Schema dell'architettura del file locking, nel caso particolare  
+    del suo utilizzo secondo l'interfaccia standard POSIX.}
+  \label{fig:file_posix_lock}
+\end{figure}
+
+Infine il campo \var{l\_pid} riporta (viene usato solo in lettura, quando si
+chiama \func{fcntl} con \macro{F\_GETLK}) qual'è il processo cui appartiene il
+file lock. Nella semantica POSIX infatti il comportamento dei lock è diverso
+rispetto a quanto visto in precedenza per \func{flock}. Lo schema della
+struttura usata in questo caso è riportato in \figref{fig:file_posix_lock};
+come si vede essa è molto simile a quanto visto in
+\figref{fig:file_flock_struct} per \func{flock}:\footnote{in questo caso si
+  sono evidenziati nella figura i campi di \var{file\_lock} significativi per
+  la semantica POSIX, in particolare adesso ciascun lock contiene, oltre al
+  \acr{pid} del processo in \var{fl\_pid}, la sezione di file che viene
+  bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}.  La struttura è
+  comunque la stessa, solo che in questo caso nel campo \var{fl\_flags} è
+  impostato il bit \macro{FL\_POSIX} ed il campo \var{fl\_file} non viene
+  usato.} il lock è sempre associato all'inode, solo che in questo caso la
+titolarità non viene identificata con il riferimento ad una voce nella file
+table, ma con il valore del \acr{pid} del processo.
+
+Tutto ciò significa che la rimozione di un blocco viene effettuata
+controllando che il \acr{pid} del processo richiedente corrisponda a quello
+contenuto nel lock. Questa diversa modalità ha delle conseguenze precise
+riguardo il comportamento dei lock POSIX. La prima conseguenza è che un lock
+POSIX non viene mai ereditato attraverso una \func{fork}, dato che il processo
+figlio avrà un \acr{pid} diverso, mentre passa indenne attraverso una
+\func{exec} in quanto il \acr{pid} resta lo stesso.  Questo comporta che, al
+contrario di quanto avveniva con la semantica BSD, quando processo termina
+tutti i file lock da esso detenuti vengono immediatamente rilasciati.
+
+La seconda conseguenza è che qualunque file descriptor che faccia riferimento
+allo stesso file (che sia stato ottenuto con una \func{dup} o con una
+\func{open} non fa differenza) può essere usato per rimuovere un lock, dato
+che quello che conta è solo il \acr{pid} del processo. Da questo deriva una
+ulteriore sottile differenza di comportamento: dato che alla chiusura di un
+file i lock ad esso associati vengono rimossi, nella semantica POSIX basterà
+chiudere un file descriptor per cancellare tutti i lock realtivi al file cui
+esso faceva riferimento, anche se questi fossero stati creati usando altri
+file descriptor che restano aperti.
+
+Come abbiamo visto come l'interfaccia POSIX per il file locking sia molto più
+potente e flessibile di quella di BSD, ma è anche molto più complicata da
+usare, specie in tutti quei casi in cui non si vogliono bloccare sezioni
+separate di file. Per questo, seguendo System V, è disponibile una interfaccia
+semplificata grazie alla funzione \func{lockf}, il cui prototipo è:
+\begin{prototype}{sys/file.h}{int lockf(int fd, int cmd, off\_t len)}
+  
+  Applica, controlla o rimuove un \textit{file lock} sul file \param{fd}.
+  
+  \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    \begin{errlist}
+    \item[\macro{EAGAIN}] Non è possibile acquisire il lock, e si è
+      selezionato \macro{LOCK\_NB}, oppure l'operazione è proibita perché il
+      file è mappato in memoria.
+    \item[\macro{ENOLCK}] Il sistema non ha le risorse per il locking: ci sono
+      troppi segmenti di lock aperti, si è esaurita la tabella dei lock.
+    \item[\macro{EDEADLK}] Si è riconosciuta una situazione di
+      \textit{deadlock}.
+    \end{errlist}
+    ed inoltre \macro{EBADF}, \macro{EINVAL}.
+  }
+\end{prototype}
 
+Il comportamento della funzione dipende dal valore dell'argomento \param{cmd}
+che specifica quale azione eseguire; i valori possibili sono riportati in 
 
 \subsection{Il \textit{mandatory locking}}
 \label{sec:file_mand_locking}