+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{LOCK\_SH} & Asserisce uno \textit{shared lock} sul file.\\
+ \const{LOCK\_EX} & Asserisce un \textit{esclusive lock} sul file.\\
+ \const{LOCK\_UN} & Rilascia il \textit{file lock}.\\
+ \const{LOCK\_NB} & Impedisce che la funzione si blocchi nella
+ richiesta di un \textit{file lock}.\\
+ \hline
+ \end{tabular}
+ \caption{Valori dell'argomento \param{operation} di \func{flock}.}
+ \label{tab:file_flock_operation}
+\end{table}
+
+I primi due valori, \const{LOCK\_SH} e \const{LOCK\_EX} permettono di
+richiedere un \textit{file lock}, ed ovviamente devono essere usati in maniera
+alternativa. Se si specifica anche \const{LOCK\_NB} la funzione non si
+bloccherà qualora il lock non possa essere acquisito, ma ritornerà subito con
+un errore di \errcode{EWOULDBLOCK}. Per rilasciare un lock si dovrà invece
+usare \const{LOCK\_UN}.
+
+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 occorre descrivere con maggiore dettaglio come viene realizzato il
+file locking nel kernel in entrambe le interfacce.
+
+In fig.~\ref{fig:file_flock_struct} si è riportato uno schema essenziale
+dell'implementazione del file locking in stile BSD 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\index{inode},\footnote{in particolare, come
+ accennato in fig.~\ref{fig:file_flock_struct}, i \textit{file lock} sono
+ mantenuti in una \itindex{linked~list} \textit{linked list} di strutture
+ \struct{file\_lock}. La lista è referenziata dall'indirizzo di partenza
+ mantenuto dal campo \var{i\_flock} della struttura \struct{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 (\const{FL\_FLOCK}) o POSIX (\const{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=14cm]{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 \struct{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 file lock quanto
+piuttosto degli ulteriori riferimenti allo stesso. Questo viene realizzato dal
+kernel secondo lo schema di fig.~\ref{fig:file_flock_struct}, associando ad
+ogni nuovo \textit{file lock} un puntatore\footnote{il puntatore è mantenuto
+ nel campo \var{fl\_file} di \struct{file\_lock}, e viene utilizzato solo per
+ i lock creati con la semantica BSD.} alla voce nella \itindex{file~table}
+\textit{file table} da cui si è richiesto il lock, che così ne identifica il
+titolare.
+
+Questa struttura prevede 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 \itindex{file~table} \textit{file table}
+corrispondente a quella registrata nel lock. Allora se ricordiamo quanto
+visto in sez.~\ref{sec:file_dup} e sez.~\ref{sec:file_sharing}, e cioè che i
+file descriptor duplicati e quelli ereditati in un processo figlio puntano
+sempre alla stessa voce nella \itindex{file~table} \textit{file table}, si può
+capire immediatamente quali sono le conseguenze nei confronti delle funzioni
+\func{dup} e \func{fork}.
+
+Sarà così possibile rimuovere un file lock attraverso uno qualunque dei file
+descriptor che fanno riferimento alla stessa voce nella \itindex{file~table}
+\textit{file table}, 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
+ \itindex{file~table} \textit{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
+\itindex{file~table} \textit{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 \itindex{file~table}
+\textit{file table}; e questo avverrà solo quando tutti i file descriptor che
+fanno riferimento alla stessa voce sono stati chiusi. Quindi, nel caso ci
+siano duplicati o processi figli che mantengono ancora aperto un file
+descriptor, il lock non viene rilasciato.
+
+Si tenga presente infine 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 possibilità di utilizzo in
+sez.~\ref{sec:file_fcntl}. Quando la si impiega per il \textit{file locking}
+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}.
+
+ \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[\errcode{EACCES}] L'operazione è proibita per la presenza di
+ \textit{file lock} da parte di altri processi.
+ \item[\errcode{ENOLCK}] Il sistema non ha le risorse per il locking: ci
+ sono troppi segmenti di lock aperti, si è esaurita la tabella dei lock,
+ o il protocollo per il locking remoto è fallito.
+ \item[\errcode{EDEADLK}] Si è richiesto un lock su una regione bloccata da
+ un altro processo che è a sua volta in attesa dello sblocco di un lock
+ mantenuto dal processo corrente; si avrebbe pertanto un
+ \itindex{deadlock} \textit{deadlock}. Non è garantito che il sistema
+ riconosca sempre questa situazione.
+ \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale prima
+ di poter acquisire un lock.
+ \end{errlist}
+ ed inoltre \errval{EBADF}, \errval{EFAULT}.
+ }
+\end{prototype}
+
+Al contrario di quanto avviene con l'interfaccia basata su \func{flock} con
+\func{fcntl} è possibile bloccare anche delle singole sezioni di un file, fino
+al singolo byte. Inoltre la funzione permette di ottenere alcune informazioni
+relative agli eventuali lock preesistenti. Per poter fare tutto questo la
+funzione utilizza come terzo argomento una apposita struttura \struct{flock}
+(la cui definizione è riportata in fig.~\ref{fig:struct_flock}) nella quale
+inserire tutti i dati relativi ad un determinato lock. Si tenga presente poi
+che un lock fa sempre riferimento ad una regione, per cui si potrà avere un
+conflitto anche se c'è soltanto una sovrapposizione parziale con un'altra
+regione bloccata.
+
+\begin{figure}[!bht]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includestruct{listati/flock.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{flock}, usata da \func{fcntl} per il file
+ locking.}
+ \label{fig:struct_flock}
+\end{figure}
+
+
+I primi tre campi della struttura, \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, \var{l\_len} la
+lunghezza della sezione e infine \var{l\_whence} imposta il riferimento da cui
+contare \var{l\_start}. Il valore di \var{l\_whence} segue la stessa semantica
+dell'omonimo argomento di \func{lseek}, coi tre possibili valori
+\const{SEEK\_SET}, \const{SEEK\_CUR} e \const{SEEK\_END}, (si vedano le
+relative descrizioni in sez.~\ref{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. Inoltre 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
+ \const{F\_RDLCK} & Richiede un blocco condiviso (\textit{read lock}).\\
+ \const{F\_WRLCK} & Richiede un blocco esclusivo (\textit{write lock}).\\
+ \const{F\_UNLCK} & Richiede l'eliminazione di un file lock.\\
+ \hline
+ \end{tabular}
+ \caption{Valori possibili per il campo \var{l\_type} di \struct{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 definiti dalle costanti riportate in
+tab.~\ref{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. Infine il campo \var{l\_pid} viene usato solo
+in caso di lettura, quando si chiama \func{fcntl} con \const{F\_GETLK}, e
+riporta il \acr{pid} del processo che detiene il lock.
+
+Oltre a quanto richiesto tramite i campi di \struct{flock}, l'operazione
+effettivamente svolta dalla funzione è stabilita dal valore dall'argomento
+\param{cmd} che, come già riportato in sez.~\ref{sec:file_fcntl}, specifica
+l'azione da compiere; i valori relativi al file locking sono tre:
+\begin{basedescript}{\desclabelwidth{2.0cm}}
+\item[\const{F\_GETLK}] verifica se il file lock specificato dalla struttura
+ puntata da \param{lock} può essere acquisito: in caso negativo sovrascrive
+ la struttura \param{flock} con i valori relativi al lock già esistente che
+ ne blocca l'acquisizione, altrimenti si limita a impostarne il campo
+ \var{l\_type} con il valore \const{F\_UNLCK}.
+\item[\const{F\_SETLK}] se il campo \var{l\_type} della struttura puntata da
+ \param{lock} è \const{F\_RDLCK} o \const{F\_WRLCK} richiede il
+ corrispondente file lock, se è \const{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 \errcode{EACCES} o di
+ \errcode{EAGAIN}.
+\item[\const{F\_SETLKW}] è identica a \const{F\_SETLK}, ma se la richiesta di
+ non può essere soddisfatta per la presenza di un altro lock, 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 \errcode{EINTR}.
+\end{basedescript}
+
+Si noti che per quanto detto il comando \const{F\_GETLK} non serve a rilevare
+una presenza generica di lock su un file, perché se ne esistono altri
+compatibili con quello richiesto, la funzione ritorna comunque impostando
+\var{l\_type} a \const{F\_UNLCK}. Inoltre a seconda del valore di
+\var{l\_type} si potrà controllare o l'esistenza di un qualunque tipo di lock
+(se è \const{F\_WRLCK}) o di write lock (se è \const{F\_RDLCK}). Si consideri
+poi che può esserci più di un lock che impedisce l'acquisizione di quello
+richiesto (basta che le regioni si sovrappongano), ma la funzione ne riporterà
+sempre soltanto uno, impostando \var{l\_whence} a \const{SEEK\_SET} ed i
+valori \var{l\_start} e \var{l\_len} per indicare quale è la regione bloccata.
+
+Infine si tenga presente che effettuare un controllo con il comando
+\const{F\_GETLK} e poi tentare l'acquisizione con \const{F\_SETLK} non è una
+operazione atomica (un altro processo potrebbe acquisire un lock fra le due
+chiamate) per cui si deve sempre verificare il codice di ritorno di
+\func{fcntl}\footnote{controllare il codice di ritorno delle funzioni invocate
+ è comunque una buona norma di programmazione, che permette di evitare un
+ sacco di errori difficili da tracciare proprio perché non vengono rilevati.}
+quando la si invoca con \const{F\_SETLK}, per controllare che il lock sia
+stato effettivamente acquisito.
+
+\begin{figure}[htb]
+ \centering \includegraphics[width=9cm]{img/file_lock_dead}
+ \caption{Schema di una situazione di \itindex{deadlock} \textit{deadlock}.}
+ \label{fig:file_flock_dead}
+\end{figure}
+
+Non operando a livello di interi file, il file locking POSIX introduce
+un'ulteriore complicazione; consideriamo la situazione illustrata in
+fig.~\ref{fig:file_flock_dead}, in cui il processo A blocca la regione 1 e il
+processo B la regione 2. Supponiamo che successivamente il processo A richieda
+un lock sulla regione 2 che non può essere acquisito per il preesistente lock
+del processo 2; il processo 1 si bloccherà fintanto che il processo 2 non
+rilasci il blocco. Ma cosa accade se il processo 2 nel frattempo tenta a sua
+volta di ottenere un lock sulla regione A? Questa è una tipica situazione che
+porta ad un \itindex{deadlock} \textit{deadlock}, dato che a quel punto anche
+il processo 2 si bloccherebbe, e niente potrebbe sbloccare l'altro processo.
+Per questo motivo il kernel si incarica di rilevare situazioni di questo tipo,
+ed impedirle restituendo un errore di \errcode{EDEADLK} alla funzione che
+cerca di acquisire un lock che porterebbe ad un \itindex{deadlock}
+\textit{deadlock}.
+
+\begin{figure}[!bht]
+ \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}