\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
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
\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
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}
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
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=9cm]{img/file_lock_dead}
\caption{Schema di una situazione di \textit{deadlock}.}
\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
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.
+
\subsection{La funzione \func{lockf}}
\label{sec:file_lockf}
}
\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}.
projects / gapil.git / blobdiff