-quando la si invoca con \macro{F\_SETLK} per controllare che il lock sia stato
-effettivamente acquisito.
-
-Un'ultima considerazione riguardo il funzionamento del file locking POSIX
-riguarda la loro caratteristica di operare su delle sezioni di file: è
-possibile con una sola chiamata rimuovere più lock separati (indicando in
-\var{flock} una regione che li copra tutti), o rimuovere solo una parte di un
-lock preesistente (indicando una sezione contenuta in un altro lock), o di
-coprire con un nuovo lock altri lock già ottenuti. In tutti questi casi il
-kernel si preoccupa di accorpare o suddividere le regioni bloccate,
-aggiornando opportunamente le strutture interne usate per il file locking.
+quando la si invoca con \macro{F\_SETLK}, per controllare che il lock sia
+stato effettivamente acquisito.
+
+Occorre infine considerare come interagiscono operazioni su lock che si
+estendono su regioni che si sovrappongono fra loro (ovviamente si fa
+riferimento ai lock detenuti dallo stesso processo); ad esempio è possibile
+con una sola chiamata rimuovere più lock separati (indicando in \var{flock}
+una regione che li copra tutti), o rimuovere solo una parte di un lock
+preesistente (indicando una sezione contenuta in un altro lock), di coprire
+con un nuovo lock altri lock già ottenuti. In tutti questi casi il kernel si
+preoccupa di accorpare o suddividere le regioni bloccate, a seconda di quanto
+necessario per soddisfare l'operazione richiesta, aggiornando opportunamente
+le strutture interne usate per il file locking.
+
+\begin{figure}[htb]
+ \centering \includegraphics[width=13cm]{img/file_posix_lock}
+ \caption{Schema di una situazione di \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
+\figref{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}\index{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 \macro{EDEADLK} alla funzione che cerca di
+acquisire un lock che porterebbe ad un \textit{deadlock}.
+