Figure per il deadlock, e programma di prova per il file locking
[gapil.git] / fileadv.tex
1 \chapter{La gestione avanzata dei file}
2 \label{cha:file_advanced}
3
4 In questo capitolo affronteremo le tematiche relative alla gestione avanzata
5 dei file, che non sono state trattate in \capref{cha:file_unix_interface},
6 dove ci si è limitati ad una panoramica delle funzioni base. In particolare
7 tratteremo delle funzioni di input/output avanzato e del \textit{file
8   locking}.
9
10
11 \section{Le funzioni di I/O avanzato}
12 \label{sec:file_advanced_io}
13
14 In questa sezione esamineremo le funzioni che permettono una gestione più
15 sofisticata dell'I/O su file, a partire da quelle che permettono di gestire
16 l'accesso contemporaneo a più file, per concludere con la gestione dell'I/O
17 mappato in memoria.
18
19
20 \subsection{La modalità di I/O \textsl{non-bloccante}}
21 \label{sec:file_noblocking}
22
23 Abbiamo visto in \secref{sec:sig_gen_beha}, affrontando la suddivisione fra
24 \textit{fast} e \textit{slow} system call, che in certi casi le funzioni di
25 I/O possono bloccarsi indefinitamente.\footnote{si ricordi però che questo può
26   accadere solo per le pipe, i socket ed alcuni file di dispositivo; sui file
27   normali le funzioni di lettura e scrittura ritornano sempre subito.}  Ad
28 esempio le operazioni di lettura possono bloccarsi quando non ci sono dati
29 disponibili sul descrittore su cui si sta operando.
30
31 Questo comportamento causa uno dei problemi più comuni che ci si trova ad
32 affrontare nelle operazioni di I/O, che è quello che si verifica quando si
33 devono eseguire operazioni che possono bloccarsi su più file descriptor:
34 mentre si è bloccati su uno di essi su di un'altro potrebbero essere presenti
35 dei dati; così che nel migliore dei casi si avrebbe una lettura ritardata
36 inutilmente, e nel peggiore si potrebbe addirittura arrivare ad un
37 \textit{deadlock}.
38
39 Abbiamo già accennato in \secref{sec:file_open} che è possibile prevenire
40 questo tipo di comportamento aprendo un file in modalità
41 \textsl{non-bloccante}, attraverso l'uso del flag \macro{O\_NONBLOCK} nella
42 chiamata di \func{open}. In questo caso le funzioni di input/output che
43 altrimenti si sarebbero bloccate ritornano immediatamente, restituendo
44 l'errore \macro{EAGAIN}.
45
46 L'utilizzo di questa modalità di I/O permette di risolvere il problema
47 controllando a turno i vari file descriptor, in un ciclo in cui si ripete
48 l'accesso fintanto che esso non viene garantito.  Ovviamente questa tecnica,
49 detta \textit{polling}\index{polling}, è estremamente inefficiente: si tiene
50 costantemente impiegata la CPU solo per eseguire in continuazione delle system
51 call che nella gran parte dei casi falliranno. Per evitare questo, come
52 vedremo in \secref{sec:file_multiplexing}, è stata introdotta una nuova
53 interfaccia di programmazione, che comporta comunque l'uso della modalità di
54 I/O non bloccante.
55
56
57
58 \subsection{L'I/O multiplexing}
59 \label{sec:file_multiplexing}
60
61 Per superare il problema di dover usare il \textit{polling}\index{polling} per
62 controllare la possibilità di effettuare operazioni su un file aperto in
63 modalità non bloccante, sia BSD che System V hanno introdotto delle nuove
64 funzioni in grado di sospendere l'esecuzione di un processo in attesa che
65 l'accesso diventi possibile.  Il primo ad introdurre questa modalità di
66 operazione, chiamata usualmente \textit{I/O multiplexing}, è stato
67 BSD,\footnote{la funzione è apparsa in BSD4.2 e standardizzata in BSD4.4, ma è
68   stata portata su tutti i sistemi che supportano i \textit{socket}, compreso
69   le varianti di System V.}  con la funzione \func{select}, il cui prototipo
70 è:
71 \begin{functions}
72   \headdecl{sys/time.h}
73   \headdecl{sys/types.h}
74   \headdecl{unistd.h}
75   \funcdecl{int select(int n, fd\_set *readfds, fd\_set *writefds, fd\_set
76     *exceptfds, struct timeval *timeout)}
77   
78   Attende che uno dei file descriptor degli insiemi specificati diventi
79   attivo.
80   
81   \bodydesc{La funzione in caso di successo restituisce il numero di file
82     descriptor (anche nullo) che sono attivi, e -1 in caso di errore, nel qual
83     caso \var{errno} assumerà uno dei valori:
84   \begin{errlist}
85   \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato in uno
86   degli insiemi.
87   \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
88   \item[\macro{EINVAL}] Si è specificato per \param{n} un valore negativo.
89   \end{errlist}
90   ed inoltre \macro{ENOMEM}.
91 }
92 \end{functions}
93
94 La funzione mette il processo in stato di \textit{sleep} (vedi
95 \tabref{tab:proc_proc_states}) fintanto che almeno uno dei file descriptor
96 degli insiemi specificati (\param{readfds}, \param{writefds} e
97 \param{exceptfds}), non diventa attivo, per un tempo massimo specificato da
98 \param{timeout}.
99
100 Per specificare quali file descriptor si intende \textsl{selezionare}, la
101 funzione usa un particolare oggetto, il \textit{file descriptor set},
102 identificato dal tipo \type{fd\_set}, che serve ad identificare un insieme di
103 file descriptor, (in maniera analoga a come un \textit{signal set}, vedi
104 \secref{sec:sig_sigset}, identifica un insieme di segnali). Per la
105 manipolazione di questi \textit{file descriptor set} si possono usare delle
106 opportune macro di preprocessore:
107 \begin{functions}
108   \headdecl{sys/time.h}
109   \headdecl{sys/types.h}
110   \headdecl{unistd.h}
111   \funcdecl{FD\_ZERO(fd\_set *set)}
112   Inizializza l'insieme (vuoto).
113
114   \funcdecl{FD\_SET(int fd, fd\_set *set)}
115   Inserisce il file descriptor \param{fd} nell'insieme.
116
117   \funcdecl{FD\_CLR(int fd, fd\_set *set)}
118   Rimuove il file descriptor \param{fd} nell'insieme.
119   
120   \funcdecl{FD\_ISSET(int fd, fd\_set *set)}
121   Controlla se il file descriptor \param{fd} è nell'insieme.
122 \end{functions}
123
124 In genere un \textit{file descriptor set} può contenere fino ad un massimo di
125 \macro{FD\_SETSIZE} file descriptor.  Questo valore in origine corrispondeva
126 al limite per il numero massimo di file aperti\footnote{ad esempio in Linux,
127   fino alla serie 2.0.x, c'era un limite di 256 file per processo.}, ma
128 quando, come nelle versioni più recenti del kernel, non c'è più un limite
129 massimo, esso indica le dimensioni massime dei numeri usati nei \textit{file
130   descriptor set}.
131
132 La funzione richiede di specificare tre insiemi distinti di file descriptor;
133 il primo, \param{readfds}, verrà osservato per rilevare la disponibilità di
134 effettuare una lettura, il secondo, \param{writefds}, per verificare la
135 possibilità effettuare una scrittura ed il terzo, \param{exceptfds}, per
136 verificare l'esistenza di condizioni eccezionali (come i messaggi urgenti su
137 un \textit{socket}\index{socket}, vedi \secref{sec:xxx_urgent}).
138
139 La funzione inoltre richiede anche di specificare, tramite l'argomento
140 \param{n}, un valore massimo del numero dei file descriptor usati
141 nell'insieme; si può usare il già citato \macro{FD\_SETSIZE}, oppure il numero
142 più alto dei file descriptor usati nei tre insiemi, aumentato di uno.
143
144 Infine l'argomento \param{timeout}, specifica un tempo massimo di
145 attesa\footnote{il tempo è valutato come \textit{elapsed time}.} prima che la
146 funzione ritorni; se impostato a \macro{NULL} la funzione attende
147 indefinitamente. Si può specificare anche un tempo nullo (cioè una \var{struct
148   timeval} con i campi impostati a zero), qualora si voglia semplicemente
149 controllare lo stato corrente dei file descriptor.
150
151 La funzione restituisce il totale dei file descriptor pronti nei tre insiemi,
152 il valore zero indica sempre che si è raggiunto un timeout. Ciascuno dei tre
153 insiemi viene sovrascritto per indicare quale file descriptor è pronto per le
154 operazioni ad esso relative, in modo da poterlo controllare con la macro
155 \macro{FD\_ISSET}. In caso di errore la funzione restituisce -1 e gli insiemi
156 non vengono toccati.
157
158 In Linux \func{select} modifica anche il valore di \param{timeout},
159 impostandolo al tempo restante; questo è utile quando la funzione viene
160 interrotta da un segnale, in tal caso infatti si ha un errore di
161 \macro{EINTR}, ed occorre rilanciare la funzione; in questo modo non è
162 necessario ricalcolare tutte le volte il tempo rimanente.\footnote{questo può
163   causare problemi di portabilità sia quando si trasporta codice scritto su
164   Linux che legge questo valore, sia quando si usano programmi scritti per
165   altri sistemi che non dispongono di questa caratteristica e ricalcolano
166   \param{timeout} tutte le volte. In genere la caratteristica è disponibile
167   nei sistemi che derivano da System V e non disponibile per quelli che
168   derivano da BSD.}
169
170 Come accennato l'interfaccia di \func{select} è una estensione di BSD; anche
171 System V ha introdotto una sua interfaccia per gestire l'\textit{I/O
172   multiplexing}, basata sulla funzione \func{poll},\footnote{la funzione è
173   prevista dallo standard XPG4, ed è stata introdotta in Linux come system
174   call a partire dal kernel 2.1.23 e dalle \acr{libc} 5.4.28.} il cui
175 prototipo è:
176 \begin{prototype}{sys/poll.h}
177   {int poll(struct pollfd *ufds, unsigned int nfds, int timeout)}
178
179 La funzione attente un cambiamento di stato per uno dei file descriptor
180 specificati da \param{ufds}.
181   
182 \bodydesc{La funzione restituisce il numero di file descriptor con attività in
183   caso di successo, o 0 se c'è stato un timeout; in caso di errore viene
184   restituito  -1 ed \var{errno} assumerà uno dei valori:
185   \begin{errlist}
186   \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato in uno
187   degli insiemi.
188   \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
189   \end{errlist}
190   ed inoltre \macro{EFAULT} e \macro{ENOMEM}.}
191 \end{prototype}
192
193 La funzione tiene sotto controllo un numero \param{ndfs} di file descriptor
194 specificati attraverso un vettore di puntatori a strutture di tipo
195 \type{pollfd}, la cui definizione è riportata in \figref{fig:file_pollfd}.
196 Come \func{select} anche \func{poll} permette di interrompere l'attesa dopo un
197 certo tempo, che va specificato attraverso \param{timeout} in numero di
198 millisecondi (un valore negativo indica un'attesa indefinita).
199
200 \begin{figure}[!htb]
201   \footnotesize \centering
202   \begin{minipage}[c]{15cm}
203     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
204 struct pollfd {
205         int fd;           /* file descriptor */
206         short events;     /* requested events */
207         short revents;    /* returned events */
208 };
209     \end{lstlisting}
210   \end{minipage} 
211   \normalsize 
212   \caption{La struttura \type{pollfd}, utilizzata per specificare le modalità
213     di controllo di un file descriptor alla funzione \func{poll}.}
214   \label{fig:file_pollfd}
215 \end{figure}
216
217 Per ciascun file da controllare deve essere opportunamente predisposta una
218 struttura \type{pollfd}; nel campo \var{fd} deve essere specificato il file
219 descriptor, mentre nel campo \var{events} il tipo di evento su cui si vuole
220 attendere; quest'ultimo deve essere specificato come maschera binaria dei
221 primi tre valori riportati in \tabref{tab:file_pollfd_flags} (gli altri
222 vengono utilizzati solo per \var{revents} come valori in uscita).
223
224 \begin{table}[htb]
225   \centering
226   \footnotesize
227   \begin{tabular}[c]{|l|c|l|}
228     \hline
229     \textbf{Flag} & \textbf{Valore} & \textbf{Significato} \\
230     \hline
231     \hline
232     \macro{POLLIN}    & 0x001 & È possibile la lettura immediata.\\
233     \macro{POLLPRI}   & 0x002 & Sono presenti dati urgenti.\\
234     \macro{POLLOUT}   & 0x004 & È possibile la scrittura immediata.\\
235     \hline
236     \macro{POLLERR}   & 0x008 & C'è una condizione di errore.\\
237     \macro{POLLHUP}   & 0x010 & Si è verificato un hung-up.\\
238     \macro{POLLNVAL}  & 0x020 & Il file descriptor non è aperto.\\
239     \hline
240     \macro{POLLRDNORM}& 0x040 & Sono disponibili in lettura dati normali.\\ 
241     \macro{POLLRDBAND}& 0x080 & Sono disponibili in lettura dati ad alta 
242                                 priorità. \\
243     \macro{POLLWRNORM}& 0x100 & È possibile la scrittura di dati normali.  \\ 
244     \macro{POLLWRBAND}& 0x200 & È possibile la scrittura di dati ad 
245                                 alta priorità. \\
246     \macro{POLLMSG}   & 0x400 & Estensione propria di Linux.\\
247     \hline    
248   \end{tabular}
249   \caption{Costanti per l'identificazione dei vari bit dei campi
250     \var{events} e \var{revents} di \type{pollfd}.}
251   \label{tab:file_pollfd_flags}
252 \end{table}
253
254 La funzione ritorna, restituendo il numero di file per i quali si è verificata
255 una delle condizioni di attesa richieste od un errore. Lo stato dei file
256 all'uscita della funzione viene restituito nel campo \var{revents} della
257 relativa struttura \type{pollfd}, che viene impostato alla maschera binaria
258 dei valori riportati in \tabref{tab:file_pollfd_flags}, ed oltre alle tre
259 condizioni specificate tramite \var{events} può riportare anche l'occorrere di
260 una condizione di errore.
261
262 Lo standard POSIX è rimasto a lungo senza primitive per l'\textit{I/O
263   multiplexing}, che è stata introdotto con le ultime revisioni dello standard
264 (POSIX 1003.1g-2000 e POSIX 1003.1-2001). Esso prevede che tutte le funzioni
265 ad esso relative vengano dichiarate nell'header \file{sys/select.h}, che
266 sostituisce i precedenti, ed aggiunge a \func{select} una nuova funzione
267 \func{pselect},\footnote{il supporto per lo standard POSIX 1003.1-2001, ed
268   l'header \file{sys/select.h}, compaiono in Linux a partire dalle \acr{glibc}
269   2.1. Le \acr{libc4} e \acr{libc5} non contengono questo header, le
270   \acr{glibc} 2.0 contengono una definizione sbagliata di \func{psignal},
271   senza l'argomento \param{sigmask}, la definizione corretta è presente dalle
272   \acr{glibc} 2.1-2.2.1 se si è definito \macro{\_GNU\_SOURCE} e nelle
273   \acr{glibc} 2.2.2-2.2.4 se si è definito \macro{\_XOPEN\_SOURCE} con valore
274   maggiore di 600.} il cui prototipo è:
275 \begin{prototype}{sys/select.h}
276   {int pselect(int n, fd\_set *readfds, fd\_set *writefds, fd\_set *exceptfds,
277     struct timespec *timeout, sigset\_t *sigmask)}
278   
279   Attende che uno dei file descriptor degli insiemi specificati diventi
280   attivo.
281   
282   \bodydesc{La funzione in caso di successo restituisce il numero di file
283     descriptor (anche nullo) che sono attivi, e -1 in caso di errore, nel qual
284     caso \var{errno} assumerà uno dei valori:
285   \begin{errlist}
286   \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato in uno
287   degli insiemi.
288   \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
289   \item[\macro{EINVAL}] Si è specificato per \param{n} un valore negativo.
290   \end{errlist}
291   ed inoltre \macro{ENOMEM}.}
292 \end{prototype}
293
294 La funzione è sostanzialmente identica a \func{select}, solo che usa una
295 struttura \type{timespec} per indicare con maggiore precisione il timeout e
296 non ne aggiorna il valore in caso di interruzione, inoltre prende un argomento
297 aggiuntivo \param{sigmask} che è il puntatore ad una maschera di segnali (si
298 veda \secref{sec:sig_sigmask}). La maschera corrente viene sostituita da
299 questa immediatamente prima di eseguire l'attesa, e ripristinata al ritorno
300 della funzione.
301
302 L'uso di \param{sigmask} è stato introdotto allo scopo di prevenire possibili
303 race condition\footnote{in Linux però, non esistendo una system call apposita,
304   la funzione è implementata nelle \acr{glibc} usando \func{select}, e la
305   possibilità di una race condition resta.} quando si deve eseguire un test su
306 una variabile assegnata da un manipolatore sulla base dell'occorrenza di un
307 segnale per decidere se lanciare \func{select}. Fra il test e l'esecuzione è
308 presente una finestra in cui potrebbe arrivare il segnale che non sarebbe
309 rilevato; la race condition diventa superabile disabilitando il segnale prima
310 del test e riabilitandolo poi grazie all'uso di \param{sigmask}.
311
312
313
314 \subsection{L'I/O asincrono}
315 \label{sec:file_asyncronous_io}
316
317 Una modalità alternativa all'uso dell'\textit{I/O multiplexing} è quella di
318 fare ricorso al cosiddetto \textsl{I/O asincrono}. Il concetto base
319 dell'\textsl{I/O asincrono} è che le funzioni di I/O non attendono il
320 completamento delle operazioni prima di ritornare, così che il processo non
321 viene bloccato.  In questo modo diventa ad esempio possibile effettuare una
322 richiesta preventiva di dati, in modo da poter effettuare in contemporanea le
323 operazioni di calcolo e quelle di I/O.
324
325 Abbiamo accennato in \secref{sec:file_open} che è possibile, attraverso l'uso
326 del flag \macro{O\_ASYNC},\footnote{l'uso del flag di \macro{O\_ASYNC} e dei
327   comandi \macro{F\_SETOWN} e \macro{F\_GETOWN} per \func{fcntl} è specifico
328   di Linux e BSD.} aprire un file in modalità asincrona, così come è possibile
329 attivare in un secondo tempo questa modalità impostando questo flag attraverso
330 l'uso di \func{fcntl} con il comando \macro{F\_SETFL} (vedi
331 \secref{sec:file_fcntl}).
332
333 In realtà in questo caso non si tratta di I/O asincrono vero e proprio, quanto
334 di un meccanismo asincrono di notifica delle variazione dello stato del file
335 descriptor; quello che succede è che il sistema genera un segnale (normalmente
336 \macro{SIGIO}, ma è possibile usarne altri) tutte le volte che diventa
337 possibile leggere o scrivere dal file descriptor che si è posto in questa
338 modalità. Si può inoltre selezionare, con il comando \macro{F\_SETOWN} di
339 \func{fcntl}, quale processo (o gruppo di processi) riceverà il segnale. 
340
341 In questo modo si può evitare l'uso delle funzioni \func{poll} o \func{select}
342 che, quando vengono usate con un numero molto grande di file descriptor, non
343 hanno buone prestazioni. In tal caso infatti la maggior parte del loro tempo
344 di esecuzione è impegnato ad eseguire una scansione su tutti i file descriptor
345 tenuti sotto controllo per determinare quali di essi (in genere una piccola
346 percentuale) sono diventati attivi.
347
348 Tuttavia con l'implementazione classica dei segnali questa modalità di I/O
349 presenta notevoli problemi, dato che non è possibile determinare, quando sono
350 più di uno, qual'è il file descriptor responsabile dell'emissione del segnale.
351 Linux però supporta le estensioni POSIX.1b dei segnali che permettono di
352 superare il problema facendo ricorso alle informazioni aggiuntive restituite
353 attraverso la struttura \type{siginfo\_t}, utilizzando la forma estesa
354 \var{sa\_sigaction} del manipolatore (si riveda quanto illustrato in
355 \secref{sec:sig_sigaction}).
356
357 Per far questo però occorre utilizzare le funzionalità dei segnali real-time
358 (vedi \secref{sec:sig_real_time}) impostando esplicitamente con il comando
359 \macro{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare in caso di
360 I/O asincrono (il segnale predefinito è \macro{SIGIO}). In questo caso il
361 manipolatore tutte le volte che riceverà \macro{SI\_SIGIO} come valore del
362 campo \var{si\_code}\footnote{il valore resta \macro{SI\_SIGIO} qualunque sia
363   il segnale che si è associato all'I/O asincrono, ed indica appunto che il
364   segnale è stato generato a causa di attività nell'I/O asincrono.} di
365 \type{siginfo\_t}, troverà nel campo \var{si\_fd} il valore del file
366 descriptor che ha generato il segnale.
367
368 Un secondo vantaggio dell'uso dei segnali real-time è che essendo dotati di
369 una coda di consegna ogni segnale sarà associato ad uno solo file descriptor;
370 inoltre sarà possibile stabilire delle priorità nella risposta a seconda del
371 segnale usato. In questo modo si può identificare immediatamente un file su
372 cui l'accesso è diventato possibile evitando completamente l'uso di funzioni
373 come \func{poll} e \func{select}, almeno fintanto che non si satura la coda;
374 si eccedono le dimensioni di quest'ultima; in tal caso infatti il kernel, non
375 potendo più assicurare il comportamento corretto per un segnale real-time,
376 invierà al suo posto un \var{SIGIO}, su cui si accumuleranno tutti i segnali
377 in eccesso, e si dovrà determinare al solito modo quali sono i file diventati
378 attivi.
379
380 Benché la modalità di apertura asincrona di un file possa risultare utile in
381 varie occasioni (in particolar modo con i socket e gli altri file per i quali
382 le funzioni di I/O sono system call lente), essa è comunque limitata alla
383 notifica della disponibilità del file descriptor per le operazioni di I/O, e
384 non ad uno svolgimento asincrono delle medesime.  Lo standard POSIX.1b
385 definisce anche una interfaccia apposita per l'I/O asincrono, che prevede un
386 insieme di funzioni dedicate, completamente separate rispetto a quelle usate
387 normalmente.
388
389 In generale questa interfaccia è completamente astratta e può essere
390 implementata sia direttamente nel kernel, che in user space attraverso l'uso
391 di thread. Al momento\footnote{fino ai kernel della serie 2.4.x, nella serie
392   2.5.x è però iniziato un lavoro completo di riscrittura di tutto il sistema
393   di I/O, che prevede anche l'introduzione di un nuovo layer per l'I/O
394   asincrono (effettuato a partire dal 2.5.32).} esiste una sola versione
395 stabile di questa interfaccia, quella delle \acr{glibc}, che è realizzata
396 completamente in user space.  Esistono comunque vari progetti sperimentali
397 (come il KAIO della SGI, o i patch di Benjamin La Haise) che prevedono un
398 supporto diretto da parte del kernel.
399
400 Lo standard prevede che tutte le operazioni di I/O asincrono siano controllate
401 attraverso l'uso di una apposita struttura \type{aiocb} (il cui nome sta per
402 \textit{asyncronous I/O control block}), che viene passata come argomento a
403 tutte le funzioni dell'interfaccia. La sua definizione, come effettuata in
404 \file{aio.h}, è riportata in \figref{fig:file_aiocb}. Nello steso file è
405 definita la macro \macro{\_POSIX\_ASYNCHRONOUS\_IO}, che dichiara la
406 disponibilità dell'interfaccia per l'I/O asincrono.
407
408 \begin{figure}[!htb]
409   \footnotesize \centering
410   \begin{minipage}[c]{15cm}
411     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
412 struct aiocb
413 {
414     int aio_fildes;               /* File descriptor.  */
415     off_t aio_offset;             /* File offset */
416     int aio_lio_opcode;           /* Operation to be performed.  */
417     int aio_reqprio;              /* Request priority offset.  */
418     volatile void *aio_buf;       /* Location of buffer.  */
419     size_t aio_nbytes;            /* Length of transfer.  */
420     struct sigevent aio_sigevent; /* Signal number and value.  */
421 };
422     \end{lstlisting}
423   \end{minipage} 
424   \normalsize 
425   \caption{La struttura \type{aiocb}, usata per il controllo dell'I/O
426     asincrono.}
427   \label{fig:file_aiocb}
428 \end{figure}
429
430 Le operazioni di I/O asincrono possono essere effettuate solo su un file già
431 aperto; il file deve inoltre supportare la funzione \func{lseek},
432 pertanto terminali e pipe sono esclusi. Non c'è limite al numero di operazioni
433 contemporanee effettuabili su un singolo file.
434
435 Ogni operazione deve inizializzare opportunamente un \textit{control block}.
436 Il file descriptor su cui operare deve essere specificato tramite il campo
437 \var{aio\_fildes}; dato che più operazioni possono essere eseguita in maniera
438 asincrona, il concetto di posizione corrente sul file viene a mancare;
439 pertanto si deve sempre specificare nel campo \var{aio\_offset} la posizione
440 sul file da cui i dati saranno letti o scritti.  Nel campo \var{aio\_buf} deve
441 essere specificato l'indirizzo del buffer usato per l'I/O, ed in
442 \var{aio\_nbytes} la lunghezza del blocco di dati da trasferire.
443
444 Il campo \var{aio\_reqprio} permette di impostare la priorità delle operazioni
445 di I/O.\footnote{in generale perché ciò sia possibile occorre che la
446   piattaforma supporti questa caratteristica, questo viene indicato definendo
447   le macro \macro{\_POSIX\_PRIORITIZED\_IO}, e
448   \macro{\_POSIX\_PRIORITY\_SCHEDULING}.} La priorità viene impostata a
449 partire da quella del processo chiamante (vedi \secref{sec:proc_priority}),
450 cui viene sottratto il valore di questo campo.
451
452 Il campo \var{aio\_lio\_opcode} è usato soltanto dalla funzione
453 \func{lio\_listio}, che, come vedremo più avanti, permette di eseguire con una
454 sola chiamata una serie di operazioni, usando un vettore di \textit{control
455   block}. Tramite questo campo si specifica quale è la natura di ciascuna di
456 esse.
457
458 \begin{figure}[!htb]
459   \footnotesize \centering
460   \begin{minipage}[c]{15cm}
461     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
462 struct sigevent
463 {
464     sigval_t sigev_value;
465     int sigev_signo;
466     int sigev_notify;
467     sigev_notify_function;
468     sigev_notify_attributes;
469 };
470     \end{lstlisting}
471   \end{minipage} 
472   \normalsize 
473   \caption{La struttura \type{sigevent}, usata per specificare le modalità di
474     notifica degli eventi relativi alle operazioni di I/O asincrono.}
475   \label{fig:file_sigevent}
476 \end{figure}
477
478 Infine il campo \var{aio\_sigevent} è una struttura di tipo \type{sigevent}
479 che serve a specificare il modo in cui si vuole che venga effettuata la
480 notifica del completamento delle operazioni richieste. La struttura è
481 riportata in \secref{fig:file_sigevent}; il campo \var{sigev\_notify} è quello
482 che indica le modalità della notifica, esso può assumere i tre valori:
483 \begin{basedescript}{\desclabelwidth{3.0cm}}
484 \item[\macro{SIGEV\_NONE}]   Non viene inviata nessuna notifica.
485 \item[\macro{SIGEV\_SIGNAL}] La notifica viene effettuata inviando al processo
486   chiamante il segnale specificato nel campo \var{sigev\_signo}, se il
487   manipolatore è installato con \macro{SA\_SIGINFO}, il gli verrà restituito
488   il valore di \var{sigev\_value} in come valore del campo \var{si\_value} per
489   \type{siginfo\_t}.
490 \item[\macro{SIGEV\_THREAD}] La notifica viene effettuata creando un nuovo
491   thread che esegue la funzione specificata da \var{sigev\_notify\_function},
492   con gli attributi specificati da \var{sigev\_notify\_attribute}.
493 \end{basedescript}
494
495 Le due funzioni base dell'interfaccia per l'I/O asincrono sono
496 \func{aio\_read} ed \func{aio\_write}.  Esse permettono di richiedere una
497 lettura od una scrittura asincrona di dati, usando la struttura \type{aiocb}
498 appena descritta; i rispettivi prototipi sono:
499 \begin{functions}
500   \headdecl{aio.h}
501
502   \funcdecl{int aio\_read(struct aiocb *aiocbp)}
503   Richiede una lettura asincrona secondo quanto specificato con \param{aiocbp}.
504
505   \funcdecl{int aio\_write(struct aiocb *aiocbp)}
506   Richiede una scrittura asincrona secondo quanto specificato con
507   \param{aiocbp}.
508   
509   \bodydesc{Le funzioni restituiscono 0 in caso di successo, e -1 in caso di
510     errore, nel qual caso \var{errno} assumerà uno dei valori:
511   \begin{errlist}
512   \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato.
513   \item[\macro{ENOSYS}] La funzione non è implementata.
514   \item[\macro{EINVAL}] Si è specificato un valore non valido per i campi
515     \var{aio\_offset} o \var{aio\_reqprio} di \param{aiocbp}.
516   \item[\macro{EAGAIN}] La coda delle richieste è momentaneamente piena.
517   \end{errlist}
518 }
519 \end{functions}
520
521 Entrambe le funzioni ritornano immediatamente dopo aver messo in coda la
522 richiesta, o in caso di errore. Non è detto che gli errori \macro{EBADF} ed
523 \macro{EINVAL} siano rilevati immediatamente al momento della chiamata,
524 potrebbero anche emergere nelle fasi successive delle operazioni. Lettura e
525 scrittura avvengono alla posizione indicata da \var{aio\_offset}, a meno che
526 il file non sia stato aperto in \textit{append mode} (vedi
527 \secref{sec:file_open}), nel qual caso le scritture vengono effettuate
528 comunque alla fine de file, nell'ordine delle chiamate a \func{aio\_write}.
529
530 Si tenga inoltre presente che deallocare la memoria indirizzata da
531 \param{aiocbp} o modificarne i valori prima della conclusione di una
532 operazione può dar luogo a risultati impredicibili, perché l'accesso ai vari
533 campi per eseguire l'operazione può avvenire in un momento qualsiasi dopo la
534 richiesta.  Questo comporta che occorre evitare di usare per \param{aiocbp}
535 variabili automatiche e che non si deve riutilizzare la stessa struttura per
536 un ulteriore operazione fintanto che la precedente non sia stata ultimata. In
537 generale per ogni operazione di I/O asincrono si deve utilizzare una diversa
538 struttura \type{aiocb}.
539
540 Dato che si opera in modalità asincrona, il successo di \func{aio\_read} o
541 \func{aio\_write} non implica che le operazioni siano state effettivamente
542 eseguite in maniera corretta; per verificarne l'esito l'interfaccia prevede
543 altre due funzioni, che permettono di controllare lo stato di esecuzione. La
544 prima è \func{aio\_error}, che serve a determinare un eventuale stato di
545 errore; il suo prototipo è:
546 \begin{prototype}{aio.h}
547   {int aio\_error(const struct aiocb *aiocbp)}  
548
549   Determina lo stato di errore delle operazioni di I/O associate a
550   \param{aiocbp}.
551   
552   \bodydesc{La funzione restituisce 0 se le operazioni si sono concluse con
553     successo, altrimenti restituisce il codice di errore relativo al loro
554     fallimento.}
555 \end{prototype}
556
557 Se l'operazione non si è ancora completata viene restituito l'errore di
558 \macro{EINPROGRESS}. La funzione ritorna zero quando l'operazione si è
559 conclusa con successo, altrimenti restituisce il codice dell'errore
560 verificatosi, ed esegue la corrispondente impostazione di \var{errno}. Il
561 codice può essere sia \macro{EINVAL} ed \macro{EBADF}, dovuti ad un valore
562 errato per \param{aiocbp}, che uno degli errori possibili durante l'esecuzione
563 dell'operazione di I/O richiesta, nel qual caso saranno restituiti, a seconda
564 del caso, i codici di errore delle system call \func{read}, \func{write} e
565 \func{fsync}.
566
567 Una volta che si sia certi che le operazioni siano state concluse (cioè dopo
568 che una chiamata ad \func{aio\_error} non ha restituito \macro{EINPROGRESS},
569 si potrà usare la seconda funzione dell'interfaccia, \func{aio\_return}, che
570 permette di verificare il completamento delle operazioni di I/O asincrono; il
571 suo prototipo è:
572 \begin{prototype}{aio.h}
573 {ssize\_t aio\_return(const struct aiocb *aiocbp)} 
574
575 Recupera il valore dello stato di ritorno delle operazioni di I/O associate a
576 \param{aiocbp}.
577   
578 \bodydesc{La funzione restituisce lo stato di uscita dell'operazione
579   eseguita.}
580 \end{prototype}
581
582 La funzione deve essere chiamata una sola volte per ciascuna operazione
583 asincrona, essa infatti fa sì che il sistema rilasci le risorse ad essa
584 associate. É per questo motivo che occorre chiamare la funzione solo dopo che
585 l'operazione cui \param{aiocbp} fa riferimento si è completata. Una chiamata
586 precedente il completamento delle operazioni darebbe risultati indeterminati.
587
588 La funzione restituisce il valore di ritorno relativo all'operazione eseguita,
589 così come ricavato dalla sottostante system call (il numero di byte letti,
590 scritti o il valore di ritorno di \func{fsync}).  É importante chiamare sempre
591 questa funzione, altrimenti le risorse disponibili per le operazioni di I/O
592 asincrono non verrebbero liberate, rischiando di arrivare ad un loro
593 esaurimento.
594
595 Oltre alle operazioni di lettura e scrittura l'interfaccia POSIX.1b mette a
596 disposizione un'altra operazione, quella di sincronizzazione dell'I/O, essa è
597 compiuta dalla funzione \func{aio\_fsync}, che ha lo stesso effetto della
598 analoga \func{fsync}, ma viene eseguita in maniera asincrona; il suo prototipo
599 è:
600 \begin{prototype}{aio.h}
601 {ssize\_t aio\_return(int op, struct aiocb *aiocbp)} 
602
603 Richiede la sincronizzazione dei dati per il file indicato da \param{aiocbp}.
604   
605 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
606   errore, che può essere, con le stesse modalità di \func{aio\_read},
607   \macro{EAGAIN}, \macro{EBADF} o \macro{EINVAL}.}
608 \end{prototype}
609
610 La funzione richiede la sincronizzazione delle operazioni di I/O, ritornando
611 immediatamente. L'esecuzione effettiva della sincronizzazione dovrà essere
612 verificata con \func{aio\_error} e \func{aio\_return} come per le operazioni
613 di lettura e scrittura. L'argomento \param{op} permette di indicare la
614 modalità di esecuzione, se si specifica il valore \macro{O\_DSYNC} le
615 operazioni saranno completate con una chiamata a \func{fdatasync}, se si
616 specifica \macro{O\_SYNC} con una chiamata a \func{fsync} (per i dettagli vedi
617 \secref{sec:file_sync}).
618
619 Il successo della chiamata assicura la sincronizzazione delle operazioni fino
620 allora richieste, niente è garantito riguardo la sincronizzazione dei dati
621 relativi ad eventuali operazioni richieste successivamente. Se si è
622 specificato un meccanismo di notifica questo sarà innescato una volta che le
623 operazioni di sincronizzazione dei dati saranno completate.
624
625 In alcuni casi può essere necessario interrompere le operazioni (in genere
626 quando viene richiesta un'uscita immediata dal programma), per questo lo
627 standard POSIX.1b prevede una funzioni apposita, \func{aio\_cancel}, che
628 permette di cancellare una operazione richiesta in precedenza; il suo
629 prototipo è:
630 \begin{prototype}{aio.h}
631 {int aio\_cancel(int fildes, struct aiocb *aiocbp)} 
632
633 Richiede la cancellazione delle operazioni sul file \param{fildes} specificate
634 da \param{aiocbp}.
635   
636 \bodydesc{La funzione restituisce il risultato dell'operazione con un codice
637   di positivo, e -1 in caso di errore, che avviene qualora si sia specificato
638   un valore non valido di \param{fildes}, imposta \var{errno} al valore
639   \macro{EBADF}.}
640 \end{prototype}
641
642 La funzione permette di cancellare una operazione specifica sul file
643 \param{fildes}, o tutte le operazioni pendenti, specificando \macro{NULL} come
644 valore di \param{aiocbp}.  Quando una operazione viene cancellata una
645 successiva chiamata ad \func{aio\_error} riporterà \macro{ECANCELED} come
646 codice di errore, ed il suo codice di ritorno sarà -1, inoltre il meccanismo
647 di notifica non verrà invocato. Se si specifica una operazione relativa ad un
648 altro file descriptor il risultato è indeterminato.
649
650 In caso di successo, i possibili valori di ritorno per \func{aio\_cancel} sono
651 tre (anch'essi definiti in \file{aio.h}):
652 \begin{basedescript}{\desclabelwidth{3.0cm}}
653 \item[\macro{AIO\_ALLDONE}] indica che le operazioni di cui si è richiesta la
654   cancellazione sono state già completate,
655   
656 \item[\macro{AIO\_CANCELED}] indica che tutte le operazioni richieste sono
657   state cancellate,  
658   
659 \item[\macro{AIO\_NOTCANCELED}] indica che alcune delle operazioni erano in
660   corso e non sono state cancellate.
661 \end{basedescript}
662
663 Nel caso si abbia \macro{AIO\_NOTCANCELED} occorrerà chiamare
664 \func{aio\_error} per determinare quali sono le operazioni effettivamente
665 cancellate. Le operazioni che non sono state cancellate proseguiranno il loro
666 corso normale, compreso quanto richiesto riguardo al meccanismo di notifica
667 del loro avvenuto completamento.
668
669 Benché l'I/O asincrono preveda un meccanismo di notifica, l'interfaccia
670 fornisce anche una apposita funzione, \func{aio\_suspend}, che permette di
671 sospendere l'esecuzione del processo chiamante fino al completamento di una
672 specifica operazione; il suo prototipo è:
673 \begin{prototype}{aio.h}
674 {int aio\_suspend(const struct aiocb * const list[], int nent, const struct
675     timespec *timeout)}
676   
677   Attende, per un massimo di \param{timeout}, il completamento di una delle
678   operazioni specificate da \param{list}.
679   
680   \bodydesc{La funzione restituisce 0 se una (o più) operazioni sono state
681     completate, e -1 in caso di errore nel qual caso \var{errno} assumerà uno
682     dei valori:
683     \begin{errlist}
684     \item[\macro{EAGAIN}] Nessuna operazione è stata completata entro
685       \param{timeout}.
686     \item[\macro{ENOSYS}] La funzione non è implementata.
687     \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
688     \end{errlist}
689   }
690 \end{prototype}
691
692 La funzione permette di bloccare il processo fintanto che almeno una delle
693 \param{nent} operazioni specificate nella lista \param{list} è completata, per
694 un tempo massimo specificato da \param{timout}, o fintanto che non arrivi un
695 segnale.\footnote{si tenga conto che questo segnale può anche essere quello
696   utilizzato come meccanismo di notifica.} La lista deve essere inizializzata
697 con delle strutture \var{aiocb} relative ad operazioni effettivamente
698 richieste, ma può contenere puntatori nulli, che saranno ignorati. In caso si
699 siano specificati valori non validi l'effetto è indefinito.  Un valore
700 \macro{NULL} per \param{timout} comporta l'assenza di timeout.
701
702 Lo standard POSIX.1b infine ha previsto pure una funzione, \func{lio\_listio},
703 che permette di effettuare la richiesta di una intera lista di operazioni di
704 lettura o scrittura; il suo prototipo è:
705 \begin{prototype}{aio.h}
706   {int lio\_listio(int mode, struct aiocb * const list[], int nent, struct
707     sigevent *sig)}
708   
709   Richiede l'esecuzione delle operazioni di I/O elencata da \param{list},
710   secondo la modalità \param{mode}.
711   
712   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
713     errore, nel qual caso \var{errno} assumerà uno dei valori:
714     \begin{errlist}
715     \item[\macro{EAGAIN}] Nessuna operazione è stata completata entro
716       \param{timeout}.
717     \item[\macro{ENOSYS}] La funzione non è implementata.
718     \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
719     \end{errlist}
720   }
721 \end{prototype}
722
723 La funzione esegue la richiesta delle \param{nent} operazioni indicate dalla
724 lista \param{list}; questa deve contenere gli indirizzi di altrettanti
725 \textit{control block}, opportunamente inizializzati; in particolare nel caso
726 dovrà essere specificato il tipo di operazione tramite il campo
727 \var{aio\_lio\_opcode}, che può prendere i tre valori:
728 \begin{basedescript}{\desclabelwidth{2.0cm}}
729 \item[\macro{LIO\_READ}]  si richiede una operazione di lettura.
730 \item[\macro{LIO\_WRITE}] si richiede una operazione di scrittura.
731 \item[\macro{LIO\_NOP}] non si effettua nessuna operazione.
732 \end{basedescript}
733 l'ultimo valore viene usato quando si ha a che fare con un vettore di
734 dimensione fissa, per poter specificare solo alcune operazioni, o quando si è
735 dovuto cancellare delle operazioni e si deve ripetere la richiesta per quelle
736 non completate.
737
738 L'argomento \param{mode} permette di stabilire il comportamento della
739 funzione, se viene specificato il valore \macro{LIO\_WAIT} la funzione si
740 blocca fino al completamento di tutte le operazioni richieste; se invece si
741 specifica \macro{LIO\_NOWAIT} la funzione ritorna immediatamente dopo aver
742 messo in coda tutte le richieste. In questo caso il chiamante può richiedere
743 la notifica del completamento di tutte le richieste, impostando l'argomento
744 \param{sig} in maniera analoga a come si fa per il campo \var{aio\_sigevent}
745 di \type{aiocb}.
746
747
748
749 \subsection{I/O vettorizzato}
750 \label{sec:file_multiple_io}
751
752 Un caso abbastanza comune è quello in cui ci si trova a dover eseguire una
753 serie multipla di operazioni di I/O, come una serie di letture o scritture di
754 vari buffer. Un esempio tipico è quando i dati sono strutturati nei campi di
755 una struttura ed essi devono essere caricati o salvati su un file.  Benché
756 l'operazione sia facilmente eseguibile attraverso una serie multipla di
757 chiamate, ci sono casi in cui si vuole poter contare sulla atomicità delle
758 operazioni.
759
760 Per questo motivo BSD 4.2\footnote{Le due funzioni sono riprese da BSD4.4 ed
761   integrate anche dallo standard Unix 98; fino alle libc5 Linux usava
762   \type{size\_t} come tipo dell'argomento \param{count}, una scelta logica,
763   che però è stata dismessa per restare aderenti allo standard.} ha introdotto
764 due nuove system call, \func{readv} e \func{writev}, che permettono di
765 effettuare con una sola chiamata una lettura o una scrittura su una serie di
766 buffer (quello che viene chiamato \textsl{I/O vettorizzato}. I relativi
767 prototipi sono:
768 \begin{functions}
769   \headdecl{sys/uio.h}
770   
771   \funcdecl{int readv(int fd, const struct iovec *vector, int count)} Esegue
772   una lettura vettorizzata da \param{fd} nei \param{count} buffer specificati
773   da \param{vector}.
774   
775   \funcdecl{int writev(int fd, const struct iovec *vector, int count)} Esegue
776   una scrittura vettorizzata da \param{fd} nei \param{count} buffer
777   specificati da \param{vector}.
778   
779   \bodydesc{Le funzioni restituiscono il numero di byte letti o scritti in
780     caso di successo, e -1 in caso di errore, nel qual caso \var{errno}
781     assumerà uno dei valori:
782   \begin{errlist}
783   \item[\macro{EBADF}] si è specificato un file descriptor sbagliato.
784   \item[\macro{EINVAL}] si è specificato un valore non valido per uno degli
785     argomenti (ad esempio \param{count} è maggiore di \macro{MAX\_IOVEC}).
786   \item[\macro{EINTR}] la funzione è stata interrotta da un segnale prima di
787     di avere eseguito una qualunque lettura o scrittura.
788   \item[\macro{EAGAIN}] \param{fd} è stato aperto in modalità non bloccante e
789   non ci sono dati in lettura.
790   \item[\macro{EOPNOTSUPP}] La coda delle richieste è momentaneamente piena.
791   \end{errlist}
792   ed inoltre \macro{EISDIR}, \macro{ENOMEM}, \macro{EFAULT} (se non sono stato
793   allocati correttamente i buffer specificati nei campi \func{iov\_base}), più
794   tutti gli ulteriori errori che potrebbero avere le usuali funzioni di
795   lettura e scrittura eseguite su \param{fd}.}
796 \end{functions}
797
798 Entrambe le funzioni usano una struttura \type{iovec}, definita in
799 \figref{fig:file_iovec}, che definisce dove i dati devono essere letti o
800 scritti. Il primo campo, \var{iov\_base}, contiene l'indirizzo del buffer ed
801 il secondo, \var{iov\_len}, la dimensione dello stesso. 
802
803 \begin{figure}[!htb]
804   \footnotesize \centering
805   \begin{minipage}[c]{15cm}
806     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
807 struct iovec {
808     __ptr_t iov_base;    /* Starting address */
809     size_t iov_len;      /* Length in bytes  */
810 };
811     \end{lstlisting}
812   \end{minipage} 
813   \normalsize 
814   \caption{La struttura \type{iovec}, usata dalle operazioni di I/O
815     vettorizzato.} 
816   \label{fig:file_iovec}
817 \end{figure}
818
819 I buffer da utilizzare sono indicati attraverso l'argomento \param{vector} che
820 è un vettore di strutture \var{iovec}, la cui lunghezza è specificata da
821 \param{count}.  Ciascuna struttura dovrà essere inizializzata per
822 opportunamente per indicare i vari buffer da/verso i quali verrà eseguito il
823 trasferimento dei dati. Essi verranno letti (o scritti) nell'ordine in cui li
824 si sono specificati nel vettore \var{vector}.
825
826
827 \subsection{File mappati in memoria}
828 \label{sec:file_memory_map}
829
830 Una modalità alternativa di I/O, che usa una interfaccia completamente diversa
831 rispetto a quella classica vista in \capref{cha:file_unix_interface}, è il
832 cosiddetto \textit{memory-mapped I/O}, che, attraverso il meccanismo della
833 \textsl{paginazione}\index{paginazione} usato dalla memoria virtuale (vedi
834 \secref{sec:proc_mem_gen}), permette di \textsl{mappare} il contenuto di un
835 file in una sezione dello spazio di indirizzi del processo. Il meccanismo è
836 illustrato in \figref{fig:file_mmap_layout}, una sezione del file viene
837 riportata direttamente nello spazio degli indirizzi del programma. Tutte le
838 operazioni su questa zona verranno riportate indietro sul file dal meccanismo
839 della memoria virtuale che trasferirà il contenuto di quel segmento sul file
840 invece che nella swap, per cui si può parlare tanto di file mappato in
841 memoria, quanto di memoria mappata su file.
842
843 \begin{figure}[htb]
844   \centering
845   \includegraphics[width=9.5cm]{img/mmap_layout}
846   \caption{Disposizione della memoria di un processo quando si esegue la
847   mappatura in memoria di un file.}
848   \label{fig:file_mmap_layout}
849 \end{figure}
850
851 Tutto questo comporta una notevole semplificazione delle operazioni di I/O, in
852 quanto non sarà più necessario utilizzare dei buffer intermedi su cui
853 appoggiare i dati da traferire, ma questi potranno essere acceduti
854 direttamente nella sezione di memoria mappata; inoltre questa interfaccia è
855 più efficiente delle usuali funzioni di I/O, in quanto permette di caricare in
856 memoria solo le parti del file che sono effettivamente usate ad un dato
857 istante.
858
859 Infatti, dato che l'accesso è fatto direttamente attraverso la memoria
860 virtuale, la sezione di memoria mappata su cui si opera sarà a sua volta letta
861 o scritta sul file una pagina alla volta e solo per le parti effettivamente
862 usate, il tutto in maniera completamente trasparente al processo; l'accesso
863 alle pagine non ancora caricate avverrà allo stesso modo con cui vengono
864 caricate in memoria le pagine che sono state salvate sullo swap.
865
866 Infine in situazioni in cui la memoria è scarsa, le pagine che mappano un
867 file vengono salvate automaticamente, così come le pagine dei programmi
868 vengono scritte sulla swap; questo consente di accedere ai file su dimensioni
869 il cui solo limite è quello dello spazio di indirizzi disponibile, e non della
870 memoria su cui possono esserne lette delle porzioni.
871
872 L'interfaccia prevede varie funzioni per la gestione del \textit{memory mapped
873   I/O}, la prima di queste è \func{mmap}, che serve ad eseguire la mappatura
874 in memoria di un file; il suo prototipo è:
875 \begin{functions}
876   
877   \headdecl{unistd.h}
878   \headdecl{sys/mman.h} 
879
880   \funcdecl{void * mmap(void * start, size\_t length, int prot, int flags, int
881     fd, off\_t offset)}
882   
883   Esegue la mappatura in memoria del file \param{fd}.
884   
885   \bodydesc{La funzione restituisce il puntatore alla zona di memoria mappata
886     in caso di successo, e \macro{MAP\_FAILED} (-1) in caso di errore, nel
887     qual caso \var{errno} assumerà uno dei valori:
888     \begin{errlist}
889     \item[\macro{EBADF}] Il file descriptor non è valido, e non si è usato
890       \macro{MAP\_ANONYMOUS}.
891     \item[\macro{EACCES}] Il file descriptor non si riferisce ad un file
892       regolare, o si è richiesto \macro{MAP\_PRIVATE} ma \param{fd} non è
893       aperto in lettura, o si è richiesto \macro{MAP\_SHARED} e impostato
894       \macro{PROT\_WRITE} ed \param{fd} non è aperto in lettura/scrittura, o
895       si è impostato \macro{PROT\_WRITE} ed \param{fd} è in
896       \textit{append-only}.
897     \item[\macro{EINVAL}] I valori di \param{start}, \param{length} o
898       \param{offset} non sono validi (o troppo grandi o non allineati sulla
899       dimensione delle pagine).
900     \item[\macro{ETXTBSY}] Si è impostato \macro{MAP\_DENYWRITE} ma \param{fd}
901       è aperto in scrittura.
902     \item[\macro{EAGAIN}] Il file è bloccato, o si è bloccata troppa memoria.
903     \item[\macro{ENOMEM}] Non c'è memoria o si è superato il limite sul numero
904       di mappature possibili.
905     \item[\macro{ENODEV}] Il filesystem di \param{fd} non supporta il memory
906       mapping.
907     \end{errlist}
908   }
909 \end{functions}
910
911 La funzione richiede di mappare in memoria la sezione del file \param{fd} a
912 partire da \param{offset} per \param{lenght} byte, preferibilmente
913 all'indirizzo \param{start}. Il valore di \param{offset} deve essere un
914 multiplo della dimensione di una pagina di memoria. 
915
916
917 \begin{table}[htb]
918   \centering
919   \footnotesize
920   \begin{tabular}[c]{|l|l|}
921     \hline
922     \textbf{Valore} & \textbf{Significato} \\
923     \hline
924     \hline
925     \macro{PROT\_EXEC}  & Le pagine possono essere eseguite.\\
926     \macro{PROT\_READ}  & Le pagine possono essere lette.\\
927     \macro{PROT\_WRITE} & Le pagine possono essere scritte.\\
928     \macro{PROT\_NONE}  & L'accesso alle pagine è vietato.\\
929     \hline    
930   \end{tabular}
931   \caption{Valori dell'argomento \param{prot} di \func{mmap}, relativi alla
932     protezione applicate alle pagine del file mappate in memoria.}
933   \label{tab:file_mmap_prot}
934 \end{table}
935
936
937 Il valore dell'argomento \param{prot} indica la protezione\footnote{in Linux
938   la memoria reale è divisa in pagine: ogni processo vede la sua memoria
939   attraverso uno o più segmenti lineari di memoria virtuale.  Per ciascuno di
940   questi segmenti il kernel mantiene nella \textit{page table} la mappatura
941   sulle pagine di memoria reale, ed le modalità di accesso (lettura,
942   esecuzione, scrittura); una loro violazione causa quella che si chiama una
943   \textit{segment violation}, e la relativa emissione del segnale
944   \macro{SIGSEGV}.} da applicare al segmento di memoria e deve essere
945 specificato come maschera binaria ottenuta dall'OR di uno o più dei valori
946 riportati in \tabref{tab:file_mmap_flag}; il valore specificato deve essere
947 compatibile con la modalità di accesso con cui si è aperto il file.
948
949 L'argomento \param{flags} specifica infine qual'è il tipo di oggetto mappato,
950 le opzioni relative alle modalità con cui è effettuata la mappatura e alle
951 modalità con cui le modifiche alla memoria mappata vengono condivise o
952 mantenute private al processo che le ha effettuate. Deve essere specificato
953 come maschera binaria ottenuta dall'OR di uno o più dei valori riportati in
954 \tabref{tab:file_mmap_flag}.
955
956 \begin{table}[htb]
957   \centering
958   \footnotesize
959   \begin{tabular}[c]{|l|p{10cm}|}
960     \hline
961     \textbf{Valore} & \textbf{Significato} \\
962     \hline
963     \hline
964     \macro{MAP\_FIXED}     & Non permette di restituire un indirizzo diverso
965                              da \param{start}, se questo non può essere usato
966                              \func{mmap} fallisce. Se si imposta questo flag il
967                              valore di \param{start} deve essere allineato
968                              alle dimensioni di una pagina. \\
969     \macro{MAP\_SHARED}    & I cambiamenti sulla memoria mappata vengono
970                              riportati sul file e saranno immediatamente
971                              visibili agli altri processi che mappano lo stesso
972                              file.\footnotemark Il file su disco però non sarà
973                              aggiornato fino alla chiamata di \func{msync} o
974                              \func{unmap}), e solo allora le modifiche saranno
975                              visibili per l'I/O convenzionale. Incompatibile
976                              con \macro{MAP\_PRIVATE}. \\ 
977     \macro{MAP\_PRIVATE}   & I cambiamenti sulla memoria mappata non vengono
978                              riportati sul file. Ne viene fatta una copia
979                              privata cui solo il processo chiamante ha
980                              accesso.  Le modifiche sono mantenute attraverso
981                              il meccanismo del 
982                              \textit{copy on write}\index{copy on write} e
983                              salvate su swap in caso di necessità. Non è
984                              specificato se i cambiamenti sul file originale
985                              vengano riportati sulla regione
986                              mappata. Incompatibile con \macro{MAP\_SHARED}. \\
987     \macro{MAP\_DENYWRITE} & In Linux viene ignorato per evitare
988                              \textit{DoS}\index{DoS} (veniva usato per
989                              segnalare che tentativi di scrittura sul file
990                              dovevano fallire con \macro{ETXTBUSY}).\\
991     \macro{MAP\_EXECUTABLE}& Ignorato. \\
992     \macro{MAP\_NORESERVE} & Si usa con \macro{MAP\_PRIVATE}. Non riserva
993                              delle pagine di swap ad uso del meccanismo di
994                              \textit{copy on write}\index{copy on write}
995                              per mantenere le
996                              modifiche fatte alla regione mappata, in
997                              questo caso dopo una scrittura, se non c'è più
998                              memoria disponibile, si ha l'emissione di
999                              un \macro{SIGSEGV}. \\
1000     \macro{MAP\_LOCKED}    & Se impostato impedisce lo swapping delle pagine
1001                              mappate. \\
1002     \macro{MAP\_GROWSDOWN} & Usato per gli stack. Indica 
1003                              che la mappatura deve essere effettuata con gli
1004                              indirizzi crescenti verso il basso.\\
1005     \macro{MAP\_ANONYMOUS} & La mappatura non è associata a nessun file. Gli
1006                              argomenti \param{fd} e \param{offset} sono
1007                              ignorati.\footnotemark\\
1008     \macro{MAP\_ANON}      & Sinonimo di \macro{MAP\_ANONYMOUS}, deprecato.\\
1009     \macro{MAP\_FILE}      & Valore di compatibilità, deprecato.\\
1010     \hline
1011   \end{tabular}
1012   \caption{Valori possibili dell'argomento \param{flag} di \func{mmap}.}
1013   \label{tab:file_mmap_flag}
1014 \end{table}
1015
1016 \footnotetext{Dato che tutti faranno riferimento alle stesse pagine di
1017   memoria.}  
1018 \footnotetext{L'uso di questo flag con \macro{MAP\_SHARED} è
1019   stato implementato in Linux a partire dai kernel della serie 2.4.x.}
1020
1021 Gli effetti dell'accesso ad una zona di memoria mappata su file possono essere
1022 piuttosto complessi, essi si possono comprendere solo tenendo presente che
1023 tutto quanto è comunque basato sul basato sul meccanismo della memoria
1024 virtuale. Questo comporta allora una serie di conseguenze. La più ovvia è che
1025 se si cerca di scrivere su una zona mappata in sola lettura si avrà
1026 l'emissione di un segnale di violazione di accesso (\macro{SIGSEGV}), dato che
1027 i permessi sul segmento di memoria relativo non consentono questo tipo di
1028 accesso.
1029
1030 È invece assai diversa la questione relativa agli accessi al di fuori della
1031 regione di cui si è richiesta la mappatura. A prima vista infatti si potrebbe
1032 ritenere che anch'essi debbano generare un segnale di violazione di accesso;
1033 questo però non tiene conto del fatto che, essendo basata sul meccanismo della
1034 paginazione, la mappatura in memoria non può che essere eseguita su un
1035 segmento di dimensioni rigorosamente multiple di quelle di una pagina, ed in
1036 generale queste potranno non corrispondere alle dimensioni effettive del file
1037 o della sezione che si vuole mappare. Il caso più comune è quello illustrato
1038 in \figref{fig:file_mmap_boundary}, in cui la sezione di file non rientra nei
1039 confini di una pagina: in tal caso verrà il file sarà mappato su un segmento
1040 di memoria che si estende fino al bordo della pagina successiva.
1041
1042 \begin{figure}[htb]
1043   \centering
1044   \includegraphics[width=10cm]{img/mmap_boundary}
1045   \caption{Schema della mappatura in memoria di una sezione di file di
1046     dimensioni non corrispondenti al bordo di una pagina.}
1047   \label{fig:file_mmap_boundary}
1048 \end{figure}
1049
1050
1051 In questo caso è possibile accedere a quella zona di memoria che eccede le
1052 dimensioni specificate da \param{lenght}, senza ottenere un \macro{SIGSEGV}
1053 poiché essa è presente nello spazio di indirizzi del processo, anche se non è
1054 mappata sul file. Il comportamento del sistema è quello di restituire un
1055 valore nullo per quanto viene letto, e di non riportare su file quanto viene
1056 scritto.
1057
1058 Un caso più complesso è quello che si viene a creare quando le dimensioni del
1059 file mappato sono più corte delle dimensioni della mappatura, oppure quando il
1060 file è stato troncato, dopo che è stato mappato, ad una dimensione inferiore a
1061 quella della mappatura in memoria.
1062
1063 \begin{figure}[htb]
1064   \centering
1065   \includegraphics[width=13cm]{img/mmap_exceed}
1066   \caption{Schema della mappatura in memoria di file di dimensioni inferiori
1067     alla lunghezza richiesta.}
1068   \label{fig:file_mmap_exceed}
1069 \end{figure}
1070
1071 In questa situazione, per la sezione di pagina parzialmente coperta dal
1072 contenuto del file, vale esattamente quanto visto in precedenza; invece per la
1073 parte che eccede, fino alle dimensioni date da \param{length}, l'accesso non
1074 sarà più possibile, ma il segnale emesso non sarà \macro{SIGSEGV}, ma
1075 \macro{SIGBUS}, come illustrato in \figref{fig:file_mmap_exceed}.
1076
1077 Non tutti i file possono venire mappati in memoria, dato che, come illustrato
1078 in \figref{fig:file_mmap_layout}, la mappatura introduce una corrispondenza
1079 biunivoca fra una sezione di un file ed una sezione di memoria. Questo
1080 comporta che ad esempio non è possibile mappare in memoria file descriptor
1081 relativi a pipe, socket e fifo, per i quali non ha senso parlare di
1082 \textsl{sezione}. Lo stesso vale anche per alcuni file di dispositivo, che non
1083 dispongono della relativa operazione \var{mmap} (si ricordi quanto esposto in
1084 \secref{sec:file_vfs_work}). Si tenga presente però che esistono anche casi di
1085 dispositivi (un esempio è l'interfaccia al ponte PCI-VME del chip Universe)
1086 che sono utilizzabili solo con questa interfaccia.
1087
1088 Dato che passando attraverso una \func{fork} lo spazio di indirizzi viene
1089 copiato integralmente, i file mappati in memoria verranno ereditati in maniera
1090 trasparente dal processo figlio, mantenendo gli stessi attributi avuti nel
1091 padre; così se si è usato \macro{MAP\_SHARED} padre e figlio accederanno allo
1092 stesso file in maniera condivisa, mentre se si è usato \macro{MAP\_PRIVATE}
1093 ciascuno di essi manterrà una sua versione privata indipendente. Non c'è
1094 invece nessun passaggio attraverso una \func{exec}, dato che quest'ultima
1095 sostituisce tutto lo spazio degli indirizzi di un processo con quello di un
1096 nuovo programma.
1097
1098 Quando si effettua la mappatura di un file vengono pure modificati i tempi ad
1099 esso associati (di cui si è trattato in \secref{sec:file_file_times}). Il
1100 valore di \var{st\_atime} può venir cambiato in qualunque istante a partire
1101 dal momento in cui la mappatura è stata effettuata: il primo riferimento ad
1102 una pagina mappata su un file aggiorna questo tempo.  I valori di
1103 \var{st\_ctime} e \var{st\_mtime} possono venir cambiati solo quando si è
1104 consentita la scrittura sul file (cioè per un file mappato con
1105 \macro{PROT\_WRITE} e \macro{MAP\_SHARED}) e sono aggiornati dopo la scrittura
1106 o in corrispondenza di una eventuale \func{msync}.
1107
1108 Dato per i file mappati in memoria le operazioni di I/O sono gestite
1109 direttamente dalla memoria virtuale, occorre essere consapevoli delle
1110 interazioni che possono esserci con operazioni effettuate con l'interfaccia
1111 standard dei file di \capref{cha:file_unix_interface}. Il problema è che una
1112 volta che si è mappato un file, le operazioni di lettura e scrittura saranno
1113 eseguite sulla memoria, e riportate su disco in maniera autonoma dal sistema
1114 della memoria virtuale.
1115
1116 Pertanto se si modifica un file con l'interfaccia standard queste modifiche
1117 potranno essere visibili o meno a seconda del momento in cui la memoria
1118 virtuale trasporterà dal disco in memoria quella sezione del file, perciò è
1119 del tutto imprevedibile il risultato della modifica di un file nei confronti
1120 del contenuto della memoria mappata su cui è mappato.
1121
1122 Per quanto appena visto, è sempre sconsigliabile eseguire scritture su file
1123 attraverso l'interfaccia standard, quando lo si è mappato in memoria, è invece
1124 possibile usare l'interfaccia standard per leggere un file mappato in memoria,
1125 purché si abbia una certa cura; infatti l'interfaccia dell'I/O mappato in
1126 memoria mette a disposizione la funzione \func{msync} per sincronizzare il
1127 contenuto della memoria mappata con il file su disco; il suo prototipo è:
1128 \begin{functions}  
1129   \headdecl{unistd.h}
1130   \headdecl{sys/mman.h} 
1131
1132   \funcdecl{int msync(const void *start, size\_t length, int flags)}
1133   
1134   Sincronizza i contenuti di una sezione di un file mappato in memoria.
1135   
1136   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
1137     errore nel qual caso \var{errno} assumerà uno dei valori:
1138     \begin{errlist}
1139     \item[\macro{EINVAL}] O \param{start} non è multiplo di \macro{PAGESIZE},
1140     o si è specificato un valore non valido per \param{flags}.
1141     \item[\macro{EFAULT}] L'intervallo specificato non ricade in una zona
1142       precedentemente mappata.
1143     \end{errlist}
1144   }
1145 \end{functions}
1146
1147 La funzione esegue la sincronizzazione di quanto scritto nella sezione di
1148 memoria indicata da \param{start} e \param{offset}, scrivendo le modifiche sul
1149 file (qualora questo non sia già stato fatto).  Provvede anche ad aggiornare i
1150 relativi tempi di modifica. In questo modo si è sicuri che dopo l'esecuzione
1151 di \func{msync} le funzioni dell'interfaccia standard troveranno un contenuto
1152 del file aggiornato.
1153
1154 \begin{table}[htb]
1155   \centering
1156   \footnotesize
1157   \begin{tabular}[c]{|l|l|}
1158     \hline
1159     \textbf{Valore} & \textbf{Significato} \\
1160     \hline
1161     \hline
1162     \macro{MS\_ASYNC}     & Richiede la sincronizzazione.\\
1163     \macro{MS\_SYNC}      & Attende che la sincronizzazione si eseguita.\\
1164     \macro{MS\_INVALIDATE}& Richiede che le altre mappature dello stesso file
1165                             siano invalidate.\\
1166     \hline    
1167   \end{tabular}
1168   \caption{Valori dell'argomento \param{flag} di \func{msync}.}
1169   \label{tab:file_mmap_rsync}
1170 \end{table}
1171
1172 L'argomento \param{flag} è specificato come maschera binaria composta da un OR
1173 dei valori riportati in \tabref{tab:file_mmap_rsync}, di questi però
1174 \macro{MS\_ASYNC} e \macro{MS\_SYNC} sono incompatibili; con il primo valore
1175 infatti la funzione si limita ad inoltrare la richiesta di sincronizzazione al
1176 meccanismo della memoria virtuale, ritornando subito, mentre con il secondo
1177 attende che la sincronizzazione sia stata effettivamente eseguita. Il terzo
1178 flag fa invalidare le pagine di cui si richiede la sincronizzazione per tutte
1179 le mappature dello stesso file, così che esse possano essere immediatamente
1180 aggiornate ai nuovi valori.
1181
1182 Una volta che si sono completate le operazioni di I/O si può eliminare la
1183 mappatura della memoria usando la funzione \func{munmap}, il suo prototipo è:
1184 \begin{functions}  
1185   \headdecl{unistd.h}
1186   \headdecl{sys/mman.h} 
1187
1188   \funcdecl{int munmap(void *start, size\_t length)}
1189   
1190   Rilascia la mappatura sulla sezione di memoria specificata.
1191
1192   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
1193     errore nel qual caso \var{errno} assumerà uno dei valori:
1194     \begin{errlist}
1195     \item[\macro{EINVAL}] L'intervallo specificato non ricade in una zona
1196       precedentemente mappata.
1197     \end{errlist}
1198   }
1199 \end{functions}
1200
1201 La funzione cancella la mappatura per l'intervallo specificato attraverso
1202 \param{start} e \param{length}, ed ogni successivo accesso a tale regione
1203 causerà un errore di accesso in memoria. L'argomento \param{start} deve essere
1204 allineato alle dimensioni di una pagina di memoria, e la mappatura di tutte le
1205 pagine contenute (anche parzialmente) nell'intervallo indicato, verrà rimossa.
1206 Indicare un intervallo che non contiene pagine mappate non è un errore.
1207
1208 Alla conclusione del processo, ogni pagina mappata verrà automaticamente
1209 rilasciata, mentre la chiusura del file descriptor usato per effettuare la
1210 mappatura in memoria non ha alcun effetto sulla stessa.
1211
1212
1213 \section{Il file locking}
1214 \label{sec:file_locking}
1215
1216 In \secref{sec:file_sharing} abbiamo preso in esame le modalità in cui un
1217 sistema unix-like gestisce la condivisione dei file da parte di processi
1218 diversi. In quell'occasione si è visto come, con l'eccezione dei file aperti
1219 in \textit{append mode}, quando più processi scrivono contemporaneamente sullo
1220 stesso file non è possibile determinare la sequenza in cui essi opereranno.
1221
1222 Questo causa la possibilità di race condition\index{race condition}; in
1223 generale le situazioni più comuni sono due: l'interazione fra un processo che
1224 scrive e altri che leggono, in cui questi ultimi possono leggere informazioni
1225 scritte solo in maniera parziale o incompleta; o quella in cui diversi
1226 processi scrivono, mescolando in maniera imprevedibile il loro output sul
1227 file.
1228
1229 In tutti questi casi il \textit{file locking} è la tecnica che permette di
1230 evitare le race condition, attraverso una serie di funzioni che permettono di
1231 bloccare l'accesso al file da parte di altri processi, così da evitare le
1232 sovrapposizioni, e garantire la atomicità delle operazioni di scrittura.
1233
1234
1235
1236 \subsection{L'\textit{advisory locking}}
1237 \label{sec:file_record_locking}
1238
1239 La prima modalità di \textit{file locking} che è stata implementata nei
1240 sistemi unix-like è quella che viene usualmente chiamata \textit{advisory
1241   locking},\footnote{Stevens in \cite{APUE} fa riferimento a questo argomento
1242   come al \textit{record locking}, dizione utilizzata anche dal manuale delle
1243   \acr{glibc}; nelle pagine di manuale si parla di \textit{discretionary file
1244     lock} per \func{fcntl} e di \textit{advisory locking} per \func{flock},
1245   mentre questo nome viene usato da Stevens per riferirsi al \textit{file
1246     locking} POSIX. Dato che la dizione \textit{record locking} è quantomeno
1247   ambigua, in quanto in un sistema Unix non esiste niente che possa fare
1248   riferimento al concetto di \textit{record}, alla fine si è scelto di
1249   mantenere il nome \textit{advisory locking}.} in quanto sono i singoli
1250 processi, e non il sistema, che si incaricano di asserire e verificare se
1251 esistono delle condizioni di blocco per l'accesso ai file.  Questo significa
1252 che le funzioni \func{read} o \func{write} non risentono affatto della
1253 presenza di un eventuale \textit{lock}, e che sta ai vari processi controllare
1254 esplicitamente lo stato dei file condivisi prima di accedervi, implementando
1255 un opportuno protocollo.
1256
1257 In generale si distinguono due tipologie di \textit{file lock}:\footnote{di
1258   seguito ci riferiremo sempre ai blocchi di accesso ai file con la
1259   nomenclatura inglese di \textit{file lock}, o più brevemente con
1260   \textit{lock}, per evitare confuzioni linguistiche con il blocco di un
1261   processo (cioè la condizione in cui il processo viene posto in stato di
1262   \textit{sleep}).} la prima è il cosiddetto \textit{shared lock}, detto anche
1263 \textit{read lock} in quanto serve a bloccare l'accesso in scrittura su un
1264 file affinché non venga modificato mentre lo si legge. Si parla appunto di
1265 \textsl{blocco condiviso} in quanto più processi possono richiedere
1266 contemporaneamente uno \textit{shared lock} su un file per proteggere il loro
1267 accesso in lettura.
1268
1269 La seconda tipologia è il cosiddetto \textit{exclusive lock}, detto anche
1270 \textit{write lock} in quanto serve a bloccare l'accesso su un file (sia in
1271 lettura che in scrittura) da parte di altri processi mentre lo si sta
1272 scrivendo. Si parla di \textsl{blocco esclusivo} appunto perché un solo
1273 processo alla volta può richiedere un \textit{exclusive lock} su un file per
1274 proteggere il suo accesso in scrittura. 
1275
1276 \begin{table}[htb]
1277   \centering
1278   \footnotesize
1279   \begin{tabular}[c]{|l|c|c|c|}
1280     \hline
1281     \textbf{Richiesta} & \multicolumn{3}{|c|}{\textbf{Stato del file}}\\
1282     \cline{2-4}
1283                        &Nessun lock&\textit{Read lock}&\textit{Write lock}\\
1284     \hline
1285     \hline
1286     \textit{Read lock} & SI & SI & NO \\
1287     \textit{Write lock}& SI & NO & NO \\
1288     \hline    
1289   \end{tabular}
1290   \caption{Tipologie di file locking.}
1291   \label{tab:file_file_lock}
1292 \end{table}
1293
1294 In Linux sono disponibili due interfacce per utilizzare l'\textit{advisory
1295   locking}, la prima è quella derivata da BSD, che è basata sulla funzione
1296 \func{flock}, la seconda è quella standardizzata da POSIX.1 (derivata da
1297 System V), che è basata sulla funzione \func{fcntl}.  I \textit{file lock}
1298 sono implementati in maniera completamente indipendente nelle due interfacce,
1299 che pertanto possono coesistere senza interferenze.
1300
1301 Entrambe le interfacce prevedono la stessa procedura di funzionamento: si
1302 inizia sempre con il richiedere l'opportuno \textit{file lock} (un
1303 \textit{exclusive lock} per una scrittura, uno \textit{shared lock} per una
1304 lettura) prima di eseguire l'accesso ad un file.  Se il lock viene acquisito
1305 il processo prosegue l'esecuzione, altrimenti (a meno di non aver richiesto un
1306 comportamento non bloccante) viene posto in stato di sleep. Una volta finite
1307 le operazioni sul file si deve provvedere a rimuovere il lock. La situazione
1308 delle varie possibilità è riassunta in \tabref{tab:file_file_lock}.
1309
1310 %%  Si ricordi che
1311 %% la condizione per acquisire uno \textit{shared lock} è che il file non abbia
1312 %% già un \textit{exclusive lock} attivo, mentre per acquisire un
1313 %% \textit{exclusive lock} non deve essere presente nessun tipo di blocco.
1314
1315
1316 \subsection{La funzione \func{flock}}
1317 \label{sec:file_flock}
1318
1319 La prima interfaccia per il file locking, quella derivata da BSD, permette di
1320 eseguire un blocco solo su un intero file; la funzione usata per richiedere e
1321 rimuovere un \textit{file lock} è \func{flock}, ed il suo prototipo è:
1322 \begin{prototype}{sys/file.h}{int flock(int fd, int operation)}
1323   
1324   Applica o rimuove un \textit{file lock} sul file \param{fd}.
1325   
1326   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
1327     errore, nel qual caso \var{errno} assumerà uno dei valori:
1328     \begin{errlist}
1329     \item[\macro{EWOULDBLOCK}] Il file ha già un blocco attivo, e si è
1330       specificato \macro{LOCK\_NB}.
1331     \end{errlist}
1332   }
1333 \end{prototype}
1334
1335 La funzione può essere usata per acquisire o rilasciare un \textit{file lock}
1336 a seconda di quanto specificato tramite il valore dell'argomento
1337 \param{operation}, questo viene interpretato come maschera binaria, e deve
1338 essere passato utilizzando le costanti riportate in
1339 \tabref{tab:file_flock_operation}.
1340
1341 \begin{table}[htb]
1342   \centering
1343   \footnotesize
1344   \begin{tabular}[c]{|l|l|}
1345     \hline
1346     \textbf{Valore} & \textbf{Significato} \\
1347     \hline
1348     \hline
1349     \macro{LOCK\_SH} & Asserisce uno \textit{shared lock} sul file.\\ 
1350     \macro{LOCK\_EX} & Asserisce un \textit{esclusive lock} sul file.\\
1351     \macro{LOCK\_UN} & Rilascia il \textit{file lock}.\\
1352     \macro{LOCK\_NB} & Impedisce che la funzione si blocchi nella
1353                        richiesta di un \textit{file lock}.\\
1354     \hline    
1355   \end{tabular}
1356   \caption{Valori dell'argomento \param{operation} di \func{flock}.}
1357   \label{tab:file_flock_operation}
1358 \end{table}
1359
1360 I primi due valori, \macro{LOCK\_SH} e \macro{LOCK\_EX} permettono di
1361 richiedere un \textit{file lock}, ed ovviamente devono essere usati in maniera
1362 alternativa. Se si specifica anche \macro{LOCK\_NB} la funzione non si
1363 bloccherà qualora il lock non possa essere acquisito, ma ritornerà subito con
1364 un errore di \macro{EWOULDBLOCK}. Per rilasciare un lock si dovrà invece usare
1365 \macro{LOCK\_UN}.
1366
1367 La semantica del file locking di BSD è diversa da quella del file locking
1368 POSIX, in particolare per quanto riguarda il comportamento dei lock nei
1369 confronti delle due funzioni \func{dup} e \func{fork}.  Per capire queste
1370 differenze occorre descrivere con maggiore dettaglio come viene realizzato il
1371 file locking nel kernel in entrambe le interfacce.
1372
1373 In \figref{fig:file_flock_struct} si è riportato uno schema essenziale
1374 dell'implementazione del file locking in stile BSD in Linux; il punto
1375 fondamentale da capire è che un lock, qualunque sia l'interfaccia che si usa,
1376 anche se richiesto attraverso un file descriptor, agisce sempre su un file;
1377 perciò le informazioni relative agli eventuali \textit{file lock} sono
1378 mantenute a livello di inode,\footnote{in particolare, come accennato in
1379   \figref{fig:file_flock_struct}, i \textit{file lock} sono mantenuti un una
1380   \textit{linked list}\index{linked list} di strutture \var{file\_lock}. La
1381   lista è referenziata dall'indirizzo di partenza mantenuto dal campo
1382   \var{i\_flock} della struttura \var{inode} (per le definizioni esatte si
1383   faccia riferimento al file \file{fs.h} nei sorgenti del kernel).  Un bit del
1384   campo \var{fl\_flags} di specifica se si tratta di un lock in semantica BSD
1385   (\macro{FL\_FLOCK}) o POSIX (\macro{FL\_POSIX}).} dato che questo è l'unico
1386 riferimento in comune che possono avere due processi diversi che aprono lo
1387 stesso file.
1388
1389 \begin{figure}[htb]
1390   \centering
1391   \includegraphics[width=13cm]{img/file_flock}
1392   \caption{Schema dell'architettura del file locking, nel caso particolare  
1393     del suo utilizzo da parte dalla funzione \func{flock}.}
1394   \label{fig:file_flock_struct}
1395 \end{figure}
1396
1397 La richiesta di un file lock prevede una scansione della lista per determinare
1398 se l'acquisizione è possibile, ed in caso positivo l'aggiunta di un nuovo
1399 elemento.\footnote{cioè una nuova struttura \var{file\_lock}.}  Nel caso dei
1400 lock creati con \func{flock} la semantica della funzione prevede che sia
1401 \func{dup} che \func{fork} non creino ulteriori istanze di un file lock quanto
1402 piuttosto degli ulteriori riferimenti allo stesso. Questo viene realizzato dal
1403 kernel secondo lo schema di \figref{fig:file_flock_struct}, associando ad ogni
1404 nuovo \textit{file lock} un puntatore\footnote{il puntatore è mantenuto nel
1405   campo \var{fl\_file} di \var{file\_lock}, e viene utilizzato solo per i lock
1406   creati con la semantica BSD.} alla voce nella \textit{file table} da cui si
1407 è richiesto il lock, che così ne identifica il titolare.
1408
1409 Questa struttura prevede che, quando si richiede la rimozione di un file lock,
1410 il kernel acconsenta solo se la richiesta proviene da un file descriptor che
1411 fa riferimento ad una voce nella file table corrispondente a quella registrata
1412 nel lock.  Allora se ricordiamo quanto visto in \secref{sec:file_dup} e
1413 \secref{sec:file_sharing}, e cioè che i file descriptor duplicati e quelli
1414 ereditati in un processo figlio puntano sempre alla stessa voce nella file
1415 table, si può capire immediatamente quali sono le conseguenze nei confronti
1416 delle funzioni \func{dup} e \func{fork}.
1417
1418 Sarà così possibile rimuovere un file lock attraverso uno qualunque dei file
1419 descriptor che fanno riferimento alla stessa voce nella file table, anche se
1420 questo è diverso da quello con cui lo si è creato,\footnote{attenzione, questo
1421   non vale se il file descriptor fa riferimento allo stesso file, ma
1422   attraverso una voce diversa della file table, come accade tutte le volte che
1423   si apre più volte lo stesso file.} o se si esegue la rimozione in un
1424 processo figlio; inoltre una volta tolto un file lock, la rimozione avrà
1425 effetto su tutti i file descriptor che condividono la stessa voce nella file
1426 table, e quindi, nel caso di file descriptor ereditati attraverso una
1427 \func{fork}, anche su processi diversi.
1428
1429 Infine, per evitare che la terminazione imprevista di un processo lasci attivi
1430 dei file lock, quando un file viene chiuso il kernel provveda anche a
1431 rimuovere tutti i lock ad esso associati. Anche in questo caso occorre tenere
1432 presente cosa succede quando si hanno file descriptor duplicati; in tal caso
1433 infatti il file non verrà effettivamente chiuso (ed il lock rimosso) fintanto
1434 che non viene rilasciata la relativa voce nella file table; e questo avverrà
1435 solo quando tutti i file descriptor che fanno riferimento alla stessa voce
1436 sono stati chiusi.  Quindi, nel caso ci siano duplicati o processi figli che
1437 mantengono ancora aperto un file descriptor, il lock non viene rilasciato.
1438
1439 Si tenga presente infine che \func{flock} non è in grado di funzionare per i
1440 file mantenuti su NFS, in questo caso, se si ha la necessità di eseguire il
1441 \textit{file locking}, occorre usare l'interfaccia basata su \func{fcntl} che
1442 può funzionare anche attraverso NFS, a condizione che sia il client che il
1443 server supportino questa funzionalità.
1444  
1445
1446 \subsection{Il file locking POSIX}
1447 \label{sec:file_posix_lock}
1448
1449 La seconda interfaccia per l'\textit{advisory locking} disponibile in Linux è
1450 quella standardizzata da POSIX, basata sulla funzione \func{fcntl}. Abbiamo
1451 già trattato questa funzione nelle sue molteplici possibilità di utilizzo in
1452 \secref{sec:file_fcntl}. Quando la si impiega per il \textit{file locking}
1453 essa viene usata solo secondo il prototipo:
1454 \begin{prototype}{fcntl.h}{int fcntl(int fd, int cmd, struct flock *lock)}
1455   
1456   Applica o rimuove un \textit{file lock} sul file \param{fd}.
1457   
1458   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
1459     errore, nel qual caso \var{errno} assumerà uno dei valori:
1460     \begin{errlist}
1461     \item[\macro{EACCES}] L'operazione è proibita per la presenza di
1462       \textit{file lock} da parte di altri processi.
1463     \item[\macro{ENOLCK}] Il sistema non ha le risorse per il locking: ci sono
1464       troppi segmenti di lock aperti, si è esaurita la tabella dei lock, o il
1465       protocollo per il locking remoto è fallito.
1466     \item[\macro{EDEADLK}] Si è richiesto un lock su una regione bloccata da
1467       un altro processo che è a sua volta in attesa dello sblocco di un lock
1468       mantenuto dal processo corrente; si avrebbe pertanto un
1469       \textit{deadlock}. Non è garantito che il sistema riconosca sempre
1470       questa situazione.
1471     \item[\macro{EINTR}] La funzione è stata interrotta da un segnale prima di
1472       poter acquisire un lock.
1473     \end{errlist}
1474     ed inoltre \macro{EBADF}, \macro{EFAULT}.
1475   }
1476 \end{prototype}
1477
1478 Al contrario di quanto avviene con l'interfaccia basata su \func{flock} con
1479 \func{fcntl} è possibile bloccare anche delle singole sezioni di un file;
1480 inoltre la funzione permette di ottenere informazioni relative ai lock
1481 esistenti.  Per realizzare tutto questo la funzione utilizza come terzo
1482 argomento una apposita struttura \var{flock} (la cui definizione è riportata
1483 in \figref{fig:struct_flock}) nella quale inserire tutti i dati relativi ad un
1484 determinato lock.
1485
1486 \begin{figure}[!bht]
1487   \footnotesize \centering
1488   \begin{minipage}[c]{15cm}
1489     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
1490 struct flock {
1491     short int l_type;   /* Type of lock: F_RDLCK, F_WRLCK, or F_UNLCK.  */
1492     short int l_whence; /* Where `l_start' is relative to (like `lseek').  */
1493     off_t l_start;      /* Offset where the lock begins.  */
1494     off_t l_len;        /* Size of the locked area; zero means until EOF.  */
1495     pid_t l_pid;        /* Process holding the lock.  */
1496 };
1497     \end{lstlisting}
1498   \end{minipage} 
1499   \normalsize 
1500   \caption{La struttura \type{flock}, usata da \func{fcntl} per il file
1501     locking.} 
1502   \label{fig:struct_flock}
1503 \end{figure}
1504
1505
1506 I primi tre campi della struttura, \var{l\_whence}, \var{l\_start} e
1507 \var{l\_len}, servono a specificare la sezione del file a cui fa riferimento
1508 il lock: \var{l\_start} specifica il byte di partenza, \var{l\_len} la
1509 lunghezza della sezione e infine \var{l\_whence} imposta il riferimento da cui
1510 contare \var{l\_start}. Il valore di \var{l\_whence} segue la stessa semantica
1511 dell'omonimo argomento di \func{lseek}, coi tre possibili valori
1512 \macro{SEEK\_SET}, \macro{SEEK\_CUR} e \macro{SEEK\_END}, (si vedano le
1513 relative descrizioni in \secref{sec:file_lseek}).
1514
1515 Si tenga presente che un lock può essere richiesto anche per una regione al di
1516 là della corrente fine del file, così che una eventuale estensione dello
1517 stesso resti coperta dal blocco. Inoltre se si specifica un valore nullo per
1518 \var{l\_len} il blocco si considera esteso fino alla dimensione massima del
1519 file; in questo modo è possibile bloccare una qualunque regione a partire da
1520 un certo punto fino alla fine del file, coprendo automaticamente quanto
1521 eventualmente aggiunto in coda allo stesso.
1522
1523 Il tipo di file lock richiesto viene specificato dal campo \var{l\_type}, esso
1524 può assumere i tre valori definiti dalle costanti riportate in
1525 \tabref{tab:file_flock_type}, che permettono di richiedere rispettivamente uno
1526 \textit{shared lock}, un \textit{esclusive lock}, e la rimozione di un lock
1527 precedentemente acquisito. Infine il campo \var{l\_pid} viene usato solo in
1528 caso di lettura, quando si chiama \func{fcntl} con \macro{F\_GETLK}, e riporta
1529 il \acr{pid} del processo che detiene il lock.
1530
1531 \begin{table}[htb]
1532   \centering
1533   \footnotesize
1534   \begin{tabular}[c]{|l|l|}
1535     \hline
1536     \textbf{Valore} & \textbf{Significato} \\
1537     \hline
1538     \hline
1539     \macro{F\_RDLCK} & Richiede un blocco condiviso (\textit{read lock}).\\
1540     \macro{F\_WRLCK} & Richiede un blocco esclusivo (\textit{write lock}).\\
1541     \macro{F\_UNLCK} & Richiede l'eliminazione di un file lock.\\
1542     \hline    
1543   \end{tabular}
1544   \caption{Valori possibili per il campo \var{l\_type} di \func{flock}.}
1545   \label{tab:file_flock_type}
1546 \end{table}
1547
1548 L'operazione effettivamente svolta dalla funzione è stabilita dal valore
1549 dall'argomento \param{cmd} che, come già riportato in \secref{sec:file_fcntl},
1550 specifica l'azione da compiere; i valori relativi al file locking sono tre:
1551 \begin{basedescript}{\desclabelwidth{2.0cm}}
1552 \item[\macro{F\_GETLK}] verifica se il file lock specificato dalla struttura
1553   puntata da \param{lock} può essere acquisito: in caso negativo sovrascrive
1554   la struttura \param{flock} con i valori relativi al lock già esistente che
1555   ne blocca l'acquisizione, altrimenti si limita a impostarne il campo
1556   \var{l\_type} con il valore \macro{F\_UNLCK}. 
1557 \item[\macro{F\_SETLK}] se il campo \var{l\_type} della struttura puntata da
1558   \param{lock} è \macro{F\_RDLCK} o \macro{F\_WRLCK} richiede il
1559   corrispondente file lock, se è \macro{F\_UNLCK} lo rilascia. Nel caso la
1560   richiesta non possa essere soddisfatta a causa di un lock preesistente la
1561   funzione ritorna immediatamente con un errore di \macro{EACCES} o di
1562   \macro{EAGAIN}.
1563 \item[\macro{F\_SETLKW}] è identica a \macro{F\_SETLK}, ma se la richiesta di
1564   un lock non può essere soddisfatta per la presenza di un altro blocco, mette
1565   il processo in stato di attesa fintanto che il lock precedente non viene
1566   rilasciato. Se l'attesa viene interrotta da un segnale la funzione ritorna
1567   con un errore di \macro{EINTR}.
1568 \end{basedescript}
1569
1570 Si noti che per quanto detto il comando \macro{F\_GETLK} non serve a rilevare
1571 una presenza generica di lock su un file, perché se ne esistono altri
1572 compatibili con quello richiesto, la funzione ritorna comunque impostando
1573 \var{l\_type} a \macro{F\_UNLCK}.  Inoltre a seconda del valore di
1574 \var{l\_type} si potrà controllare o l'esistenza di un qualunque tipo di lock
1575 (con \macro{F\_WRLCK}) o di write lock (con \macro{F\_RDLCK}). Si consideri
1576 poi che può esserci più di un lock che impedisce l'acquisizione di quello
1577 richiesto, ma la funzione ne riporterà sempre soltanto uno, impostando
1578 \var{l\_whence} a \macro{SEEK\_SET} ed i valori \var{l\_start} e \var{l\_len}
1579 per indicare quale è la regione bloccata.
1580
1581 Infine si tenga presente che effettuare un controllo con il comando
1582 \macro{F\_GETLK} e poi tentare l'acquisizione con \macro{F\_SETLK} non è una
1583 operazione atomica (un altro processo potrebbe acquisire un lock fra le due
1584 chiamate) per cui si deve sempre verificare il codice di ritorno di
1585 \func{fcntl}\footnote{controllare il codice di ritorno delle funzioni invocate
1586   è comunque una buona norma di programmazione, che permette di evitare un
1587   sacco di errori difficili da tracciare proprio perché non vengono rilevati.}
1588 quando la si invoca con \macro{F\_SETLK}, per controllare che il lock sia
1589 stato effettivamente acquisito.
1590
1591 Occorre infine considerare come interagiscono operazioni su lock che si
1592 estendono su regioni che si sovrappongono fra loro (ovviamente si fa
1593 riferimento ai lock detenuti dallo stesso processo); ad esempio è possibile
1594 con una sola chiamata rimuovere più lock separati (indicando in \var{flock}
1595 una regione che li copra tutti), o rimuovere solo una parte di un lock
1596 preesistente (indicando una sezione contenuta in un altro lock), di coprire
1597 con un nuovo lock altri lock già ottenuti. In tutti questi casi il kernel si
1598 preoccupa di accorpare o suddividere le regioni bloccate, a seconda di quanto
1599 necessario per soddisfare l'operazione richiesta, aggiornando opportunamente
1600 le strutture interne usate per il file locking.
1601
1602 \begin{figure}[htb]
1603   \centering \includegraphics[width=9cm]{img/file_lock_dead}
1604   \caption{Schema di una situazione di \textit{deadlock}.}
1605   \label{fig:file_flock_dead}
1606 \end{figure}
1607
1608 Non operando a livello di interi file, il file locking POSIX introduce
1609 un'ulteriore complicazione; consideriamo la situazione illustrata in
1610 \figref{fig:file_flock_dead}, in cui il processo A blocca la regione 1 e il
1611 processo B la regione 2. Supponiamo che successivamente il processo A richieda
1612 un lock sulla regione 2 che non può essere acquisito per il preesistente lock
1613 del processo 2; il processo 1 si bloccherà fintanto che il processo 2 non
1614 rilasci il blocco. Ma cosa accade se il processo 2 nel frattempo tenta a sua
1615 volta di ottenere un lock sulla regione A? Questa è una tipica situazione che
1616 porta ad un \textit{deadlock}\index{deadlock}, dato che a quel punto anche il
1617 processo 2 si bloccherebbe, e niente potrebbe sbloccare l'altro processo. Per
1618 questo motivo il kernel si incarica di rilevare situazioni di questo tipo, ed
1619 impedirle restituendo un errore di \macro{EDEADLK} alla funzione che cerca di
1620 acquisire un lock che porterebbe ad un \textit{deadlock}.
1621
1622 \begin{figure}[htb]
1623   \centering \includegraphics[width=13cm]{img/file_posix_lock}
1624   \caption{Schema dell'architettura del file locking, nel caso particolare  
1625     del suo utilizzo secondo l'interfaccia standard POSIX.}
1626   \label{fig:file_posix_lock}
1627 \end{figure}
1628
1629 Come accennato nella semantica POSIX si ha un comportamento del file locking
1630 diverso rispetto a quanto visto in \secref{sec:file_flock}.  Lo schema della
1631 struttura usata dal kernel in questo caso è riportato in
1632 \figref{fig:file_posix_lock}; come si vede essa è molto simile a quanto visto
1633 in \figref{fig:file_flock_struct} per \func{flock}:\footnote{in questo caso
1634   nella figura si sono evidenziati solo i campi di \var{file\_lock}
1635   significativi per la semantica POSIX, in particolare adesso ciascuna
1636   struttura contiene, oltre al \acr{pid} del processo in \var{fl\_pid}, la
1637   sezione di file che viene bloccata grazie ai campi \var{fl\_start} e
1638   \var{fl\_end}.  La struttura è comunque la stessa, solo che in questo caso
1639   nel campo \var{fl\_flags} è impostato il bit \macro{FL\_POSIX} ed il campo
1640   \var{fl\_file} non viene usato.} il lock è sempre associato all'inode, solo
1641 che in questo caso la titolarità non viene identificata con il riferimento ad
1642 una voce nella file table, ma con il valore del \acr{pid} del processo.
1643
1644 Tutto ciò significa che la rimozione di un lock viene effettuata controllando
1645 che il \acr{pid} del processo richiedente corrisponda a quello contenuto nel
1646 lock. Questa diversa modalità ha delle conseguenze precise riguardo il
1647 comportamento dei lock POSIX. La prima conseguenza è che un lock POSIX non
1648 viene mai ereditato attraverso una \func{fork}, dato che il processo figlio
1649 avrà un \acr{pid} diverso, mentre passa indenne attraverso una \func{exec} in
1650 quanto il \acr{pid} resta lo stesso.  Questo comporta che, al contrario di
1651 quanto avveniva con la semantica BSD, quando processo termina tutti i file
1652 lock da esso detenuti vengono immediatamente rilasciati.
1653
1654 La seconda conseguenza è che qualunque file descriptor che faccia riferimento
1655 allo stesso file (che sia stato ottenuto con una \func{dup} o con una
1656 \func{open} in questo caso non fa differenza) può essere usato per rimuovere
1657 un lock, dato che quello che conta è solo il \acr{pid} del processo. Da questo
1658 deriva una ulteriore sottile differenza di comportamento: dato che alla
1659 chiusura di un file i lock ad esso associati vengono rimossi, nella semantica
1660 POSIX basterà chiudere un file descriptor qualunque per cancellare tutti i
1661 lock relativi al file cui esso faceva riferimento, anche se questi fossero
1662 stati creati usando altri file descriptor che restano aperti.
1663
1664
1665 \subsection{La funzione \func{lockf}}
1666 \label{sec:file_lockf}
1667
1668 Abbiamo visto come l'interfaccia POSIX per il file locking sia molto più
1669 potente e flessibile di quella di BSD, ma è anche molto più complicata da
1670 usare per le varie opzioni da passare a \func{fcntl}. Per questo motivo è
1671 disponibile anche una interfaccia semplificata (ripresa da System V) che
1672 utilizza la funzione \func{lockf}, il cui prototipo è:
1673 \begin{prototype}{sys/file.h}{int lockf(int fd, int cmd, off\_t len)}
1674   
1675   Applica, controlla o rimuove un \textit{file lock} sul file \param{fd}.
1676   
1677   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
1678     errore, nel qual caso \var{errno} assumerà uno dei valori:
1679     \begin{errlist}
1680     \item[\macro{EWOULDBLOCK}] Non è possibile acquisire il lock, e si è
1681       selezionato \macro{LOCK\_NB}, oppure l'operazione è proibita perché il
1682       file è mappato in memoria.
1683     \item[\macro{ENOLCK}] Il sistema non ha le risorse per il locking: ci sono
1684       troppi segmenti di lock aperti, si è esaurita la tabella dei lock.
1685     \end{errlist}
1686     ed inoltre \macro{EBADF}, \macro{EINVAL}.
1687   }
1688 \end{prototype}
1689
1690 Il comportamento della funzione dipende dal valore dell'argomento \param{cmd}
1691 che specifica quale azione eseguire; i valori possibili sono riportati in
1692 \tabref{tab:file_lockf_type}.
1693
1694 \begin{table}[htb]
1695   \centering
1696   \footnotesize
1697   \begin{tabular}[c]{|l|p{7cm}|}
1698     \hline
1699     \textbf{Valore} & \textbf{Significato} \\
1700     \hline
1701     \hline
1702     \macro{LOCK\_SH}& Richiede uno \textit{shared lock}. Più processi possono
1703                       mantenere un lock condiviso sullo stesso file.\\
1704     \macro{LOCK\_EX}& Richiede un \textit{exclusive lock}. Un solo processo
1705                       alla volta può mantenere un lock esclusivo su un file. \\
1706     \macro{LOCK\_UN}& Sblocca il file.\\
1707     \macro{LOCK\_NB}& Non blocca la funzione quando il lock non è disponibile,
1708                       si specifica sempre insieme ad una delle altre operazioni
1709                       con un OR aritmetico dei valori.\\ 
1710     \hline    
1711   \end{tabular}
1712   \caption{Valori possibili per il campo \var{cmd} di \func{lockf}.}
1713   \label{tab:file_lockf_type}
1714 \end{table}
1715
1716 Qualora il lock non possa essere acquisito, a meno di non aver specificato
1717 \macro{LOCK\_NB}, la funzione si blocca fino alla disponibilità dello stesso.
1718 Dato che la funzione è implementata utilizzando \func{fcntl} la semantica
1719 delle operazioni è la stessa di quest'ultima (pertanto la funzione non è
1720 affatto equivalente a \func{flock}).
1721
1722
1723
1724 \subsection{Il \textit{mandatory locking}}
1725 \label{sec:file_mand_locking}
1726
1727 Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4,
1728 per introdurre un file locking che, come dice il nome, fosse effettivo
1729 indipendentemente dai controlli eseguiti da un processo. Con il
1730 \textit{mandatory locking} infatti è possibile far eseguire il blocco del file
1731 direttamente al sistema, così che, anche qualora non si predisponessero le
1732 opportune verifiche nei processi, questo verrebbe comunque rispettato.
1733
1734 Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
1735 utilizzo particolare del bit \acr{sgid}. Se si ricorda quanto esposto in
1736 \secref{sec:file_suid_sgid}), esso viene di norma utilizzato per cambiare il
1737 groupid effettivo con cui viene eseguito un programma, ed è pertanto sempre
1738 associato alla presenza del permesso di esecuzione per il gruppo. Impostando
1739 questo bit su un file senza permesso di esecuzione in un sistema che supporta
1740 il \textit{mandatory locking}, fa sì che quest'ultimo venga attivato per il
1741 file in questione. In questo modo una combinazione dei permessi
1742 originariamente non contemplata, in quanto senza significato, diventa
1743 l'indicazione della presenza o meno del \textit{mandatory
1744   locking}.\footnote{un lettore attento potrebbe ricordare quanto detto in
1745   \secref{sec:file_chmod} e cioè che il bit \acr{sgid} viene cancellato (come
1746   misura di sicurezza) quando di scrive su un file, questo non vale quando
1747   esso viene utilizzato per attivare il \textit{mandatory locking}.}
1748
1749 L'uso del \textit{mandatory locking} presenta vari aspetti delicati, dato che
1750 neanche root può passare sopra ad un lock; pertanto un processo che blocchi un
1751 file cruciale può renderlo completamente inaccessibile, rendendo completamente
1752 inutilizzabile il sistema\footnote{il problema si potrebbe risolvere
1753   rimuovendo il bit \acr{sgid}, ma non è detto che sia così facile fare questa
1754   operazione con un sistema bloccato.} inoltre con il \textit{mandatory
1755   locking} si può bloccare completamente un server NFS richiedendo una lettura
1756 su un file su cui è attivo un lock. Per questo motivo l'abilitazione del
1757 mandatory locking è di norma disabilitata, e deve essere attivata filesystem
1758 per filesystem in fase di montaggio (specificando l'apposita opzione di
1759 \func{mount} riportata in \tabref{tab:sys_mount_flags}, o con l'opzione
1760 \cmd{mand} per il comando).
1761
1762 Si tenga presente inoltre che il \textit{mandatory locking} funziona
1763 sull'interfaccia POSIX di \func{fcntl}, questo significa che non ha nessun
1764 effetto sui lock richiesti con l'interfaccia di \func{flock}, ed inoltre che
1765 la granularità del lock è quella del singolo byte, come per \func{fcntl}.
1766
1767 La sintassi di acquisizione dei lock è esattamente la stessa vista in
1768 precedenza per \func{fcntl} e \func{lockf}, la differenza è che in caso di
1769 mandatory lock attivato non è più necessario controllare la disponibilità di
1770 accesso al file, ma si potranno usare direttamente le ordinarie funzioni di
1771 lettura e scrittura e sarà compito del kernel gestire direttamente il file
1772 locking.
1773
1774 Questo significa che in caso di read lock la lettura dal file potrà avvenire
1775 normalmente con \func{read}, mentre una \func{write} si bloccherà fino al
1776 rilascio del lock, a meno di non aver aperto il file con \macro{O\_NONBLOCK},
1777 nel qual caso essa ritornerà immediatamente con un errore di \macro{EAGAIN}.
1778
1779 Se invece si è acquisito un write lock tutti i tentativi di leggere o scrivere
1780 sulla regione del file bloccata fermeranno il processo fino al rilascio del
1781 lock, a meno che il file non sia stato aperto con \macro{O\_NONBLOCK}, nel
1782 qual caso di nuovo si otterrà un ritorno immediato con l'errore di
1783 \macro{EAGAIN}.
1784
1785 Infine occorre ricordare che le funzioni di lettura e scrittura non sono le
1786 sole ad operare sui contenuti di un file, e che sia \func{creat} che
1787 \func{open} (quando chiamata con \macro{O\_TRUNC}) effettuano dei cambiamenti,
1788 così come \func{truncate}, riducendone le dimensioni (a zero nei primi due
1789 casi, a quanto specificato nel secondo). Queste operazioni sono assimilate a
1790 degli accessi in scrittura e pertanto non potranno essere eseguite (fallendo
1791 con un errore di \macro{EAGAIN}) su un file su cui sia presente un qualunque
1792 lock (le prime due sempre, la terza solo nel caso che la riduzione delle
1793 dimensioni del file vada a sovrapporsi ad una regione bloccata).
1794
1795 L'ultimo aspetto della interazione del \textit{mandatory locking} con le
1796 funzioni di accesso ai file è quello relativo ai file mappati in memoria
1797 appena trattati in \secref{sec:file_memory_map}; anche in tal caso infatti,
1798 quando si esegue la mappatura con l'opzione \macro{MAP\_SHARED}, si ha un
1799 accesso al contenuto del file. Lo standard SVID prevede che sia impossibile
1800 eseguire il memory mapping di un file su cui sono presenti dei
1801 lock\footnote{alcuni sistemi, come HP-UX, sono ancora più restrittivi e lo
1802   impediscono anche in caso di \textit{advisory locking}, anche se questo non
1803   ha molto senso.} in Linux è stata però fatta la scelta implementativa di
1804 seguire questo comportamento soltanto quando si chiama \func{mmap} con
1805 l'opzione \macro{MAP\_SHARED} (nel qual caso la funzione fallisce con il
1806 solito \macro{EAGAIN}). 
1807
1808
1809
1810
1811 %%% Local Variables: 
1812 %%% mode: latex
1813 %%% TeX-master: "gapil"
1814 %%% End: