X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=811d9b196310f3c67f9056baed227efed9489e3d;hp=43451b723e6ebceac561ef2cd0ac7c9a85e91a6e;hb=978f01b032c3492f1a5bec1f9139b84979efb800;hpb=1d4b809bf491b417dee3994f6f9e9a897cb1d2ca diff --git a/fileadv.tex b/fileadv.tex index 43451b7..811d9b1 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -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}. +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 @@ -1388,7 +1393,7 @@ stesso file. \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} @@ -1612,7 +1617,7 @@ 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}. -\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.} @@ -1781,7 +1786,7 @@ 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. +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 @@ -1793,7 +1798,6 @@ 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 @@ -1801,15 +1805,157 @@ attesa (\texttt{\small 50}) finch 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ù -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}. @@ -1899,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). -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 @@ -1933,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 -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 - 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.