+dei file. Inizieremo con la trattazione delle problematiche del \textit{file
+ locking} e poi prenderemo in esame le varie funzionalità avanzate che
+permettono una gestione più sofisticata dell'I/O su file, a partire da quelle
+che consentono di gestire l'accesso contemporaneo a più file esaminando le
+varie modalità alternative di gestire l'I/O per concludere con la gestione dei
+file mappati in memoria e le altre funzioni avanzate che consentono un
+controllo più dettagliato delle modalità di I/O.
+
+
+\section{Il \textit{file locking}}
+\label{sec:file_locking}
+
+\itindbeg{file~locking}
+
+In sez.~\ref{sec:file_shared_access} abbiamo preso in esame le modalità in cui
+un sistema unix-like gestisce l'accesso concorrente ai file da parte di
+processi diversi. In quell'occasione si è visto come, con l'eccezione dei file
+aperti in \textit{append mode}, quando più processi scrivono
+contemporaneamente sullo stesso file non è possibile determinare la sequenza
+in cui essi opereranno.
+
+Questo causa la possibilità di una \textit{race condition}; in generale le
+situazioni più comuni sono due: l'interazione fra un processo che scrive e
+altri che leggono, in cui questi ultimi possono leggere informazioni scritte
+solo in maniera parziale o incompleta; o quella in cui diversi processi
+scrivono, mescolando in maniera imprevedibile il loro output sul file.
+
+In tutti questi casi il \textit{file locking} è la tecnica che permette di
+evitare le \textit{race condition}, attraverso una serie di funzioni che
+permettono di bloccare l'accesso al file da parte di altri processi, così da
+evitare le sovrapposizioni, e garantire la atomicità delle operazioni di
+lettura o scrittura.
+
+
+\subsection{L'\textit{advisory locking}}
+\label{sec:file_record_locking}
+
+La prima modalità di \textit{file locking} che è stata implementata nei
+sistemi unix-like è quella che viene usualmente chiamata \textit{advisory
+ locking},\footnote{Stevens in \cite{APUE} fa riferimento a questo argomento
+ come al \textit{record locking}, dizione utilizzata anche dal manuale della
+ \acr{glibc}; nelle pagine di manuale si parla di \textit{discrectionary file
+ lock} per \func{fcntl} e di \textit{advisory locking} per \func{flock},
+ mentre questo nome viene usato da Stevens per riferirsi al \textit{file
+ locking} POSIX. Dato che la dizione \textit{record locking} è quantomeno
+ ambigua, in quanto in un sistema Unix non esiste niente che possa fare
+ riferimento al concetto di \textit{record}, alla fine si è scelto di
+ mantenere il nome \textit{advisory locking}.} in quanto sono i singoli
+processi, e non il sistema, che si incaricano di asserire e verificare se
+esistono delle condizioni di blocco per l'accesso ai file.
+
+Questo significa che le funzioni \func{read} o \func{write} vengono eseguite
+comunque e non risentono affatto della presenza di un eventuale \textit{lock};
+pertanto è sempre compito dei vari processi che intendono usare il
+\textit{file locking}, controllare esplicitamente lo stato dei file condivisi
+prima di accedervi, utilizzando le relative funzioni.
+
+In generale si distinguono due tipologie di \textit{file lock};\footnote{di
+ seguito ci riferiremo sempre ai blocchi di accesso ai file con la
+ nomenclatura inglese di \textit{file lock}, o più brevemente con
+ \textit{lock}, per evitare confusioni linguistiche con il blocco di un
+ processo (cioè la condizione in cui il processo viene posto in stato di
+ \textit{sleep}).} 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é il suo contenuto non venga modificato mentre lo si legge. Si
+parla appunto di \textsl{blocco condiviso} in quanto più processi possono
+richiedere contemporaneamente uno \textit{shared lock} su un file per
+proteggere il loro accesso in lettura.
+
+La seconda tipologia è il cosiddetto \textit{exclusive lock}, detto anche
+\textit{write lock} in quanto serve a bloccare l'accesso su un file (sia in
+lettura che in scrittura) da parte di altri processi mentre lo si sta
+scrivendo. Si parla di \textsl{blocco esclusivo} appunto perché un solo
+processo alla volta può richiedere un \textit{exclusive lock} su un file per
+proteggere il suo accesso in scrittura.
+
+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 recepita dallo standard POSIX.1 (che è
+derivata dall'interfaccia usata in System V), che è basata sulla funzione
+\func{fcntl}. I \textit{file lock} sono implementati in maniera completamente
+indipendente nelle due interfacce (in realtà con Linux questo avviene solo
+dalla serie 2.0 dei kernel) che pertanto possono coesistere senza
+interferenze.
+
+Entrambe le interfacce prevedono la stessa procedura di funzionamento: si
+inizia sempre con il richiedere 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 blocco viene acquisito
+il processo prosegue l'esecuzione, altrimenti (a meno di non aver richiesto un
+comportamento non bloccante) viene posto in stato di \textit{sleep}. Una volta
+finite le operazioni sul file si deve provvedere a rimuovere il blocco.
+
+La situazione delle varie possibilità che si possono verificare è riassunta in
+tab.~\ref{tab:file_file_lock}, dove si sono riportati, a seconda delle varie
+tipologie di blocco già presenti su un file, il risultato che si avrebbe in
+corrispondenza di una ulteriore richiesta da parte di un processo di un blocco
+nelle due tipologie di \textit{file lock} menzionate, con un successo o meno
+della richiesta.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|c|c|c|}
+ \hline
+ \textbf{Richiesta} & \multicolumn{3}{|c|}{\textbf{Stato del file}}\\
+ \cline{2-4}
+ &Nessun \textit{lock}&\textit{Read lock}&\textit{Write lock}\\
+ \hline
+ \hline
+ \textit{Read lock} & esecuzione & esecuzione & blocco \\
+ \textit{Write lock}& esecuzione & blocco & blocco \\
+ \hline
+ \end{tabular}
+ \caption{Tipologie di \textit{file locking}.}
+ \label{tab:file_file_lock}
+\end{table}
+
+Si tenga presente infine che il controllo di accesso e la gestione dei
+permessi viene effettuata quando si apre un file, l'unico controllo residuo
+che si può avere riguardo il \textit{file locking} è che il tipo di blocco che
+si vuole ottenere su un file deve essere compatibile con le modalità di
+apertura dello stesso (in lettura per un \textit{read lock} e in scrittura per
+un \textit{write 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 \textit{file locking}, quella derivata da BSD,
+permette di eseguire un blocco solo su un intero file; la funzione di sistema
+usata per richiedere e rimuovere un \textit{file lock} è \funcd{flock}, ed il
+suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/file.h}
+\fdecl{int flock(int fd, int operation)}
+\fdesc{Applica o rimuove un \textit{file lock}.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale
+ nell'attesa dell'acquisizione di un \textit{file lock}.
+ \item[\errcode{EINVAL}] si è specificato un valore non valido
+ per \param{operation}.
+ \item[\errcode{ENOLCK}] il kernel non ha memoria sufficiente per gestire il
+ \textit{file lock}.
+ \item[\errcode{EWOULDBLOCK}] il file ha già un blocco attivo, e si è
+ specificato \const{LOCK\_NB}.
+ \end{errlist}
+ ed inoltre \errval{EBADF} nel suo significato generico.
+}
+\end{funcproto}
+
+La funzione può essere usata per acquisire o rilasciare un \textit{file lock}
+a seconda di quanto specificato tramite il valore dell'argomento
+\param{operation}; questo viene interpretato come maschera binaria, e deve
+essere passato costruendo il valore con un OR aritmetico delle costanti
+riportate in tab.~\ref{tab:file_flock_operation}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{6cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{LOCK\_SH} & Richiede uno \textit{shared lock} sul file.\\
+ \constd{LOCK\_EX} & Richiede un \textit{esclusive lock} sul file.\\
+ \constd{LOCK\_UN} & Rilascia il \textit{file lock}.\\
+ \constd{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} rispettivamente condiviso o esclusivo, ed
+ovviamente non possono essere usati insieme. Se con essi si specifica anche
+\const{LOCK\_NB} la funzione non si bloccherà qualora il \textit{file lock}
+non possa essere acquisito, ma ritornerà subito con un errore di
+\errcode{EWOULDBLOCK}. Per rilasciare un \textit{file lock} si dovrà invece
+usare direttamente \const{LOCK\_UN}.
+
+Si tenga presente che non esiste una modalità per eseguire atomicamente un
+cambiamento del tipo di blocco (da \textit{shared lock} a \textit{esclusive
+ lock}), il blocco deve essere prima rilasciato e poi richiesto, ed è sempre
+possibile che nel frattempo abbia successo un'altra richiesta pendente,
+facendo fallire la riacquisizione.
+
+Si tenga presente infine che \func{flock} non è supportata per i file
+mantenuti su NFS, in questo caso, se si ha la necessità di utilizzare il
+\textit{file locking}, occorre usare l'interfaccia del \textit{file locking}
+POSIX basata su \func{fcntl} che è in grado di funzionare anche attraverso
+NFS, a condizione ovviamente che sia il client che il server supportino questa
+funzionalità.
+
+La semantica del \textit{file locking} di BSD inoltre è diversa da quella del
+\textit{file locking} POSIX, in particolare per quanto riguarda il
+comportamento dei \textit{file lock} nei confronti delle due funzioni
+\func{dup} e \func{fork}. Per capire queste differenze occorre descrivere con
+maggiore dettaglio come viene realizzato dal kernel il \textit{file locking}
+per entrambe le interfacce.
+
+In fig.~\ref{fig:file_flock_struct} si è riportato uno schema essenziale
+dell'implementazione del \textit{file locking} in stile BSD su Linux. Il punto
+fondamentale da capire è che un \textit{file lock}, qualunque sia
+l'interfaccia che si usa, anche se richiesto attraverso un file descriptor,
+agisce sempre su di un file; perciò le informazioni relative agli eventuali
+\textit{file lock} sono mantenute dal kernel a livello di \textit{inode}, dato
+che questo è l'unico riferimento in comune che possono avere due processi
+diversi che aprono lo stesso file.
+
+In particolare, come accennato in fig.~\ref{fig:file_flock_struct}, i
+\textit{file lock} sono mantenuti in una \textit{linked list} di strutture
+\kstructd{file\_lock}. La lista è referenziata dall'indirizzo di partenza
+mantenuto dal campo \var{i\_flock} della struttura \kstruct{inode} (per le
+definizioni esatte si faccia riferimento al file \file{include/linux/fs.h} nei
+sorgenti del kernel). Un bit del campo \var{fl\_flags} di specifica se si
+tratta di un lock in semantica BSD (\constd{FL\_FLOCK}) o POSIX
+(\constd{FL\_POSIX}) o un \textit{file lease} (\constd{FL\_LEASE}, vedi
+sez.~\ref{sec:file_asyncronous_lease}).
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=12cm]{img/file_flock}
+ \caption{Schema dell'architettura del \textit{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 \textit{file lock} prevede una scansione della lista per
+determinare se l'acquisizione è possibile, ed in caso positivo l'aggiunta di
+un nuovo elemento (cioè l'aggiunta di una nuova struttura
+\kstruct{file\_lock}). Nel caso dei blocchi 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 secondo lo schema
+di fig.~\ref{fig:file_flock_struct}, associando ad ogni nuovo \textit{file
+ lock} un puntatore alla voce nella \textit{file table} da cui si è richiesto
+il blocco, che così ne identifica il titolare. Il puntatore è mantenuto nel
+campo \var{fl\_file} di \kstruct{file\_lock}, e viene utilizzato solo per i
+\textit{file lock} creati con la semantica BSD.
+
+Questa struttura prevede che, quando si richiede la rimozione di un
+\textit{file lock}, il kernel acconsenta solo se la richiesta proviene da un
+file descriptor che fa riferimento ad una voce nella \textit{file table}
+corrispondente a quella registrata nel blocco. Allora se ricordiamo quanto
+visto in sez.~\ref{sec:file_dup} e sez.~\ref{sec:file_shared_access}, e cioè
+che i file descriptor duplicati e quelli ereditati in un processo figlio
+puntano sempre alla stessa voce nella \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 \textit{file lock} attraverso uno qualunque
+dei file descriptor che fanno riferimento alla stessa voce nella \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
+ \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 \textit{file lock} su un file, la rimozione avrà effetto su
+tutti i file descriptor che condividono la stessa voce nella \textit{file
+ table}, e quindi, nel caso di file descriptor ereditati attraverso una
+\func{fork}, anche per processi diversi.
+
+Infine, per evitare che la terminazione imprevista di un processo lasci attivi
+dei \textit{file lock}, quando un file viene chiuso il kernel provvede anche a
+rimuovere tutti i blocchi 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 blocco rimosso)
+fintanto che non viene rilasciata la relativa voce nella \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
+\textit{file lock} non viene rilasciato.
+
+
+\subsection{Il \textit{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 di sistema
+\func{fcntl}. Abbiamo già trattato questa funzione nelle sue molteplici
+possibilità di utilizzo in sez.~\ref{sec:file_fcntl_ioctl}. Quando la si
+impiega per il \textit{file locking} essa viene usata solo secondo il seguente
+prototipo:
+
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fdecl{int fcntl(int fd, int cmd, struct flock *lock)}
+\fdesc{Applica o rimuove un \textit{file lock}.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un 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{EDEADLK}] si è richiesto un \textit{lock} su una regione
+ bloccata da un altro processo che è a sua volta in attesa dello sblocco
+ di un \textit{lock} mantenuto dal processo corrente; si avrebbe pertanto
+ un \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 \textit{file lock}.
+ \item[\errcode{ENOLCK}] il sistema non ha le risorse per il blocco: ci
+ sono troppi segmenti di \textit{lock} aperti, si è esaurita la tabella
+ dei \textit{file lock}, o il protocollo per il blocco remoto è fallito.
+ \end{errlist}
+ ed inoltre \errval{EBADF}, \errval{EFAULT} nel loro significato generico.}
+\end{funcproto}
+
+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 blocchi 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 blocco. Si tenga presente poi
+che un \textit{file 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}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.90\textwidth}
+ \includestruct{listati/flock.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{flock}, usata da \func{fcntl} per il
+ \textit{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 blocco: \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 tab.~\ref{tab:lseek_whence_values}).
+
+Si tenga presente che un \textit{file 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.
+
+Lo standard POSIX non richiede che \var{l\_len} sia positivo, ed a partire dal
+kernel 2.4.21 è possibile anche indicare valori di \var{l\_len} negativi, in
+tal caso l'intervallo coperto va da \var{l\_start}$+$\var{l\_len} a
+\var{l\_start}$-1$, mentre per un valore positivo l'intervallo va da
+\var{l\_start} a \var{l\_start}$+$\var{l\_len}$-1$. Si può però usare un
+valore negativo soltanto se l'inizio della regione indicata non cade prima
+dell'inizio del file, mentre come accennato con un valore positivo si
+può anche indicare una regione che eccede la dimensione corrente del file.
+
+Il tipo di \textit{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 blocco 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 \ids{PID} del processo che detiene il
+\textit{file lock}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{F\_RDLCK} & Richiede un blocco condiviso (\textit{read lock}).\\
+ \constd{F\_WRLCK} & Richiede un blocco esclusivo (\textit{write lock}).\\
+ \constd{F\_UNLCK} & Richiede l'eliminazione di un \textit{file lock}.\\
+ \hline
+ \end{tabular}
+ \caption{Valori possibili per il campo \var{l\_type} di \struct{flock}.}
+ \label{tab:file_flock_type}
+\end{table}
+
+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_ioctl},
+specifica l'azione da compiere; i valori utilizzabili relativi al \textit{file
+ locking} sono tre:
+\begin{basedescript}{\desclabelwidth{2.0cm}}
+\item[\constd{F\_GETLK}] verifica se il \textit{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 blocco già
+ esistente che ne blocca l'acquisizione, altrimenti si limita a impostarne il
+ campo \var{l\_type} con il valore \const{F\_UNLCK}.
+\item[\constd{F\_SETLK}] se il campo \var{l\_type} della struttura puntata da
+ \param{lock} è \const{F\_RDLCK} o \const{F\_WRLCK} richiede il
+ corrispondente \textit{file lock}, se è \const{F\_UNLCK} lo rilascia; nel
+ caso la richiesta non possa essere soddisfatta a causa di un blocco
+ preesistente la funzione ritorna immediatamente con un errore di
+ \errcode{EACCES} o di \errcode{EAGAIN}.
+\item[\constd{F\_SETLKW}] è identica a \const{F\_SETLK}, ma se la richiesta di
+ non può essere soddisfatta per la presenza di un altro blocco, mette il
+ processo in stato di attesa fintanto che il blocco 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 blocco 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
+blocco (se è \const{F\_WRLCK}) o di \textit{write lock} (se è
+\const{F\_RDLCK}). Si consideri poi che può esserci più di un blocco 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 blocco 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 blocco sia
+stato effettivamente acquisito.
+
+\begin{figure}[!htb]
+ \centering \includegraphics[width=9cm]{img/file_lock_dead}
+ \caption{Schema di una situazione di \textit{deadlock}.}
+ \label{fig:file_flock_dead}
+\end{figure}
+
+Non operando a livello di interi file, il \textit{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 \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 blocco che porterebbe ad un \textit{deadlock}.
+
+Per capire meglio il funzionamento del \textit{file locking} in semantica
+POSIX (che differisce alquanto rispetto da quello di BSD, visto
+sez.~\ref{sec:file_flock}) esaminiamo più in dettaglio come viene gestito dal
+kernel. Lo schema delle strutture utilizzate è riportato in
+fig.~\ref{fig:file_posix_lock}; come si vede esso è molto simile all'analogo
+di fig.~\ref{fig:file_flock_struct}. In questo caso nella figura si sono
+evidenziati solo i campi di \kstructd{file\_lock} significativi per la
+semantica POSIX, in particolare adesso ciascuna struttura contiene, oltre al
+\ids{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
+\const{FL\_POSIX} ed il campo \var{fl\_file} non viene usato. Il blocco è
+sempre associato all'\textit{inode}, solo che in questo caso la titolarità non
+viene identificata con il riferimento ad una voce nella \textit{file table},
+ma con il valore del \ids{PID} del processo.
+
+\begin{figure}[!htb]
+ \centering \includegraphics[width=12cm]{img/file_posix_lock}
+ \caption{Schema dell'architettura del \textit{file locking}, nel caso
+ particolare del suo utilizzo secondo l'interfaccia standard POSIX.}
+ \label{fig:file_posix_lock}
+\end{figure}
+
+Quando si richiede un \textit{file lock} il kernel effettua una scansione di
+tutti i blocchi presenti sul file\footnote{scandisce cioè la \textit{linked
+ list} delle strutture \kstruct{file\_lock}, scartando automaticamente
+ quelle per cui \var{fl\_flags} non è \const{FL\_POSIX}, così che le due
+ interfacce restano ben separate.} per verificare se la regione richiesta
+non si sovrappone ad una già bloccata, in caso affermativo decide in base al
+tipo di blocco, in caso negativo il nuovo blocco viene comunque acquisito ed
+aggiunto alla lista.
+
+Nel caso di rimozione invece questa viene effettuata controllando che il
+\ids{PID} del processo richiedente corrisponda a quello contenuto nel blocco.
+Questa diversa modalità ha delle conseguenze precise riguardo il comportamento
+dei \textit{file lock} POSIX. La prima conseguenza è che un \textit{file lock}
+POSIX non viene mai ereditato attraverso una \func{fork}, dato che il processo
+figlio avrà un \ids{PID} diverso, mentre passa indenne attraverso una
+\func{exec} in quanto il \ids{PID} resta lo stesso. Questo comporta che, al
+contrario di quanto avveniva con la semantica BSD, quando un processo termina
+tutti i \textit{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} in questo caso non fa differenza) può essere usato per rimuovere
+un blocco, dato che quello che conta è solo il \ids{PID} del processo. Da
+questo deriva una ulteriore sottile differenza di comportamento: dato che alla
+chiusura di un file i blocchi ad esso associati vengono rimossi, nella
+semantica POSIX basterà chiudere un file descriptor qualunque per cancellare
+tutti i blocchi relativi al file cui esso faceva riferimento, anche se questi
+fossero stati creati usando altri file descriptor che restano aperti.
+
+Dato che il controllo sull'accesso ai blocchi viene eseguito sulla base del
+\ids{PID} del processo, possiamo anche prendere in considerazione un altro
+degli aspetti meno chiari di questa interfaccia e cioè cosa succede quando si
+richiedono dei blocchi su regioni che si sovrappongono fra loro all'interno
+stesso processo. Siccome il controllo, come nel caso della rimozione, si basa
+solo sul \ids{PID} del processo che chiama la funzione, queste richieste
+avranno sempre successo. Nel caso della semantica BSD, essendo i lock
+relativi a tutto un file e non accumulandosi,\footnote{questa ultima
+ caratteristica è vera in generale, se cioè si richiede più volte lo stesso
+ \textit{file lock}, o più blocchi sulla stessa sezione di file, le richieste
+ non si cumulano e basta una sola richiesta di rilascio per cancellare il
+ blocco.} la cosa non ha alcun effetto; la funzione ritorna con successo,
+senza che il kernel debba modificare la lista dei \textit{file lock}.
+
+Con i \textit{file lock} POSIX invece si possono avere una serie di situazioni
+diverse: ad esempio è possibile rimuovere con una sola chiamata più
+\textit{file lock} distinti (indicando in una regione che si sovrapponga
+completamente a quelle di questi ultimi), o rimuovere solo una parte di un
+blocco preesistente (indicando una regione contenuta in quella di un altro
+blocco), creando un buco, o coprire con un nuovo blocco altri \textit{file
+ lock} già ottenuti, e così via, a secondo di come si sovrappongono le
+regioni richieste e del tipo di operazione richiesta.
+
+Il comportamento seguito in questo caso è che la funzione ha successo ed
+esegue l'operazione richiesta sulla regione indicata; è compito del kernel
+preoccuparsi di accorpare o dividere le voci nella lista dei \textit{file
+ lock} per far sì che le regioni bloccate da essa risultanti siano coerenti
+con quanto necessario a soddisfare l'operazione richiesta.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/Flock.c}
+ \end{minipage}
+ \normalsize
+ \caption{Sezione principale del codice del programma \file{Flock.c}.}
+ \label{fig:file_flock_code}
+\end{figure}
+
+Per fare qualche esempio sul \textit{file locking} si è scritto un programma che
+permette di bloccare una sezione di un file usando la semantica POSIX, o un
+intero file usando la semantica BSD; in fig.~\ref{fig:file_flock_code} è
+riportata il corpo principale del codice del programma, (il testo completo è
+allegato nella directory dei sorgenti, nel file \texttt{Flock.c}).
+
+La sezione relativa alla gestione delle opzioni al solito si è omessa, come la
+funzione che stampa le istruzioni per l'uso del programma, essa si cura di
+impostare le variabili \var{type}, \var{start} e \var{len}; queste ultime due
+vengono inizializzate al valore numerico fornito rispettivamente tramite gli
+switch \code{-s} e \cmd{-l}, mentre il valore della prima viene impostato con
+le opzioni \cmd{-w} e \cmd{-r} si richiede rispettivamente o un \textit{write
+ lock} o \textit{read lock} (i due valori sono esclusivi, la variabile
+assumerà quello che si è specificato per ultimo). Oltre a queste tre vengono
+pure impostate la variabile \var{bsd}, che abilita la semantica omonima quando
+si invoca l'opzione \cmd{-f} (il valore preimpostato è nullo, ad indicare la
+semantica POSIX), e la variabile \var{cmd} che specifica la modalità di
+richiesta del \textit{file lock} (bloccante o meno), a seconda dell'opzione
+\cmd{-b}.
+
+Il programma inizia col controllare (\texttt{\small 11-14}) che venga passato
+un argomento (il file da bloccare), che sia stato scelto (\texttt{\small
+ 15-18}) il tipo di blocco, dopo di che apre (\texttt{\small 19}) il file,
+uscendo (\texttt{\small 20-23}) in caso di errore. A questo punto il
+comportamento dipende dalla semantica scelta; nel caso sia BSD occorre
+reimpostare il valore di \var{cmd} per l'uso con \func{flock}; infatti il
+valore preimpostato fa riferimento alla semantica POSIX e vale rispettivamente
+\const{F\_SETLKW} o \const{F\_SETLK} a seconda che si sia impostato o meno la
+modalità bloccante.
+
+Nel caso si sia scelta la semantica BSD (\texttt{\small 25-34}) prima si
+controlla (\texttt{\small 27-31}) il valore di \var{cmd} per determinare se
+si vuole effettuare una chiamata bloccante o meno, reimpostandone il valore
+opportunamente, dopo di che a seconda del tipo di blocco al valore viene
+aggiunta la relativa opzione, con un OR aritmetico, dato che \func{flock}
+vuole un argomento \param{operation} in forma di maschera binaria. Nel caso
+invece che si sia scelta la semantica POSIX le operazioni sono molto più
+immediate si prepara (\texttt{\small 36-40}) la struttura per il lock, e lo
+si esegue (\texttt{\small 41}).
+
+In entrambi i casi dopo aver richiesto il blocco viene controllato il
+risultato uscendo (\texttt{\small 44-46}) in caso di errore, o stampando un
+messaggio (\texttt{\small 47-49}) in caso di successo. Infine il programma si
+pone in attesa (\texttt{\small 50}) finché un segnale (ad esempio un \cmd{C-c}
+dato da tastiera) non lo interrompa; in questo caso il programma termina, e
+tutti i blocchi vengono rilasciati.
+
+Con il programma possiamo fare varie verifiche sul funzionamento del
+\textit{file locking}; cominciamo con l'eseguire un \textit{read lock} su un
+file, ad esempio usando all'interno di un terminale il seguente comando:
+
+\begin{Console}
+[piccardi@gont sources]$ \textbf{./flock -r Flock.c}
+Lock acquired
+\end{Console}
+%$
+il programma segnalerà di aver acquisito un blocco e si bloccherà; in questo
+caso si è usato il \textit{file locking} POSIX e non avendo specificato niente
+riguardo alla sezione che si vuole bloccare sono stati usati i valori
+preimpostati che bloccano tutto il file. A questo punto se proviamo ad
+eseguire lo stesso comando in un altro terminale, e avremo lo stesso
+risultato. Se invece proviamo ad eseguire un \textit{write lock} avremo:
+
+\begin{Console}
+[piccardi@gont sources]$ \textbf{./flock -w Flock.c}
+Failed lock: Resource temporarily unavailable
+\end{Console}
+%$
+come ci aspettiamo il programma terminerà segnalando l'indisponibilità del
+blocco, dato che il file è bloccato dal precedente \textit{read lock}. Si noti
+che il risultato è lo stesso anche se si richiede il blocco su una sola parte
+del file con il comando:
+
+\begin{Console}
+[piccardi@gont sources]$ \textbf{./flock -w -s0 -l10 Flock.c}
+Failed lock: Resource temporarily unavailable
+\end{Console}
+%$
+se invece blocchiamo una regione con:
+
+\begin{Console}
+[piccardi@gont sources]$ \textbf{./flock -r -s0 -l10 Flock.c}
+Lock acquired
+\end{Console}
+%$
+una volta che riproviamo ad acquisire il \textit{write lock} i risultati
+dipenderanno dalla regione richiesta; ad esempio nel caso in cui le due
+regioni si sovrappongono avremo che:
+
+\begin{Console}
+[piccardi@gont sources]$ \textbf{./flock -w -s5 -l15 Flock.c}
+Failed lock: Resource temporarily unavailable
+\end{Console}
+%$
+ed il blocco viene rifiutato, ma se invece si richiede una regione distinta
+avremo che:
+
+\begin{Console}
+[piccardi@gont sources]$ \textbf{./flock -w -s11 -l15 Flock.c}
+Lock acquired
+\end{Console}
+%$
+ed il blocco viene acquisito. Se a questo punto si prova ad eseguire un
+\textit{read lock} che comprende la nuova regione bloccata in scrittura:
+
+\begin{Console}
+[piccardi@gont sources]$ \textbf{./flock -r -s10 -l20 Flock.c}
+Failed lock: Resource temporarily unavailable
+\end{Console}
+%$
+come ci aspettiamo questo non sarà consentito.
+
+Il programma di norma esegue il tentativo di acquisire il lock in modalità non
+bloccante, se però usiamo l'opzione \cmd{-b} possiamo impostare la modalità
+bloccante, riproviamo allora a ripetere le prove precedenti con questa
+opzione:
+
+\begin{Console}
+[piccardi@gont sources]$ \textbf{./flock -r -b -s0 -l10 Flock.c} Lock acquired
+\end{Console}
+%$
+il primo comando acquisisce subito un \textit{read lock}, e quindi non cambia
+nulla, ma se proviamo adesso a richiedere un \textit{write lock} che non potrà
+essere acquisito otterremo:
+
+\begin{Console}
+[piccardi@gont sources]$ \textbf{./flock -w -s0 -l10 Flock.c}
+\end{Console}
+%$
+il programma cioè si bloccherà nella chiamata a \func{fcntl}; se a questo
+punto rilasciamo il precedente blocco (terminando il primo comando un
+\texttt{C-c} sul terminale) potremo verificare che sull'altro terminale il
+blocco viene acquisito, con la comparsa di una nuova riga:
+
+\begin{Console}
+[piccardi@gont sources]$ \textbf{./flock -w -s0 -l10 Flock.c}
+Lock acquired
+\end{Console}
+%$
+
+Un'altra cosa che si può controllare con il nostro programma è l'interazione
+fra i due tipi di blocco; se ripartiamo dal primo comando con cui si è
+ottenuto un blocco in lettura sull'intero file, possiamo verificare cosa
+succede quando si cerca di ottenere un blocco in scrittura con la semantica
+BSD:
+
+\begin{Console}
+[root@gont sources]# \textbf{./flock -f -w Flock.c}
+Lock acquired
+\end{Console}
+%$
+che ci mostra come i due tipi di blocco siano assolutamente indipendenti; per
+questo motivo occorre sempre tenere presente quale, fra le due semantiche
+disponibili, stanno usando i programmi con cui si interagisce, dato che i
+blocchi applicati con l'altra non avrebbero nessun effetto.
+
+% \subsection{La funzione \func{lockf}}
+% \label{sec:file_lockf}
+
+Abbiamo visto come l'interfaccia POSIX per il \textit{file locking} sia molto
+più potente e flessibile di quella di BSD, questo comporta anche una maggiore
+complessità per via delle varie opzioni da passare a \func{fcntl}. Per questo
+motivo è disponibile anche una interfaccia semplificata che utilizza la
+funzione \funcd{lockf},\footnote{la funzione è ripresa da System V e per
+ poterla utilizzare è richiesta che siano definite le opportune macro, una
+ fra \macro{\_BSD\_SOURCE} o \macro{\_SVID\_SOURCE}, oppure
+ \macro{\_XOPEN\_SOURCE} ad un valore di almeno 500, oppure
+ \macro{\_XOPEN\_SOURCE} e \macro{\_XOPEN\_SOURCE\_EXTENDED}.} il cui
+prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int lockf(int fd, int cmd, off\_t len)}
+\fdesc{Applica, controlla o rimuove un \textit{file lock}.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EAGAIN}] il file è bloccato, e si sono richiesti
+ \const{F\_TLOCK} o \const{F\_TEST} (in alcuni casi può dare anche
+ \errcode{EACCESS}.
+ \item[\errcode{EBADF}] \param{fd} non è un file descriptor aperto o si sono
+ richiesti \const{F\_LOCK} o \const{F\_TLOCK} ma il file non è scrivibile.
+ \item[\errcode{EINVAL}] si è usato un valore non valido per \param{cmd}.
+ \end{errlist}
+ ed inoltre \errcode{EDEADLK} e \errcode{ENOLCK} con lo stesso significato
+ che hanno con \func{fcntl}.
+}
+\end{funcproto}
+
+La funzione opera sul file indicato dal file descriptor \param{fd}, che deve
+essere aperto in scrittura, perché utilizza soltanto \textit{lock}
+esclusivi. La sezione di file bloccata viene controllata dal valore
+di \param{len}, che indica la lunghezza della stessa, usando come riferimento
+la posizione corrente sul file. La sezione effettiva varia a secondo del
+segno, secondo lo schema illustrato in fig.~\ref{fig:file_lockf_boundary}, se
+si specifica un valore nullo il file viene bloccato a partire dalla posizione
+corrente fino alla sua fine presente o futura (nello schema corrisponderebbe
+ad un valore infinito positivo).
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=10cm]{img/lockf_boundary}
+ \caption{Schema della sezione di file bloccata con \func{lockf}.}
+ \label{fig:file_lockf_boundary}
+\end{figure}
+
+Il comportamento della funzione viene controllato dal valore
+dell'argomento \param{cmd}, che specifica quale azione eseguire, i soli valori
+consentiti sono i seguenti:
+
+\begin{basedescript}{\desclabelwidth{2.0cm}}
+\item[\constd{F\_LOCK}] Richiede un \textit{lock} esclusivo sul file, e blocca
+ il processo chiamante se, anche parzialmente, la sezione indicata si
+ sovrappone ad una che è già stata bloccata da un altro processo; in caso di
+ sovrapposizione con un altro blocco già ottenuto le sezioni vengono unite.
+\item[\constd{F\_TLOCK}] Richiede un \textit{exclusive lock}, in maniera
+ identica a \const{F\_LOCK}, ma in caso di indisponibilità non blocca il
+ processo restituendo un errore di \errval{EAGAIN}.
+\item[\constd{F\_ULOCK}] Rilascia il blocco sulla sezione indicata, questo può
+ anche causare la suddivisione di una sezione bloccata in precedenza nelle
+ due parti eccedenti nel caso si sia indicato un intervallo più limitato.
+\item[\constd{F\_TEST}] Controlla la presenza di un blocco sulla sezione di
+ file indicata, \func{lockf} ritorna $0$ se la sezione è libera o bloccata
+ dal processo stesso, o $-1$ se è bloccata da un altro processo, nel qual
+ caso \var{errno} assume il valore \errval{EAGAIN} (ma su alcuni sistemi può
+ essere restituito anche \errval{EACCESS}).
+\end{basedescript}
+
+La funzione è semplicemente una diversa interfaccia al \textit{file locking}
+POSIX ed è realizzata utilizzando \func{fcntl}; pertanto la semantica delle
+operazioni è la stessa di quest'ultima e quindi la funzione presenta lo stesso
+comportamento riguardo gli effetti della chiusura dei file, ed il
+comportamento sui file duplicati e nel passaggio attraverso \func{fork} ed
+\func{exec}. Per questo stesso motivo la funzione non è equivalente a
+\func{flock} e può essere usata senza interferenze insieme a quest'ultima.
+
+
+\subsection{Gli \textit{open file descriptor locks}}
+\label{sec:open_file_descriptor_locks}
+
+Come illustrato in dettaglio nella precedente sez.~\ref{sec:file_posix_lock},
+la chiusura di un file su cui sono presenti dei \textit{file lock} comporta
+l'immediato rilascio degli stessi, anche se questi sono stati acquisiti da un
+processo diverso.
+
+da finire.
+
+% TODO trattare i POSIX file-private lock introdotti con il 3.15,
+% vedi http://lwn.net/Articles/586904/ correlato:
+% http://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2.html
+
+\subsection{Il \textit{mandatory locking}}
+\label{sec:file_mand_locking}
+
+\itindbeg{mandatory~locking}
+
+Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4,
+per introdurre un \textit{file locking} che, come dice il nome, fosse
+effettivo indipendentemente dai controlli eseguiti da un processo. Con il
+\textit{mandatory locking} infatti è possibile far eseguire il blocco del file
+direttamente al sistema, così che, anche qualora non si predisponessero le
+opportune verifiche nei processi, questo verrebbe comunque rispettato.
+
+Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
+utilizzo particolare del bit \acr{sgid} dei permessi dei file. Se si ricorda
+quanto esposto in sez.~\ref{sec:file_special_perm}), esso viene di norma
+utilizzato per cambiare il \ids{GID} effettivo con cui viene eseguito un
+programma, ed è pertanto sempre associato alla presenza del permesso di
+esecuzione per il gruppo. Impostando questo bit su un file senza permesso di
+esecuzione in un sistema che supporta il \textit{mandatory locking}, fa sì che
+quest'ultimo venga attivato per il file in questione. In questo modo una
+combinazione dei permessi originariamente non contemplata, in quanto senza
+significato, diventa l'indicazione della presenza o meno del \textit{mandatory
+ locking}.\footnote{un lettore attento potrebbe ricordare quanto detto in
+ sez.~\ref{sec:file_perm_management} e cioè che il bit \acr{sgid} viene
+ cancellato (come misura di sicurezza) quando di scrive su un file, questo
+ non vale quando esso viene utilizzato per attivare il \textit{mandatory
+ locking}.}
+
+L'uso del \textit{mandatory locking} presenta vari aspetti delicati, dato che
+neanche l'amministratore può passare sopra ad un \textit{file lock}; pertanto
+un processo che blocchi un file cruciale può renderlo completamente
+inaccessibile, rendendo completamente inutilizzabile il sistema\footnote{il
+ problema si potrebbe risolvere rimuovendo il bit \acr{sgid}, ma non è detto
+ che sia così facile fare questa operazione con un sistema bloccato.}
+inoltre con il \textit{mandatory locking} si può bloccare completamente un
+server NFS richiedendo una lettura su un file su cui è attivo un blocco. Per
+questo motivo l'abilitazione del \textit{mandatory locking} è di norma
+disabilitata, e deve essere attivata filesystem per filesystem in fase di
+montaggio, specificando l'apposita opzione di \func{mount} riportata in
+sez.~\ref{sec:filesystem_mounting}, o con l'opzione \code{-o mand} per il
+comando omonimo.
+
+Si tenga presente inoltre che il \textit{mandatory locking} funziona solo
+sull'interfaccia POSIX di \func{fcntl}. Questo ha due conseguenze: che non si
+ha nessun effetto sui \textit{file lock} richiesti con l'interfaccia di
+\func{flock}, e che la granularità del blocco è quella del singolo byte, come
+per \func{fcntl}.
+
+La sintassi di acquisizione dei blocchi è esattamente la stessa vista in
+precedenza per \func{fcntl} e \func{lockf}, la differenza è che in caso di
+\textit{mandatory lock} attivato non è più necessario controllare la
+disponibilità di accesso al file, ma si potranno usare direttamente le
+ordinarie funzioni di lettura e scrittura e sarà compito del kernel gestire
+direttamente il \textit{file locking}.
+
+Questo significa che in caso di \textit{read lock} la lettura dal file potrà
+avvenire normalmente con \func{read}, mentre una \func{write} si bloccherà
+fino al rilascio del blocco, a meno di non aver aperto il file con
+\const{O\_NONBLOCK}, nel qual caso essa ritornerà immediatamente con un errore
+di \errcode{EAGAIN}.
+
+Se invece si è acquisito un \textit{write lock} tutti i tentativi di leggere o
+scrivere sulla regione del file bloccata fermeranno il processo fino al
+rilascio del blocco, a meno che il file non sia stato aperto con
+\const{O\_NONBLOCK}, nel qual caso di nuovo si otterrà un ritorno immediato
+con l'errore di \errcode{EAGAIN}.
+
+Infine occorre ricordare che le funzioni di lettura e scrittura non sono le
+sole ad operare sui contenuti di un file, e che sia \func{creat} che
+\func{open} (quando chiamata con \const{O\_TRUNC}) effettuano dei cambiamenti,
+così come \func{truncate}, riducendone le dimensioni (a zero nei primi due
+casi, a quanto specificato nel secondo). Queste operazioni sono assimilate a
+degli accessi in scrittura e pertanto non potranno essere eseguite (fallendo
+con un errore di \errcode{EAGAIN}) su un file su cui sia presente un qualunque
+blocco (le prime due sempre, la terza solo nel caso che la riduzione delle
+dimensioni del file vada a sovrapporsi ad una regione bloccata).
+
+L'ultimo aspetto della interazione del \textit{mandatory locking} con le
+funzioni di accesso ai file è quello relativo ai file mappati in memoria (vedi
+sez.~\ref{sec:file_memory_map}); anche in tal caso infatti, quando si esegue
+la mappatura con l'opzione \const{MAP\_SHARED}, si ha un accesso al contenuto
+del file. Lo standard SVID prevede che sia impossibile eseguire il
+\textit{memory mapping} di un file su cui sono presenti dei
+blocchi\footnote{alcuni sistemi, come HP-UX, sono ancora più restrittivi e lo
+ impediscono anche in caso di \textit{advisory locking}, anche se questo
+ comportamento non ha molto senso, dato che comunque qualunque accesso
+ diretto al file è consentito.} in Linux è stata però fatta la scelta
+implementativa\footnote{per i dettagli si possono leggere le note relative
+ all'implementazione, mantenute insieme ai sorgenti del kernel nel file
+ \file{Documentation/mandatory.txt}.} di seguire questo comportamento
+soltanto quando si chiama \func{mmap} con l'opzione \const{MAP\_SHARED} (nel
+qual caso la funzione fallisce con il solito \errcode{EAGAIN}) che comporta la
+possibilità di modificare il file.
+
+Si tenga conto infine che su Linux l'implementazione corrente del
+\textit{mandatory locking} è difettosa e soffre di una \textit{race
+ condition}, per cui una scrittura con \func{write} che si sovrapponga alla
+richiesta di un \textit{read lock} può modificare i dati anche dopo che questo
+è stato ottenuto, ed una lettura con \func{read} può restituire dati scritti
+dopo l'ottenimento di un \textit{write lock}. Lo stesso tipo di problema si
+può presentare anche con l'uso di file mappati in memoria; pertanto allo stato
+attuale delle cose è sconsigliabile fare affidamento sul \textit{mandatory
+ locking}.
+
+% TODO il supporto è stato reso opzionale nel 4.5, verrà eliminato nel futuro
+% (vedi http://lwn.net/Articles/667210/)
+
+\itindend{file~locking}
+
+\itindend{mandatory~locking}