Ulteriori correzioni da D. Masini
[gapil.git] / fileadv.tex
index bff4ab76588c225940a296fbfd7e003b17838bdf..811d9b196310f3c67f9056baed227efed9489e3d 100644 (file)
@@ -1307,6 +1307,11 @@ comportamento non bloccante) viene posto in stato di sleep. Una volta finite
 le operazioni sul file si deve provvedere a rimuovere il lock. La situazione
 delle varie possibilità è riassunta in \tabref{tab:file_file_lock}.
 
 le operazioni sul file si deve provvedere a rimuovere il lock. La situazione
 delle varie possibilità è riassunta in \tabref{tab:file_file_lock}.
 
+Si tenga presente infine che il controllo di accesso è effettuato quando si
+apre un file, l'unico controllo residuo è che il tipo di lock che si vuole
+otternere deve essere compatibile con le modalità di apertura dello stesso (di
+lettura per un read lock e di scrittura per un 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
 %%  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
@@ -1388,7 +1393,7 @@ stesso file.
 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering
-  \includegraphics[width=13cm]{img/file_flock}
+  \includegraphics[width=12.5cm]{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}
   \caption{Schema dell'architettura del file locking, nel caso particolare  
     del suo utilizzo da parte dalla funzione \func{flock}.}
   \label{fig:file_flock_struct}
@@ -1476,12 +1481,15 @@ essa viene usata solo secondo il prototipo:
 \end{prototype}
 
 Al contrario di quanto avviene con l'interfaccia basata su \func{flock} con
 \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;
-inoltre la funzione permette di ottenere informazioni relative ai lock
-esistenti.  Per realizzare tutto questo la funzione utilizza come terzo
-argomento una apposita struttura \var{flock} (la cui definizione è riportata
-in \figref{fig:struct_flock}) nella quale inserire tutti i dati relativi ad un
-determinato lock.
+\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 \var{flock} (la
+cui definizione è riportata in \figref{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{figure}[!bht]
   \footnotesize \centering
@@ -1510,7 +1518,7 @@ 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
 \macro{SEEK\_SET}, \macro{SEEK\_CUR} e \macro{SEEK\_END}, (si vedano le
 contare \var{l\_start}. Il valore di \var{l\_whence} 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}).
+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
 
 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
@@ -1545,9 +1553,10 @@ il \acr{pid} del processo che detiene il lock.
   \label{tab:file_flock_type}
 \end{table}
 
   \label{tab:file_flock_type}
 \end{table}
 
-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 locking sono tre:
+Oltre a quanto richiesto tramite i campi di \var{flock}, 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 locking sono tre:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
 \item[\macro{F\_GETLK}] verifica se il file lock specificato dalla struttura
   puntata da \param{lock} può essere acquisito: in caso negativo sovrascrive
 \begin{basedescript}{\desclabelwidth{2.0cm}}
 \item[\macro{F\_GETLK}] verifica se il file lock specificato dalla struttura
   puntata da \param{lock} può essere acquisito: in caso negativo sovrascrive
@@ -1561,8 +1570,8 @@ specifica l'azione da compiere; i valori relativi al file locking sono tre:
   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
   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
+  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 \macro{EINTR}.
 \end{basedescript}
   rilasciato. Se l'attesa viene interrotta da un segnale la funzione ritorna
   con un errore di \macro{EINTR}.
 \end{basedescript}
@@ -1572,11 +1581,11 @@ una presenza generica di lock su un file, perch
 compatibili con quello richiesto, la funzione ritorna comunque impostando
 \var{l\_type} a \macro{F\_UNLCK}.  Inoltre a seconda del valore di
 \var{l\_type} si potrà controllare o l'esistenza di un qualunque tipo di lock
 compatibili con quello richiesto, la funzione ritorna comunque impostando
 \var{l\_type} a \macro{F\_UNLCK}.  Inoltre a seconda del valore di
 \var{l\_type} si potrà controllare o l'esistenza di un qualunque tipo di lock
-(con \macro{F\_WRLCK}) o di write lock (con \macro{F\_RDLCK}). Si consideri
+(se è \macro{F\_WRLCK}) o di write lock (se è \macro{F\_RDLCK}). Si consideri
 poi che può esserci più di un lock che impedisce l'acquisizione di quello
 poi che può esserci più di un lock che impedisce l'acquisizione di quello
-richiesto, ma la funzione ne riporterà sempre soltanto uno, impostando
-\var{l\_whence} a \macro{SEEK\_SET} ed i valori \var{l\_start} e \var{l\_len}
-per indicare quale è la regione bloccata.
+richiesto (basta che le regioni si sovrappongano), ma la funzione ne riporterà
+sempre soltanto uno, impostando \var{l\_whence} a \macro{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
 \macro{F\_GETLK} e poi tentare l'acquisizione con \macro{F\_SETLK} non è una
 
 Infine si tenga presente che effettuare un controllo con il comando
 \macro{F\_GETLK} e poi tentare l'acquisizione con \macro{F\_SETLK} non è una
@@ -1588,24 +1597,12 @@ chiamate) per cui si deve sempre verificare il codice di ritorno di
 quando la si invoca con \macro{F\_SETLK}, per controllare che il lock sia
 stato effettivamente acquisito.
 
 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]
 \begin{figure}[htb]
-  \centering \includegraphics[width=13cm]{img/file_posix_lock}
+  \centering \includegraphics[width=9cm]{img/file_lock_dead}
   \caption{Schema di una situazione di \textit{deadlock}.}
   \label{fig:file_flock_dead}
 \end{figure}
 
   \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
 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
@@ -1620,38 +1617,47 @@ 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}.
 
 impedirle restituendo un errore di \macro{EDEADLK} alla funzione che cerca di
 acquisire un lock che porterebbe ad un \textit{deadlock}.
 
