X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=811d9b196310f3c67f9056baed227efed9489e3d;hp=bff4ab76588c225940a296fbfd7e003b17838bdf;hb=7b63698a1ef54d7274e2c14065d62260644abde0;hpb=8dfb3e378ecbbd8d2c84ef46da9c9002465ef4dd diff --git a/fileadv.tex b/fileadv.tex index bff4ab7..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} @@ -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 -\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 @@ -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 -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 @@ -1545,9 +1553,10 @@ il \acr{pid} del processo che detiene il lock. \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 @@ -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 - 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} @@ -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 -(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 -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 @@ -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. -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} + \centering \includegraphics[width=9cm]{img/file_lock_dead} \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 @@ -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}. - -\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} -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 @@ -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. +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ù -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}. @@ -1689,7 +1973,7 @@ utilizza la funzione \func{lockf}, il cui prototipo } \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}. @@ -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). -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 @@ -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 -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.