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
\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}
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.}
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
\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 delle due semantiche
-disponibili stanno usando i programmi con cui si interagisce, dato che
-applicare dei lock usando l'altra non avrebbe nessun effetto.
+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.
\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}.
\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
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.
projects / gapil.git / blobdiff