-
-\begin{figure}[htb]
+\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}
 
   \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}
 
-Come accennato nella semantica POSIX si ha un comportamento del file locking
-diverso rispetto a quanto visto in \secref{sec:file_flock}.  Lo schema della
-struttura usata dal kernel 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
-  nella figura si sono evidenziati solo i campi di \var{file\_lock}
-  significativi per la semantica POSIX, in particolare adesso ciascuna
-  struttura 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 lock 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.
+
+Per capire meglio il funzionamento del file locking in semantica POSIX (che
+differisce alquanto rispetto da quello di BSD, visto \secref{sec:file_flock})
+esaminiamo più in dettaglio come viene gestito dal kernel. Lo schema delle
+strutture utilizzate è riportato in \figref{fig:file_posix_lock}; come si vede
+esso è molto simile all'analogo di \figref{fig:file_flock_struct}:\footnote{in
+  questo caso nella figura si sono evidenziati solo i campi di
+  \var{file\_lock} significativi per la semantica POSIX, in particolare adesso
+  ciascuna struttura 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.
+
+Quando si richiede un lock il kernel effettua una scansione di tutti i lock
+presenti sul file\footnote{scandisce cioè la linked list delle strutture
+  \var{file\_lock}, scartando automaticamente quelle per cui \var{fl\_flags}
+  non è \macro{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 lock, in caso negativo il nuovo
+lock viene comunque acquisito ed aggiunto alla lista.
+
+Nel caso di rimozione invece questa 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
 
 La seconda conseguenza è che qualunque file descriptor che faccia riferimento
 allo stesso file (che sia stato ottenuto con una \func{dup} o con una
@@ -1663,15 +1669,293 @@ POSIX baster
 lock relativi al file cui esso faceva riferimento, anche se questi fossero
 stati creati usando altri file descriptor che restano aperti.
 
 lock 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 lock viene eseguito sulla base del
+\acr{pid} del processo, possiamo anche prendere in cosiderazione un'altro
+degli aspetti meno chiari di questa interfaccia e cioè cosa succede quando si
+richiedono dei lock su regioni che si sovrappongono fra loro all'interno
+stesso processo. Siccome il controllo, come nel caso della rimozione, si basa
+solo sul \acr{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 file lock, o più lock sula stessa
+  sezione di file, le richieste non si cumulano e basta una sola richiesta di
+  rilascio per cancellare il lock.}  la cosa non ha alcun effetto; la funzione
+ritorna con successo, senza che il kernel debba modificare la lista dei lock.
+In questo caso invece si possono avere una serie di situazioni diverse: ad
+esempio è possibile rimuovere con una sola chiamata più lock distinti
+(indicando in una regione che si sovrapponga completamente a quelle di questi
+ultimi), o rimuovere solo una parte di un lock preesistente (indicando una
+regione contenuta in quella di un altro lock), creando un buco, o coprire con
+un nuovo lock altri 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 lock per far si
+che le regioni bloccate da essa risultanti siano coerenti con quanto
+necessario a soddisfare l'operazione richiesta.
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \begin{lstlisting}{}
+int main(int argc, char *argv[])
+{
+    int type = F_UNLCK;            /* lock type: default to unlock (invalid) */
+    off_t start = 0;             /* start of the locked region: default to 0 */
+    off_t len = 0;              /* length of the locked region: default to 0 */
+    int fd, res, i;                                    /* internal variables */
+    int bsd = 0;                          /* semantic type: default to POSIX */
+    int cmd = F_SETLK;              /* lock command: default to non-blocking */
+    struct flock lock;                                /* file lock structure */
+    ...
+    if ((argc - optind) != 1) {          /* There must be remaing parameters */
+        printf("Wrong number of arguments %d\n", argc - optind);
+        usage();
+    }
+    if (type == F_UNLCK) {            /* There must be a -w or -r option set */
+        printf("You should set a read or a write lock\n");
+        usage();
+    }
+    fd = open(argv[optind], O_RDWR);           /* open the file to be locked */
+    if (fd < 0) {                                           /* on error exit */
+        perror("Wrong filename");
+        exit(1);
+    }
+    /* do lock */
+    if (bsd) {                                             /* if BSD locking */
+        /* rewrite cmd for suitables flock operation values */ 
+        if (cmd == F_SETLKW) {                             /* if no-blocking */
+            cmd = LOCK_NB;              /* set the value for flock operation */
+        } else {                                                     /* else */
+            cmd = 0;                                      /* default is null */
+        }
+        if (type == F_RDLCK) cmd |= LOCK_SH;          /* set for shared lock */
+        if (type == F_WRLCK) cmd |= LOCK_EX;       /* set for exclusive lock */
+        res = flock(fd, cmd);                                /* esecute lock */
+    } else {                                             /* if POSIX locking */
+        /* setting flock structure */
+        lock.l_type = type;                       /* set type: read or write */
+        lock.l_whence = SEEK_SET;    /* start from the beginning of the file */
+        lock.l_start = start;          /* set the start of the locked region */
+        lock.l_len = len;             /* set the length of the locked region */
+        res = fcntl(fd, cmd, &lock);                              /* do lock */
+    }
+    /* check lock results */
+    if (res) {                                              /* on error exit */
+        perror("Failed lock");
+        exit(1);
+    } else {                                           /* else write message */
+        printf("Lock acquired\n");
+    }
+    pause();                       /* stop the process, use a signal to exit */
+    return 0;
+}
+    \end{lstlisting}
+  \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 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 \figref{fig:file_flock_code} è
+riportata il corpo principale del codice del programma, (il testo completo è
+allegato nella directory dei sorgenti).
+
+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 write lock o
+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
+lock (bloccante o meno), a seconda dell'opzione \cmd{-b}.
+
+Il programma inizia col controllare (\texttt{\small 11--14}) che venga passato
+un parametro (il file da bloccare), che sia stato scelto (\texttt{\small
+  15--18}) il tipo di lock, 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
+\macro{F\_SETLKW} o \macro{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 lock 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
+esegue (\texttt{\small 41}).
+
+In entrambi i casi dopo aver richiesto il lock 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
+lock vengono rilasciati.
+
+Con il programma possiamo fare varie verifiche sul funzionamento del file
+locking; cominciamo con l'eseguire un read lock su un file, ad esempio usando
+all'interno di un terminale il seguente comando:
+
+\vspace{1mm}
+\begin{minipage}[c]{12cm}
+\begin{verbatim}
+[piccardi@gont sources]$ ./flock -r Flock.c
+Lock acquired
+\end{verbatim}%$
+\end{minipage}\vspace{1mm}
+\par\noindent
+il programma segnalerà di aver acquisito un lock e si bloccherà; in questo
+caso si è usato il 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 write lock avremo:
+
+\vspace{1mm}
+\begin{minipage}[c]{12cm}
+\begin{verbatim}
+[piccardi@gont sources]$ ./flock -w Flock.c
+Failed lock: Resource temporarily unavailable
+\end{verbatim}%$
+\end{minipage}\vspace{1mm}
+\par\noindent
+come ci aspettiamo il programma terminerà segnalando l'indisponibilità del
+lock, dato che il file è bloccato dal precedente read lock. Si noti che il
+risultato è lo stesso anche se si richiede il blocco su una sola parte del
+file con il comando:
+
+\vspace{1mm}
+\begin{minipage}[c]{12cm}
+\begin{verbatim}
+[piccardi@gont sources]$ ./flock -w -s0 -l10 Flock.c
+Failed lock: Resource temporarily unavailable
+\end{verbatim}%$
+\end{minipage}\vspace{1mm}
+\par\noindent
+se invece blocchiamo una regione con: 
+
+\vspace{1mm}
+\begin{minipage}[c]{12cm}
+\begin{verbatim}
+[piccardi@gont sources]$ ./flock -r -s0 -l10 Flock.c
+Lock acquired
+\end{verbatim}%$
+\end{minipage}\vspace{1mm}
+\par\noindent
+una volta che riproviamo ad acquisire il write lock i risultati dipenderanno
+dalla regione richiesta; ad esempio nel caso in cui le due regioni si
+sovrappongono avremo che:
+
+\vspace{1mm}
+\begin{minipage}[c]{12cm}
+\begin{verbatim}
+[piccardi@gont sources]$ ./flock -w -s5 -l15  Flock.c
+Failed lock: Resource temporarily unavailable
+\end{verbatim}%$
+\end{minipage}\vspace{1mm}
+\par\noindent
+ed il lock viene rifiutato, ma se invece si richiede una regione distinta
+avremo che:
+
+\vspace{1mm}
+\begin{minipage}[c]{12cm}
+\begin{verbatim}
+[piccardi@gont sources]$ ./flock -w -s11 -l15  Flock.c
+Lock acquired
+\end{verbatim}%$
+\end{minipage}\vspace{1mm}
+\par\noindent
+ed il lock viene acquisito. Se a questo punto si prova ad eseguire un read
+lock che comprende la nuova regione bloccata in scrittura:
+
+\vspace{1mm}
+\begin{minipage}[c]{12cm}
+\begin{verbatim}
+[piccardi@gont sources]$ ./flock -r -s10 -l20 Flock.c
+Failed lock: Resource temporarily unavailable
+\end{verbatim}%$
+\end{minipage}\vspace{1mm}
+\par\noindent
+come ci aspettimo 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:
+
+\vspace{1mm}
+\begin{minipage}[c]{12cm}
+\begin{verbatim}
+[piccardi@gont sources]$ ./flock -r -b -s0 -l10 Flock.c Lock acquired
+\end{verbatim}%$
+\end{minipage}\vspace{1mm}
+\par\noindent
+il primo comando acquisisce subito un read lock, e quindi non cambia nulla, ma
+se proviamo adesso a richidere un write lock che non potrà essere acquisito
+otterremo:
+
+\vspace{1mm}
+\begin{minipage}[c]{12cm}
+\begin{verbatim}
+[piccardi@gont sources]$ ./flock -w -s0 -l10 Flock.c
+\end{verbatim}%$
+\end{minipage}\vspace{1mm}
+\par\noindent
+il programma cioè si bloccherà nella chiamata a \func{fcntl}; se a questo
+punto rilasciamo il precedente lock (terminando il primo comando un
+\texttt{C-c} sul terminale) potremo verificare che sull'altro terminale il
+lock viene acquisito, con la comparsa di una nuova riga:
+
+\vspace{1mm}
+\begin{minipage}[c]{12cm}
+\begin{verbatim}
+[piccardi@gont sources]$ ./flock -w -s0 -l10 Flock.c
+Lock acquired
+\end{verbatim}%$
+\end{minipage}\vspace{3mm}
+\par\noindent
+
+Un'altra cosa che si può controllare con il nostro programma è l'interazione
+fra i due tipi di lock; se ripartiamo dal primo comando con cui si è ottenuto
+un lock in lettura sull'intero file, possiamo verificare cosa succede quando
+si cerca di ottenere un lock in scrittura con la semantica BSD:
+
+\vspace{1mm}
+\begin{minipage}[c]{12cm}
+\begin{verbatim}
+[root@gont sources]# ./flock -f -w Flock.c
+Lock acquired
+\end{verbatim}
+\end{minipage}\vspace{1mm}
+\par\noindent
+che ci mostra come i due tipi di lock 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 lock
+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 file locking sia molto più
 
 \subsection{La funzione \func{lockf}}
 \label{sec:file_lockf}
 
 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 per le varie opzioni da passare a \func{fcntl}. Per questo motivo è
-disponibile anche una interfaccia semplificata (ripresa da System V) che
-utilizza la funzione \func{lockf}, il cui prototipo è:
+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 (ripresa da System V)
+che utilizza la 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}.
 \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}.
@@ -1689,7 +1973,7 @@ utilizza la funzione \func{lockf}, il cui prototipo 
   }
 \end{prototype}
 
   }
 \end{prototype}
 
