3 %% Copyright (C) 2000-2004 Simone Piccardi. Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
11 \chapter{La gestione avanzata dei file}
12 \label{cha:file_advanced}
14 In questo capitolo affronteremo le tematiche relative alla gestione avanzata
15 dei file. In particolare tratteremo delle funzioni di input/output avanzato,
16 che permettono una gestione più sofisticata dell'I/O su file, a partire da
17 quelle che permettono di gestire l'accesso contemporaneo a più file, per
18 concludere con la gestione dell'I/O mappato in memoria. Dedicheremo poi la
19 fine del capitolo alle problematiche del \textit{file locking}.
22 \section{L'\textit{I/O multiplexing}}
23 \label{sec:file_multiplexing}
25 Uno dei problemi che si presentano quando si deve operare contemporaneamente
26 su molti file usando le funzioni illustrate in
27 cap.~\ref{cha:file_unix_interface} e cap.~\ref{cha:files_std_interface} è che
28 si può essere bloccati nelle operazioni su un file mentre un altro potrebbe
29 essere disponibile. L'\textit{I/O multiplexing} nasce risposta a questo
30 problema. In questa sezione forniremo una introduzione a questa problematica
31 ed analizzeremo le varie funzioni usate per implementare questa modalità di
35 \subsection{La problematica dell'\textit{I/O multiplexing}}
36 \label{sec:file_noblocking}
38 Abbiamo visto in sez.~\ref{sec:sig_gen_beha}, affrontando la suddivisione fra
39 \textit{fast} e \textit{slow} system call,\index{system call lente} che in
40 certi casi le funzioni di I/O possono bloccarsi indefinitamente.\footnote{si
41 ricordi però che questo può accadere solo per le pipe, i
42 socket\index{socket} ed alcuni file di dispositivo\index{file!di
43 dispositivo}; sui file normali le funzioni di lettura e scrittura
44 ritornano sempre subito.} Ad esempio le operazioni di lettura possono
45 bloccarsi quando non ci sono dati disponibili sul descrittore su cui si sta
48 Questo comportamento causa uno dei problemi più comuni che ci si trova ad
49 affrontare nelle operazioni di I/O, che si verifica quando si deve operare con
50 più file descriptor eseguendo funzioni che possono bloccarsi senza che sia
51 possibile prevedere quando questo può avvenire (il caso più classico è quello
52 di un server in attesa di dati in ingresso da vari client). Quello che può
53 accadere è di restare bloccati nell'eseguire una operazione su un file
54 descriptor che non è ``\textsl{pronto}'', quando ce ne potrebbe essere
55 un'altro disponibile. Questo comporta nel migliore dei casi una operazione
56 ritardata inutilmente nell'attesa del completamento di quella bloccata, mentre
57 nel peggiore dei casi (quando la conclusione della operazione bloccata dipende
58 da quanto si otterrebbe dal file descriptor ``\textsl{disponibile}'') si
59 potrebbe addirittura arrivare ad un \textit{deadlock}\index{deadlock}.
61 Abbiamo già accennato in sez.~\ref{sec:file_open} che è possibile prevenire
62 questo tipo di comportamento delle funzioni di I/O aprendo un file in
63 \textsl{modalità non-bloccante}, attraverso l'uso del flag \const{O\_NONBLOCK}
64 nella chiamata di \func{open}. In questo caso le funzioni di input/output
65 eseguite sul file che si sarebbero bloccate, ritornano immediatamente,
66 restituendo l'errore \errcode{EAGAIN}. L'utilizzo di questa modalità di I/O
67 permette di risolvere il problema controllando a turno i vari file descriptor,
68 in un ciclo in cui si ripete l'accesso fintanto che esso non viene garantito.
69 Ovviamente questa tecnica, detta \textit{polling}\index{polling}, è
70 estremamente inefficiente: si tiene costantemente impiegata la CPU solo per
71 eseguire in continuazione delle system call che nella gran parte dei casi
74 Per superare questo problema è stato introdotto il concetto di \textit{I/O
75 multiplexing}, una nuova modalità di operazioni che consenta di tenere sotto
76 controllo più file descriptor in contemporanea, permettendo di bloccare un
77 processo quando le operazioni volute non sono possibili, e di riprenderne
78 l'esecuzione una volta che almeno una di quelle richieste sia disponibile, in
79 modo da poterla eseguire con la sicurezza di non restare bloccati.
81 Dato che, come abbiamo già accennato, per i normali file su disco non si ha
82 mai un accesso bloccante, l'uso più comune delle funzioni che esamineremo nei
83 prossimi paragrafi è per i server di rete, in cui esse vengono utilizzate per
84 tenere sotto controllo dei socket; pertanto ritorneremo su di esse con
85 ulteriori dettagli e qualche esempio in sez.~\ref{sec:TCP_sock_multiplexing}.
88 \subsection{Le funzioni \func{select} e \func{pselect}}
89 \label{sec:file_select}
91 Il primo kernel unix-like ad introdurre una interfaccia per l'\textit{I/O
92 multiplexing} è stato BSD,\footnote{la funzione \func{select} è apparsa in
93 BSD4.2 e standardizzata in BSD4.4, ma è stata portata su tutti i sistemi che
94 supportano i \textit{socket}\index{socket}, compreso le varianti di System
95 V.} con la funzione \funcd{select}, il cui prototipo è:
98 \headdecl{sys/types.h}
100 \funcdecl{int select(int n, fd\_set *readfds, fd\_set *writefds, fd\_set
101 *exceptfds, struct timeval *timeout)}
103 Attende che uno dei file descriptor degli insiemi specificati diventi
106 \bodydesc{La funzione in caso di successo restituisce il numero di file
107 descriptor (anche nullo) che sono attivi, e -1 in caso di errore, nel qual
108 caso \var{errno} assumerà uno dei valori:
110 \item[\errcode{EBADF}] Si è specificato un file descriptor sbagliato in uno
112 \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
113 \item[\errcode{EINVAL}] Si è specificato per \param{n} un valore negativo o
114 un valore non valido per \param{timeout}.
116 ed inoltre \errval{ENOMEM}.
120 La funzione mette il processo in stato di \textit{sleep} (vedi
121 tab.~\ref{tab:proc_proc_states}) fintanto che almeno uno dei file descriptor
122 degli insiemi specificati (\param{readfds}, \param{writefds} e
123 \param{exceptfds}), non diventa attivo, per un tempo massimo specificato da
126 Per specificare quali file descriptor si intende \textsl{selezionare}, la
127 funzione usa un particolare oggetto, il \textit{file descriptor set},
128 identificato dal tipo \type{fd\_set}, che serve ad identificare un insieme di
129 file descriptor, in maniera analoga a come un
130 \index{\textit{signal set}}\textit{signal set} (vedi
131 sez.~\ref{sec:sig_sigset}) identifica un insieme di segnali. Per la
132 manipolazione di questi \textit{file descriptor set} si possono usare delle
133 opportune macro di preprocessore:
135 \headdecl{sys/time.h}
136 \headdecl{sys/types.h}
138 \funcdecl{FD\_ZERO(fd\_set *set)}
139 Inizializza l'insieme (vuoto).
141 \funcdecl{FD\_SET(int fd, fd\_set *set)}
142 Inserisce il file descriptor \param{fd} nell'insieme.
144 \funcdecl{FD\_CLR(int fd, fd\_set *set)}
145 Rimuove il file descriptor \param{fd} nell'insieme.
147 \funcdecl{FD\_ISSET(int fd, fd\_set *set)}
148 Controlla se il file descriptor \param{fd} è nell'insieme.
151 In genere un \textit{file descriptor set} può contenere fino ad un massimo di
152 \const{FD\_SETSIZE} file descriptor. Questo valore in origine corrispondeva
153 al limite per il numero massimo di file aperti\footnote{ad esempio in Linux,
154 fino alla serie 2.0.x, c'era un limite di 256 file per processo.}, ma da
155 quando, come nelle versioni più recenti del kernel, non c'è più un limite
156 massimo, esso indica le dimensioni massime dei numeri usati nei \textit{file
157 descriptor set}.\footnote{il suo valore, secondo lo standard POSIX
158 1003.1-2001, è definito in \file{sys/select.h}, ed è pari a 1024.} Si tenga
159 presente che i \textit{file descriptor set} devono sempre essere inizializzati
160 con \macro{FD\_ZERO}; passare a \func{select} un valore non inizializzato può
161 dar luogo a comportamenti non prevedibili.
163 La funzione richiede di specificare tre insiemi distinti di file descriptor;
164 il primo, \param{readfds}, verrà osservato per rilevare la disponibilità di
165 effettuare una lettura,\footnote{per essere precisi la funzione ritornerà in
166 tutti i casi in cui la successiva esecuzione di \func{read} risulti non
167 bloccante, quindi anche in caso di \textit{end-of-file}.} il secondo,
168 \param{writefds}, per verificare la possibilità effettuare una scrittura ed il
169 terzo, \param{exceptfds}, per verificare l'esistenza di eccezioni (come i
170 messaggi urgenti su un \textit{socket}\index{socket}, vedi
171 sez.~\ref{sec:TCP_urgent_data}).
173 Dato che in genere non si tengono mai sotto controllo fino a
174 \const{FD\_SETSIZE} file contemporaneamente la funzione richiede di
175 specificare qual'è il numero massimo dei file descriptor indicati nei tre
176 insiemi precedenti. Questo viene fatto per efficienza, per evitare di passare
177 e far controllare al kernel una quantità di memoria superiore a quella
178 necessaria. Questo limite viene indicato tramite l'argomento \param{n}, che
179 deve corrispondere al valore massimo aumentato di uno.\footnote{i file
180 descriptor infatti sono contati a partire da zero, ed il valore indica il
181 numero di quelli da tenere sotto controllo; dimenticarsi di aumentare di uno
182 il valore di \param{n} è un errore comune.} Infine l'argomento
183 \param{timeout}, specifica un tempo massimo di attesa prima che la funzione
184 ritorni; se impostato a \val{NULL} la funzione attende indefinitamente. Si può
185 specificare anche un tempo nullo (cioè una struttura \struct{timeval} con i
186 campi impostati a zero), qualora si voglia semplicemente controllare lo stato
187 corrente dei file descriptor.
189 La funzione restituisce il numero di file descriptor pronti,\footnote{questo è
190 il comportamento previsto dallo standard, ma la standardizzazione della
191 funzione è recente, ed esistono ancora alcune versioni di Unix che non si
192 comportano in questo modo.} e ciascun insieme viene sovrascritto per
193 indicare quali sono i file descriptor pronti per le operazioni ad esso
194 relative, in modo da poterli controllare con \const{FD\_ISSET}. Se invece si
195 ha un timeout viene restituito un valore nullo e gli insiemi non vengono
196 modificati. In caso di errore la funzione restituisce -1, ed i valori dei tre
197 insiemi sono indefiniti e non si può fare nessun affidamento sul loro
200 In Linux \func{select} modifica anche il valore di \param{timeout},
201 impostandolo al tempo restante in caso di interruzione prematura; questo è
202 utile quando la funzione viene interrotta da un segnale, in tal caso infatti
203 si ha un errore di \errcode{EINTR}, ed occorre rilanciare la funzione; in
204 questo modo non è necessario ricalcolare tutte le volte il tempo
205 rimanente.\footnote{questo può causare problemi di portabilità sia quando si
206 trasporta codice scritto su Linux che legge questo valore, sia quando si
207 usano programmi scritti per altri sistemi che non dispongono di questa
208 caratteristica e ricalcolano \param{timeout} tutte le volte. In genere la
209 caratteristica è disponibile nei sistemi che derivano da System V e non
210 disponibile per quelli che derivano da BSD.}
212 Uno dei problemi che si presentano con l'uso di \func{select} è che il suo
213 comportamento dipende dal valore del file descriptor che si vuole tenere sotto
214 controllo. Infatti il kernel riceve con \param{n} un valore massimo per tale
215 valore, e per capire quali sono i file descriptor da tenere sotto controllo
216 dovrà effettuare una scansione su tutto l'intervallo, che può anche essere
217 anche molto ampio anche se i file descriptor sono solo poche unità; tutto ciò
218 ha ovviamente delle conseguenze ampiamente negative per le prestazioni.
220 Inoltre c'è anche il problema che il numero massimo dei file che si possono
221 tenere sotto controllo, la funzione è nata quando il kernel consentiva un
222 numero massimo di 1024 file descriptor per processo, adesso che il numero può
223 essere arbitario si viene a creare una dipendenza del tutto artificiale dalle
224 dimensioni della struttura \type{fd\_set}, che può necessitare di essere
225 estesa, con ulteriori perdite di prestazioni.
227 Lo standard POSIX è rimasto a lungo senza primitive per l'\textit{I/O
228 multiplexing}, introdotto solo con le ultime revisioni dello standard (POSIX
229 1003.1g-2000 e POSIX 1003.1-2001). La scelta è stata quella di seguire
230 l'interfaccia creata da BSD, ma prevede che tutte le funzioni ad esso relative
231 vengano dichiarate nell'header \file{sys/select.h}, che sostituisce i
232 precedenti, ed inoltre aggiunge a \func{select} una nuova funzione
233 \funcd{pselect},\footnote{il supporto per lo standard POSIX 1003.1-2001, ed
234 l'header \file{sys/select.h}, compaiono in Linux a partire dalle \acr{glibc}
235 2.1. Le \acr{libc4} e \acr{libc5} non contengono questo header, le
236 \acr{glibc} 2.0 contengono una definizione sbagliata di \func{psignal},
237 senza l'argomento \param{sigmask}, la definizione corretta è presente dalle
238 \acr{glibc} 2.1-2.2.1 se si è definito \macro{\_GNU\_SOURCE} e nelle
239 \acr{glibc} 2.2.2-2.2.4 se si è definito \macro{\_XOPEN\_SOURCE} con valore
240 maggiore di 600.} il cui prototipo è:
241 \begin{prototype}{sys/select.h}
242 {int pselect(int n, fd\_set *readfds, fd\_set *writefds, fd\_set *exceptfds,
243 struct timespec *timeout, sigset\_t *sigmask)}
245 Attende che uno dei file descriptor degli insiemi specificati diventi
248 \bodydesc{La funzione in caso di successo restituisce il numero di file
249 descriptor (anche nullo) che sono attivi, e -1 in caso di errore, nel qual
250 caso \var{errno} assumerà uno dei valori:
252 \item[\errcode{EBADF}] Si è specificato un file descriptor sbagliato in uno
254 \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
255 \item[\errcode{EINVAL}] Si è specificato per \param{n} un valore negativo o
256 un valore non valido per \param{timeout}.
258 ed inoltre \errval{ENOMEM}.}
261 La funzione è sostanzialmente identica a \func{select}, solo che usa una
262 struttura \struct{timespec} (vedi fig.~\ref{fig:sys_timeval_struct}) per
263 indicare con maggiore precisione il timeout e non ne aggiorna il valore in
264 caso di interruzione. Inoltre prende un argomento aggiuntivo \param{sigmask}
265 che è il puntatore ad una maschera di segnali (si veda
266 sez.~\ref{sec:sig_sigmask}). La maschera corrente viene sostituita da questa
267 immediatamente prima di eseguire l'attesa, e ripristinata al ritorno della
270 L'uso di \param{sigmask} è stato introdotto allo scopo di prevenire possibili
271 race condition\index{race condition} quando ci si deve porre in attesa sia di
272 un segnale che di dati. La tecnica classica è quella di utilizzare il gestore
273 per impostare una variabile globale e controllare questa nel corpo principale
274 del programma; abbiamo visto in sez.~\ref{sec:sig_example} come questo lasci
275 spazio a possibili race condition, per cui diventa essenziale utilizzare
276 \func{sigprocmask} per disabilitare la ricezione del segnale prima di eseguire
277 il controllo e riabilitarlo dopo l'esecuzione delle relative operazioni, onde
278 evitare l'arrivo di un segnale immediatamente dopo il controllo, che andrebbe
281 Nel nostro caso il problema si pone quando oltre al segnale si devono tenere
282 sotto controllo anche dei file descriptor con \func{select}, in questo caso si
283 può fare conto sul fatto che all'arrivo di un segnale essa verrebbe interrotta
284 e si potrebbero eseguire di conseguenza le operazioni relative al segnale e
285 alla gestione dati con un ciclo del tipo:
286 \includecodesnip{listati/select_race.c} qui però emerge una race
287 condition,\index{race condition} perché se il segnale arriva prima della
288 chiamata a \func{select}, questa non verrà interrotta, e la ricezione del
289 segnale non sarà rilevata.
291 Per questo è stata introdotta \func{pselect} che attraverso l'argomento
292 \param{sigmask} permette di riabilitare la ricezione il segnale
293 contestualmente all'esecuzione della funzione,\footnote{in Linux però non è
294 presente la relativa system call, e la funzione è implementata nelle
295 \acr{glibc} attraverso \func{select} (vedi \texttt{man select\_tut}) per cui
296 la possibilità di race condition permane; esiste però una soluzione,
297 chiamata \index{\textit{self-pipe trick}}\textit{self-pipe trick}, che
298 consiste nell'aprire una pipe (vedi sez.~\ref{sec:ipc_pipes}) ed usare
299 \func{select} sul capo in lettura della stessa, e indicare l'arrivo di un
300 segnale scrivendo sul capo in scrittura all'interno del manipolatore; in
301 questo modo anche se il segnale va perso prima della chiamata di
302 \func{select} questa lo riconoscerà comunque dalla presenza di dati sulla
303 pipe.} ribloccandolo non appena essa ritorna, così che il precedente codice
304 potrebbe essere riscritto nel seguente modo:
305 \includecodesnip{listati/pselect_norace.c} in questo caso utilizzando
306 \var{oldmask} durante l'esecuzione di \func{pselect} la ricezione del segnale
307 sarà abilitata, ed in caso di interruzione si potranno eseguire le relative
312 \subsection{La funzione \func{poll}}
313 \label{sec:file_poll}
315 Nello sviluppo di System V, invece di utilizzare l'interfaccia di
316 \func{select}, che è una estensione tipica di BSD, è stata introdotta un'altra
317 interfaccia, basata sulla funzione \funcd{poll},\footnote{la funzione è
318 prevista dallo standard XPG4, ed è stata introdotta in Linux come system
319 call a partire dal kernel 2.1.23 ed inserita nelle \acr{libc} 5.4.28.} il
321 \begin{prototype}{sys/poll.h}
322 {int poll(struct pollfd *ufds, unsigned int nfds, int timeout)}
324 La funzione attende un cambiamento di stato su un insieme di file
327 \bodydesc{La funzione restituisce il numero di file descriptor con attività
328 in caso di successo, o 0 se c'è stato un timeout e -1 in caso di errore,
329 ed in quest'ultimo caso \var{errno} assumerà uno dei valori:
331 \item[\errcode{EBADF}] Si è specificato un file descriptor sbagliato in uno
333 \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
334 \item[\errcode{EINVAL}] Il valore di \param{nfds} eccede il limite
335 \macro{RLIMIT\_NOFILE}.
337 ed inoltre \errval{EFAULT} e \errval{ENOMEM}.}
340 La funzione permette di tenere sotto controllo contemporaneamente \param{ndfs}
341 file descriptor, specificati attraverso il puntatore \param{ufds} ad un
342 vettore di strutture \struct{pollfd}. Come con \func{select} si può
343 interrompere l'attesa dopo un certo tempo, questo deve essere specificato con
344 l'argomento \param{timeout} in numero di millisecondi: un valore negativo
345 indica un'attesa indefinita, mentre un valore nullo comporta il ritorno
346 immediato (e può essere utilizzato per impiegare \func{poll} in modalità
347 \textsl{non-bloccante}).
350 \footnotesize \centering
351 \begin{minipage}[c]{15cm}
352 \includestruct{listati/pollfd.h}
355 \caption{La struttura \structd{pollfd}, utilizzata per specificare le
356 modalità di controllo di un file descriptor alla funzione \func{poll}.}
357 \label{fig:file_pollfd}
360 Per ciascun file da controllare deve essere inizializzata una struttura
361 \struct{pollfd} nel vettore indicato dall'argomento \param{ufds}. La
362 struttura, la cui definizione è riportata in fig.~\ref{fig:file_pollfd},
363 prevede tre campi: in \var{fd} deve essere indicato il numero del file
364 descriptor da controllare, in \var{events} deve essere specificata una
365 maschera binaria di flag che indichino il tipo di evento che si vuole
366 controllare, mentre in \var{revents} il kernel restituirà il relativo
367 risultato. Usando un valore negativo per \param{fd} la corrispondente
368 struttura sarà ignorata da \func{poll}. Dato che i dati in ingresso sono del
369 tutto indipendenti da quelli in uscita (che vengono restituiti in
370 \var{revents}) non è necessario reinizializzare tutte le volte il valore delle
371 strutture \struct{pollfd} a meno di non voler cambiare qualche condizione.
373 Le costanti che definiscono i valori relativi ai bit usati nelle maschere
374 binarie dei campi \var{events} e \var{revents} sono riportati in
375 tab.~\ref{tab:file_pollfd_flags}, insieme al loro significato. Le si sono
376 suddivise in tre gruppi, nel primo gruppo si sono indicati i bit utilizzati
377 per controllare l'attività in ingresso, nel secondo quelli per l'attività in
378 uscita, mentre il terzo gruppo contiene dei valori che vengono utilizzati solo
379 nel campo \var{revents} per notificare delle condizioni di errore.
384 \begin{tabular}[c]{|l|l|}
386 \textbf{Flag} & \textbf{Significato} \\
389 \const{POLLIN} & È possibile la lettura.\\
390 \const{POLLRDNORM}& Sono disponibili in lettura dati normali.\\
391 \const{POLLRDBAND}& Sono disponibili in lettura dati prioritari. \\
392 \const{POLLPRI} & È possibile la lettura di dati urgenti.\\
394 \const{POLLOUT} & È possibile la scrittura immediata.\\
395 \const{POLLWRNORM}& È possibile la scrittura di dati normali. \\
396 \const{POLLWRBAND}& È possibile la scrittura di dati prioritari. \\
398 \const{POLLERR} & C'è una condizione di errore.\\
399 \const{POLLHUP} & Si è verificato un hung-up.\\
400 \const{POLLNVAL} & Il file descriptor non è aperto.\\
402 \const{POLLMSG} & Definito per compatibilità con SysV.\\
405 \caption{Costanti per l'identificazione dei vari bit dei campi
406 \var{events} e \var{revents} di \struct{pollfd}.}
407 \label{tab:file_pollfd_flags}
410 Il valore \const{POLLMSG} non viene utilizzato ed è definito solo per
411 compatibilità con l'implementazione di SysV che usa gli
412 \textit{stream};\footnote{essi sono una interfaccia specifica di SysV non
413 presente in Linux, e non hanno nulla a che fare con i file \textit{stream}
414 delle librerie standard del C.} è da questi che derivano i nomi di alcune
415 costanti, in quanto per essi sono definite tre classi di dati:
416 \textsl{normali}, \textit{prioritari} ed \textit{urgenti}. In Linux la
417 distinzione ha senso solo per i dati \textit{out-of-band} dei socket (vedi
418 sez.~\ref{sec:TCP_urgent_data}), ma su questo e su come \func{poll} reagisce
419 alle varie condizioni dei socket torneremo in sez.~\ref{sec:TCP_serv_poll},
420 dove vedremo anche un esempio del suo utilizzo. Si tenga conto comunque che le
421 costanti relative ai diversi tipi di dati (come \macro{POLLRDNORM} e
422 \macro{POLLRDBAND}) sono utilizzabili soltanto qualora si sia definita la
423 macro \macro{\_XOPEN\_SOURCE}.\footnote{e ci si ricordi di farlo sempre in
424 testa al file, definirla soltanto prima di includere \file{sys/poll.h} non è
427 In caso di successo funzione ritorna restituendo il numero di file (un valore
428 positivo) per i quali si è verificata una delle condizioni di attesa richieste
429 o per i quali si è verificato un errore (nel qual caso vengono utilizzati i
430 valori di tab.~\ref{tab:file_pollfd_flags} esclusivi di \var{revents}). Un
431 valore nullo indica che si è raggiunto il timeout, mentre un valore negativo
432 indica un errore nella chiamata, il cui codice viene riportato al solito
436 %\subsection{L'interfaccia di \textit{epoll}}
437 %\label{sec:file_epoll}
442 \section{L'accesso \textsl{asincrono} ai file}
443 \label{sec:file_asyncronous_access}
445 Benché l'\textit{I/O multiplexing} sia stata la prima, e sia tutt'ora una fra
446 le più diffuse modalità di gestire l'I/O in situazioni complesse in cui si
447 debba operare su più file contemporaneamente, esistono altre modalità di
448 gestione delle stesse problematiche. In particolare sono importanti in questo
449 contesto le modalità di accesso ai file eseguibili in maniera
450 \textsl{asincrona}, quelle cioè in cui un processo non deve bloccarsi in
451 attesa della disponibilità dell'accesso al file, ma può proseguire
452 nell'esecuzione utilizzando invece un meccanismo di notifica asincrono (di
453 norma un segnale), per essere avvisato della possibilità di eseguire le
454 operazioni di I/O volute.
457 \subsection{Operazioni asincrone sui file}
458 \label{sec:file_asyncronous_operation}
460 Abbiamo accennato in sez.~\ref{sec:file_open} che è possibile, attraverso l'uso
461 del flag \const{O\_ASYNC},\footnote{l'uso del flag di \const{O\_ASYNC} e dei
462 comandi \const{F\_SETOWN} e \const{F\_GETOWN} per \func{fcntl} è specifico
463 di Linux e BSD.} aprire un file in modalità asincrona, così come è possibile
464 attivare in un secondo tempo questa modalità impostando questo flag attraverso
465 l'uso di \func{fcntl} con il comando \const{F\_SETFL} (vedi
466 sez.~\ref{sec:file_fcntl}).
468 In realtà in questo caso non si tratta di eseguire delle operazioni di lettura
469 o scrittura del file in modo asincrono (tratteremo questo, che più
470 propriamente è detto \textsl{I/O asincrono} in
471 sez.~\ref{sec:file_asyncronous_io}), quanto di un meccanismo asincrono di
472 notifica delle variazione dello stato del file descriptor aperto in questo
475 Quello che succede in questo caso è che il sistema genera un segnale
476 (normalmente \const{SIGIO}, ma è possibile usarne altri con il comando
477 \const{F\_SETSIG} di \func{fcntl}) tutte le volte che diventa possibile
478 leggere o scrivere dal file descriptor che si è posto in questa modalità. Si
479 può inoltre selezionare, con il comando \const{F\_SETOWN} di \func{fcntl},
480 quale processo (o gruppo di processi) riceverà il segnale. Se pertanto si
481 effettuano le operazioni di I/O in risposta alla ricezione del segnale non ci
482 sarà più la necessità di restare bloccati in attesa della disponibilità di
483 accesso ai file; per questo motivo Stevens chiama questa modalità
484 \textit{signal driven I/O}.
486 In questo modo si può evitare l'uso delle funzioni \func{poll} o \func{select}
487 che, quando vengono usate con un numero molto grande di file descriptor, non
488 hanno buone prestazioni. % aggiungere cenno a epoll quando l'avrò scritta
489 In tal caso infatti la maggior parte del loro tempo
490 di esecuzione è impegnato ad eseguire una scansione su tutti i file descriptor
491 tenuti sotto controllo per determinare quali di essi (in genere una piccola
492 percentuale) sono diventati attivi.
494 Tuttavia con l'implementazione classica dei segnali questa modalità di I/O
495 presenta notevoli problemi, dato che non è possibile determinare, quando i
496 file descriptor sono più di uno, qual'è quello responsabile dell'emissione del
497 segnale. Inoltre dato che i segnali normali non si accodano (si ricordi quanto
498 illustrato in sez.~\ref{sec:sig_notification}), in presenza di più file
499 descriptor attivi contemporaneamente, più segnali emessi nello stesso momento
500 verrebbero notificati una volta sola. Linux però supporta le estensioni
501 POSIX.1b dei segnali real-time, che vengono accodati e che permettono di
502 riconoscere il file descriptor che li ha emessi. In questo caso infatti si può
503 fare ricorso alle informazioni aggiuntive restituite attraverso la struttura
504 \struct{siginfo\_t}, utilizzando la forma estesa \var{sa\_sigaction} del
505 gestore (si riveda quanto illustrato in sez.~\ref{sec:sig_sigaction}).
507 Per far questo però occorre utilizzare le funzionalità dei segnali real-time
508 (vedi sez.~\ref{sec:sig_real_time}) impostando esplicitamente con il comando
509 \const{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare in caso di
510 I/O asincrono (il segnale predefinito è \const{SIGIO}). In questo caso il
511 gestore, tutte le volte che riceverà \const{SI\_SIGIO} come valore del
512 campo \var{si\_code}\footnote{il valore resta \const{SI\_SIGIO} qualunque sia
513 il segnale che si è associato all'I/O asincrono, ed indica appunto che il
514 segnale è stato generato a causa di attività nell'I/O asincrono.} di
515 \struct{siginfo\_t}, troverà nel campo \var{si\_fd} il valore del file
516 descriptor che ha generato il segnale.
518 Un secondo vantaggio dell'uso dei segnali real-time è che essendo questi
519 ultimi dotati di una coda di consegna ogni segnale sarà associato ad uno solo
520 file descriptor; inoltre sarà possibile stabilire delle priorità nella
521 risposta a seconda del segnale usato, dato che i segnali real-time supportano
522 anche questa funzionalità. In questo modo si può identificare immediatamente
523 un file su cui l'accesso è diventato possibile evitando completamente l'uso di
524 funzioni come \func{poll} e \func{select}, almeno fintanto che non si satura
525 la coda. Se infatti si eccedono le dimensioni di quest'ultima, il kernel, non
526 potendo più assicurare il comportamento corretto per un segnale real-time,
527 invierà al suo posto un solo \const{SIGIO}, su cui si saranno accumulati tutti
528 i segnali in eccesso, e si dovrà allora determinare con un ciclo quali sono i
529 file diventati attivi.
532 \subsection{L'interfaccia POSIX per l'I/O asincrono}
533 \label{sec:file_asyncronous_io}
535 Una modalità alternativa all'uso dell'\textit{I/O multiplexing} per gestione
536 dell'I/O simultaneo su molti file è costituita dal cosiddetto \textsl{I/O
537 asincrono}. Il concetto base dell'\textsl{I/O asincrono} è che le funzioni
538 di I/O non attendono il completamento delle operazioni prima di ritornare,
539 così che il processo non viene bloccato. In questo modo diventa ad esempio
540 possibile effettuare una richiesta preventiva di dati, in modo da poter
541 effettuare in contemporanea le operazioni di calcolo e quelle di I/O.
543 Benché la modalità di apertura asincrona di un file possa risultare utile in
544 varie occasioni (in particolar modo con i socket\index{socket} e gli altri
545 file per i quali le funzioni di I/O sono \index{system call lente}system call
546 lente), essa è comunque limitata alla notifica della disponibilità del file
547 descriptor per le operazioni di I/O, e non ad uno svolgimento asincrono delle
548 medesime. Lo standard POSIX.1b definisce una interfaccia apposita per l'I/O
549 asincrono vero e proprio, che prevede un insieme di funzioni dedicate per la
550 lettura e la scrittura dei file, completamente separate rispetto a quelle
553 In generale questa interfaccia è completamente astratta e può essere
554 implementata sia direttamente nel kernel, che in user space attraverso l'uso
555 di thread. Al momento esiste una sola versione stabile di questa interfaccia,
556 quella delle \acr{glibc}, che è realizzata completamente in user space, ed
557 accessibile linkando i programmi con la libreria \file{librt}. Nei kernel
558 della nuova serie è stato anche introdotta (a partire dal 2.5.32) un nuovo
559 layer per l'I/O asincrono.
561 Lo standard prevede che tutte le operazioni di I/O asincrono siano controllate
562 attraverso l'uso di una apposita struttura \struct{aiocb} (il cui nome sta per
563 \textit{asyncronous I/O control block}), che viene passata come argomento a
564 tutte le funzioni dell'interfaccia. La sua definizione, come effettuata in
565 \file{aio.h}, è riportata in fig.~\ref{fig:file_aiocb}. Nello steso file è
566 definita la macro \macro{\_POSIX\_ASYNCHRONOUS\_IO}, che dichiara la
567 disponibilità dell'interfaccia per l'I/O asincrono.
570 \footnotesize \centering
571 \begin{minipage}[c]{15cm}
572 \includestruct{listati/aiocb.h}
575 \caption{La struttura \structd{aiocb}, usata per il controllo dell'I/O
577 \label{fig:file_aiocb}
580 Le operazioni di I/O asincrono possono essere effettuate solo su un file già
581 aperto; il file deve inoltre supportare la funzione \func{lseek}, pertanto
582 terminali e pipe sono esclusi. Non c'è limite al numero di operazioni
583 contemporanee effettuabili su un singolo file. Ogni operazione deve
584 inizializzare opportunamente un \textit{control block}. Il file descriptor su
585 cui operare deve essere specificato tramite il campo \var{aio\_fildes}; dato
586 che più operazioni possono essere eseguita in maniera asincrona, il concetto
587 di posizione corrente sul file viene a mancare; pertanto si deve sempre
588 specificare nel campo \var{aio\_offset} la posizione sul file da cui i dati
589 saranno letti o scritti. Nel campo \var{aio\_buf} deve essere specificato
590 l'indirizzo del buffer usato per l'I/O, ed in \var{aio\_nbytes} la lunghezza
591 del blocco di dati da trasferire.
593 Il campo \var{aio\_reqprio} permette di impostare la priorità delle operazioni
594 di I/O.\footnote{in generale perché ciò sia possibile occorre che la
595 piattaforma supporti questa caratteristica, questo viene indicato definendo
596 le macro \macro{\_POSIX\_PRIORITIZED\_IO}, e
597 \macro{\_POSIX\_PRIORITY\_SCHEDULING}.} La priorità viene impostata a
598 partire da quella del processo chiamante (vedi sez.~\ref{sec:proc_priority}),
599 cui viene sottratto il valore di questo campo. Il campo
600 \var{aio\_lio\_opcode} è usato solo dalla funzione \func{lio\_listio}, che,
601 come vedremo, permette di eseguire con una sola chiamata una serie di
602 operazioni, usando un vettore di \textit{control block}. Tramite questo campo
603 si specifica quale è la natura di ciascuna di esse.
606 \footnotesize \centering
607 \begin{minipage}[c]{15cm}
608 \includestruct{listati/sigevent.h}
611 \caption{La struttura \structd{sigevent}, usata per specificare le modalità
612 di notifica degli eventi relativi alle operazioni di I/O asincrono.}
613 \label{fig:file_sigevent}
616 Infine il campo \var{aio\_sigevent} è una struttura di tipo \struct{sigevent}
617 che serve a specificare il modo in cui si vuole che venga effettuata la
618 notifica del completamento delle operazioni richieste. La struttura è
619 riportata in fig.~\ref{fig:file_sigevent}; il campo \var{sigev\_notify} è
620 quello che indica le modalità della notifica, esso può assumere i tre valori:
621 \begin{basedescript}{\desclabelwidth{2.6cm}}
622 \item[\const{SIGEV\_NONE}] Non viene inviata nessuna notifica.
623 \item[\const{SIGEV\_SIGNAL}] La notifica viene effettuata inviando al processo
624 chiamante il segnale specificato da \var{sigev\_signo}; se il gestore di
625 questo è stato installato con \const{SA\_SIGINFO} gli verrà restituito il
626 valore di \var{sigev\_value} (la cui definizione è in
627 fig.~\ref{fig:sig_sigval}) come valore del campo \var{si\_value} di
629 \item[\const{SIGEV\_THREAD}] La notifica viene effettuata creando un nuovo
630 thread che esegue la funzione specificata da \var{sigev\_notify\_function}
631 con argomento \var{sigev\_value}, e con gli attributi specificati da
632 \var{sigev\_notify\_attribute}.
635 Le due funzioni base dell'interfaccia per l'I/O asincrono sono
636 \funcd{aio\_read} ed \funcd{aio\_write}. Esse permettono di richiedere una
637 lettura od una scrittura asincrona di dati, usando la struttura \struct{aiocb}
638 appena descritta; i rispettivi prototipi sono:
642 \funcdecl{int aio\_read(struct aiocb *aiocbp)}
643 Richiede una lettura asincrona secondo quanto specificato con \param{aiocbp}.
645 \funcdecl{int aio\_write(struct aiocb *aiocbp)}
646 Richiede una scrittura asincrona secondo quanto specificato con
649 \bodydesc{Le funzioni restituiscono 0 in caso di successo, e -1 in caso di
650 errore, nel qual caso \var{errno} assumerà uno dei valori:
652 \item[\errcode{EBADF}] Si è specificato un file descriptor sbagliato.
653 \item[\errcode{ENOSYS}] La funzione non è implementata.
654 \item[\errcode{EINVAL}] Si è specificato un valore non valido per i campi
655 \var{aio\_offset} o \var{aio\_reqprio} di \param{aiocbp}.
656 \item[\errcode{EAGAIN}] La coda delle richieste è momentaneamente piena.
661 Entrambe le funzioni ritornano immediatamente dopo aver messo in coda la
662 richiesta, o in caso di errore. Non è detto che gli errori \errcode{EBADF} ed
663 \errcode{EINVAL} siano rilevati immediatamente al momento della chiamata,
664 potrebbero anche emergere nelle fasi successive delle operazioni. Lettura e
665 scrittura avvengono alla posizione indicata da \var{aio\_offset}, a meno che
666 il file non sia stato aperto in \textit{append mode} (vedi
667 sez.~\ref{sec:file_open}), nel qual caso le scritture vengono effettuate
668 comunque alla fine de file, nell'ordine delle chiamate a \func{aio\_write}.
670 Si tenga inoltre presente che deallocare la memoria indirizzata da
671 \param{aiocbp} o modificarne i valori prima della conclusione di una
672 operazione può dar luogo a risultati impredicibili, perché l'accesso ai vari
673 campi per eseguire l'operazione può avvenire in un momento qualsiasi dopo la
674 richiesta. Questo comporta che non si devono usare per \param{aiocbp}
675 variabili automatiche e che non si deve riutilizzare la stessa struttura per
676 un'altra operazione fintanto che la precedente non sia stata ultimata. In
677 generale per ogni operazione si deve utilizzare una diversa struttura
680 Dato che si opera in modalità asincrona, il successo di \func{aio\_read} o
681 \func{aio\_write} non implica che le operazioni siano state effettivamente
682 eseguite in maniera corretta; per verificarne l'esito l'interfaccia prevede
683 altre due funzioni, che permettono di controllare lo stato di esecuzione. La
684 prima è \funcd{aio\_error}, che serve a determinare un eventuale stato di
685 errore; il suo prototipo è:
686 \begin{prototype}{aio.h}
687 {int aio\_error(const struct aiocb *aiocbp)}
689 Determina lo stato di errore delle operazioni di I/O associate a
692 \bodydesc{La funzione restituisce 0 se le operazioni si sono concluse con
693 successo, altrimenti restituisce il codice di errore relativo al loro
697 Se l'operazione non si è ancora completata viene restituito l'errore di
698 \errcode{EINPROGRESS}. La funzione ritorna zero quando l'operazione si è
699 conclusa con successo, altrimenti restituisce il codice dell'errore
700 verificatosi, ed esegue la corrispondente impostazione di \var{errno}. Il
701 codice può essere sia \errcode{EINVAL} ed \errcode{EBADF}, dovuti ad un valore
702 errato per \param{aiocbp}, che uno degli errori possibili durante l'esecuzione
703 dell'operazione di I/O richiesta, nel qual caso saranno restituiti, a seconda
704 del caso, i codici di errore delle system call \func{read}, \func{write} e
707 Una volta che si sia certi che le operazioni siano state concluse (cioè dopo
708 che una chiamata ad \func{aio\_error} non ha restituito
709 \errcode{EINPROGRESS}), si potrà usare la funzione \funcd{aio\_return}, che
710 permette di verificare il completamento delle operazioni di I/O asincrono; il
712 \begin{prototype}{aio.h}
713 {ssize\_t aio\_return(const struct aiocb *aiocbp)}
715 Recupera il valore dello stato di ritorno delle operazioni di I/O associate a
718 \bodydesc{La funzione restituisce lo stato di uscita dell'operazione
722 La funzione deve essere chiamata una sola volte per ciascuna operazione
723 asincrona, essa infatti fa sì che il sistema rilasci le risorse ad essa
724 associate. É per questo motivo che occorre chiamare la funzione solo dopo che
725 l'operazione cui \param{aiocbp} fa riferimento si è completata. Una chiamata
726 precedente il completamento delle operazioni darebbe risultati indeterminati.
728 La funzione restituisce il valore di ritorno relativo all'operazione eseguita,
729 così come ricavato dalla sottostante system call (il numero di byte letti,
730 scritti o il valore di ritorno di \func{fsync}). É importante chiamare sempre
731 questa funzione, altrimenti le risorse disponibili per le operazioni di I/O
732 asincrono non verrebbero liberate, rischiando di arrivare ad un loro
735 Oltre alle operazioni di lettura e scrittura l'interfaccia POSIX.1b mette a
736 disposizione un'altra operazione, quella di sincronizzazione dell'I/O,
737 compiuta dalla funzione \func{aio\_fsync}, che ha lo stesso effetto della
738 analoga \func{fsync}, ma viene eseguita in maniera asincrona; il suo prototipo
740 \begin{prototype}{aio.h}
741 {ssize\_t aio\_return(int op, struct aiocb *aiocbp)}
743 Richiede la sincronizzazione dei dati per il file indicato da \param{aiocbp}.
745 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
746 errore, che può essere, con le stesse modalità di \func{aio\_read},
747 \errval{EAGAIN}, \errval{EBADF} o \errval{EINVAL}.}
750 La funzione richiede la sincronizzazione delle operazioni di I/O, ritornando
751 immediatamente. L'esecuzione effettiva della sincronizzazione dovrà essere
752 verificata con \func{aio\_error} e \func{aio\_return} come per le operazioni
753 di lettura e scrittura. L'argomento \param{op} permette di indicare la
754 modalità di esecuzione, se si specifica il valore \const{O\_DSYNC} le
755 operazioni saranno completate con una chiamata a \func{fdatasync}, se si
756 specifica \const{O\_SYNC} con una chiamata a \func{fsync} (per i dettagli vedi
757 sez.~\ref{sec:file_sync}).
759 Il successo della chiamata assicura la sincronizzazione delle operazioni fino
760 allora richieste, niente è garantito riguardo la sincronizzazione dei dati
761 relativi ad eventuali operazioni richieste successivamente. Se si è
762 specificato un meccanismo di notifica questo sarà innescato una volta che le
763 operazioni di sincronizzazione dei dati saranno completate.
765 In alcuni casi può essere necessario interrompere le operazioni (in genere
766 quando viene richiesta un'uscita immediata dal programma), per questo lo
767 standard POSIX.1b prevede una funzioni apposita, \funcd{aio\_cancel}, che
768 permette di cancellare una operazione richiesta in precedenza; il suo
770 \begin{prototype}{aio.h}
771 {int aio\_cancel(int fildes, struct aiocb *aiocbp)}
773 Richiede la cancellazione delle operazioni sul file \param{fildes} specificate
776 \bodydesc{La funzione restituisce il risultato dell'operazione con un codice
777 di positivo, e -1 in caso di errore, che avviene qualora si sia specificato
778 un valore non valido di \param{fildes}, imposta \var{errno} al valore
782 La funzione permette di cancellare una operazione specifica sul file
783 \param{fildes}, o tutte le operazioni pendenti, specificando \val{NULL} come
784 valore di \param{aiocbp}. Quando una operazione viene cancellata una
785 successiva chiamata ad \func{aio\_error} riporterà \errcode{ECANCELED} come
786 codice di errore, ed il suo codice di ritorno sarà -1, inoltre il meccanismo
787 di notifica non verrà invocato. Se si specifica una operazione relativa ad un
788 altro file descriptor il risultato è indeterminato.
790 In caso di successo, i possibili valori di ritorno per \func{aio\_cancel} sono
791 tre (anch'essi definiti in \file{aio.h}):
792 \begin{basedescript}{\desclabelwidth{3.0cm}}
793 \item[\const{AIO\_ALLDONE}] indica che le operazioni di cui si è richiesta la
794 cancellazione sono state già completate,
796 \item[\const{AIO\_CANCELED}] indica che tutte le operazioni richieste sono
799 \item[\const{AIO\_NOTCANCELED}] indica che alcune delle operazioni erano in
800 corso e non sono state cancellate.
803 Nel caso si abbia \const{AIO\_NOTCANCELED} occorrerà chiamare
804 \func{aio\_error} per determinare quali sono le operazioni effettivamente
805 cancellate. Le operazioni che non sono state cancellate proseguiranno il loro
806 corso normale, compreso quanto richiesto riguardo al meccanismo di notifica
807 del loro avvenuto completamento.
809 Benché l'I/O asincrono preveda un meccanismo di notifica, l'interfaccia
810 fornisce anche una apposita funzione, \funcd{aio\_suspend}, che permette di
811 sospendere l'esecuzione del processo chiamante fino al completamento di una
812 specifica operazione; il suo prototipo è:
813 \begin{prototype}{aio.h}
814 {int aio\_suspend(const struct aiocb * const list[], int nent, const struct
817 Attende, per un massimo di \param{timeout}, il completamento di una delle
818 operazioni specificate da \param{list}.
820 \bodydesc{La funzione restituisce 0 se una (o più) operazioni sono state
821 completate, e -1 in caso di errore nel qual caso \var{errno} assumerà uno
824 \item[\errcode{EAGAIN}] Nessuna operazione è stata completata entro
826 \item[\errcode{ENOSYS}] La funzione non è implementata.
827 \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
832 La funzione permette di bloccare il processo fintanto che almeno una delle
833 \param{nent} operazioni specificate nella lista \param{list} è completata, per
834 un tempo massimo specificato da \param{timout}, o fintanto che non arrivi un
835 segnale.\footnote{si tenga conto che questo segnale può anche essere quello
836 utilizzato come meccanismo di notifica.} La lista deve essere inizializzata
837 con delle strutture \struct{aiocb} relative ad operazioni effettivamente
838 richieste, ma può contenere puntatori nulli, che saranno ignorati. In caso si
839 siano specificati valori non validi l'effetto è indefinito. Un valore
840 \val{NULL} per \param{timout} comporta l'assenza di timeout.
842 Lo standard POSIX.1b infine ha previsto pure una funzione, \funcd{lio\_listio},
843 che permette di effettuare la richiesta di una intera lista di operazioni di
844 lettura o scrittura; il suo prototipo è:
845 \begin{prototype}{aio.h}
846 {int lio\_listio(int mode, struct aiocb * const list[], int nent, struct
849 Richiede l'esecuzione delle operazioni di I/O elencata da \param{list},
850 secondo la modalità \param{mode}.
852 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
853 errore, nel qual caso \var{errno} assumerà uno dei valori:
855 \item[\errcode{EAGAIN}] Nessuna operazione è stata completata entro
857 \item[\errcode{EINVAL}] Si è passato un valore di \param{mode} non valido
858 o un numero di operazioni \param{nent} maggiore di
859 \const{AIO\_LISTIO\_MAX}.
860 \item[\errcode{ENOSYS}] La funzione non è implementata.
861 \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
866 La funzione esegue la richiesta delle \param{nent} operazioni indicate dalla
867 lista \param{list}; questa deve contenere gli indirizzi di altrettanti
868 \textit{control block}, opportunamente inizializzati; in particolare nel caso
869 dovrà essere specificato il tipo di operazione tramite il campo
870 \var{aio\_lio\_opcode}, che può prendere i tre valori:
871 \begin{basedescript}{\desclabelwidth{2.0cm}}
872 \item[\const{LIO\_READ}] si richiede una operazione di lettura.
873 \item[\const{LIO\_WRITE}] si richiede una operazione di scrittura.
874 \item[\const{LIO\_NOP}] non si effettua nessuna operazione.
876 l'ultimo valore viene usato quando si ha a che fare con un vettore di
877 dimensione fissa, per poter specificare solo alcune operazioni, o quando si è
878 dovuto cancellare delle operazioni e si deve ripetere la richiesta per quelle
881 L'argomento \param{mode} permette di stabilire il comportamento della
882 funzione, se viene specificato il valore \const{LIO\_WAIT} la funzione si
883 blocca fino al completamento di tutte le operazioni richieste; se invece si
884 specifica \const{LIO\_NOWAIT} la funzione ritorna immediatamente dopo aver
885 messo in coda tutte le richieste. In questo caso il chiamante può richiedere
886 la notifica del completamento di tutte le richieste, impostando l'argomento
887 \param{sig} in maniera analoga a come si fa per il campo \var{aio\_sigevent}
891 \section{Altre modalità di I/O avanzato}
892 \label{sec:file_advanced_io}
894 Oltre alle precedenti modalità di \textit{I/O multiplexing} e \textsl{I/O
895 asincrono}, esistono altre funzioni che implementano delle modalità di
896 accesso ai file più evolute rispetto alle normali funzioni di lettura e
897 scrittura che abbiamo esaminato in sez.~\ref{sec:file_base_func}. In questa
898 sezione allora prenderemo in esame le interfacce per l'\textsl{I/O
899 vettorizzato} e per l'\textsl{I/O mappato in memoria}.
902 \subsection{I/O vettorizzato}
903 \label{sec:file_multiple_io}
905 Un caso abbastanza comune è quello in cui ci si trova a dover eseguire una
906 serie multipla di operazioni di I/O, come una serie di letture o scritture di
907 vari buffer. Un esempio tipico è quando i dati sono strutturati nei campi di
908 una struttura ed essi devono essere caricati o salvati su un file. Benché
909 l'operazione sia facilmente eseguibile attraverso una serie multipla di
910 chiamate, ci sono casi in cui si vuole poter contare sulla atomicità delle
913 Per questo motivo BSD 4.2\footnote{Le due funzioni sono riprese da BSD4.4 ed
914 integrate anche dallo standard Unix 98. Fino alle libc5, Linux usava
915 \type{size\_t} come tipo dell'argomento \param{count}, una scelta logica,
916 che però è stata dismessa per restare aderenti allo standard.} ha introdotto
917 due nuove system call, \funcd{readv} e \funcd{writev}, che permettono di
918 effettuare con una sola chiamata una lettura o una scrittura su una serie di
919 buffer (quello che viene chiamato \textsl{I/O vettorizzato}. I relativi
924 \funcdecl{int readv(int fd, const struct iovec *vector, int count)} Esegue
925 una lettura vettorizzata da \param{fd} nei \param{count} buffer specificati
928 \funcdecl{int writev(int fd, const struct iovec *vector, int count)} Esegue
929 una scrittura vettorizzata da \param{fd} nei \param{count} buffer
930 specificati da \param{vector}.
932 \bodydesc{Le funzioni restituiscono il numero di byte letti o scritti in
933 caso di successo, e -1 in caso di errore, nel qual caso \var{errno}
934 assumerà uno dei valori:
936 \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato.
937 \item[\errcode{EINVAL}] si è specificato un valore non valido per uno degli
938 argomenti (ad esempio \param{count} è maggiore di \const{MAX\_IOVEC}).
939 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di
940 di avere eseguito una qualunque lettura o scrittura.
941 \item[\errcode{EAGAIN}] \param{fd} è stato aperto in modalità non bloccante e
942 non ci sono dati in lettura.
943 \item[\errcode{EOPNOTSUPP}] La coda delle richieste è momentaneamente piena.
945 ed inoltre \errval{EISDIR}, \errval{ENOMEM}, \errval{EFAULT} (se non sono
946 stato allocati correttamente i buffer specificati nei campi
947 \func{iov\_base}), più tutti gli ulteriori errori che potrebbero avere le
948 usuali funzioni di lettura e scrittura eseguite su \param{fd}.}
951 Entrambe le funzioni usano una struttura \struct{iovec}, definita in
952 fig.~\ref{fig:file_iovec}, che definisce dove i dati devono essere letti o
953 scritti. Il primo campo, \var{iov\_base}, contiene l'indirizzo del buffer ed
954 il secondo, \var{iov\_len}, la dimensione dello stesso.
957 \footnotesize \centering
958 \begin{minipage}[c]{15cm}
959 \includestruct{listati/iovec.h}
962 \caption{La struttura \structd{iovec}, usata dalle operazioni di I/O
964 \label{fig:file_iovec}
967 I buffer da utilizzare sono indicati attraverso l'argomento \param{vector} che
968 è un vettore di strutture \struct{iovec}, la cui lunghezza è specificata da
969 \param{count}. Ciascuna struttura dovrà essere inizializzata per
970 opportunamente per indicare i vari buffer da/verso i quali verrà eseguito il
971 trasferimento dei dati. Essi verranno letti (o scritti) nell'ordine in cui li
972 si sono specificati nel vettore \param{vector}.
975 \subsection{File mappati in memoria}
976 \label{sec:file_memory_map}
978 Una modalità alternativa di I/O, che usa una interfaccia completamente diversa
979 rispetto a quella classica vista in cap.~\ref{cha:file_unix_interface}, è il
980 cosiddetto \textit{memory-mapped I/O}, che, attraverso il meccanismo della
981 \textsl{paginazione}\index{paginazione} usato dalla memoria virtuale (vedi
982 sez.~\ref{sec:proc_mem_gen}), permette di \textsl{mappare} il contenuto di un
983 file in una sezione dello spazio di indirizzi del processo. Il meccanismo è
984 illustrato in fig.~\ref{fig:file_mmap_layout}, una sezione del file viene
985 riportata direttamente nello spazio degli indirizzi del programma. Tutte le
986 operazioni su questa zona verranno riportate indietro sul file dal meccanismo
987 della memoria virtuale\index{memoria virtuale} che trasferirà il contenuto di
988 quel segmento sul file invece che nella swap, per cui si può parlare tanto di
989 file mappato in memoria, quanto di memoria mappata su file.
993 \includegraphics[width=7.cm]{img/mmap_layout}
994 \caption{Disposizione della memoria di un processo quando si esegue la
995 mappatura in memoria di un file.}
996 \label{fig:file_mmap_layout}
999 Tutto questo comporta una notevole semplificazione delle operazioni di I/O, in
1000 quanto non sarà più necessario utilizzare dei buffer intermedi su cui
1001 appoggiare i dati da traferire, ma questi potranno essere acceduti
1002 direttamente nella sezione di memoria mappata; inoltre questa interfaccia è
1003 più efficiente delle usuali funzioni di I/O, in quanto permette di caricare in
1004 memoria solo le parti del file che sono effettivamente usate ad un dato
1007 Infatti, dato che l'accesso è fatto direttamente attraverso la memoria
1008 virtuale,\index{memoria virtuale} la sezione di memoria mappata su cui si
1009 opera sarà a sua volta letta o scritta sul file una pagina alla volta e solo
1010 per le parti effettivamente usate, il tutto in maniera completamente
1011 trasparente al processo; l'accesso alle pagine non ancora caricate avverrà
1012 allo stesso modo con cui vengono caricate in memoria le pagine che sono state
1013 salvate sullo swap. Infine in situazioni in cui la memoria è scarsa, le
1014 pagine che mappano un file vengono salvate automaticamente, così come le
1015 pagine dei programmi vengono scritte sulla swap; questo consente di accedere
1016 ai file su dimensioni il cui solo limite è quello dello spazio di indirizzi
1017 disponibile, e non della memoria su cui possono esserne lette delle porzioni.
1019 L'interfaccia prevede varie funzioni per la gestione del \textit{memory mapped
1020 I/O}, la prima di queste è \funcd{mmap}, che serve ad eseguire la mappatura
1021 in memoria di un file; il suo prototipo è:
1025 \headdecl{sys/mman.h}
1027 \funcdecl{void * mmap(void * start, size\_t length, int prot, int flags, int
1030 Esegue la mappatura in memoria del file \param{fd}.
1032 \bodydesc{La funzione restituisce il puntatore alla zona di memoria mappata
1033 in caso di successo, e \const{MAP\_FAILED} (-1) in caso di errore, nel
1034 qual caso \var{errno} assumerà uno dei valori:
1036 \item[\errcode{EBADF}] Il file descriptor non è valido, e non si è usato
1037 \const{MAP\_ANONYMOUS}.
1038 \item[\errcode{EACCES}] o \param{fd} non si riferisce ad un file regolare,
1039 o si è usato \const{MAP\_PRIVATE} ma \param{fd} non è aperto in lettura,
1040 o si è usato \const{MAP\_SHARED} e impostato \const{PROT\_WRITE} ed
1041 \param{fd} non è aperto in lettura/scrittura, o si è impostato
1042 \const{PROT\_WRITE} ed \param{fd} è in \textit{append-only}.
1043 \item[\errcode{EINVAL}] I valori di \param{start}, \param{length} o
1044 \param{offset} non sono validi (o troppo grandi o non allineati sulla
1045 dimensione delle pagine).
1046 \item[\errcode{ETXTBSY}] Si è impostato \const{MAP\_DENYWRITE} ma
1047 \param{fd} è aperto in scrittura.
1048 \item[\errcode{EAGAIN}] Il file è bloccato, o si è bloccata troppa memoria.
1049 \item[\errcode{ENOMEM}] Non c'è memoria o si è superato il limite sul
1050 numero di mappature possibili.
1051 \item[\errcode{ENODEV}] Il filesystem di \param{fd} non supporta il memory
1057 La funzione richiede di mappare in memoria la sezione del file \param{fd} a
1058 partire da \param{offset} per \param{lenght} byte, preferibilmente
1059 all'indirizzo \param{start}. Il valore di \param{offset} deve essere un
1060 multiplo della dimensione di una pagina di memoria.
1066 \begin{tabular}[c]{|l|l|}
1068 \textbf{Valore} & \textbf{Significato} \\
1071 \const{PROT\_EXEC} & Le pagine possono essere eseguite.\\
1072 \const{PROT\_READ} & Le pagine possono essere lette.\\
1073 \const{PROT\_WRITE} & Le pagine possono essere scritte.\\
1074 \const{PROT\_NONE} & L'accesso alle pagine è vietato.\\
1077 \caption{Valori dell'argomento \param{prot} di \func{mmap}, relativi alla
1078 protezione applicate alle pagine del file mappate in memoria.}
1079 \label{tab:file_mmap_prot}
1083 Il valore dell'argomento \param{prot} indica la protezione\footnote{in Linux
1084 la memoria reale è divisa in pagine: ogni processo vede la sua memoria
1085 attraverso uno o più segmenti lineari di memoria virtuale. Per ciascuno di
1086 questi segmenti il kernel mantiene nella \textit{page table} la mappatura
1087 sulle pagine di memoria reale, ed le modalità di accesso (lettura,
1088 esecuzione, scrittura); una loro violazione causa quella che si chiama una
1089 \textit{segment violation}, e la relativa emissione del segnale
1090 \const{SIGSEGV}.} da applicare al segmento di memoria e deve essere
1091 specificato come maschera binaria ottenuta dall'OR di uno o più dei valori
1092 riportati in tab.~\ref{tab:file_mmap_flag}; il valore specificato deve essere
1093 compatibile con la modalità di accesso con cui si è aperto il file.
1095 L'argomento \param{flags} specifica infine qual'è il tipo di oggetto mappato,
1096 le opzioni relative alle modalità con cui è effettuata la mappatura e alle
1097 modalità con cui le modifiche alla memoria mappata vengono condivise o
1098 mantenute private al processo che le ha effettuate. Deve essere specificato
1099 come maschera binaria ottenuta dall'OR di uno o più dei valori riportati in
1100 tab.~\ref{tab:file_mmap_flag}.
1105 \begin{tabular}[c]{|l|p{10cm}|}
1107 \textbf{Valore} & \textbf{Significato} \\
1110 \const{MAP\_FIXED} & Non permette di restituire un indirizzo diverso
1111 da \param{start}, se questo non può essere usato
1112 \func{mmap} fallisce. Se si imposta questo flag il
1113 valore di \param{start} deve essere allineato
1114 alle dimensioni di una pagina. \\
1115 \const{MAP\_SHARED} & I cambiamenti sulla memoria mappata vengono
1116 riportati sul file e saranno immediatamente
1117 visibili agli altri processi che mappano lo stesso
1118 file.\footnotemark Il file su disco però non sarà
1119 aggiornato fino alla chiamata di \func{msync} o
1120 \func{unmap}), e solo allora le modifiche saranno
1121 visibili per l'I/O convenzionale. Incompatibile
1122 con \const{MAP\_PRIVATE}. \\
1123 \const{MAP\_PRIVATE} & I cambiamenti sulla memoria mappata non vengono
1124 riportati sul file. Ne viene fatta una copia
1125 privata cui solo il processo chiamante ha
1126 accesso. Le modifiche sono mantenute attraverso
1128 \textit{copy on write}\index{copy on write} e
1129 salvate su swap in caso di necessità. Non è
1130 specificato se i cambiamenti sul file originale
1131 vengano riportati sulla regione
1132 mappata. Incompatibile con \const{MAP\_SHARED}. \\
1133 \const{MAP\_DENYWRITE} & In Linux viene ignorato per evitare
1134 \textit{DoS}\index{DoS} (veniva usato per
1135 segnalare che tentativi di scrittura sul file
1136 dovevano fallire con \errcode{ETXTBSY}).\\
1137 \const{MAP\_EXECUTABLE}& Ignorato. \\
1138 \const{MAP\_NORESERVE} & Si usa con \const{MAP\_PRIVATE}. Non riserva
1139 delle pagine di swap ad uso del meccanismo di
1140 \textit{copy on write}\index{copy on write}
1142 modifiche fatte alla regione mappata, in
1143 questo caso dopo una scrittura, se non c'è più
1144 memoria disponibile, si ha l'emissione di
1145 un \const{SIGSEGV}. \\
1146 \const{MAP\_LOCKED} & Se impostato impedisce lo swapping delle pagine
1148 \const{MAP\_GROWSDOWN} & Usato per gli stack. Indica
1149 che la mappatura deve essere effettuata con gli
1150 indirizzi crescenti verso il basso.\\
1151 \const{MAP\_ANONYMOUS} & La mappatura non è associata a nessun file. Gli
1152 argomenti \param{fd} e \param{offset} sono
1153 ignorati.\footnotemark\\
1154 \const{MAP\_ANON} & Sinonimo di \const{MAP\_ANONYMOUS}, deprecato.\\
1155 \const{MAP\_FILE} & Valore di compatibilità, deprecato.\\
1158 \caption{Valori possibili dell'argomento \param{flag} di \func{mmap}.}
1159 \label{tab:file_mmap_flag}
1162 \footnotetext{Dato che tutti faranno riferimento alle stesse pagine di
1164 \footnotetext{L'uso di questo flag con \const{MAP\_SHARED} è
1165 stato implementato in Linux a partire dai kernel della serie 2.4.x.}
1167 Gli effetti dell'accesso ad una zona di memoria mappata su file possono essere
1168 piuttosto complessi, essi si possono comprendere solo tenendo presente che
1169 tutto quanto è comunque basato sul basato sul meccanismo della memoria
1170 virtuale.\index{memoria virtuale} Questo comporta allora una serie di
1171 conseguenze. La più ovvia è che se si cerca di scrivere su una zona mappata in
1172 sola lettura si avrà l'emissione di un segnale di violazione di accesso
1173 (\const{SIGSEGV}), dato che i permessi sul segmento di memoria relativo non
1174 consentono questo tipo di accesso.
1176 \begin{figure}[!htb]
1178 \includegraphics[width=10cm]{img/mmap_boundary}
1179 \caption{Schema della mappatura in memoria di una sezione di file di
1180 dimensioni non corrispondenti al bordo di una pagina.}
1181 \label{fig:file_mmap_boundary}
1184 È invece assai diversa la questione relativa agli accessi al di fuori della
1185 regione di cui si è richiesta la mappatura. A prima vista infatti si potrebbe
1186 ritenere che anch'essi debbano generare un segnale di violazione di accesso;
1187 questo però non tiene conto del fatto che, essendo basata sul meccanismo della
1188 paginazione\index{paginazione}, la mappatura in memoria non può che essere
1189 eseguita su un segmento di dimensioni rigorosamente multiple di quelle di una
1190 pagina, ed in generale queste potranno non corrispondere alle dimensioni
1191 effettive del file o della sezione che si vuole mappare. Il caso più comune è
1192 quello illustrato in fig.~\ref{fig:file_mmap_boundary}, in cui la sezione di
1193 file non rientra nei confini di una pagina: in tal caso verrà il file sarà
1194 mappato su un segmento di memoria che si estende fino al bordo della pagina
1197 In questo caso è possibile accedere a quella zona di memoria che eccede le
1198 dimensioni specificate da \param{lenght}, senza ottenere un \const{SIGSEGV}
1199 poiché essa è presente nello spazio di indirizzi del processo, anche se non è
1200 mappata sul file. Il comportamento del sistema è quello di restituire un
1201 valore nullo per quanto viene letto, e di non riportare su file quanto viene
1204 Un caso più complesso è quello che si viene a creare quando le dimensioni del
1205 file mappato sono più corte delle dimensioni della mappatura, oppure quando il
1206 file è stato troncato, dopo che è stato mappato, ad una dimensione inferiore a
1207 quella della mappatura in memoria.
1211 \includegraphics[width=10cm]{img/mmap_exceed}
1212 \caption{Schema della mappatura in memoria di file di dimensioni inferiori
1213 alla lunghezza richiesta.}
1214 \label{fig:file_mmap_exceed}
1217 In questa situazione, per la sezione di pagina parzialmente coperta dal
1218 contenuto del file, vale esattamente quanto visto in precedenza; invece per la
1219 parte che eccede, fino alle dimensioni date da \param{length}, l'accesso non
1220 sarà più possibile, ma il segnale emesso non sarà \const{SIGSEGV}, ma
1221 \const{SIGBUS}, come illustrato in fig.~\ref{fig:file_mmap_exceed}.
1223 Non tutti i file possono venire mappati in memoria, dato che, come illustrato
1224 in fig.~\ref{fig:file_mmap_layout}, la mappatura introduce una corrispondenza
1225 biunivoca fra una sezione di un file ed una sezione di memoria. Questo
1226 comporta che ad esempio non è possibile mappare in memoria file descriptor
1227 relativi a pipe, socket e fifo, per i quali non ha senso parlare di
1228 \textsl{sezione}. Lo stesso vale anche per alcuni file di dispositivo, che non
1229 dispongono della relativa operazione \func{mmap} (si ricordi quanto esposto in
1230 sez.~\ref{sec:file_vfs_work}). Si tenga presente però che esistono anche casi
1231 di dispositivi (un esempio è l'interfaccia al ponte PCI-VME del chip Universe)
1232 che sono utilizzabili solo con questa interfaccia.
1234 Dato che passando attraverso una \func{fork} lo spazio di indirizzi viene
1235 copiato integralmente, i file mappati in memoria verranno ereditati in maniera
1236 trasparente dal processo figlio, mantenendo gli stessi attributi avuti nel
1237 padre; così se si è usato \const{MAP\_SHARED} padre e figlio accederanno allo
1238 stesso file in maniera condivisa, mentre se si è usato \const{MAP\_PRIVATE}
1239 ciascuno di essi manterrà una sua versione privata indipendente. Non c'è
1240 invece nessun passaggio attraverso una \func{exec}, dato che quest'ultima
1241 sostituisce tutto lo spazio degli indirizzi di un processo con quello di un
1244 Quando si effettua la mappatura di un file vengono pure modificati i tempi ad
1245 esso associati (di cui si è trattato in sez.~\ref{sec:file_file_times}). Il
1246 valore di \var{st\_atime} può venir cambiato in qualunque istante a partire
1247 dal momento in cui la mappatura è stata effettuata: il primo riferimento ad
1248 una pagina mappata su un file aggiorna questo tempo. I valori di
1249 \var{st\_ctime} e \var{st\_mtime} possono venir cambiati solo quando si è
1250 consentita la scrittura sul file (cioè per un file mappato con
1251 \const{PROT\_WRITE} e \const{MAP\_SHARED}) e sono aggiornati dopo la scrittura
1252 o in corrispondenza di una eventuale \func{msync}.
1254 Dato per i file mappati in memoria le operazioni di I/O sono gestite
1255 direttamente dalla memoria virtuale, occorre essere consapevoli delle
1256 interazioni che possono esserci con operazioni effettuate con l'interfaccia
1257 standard dei file di cap.~\ref{cha:file_unix_interface}. Il problema è che una
1258 volta che si è mappato un file, le operazioni di lettura e scrittura saranno
1259 eseguite sulla memoria, e riportate su disco in maniera autonoma dal sistema
1260 della memoria virtuale.
1262 Pertanto se si modifica un file con l'interfaccia standard queste modifiche
1263 potranno essere visibili o meno a seconda del momento in cui la memoria
1264 virtuale trasporterà dal disco in memoria quella sezione del file, perciò è
1265 del tutto imprevedibile il risultato della modifica di un file nei confronti
1266 del contenuto della memoria su cui è mappato.
1268 Per questo, è sempre sconsigliabile eseguire scritture su file attraverso
1269 l'interfaccia standard, quando lo si è mappato in memoria, è invece possibile
1270 usare l'interfaccia standard per leggere un file mappato in memoria, purché si
1271 abbia una certa cura; infatti l'interfaccia dell'I/O mappato in memoria mette
1272 a disposizione la funzione \funcd{msync} per sincronizzare il contenuto della
1273 memoria mappata con il file su disco; il suo prototipo è:
1276 \headdecl{sys/mman.h}
1278 \funcdecl{int msync(const void *start, size\_t length, int flags)}
1280 Sincronizza i contenuti di una sezione di un file mappato in memoria.
1282 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
1283 errore nel qual caso \var{errno} assumerà uno dei valori:
1285 \item[\errcode{EINVAL}] O \param{start} non è multiplo di \const{PAGESIZE},
1286 o si è specificato un valore non valido per \param{flags}.
1287 \item[\errcode{EFAULT}] L'intervallo specificato non ricade in una zona
1288 precedentemente mappata.
1293 La funzione esegue la sincronizzazione di quanto scritto nella sezione di
1294 memoria indicata da \param{start} e \param{offset}, scrivendo le modifiche sul
1295 file (qualora questo non sia già stato fatto). Provvede anche ad aggiornare i
1296 relativi tempi di modifica. In questo modo si è sicuri che dopo l'esecuzione
1297 di \func{msync} le funzioni dell'interfaccia standard troveranno un contenuto
1298 del file aggiornato.
1303 \begin{tabular}[c]{|l|l|}
1305 \textbf{Valore} & \textbf{Significato} \\
1308 \const{MS\_ASYNC} & Richiede la sincronizzazione.\\
1309 \const{MS\_SYNC} & Attende che la sincronizzazione si eseguita.\\
1310 \const{MS\_INVALIDATE}& Richiede che le altre mappature dello stesso file
1314 \caption{Valori dell'argomento \param{flag} di \func{msync}.}
1315 \label{tab:file_mmap_rsync}
1318 L'argomento \param{flag} è specificato come maschera binaria composta da un OR
1319 dei valori riportati in tab.~\ref{tab:file_mmap_rsync}, di questi però
1320 \const{MS\_ASYNC} e \const{MS\_SYNC} sono incompatibili; con il primo valore
1321 infatti la funzione si limita ad inoltrare la richiesta di sincronizzazione al
1322 meccanismo della memoria virtuale, ritornando subito, mentre con il secondo
1323 attende che la sincronizzazione sia stata effettivamente eseguita. Il terzo
1324 flag fa invalidare le pagine di cui si richiede la sincronizzazione per tutte
1325 le mappature dello stesso file, così che esse possano essere immediatamente
1326 aggiornate ai nuovi valori.
1328 Una volta che si sono completate le operazioni di I/O si può eliminare la
1329 mappatura della memoria usando la funzione \funcd{munmap}, il suo prototipo è:
1332 \headdecl{sys/mman.h}
1334 \funcdecl{int munmap(void *start, size\_t length)}
1336 Rilascia la mappatura sulla sezione di memoria specificata.
1338 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
1339 errore nel qual caso \var{errno} assumerà uno dei valori:
1341 \item[\errcode{EINVAL}] L'intervallo specificato non ricade in una zona
1342 precedentemente mappata.
1347 La funzione cancella la mappatura per l'intervallo specificato attraverso
1348 \param{start} e \param{length}, ed ogni successivo accesso a tale regione
1349 causerà un errore di accesso in memoria. L'argomento \param{start} deve essere
1350 allineato alle dimensioni di una pagina di memoria, e la mappatura di tutte le
1351 pagine contenute (anche parzialmente) nell'intervallo indicato, verrà rimossa.
1352 Indicare un intervallo che non contiene pagine mappate non è un errore.
1354 Alla conclusione del processo, ogni pagina mappata verrà automaticamente
1355 rilasciata, mentre la chiusura del file descriptor usato per effettuare la
1356 mappatura in memoria non ha alcun effetto sulla stessa.
1359 \section{Il file locking}
1360 \label{sec:file_locking}
1362 \index{file!locking|(}
1363 In sez.~\ref{sec:file_sharing} abbiamo preso in esame le modalità in cui un
1364 sistema unix-like gestisce la condivisione dei file da parte di processi
1365 diversi. In quell'occasione si è visto come, con l'eccezione dei file aperti
1366 in \textit{append mode}, quando più processi scrivono contemporaneamente sullo
1367 stesso file non è possibile determinare la sequenza in cui essi opereranno.
1369 Questo causa la possibilità di race condition\index{race condition}; in
1370 generale le situazioni più comuni sono due: l'interazione fra un processo che
1371 scrive e altri che leggono, in cui questi ultimi possono leggere informazioni
1372 scritte solo in maniera parziale o incompleta; o quella in cui diversi
1373 processi scrivono, mescolando in maniera imprevedibile il loro output sul
1376 In tutti questi casi il \textit{file locking} è la tecnica che permette di
1377 evitare le race condition\index{race condition}, attraverso una serie di
1378 funzioni che permettono di bloccare l'accesso al file da parte di altri
1379 processi, così da evitare le sovrapposizioni, e garantire la atomicità delle
1380 operazioni di scrittura.
1384 \subsection{L'\textit{advisory locking}}
1385 \label{sec:file_record_locking}
1387 La prima modalità di \textit{file locking} che è stata implementata nei
1388 sistemi unix-like è quella che viene usualmente chiamata \textit{advisory
1389 locking},\footnote{Stevens in \cite{APUE} fa riferimento a questo argomento
1390 come al \textit{record locking}, dizione utilizzata anche dal manuale delle
1391 \acr{glibc}; nelle pagine di manuale si parla di \textit{discretionary file
1392 lock} per \func{fcntl} e di \textit{advisory locking} per \func{flock},
1393 mentre questo nome viene usato da Stevens per riferirsi al \textit{file
1394 locking} POSIX. Dato che la dizione \textit{record locking} è quantomeno
1395 ambigua, in quanto in un sistema Unix non esiste niente che possa fare
1396 riferimento al concetto di \textit{record}, alla fine si è scelto di
1397 mantenere il nome \textit{advisory locking}.} in quanto sono i singoli
1398 processi, e non il sistema, che si incaricano di asserire e verificare se
1399 esistono delle condizioni di blocco per l'accesso ai file. Questo significa
1400 che le funzioni \func{read} o \func{write} vengono eseguite comunque e non
1401 risentono affatto della presenza di un eventuale \textit{lock}; pertanto è
1402 sempre compito dei vari processi che intendono usare il file locking,
1403 controllare esplicitamente lo stato dei file condivisi prima di accedervi,
1404 utilizzando le relative funzioni.
1406 In generale si distinguono due tipologie di \textit{file lock}:\footnote{di
1407 seguito ci riferiremo sempre ai blocchi di accesso ai file con la
1408 nomenclatura inglese di \textit{file lock}, o più brevemente con
1409 \textit{lock}, per evitare confusioni linguistiche con il blocco di un
1410 processo (cioè la condizione in cui il processo viene posto in stato di
1411 \textit{sleep}).} la prima è il cosiddetto \textit{shared lock}, detto anche
1412 \textit{read lock} in quanto serve a bloccare l'accesso in scrittura su un
1413 file affinché il suo contenuto non venga modificato mentre lo si legge. Si
1414 parla appunto di \textsl{blocco condiviso} in quanto più processi possono
1415 richiedere contemporaneamente uno \textit{shared lock} su un file per
1416 proteggere il loro accesso in lettura.
1418 La seconda tipologia è il cosiddetto \textit{exclusive lock}, detto anche
1419 \textit{write lock} in quanto serve a bloccare l'accesso su un file (sia in
1420 lettura che in scrittura) da parte di altri processi mentre lo si sta
1421 scrivendo. Si parla di \textsl{blocco esclusivo} appunto perché un solo
1422 processo alla volta può richiedere un \textit{exclusive lock} su un file per
1423 proteggere il suo accesso in scrittura.
1428 \begin{tabular}[c]{|l|c|c|c|}
1430 \textbf{Richiesta} & \multicolumn{3}{|c|}{\textbf{Stato del file}}\\
1432 &Nessun lock&\textit{Read lock}&\textit{Write lock}\\
1435 \textit{Read lock} & SI & SI & NO \\
1436 \textit{Write lock}& SI & NO & NO \\
1439 \caption{Tipologie di file locking.}
1440 \label{tab:file_file_lock}
1443 In Linux sono disponibili due interfacce per utilizzare l'\textit{advisory
1444 locking}, la prima è quella derivata da BSD, che è basata sulla funzione
1445 \func{flock}, la seconda è quella standardizzata da POSIX.1 (derivata da
1446 System V), che è basata sulla funzione \func{fcntl}. I \textit{file lock}
1447 sono implementati in maniera completamente indipendente nelle due interfacce,
1448 che pertanto possono coesistere senza interferenze.
1450 Entrambe le interfacce prevedono la stessa procedura di funzionamento: si
1451 inizia sempre con il richiedere l'opportuno \textit{file lock} (un
1452 \textit{exclusive lock} per una scrittura, uno \textit{shared lock} per una
1453 lettura) prima di eseguire l'accesso ad un file. Se il lock viene acquisito
1454 il processo prosegue l'esecuzione, altrimenti (a meno di non aver richiesto un
1455 comportamento non bloccante) viene posto in stato di sleep. Una volta finite
1456 le operazioni sul file si deve provvedere a rimuovere il lock. La situazione
1457 delle varie possibilità è riassunta in tab.~\ref{tab:file_file_lock}, dove si
1458 sono riportati, per le varie tipologie di lock presenti su un file, il
1459 risultato che si ha in corrispondenza alle due tipologie di \textit{file lock}
1460 menzionate, nel successo della richiesta.
1462 Si tenga presente infine che il controllo di accesso e la gestione dei
1463 permessi viene effettuata quando si apre un file, l'unico controllo residuo
1464 che si può avere riguardo il \textit{file locking} è che il tipo di lock che
1465 si vuole ottenere su un file deve essere compatibile con le modalità di
1466 apertura dello stesso (in lettura per un read lock e in scrittura per un write
1470 %% la condizione per acquisire uno \textit{shared lock} è che il file non abbia
1471 %% già un \textit{exclusive lock} attivo, mentre per acquisire un
1472 %% \textit{exclusive lock} non deve essere presente nessun tipo di blocco.
1475 \subsection{La funzione \func{flock}}
1476 \label{sec:file_flock}
1478 La prima interfaccia per il file locking, quella derivata da BSD, permette di
1479 eseguire un blocco solo su un intero file; la funzione usata per richiedere e
1480 rimuovere un \textit{file lock} è \funcd{flock}, ed il suo prototipo è:
1481 \begin{prototype}{sys/file.h}{int flock(int fd, int operation)}
1483 Applica o rimuove un \textit{file lock} sul file \param{fd}.
1485 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
1486 errore, nel qual caso \var{errno} assumerà uno dei valori:
1488 \item[\errcode{EWOULDBLOCK}] Il file ha già un blocco attivo, e si è
1489 specificato \const{LOCK\_NB}.
1494 La funzione può essere usata per acquisire o rilasciare un \textit{file lock}
1495 a seconda di quanto specificato tramite il valore dell'argomento
1496 \param{operation}, questo viene interpretato come maschera binaria, e deve
1497 essere passato utilizzando le costanti riportate in
1498 tab.~\ref{tab:file_flock_operation}.
1503 \begin{tabular}[c]{|l|l|}
1505 \textbf{Valore} & \textbf{Significato} \\
1508 \const{LOCK\_SH} & Asserisce uno \textit{shared lock} sul file.\\
1509 \const{LOCK\_EX} & Asserisce un \textit{esclusive lock} sul file.\\
1510 \const{LOCK\_UN} & Rilascia il \textit{file lock}.\\
1511 \const{LOCK\_NB} & Impedisce che la funzione si blocchi nella
1512 richiesta di un \textit{file lock}.\\
1515 \caption{Valori dell'argomento \param{operation} di \func{flock}.}
1516 \label{tab:file_flock_operation}
1519 I primi due valori, \const{LOCK\_SH} e \const{LOCK\_EX} permettono di
1520 richiedere un \textit{file lock}, ed ovviamente devono essere usati in maniera
1521 alternativa. Se si specifica anche \const{LOCK\_NB} la funzione non si
1522 bloccherà qualora il lock non possa essere acquisito, ma ritornerà subito con
1523 un errore di \errcode{EWOULDBLOCK}. Per rilasciare un lock si dovrà invece
1524 usare \const{LOCK\_UN}.
1526 La semantica del file locking di BSD è diversa da quella del file locking
1527 POSIX, in particolare per quanto riguarda il comportamento dei lock nei
1528 confronti delle due funzioni \func{dup} e \func{fork}. Per capire queste
1529 differenze occorre descrivere con maggiore dettaglio come viene realizzato il
1530 file locking nel kernel in entrambe le interfacce.
1532 In fig.~\ref{fig:file_flock_struct} si è riportato uno schema essenziale
1533 dell'implementazione del file locking in stile BSD in Linux; il punto
1534 fondamentale da capire è che un lock, qualunque sia l'interfaccia che si usa,
1535 anche se richiesto attraverso un file descriptor, agisce sempre su un file;
1536 perciò le informazioni relative agli eventuali \textit{file lock} sono
1537 mantenute a livello di inode\index{inode},\footnote{in particolare, come
1538 accennato in fig.~\ref{fig:file_flock_struct}, i \textit{file lock} sono
1539 mantenuti un una \textit{linked list}\index{linked list} di strutture
1540 \struct{file\_lock}. La lista è referenziata dall'indirizzo di partenza
1541 mantenuto dal campo \var{i\_flock} della struttura \struct{inode} (per le
1542 definizioni esatte si faccia riferimento al file \file{fs.h} nei sorgenti
1543 del kernel). Un bit del campo \var{fl\_flags} di specifica se si tratta di
1544 un lock in semantica BSD (\const{FL\_FLOCK}) o POSIX (\const{FL\_POSIX}).}
1545 dato che questo è l'unico riferimento in comune che possono avere due processi
1546 diversi che aprono lo stesso file.
1550 \includegraphics[width=14cm]{img/file_flock}
1551 \caption{Schema dell'architettura del file locking, nel caso particolare
1552 del suo utilizzo da parte dalla funzione \func{flock}.}
1553 \label{fig:file_flock_struct}
1556 La richiesta di un file lock prevede una scansione della lista per determinare
1557 se l'acquisizione è possibile, ed in caso positivo l'aggiunta di un nuovo
1558 elemento.\footnote{cioè una nuova struttura \struct{file\_lock}.} Nel caso
1559 dei lock creati con \func{flock} la semantica della funzione prevede che sia
1560 \func{dup} che \func{fork} non creino ulteriori istanze di un file lock quanto
1561 piuttosto degli ulteriori riferimenti allo stesso. Questo viene realizzato dal
1562 kernel secondo lo schema di fig.~\ref{fig:file_flock_struct}, associando ad
1563 ogni nuovo \textit{file lock} un puntatore\footnote{il puntatore è mantenuto
1564 nel campo \var{fl\_file} di \struct{file\_lock}, e viene utilizzato solo per
1565 i lock creati con la semantica BSD.} alla voce nella \textit{file table} da
1566 cui si è richiesto il lock, che così ne identifica il titolare.
1568 Questa struttura prevede che, quando si richiede la rimozione di un file lock,
1569 il kernel acconsenta solo se la richiesta proviene da un file descriptor che
1570 fa riferimento ad una voce nella file table corrispondente a quella registrata
1571 nel lock. Allora se ricordiamo quanto visto in sez.~\ref{sec:file_dup} e
1572 sez.~\ref{sec:file_sharing}, e cioè che i file descriptor duplicati e quelli
1573 ereditati in un processo figlio puntano sempre alla stessa voce nella file
1574 table, si può capire immediatamente quali sono le conseguenze nei confronti
1575 delle funzioni \func{dup} e \func{fork}.
1577 Sarà così possibile rimuovere un file lock attraverso uno qualunque dei file
1578 descriptor che fanno riferimento alla stessa voce nella file table, anche se
1579 questo è diverso da quello con cui lo si è creato,\footnote{attenzione, questo
1580 non vale se il file descriptor fa riferimento allo stesso file, ma
1581 attraverso una voce diversa della file table, come accade tutte le volte che
1582 si apre più volte lo stesso file.} o se si esegue la rimozione in un
1583 processo figlio; inoltre una volta tolto un file lock, la rimozione avrà
1584 effetto su tutti i file descriptor che condividono la stessa voce nella file
1585 table, e quindi, nel caso di file descriptor ereditati attraverso una
1586 \func{fork}, anche su processi diversi.
1588 Infine, per evitare che la terminazione imprevista di un processo lasci attivi
1589 dei file lock, quando un file viene chiuso il kernel provveda anche a
1590 rimuovere tutti i lock ad esso associati. Anche in questo caso occorre tenere
1591 presente cosa succede quando si hanno file descriptor duplicati; in tal caso
1592 infatti il file non verrà effettivamente chiuso (ed il lock rimosso) fintanto
1593 che non viene rilasciata la relativa voce nella file table; e questo avverrà
1594 solo quando tutti i file descriptor che fanno riferimento alla stessa voce
1595 sono stati chiusi. Quindi, nel caso ci siano duplicati o processi figli che
1596 mantengono ancora aperto un file descriptor, il lock non viene rilasciato.
1598 Si tenga presente infine che \func{flock} non è in grado di funzionare per i
1599 file mantenuti su NFS, in questo caso, se si ha la necessità di eseguire il
1600 \textit{file locking}, occorre usare l'interfaccia basata su \func{fcntl} che
1601 può funzionare anche attraverso NFS, a condizione che sia il client che il
1602 server supportino questa funzionalità.
1605 \subsection{Il file locking POSIX}
1606 \label{sec:file_posix_lock}
1608 La seconda interfaccia per l'\textit{advisory locking} disponibile in Linux è
1609 quella standardizzata da POSIX, basata sulla funzione \func{fcntl}. Abbiamo
1610 già trattato questa funzione nelle sue molteplici possibilità di utilizzo in
1611 sez.~\ref{sec:file_fcntl}. Quando la si impiega per il \textit{file locking}
1612 essa viene usata solo secondo il prototipo:
1613 \begin{prototype}{fcntl.h}{int fcntl(int fd, int cmd, struct flock *lock)}
1615 Applica o rimuove un \textit{file lock} sul file \param{fd}.
1617 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
1618 errore, nel qual caso \var{errno} assumerà uno dei valori:
1620 \item[\errcode{EACCES}] L'operazione è proibita per la presenza di
1621 \textit{file lock} da parte di altri processi.
1622 \item[\errcode{ENOLCK}] Il sistema non ha le risorse per il locking: ci
1623 sono troppi segmenti di lock aperti, si è esaurita la tabella dei lock,
1624 o il protocollo per il locking remoto è fallito.
1625 \item[\errcode{EDEADLK}] Si è richiesto un lock su una regione bloccata da
1626 un altro processo che è a sua volta in attesa dello sblocco di un lock
1627 mantenuto dal processo corrente; si avrebbe pertanto un
1628 \textit{deadlock}\index{deadlock}. Non è garantito che il sistema
1629 riconosca sempre questa situazione.
1630 \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale prima
1631 di poter acquisire un lock.
1633 ed inoltre \errval{EBADF}, \errval{EFAULT}.
1637 Al contrario di quanto avviene con l'interfaccia basata su \func{flock} con
1638 \func{fcntl} è possibile bloccare anche delle singole sezioni di un file, fino
1639 al singolo byte. Inoltre la funzione permette di ottenere alcune informazioni
1640 relative agli eventuali lock preesistenti. Per poter fare tutto questo la
1641 funzione utilizza come terzo argomento una apposita struttura \struct{flock}
1642 (la cui definizione è riportata in fig.~\ref{fig:struct_flock}) nella quale
1643 inserire tutti i dati relativi ad un determinato lock. Si tenga presente poi
1644 che un lock fa sempre riferimento ad una regione, per cui si potrà avere un
1645 conflitto anche se c'è soltanto una sovrapposizione parziale con un'altra
1648 \begin{figure}[!bht]
1649 \footnotesize \centering
1650 \begin{minipage}[c]{15cm}
1651 \includestruct{listati/flock.h}
1654 \caption{La struttura \structd{flock}, usata da \func{fcntl} per il file
1656 \label{fig:struct_flock}
1660 I primi tre campi della struttura, \var{l\_whence}, \var{l\_start} e
1661 \var{l\_len}, servono a specificare la sezione del file a cui fa riferimento
1662 il lock: \var{l\_start} specifica il byte di partenza, \var{l\_len} la
1663 lunghezza della sezione e infine \var{l\_whence} imposta il riferimento da cui
1664 contare \var{l\_start}. Il valore di \var{l\_whence} segue la stessa semantica
1665 dell'omonimo argomento di \func{lseek}, coi tre possibili valori
1666 \const{SEEK\_SET}, \const{SEEK\_CUR} e \const{SEEK\_END}, (si vedano le
1667 relative descrizioni in sez.~\ref{sec:file_lseek}).
1669 Si tenga presente che un lock può essere richiesto anche per una regione al di
1670 là della corrente fine del file, così che una eventuale estensione dello
1671 stesso resti coperta dal blocco. Inoltre se si specifica un valore nullo per
1672 \var{l\_len} il blocco si considera esteso fino alla dimensione massima del
1673 file; in questo modo è possibile bloccare una qualunque regione a partire da
1674 un certo punto fino alla fine del file, coprendo automaticamente quanto
1675 eventualmente aggiunto in coda allo stesso.
1680 \begin{tabular}[c]{|l|l|}
1682 \textbf{Valore} & \textbf{Significato} \\
1685 \const{F\_RDLCK} & Richiede un blocco condiviso (\textit{read lock}).\\
1686 \const{F\_WRLCK} & Richiede un blocco esclusivo (\textit{write lock}).\\
1687 \const{F\_UNLCK} & Richiede l'eliminazione di un file lock.\\
1690 \caption{Valori possibili per il campo \var{l\_type} di \struct{flock}.}
1691 \label{tab:file_flock_type}
1694 Il tipo di file lock richiesto viene specificato dal campo \var{l\_type}, esso
1695 può assumere i tre valori definiti dalle costanti riportate in
1696 tab.~\ref{tab:file_flock_type}, che permettono di richiedere rispettivamente
1697 uno \textit{shared lock}, un \textit{esclusive lock}, e la rimozione di un
1698 lock precedentemente acquisito. Infine il campo \var{l\_pid} viene usato solo
1699 in caso di lettura, quando si chiama \func{fcntl} con \const{F\_GETLK}, e
1700 riporta il \acr{pid} del processo che detiene il lock.
1702 Oltre a quanto richiesto tramite i campi di \struct{flock}, l'operazione
1703 effettivamente svolta dalla funzione è stabilita dal valore dall'argomento
1704 \param{cmd} che, come già riportato in sez.~\ref{sec:file_fcntl}, specifica
1705 l'azione da compiere; i valori relativi al file locking sono tre:
1706 \begin{basedescript}{\desclabelwidth{2.0cm}}
1707 \item[\const{F\_GETLK}] verifica se il file lock specificato dalla struttura
1708 puntata da \param{lock} può essere acquisito: in caso negativo sovrascrive
1709 la struttura \param{flock} con i valori relativi al lock già esistente che
1710 ne blocca l'acquisizione, altrimenti si limita a impostarne il campo
1711 \var{l\_type} con il valore \const{F\_UNLCK}.
1712 \item[\const{F\_SETLK}] se il campo \var{l\_type} della struttura puntata da
1713 \param{lock} è \const{F\_RDLCK} o \const{F\_WRLCK} richiede il
1714 corrispondente file lock, se è \const{F\_UNLCK} lo rilascia. Nel caso la
1715 richiesta non possa essere soddisfatta a causa di un lock preesistente la
1716 funzione ritorna immediatamente con un errore di \errcode{EACCES} o di
1718 \item[\const{F\_SETLKW}] è identica a \const{F\_SETLK}, ma se la richiesta di
1719 non può essere soddisfatta per la presenza di un altro lock, mette il
1720 processo in stato di attesa fintanto che il lock precedente non viene
1721 rilasciato. Se l'attesa viene interrotta da un segnale la funzione ritorna
1722 con un errore di \errcode{EINTR}.
1725 Si noti che per quanto detto il comando \const{F\_GETLK} non serve a rilevare
1726 una presenza generica di lock su un file, perché se ne esistono altri
1727 compatibili con quello richiesto, la funzione ritorna comunque impostando
1728 \var{l\_type} a \const{F\_UNLCK}. Inoltre a seconda del valore di
1729 \var{l\_type} si potrà controllare o l'esistenza di un qualunque tipo di lock
1730 (se è \const{F\_WRLCK}) o di write lock (se è \const{F\_RDLCK}). Si consideri
1731 poi che può esserci più di un lock che impedisce l'acquisizione di quello
1732 richiesto (basta che le regioni si sovrappongano), ma la funzione ne riporterà
1733 sempre soltanto uno, impostando \var{l\_whence} a \const{SEEK\_SET} ed i
1734 valori \var{l\_start} e \var{l\_len} per indicare quale è la regione bloccata.
1736 Infine si tenga presente che effettuare un controllo con il comando
1737 \const{F\_GETLK} e poi tentare l'acquisizione con \const{F\_SETLK} non è una
1738 operazione atomica (un altro processo potrebbe acquisire un lock fra le due
1739 chiamate) per cui si deve sempre verificare il codice di ritorno di
1740 \func{fcntl}\footnote{controllare il codice di ritorno delle funzioni invocate
1741 è comunque una buona norma di programmazione, che permette di evitare un
1742 sacco di errori difficili da tracciare proprio perché non vengono rilevati.}
1743 quando la si invoca con \const{F\_SETLK}, per controllare che il lock sia
1744 stato effettivamente acquisito.
1747 \centering \includegraphics[width=9cm]{img/file_lock_dead}
1748 \caption{Schema di una situazione di \textit{deadlock}\index{deadlock}.}
1749 \label{fig:file_flock_dead}
1752 Non operando a livello di interi file, il file locking POSIX introduce
1753 un'ulteriore complicazione; consideriamo la situazione illustrata in
1754 fig.~\ref{fig:file_flock_dead}, in cui il processo A blocca la regione 1 e il
1755 processo B la regione 2. Supponiamo che successivamente il processo A richieda
1756 un lock sulla regione 2 che non può essere acquisito per il preesistente lock
1757 del processo 2; il processo 1 si bloccherà fintanto che il processo 2 non
1758 rilasci il blocco. Ma cosa accade se il processo 2 nel frattempo tenta a sua
1759 volta di ottenere un lock sulla regione A? Questa è una tipica situazione che
1760 porta ad un \textit{deadlock}\index{deadlock}, dato che a quel punto anche il
1761 processo 2 si bloccherebbe, e niente potrebbe sbloccare l'altro processo. Per
1762 questo motivo il kernel si incarica di rilevare situazioni di questo tipo, ed
1763 impedirle restituendo un errore di \errcode{EDEADLK} alla funzione che cerca
1764 di acquisire un lock che porterebbe ad un \textit{deadlock}.
1766 \begin{figure}[!bht]
1767 \centering \includegraphics[width=13cm]{img/file_posix_lock}
1768 \caption{Schema dell'architettura del file locking, nel caso particolare
1769 del suo utilizzo secondo l'interfaccia standard POSIX.}
1770 \label{fig:file_posix_lock}
1774 Per capire meglio il funzionamento del file locking in semantica POSIX (che
1775 differisce alquanto rispetto da quello di BSD, visto
1776 sez.~\ref{sec:file_flock}) esaminiamo più in dettaglio come viene gestito dal
1777 kernel. Lo schema delle strutture utilizzate è riportato in
1778 fig.~\ref{fig:file_posix_lock}; come si vede esso è molto simile all'analogo
1779 di fig.~\ref{fig:file_flock_struct}:\footnote{in questo caso nella figura si
1780 sono evidenziati solo i campi di \struct{file\_lock} significativi per la
1781 semantica POSIX, in particolare adesso ciascuna struttura contiene, oltre al
1782 \acr{pid} del processo in \var{fl\_pid}, la sezione di file che viene
1783 bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}. La struttura è
1784 comunque la stessa, solo che in questo caso nel campo \var{fl\_flags} è
1785 impostato il bit \const{FL\_POSIX} ed il campo \var{fl\_file} non viene
1786 usato.} il lock è sempre associato all'inode\index{inode}, solo che in
1787 questo caso la titolarità non viene identificata con il riferimento ad una
1788 voce nella file table, ma con il valore del \acr{pid} del processo.
1790 Quando si richiede un lock il kernel effettua una scansione di tutti i lock
1791 presenti sul file\footnote{scandisce cioè la linked list delle strutture
1792 \struct{file\_lock}, scartando automaticamente quelle per cui
1793 \var{fl\_flags} non è \const{FL\_POSIX}, così che le due interfacce restano
1794 ben separate.} per verificare se la regione richiesta non si sovrappone ad
1795 una già bloccata, in caso affermativo decide in base al tipo di lock, in caso
1796 negativo il nuovo lock viene comunque acquisito ed aggiunto alla lista.
1798 Nel caso di rimozione invece questa viene effettuata controllando che il
1799 \acr{pid} del processo richiedente corrisponda a quello contenuto nel lock.
1800 Questa diversa modalità ha delle conseguenze precise riguardo il comportamento
1801 dei lock POSIX. La prima conseguenza è che un lock POSIX non viene mai
1802 ereditato attraverso una \func{fork}, dato che il processo figlio avrà un
1803 \acr{pid} diverso, mentre passa indenne attraverso una \func{exec} in quanto
1804 il \acr{pid} resta lo stesso. Questo comporta che, al contrario di quanto
1805 avveniva con la semantica BSD, quando processo termina tutti i file lock da
1806 esso detenuti vengono immediatamente rilasciati.
1808 La seconda conseguenza è che qualunque file descriptor che faccia riferimento
1809 allo stesso file (che sia stato ottenuto con una \func{dup} o con una
1810 \func{open} in questo caso non fa differenza) può essere usato per rimuovere
1811 un lock, dato che quello che conta è solo il \acr{pid} del processo. Da questo
1812 deriva una ulteriore sottile differenza di comportamento: dato che alla
1813 chiusura di un file i lock ad esso associati vengono rimossi, nella semantica
1814 POSIX basterà chiudere un file descriptor qualunque per cancellare tutti i
1815 lock relativi al file cui esso faceva riferimento, anche se questi fossero
1816 stati creati usando altri file descriptor che restano aperti.
1818 Dato che il controllo sull'accesso ai lock viene eseguito sulla base del
1819 \acr{pid} del processo, possiamo anche prendere in considerazione un'altro
1820 degli aspetti meno chiari di questa interfaccia e cioè cosa succede quando si
1821 richiedono dei lock su regioni che si sovrappongono fra loro all'interno
1822 stesso processo. Siccome il controllo, come nel caso della rimozione, si basa
1823 solo sul \acr{pid} del processo che chiama la funzione, queste richieste
1824 avranno sempre successo.
1826 Nel caso della semantica BSD, essendo i lock relativi a tutto un file e non
1827 accumulandosi,\footnote{questa ultima caratteristica è vera in generale, se
1828 cioè si richiede più volte lo stesso file lock, o più lock sulla stessa
1829 sezione di file, le richieste non si cumulano e basta una sola richiesta di
1830 rilascio per cancellare il lock.} la cosa non ha alcun effetto; la funzione
1831 ritorna con successo, senza che il kernel debba modificare la lista dei lock.
1832 In questo caso invece si possono avere una serie di situazioni diverse: ad
1833 esempio è possibile rimuovere con una sola chiamata più lock distinti
1834 (indicando in una regione che si sovrapponga completamente a quelle di questi
1835 ultimi), o rimuovere solo una parte di un lock preesistente (indicando una
1836 regione contenuta in quella di un altro lock), creando un buco, o coprire con
1837 un nuovo lock altri lock già ottenuti, e così via, a secondo di come si
1838 sovrappongono le regioni richieste e del tipo di operazione richiesta. Il
1839 comportamento seguito in questo caso che la funzione ha successo ed esegue
1840 l'operazione richiesta sulla regione indicata; è compito del kernel
1841 preoccuparsi di accorpare o dividere le voci nella lista dei lock per far si
1842 che le regioni bloccate da essa risultanti siano coerenti con quanto
1843 necessario a soddisfare l'operazione richiesta.
1845 \begin{figure}[!htb]
1846 \footnotesize \centering
1847 \begin{minipage}[c]{15cm}
1848 \includecodesample{listati/Flock.c}
1851 \caption{Sezione principale del codice del programma \file{Flock.c}.}
1852 \label{fig:file_flock_code}
1855 Per fare qualche esempio sul file locking si è scritto un programma che
1856 permette di bloccare una sezione di un file usando la semantica POSIX, o un
1857 intero file usando la semantica BSD; in fig.~\ref{fig:file_flock_code} è
1858 riportata il corpo principale del codice del programma, (il testo completo è
1859 allegato nella directory dei sorgenti).
1861 La sezione relativa alla gestione delle opzioni al solito si è omessa, come la
1862 funzione che stampa le istruzioni per l'uso del programma, essa si cura di
1863 impostare le variabili \var{type}, \var{start} e \var{len}; queste ultime due
1864 vengono inizializzate al valore numerico fornito rispettivamente tramite gli
1865 switch \code{-s} e \cmd{-l}, mentre il valore della prima viene impostato con
1866 le opzioni \cmd{-w} e \cmd{-r} si richiede rispettivamente o un write lock o
1867 read lock (i due valori sono esclusivi, la variabile assumerà quello che si è
1868 specificato per ultimo). Oltre a queste tre vengono pure impostate la
1869 variabile \var{bsd}, che abilita la semantica omonima quando si invoca
1870 l'opzione \cmd{-f} (il valore preimpostato è nullo, ad indicare la semantica
1871 POSIX), e la variabile \var{cmd} che specifica la modalità di richiesta del
1872 lock (bloccante o meno), a seconda dell'opzione \cmd{-b}.
1874 Il programma inizia col controllare (\texttt{\small 11--14}) che venga passato
1875 un parametro (il file da bloccare), che sia stato scelto (\texttt{\small
1876 15--18}) il tipo di lock, dopo di che apre (\texttt{\small 19}) il file,
1877 uscendo (\texttt{\small 20--23}) in caso di errore. A questo punto il
1878 comportamento dipende dalla semantica scelta; nel caso sia BSD occorre
1879 reimpostare il valore di \var{cmd} per l'uso con \func{flock}; infatti il
1880 valore preimpostato fa riferimento alla semantica POSIX e vale rispettivamente
1881 \const{F\_SETLKW} o \const{F\_SETLK} a seconda che si sia impostato o meno la
1884 Nel caso si sia scelta la semantica BSD (\texttt{\small 25--34}) prima si
1885 controlla (\texttt{\small 27--31}) il valore di \var{cmd} per determinare se
1886 si vuole effettuare una chiamata bloccante o meno, reimpostandone il valore
1887 opportunamente, dopo di che a seconda del tipo di lock al valore viene
1888 aggiunta la relativa opzione (con un OR aritmetico, dato che \func{flock}
1889 vuole un argomento \param{operation} in forma di maschera binaria. Nel caso
1890 invece che si sia scelta la semantica POSIX le operazioni sono molto più
1891 immediate, si prepara (\texttt{\small 36--40}) la struttura per il lock, e lo
1892 esegue (\texttt{\small 41}).
1894 In entrambi i casi dopo aver richiesto il lock viene controllato il risultato
1895 uscendo (\texttt{\small 44--46}) in caso di errore, o stampando un messaggio
1896 (\texttt{\small 47--49}) in caso di successo. Infine il programma si pone in
1897 attesa (\texttt{\small 50}) finché un segnale (ad esempio un \cmd{C-c} dato da
1898 tastiera) non lo interrompa; in questo caso il programma termina, e tutti i
1899 lock vengono rilasciati.
1901 Con il programma possiamo fare varie verifiche sul funzionamento del file
1902 locking; cominciamo con l'eseguire un read lock su un file, ad esempio usando
1903 all'interno di un terminale il seguente comando:
1906 \begin{minipage}[c]{12cm}
1908 [piccardi@gont sources]$ ./flock -r Flock.c
1911 \end{minipage}\vspace{1mm}
1913 il programma segnalerà di aver acquisito un lock e si bloccherà; in questo
1914 caso si è usato il file locking POSIX e non avendo specificato niente riguardo
1915 alla sezione che si vuole bloccare sono stati usati i valori preimpostati che
1916 bloccano tutto il file. A questo punto se proviamo ad eseguire lo stesso
1917 comando in un altro terminale, e avremo lo stesso risultato. Se invece
1918 proviamo ad eseguire un write lock avremo:
1921 \begin{minipage}[c]{12cm}
1923 [piccardi@gont sources]$ ./flock -w Flock.c
1924 Failed lock: Resource temporarily unavailable
1926 \end{minipage}\vspace{1mm}
1928 come ci aspettiamo il programma terminerà segnalando l'indisponibilità del
1929 lock, dato che il file è bloccato dal precedente read lock. Si noti che il
1930 risultato è lo stesso anche se si richiede il blocco su una sola parte del
1931 file con il comando:
1934 \begin{minipage}[c]{12cm}
1936 [piccardi@gont sources]$ ./flock -w -s0 -l10 Flock.c
1937 Failed lock: Resource temporarily unavailable
1939 \end{minipage}\vspace{1mm}
1941 se invece blocchiamo una regione con:
1944 \begin{minipage}[c]{12cm}
1946 [piccardi@gont sources]$ ./flock -r -s0 -l10 Flock.c
1949 \end{minipage}\vspace{1mm}
1951 una volta che riproviamo ad acquisire il write lock i risultati dipenderanno
1952 dalla regione richiesta; ad esempio nel caso in cui le due regioni si
1953 sovrappongono avremo che:
1956 \begin{minipage}[c]{12cm}
1958 [piccardi@gont sources]$ ./flock -w -s5 -l15 Flock.c
1959 Failed lock: Resource temporarily unavailable
1961 \end{minipage}\vspace{1mm}
1963 ed il lock viene rifiutato, ma se invece si richiede una regione distinta
1967 \begin{minipage}[c]{12cm}
1969 [piccardi@gont sources]$ ./flock -w -s11 -l15 Flock.c
1972 \end{minipage}\vspace{1mm}
1974 ed il lock viene acquisito. Se a questo punto si prova ad eseguire un read
1975 lock che comprende la nuova regione bloccata in scrittura:
1978 \begin{minipage}[c]{12cm}
1980 [piccardi@gont sources]$ ./flock -r -s10 -l20 Flock.c
1981 Failed lock: Resource temporarily unavailable
1983 \end{minipage}\vspace{1mm}
1985 come ci aspettiamo questo non sarà consentito.
1987 Il programma di norma esegue il tentativo di acquisire il lock in modalità non
1988 bloccante, se però usiamo l'opzione \cmd{-b} possiamo impostare la modalità
1989 bloccante, riproviamo allora a ripetere le prove precedenti con questa
1993 \begin{minipage}[c]{12cm}
1995 [piccardi@gont sources]$ ./flock -r -b -s0 -l10 Flock.c Lock acquired
1997 \end{minipage}\vspace{1mm}
1999 il primo comando acquisisce subito un read lock, e quindi non cambia nulla, ma
2000 se proviamo adesso a richiedere un write lock che non potrà essere acquisito
2004 \begin{minipage}[c]{12cm}
2006 [piccardi@gont sources]$ ./flock -w -s0 -l10 Flock.c
2008 \end{minipage}\vspace{1mm}
2010 il programma cioè si bloccherà nella chiamata a \func{fcntl}; se a questo
2011 punto rilasciamo il precedente lock (terminando il primo comando un
2012 \texttt{C-c} sul terminale) potremo verificare che sull'altro terminale il
2013 lock viene acquisito, con la comparsa di una nuova riga:
2016 \begin{minipage}[c]{12cm}
2018 [piccardi@gont sources]$ ./flock -w -s0 -l10 Flock.c
2021 \end{minipage}\vspace{3mm}
2024 Un'altra cosa che si può controllare con il nostro programma è l'interazione
2025 fra i due tipi di lock; se ripartiamo dal primo comando con cui si è ottenuto
2026 un lock in lettura sull'intero file, possiamo verificare cosa succede quando
2027 si cerca di ottenere un lock in scrittura con la semantica BSD:
2030 \begin{minipage}[c]{12cm}
2032 [root@gont sources]# ./flock -f -w Flock.c
2035 \end{minipage}\vspace{1mm}
2037 che ci mostra come i due tipi di lock siano assolutamente indipendenti; per
2038 questo motivo occorre sempre tenere presente quale fra le due semantiche
2039 disponibili stanno usando i programmi con cui si interagisce, dato che i lock
2040 applicati con l'altra non avrebbero nessun effetto.
2044 \subsection{La funzione \func{lockf}}
2045 \label{sec:file_lockf}
2047 Abbiamo visto come l'interfaccia POSIX per il file locking sia molto più
2048 potente e flessibile di quella di BSD, questo comporta anche una maggiore
2049 complessità per via delle varie opzioni da passare a \func{fcntl}. Per questo
2050 motivo è disponibile anche una interfaccia semplificata (ripresa da System V)
2051 che utilizza la funzione \funcd{lockf}, il cui prototipo è:
2052 \begin{prototype}{sys/file.h}{int lockf(int fd, int cmd, off\_t len)}
2054 Applica, controlla o rimuove un \textit{file lock} sul file \param{fd}.
2056 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
2057 errore, nel qual caso \var{errno} assumerà uno dei valori:
2059 \item[\errcode{EWOULDBLOCK}] Non è possibile acquisire il lock, e si è
2060 selezionato \const{LOCK\_NB}, oppure l'operazione è proibita perché il
2061 file è mappato in memoria.
2062 \item[\errcode{ENOLCK}] Il sistema non ha le risorse per il locking: ci
2063 sono troppi segmenti di lock aperti, si è esaurita la tabella dei lock.
2065 ed inoltre \errval{EBADF}, \errval{EINVAL}.
2069 Il comportamento della funzione dipende dal valore dell'argomento \param{cmd},
2070 che specifica quale azione eseguire; i valori possibili sono riportati in
2071 tab.~\ref{tab:file_lockf_type}.
2076 \begin{tabular}[c]{|l|p{7cm}|}
2078 \textbf{Valore} & \textbf{Significato} \\
2081 \const{LOCK\_SH}& Richiede uno \textit{shared lock}. Più processi possono
2082 mantenere un lock condiviso sullo stesso file.\\
2083 \const{LOCK\_EX}& Richiede un \textit{exclusive lock}. Un solo processo
2084 alla volta può mantenere un lock esclusivo su un file. \\
2085 \const{LOCK\_UN}& Sblocca il file.\\
2086 \const{LOCK\_NB}& Non blocca la funzione quando il lock non è disponibile,
2087 si specifica sempre insieme ad una delle altre operazioni
2088 con un OR aritmetico dei valori.\\
2091 \caption{Valori possibili per l'argomento \param{cmd} di \func{lockf}.}
2092 \label{tab:file_lockf_type}
2095 Qualora il lock non possa essere acquisito, a meno di non aver specificato
2096 \const{LOCK\_NB}, la funzione si blocca fino alla disponibilità dello stesso.
2097 Dato che la funzione è implementata utilizzando \func{fcntl} la semantica
2098 delle operazioni è la stessa di quest'ultima (pertanto la funzione non è
2099 affatto equivalente a \func{flock}).
2103 \subsection{Il \textit{mandatory locking}}
2104 \label{sec:file_mand_locking}
2106 Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4,
2107 per introdurre un file locking che, come dice il nome, fosse effettivo
2108 indipendentemente dai controlli eseguiti da un processo. Con il
2109 \textit{mandatory locking} infatti è possibile far eseguire il blocco del file
2110 direttamente al sistema, così che, anche qualora non si predisponessero le
2111 opportune verifiche nei processi, questo verrebbe comunque rispettato.
2113 Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
2114 utilizzo particolare del bit \acr{sgid}. Se si ricorda quanto esposto in
2115 sez.~\ref{sec:file_suid_sgid}), esso viene di norma utilizzato per cambiare il
2116 group-ID effettivo con cui viene eseguito un programma, ed è pertanto sempre
2117 associato alla presenza del permesso di esecuzione per il gruppo. Impostando
2118 questo bit su un file senza permesso di esecuzione in un sistema che supporta
2119 il \textit{mandatory locking}, fa sì che quest'ultimo venga attivato per il
2120 file in questione. In questo modo una combinazione dei permessi
2121 originariamente non contemplata, in quanto senza significato, diventa
2122 l'indicazione della presenza o meno del \textit{mandatory
2123 locking}.\footnote{un lettore attento potrebbe ricordare quanto detto in
2124 sez.~\ref{sec:file_chmod} e cioè che il bit \acr{sgid} viene cancellato (come
2125 misura di sicurezza) quando di scrive su un file, questo non vale quando
2126 esso viene utilizzato per attivare il \textit{mandatory locking}.}
2128 L'uso del \textit{mandatory locking} presenta vari aspetti delicati, dato che
2129 neanche root può passare sopra ad un lock; pertanto un processo che blocchi un
2130 file cruciale può renderlo completamente inaccessibile, rendendo completamente
2131 inutilizzabile il sistema\footnote{il problema si potrebbe risolvere
2132 rimuovendo il bit \acr{sgid}, ma non è detto che sia così facile fare questa
2133 operazione con un sistema bloccato.} inoltre con il \textit{mandatory
2134 locking} si può bloccare completamente un server NFS richiedendo una lettura
2135 su un file su cui è attivo un lock. Per questo motivo l'abilitazione del
2136 mandatory locking è di norma disabilitata, e deve essere attivata filesystem
2137 per filesystem in fase di montaggio (specificando l'apposita opzione di
2138 \func{mount} riportata in tab.~\ref{tab:sys_mount_flags}, o con l'opzione
2139 \cmd{mand} per il comando).
2141 Si tenga presente inoltre che il \textit{mandatory locking} funziona solo
2142 sull'interfaccia POSIX di \func{fcntl}. Questo ha due conseguenze: che non si
2143 ha nessun effetto sui lock richiesti con l'interfaccia di \func{flock}, e che
2144 la granularità del lock è quella del singolo byte, come per \func{fcntl}.
2146 La sintassi di acquisizione dei lock è esattamente la stessa vista in
2147 precedenza per \func{fcntl} e \func{lockf}, la differenza è che in caso di
2148 mandatory lock attivato non è più necessario controllare la disponibilità di
2149 accesso al file, ma si potranno usare direttamente le ordinarie funzioni di
2150 lettura e scrittura e sarà compito del kernel gestire direttamente il file
2153 Questo significa che in caso di read lock la lettura dal file potrà avvenire
2154 normalmente con \func{read}, mentre una \func{write} si bloccherà fino al
2155 rilascio del lock, a meno di non aver aperto il file con \const{O\_NONBLOCK},
2156 nel qual caso essa ritornerà immediatamente con un errore di \errcode{EAGAIN}.
2158 Se invece si è acquisito un write lock tutti i tentativi di leggere o scrivere
2159 sulla regione del file bloccata fermeranno il processo fino al rilascio del
2160 lock, a meno che il file non sia stato aperto con \const{O\_NONBLOCK}, nel
2161 qual caso di nuovo si otterrà un ritorno immediato con l'errore di
2164 Infine occorre ricordare che le funzioni di lettura e scrittura non sono le
2165 sole ad operare sui contenuti di un file, e che sia \func{creat} che
2166 \func{open} (quando chiamata con \const{O\_TRUNC}) effettuano dei cambiamenti,
2167 così come \func{truncate}, riducendone le dimensioni (a zero nei primi due
2168 casi, a quanto specificato nel secondo). Queste operazioni sono assimilate a
2169 degli accessi in scrittura e pertanto non potranno essere eseguite (fallendo
2170 con un errore di \errcode{EAGAIN}) su un file su cui sia presente un qualunque
2171 lock (le prime due sempre, la terza solo nel caso che la riduzione delle
2172 dimensioni del file vada a sovrapporsi ad una regione bloccata).
2174 L'ultimo aspetto della interazione del \textit{mandatory locking} con le
2175 funzioni di accesso ai file è quello relativo ai file mappati in memoria (che
2176 abbiamo trattato in sez.~\ref{sec:file_memory_map}); anche in tal caso infatti,
2177 quando si esegue la mappatura con l'opzione \const{MAP\_SHARED}, si ha un
2178 accesso al contenuto del file. Lo standard SVID prevede che sia impossibile
2179 eseguire il memory mapping di un file su cui sono presenti dei
2180 lock\footnote{alcuni sistemi, come HP-UX, sono ancora più restrittivi e lo
2181 impediscono anche in caso di \textit{advisory locking}, anche se questo
2182 comportamento non ha molto senso, dato che comunque qualunque accesso
2183 diretto al file è consentito.} in Linux è stata però fatta la scelta
2184 implementativa\footnote{per i dettagli si possono leggere le note relative
2185 all'implementazione, mantenute insieme ai sorgenti del kernel nel file
2186 \file{Documentation/mandatory.txt}.} di seguire questo comportamento
2187 soltanto quando si chiama \func{mmap} con l'opzione \const{MAP\_SHARED} (nel
2188 qual caso la funzione fallisce con il solito \errcode{EAGAIN}) che comporta la
2189 possibilità di modificare il file.
2190 \index{file!locking|)}
2195 %%% Local Variables:
2197 %%% TeX-master: "gapil"