-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.