-Il comportamento della funzione dipende dal valore dell'argomento \param{cmd}
+Il comportamento della funzione dipende dal valore dell'argomento \param{cmd},
 che specifica quale azione eseguire; i valori possibili sono riportati in
 \tabref{tab:file_lockf_type}.
 
 che specifica quale azione eseguire; i valori possibili sono riportati in
 \tabref{tab:file_lockf_type}.
 
@@ -1761,9 +2045,9 @@ per filesystem in fase di montaggio (specificando l'apposita opzione di
 \func{mount} riportata in \tabref{tab:sys_mount_flags}, o con l'opzione
 \cmd{mand} per il comando).
 
 \func{mount} riportata in \tabref{tab:sys_mount_flags}, o con l'opzione
 \cmd{mand} per il comando).
 
-Si tenga presente inoltre che il \textit{mandatory locking} funziona
-sull'interfaccia POSIX di \func{fcntl}, questo significa che non ha nessun
-effetto sui lock richiesti con l'interfaccia di \func{flock}, ed inoltre che
+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 lock richiesti con l'interfaccia di \func{flock}, e che
 la granularità del lock è quella del singolo byte, come per \func{fcntl}.
 
 La sintassi di acquisizione dei lock è esattamente la stessa vista in
 la granularità del lock è quella del singolo byte, come per \func{fcntl}.
 
 La sintassi di acquisizione dei lock è esattamente la stessa vista in
