+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.
+
+Come esempio dell'uso di questa funzione si è scritto un programma che
+permette di bloccare una sezione a piacere di un qualunque file; in
+\figref{fig:file_flock_code} è riportata la sezione principale del codice del
+programma, (il testo completo è allegato nella directory dei sorgenti).
+
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}{}
+int main(int argc, char *argv[])
+{
+/*
+ * Variables definition
+ */
+ int type = F_UNLCK;
+ off_t start;
+ off_t len;
+ int fd, res, i;
+ int cmd = F_SETLK ;
+ struct flock lock;
+ ...
+ if ((argc - optind) != 1) { /* There must be remaing parameters */
+ printf("Wrong number of arguments %d\n", argc - optind);
+ usage();
+ }
+ if (type == F_UNLCK) { /* Just lock */
+ printf("You should set a read or a write lock\n");
+ usage();
+ }
+ fd = open(argv[optind], O_RDWR);
+ if (fd < 0) {
+ perror("Wrong filename");
+ exit(1);
+ }
+ /* setting lock structure */
+ lock.l_type = type;
+ lock.l_whence = SEEK_SET;
+ lock.l_start = start;
+ lock.l_len = len;
+ /* do lock */
+ res = fcntl(fd, cmd, &lock);
+ if (res) {
+ perror("Failed lock");
+ exit(1);
+ }
+ pause();
+ return 0;
+}
+ \end{lstlisting}
+ \end{minipage}
+ \normalsize
+ \caption{Sezione principale del codice del programma \file{Flock.c}.}
+ \label{fig:file_flock_code}
+\end{figure}
+
+La parte più complessa del programma è in realtà la logica della gestione
+delle opzioni (che qui si è omessa), che 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 con \cmd{-w} e \cmd{-r} si richiede rispettivamente un write
+lock o read lock.
+
projects / gapil.git / commitdiff