1 \chapter{La gestione avanzata dei file}
2 \label{cha:file_advanced}
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
11 \section{Le funzioni di I/O avanzato}
12 \label{sec:file_advanced_io}
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
20 \subsection{La modalità di I/O \textsl{non-bloccante}}
21 \label{sec:file_noblocking}
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.
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
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}.
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}, è estremamente inefficiente: si tiene costantemente
50 impiegata la CPU solo per eseguire in continuazione delle system call che
51 nella gran parte dei casi falliranno. Per evitare questo, come vedremo in
52 \secref{sec:file_multiplexing}, è stata introdotta una nuova interfaccia di
53 programmazione, che comporta comunque l'uso della modalità di I/O non
58 \subsection{L'I/O multiplexing}
59 \label{sec:file_multiplexing}
61 Per superare il problema di dover usare il \textit{polling} per controllare la
62 possibilità di effettuare operazioni su un file aperto in modalità non
63 bloccante, sia BSD che System V hanno introdotto delle nuove funzioni in grado
64 di sospendere l'esecuzione di un processo in attesa che l'accesso diventi
65 possibile. Il primo ad introdurre questa modalità di operazione, chiamata
66 usualmente \textit{I/O multiplexing}, è stato BSD,\footnote{la funzione è
67 apparsa in BSD4.2 e standardizzata in BSD4.4, ma è stata portata su tutti i
68 sistemi che supportano i \textit{socket}, compreso le varianti di System V.}
69 con la funzione \func{select}, il cui prototipo è:
72 \headdecl{sys/types.h}
74 \funcdecl{int select(int n, fd\_set *readfds, fd\_set *writefds, fd\_set
75 *exceptfds, struct timeval *timeout)}
77 Attende che uno dei file descriptor degli insiemi specificati diventi
80 \bodydesc{La funzione in caso di successo restituisce il numero di file
81 descriptor (anche nullo) che sono attivi, e -1 in caso di errore, nel qual
82 caso \var{errno} assumerà uno dei valori:
84 \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato in uno
86 \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
87 \item[\macro{EINVAL}] Si è specificato per \param{n} un valore negativo.
89 ed inoltre \macro{ENOMEM}.
93 La funzione mette il processo in stato di \textit{sleep} (vedi
94 \tabref{tab:proc_proc_states}) fintanto che almeno uno dei file descriptor
95 degli insiemi specificati (\param{readfds}, \param{writefds} e
96 \param{exceptfds}), non diventa attivo, per un tempo massimo specificato da
99 Per specificare quali file descriptor si intende \textsl{selezionare}, la
100 funzione usa un particolare oggetto, il \textit{file descriptor set},
101 identificato dal tipo \type{fd\_set}, che serve ad identificare un insieme di
102 file descriptor, (in maniera analoga a come un \textit{signal set}, vedi
103 \secref{sec:sig_sigset}, identifica un insieme di segnali). Per la
104 manipolazione di questi \textit{file descriptor set} si possono usare delle
105 opportune macro di preprocessore:
107 \headdecl{sys/time.h}
108 \headdecl{sys/types.h}
110 \funcdecl{FD\_ZERO(fd\_set *set)}
111 Inizializza l'insieme (vuoto).
113 \funcdecl{FD\_SET(int fd, fd\_set *set)}
114 Inserisce il file descriptor \param{fd} nell'insieme.
116 \funcdecl{FD\_CLR(int fd, fd\_set *set)}
117 Rimuove il file descriptor \param{fd} nell'insieme.
119 \funcdecl{FD\_ISSET(int fd, fd\_set *set)}
120 Controlla se il file descriptor \param{fd} è nell'insieme.
123 In genere un \textit{file descriptor set} può contenere fino ad un massimo di
124 \macro{FD\_SETSIZE} file descriptor. Questo valore in origine corrispondeva
125 al limite per il numero massimo di file aperti\footnote{ad esempio in Linux,
126 fino alla serie 2.0.x, c'era un limite di 256 file per processo.}, ma
127 quando, come nelle versioni più recenti del kernel, non c'è più un limite
128 massimo, esso indica le dimensioni massime dei numeri usati nei \textit{file
131 La funzione richiede di specificare tre insiemi distinti di file descriptor;
132 il primo, \param{readfds}, verrà osservato per rilevare la disponibilità di
133 effettuare una lettura, il secondo, \param{writefds}, per verificare la
134 possibilità effettuare una scrittura ed il terzo, \param{exceptfds}, per
135 verificare l'esistenza di condizioni eccezionali (come i messaggi urgenti su
136 un \textit{socket}\index{socket}, vedi \secref{sec:xxx_urgent}).
138 La funzione inoltre richiede anche di specificare, tramite l'argomento
139 \param{n}, un valore massimo del numero dei file descriptor usati
140 nell'insieme; si può usare il già citato \macro{FD\_SETSIZE}, oppure il numero
141 più alto dei file descriptor usati nei tre insiemi, aumentato di uno.
143 Infine l'argomento \param{timeout}, specifica un tempo massimo di
144 attesa\footnote{il tempo è valutato come \textit{elapsed time}.} prima che la
145 funzione ritorni; se impostato a \macro{NULL} la funzione attende
146 indefinitamente. Si può specificare anche un tempo nullo (cioè una \var{struct
147 timeval} con i campi impostati a zero), qualora si voglia semplicemente
148 controllare lo stato corrente dei file descriptor.
150 La funzione restituisce il totale dei file descriptor pronti nei tre insiemi,
151 il valore zero indica sempre che si è raggiunto un timeout. Ciascuno dei tre
152 insiemi viene sovrascritto per indicare quale file descriptor è pronto per le
153 operazioni ad esso relative, in modo da poterlo controllare con la macro
154 \macro{FD\_ISSET}. In caso di errore la funzione restituisce -1 e gli insiemi
157 In Linux \func{select} modifica anche il valore di \param{timeout},
158 impostandolo al tempo restante; questo è utile quando la funzione viene
159 interrotta da un segnale, in tal caso infatti si ha un errore di
160 \macro{EINTR}, ed occorre rilanciare la funzione; in questo modo non è
161 necessario ricalcolare tutte le volte il tempo rimanente.\footnote{questo può
162 causare problemi di portabilità sia quando si trasporta codice scritto su
163 Linux che legge questo valore, sia quando si usano programmi scritti per
164 altri sistemi che non dispongono di questa caratteristica e ricalcolano
165 \param{timeout} tutte le volte. In genere la caratteristica è disponibile
166 nei sistemi che derivano da System V e non disponibile per quelli che
169 Come accennato l'interfaccia di \func{select} è una estensione di BSD; anche
170 System V ha introdotto una sua interfaccia per gestire l'\textit{I/O
171 multiplexing}, basata sulla funzione \func{poll},\footnote{la funzione è
172 prevista dallo standard XPG4, ed è stata introdotta in Linux come system
173 call a partire dal kernel 2.1.23 e dalle \acr{libc} 5.4.28.} il cui
175 \begin{prototype}{sys/poll.h}
176 {int poll(struct pollfd *ufds, unsigned int nfds, int timeout)}
178 La funzione attente un cambiamento di stato per uno dei file descriptor
179 specificati da \param{ufds}.
181 \bodydesc{La funzione restituisce il numero di file descriptor con attività in
182 caso di successo, o 0 se c'è stato un timeout; in caso di errore viene
183 restituito -1 ed \var{errno} assumerà uno dei valori:
185 \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato in uno
187 \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
189 ed inoltre \macro{EFAULT} e \macro{ENOMEM}.}
192 La funzione tiene sotto controllo un numero \param{ndfs} di file descriptor
193 specificati attraverso un vettore di puntatori a strutture di tipo
194 \type{pollfd}, la cui definizione è riportata in \figref{fig:file_pollfd}.
195 Come \func{select} anche \func{poll} permette di interrompere l'attesa dopo un
196 certo tempo, che va specificato attraverso \param{timeout} in numero di
197 millisecondi (un valore negativo indica un'attesa indefinita).
200 \footnotesize \centering
201 \begin{minipage}[c]{15cm}
202 \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
204 int fd; /* file descriptor */
205 short events; /* requested events */
206 short revents; /* returned events */
211 \caption{La struttura \type{pollfd}, utilizzata per specificare le modalità
212 di controllo di un file descriptor alla funzione \func{poll}.}
213 \label{fig:file_pollfd}
216 Per ciascun file da controllare deve essere opportunamente predisposta una
217 struttura \type{pollfd}; nel campo \var{fd} deve essere specificato il file
218 descriptor, mentre nel campo \var{events} il tipo di evento su cui si vuole
219 attendere; quest'ultimo deve essere specificato come maschera binaria dei
220 primi tre valori riportati in \tabref{tab:file_pollfd_flags} (gli altri
221 vengono utilizzati solo per \var{revents} come valori in uscita).
226 \begin{tabular}[c]{|l|c|l|}
228 \textbf{Flag} & \textbf{Valore} & \textbf{Significato} \\
231 \macro{POLLIN} & 0x001 & È possibile la lettura immediata.\\
232 \macro{POLLPRI} & 0x002 & Sono presenti dati urgenti.\\
233 \macro{POLLOUT} & 0x004 & È possibile la scrittura immediata.\\
235 \macro{POLLERR} & 0x008 & C'è una condizione di errore.\\
236 \macro{POLLHUP} & 0x010 & Si è verificato un hung-up.\\
237 \macro{POLLNVAL} & 0x020 & Il file descriptor non è aperto.\\
239 \macro{POLLRDNORM}& 0x040 & Sono disponibili in lettura dati normali.\\
240 \macro{POLLRDBAND}& 0x080 & Sono disponibili in lettura dati ad alta
242 \macro{POLLWRNORM}& 0x100 & È possibile la scrittura di dati normali. \\
243 \macro{POLLWRBAND}& 0x200 & È possibile la scrittura di dati ad
245 \macro{POLLMSG} & 0x400 & Estensione propria di Linux.\\
248 \caption{Costanti per l'identificazione dei vari bit dei campi
249 \var{events} e \var{revents} di \type{pollfd}.}
250 \label{tab:file_pollfd_flags}
253 La funzione ritorna, restituendo il numero di file per i quali si è verificata
254 una delle condizioni di attesa richieste od un errore. Lo stato dei file
255 all'uscita della funzione viene restituito nel campo \var{revents} della
256 relativa struttura \type{pollfd}, che viene impostato alla maschera binaria
257 dei valori riportati in \tabref{tab:file_pollfd_flags}, ed oltre alle tre
258 condizioni specificate tramite \var{events} può riportare anche l'occorrere di
259 una condizione di errore.
261 Lo standard POSIX è rimasto a lungo senza primitive per l'\textit{I/O
262 multiplexing}, che è stata introdotto con le ultime revisioni dello standard
263 (POSIX 1003.1g-2000 e POSIX 1003.1-2001). Esso prevede che tutte le funzioni
264 ad esso relative vengano dichiarate nell'header \file{sys/select.h}, che
265 sostituisce i precedenti, ed aggiunge a \func{select} una nuova funzione
266 \func{pselect},\footnote{il supporto per lo standard POSIX 1003.1-2001, ed
267 l'header \file{sys/select.h}, compaiono in Linux a partire dalle \acr{glibc}
268 2.1. Le \acr{libc4} e \acr{libc5} non contengono questo header, le
269 \acr{glibc} 2.0 contengono una definizione sbagliata di \func{psignal},
270 senza l'argomento \param{sigmask}, la definizione corretta è presente dalle
271 \acr{glibc} 2.1-2.2.1 se si è definito \macro{\_GNU\_SOURCE} e nelle
272 \acr{glibc} 2.2.2-2.2.4 se si è definito \macro{\_XOPEN\_SOURCE} con valore
273 maggiore di 600.} il cui prototipo è:
274 \begin{prototype}{sys/select.h}
275 {int pselect(int n, fd\_set *readfds, fd\_set *writefds, fd\_set *exceptfds,
276 struct timespec *timeout, sigset\_t *sigmask)}
278 Attende che uno dei file descriptor degli insiemi specificati diventi
281 \bodydesc{La funzione in caso di successo restituisce il numero di file
282 descriptor (anche nullo) che sono attivi, e -1 in caso di errore, nel qual
283 caso \var{errno} assumerà uno dei valori:
285 \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato in uno
287 \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
288 \item[\macro{EINVAL}] Si è specificato per \param{n} un valore negativo.
290 ed inoltre \macro{ENOMEM}.}
293 La funzione è sostanzialmente identica a \func{select}, solo che usa una
294 struttura \type{timespec} per indicare con maggiore precisione il timeout e
295 non ne aggiorna il valore in caso di interruzione, inoltre prende un argomento
296 aggiuntivo \param{sigmask} che è il puntatore ad una maschera di segnali (si
297 veda \secref{sec:sig_sigmask}). La maschera corrente viene sostituita da
298 questa immediatamente prima di eseguire l'attesa, e ripristinata al ritorno
301 L'uso di \param{sigmask} è stato introdotto allo scopo di prevenire possibili
302 race condition\footnote{in Linux però, non esistendo una system call apposita,
303 la funzione è implementata nelle \acr{glibc} usando \func{select}, e la
304 possibilità di una race condition resta.} quando si deve eseguire un test su
305 una variabile assegnata da un manipolatore sulla base dell'occorrenza di un
306 segnale per decidere se lanciare \func{select}. Fra il test e l'esecuzione è
307 presente una finestra in cui potrebbe arrivare il segnale che non sarebbe
308 rilevato; la race condition diventa superabile disabilitando il segnale prima
309 del test e riabilitandolo poi grazie all'uso di \param{sigmask}.
313 \subsection{L'I/O asincrono}
314 \label{sec:file_asyncronous_io}
316 Una modalità alternativa all'uso dell'\textit{I/O multiplexing} è quella di
317 fare ricorso al cosiddetto \textsl{I/O asincrono}. Il concetto base
318 dell'\textsl{I/O asincrono} è che le funzioni di I/O non attendono il
319 completamento delle operazioni prima di ritornare, così che il processo non
320 viene bloccato. In questo modo diventa ad esempio possibile effettuare una
321 richiesta preventiva di dati, in modo da poter effettuare in contemporanea le
322 operazioni di calcolo e quelle di I/O.
324 Abbiamo accennato in \secref{sec:file_open} che è possibile, attraverso l'uso
325 del flag \macro{O\_ASYNC},\footnote{l'uso del flag di \macro{O\_ASYNC} e dei
326 comandi \macro{F\_SETOWN} e \macro{F\_GETOWN} per \func{fcntl} è specifico
327 di Linux e BSD.} aprire un file in modalità asincrona, così come è possibile
328 attivare in un secondo tempo questa modalità impostando questo flag attraverso
329 l'uso di \func{fcntl} con il comando \macro{F\_SETFL} (vedi
330 \secref{sec:file_fcntl}).
332 In realtà in questo caso non si tratta di I/O asincrono vero e proprio, quanto
333 di un meccanismo asincrono di notifica delle variazione dello stato del file
334 descriptor; quello che succede è che il sistema genera un segnale (normalmente
335 \macro{SIGIO}, ma è possibile usarne altri) tutte le volte che diventa
336 possibile leggere o scrivere dal file descriptor che si è posto in questa
337 modalità. Si può inoltre selezionare, con il comando \macro{F\_SETOWN} di
338 \func{fcntl}, quale processo (o gruppo di processi) riceverà il segnale.
340 In questo modo si può evitare l'uso delle funzioni \func{poll} o \func{select}
341 che, quando vengono usate con un numero molto grande di file descriptor, non
342 hanno buone prestazioni. In tal caso infatti la maggior parte del loro tempo
343 di esecuzione è impegnato ad eseguire una scansione su tutti i file descriptor
344 tenuti sotto controllo per determinare quali di essi (in genere una piccola
345 percentuale) sono diventati attivi.
347 Tuttavia con l'implementazione classica dei segnali questa modalità di I/O
348 presenta notevoli problemi, dato che non è possibile determinare, quando sono
349 più di uno, qual'è il file descriptor responsabile dell'emissione del segnale.
350 Linux però supporta le estensioni POSIX.1b dei segnali che permettono di
351 superare il problema facendo ricorso alle informazioni aggiuntive restituite
352 attraverso la struttura \type{siginfo\_t}, utilizzando la forma estesa
353 \var{sa\_sigaction} del manipolatore (si riveda quanto illustrato in
354 \secref{sec:sig_sigaction}).
356 Per far questo però occorre utilizzare le funzionalità dei segnali real-time
357 (vedi \secref{sec:sig_real_time}) impostando esplicitamente con il comando
358 \macro{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare in caso di
359 I/O asincrono (il segnale predefinito è \macro{SIGIO}). In questo caso il
360 manipolatore tutte le volte che riceverà \macro{SI\_SIGIO} come valore del
361 campo \var{si\_code}\footnote{il valore resta \macro{SI\_SIGIO} qualunque sia
362 il segnale che si è associato all'I/O asincrono, ed indica appunto che il
363 segnale è stato generato a causa di attività nell'I/O asincrono.} di
364 \type{siginfo\_t}, troverà nel campo \var{si\_fd} il valore del file
365 descriptor che ha generato il segnale.
367 Un secondo vantaggio dell'uso dei segnali real-time è che essendo dotati di
368 una coda di consegna ogni segnale sarà associato ad uno solo file descriptor;
369 inoltre sarà possibile stabilire delle priorità nella risposta a seconda del
370 segnale usato. In questo modo si può identificare immediatamente un file su
371 cui l'accesso è diventato possibile evitando completamente l'uso di funzioni
372 come \func{poll} e \func{select}, almeno fintanto che non si satura la coda;
373 si eccedono le dimensioni di quest'ultima; in tal caso infatti il kernel, non
374 potendo più assicurare il comportamento corretto per un segnale real-time,
375 invierà al suo posto un \var{SIGIO}, su cui si accumuleranno tutti i segnali
376 in eccesso, e si dovrà determinare al solito modo quali sono i file diventati
379 Benché la modalità di apertura asincrona di un file possa risultare utile in
380 varie occasioni (in particolar modo con i socket e gli altri file per i quali
381 le funzioni di I/O sono system call lente), essa è comunque limitata alla
382 notifica della disponibilità del file descriptor per le operazioni di I/O, e
383 non ad uno svolgimento asincrono delle medesime. Lo standard POSIX.1b
384 definisce anche una interfaccia apposita per l'I/O asincrono, che prevede un
385 insieme di funzioni dedicate, completamente separate rispetto a quelle usate
388 In generale questa interfaccia è completamente astratta e può essere
389 implementata sia direttamente nel kernel, che in user space attraverso l'uso
390 di thread. Al momento\footnote{fino ai kernel della serie 2.4.x, nella serie
391 2.5.x è però iniziato un lavoro completo di riscrittura di tutto il sistema
392 di I/O, che prevede anche l'introduzione di un nuovo layer per l'I/O
393 asincrono (effettuato a partire dal 2.5.32).} esiste una sola versione
394 stabile di questa interfaccia, quella delle \acr{glibc}, che è realizzata
395 completamente in user space. Esistono comunque vari progetti sperimentali
396 (come il KAIO della SGI, o i patch di Benjamin La Haise) che prevedono un
397 supporto diretto da parte del kernel.
399 Lo standard prevede che tutte le operazioni di I/O asincrono siano controllate
400 attraverso l'uso di una apposita struttura \type{aiocb} (il cui nome sta per
401 \textit{asyncronous I/O control block}), che viene passata come argomento a
402 tutte le funzioni dell'interfaccia. La sua definizione, come effettuata in
403 \file{aio.h}, è riportata in \figref{fig:file_aiocb}. Nello steso file è
404 definita la macro \macro{\_POSIX\_ASYNCHRONOUS\_IO}, che dichiara la
405 disponibilità dell'interfaccia per l'I/O asincrono.
408 \footnotesize \centering
409 \begin{minipage}[c]{15cm}
410 \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
413 int aio_fildes; /* File descriptor. */
414 off_t aio_offset; /* File offset */
415 int aio_lio_opcode; /* Operation to be performed. */
416 int aio_reqprio; /* Request priority offset. */
417 volatile void *aio_buf; /* Location of buffer. */
418 size_t aio_nbytes; /* Length of transfer. */
419 struct sigevent aio_sigevent; /* Signal number and value. */
424 \caption{La struttura \type{aiocb}, usata per il controllo dell'I/O
426 \label{fig:file_aiocb}
429 Le operazioni di I/O asincrono possono essere effettuate solo su un file già
430 aperto; il file deve inoltre supportare la funzione \func{lseek},
431 pertanto terminali e pipe sono esclusi. Non c'è limite al numero di operazioni
432 contemporanee effettuabili su un singolo file.
434 Ogni operazione deve inizializzare opportunamente un \textit{control block}.
435 Il file descriptor su cui operare deve essere specificato tramite il campo
436 \var{aio\_fildes}; dato che più operazioni possono essere eseguita in maniera
437 asincrona, il concetto di posizione corrente sul file viene a mancare;
438 pertanto si deve sempre specificare nel campo \var{aio\_offset} la posizione
439 sul file da cui i dati saranno letti o scritti. Nel campo \var{aio\_buf} deve
440 essere specificato l'indirizzo del buffer usato per l'I/O, ed in
441 \var{aio\_nbytes} la lunghezza del blocco di dati da trasferire.
443 Il campo \var{aio\_reqprio} permette di impostare la priorità delle operazioni
444 di I/O.\footnote{in generale perché ciò sia possibile occorre che la
445 piattaforma supporti questa caratteristica, questo viene indicato definendo
446 le macro \macro{\_POSIX\_PRIORITIZED\_IO}, e
447 \macro{\_POSIX\_PRIORITY\_SCHEDULING}.} La priorità viene impostata a
448 partire da quella del processo chiamante (vedi \secref{sec:proc_priority}),
449 cui viene sottratto il valore di questo campo.
451 Il campo \var{aio\_lio\_opcode} è usato soltanto dalla funzione
452 \func{lio\_listio}, che, come vedremo più avanti, permette di eseguire con una
453 sola chiamata una serie di operazioni, usando un vettore di \textit{control
454 block}. Tramite questo campo si specifica quale è la natura di ciascuna di
458 \footnotesize \centering
459 \begin{minipage}[c]{15cm}
460 \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
463 sigval_t sigev_value;
466 sigev_notify_function;
467 sigev_notify_attributes;
472 \caption{La struttura \type{sigevent}, usata per specificare le modalità di
473 notifica degli eventi relativi alle operazioni di I/O asincrono.}
474 \label{fig:file_sigevent}
477 Infine il campo \var{aio\_sigevent} è una struttura di tipo \type{sigevent}
478 che serve a specificare il modo in cui si vuole che venga effettuata la
479 notifica del completamento delle operazioni richieste. La struttura è
480 riportata in \secref{fig:file_sigevent}; il campo \var{sigev\_notify} è quello
481 che indica le modalità della notifica, esso può assumere i tre valori:
482 \begin{basedescript}{\desclabelwidth{3.0cm}}
483 \item[\macro{SIGEV\_NONE}] Non viene inviata nessuna notifica.
484 \item[\macro{SIGEV\_SIGNAL}] La notifica viene effettuata inviando al processo
485 chiamante il segnale specificato nel campo \var{sigev\_signo}, se il
486 manipolatore è installato con \macro{SA\_SIGINFO}, il gli verrà restituito
487 il valore di \var{sigev\_value} in come valore del campo \var{si\_value} per
489 \item[\macro{SIGEV\_THREAD}] La notifica viene effettuata creando un nuovo
490 thread che esegue la funzione specificata da \var{sigev\_notify\_function},
491 con gli attributi specificati da \var{sigev\_notify\_attribute}.
494 Le due funzioni base dell'interfaccia per l'I/O asincrono sono
495 \func{aio\_read} ed \func{aio\_write}. Esse permettono di richiedere una
496 lettura od una scrittura asincrona di dati, usando la struttura \type{aiocb}
497 appena descritta; i rispettivi prototipi sono:
501 \funcdecl{int aio\_read(struct aiocb *aiocbp)}
502 Richiede una lettura asincrona secondo quanto specificato con \param{aiocbp}.
504 \funcdecl{int aio\_write(struct aiocb *aiocbp)}
505 Richiede una scrittura asincrona secondo quanto specificato con
508 \bodydesc{Le funzioni restituiscono 0 in caso di successo, e -1 in caso di
509 errore, nel qual caso \var{errno} assumerà uno dei valori:
511 \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato.
512 \item[\macro{ENOSYS}] La funzione non è implementata.
513 \item[\macro{EINVAL}] Si è specificato un valore non valido per i campi
514 \var{aio\_offset} o \var{aio\_reqprio} di \param{aiocbp}.
515 \item[\macro{EAGAIN}] La coda delle richieste è momentaneamente piena.
520 Entrambe le funzioni ritornano immediatamente dopo aver messo in coda la
521 richiesta, o in caso di errore. Non è detto che gli errori \macro{EBADF} ed
522 \macro{EINVAL} siano rilevati immediatamente al momento della chiamata,
523 potrebbero anche emergere nelle fasi successive delle operazioni. Lettura e
524 scrittura avvengono alla posizione indicata da \var{aio\_offset}, a meno che
525 il file non sia stato aperto in \textit{append mode} (vedi
526 \secref{sec:file_open}), nel qual caso le scritture vengono effettuate
527 comunque alla fine de file, nell'ordine delle chiamate a \func{aio\_write}.
529 Si tenga inoltre presente che deallocare la memoria indirizzata da
530 \param{aiocbp} o modificarne i valori prima della conclusione di una
531 operazione può dar luogo a risultati impredicibili, perché l'accesso ai vari
532 campi per eseguire l'operazione può avvenire in un momento qualsiasi dopo la
533 richiesta. Questo comporta che occorre evitare di usare per \param{aiocbp}
534 variabili automatiche e che non si deve riutilizzare la stessa struttura per
535 un ulteriore operazione fintanto che la precedente non sia stata ultimata. In
536 generale per ogni operazione di I/O asincrono si deve utilizzare una diversa
537 struttura \type{aiocb}.
539 Dato che si opera in modalità asincrona, il successo di \func{aio\_read} o
540 \func{aio\_write} non implica che le operazioni siano state effettivamente
541 eseguite in maniera corretta; per verificarne l'esito l'interfaccia prevede
542 altre due funzioni, che permettono di controllare lo stato di esecuzione. La
543 prima è \func{aio\_error}, che serve a determinare un eventuale stato di
544 errore; il suo prototipo è:
545 \begin{prototype}{aio.h}
546 {int aio\_error(const struct aiocb *aiocbp)}
548 Determina lo stato di errore delle operazioni di I/O associate a
551 \bodydesc{La funzione restituisce 0 se le operazioni si sono concluse con
552 successo, altrimenti restituisce il codice di errore relativo al loro
556 Se l'operazione non si è ancora completata viene restituito l'errore di
557 \macro{EINPROGRESS}. La funzione ritorna zero quando l'operazione si è
558 conclusa con successo, altrimenti restituisce il codice dell'errore
559 verificatosi, ed esegue la corrispondente impostazione di \var{errno}. Il
560 codice può essere sia \macro{EINVAL} ed \macro{EBADF}, dovuti ad un valore
561 errato per \param{aiocbp}, che uno degli errori possibili durante l'esecuzione
562 dell'operazione di I/O richiesta, nel qual caso saranno restituiti, a seconda
563 del caso, i codici di errore delle system call \func{read}, \func{write} e
566 Una volta che si sia certi che le operazioni siano state concluse (cioè dopo
567 che una chiamata ad \func{aio\_error} non ha restituito \macro{EINPROGRESS},
568 si potrà usare la seconda funzione dell'interfaccia, \func{aio\_return}, che
569 permette di verificare il completamento delle operazioni di I/O asincrono; il
571 \begin{prototype}{aio.h}
572 {ssize\_t aio\_return(const struct aiocb *aiocbp)}
574 Recupera il valore dello stato di ritorno delle operazioni di I/O associate a
577 \bodydesc{La funzione restituisce lo stato di uscita dell'operazione
581 La funzione deve essere chiamata una sola volte per ciascuna operazione
582 asincrona, essa infatti fa sì che il sistema rilasci le risorse ad essa
583 associate. É per questo motivo che occorre chiamare la funzione solo dopo che
584 l'operazione cui \param{aiocbp} fa riferimento si è completata. Una chiamata
585 precedente il completamento delle operazioni darebbe risultati indeterminati.
587 La funzione restituisce il valore di ritorno relativo all'operazione eseguita,
588 così come ricavato dalla sottostante system call (il numero di byte letti,
589 scritti o il valore di ritorno di \func{fsync}). É importante chiamare sempre
590 questa funzione, altrimenti le risorse disponibili per le operazioni di I/O
591 asincrono non verrebbero liberate, rischiando di arrivare ad un loro
594 Oltre alle operazioni di lettura e scrittura l'interfaccia POSIX.1b mette a
595 disposizione un'altra operazione, quella di sincronizzazione dell'I/O, essa è
596 compiuta dalla funzione \func{aio\_fsync}, che ha lo stesso effetto della
597 analoga \func{fsync}, ma viene eseguita in maniera asincrona; il suo prototipo
599 \begin{prototype}{aio.h}
600 {ssize\_t aio\_return(int op, struct aiocb *aiocbp)}
602 Richiede la sincronizzazione dei dati per il file indicato da \param{aiocbp}.
604 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
605 errore, che può essere, con le stesse modalità di \func{aio\_read},
606 \macro{EAGAIN}, \macro{EBADF} o \macro{EINVAL}.}
609 La funzione richiede la sincronizzazione delle operazioni di I/O, ritornando
610 immediatamente. L'esecuzione effettiva della sincronizzazione dovrà essere
611 verificata con \func{aio\_error} e \func{aio\_return} come per le operazioni
612 di lettura e scrittura. L'argomento \param{op} permette di indicare la
613 modalità di esecuzione, se si specifica il valore \macro{O\_DSYNC} le
614 operazioni saranno completate con una chiamata a \func{fdatasync}, se si
615 specifica \macro{O\_SYNC} con una chiamata a \func{fsync} (per i dettagli vedi
616 \secref{sec:file_sync}).
618 Il successo della chiamata assicura la sincronizzazione delle operazioni fino
619 allora richieste, niente è garantito riguardo la sincronizzazione dei dati
620 relativi ad eventuali operazioni richieste successivamente. Se si è
621 specificato un meccanismo di notifica questo sarà innescato una volta che le
622 operazioni di sincronizzazione dei dati saranno completate.
624 In alcuni casi può essere necessario interrompere le operazioni (in genere
625 quando viene richiesta un'uscita immediata dal programma), per questo lo
626 standard POSIX.1b prevede una funzioni apposita, \func{aio\_cancel}, che
627 permette di cancellare una operazione richiesta in precedenza; il suo
629 \begin{prototype}{aio.h}
630 {int aio\_cancel(int fildes, struct aiocb *aiocbp)}
632 Richiede la cancellazione delle operazioni sul file \param{fildes} specificate
635 \bodydesc{La funzione restituisce il risultato dell'operazione con un codice
636 di positivo, e -1 in caso di errore, che avviene qualora si sia specificato
637 un valore non valido di \param{fildes}, imposta \var{errno} al valore
641 La funzione permette di cancellare una operazione specifica sul file
642 \param{fildes}, o tutte le operazioni pendenti, specificando \macro{NULL} come
643 valore di \param{aiocbp}. Quando una operazione viene cancellata una
644 successiva chiamata ad \func{aio\_error} riporterà \macro{ECANCELED} come
645 codice di errore, ed il suo codice di ritorno sarà -1, inoltre il meccanismo
646 di notifica non verrà invocato. Se si specifica una operazione relativa ad un
647 altro file descriptor il risultato è indeterminato.
649 In caso di successo, i possibili valori di ritorno per \func{aio\_cancel} sono
650 tre (anch'essi definiti in \file{aio.h}):
651 \begin{basedescript}{\desclabelwidth{3.0cm}}
652 \item[\macro{AIO\_ALLDONE}] indica che le operazioni di cui si è richiesta la
653 cancellazione sono state già completate,
655 \item[\macro{AIO\_CANCELED}] indica che tutte le operazioni richieste sono
658 \item[\macro{AIO\_NOTCANCELED}] indica che alcune delle operazioni erano in
659 corso e non sono state cancellate.
662 Nel caso si abbia \macro{AIO\_NOTCANCELED} occorrerà chiamare
663 \func{aio\_error} per determinare quali sono le operazioni effettivamente
664 cancellate. Le operazioni che non sono state cancellate proseguiranno il loro
665 corso normale, compreso quanto richiesto riguardo al meccanismo di notifica
666 del loro avvenuto completamento.
668 Benché l'I/O asincrono preveda un meccanismo di notifica, l'interfaccia
669 fornisce anche una apposita funzione, \func{aio\_suspend}, che permette di
670 sospendere l'esecuzione del processo chiamante fino al completamento di una
671 specifica operazione; il suo prototipo è:
672 \begin{prototype}{aio.h}
673 {int aio\_suspend(const struct aiocb * const list[], int nent, const struct
676 Attende, per un massimo di \param{timeout}, il completamento di una delle
677 operazioni specificate da \param{list}.
679 \bodydesc{La funzione restituisce 0 se una (o più) operazioni sono state
680 completate, e -1 in caso di errore nel qual caso \var{errno} assumerà uno
683 \item[\macro{EAGAIN}] Nessuna operazione è stata completata entro
685 \item[\macro{ENOSYS}] La funzione non è implementata.
686 \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
691 La funzione permette di bloccare il processo fintanto che almeno una delle
692 \param{nent} operazioni specificate nella lista \param{list} è completata, per
693 un tempo massimo specificato da \param{timout}, o fintanto che non arrivi un
694 segnale.\footnote{si tenga conto che questo segnale può anche essere quello
695 utilizzato come meccanismo di notifica.} La lista deve essere inizializzata
696 con delle strutture \var{aiocb} relative ad operazioni effettivamente
697 richieste, ma può contenere puntatori nulli, che saranno ignorati. In caso si
698 siano specificati valori non validi l'effetto è indefinito. Un valore
699 \macro{NULL} per \param{timout} comporta l'assenza di timeout.
701 Lo standard POSIX.1b infine ha previsto pure una funzione, \func{lio\_listio},
702 che permette di effettuare la richiesta di una intera lista di operazioni di
703 lettura o scrittura; il suo prototipo è:
704 \begin{prototype}{aio.h}
705 {int lio\_listio(int mode, struct aiocb * const list[], int nent, struct
708 Richiede l'esecuzione delle operazioni di I/O elencata da \param{list},
709 secondo la modalità \param{mode}.
711 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
712 errore, nel qual caso \var{errno} assumerà uno dei valori:
714 \item[\macro{EAGAIN}] Nessuna operazione è stata completata entro
716 \item[\macro{ENOSYS}] La funzione non è implementata.
717 \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
722 La funzione esegue la richiesta delle \param{nent} operazioni indicate dalla
723 lista \param{list}; questa deve contenere gli indirizzi di altrettanti
724 \textit{control block}, opportunamente inizializzati; in particolare nel caso
725 dovrà essere specificato il tipo di operazione tramite il campo
726 \var{aio\_lio\_opcode}, che può prendere i tre valori:
727 \begin{basedescript}{\desclabelwidth{2.0cm}}
728 \item[\macro{LIO\_READ}] si richiede una operazione di lettura.
729 \item[\macro{LIO\_WRITE}] si richiede una operazione di scrittura.
730 \item[\macro{LIO\_NOP}] non si effettua nessuna operazione.
732 l'ultimo valore viene usato quando si ha a che fare con un vettore di
733 dimensione fissa, per poter specificare solo alcune operazioni, o quando si è
734 dovuto cancellare delle operazioni e si deve ripetere la richiesta per quelle
737 L'argomento \param{mode} permette di stabilire il comportamento della
738 funzione, se viene specificato il valore \macro{LIO\_WAIT} la funzione si
739 blocca fino al completamento di tutte le operazioni richieste; se invece si
740 specifica \macro{LIO\_NOWAIT} la funzione ritorna immediatamente dopo aver
741 messo in coda tutte le richieste. In questo caso il chiamante può richiedere
742 la notifica del completamento di tutte le richieste, impostando l'argomento
743 \param{sig} in maniera analoga a come si fa per il campo \var{aio\_sigevent}
748 \subsection{I/O vettorizzato}
749 \label{sec:file_multiple_io}
751 Un caso abbastanza comune è quello in cui ci si trova a dover eseguire una
752 serie multipla di operazioni di I/O, come una serie di letture o scritture di
753 vari buffer. Un esempio tipico è quando i dati sono strutturati nei campi di
754 una struttura ed essi devono essere caricati o salvati su un file. Benché
755 l'operazione sia facilmente eseguibile attraverso una serie multipla di
756 chiamate, ci sono casi in cui si vuole poter contare sulla atomicità delle
759 Per questo motivo BSD 4.2\footnote{Le due funzioni sono riprese da BSD4.4 ed
760 integrate anche dallo standard Unix 98; fino alle libc5 Linux usava
761 \type{size\_t} come tipo dell'argomento \param{count}, una scelta logica,
762 che però è stata dismessa per restare aderenti allo standard.} ha introdotto
763 due nuove system call, \func{readv} e \func{writev}, che permettono di
764 effettuare con una sola chiamata una lettura o una scrittura su una serie di
765 buffer (quello che viene chiamato \textsl{I/O vettorizzato}. I relativi
770 \funcdecl{int readv(int fd, const struct iovec *vector, int count)} Esegue
771 una lettura vettorizzata da \param{fd} nei \param{count} buffer specificati
774 \funcdecl{int writev(int fd, const struct iovec *vector, int count)} Esegue
775 una scrittura vettorizzata da \param{fd} nei \param{count} buffer
776 specificati da \param{vector}.
778 \bodydesc{Le funzioni restituiscono il numero di byte letti o scritti in
779 caso di successo, e -1 in caso di errore, nel qual caso \var{errno}
780 assumerà uno dei valori:
782 \item[\macro{EBADF}] si è specificato un file descriptor sbagliato.
783 \item[\macro{EINVAL}] si è specificato un valore non valido per uno degli
784 argomenti (ad esempio \param{count} è maggiore di \macro{MAX\_IOVEC}).
785 \item[\macro{EINTR}] la funzione è stata interrotta da un segnale prima di
786 di avere eseguito una qualunque lettura o scrittura.
787 \item[\macro{EAGAIN}] \param{fd} è stato aperto in modalità non bloccante e
788 non ci sono dati in lettura.
789 \item[\macro{EOPNOTSUPP}] La coda delle richieste è momentaneamente piena.
791 ed inoltre \macro{EISDIR}, \macro{ENOMEM}, \macro{EFAULT} (se non sono stato
792 allocati correttamente i buffer specificati nei campi \func{iov\_base}), più
793 tutti gli ulteriori errori che potrebbero avere le usuali funzioni di
794 lettura e scrittura eseguite su \param{fd}.}
797 Entrambe le funzioni usano una struttura \type{iovec}, definita in
798 \figref{fig:file_iovec}, che definisce dove i dati devono essere letti o
799 scritti. Il primo campo, \var{iov\_base}, contiene l'indirizzo del buffer ed
800 il secondo, \var{iov\_len}, la dimensione dello stesso.
803 \footnotesize \centering
804 \begin{minipage}[c]{15cm}
805 \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
807 __ptr_t iov_base; /* Starting address */
808 size_t iov_len; /* Length in bytes */
813 \caption{La struttura \type{iovec}, usata dalle operazioni di I/O
815 \label{fig:file_iovec}
818 I buffer da utilizzare sono indicati attraverso l'argomento \param{vector} che
819 è un vettore di strutture \var{iovec}, la cui lunghezza è specificata da
820 \param{count}. Ciascuna struttura dovrà essere inizializzata per
821 opportunamente per indicare i vari buffer da/verso i quali verrà eseguito il
822 trasferimento dei dati. Essi verranno letti (o scritti) nell'ordine in cui li
823 si sono specificati nel vettore \var{vector}.
826 \subsection{File mappati in memoria}
827 \label{sec:file_memory_map}
829 Una modalità alternativa di I/O, che usa una interfaccia completamente diversa
830 rispetto a quella classica vista in \capref{cha:file_unix_interface}, è il
831 cosiddetto \textit{memory-mapped I/O}, che, attraverso il meccanismo della
832 \textsl{paginazione}\index{paginazione} usato dalla memoria virtuale (vedi
833 \secref{sec:proc_mem_gen}), permette di \textsl{mappare} il contenuto di un
834 file in una sezione dello spazio di indirizzi del processo. Il meccanismo è
835 illustrato in \figref{fig:file_mmap_layout}, una sezione del file viene
836 riportata direttamente nello spazio degli indirizzi del programma. Tutte le
837 operazioni su questa zona verranno riportate indietro sul file dal meccanismo
838 della memoria virtuale che trasferirà il contenuto di quel segmento sul file
839 invece che nella swap, per cui si può parlare tanto di file mappato in
840 memoria, quanto di memoria mappata su file.
844 \includegraphics[width=9.5cm]{img/mmap_layout}
845 \caption{Disposizione della memoria di un processo quando si esegue la
846 mappatura in memoria di un file.}
847 \label{fig:file_mmap_layout}
850 Tutto questo comporta una notevole semplificazione delle operazioni di I/O, in
851 quanto non sarà più necessario utilizzare dei buffer intermedi su cui
852 appoggiare i dati da traferire, ma questi potranno essere acceduti
853 direttamente nella sezione di memoria mappata; inoltre questa interfaccia è
854 più efficiente delle usuali funzioni di I/O, in quanto permette di caricare in
855 memoria solo le parti del file che sono effettivamente usate ad un dato
858 Infatti, dato che l'accesso è fatto direttamente attraverso la memoria
859 virtuale, la sezione di memoria mappata su cui si opera sarà a sua volta letta
860 o scritta sul file una pagina alla volta e solo per le parti effettivamente
861 usate, il tutto in maniera completamente trasparente al processo; l'accesso
862 alle pagine non ancora caricate avverrà allo stesso modo con cui vengono
863 caricate in memoria le pagine che sono state salvate sullo swap.
865 Infine in situazioni in cui la memoria è scarsa, le pagine che mappano un
866 file vengono salvate automaticamente, così come le pagine dei programmi
867 vengono scritte sulla swap; questo consente di accedere ai file su dimensioni
868 il cui solo limite è quello dello spazio di indirizzi disponibile, e non della
869 memoria su cui possono esserne lette delle porzioni.
871 L'interfaccia prevede varie funzioni per la gestione del \textit{memory mapped
872 I/O}, la prima di queste è \func{mmap}, che serve ad eseguire la mappatura
873 in memoria di un file; il suo prototipo è:
877 \headdecl{sys/mman.h}
879 \funcdecl{void * mmap(void * start, size\_t length, int prot, int flags, int
882 Esegue la mappatura in memoria del file \param{fd}.
884 \bodydesc{La funzione restituisce il puntatore alla zona di memoria mappata
885 in caso di successo, e \macro{MAP\_FAILED} (-1) in caso di errore, nel
886 qual caso \var{errno} assumerà uno dei valori:
888 \item[\macro{EBADF}] Il file descriptor non è valido, e non si è usato
889 \macro{MAP\_ANONYMOUS}.
890 \item[\macro{EACCES}] Il file descriptor non si riferisce ad un file
891 regolare, o si è richiesto \macro{MAP\_PRIVATE} ma \param{fd} non è
892 aperto in lettura, o si è richiesto \macro{MAP\_SHARED} e impostato
893 \macro{PROT\_WRITE} ed \param{fd} non è aperto in lettura/scrittura, o
894 si è impostato \macro{PROT\_WRITE} ed \param{fd} è in
895 \textit{append-only}.
896 \item[\macro{EINVAL}] I valori di \param{start}, \param{length} o
897 \param{offset} non sono validi (o troppo grandi o non allineati sulla
898 dimensione delle pagine).
899 \item[\macro{ETXTBSY}] Si è impostato \macro{MAP\_DENYWRITE} ma \param{fd}
900 è aperto in scrittura.
901 \item[\macro{EAGAIN}] Il file è bloccato, o si è bloccata troppa memoria.
902 \item[\macro{ENOMEM}] Non c'è memoria o si è superato il limite sul numero
903 di mappature possibili.
904 \item[\macro{ENODEV}] Il filesystem di \param{fd} non supporta il memory
910 La funzione richiede di mappare in memoria la sezione del file \param{fd} a
911 partire da \param{offset} per \param{lenght} byte, preferibilmente
912 all'indirizzo \param{start}. Il valore di \param{offset} deve essere un
913 multiplo della dimensione di una pagina di memoria.
919 \begin{tabular}[c]{|l|l|}
921 \textbf{Valore} & \textbf{Significato} \\
924 \macro{PROT\_EXEC} & Le pagine possono essere eseguite.\\
925 \macro{PROT\_READ} & Le pagine possono essere lette.\\
926 \macro{PROT\_WRITE} & Le pagine possono essere scritte.\\
927 \macro{PROT\_NONE} & L'accesso alle pagine è vietato.\\
930 \caption{Valori dell'argomento \param{prot} di \func{mmap}, relativi alla
931 protezione applicate alle pagine del file mappate in memoria.}
932 \label{tab:file_mmap_prot}
936 Il valore dell'argomento \param{prot} indica la protezione\footnote{in Linux
937 la memoria reale è divisa in pagine: ogni processo vede la sua memoria
938 attraverso uno o più segmenti lineari di memoria virtuale. Per ciascuno di
939 questi segmenti il kernel mantiene nella \textit{page table} la mappatura
940 sulle pagine di memoria reale, ed le modalità di accesso (lettura,
941 esecuzione, scrittura); una loro violazione causa quella che si chiama una
942 \textit{segment violation}, e la relativa emissione del segnale
943 \macro{SIGSEGV}.} da applicare al segmento di memoria e deve essere
944 specificato come maschera binaria ottenuta dall'OR di uno o più dei valori
945 riportati in \tabref{tab:file_mmap_flag}; il valore specificato deve essere
946 compatibile con la modalità di accesso con cui si è aperto il file.
948 L'argomento \param{flags} specifica infine qual'è il tipo di oggetto mappato,
949 le opzioni relative alle modalità con cui è effettuata la mappatura e alle
950 modalità con cui le modifiche alla memoria mappata vengono condivise o
951 mantenute private al processo che le ha effettuate. Deve essere specificato
952 come maschera binaria ottenuta dall'OR di uno o più dei valori riportati in
953 \tabref{tab:file_mmap_flag}.
958 \begin{tabular}[c]{|l|p{10cm}|}
960 \textbf{Valore} & \textbf{Significato} \\
963 \macro{MAP\_FIXED} & Non permette di restituire un indirizzo diverso
964 da \param{start}, se questo non può essere usato
965 \func{mmap} fallisce. Se si imposta questo flag il
966 valore di \param{start} deve essere allineato
967 alle dimensioni di una pagina. \\
968 \macro{MAP\_SHARED} & I cambiamenti sulla memoria mappata vengono
969 riportati sul file e saranno immediatamente
970 visibili agli altri processi che mappano lo stesso
971 file.\footnotemark Il file su disco però non sarà
972 aggiornato fino alla chiamata di \func{msync} o
973 \func{unmap}), e solo allora le modifiche saranno
974 visibili per l'I/O convenzionale. Incompatibile
975 con \macro{MAP\_PRIVATE}. \\
976 \macro{MAP\_PRIVATE} & I cambiamenti sulla memoria mappata non vengono
977 riportati sul file. Ne viene fatta una copia
978 privata cui solo il processo chiamante ha
979 accesso. Le modifiche sono mantenute attraverso
981 \textit{copy on write}\index{copy on write} e
982 salvate su swap in caso di necessità. Non è
983 specificato se i cambiamenti sul file originale
984 vengano riportati sulla regione
985 mappata. Incompatibile con \macro{MAP\_SHARED}. \\
986 \macro{MAP\_DENYWRITE} & In Linux viene ignorato per evitare
987 \textit{DoS}\index{DoS} (veniva usato per
988 segnalare che tentativi di scrittura sul file
989 dovevano fallire con \macro{ETXTBUSY}).\\
990 \macro{MAP\_EXECUTABLE}& Ignorato. \\
991 \macro{MAP\_NORESERVE} & Si usa con \macro{MAP\_PRIVATE}. Non riserva
992 delle pagine di swap ad uso del meccanismo di
993 \textit{copy on write}\index{copy on write}
995 modifiche fatte alla regione mappata, in
996 questo caso dopo una scrittura, se non c'è più
997 memoria disponibile, si ha l'emissione di
998 un \macro{SIGSEGV}. \\
999 \macro{MAP\_LOCKED} & Se impostato impedisce lo swapping delle pagine
1001 \macro{MAP\_GROWSDOWN} & Usato per gli stack. Indica
1002 che la mappatura deve essere effettuata con gli
1003 indirizzi crecenti verso il basso.\\
1004 \macro{MAP\_ANONYMOUS} & La mappatura non è associata a nessun file. Gli
1005 argomenti \param{fd} e \param{offset} sono
1006 ignorati.\footnotemark\\
1007 \macro{MAP\_ANON} & Sinonimo di \macro{MAP\_ANONYMOUS}, deprecato.\\
1008 \macro{MAP\_FILE} & Valore di compatibilità, deprecato.\\
1011 \caption{Valori possibili dell'argomento \param{flag} di \func{mmap}.}
1012 \label{tab:file_mmap_flag}
1015 \footnotetext{Dato che tutti faranno riferimento alle stesse pagine di
1017 \footnotetext{L'uso di questo flag con \macro{MAP\_SHARED} è
1018 stato implementato in Linux a partire dai kernel della serie 2.4.x.}
1020 Gli effetti dell'accesso ad una zona di memoria mappata su file possono essere
1021 piuttosto complessi, essi si possono comprendere solo tenendo presente che
1022 tutto quanto è comunque basato sul basato sul meccanismo della memoria
1023 virtuale. Questo comporta allora una serie di conseguenze. La più ovvia è che
1024 se si cerca di scrivere su una zona mappata in sola lettura si avrà
1025 l'emissione di un segnale di violazione di accesso (\macro{SIGSEGV}), dato che
1026 i permessi sul segmento di memoria relativo non consentono questo tipo di
1029 È invece assai diversa la questione relativa agli accessi al di fuori della
1030 regione di cui si è richiesta la mappatura. A prima vista infatti si potrebbe
1031 ritenere che anch'essi debbano generare un segnale di violazione di accesso;
1032 questo però non tiene conto del fatto che, essendo basata sul meccanismo della
1033 paginazione, la mappatura in memoria non può che essere eseguita su un
1034 segmento di dimensioni rigorosamente multiple di quelle di una pagina, ed in
1035 generale queste potranno non corrispondere alle dimensioni effettive del file
1036 o della sezione che si vuole mappare. Il caso più comune è quello illustrato
1037 in \figref{fig:file_mmap_boundary}, in cui la sezione di file non rientra nei
1038 confini di una pagina: in tal caso verrà il file sarà mappato su un segmento
1039 di memoria che si estende fino al bordo della pagina successiva.
1043 \includegraphics[width=10cm]{img/mmap_boundary}
1044 \caption{Schema della mappatura in memoria di una sezione di file di
1045 dimensioni non corrispondenti al bordo di una pagina.}
1046 \label{fig:file_mmap_boundary}
1050 In questo caso è possibile accedere a quella zona di memoria che eccede le
1051 dimensioni specificate da \param{lenght}, senza ottenere un \macro{SIGSEGV}
1052 poiché essa è presente nello spazio di indirizzi del processo, anche se non è
1053 mappata sul file. Il comportamento del sistema è quello di restituire un
1054 valore nullo per quanto viene letto, e di non riportare su file quanto viene
1057 Un caso più complesso è quello che si viene a creare quando le dimensioni del
1058 file mappato sono più corte delle dimensioni della mappatura, oppure quando il
1059 file è stato troncato, dopo che è stato mappato, ad una dimensione inferiore a
1060 quella della mappatura in memoria.
1064 \includegraphics[width=13cm]{img/mmap_exceed}
1065 \caption{Schema della mappatura in memoria di file di dimensioni inferiori
1066 alla lunghezza richiesta.}
1067 \label{fig:file_mmap_exceed}
1070 In questa situazione, per la sezione di pagina parzialmente coperta dal
1071 contenuto del file, vale esattamente quanto visto in precedenza; invece per la
1072 parte che eccede, fino alle dimensioni date da \param{length}, l'accesso non
1073 sarà più possibile, ma il segnale emesso non sarà \macro{SIGSEGV}, ma
1074 \macro{SIGBUS}, come illustrato in \figref{fig:file_mmap_exceed}.
1076 Non tutti i file possono venire mappati in memoria, dato che, come illustrato
1077 in \figref{fig:file_mmap_layout}, la mappatura introduce una corrispondenza
1078 biunivoca fra una sezione di un file ed una sezione di memoria. Questo
1079 comporta che ad esempio non è possibile mappare in memoria file descriptor
1080 relativi a pipe, socket e fifo, per i quali non ha senso parlare di
1081 \textsl{sezione}. Lo stesso vale anche per alcuni file di dispositivo, che non
1082 dispongono della relativa operazione \var{mmap} (si ricordi quanto esposto in
1083 \secref{sec:file_vfs_work}). Si tenga presente però che esistono anche casi di
1084 dispositivi (un esempio è l'interfaccia al ponte PCI-VME del chip Universe)
1085 che sono utilizzabili solo con questa interfaccia.
1087 Dato che passando attraverso una \func{fork} lo spazio di indirizzi viene
1088 copiato integralmente, i file mappati in memoria verranno ereditati in maniera
1089 trasparente dal processo figlio, mantenendo gli stessi attributi avuti nel
1090 padre; così se si è usato \macro{MAP\_SHARED} padre e figlio accederanno allo
1091 stesso file in maniera condivisa, mentre se si è usato \macro{MAP\_PRIVATE}
1092 ciascuno di essi manterrà una sua versione privata indipendente. Non c'è
1093 invece nessun passaggio attraverso una \func{exec}, dato che quest'ultima
1094 sostituisce tutto lo spazio degli indirizzi di un processo con quello di un
1097 Quando si effettua la mappatura di un file vengono pure modificati i tempi ad
1098 esso associati (di cui si è trattato in \secref{sec:file_file_times}). Il
1099 valore di \var{st\_atime} può venir cambiato in qualunque istante a partire
1100 dal momento in cui la mappatura è stata effettuata: il primo riferimento ad
1101 una pagina mappata su un file aggiorna questo tempo. I valori di
1102 \var{st\_ctime} e \var{st\_mtime} possono venir cambiati solo quando si è
1103 consentita la scrittura sul file (cioè per un file mappato con
1104 \macro{PROT\_WRITE} e \macro{MAP\_SHARED}) e sono aggiornati dopo la scrittura
1105 o in corrispondenza di una eventuale \func{msync}.
1107 Dato per i file mappati in memoria le operazioni di I/O sono gestite
1108 direttamente dalla memoria virtuale, occorre essere consapevoli delle
1109 interazioni che possono esserci con operazioni effettuate con l'interfaccia
1110 standard dei file di \capref{cha:file_unix_interface}. Il problema è che una
1111 volta che si è mappato un file, le operazioni di lettura e scrittura saranno
1112 eseguite sulla memoria, e riportate su disco in maniera autonoma dal sistema
1113 della memoria virtuale.
1115 Pertanto se si modifica un file con l'interfaccia standard queste modifiche
1116 potranno essere visibili o meno a seconda del momento in cui la memoria
1117 virtuale trasporterà dal disco in memoria quella sezione del file, perciò è
1118 del tutto imprevedibile il risultato della modifica di un file nei confronti
1119 del contenuto della memoria mappata su cui è mappato.
1121 Per quanto appena visto, è sempre sconsigliabile eseguire scritture su file
1122 attraverso l'interfaccia standard, quando lo si è mappato in memoria, è invece
1123 possibile usare l'interfaccia standard per leggere un file mappato in memoria,
1124 purché si abbia una certa cura; infatti l'interfaccia dell'I/O mappato in
1125 memoria mette a disposizione la funzione \func{msync} per sincronizzare il
1126 contenuto della memoria mappata con il file su disco; il suo prototipo è:
1129 \headdecl{sys/mman.h}
1131 \funcdecl{int msync(const void *start, size\_t length, int flags)}
1133 Sincronizza i contenuti di una sezione di un file mappato in memoria.
1135 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
1136 errore nel qual caso \var{errno} assumerà uno dei valori:
1138 \item[\macro{EINVAL}] O \param{start} non è multiplo di \macro{PAGESIZE},
1139 o si è specificato un valore non valido per \param{flags}.
1140 \item[\macro{EFAULT}] L'intervallo specificato non ricade in una zona
1141 precedentemente mappata.
1146 La funzione esegue la sincronizzazione di quanto scritto nella sezione di
1147 memoria indicata da \param{start} e \param{offset}, scrivendo le modifiche sul
1148 file (qualora questo non sia già stato fatto). Provvede anche ad aggiornare i
1149 relativi tempi di modifica. In questo modo si è sicuri che dopo l'esecuzione
1150 di \func{msync} le funzioni dell'interfaccia standard troveranno un contenuto
1151 del file aggiornato.
1156 \begin{tabular}[c]{|l|l|}
1158 \textbf{Valore} & \textbf{Significato} \\
1161 \macro{MS\_ASYNC} & Richiede la sincronizzazione.\\
1162 \macro{MS\_SYNC} & Attende che la sincronizzazione si eseguita.\\
1163 \macro{MS\_INVALIDATE}& Richiede che le altre mappature dello stesso file
1167 \caption{Valori dell'argomento \param{flag} di \func{msync}.}
1168 \label{tab:file_mmap_rsync}
1171 L'argomento \param{flag} è specificato come maschera binaria composta da un OR
1172 dei valori riportati in \tabref{tab:file_mmap_rsync}, di questi però
1173 \macro{MS\_ASYNC} e \macro{MS\_SYNC} sono incompatibili; con il primo valore
1174 infatti la funzione si limita ad inoltrare la richiesta di sincronizzazione al
1175 meccanismo della memoria virtuale, ritornando subito, mentre con il secondo
1176 attende che la sincronizzazione sia stata effettivamente eseguita. Il terzo
1177 flag fa invalidare le pagine di cui si richiede la sincronizzazione per tutte
1178 le mappature dello stesso file, così che esse possano essere immediatamente
1179 aggiornate ai nuovi valori.
1181 Una volta che si sono completate le operazioni di I/O si può eliminare la
1182 mappatura della memoria usando la funzione \func{munmap}, il suo prototipo è:
1185 \headdecl{sys/mman.h}
1187 \funcdecl{int munmap(void *start, size\_t length)}
1189 Rilascia la mappatura sulla sezione di memoria specificata.
1191 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
1192 errore nel qual caso \var{errno} assumerà uno dei valori:
1194 \item[\macro{EINVAL}] L'intervallo specificato non ricade in una zona
1195 precedentemente mappata.
1200 La funzione cancella la mappatura per l'intervallo specificato attraverso
1201 \param{start} e \param{length}, ed ogni successivo accesso a tale regione
1202 causerà un errore di accesso in memoria. L'argomento \param{start} deve essere
1203 allineato alle dimensioni di una pagina di memoria, e la mappatura di tutte le
1204 pagine contenute (anche parzialmente) nell'intervallo indicato, verrà rimossa.
1205 Indicare un intervallo che non contiene pagine mappate non è un errore.
1207 Alla conclusione del processo, ogni pagina mappata verrà automaticamente
1208 rilasciata, mentre la chiusura del file descriptor usato per effettuare la
1209 mappatura in memoria non ha alcun effetto sulla stessa.
1212 \section{Il file locking}
1213 \label{sec:file_locking}
1215 In \secref{sec:file_sharing} abbiamo preso in esame le modalità in cui un
1216 sistema unix-like gestisce la condivisione dei file da parte di processi
1217 diversi. In quell'occasione si è visto come, con l'eccezione dei file aperti
1218 in \textit{append mode}, quando più processi scrivono contemporaneamente sullo
1219 stesso file non è possibile determinare la sequenza in cui essi opereranno.
1221 Questo causa la possibilità di race condition\index{race condition}; in
1222 generale le situazioni più comuni sono due: l'interazione fra un processo che
1223 scrive e altri che leggono, in cui questi ultimi possono leggere informazioni
1224 scritte solo in maniera parziale o incompleta; o quella in cui diversi
1225 processi scrivono, mescolando in maniera imprevedibile il loro output sul
1228 In tutti questi casi il \textit{file locking} è la tecnica che permette di
1229 evitare le race condition, attraverso una serie di funzioni che permettono di
1230 bloccare l'accesso al file da parte di altri processi, così da evitare le
1231 sovrapposizioni, e garantire la atomicità delle operazioni di scrittura.
1235 \subsection{L'\textit{advisory locking}}
1236 \label{sec:file_record_locking}
1238 La prima modalità di file locking che è stata implementata nei sistemi
1239 unix-like è quella che viene usualmente chiamata \textit{advisory
1240 locking},\footnote{Stevens in \cite{APUE} fa riferimento a questo argomento
1241 come al \textit{record locking}, dizione utilizzata anche dal manuale delle
1242 \acr{glibc}; nelle pagine di manuale si parla di \textit{discretionary file
1243 lock} per \func{fcntl} e di \textit{advisory locking} per \func{flock},
1244 mentre questo nome viene usato anche da Stevens per riferirsi al
1245 \textit{file locking} di POSIX. Dato che la dizione \textit{record locking}
1246 è quantomeno ambigua in quanto non esiste niente che possa fare riferimento
1247 al concetto di \textit{record}, alla fine si è scelto di mantenere il nome
1248 \textit{advisory locking}.} in quanto sono i singoli processi, e non il
1249 sistema, che si incaricano di asserire e verificare se esistono delle
1250 condizioni di blocco per l'accesso ai file. Questo significa che le funzioni
1251 \func{read} o \func{write} non risentono affatto della presenza di un
1252 eventuale blocco, e che sta ai vari processi controllare esplicitamente lo
1253 stato dei file condivisi prima di accedervi, implementando un opportuno
1256 In generale si distinguono due tipologie di blocco per un file: la prima è il
1257 cosiddetto \textit{shared lock}, detto anche \textit{read lock} in quanto
1258 serve a bloccare l'accesso in scrittura su un file affinché non venga
1259 modificato mentre lo si legge. Si parla di \textsl{blocco condiviso} in quanto
1260 più processi possono richiedere contemporaneamente uno \textit{shared lock}
1261 su un file per proteggere il loro accesso in lettura.
1263 La seconda tipologia è il cosiddetto \textit{exclusive lock}, detto anche
1264 \textit{write lock} in quanto serve a bloccare l'accesso su un file (sia in
1265 lettura che in scrittura) da parte di altri processi mentre lo si sta
1266 scrivendo. Si parla di \textsl{blocco esclusivo} appunto perché un solo
1267 processo alla volta può richiedere un \textit{exclusive lock} su un file per
1268 proteggere il suo accesso in scrittura.
1270 In Linux sono disponibili due interfacce per utilizzare l'\textit{advisory
1271 locking}, la prima è quella derivata da BSD, che è basata sulla funzione
1272 \func{flock}, la seconda è quella standardizzata da POSIX.1 (derivata da
1273 System V), che è basata sulla funzione \func{fcntl}. I \textit{file lock}
1274 sono implementati in maniera completamente indipendente nelle due interfacce,
1275 che pertanto possono coesistere senza interferenze.
1277 Entrambe le interfacce prevedono la stessa procedura di funzionamento: si
1278 inizia sempre con il richiedere l'opportuno \textit{file lock} (un
1279 \textit{exclusive lock} per una scrittura, uno \textit{shared lock} per una
1280 lettura) prima di eseguire l'accesso ad un file. Se il lock viene acquisito
1281 il processo prosegue l'esecuzione, altrimenti (a meno di non aver richiesto un
1282 comportamento non bloccante) viene posto in stato di sleep. Una volta finite
1283 le operazioni sul file si deve provvedere a rimuovere il lock. Si ricordi che
1284 la condizione per acquisire uno \textit{shared lock} è che il file non abbia
1285 già un \textit{exclusive lock} attivo, mentre per acquisire un
1286 \textit{exclusive lock} non deve essere presente nessun tipo di blocco.
1289 \subsection{La funzione \func{flock}}
1290 \label{sec:file_flock}
1292 La prima interfaccia per il file locking, quella derivata da BSD, permette di
1293 eseguire un blocco solo su un intero file; la funzione usata per richiedere e
1294 rimuovere un \textit{file lock} è \func{flock}, ed il suo prototipo è:
1295 \begin{prototype}{sys/file.h}{int flock(int fd, int operation)}
1297 Applica o rimuove un \textit{file lock} sul file \param{fd}.
1299 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
1300 errore, nel qual caso \var{errno} assumerà uno dei valori:
1302 \item[\macro{EWOULDBLOCK}] Il file ha già un blocco attivo, e si è
1303 specificato \macro{LOCK\_NB}.
1308 La funzione può essere usata per acquisire o rilasciare un blocco a seconda di
1309 quanto specificato tramite il valore dell'argomento \param{operation}, questo
1310 viene interpretato come maschera binaria, e deve essere passato utilizzando le
1311 costanti riportate in \tabref{tab:file_flock_operation}.
1316 \begin{tabular}[c]{|l|l|}
1318 \textbf{Valore} & \textbf{Significato} \\
1321 \macro{LOCK\_SH} & Asserisce uno \textit{shared lock} sul file.\\
1322 \macro{LOCK\_EX} & Asserisce un \textit{esclusive lock} sul file.\\
1323 \macro{LOCK\_UN} & Sblocca il file.\\
1324 \macro{LOCK\_NB} & Impedisce che la funzione si blocchi nella
1325 richiesta di un \textit{file lock}.\\
1328 \caption{Valori dell'argomento \param{operation} di \func{flock}.}
1329 \label{tab:file_flock_operation}
1332 I primi due valori, \macro{LOCK\_SH} e \macro{LOCK\_EX} permettono di
1333 richiedere un \textit{file lock}, ed ovviamente devono essere usati in maniera
1334 alternativa. Se si specifica anche \macro{LOCK\_NB} la funzione non si
1335 bloccherà qualora il lock non possa essere acquisito, ma ritornerà subito con
1336 un errore di \macro{EWOULDBLOCK}. Per rilasciare un lock si dovrà invece usare
1339 La semantica del file locking di BSD è diversa da quella del file locking
1340 POSIX, in particolare per quanto riguarda il comportamento dei lock nei
1341 confronti delle due funzioni \func{dup} e \func{fork}. Per capire queste
1342 differenze occorre prima descrivere con maggiore dettaglio come viene
1343 realizzato il file locking nel kernel.
1345 In \figref{fig:file_flock_struct} si è riportato uno schema essenziale
1346 dell'implementazione del file locking in Linux; il punto fondamentale da
1347 capire è che un lock, qualunque sia l'interfaccia che si usa, anche se
1348 richiesto attraverso un file descriptor, agisce sempre su un file; perciò le
1349 informazioni relative agli eventuali \textit{file lock} sono mantenute a
1350 livello di inode,\footnote{in particolare, come accennato in
1351 \figref{fig:file_flock_struct}, i \textit{file lock} sono mantenuti un una
1352 \textit{linked list}\index{linked list} di strutture \var{file\_lock}. La
1353 lista è referenziata dall'indirizzo di partenza mantenuto dal campo
1354 \var{i\_flock} della struttura \var{inode} (per le definizioni esatte si
1355 faccia riferimento al file \file{fs.h} nei sorgenti del kernel). Un bit del
1356 campo \var{fl\_flags} di specifica se si tratta di un lock in semantica BSD
1357 (\macro{FL\_FLOCK}) o POSIX (\macro{FL\_POSIX}).} dato che questo è l'unico
1358 riferimento in comune che possono avere due processi diversi che aprono lo
1363 \includegraphics[width=13cm]{img/file_flock}
1364 \caption{Schema dell'architettura del file locking, nel caso particolare
1365 del suo utilizzo da parte dalla funzione \func{flock}.}
1366 \label{fig:file_flock_struct}
1369 La richiesta di un file lock prevede una scansione della lista per determinare
1370 se l'acquisizione è possibile, ed in caso positivo l'aggiunta di un nuovo
1371 elemento.\footnote{cioè una nuova struttura \var{file\_lock}.} Nel caso dei
1372 lock creati con \func{flock} la semantica della funzione prevede che sia
1373 \func{dup} che \func{fork} non creino ulteriori istanze di un \textit{file
1374 lock} quanto piuttosto degli ulteriori riferimenti allo stesso. Questo viene
1375 realizzato dal kernel associando ad ogni nuovo \textit{file lock} un
1376 puntatore\footnote{il puntatore è mantenuto nel campo \var{fl\_file} di
1377 \var{file\_lock}, e viene utilizzato solo per i lock creati con la semantica
1378 BSD.} alla voce nella \textit{file table} da cui si è richiesto il blocco,
1379 che così ne identifica il titolare.
1381 Questa struttura comporta che, quando si richiede la rimozione di un file
1382 lock, il kernel acconsenta solo se la richiesta proviene da un file descriptor
1383 che fa riferimento ad una voce nella file table corrispondente a quella
1384 registrata nel blocco. Allora se ricordiamo quanto visto in
1385 \secref{sec:file_dup} e \secref{sec:file_sharing}, e cioè che i file
1386 descriptor duplicati e quelli ereditati in un processo figlio puntano sempre
1387 alla stessa voce nella file table, si può capire immediatamente quali sono le
1388 conseguenze nei confronti delle funzioni \func{dup} e \func{fork}.
1390 Sarà cioè possibile rimuovere un file lock attraverso uno qualunque dei file
1391 descriptor che fanno riferimento alla stessa voce nella file table, quindi
1392 anche se questo è diverso da quello con cui lo si è
1393 creato,\footnote{attenzione, questo non vale se il file descriptor fa
1394 riferimento allo stesso file, ma attraverso una voce diversa della file
1395 table, come accade tutte le volte che si apre più volte lo stesso file.} o
1396 se si esegue la rimozione in un processo figlio; inoltre una volta tolto un
1397 file lock, la rimozione avrà effetto su tutti i file descriptor che
1398 condividono la stessa voce nella file table, e quindi, nel caso di file
1399 descriptor ereditati attraverso una \func{fork}, anche su processi diversi.
1401 Infine, per evitare che la terminazione imprevista di un processo lasci attivi
1402 dei file lock, quando un file viene chiuso il kernel provveda anche a
1403 rimuovere tutti i lock ad esso associati. Anche in questo caso occorre tenere
1404 presente cosa succede quando si hanno file descriptor duplicati; in tal caso
1405 infatti il file non verrà effettivamente chiuso (ed il lock rimosso) fintanto
1406 che non viene rilasciata la relativa voce nella file table; la rimozione cioè
1407 avverrà solo quando tutti i file descriptor che fanno riferimento alla stessa
1408 voce sono stati chiusi, quindi, nel caso ci siano processi figli che
1409 mantengono ancora aperto un file descriptor, il lock non sarà rilasciato.
1411 Si tenga presente che \func{flock} non è in grado di funzionare per i file
1412 mantenuti su NFS, in questo caso, se si ha la necessità di eseguire il
1413 \textit{file locking}, occorre usare l'interfaccia basata su \func{fcntl} che
1414 può funzionare anche attraverso NFS, a condizione che sia il client che il
1415 server supportino questa funzionalità.
1418 \subsection{Il file locking POSIX}
1419 \label{sec:file_posix_lock}
1421 La seconda interfaccia per l'\textit{advisory locking} disponibile in Linux è
1422 quella standardizzata da POSIX, basata sulla funzione \func{fcntl}. Abbiamo
1423 già trattato questa funzione nelle sue molteplici funzionalità in
1424 \secref{sec:file_fcntl}; quando la si impiega per il \textit{file locking}
1425 però essa viene usata solo secondo il prototipo:
1426 \begin{prototype}{fcntl.h}{int fcntl(int fd, int cmd, struct flock *lock)}
1428 Applica o rimuove un \textit{file lock} sul file \param{fd}.
1430 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
1431 errore, nel qual caso \var{errno} assumerà uno dei valori:
1433 \item[\macro{EACCES}] L'operazione è proibita per la presenza di
1434 \textit{file lock} da parte di altri processi.
1435 \item[\macro{ENOLCK}] Il sistema non ha le risorse per il locking: ci sono
1436 troppi segmenti di lock aperti, si è esaurita la tabella dei lock, o il
1437 protocollo per il locking remoto è fallito.
1438 \item[\macro{EDEADLK}] Si è richiesto un lock su una regione bloccata da
1439 un altro processo che è a sua volta in attesa dello sblocco di un lock
1440 mantenuto dal processo corrente; si avrebbe pertanto un
1441 \textit{deadlock}. Non è garantito che il sistema riconosca sempre
1443 \item[\macro{EINTR}] La funzione è stata interrotta da un segnale prima di
1444 poter acquisire un lock.
1446 ed inoltre \macro{EBADF}, \macro{EFAULT}.
1450 Al contrario di quanto avviene con l'interfaccia basata su \func{flock} con
1451 \func{fcntl} è possibile bloccare anche delle singole sezioni di un file;
1452 inoltre la funzione permette di leggere le informazioni relative ai blocchi
1453 esistenti. Per poter fare tutto questo la funzione utilizza come terzo
1454 argomento una apposita struttura \var{flock} (la cui definizione è riportata
1455 in \figref{fig:struct_flock}) che contiene tutte le specifiche di un dato file
1458 \begin{figure}[!htb]
1459 \footnotesize \centering
1460 \begin{minipage}[c]{15cm}
1461 \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
1463 short int l_type; /* Type of lock: F_RDLCK, F_WRLCK, or F_UNLCK. */
1464 short int l_whence; /* Where `l_start' is relative to (like `lseek'). */
1465 off_t l_start; /* Offset where the lock begins. */
1466 off_t l_len; /* Size of the locked area; zero means until EOF. */
1467 pid_t l_pid; /* Process holding the lock. */
1472 \caption{La struttura \type{flock}, usata da \func{fcntl} per il file
1474 \label{fig:struct_flock}
1477 L'operazione effettivamente svolta dalla funzione è stabilita dal valore
1478 dall'argomento \param{cmd} che, come già riportato in \secref{sec:file_fcntl},
1479 specifica l'azione da compiere; i valori relativi al file locking sono tre:
1480 \begin{basedescript}{\desclabelwidth{2.0cm}}
1481 \item[\macro{F\_GETLK}] verifica se il file lock specificato dalla struttura
1482 puntata da \param{lock} non è bloccato da qualche altro lock: in caso
1483 affermativo sovrascrive la struttura con i valori relativi a quest'ultimo,
1484 altrimenti si limita a impostarne il campo \var{l\_type} con
1486 \item[\macro{F\_SETLK}] se il campo \var{l\_type} della struttura puntata da
1487 \param{lock} è \macro{F\_RDLCK} o \macro{F\_WRLCK} richiede il
1488 corrispondente file lock, se è \macro{F\_UNLCK} lo rilascia. Nel caso la
1489 richiesta non possa essere soddisfatta a causa di un lock preesistente la
1490 funzione ritorna immediatamente con un errore di \macro{EACCES} o di
1492 \item[\macro{F\_SETLKW}] è identica a \macro{F\_SETLK}, ma se la richiesta di
1493 un lock non può essere soddisfatta per la presenza di un altro blocco, mette
1494 il processo in stato di attesa fintanto che il lock precedente non viene
1495 rilasciato. Se l'attesa viene interrotta da un segnale la funzione ritorna
1496 con un errore di \macro{EINTR}.
1499 Come accennato nell'interfaccia POSIX ogni file lock viene associato ad una
1500 struttura \func{flock}; i tre campi \var{l\_whence}, \var{l\_start} e
1501 \var{l\_len}, servono a specificare la sezione del file a cui fa riferimento
1502 il lock, \var{l\_start} specifica il byte di partenza, e \var{l\_len} la
1503 lunghezza della sezione; \var{l\_whence} infine imposta il riferimento da cui
1504 contare \var{l\_start} e segue la stessa semantica dell'omonimo argomento di
1505 \func{lseek}, coi tre possibili valori \macro{SEEK\_SET}, \macro{SEEK\_CUR} e
1506 \macro{SEEK\_END} (si vedano le relative descrizioni in
1507 \secref{sec:file_lseek}).
1509 Si tenga presente che un lock può essere richiesto anche per una regione al di
1510 là della corrente fine del file, così che una eventuale estensione dello
1511 stesso resti coperta dal blocco. Se si specifica un valore nullo per
1512 \var{l\_len} il blocco si considera esteso fino alla dimensione massima del
1513 file; in questo modo è possibile bloccare una qualunque regione a partire da
1514 un certo punto fino alla fine del file, coprendo automaticamente quanto
1515 eventualmente aggiunto in coda allo stesso.
1520 \begin{tabular}[c]{|l|l|}
1522 \textbf{Valore} & \textbf{Significato} \\
1525 \macro{F\_RDLCK} & Richiede un blocco condiviso (\textit{read lock}).\\
1526 \macro{F\_WRLCK} & Richiede un blocco esclusivo (\textit{write lock}).\\
1527 \macro{F\_UNLCK} & Richiede l'eliminazione di un lock.\\
1530 \caption{Valori possibili per il campo \var{l\_type} di \func{flock}.}
1531 \label{tab:file_flock_type}
1534 Il tipo di file lock richiesto viene specificato dal campo \var{l\_type}, esso
1535 può assumere i tre valori riportati in \tabref{tab:file_flock_type}, che
1536 permettono di richiedere rispettivamente uno \textit{shared lock}, un
1537 \textit{esclusive lock}, e la rimozione di un lock precedentemente acquisito.
1541 \includegraphics[width=13cm]{img/file_posix_lock}
1542 \caption{Schema dell'architettura del file locking, nel caso particolare
1543 del suo utilizzo secondo l'interfaccia standard POSIX.}
1544 \label{fig:file_posix_lock}
1547 Infine il campo \var{l\_pid} riporta (viene usato solo in lettura, quando si
1548 chiama \func{fcntl} con \macro{F\_GETLK}) qual'è il processo cui appartiene il
1549 file lock. Nella semantica POSIX infatti il comportamento dei lock è diverso
1550 rispetto a quanto visto in precedenza per \func{flock}. Lo schema della
1551 struttura usata in questo caso è riportato in \figref{fig:file_posix_lock};
1552 come si vede essa è molto simile a quanto visto in
1553 \figref{fig:file_flock_struct} per \func{flock}:\footnote{in questo caso si
1554 sono evidenziati nella figura i campi di \var{file\_lock} significativi per
1555 la semantica POSIX, in particolare adesso ciascun lock contiene, oltre al
1556 \acr{pid} del processo in \var{fl\_pid}, la sezione di file che viene
1557 bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}. La struttura è
1558 comunque la stessa, solo che in questo caso nel campo \var{fl\_flags} è
1559 impostato il bit \macro{FL\_POSIX} ed il campo \var{fl\_file} non viene
1560 usato.} il lock è sempre associato all'inode, solo che in questo caso la
1561 titolarità non viene identificata con il riferimento ad una voce nella file
1562 table, ma con il valore del \acr{pid} del processo.
1564 Tutto ciò significa che la rimozione di un blocco viene effettuata
1565 controllando che il \acr{pid} del processo richiedente corrisponda a quello
1566 contenuto nel lock. Questa diversa modalità ha delle conseguenze precise
1567 riguardo il comportamento dei lock POSIX. La prima conseguenza è che un lock
1568 POSIX non viene mai ereditato attraverso una \func{fork}, dato che il processo
1569 figlio avrà un \acr{pid} diverso, mentre passa indenne attraverso una
1570 \func{exec} in quanto il \acr{pid} resta lo stesso. Questo comporta che, al
1571 contrario di quanto avveniva con la semantica BSD, quando processo termina
1572 tutti i file lock da esso detenuti vengono immediatamente rilasciati.
1574 La seconda conseguenza è che qualunque file descriptor che faccia riferimento
1575 allo stesso file (che sia stato ottenuto con una \func{dup} o con una
1576 \func{open} non fa differenza) può essere usato per rimuovere un lock, dato
1577 che quello che conta è solo il \acr{pid} del processo. Da questo deriva una
1578 ulteriore sottile differenza di comportamento: dato che alla chiusura di un
1579 file i lock ad esso associati vengono rimossi, nella semantica POSIX basterà
1580 chiudere un file descriptor per cancellare tutti i lock relativi al file cui
1581 esso faceva riferimento, anche se questi fossero stati creati usando altri
1582 file descriptor che restano aperti.
1584 Abbiamo visto come l'interfaccia POSIX per il file locking sia molto più
1585 potente e flessibile di quella di BSD, ma è anche molto più complicata da
1586 usare. Per questo motivo è disponibile anche una interfaccia semplificata
1587 (ripresa da System V) che utilizza la funzione \func{lockf}, il cui prototipo
1589 \begin{prototype}{sys/file.h}{int lockf(int fd, int cmd, off\_t len)}
1591 Applica, controlla o rimuove un \textit{file lock} sul file \param{fd}.
1593 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
1594 errore, nel qual caso \var{errno} assumerà uno dei valori:
1596 \item[\macro{EAGAIN}] Non è possibile acquisire il lock, e si è
1597 selezionato \macro{LOCK\_NB}, oppure l'operazione è proibita perché il
1598 file è mappato in memoria.
1599 \item[\macro{ENOLCK}] Il sistema non ha le risorse per il locking: ci sono
1600 troppi segmenti di lock aperti, si è esaurita la tabella dei lock.
1601 \item[\macro{EDEADLK}] Si è riconosciuta una situazione di
1604 ed inoltre \macro{EBADF}, \macro{EINVAL}.
1608 Il comportamento della funzione dipende dal valore dell'argomento \param{cmd}
1609 che specifica quale azione eseguire; i valori possibili sono riportati in
1613 \begin{tabular}[c]{|l|l|}
1615 \textbf{Valore} & \textbf{Significato} \\
1618 \macro{F\_LOCK} & Richiede un \textit{exclusive lock}. Se non può essere
1619 ottenuto a causa di un lock preesistente la funzione
1620 blocca il processo chiamante fino al rilascio di
1622 \macro{F\_TLOCK}& Stesso comportamento di \macro{F\_LOCK} ma la funzione
1623 ritorna sempre subito, segnalando un errore quando il
1624 lock non può essere acquisito. \\
1625 \macro{F\_ULOCK}& Sblocca il file.\\
1626 \macro{F\_TEST} & Controlla il lock, la funzione restituisce 0 se il file
1627 non ha lock, o i lock appartengono al processo corrente,
1628 e -1, con un errore di \macro{EACCES}, se altri processi
1629 detengono un lock sul file.\\
1632 \caption{Valori possibili per il campo \var{cmd} di \func{lockf}.}
1633 \label{tab:file_lockf_type}
1639 \subsection{Il \textit{mandatory locking}}
1640 \label{sec:file_mand_locking}
1642 Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4,
1643 per introdurre un file locking che come dice il nome, fosse effettivo
1644 indipendentemente dai controlli eseguiti da un processo. Con il
1645 \textit{mandatory locking} infatti è possibile far eseguire il blocco del file
1646 direttamente al sistema, così che anche qualora non si predisponessero le
1647 opportune verifiche nei processi, questo verrebbe comunque rispettato.
1649 Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
1650 utilizzo particolare del bit \acr{suid}. Se si ricorda quanto esposto in
1651 \secref{sec:file_suid_sgid}), esso viene di norma utilizzato per cambiare
1652 l'userid effettivo con cui viene eseguito un programma, ed è pertanto sempre
1653 associato alla presenza del permesso di esecuzione. Impostando questo bit su
1654 un file senza permesso di esecuzione in un sistema che supporta il
1655 \textit{mandatory locking}, fa sì che quest'ultimo venga attivato per il file
1656 in questione. In questo modo una combinazione dei permessi originariamente non
1657 contemplata, in quanto senza significato, diventa l'indicazione della presenza
1658 o meno del \textit{mandatory locking}.
1662 %%% Local Variables:
1664 %%% TeX-master: "gapil"