@@ -1795,17 +2079,21 @@ lock (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
 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
-appena trattati in \secref{sec:file_memory_map}; anche in tal caso infatti,
+funzioni di accesso ai file è quello relativo ai file mappati in memoria (che
+abbiamo trattato in \secref{sec:file_memory_map}); anche in tal caso infatti,
 quando si esegue la mappatura con l'opzione \macro{MAP\_SHARED}, si ha un
 accesso al contenuto del file. Lo standard SVID prevede che sia impossibile
 eseguire il memory mapping di un file su cui sono presenti dei
 lock\footnote{alcuni sistemi, come HP-UX, sono ancora più restrittivi e lo
 quando si esegue la mappatura con l'opzione \macro{MAP\_SHARED}, si ha un
 accesso al contenuto del file. Lo standard SVID prevede che sia impossibile
 eseguire il memory mapping di un file su cui sono presenti dei
 lock\footnote{alcuni sistemi, come HP-UX, sono ancora più restrittivi e lo
-  impediscono anche in caso di \textit{advisory locking}, anche se questo non
-  ha molto senso.} in Linux è stata però fatta la scelta implementativa di
-seguire questo comportamento soltanto quando si chiama \func{mmap} con
-l'opzione \macro{MAP\_SHARED} (nel qual caso la funzione fallisce con il
-solito \macro{EAGAIN}). 
+  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 insime ai sorgenti del kernel nel file
+  \file{Documentation/mandatory.txt}.}  di seguire questo comportamento
+soltanto quando si chiama \func{mmap} con l'opzione \macro{MAP\_SHARED} (nel
+qual caso la funzione fallisce con il solito \macro{EAGAIN}) che comporta la
+possibilità di modificare il file.