X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=454d91b237a8899888231001900ff6620f3c2a6e;hp=b27f34e1df8b11bf3d80a6494c00869723103b10;hb=7e77cdaacc8c84ecfeac4aa22977b7fa34741b5c;hpb=1639f660dadb609be0b033750075cab883bdd0b4 diff --git a/fileadv.tex b/fileadv.tex index b27f34e..454d91b 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -1,113 +1,1726 @@ -\chapter{I/O avanzato} +\chapter{La gestione avanzata dei file} \label{cha:file_advanced} -In questo capitolo affronteremo le tematiche della gestione avanzata delle -funzioni di input/ouput, prenderemo in esame il \textit{file locking}, la -gestione dell'input/output da più file, per concludere con la gestione dei -file mappati in memoria. +In questo capitolo affronteremo le tematiche relative alla gestione avanzata +dei file, che non sono state trattate in \capref{cha:file_unix_interface}, +dove ci si è limitati ad una panoramica delle funzioni base. In particolare +tratteremo delle funzioni di input/output avanzato e del \textit{file + locking}. -\section{L'I/O avanzato} +\section{Le funzioni di I/O avanzato} \label{sec:file_advanced_io} -Uno dei problemi che ci si trova ad affrontare con le funzioni ordinarie -trattate in \capref{cha:file_unix_interface} è quello in cui si devono -eseguire su più di un file descriptor delle operazioni che possono bloccarsi: -il problema è che mentre si è bloccati su un file un'altro potrebbe essere -libero. - -In questa sezione vedremo come si possono affrontare queste problematiche, -quali sono le soluzioni possibili e quali i meccanismi il kernel e le librerie -ci mettono a disposizione. +In questa sezione esamineremo le funzioni che permettono una gestione più +sofisticata dell'I/O su file, a partire da quelle che permettono di gestire +l'accesso contemporaneo a più file, per concludere con la gestione dell'I/O +mappato in memoria. \subsection{La modalità di I/O \textsl{non-bloccante}} \label{sec:file_noblocking} -Una prima soluzione per evitare di bloccarsi nelle operazioni di I/O è quella -di utilizzare la modalità \textsl{non-bloccante}. Abbiamo visto in -\secref{sec:sig_gen_beha}, affrontando la suddivisione fra \textit{fast} e -\textit{slow} system call, che in certi casi le funzioni di I/O possono -bloccarsi indefinitamente.\footnote{si ricordi però che questo può accadere - solo per le pipe, i socket ed alcuni file di dispositivo; sui file normali - le funzioni di lettura e scrittura ritornano sempre subito.} -In particolare le operazioni di lettura possono bloccarsi quando non ci sono -dati disponibili sul descrittore su cui si sta operando. +Abbiamo visto in \secref{sec:sig_gen_beha}, affrontando la suddivisione fra +\textit{fast} e \textit{slow} system call, che in certi casi le funzioni di +I/O possono bloccarsi indefinitamente.\footnote{si ricordi però che questo può + accadere solo per le pipe, i socket ed alcuni file di dispositivo; sui file + normali le funzioni di lettura e scrittura ritornano sempre subito.} Ad +esempio le operazioni di lettura possono bloccarsi quando non ci sono dati +disponibili sul descrittore su cui si sta operando. + +Questo comportamento causa uno dei problemi più comuni che ci si trova ad +affrontare nelle operazioni di I/O, che è quello che si verifica quando si +devono eseguire operazioni che possono bloccarsi su più file descriptor: +mentre si è bloccati su uno di essi su di un'altro potrebbero essere presenti +dei dati; così che nel migliore dei casi si avrebbe una lettura ritardata +inutilmente, e nel peggiore si potrebbe addirittura arrivare ad un +\textit{deadlock}. Abbiamo già accennato in \secref{sec:file_open} che è possibile prevenire -questo tipo di comportamento aprendo il file in modalità non bloccante, -specificando il flag \macro{O\_NONBLOCK}. In questo caso le funzioni che si -sarebbero bloccate ritornano immediatamente restituendo l'errore -\macro{EAGAIN}. +questo tipo di comportamento aprendo un file in modalità +\textsl{non-bloccante}, attraverso l'uso del flag \macro{O\_NONBLOCK} nella +chiamata di \func{open}. In questo caso le funzioni di input/output che +altrimenti si sarebbero bloccate ritornano immediatamente, restituendo +l'errore \macro{EAGAIN}. + +L'utilizzo di questa modalità di I/O permette di risolvere il problema +controllando a turno i vari file descriptor, in un ciclo in cui si ripete +l'accesso fintanto che esso non viene garantito. Ovviamente questa tecnica, +detta \textit{polling}, è estremamente inefficiente: si tiene costantemente +impiegata la CPU solo per eseguire in continuazione delle system call che +nella gran parte dei casi falliranno. Per evitare questo, come vedremo in +\secref{sec:file_multiplexing}, è stata introdotta una nuova interfaccia di +programmazione, che comporta comunque l'uso della modalità di I/O non +bloccante. + + + +\subsection{L'I/O multiplexing} +\label{sec:file_multiplexing} + +Per superare il problema di dover usare il \textit{polling} per controllare la +possibilità di effettuare operazioni su un file aperto in modalità non +bloccante, sia BSD che System V hanno introdotto delle nuove funzioni in grado +di sospendere l'esecuzione di un processo in attesa che l'accesso diventi +possibile. Il primo ad introdurre questa modalità di operazione, chiamata +usualmente \textit{I/O multiplexing}, è stato BSD,\footnote{la funzione è + apparsa in BSD4.2 e standardizzata in BSD4.4, ma è stata portata su tutti i + sistemi che supportano i \textit{socket}, compreso le varianti di System V.} +con la funzione \func{select}, il cui prototipo è: +\begin{functions} + \headdecl{sys/time.h} + \headdecl{sys/types.h} + \headdecl{unistd.h} + \funcdecl{int select(int n, fd\_set *readfds, fd\_set *writefds, fd\_set + *exceptfds, struct timeval *timeout)} + + Attende che uno dei file descriptor degli insiemi specificati diventi + attivo. + + \bodydesc{La funzione in caso di successo restituisce il numero di file + descriptor (anche nullo) che sono attivi, e -1 in caso di errore, nel qual + caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato in uno + degli insiemi. + \item[\macro{EINTR}] La funzione è stata interrotta da un segnale. + \item[\macro{EINVAL}] Si è specificato per \param{n} un valore negativo. + \end{errlist} + ed inoltre \macro{ENOMEM}. +} +\end{functions} + +La funzione mette il processo in stato di \textit{sleep} (vedi +\tabref{tab:proc_proc_states}) fintanto che almeno uno dei file descriptor +degli insiemi specificati (\param{readfds}, \param{writefds} e +\param{exceptfds}), non diventa attivo, per un tempo massimo specificato da +\param{timeout}. + +Per specificare quali file descriptor si intende \textsl{selezionare}, la +funzione usa un particolare oggetto, il \textit{file descriptor set}, +identificato dal tipo \type{fd\_set}, che serve ad identificare un insieme di +file descriptor, (in maniera analoga a come un \textit{signal set}, vedi +\secref{sec:sig_sigset}, identifica un insieme di segnali). Per la +manipolazione di questi \textit{file descriptor set} si possono usare delle +opportune macro di preprocessore: +\begin{functions} + \headdecl{sys/time.h} + \headdecl{sys/types.h} + \headdecl{unistd.h} + \funcdecl{FD\_ZERO(fd\_set *set)} + Inizializza l'insieme (vuoto). + + \funcdecl{FD\_SET(int fd, fd\_set *set)} + Inserisce il file descriptor \param{fd} nell'insieme. + + \funcdecl{FD\_CLR(int fd, fd\_set *set)} + Rimuove il file descriptor \param{fd} nell'insieme. + + \funcdecl{FD\_ISSET(int fd, fd\_set *set)} + Controlla se il file descriptor \param{fd} è nell'insieme. +\end{functions} + +In genere un \textit{file descriptor set} può contenere fino ad un massimo di +\macro{FD\_SETSIZE} file descriptor. Questo valore in origine corrispondeva +al limite per il numero massimo di file aperti\footnote{ad esempio in Linux, + fino alla serie 2.0.x, c'era un limite di 256 file per processo.}, ma +quando, come nelle versioni più recenti del kernel, non c'è più un limite +massimo, esso indica le dimensioni massime dei numeri usati nei \textit{file + descriptor set}. + +La funzione richiede di specificare tre insiemi distinti di file descriptor; +il primo, \param{readfds}, verrà osservato per rilevare la disponibilità di +effettuare una lettura, il secondo, \param{writefds}, per verificare la +possibilità effettuare una scrittura ed il terzo, \param{exceptfds}, per +verificare l'esistenza di condizioni eccezionali (come i messaggi urgenti su +un \textit{socket}\index{socket}, vedi \secref{sec:xxx_urgent}). + +La funzione inoltre richiede anche di specificare, tramite l'argomento +\param{n}, un valore massimo del numero dei file descriptor usati +nell'insieme; si può usare il già citato \macro{FD\_SETSIZE}, oppure il numero +più alto dei file descriptor usati nei tre insiemi, aumentato di uno. + +Infine l'argomento \param{timeout}, specifica un tempo massimo di +attesa\footnote{il tempo è valutato come \textit{elapsed time}.} prima che la +funzione ritorni; se impostato a \macro{NULL} la funzione attende +indefinitamente. Si può specificare anche un tempo nullo (cioè una \var{struct + timeval} con i campi impostati a zero), qualora si voglia semplicemente +controllare lo stato corrente dei file descriptor. + +La funzione restituisce il totale dei file descriptor pronti nei tre insiemi, +il valore zero indica sempre che si è raggiunto un timeout. Ciascuno dei tre +insiemi viene sovrascritto per indicare quale file descriptor è pronto per le +operazioni ad esso relative, in modo da poterlo controllare con la macro +\macro{FD\_ISSET}. In caso di errore la funzione restituisce -1 e gli insiemi +non vengono toccati. + +In Linux \func{select} modifica anche il valore di \param{timeout}, +impostandolo al tempo restante; questo è utile quando la funzione viene +interrotta da un segnale, in tal caso infatti si ha un errore di +\macro{EINTR}, ed occorre rilanciare la funzione; in questo modo non è +necessario ricalcolare tutte le volte il tempo rimanente.\footnote{questo può + causare problemi di portabilità sia quando si trasporta codice scritto su + Linux che legge questo valore, sia quando si usano programmi scritti per + altri sistemi che non dispongono di questa caratteristica e ricalcolano + \param{timeout} tutte le volte. In genere la caratteristica è disponibile + nei sistemi che derivano da System V e non disponibile per quelli che + derivano da BSD.} + +Come accennato l'interfaccia di \func{select} è una estensione di BSD; anche +System V ha introdotto una sua interfaccia per gestire l'\textit{I/O + multiplexing}, basata sulla funzione \func{poll},\footnote{la funzione è + prevista dallo standard XPG4, ed è stata introdotta in Linux come system + call a partire dal kernel 2.1.23 e dalle \acr{libc} 5.4.28.} il cui +prototipo è: +\begin{prototype}{sys/poll.h} + {int poll(struct pollfd *ufds, unsigned int nfds, int timeout)} -Esistono molti casi però in cui non si vuole che questo avvenga +La funzione attente un cambiamento di stato per uno dei file descriptor +specificati da \param{ufds}. + +\bodydesc{La funzione restituisce il numero di file descriptor con attività in + caso di successo, o 0 se c'è stato un timeout; in caso di errore viene + restituito -1 ed \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato in uno + degli insiemi. + \item[\macro{EINTR}] La funzione è stata interrotta da un segnale. + \end{errlist} + ed inoltre \macro{EFAULT} e \macro{ENOMEM}.} +\end{prototype} +La funzione tiene sotto controllo un numero \param{ndfs} di file descriptor +specificati attraverso un vettore di puntatori a strutture di tipo +\type{pollfd}, la cui definizione è riportata in \figref{fig:file_pollfd}. +Come \func{select} anche \func{poll} permette di interrompere l'attesa dopo un +certo tempo, che va specificato attraverso \param{timeout} in numero di +millisecondi (un valore negativo indica un'attesa indefinita). +\begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{15cm} + \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{} +struct pollfd { + int fd; /* file descriptor */ + short events; /* requested events */ + short revents; /* returned events */ +}; + \end{lstlisting} + \end{minipage} + \normalsize + \caption{La struttura \type{pollfd}, utilizzata per specificare le modalità + di controllo di un file descriptor alla funzione \func{poll}.} + \label{fig:file_pollfd} +\end{figure} + +Per ciascun file da controllare deve essere opportunamente predisposta una +struttura \type{pollfd}; nel campo \var{fd} deve essere specificato il file +descriptor, mentre nel campo \var{events} il tipo di evento su cui si vuole +attendere; quest'ultimo deve essere specificato come maschera binaria dei +primi tre valori riportati in \tabref{tab:file_pollfd_flags} (gli altri +vengono utilizzati solo per \var{revents} come valori in uscita). + +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|c|l|} + \hline + \textbf{Flag} & \textbf{Valore} & \textbf{Significato} \\ + \hline + \hline + \macro{POLLIN} & 0x001 & È possibile la lettura immediata.\\ + \macro{POLLPRI} & 0x002 & Sono presenti dati urgenti.\\ + \macro{POLLOUT} & 0x004 & È possibile la scrittura immediata.\\ + \hline + \macro{POLLERR} & 0x008 & C'è una condizione di errore.\\ + \macro{POLLHUP} & 0x010 & Si è verificato un hung-up.\\ + \macro{POLLNVAL} & 0x020 & Il file descriptor non è aperto.\\ + \hline + \macro{POLLRDNORM}& 0x040 & Sono disponibili in lettura dati normali.\\ + \macro{POLLRDBAND}& 0x080 & Sono disponibili in lettura dati ad alta + priorità. \\ + \macro{POLLWRNORM}& 0x100 & È possibile la scrittura di dati normali. \\ + \macro{POLLWRBAND}& 0x200 & È possibile la scrittura di dati ad + alta priorità. \\ + \macro{POLLMSG} & 0x400 & Estensione propria di Linux.\\ + \hline + \end{tabular} + \caption{Costanti per l'identificazione dei vari bit dei campi + \var{events} e \var{revents} di \type{pollfd}.} + \label{tab:file_pollfd_flags} +\end{table} + +La funzione ritorna, restituendo il numero di file per i quali si è verificata +una delle condizioni di attesa richieste od un errore. Lo stato dei file +all'uscita della funzione viene restituito nel campo \var{revents} della +relativa struttura \type{pollfd}, che viene impostato alla maschera binaria +dei valori riportati in \tabref{tab:file_pollfd_flags}, ed oltre alle tre +condizioni specificate tramite \var{events} può riportare anche l'occorrere di +una condizione di errore. + +Lo standard POSIX è rimasto a lungo senza primitive per l'\textit{I/O + multiplexing}, che è stata introdotto con le ultime revisioni dello standard +(POSIX 1003.1g-2000 e POSIX 1003.1-2001). Esso prevede che tutte le funzioni +ad esso relative vengano dichiarate nell'header \file{sys/select.h}, che +sostituisce i precedenti, ed aggiunge a \func{select} una nuova funzione +\func{pselect},\footnote{il supporto per lo standard POSIX 1003.1-2001, ed + l'header \file{sys/select.h}, compaiono in Linux a partire dalle \acr{glibc} + 2.1. Le \acr{libc4} e \acr{libc5} non contengono questo header, le + \acr{glibc} 2.0 contengono una definizione sbagliata di \func{psignal}, + senza l'argomento \param{sigmask}, la definizione corretta è presente dalle + \acr{glibc} 2.1-2.2.1 se si è definito \macro{\_GNU\_SOURCE} e nelle + \acr{glibc} 2.2.2-2.2.4 se si è definito \macro{\_XOPEN\_SOURCE} con valore + maggiore di 600.} il cui prototipo è: +\begin{prototype}{sys/select.h} + {int pselect(int n, fd\_set *readfds, fd\_set *writefds, fd\_set *exceptfds, + struct timespec *timeout, sigset\_t *sigmask)} + + Attende che uno dei file descriptor degli insiemi specificati diventi + attivo. + + \bodydesc{La funzione in caso di successo restituisce il numero di file + descriptor (anche nullo) che sono attivi, e -1 in caso di errore, nel qual + caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato in uno + degli insiemi. + \item[\macro{EINTR}] La funzione è stata interrotta da un segnale. + \item[\macro{EINVAL}] Si è specificato per \param{n} un valore negativo. + \end{errlist} + ed inoltre \macro{ENOMEM}.} +\end{prototype} + +La funzione è sostanzialmente identica a \func{select}, solo che usa una +struttura \type{timespec} per indicare con maggiore precisione il timeout e +non ne aggiorna il valore in caso di interruzione, inoltre prende un argomento +aggiuntivo \param{sigmask} che è il puntatore ad una maschera di segnali (si +veda \secref{sec:sig_sigmask}). La maschera corrente viene sostituita da +questa immediatamente prima di eseguire l'attesa, e ripristinata al ritorno +della funzione. + +L'uso di \param{sigmask} è stato introdotto allo scopo di prevenire possibili +race condition\footnote{in Linux però, non esistendo una system call apposita, + la funzione è implementata nelle \acr{glibc} usando \func{select}, e la + possibilità di una race condition resta.} quando si deve eseguire un test su +una variabile assegnata da un manipolatore sulla base dell'occorrenza di un +segnale per decidere se lanciare \func{select}. Fra il test e l'esecuzione è +presente una finestra in cui potrebbe arrivare il segnale che non sarebbe +rilevato; la race condition diventa superabile disabilitando il segnale prima +del test e riabilitandolo poi grazie all'uso di \param{sigmask}. -%\section{I/O asincrono} -%\label{sec:file_asynchronous} -%Non supportato in Linux, in BSD e SRv4 c'è, ma usando il segnale \macro{SIGIO} -%per indicare che i dati sono disponibili, può essere usato in maniera semplice -%con un solo file per processo (altrimenti non sarebbe più possibile -%distinguere da quale file proviene l'attività che ha causato l'emissione del -%segnale). \subsection{L'I/O asincrono} \label{sec:file_asyncronous_io} +Una modalità alternativa all'uso dell'\textit{I/O multiplexing} è quella di +fare ricorso al cosiddetto \textsl{I/O asincrono}. Il concetto base +dell'\textsl{I/O asincrono} è che le funzioni di I/O non attendono il +completamento delle operazioni prima di ritornare, così che il processo non +viene bloccato. In questo modo diventa ad esempio possibile effettuare una +richiesta preventiva di dati, in modo da poter effettuare in contemporanea le +operazioni di calcolo e quelle di I/O. +Abbiamo accennato in \secref{sec:file_open} che è possibile, attraverso l'uso +del flag \macro{O\_ASYNC},\footnote{l'uso del flag di \macro{O\_ASYNC} e dei + comandi \macro{F\_SETOWN} e \macro{F\_GETOWN} per \func{fcntl} è specifico + di Linux e BSD.} aprire un file in modalità asincrona, così come è possibile +attivare in un secondo tempo questa modalità impostando questo flag attraverso +l'uso di \func{fcntl} con il comando \macro{F\_SETFL} (vedi +\secref{sec:file_fcntl}). + +In realtà in questo caso non si tratta di I/O asincrono vero e proprio, quanto +di un meccanismo asincrono di notifica delle variazione dello stato del file +descriptor; quello che succede è che il sistema genera un segnale (normalmente +\macro{SIGIO}, ma è possibile usarne altri) tutte le volte che diventa +possibile leggere o scrivere dal file descriptor che si è posto in questa +modalità. Si può inoltre selezionare, con il comando \macro{F\_SETOWN} di +\func{fcntl}, quale processo (o gruppo di processi) riceverà il segnale. + +In questo modo si può evitare l'uso delle funzioni \func{poll} o \func{select} +che, quando vengono usate con un numero molto grande di file descriptor, non +hanno buone prestazioni. In tal caso infatti la maggior parte del loro tempo +di esecuzione è impegnato ad eseguire una scansione su tutti i file descriptor +tenuti sotto controllo per determinare quali di essi (in genere una piccola +percentuale) sono diventati attivi. + +Tuttavia con l'implementazione classica dei segnali questa modalità di I/O +presenta notevoli problemi, dato che non è possibile determinare, quando sono +più di uno, qual'è il file descriptor responsabile dell'emissione del segnale. +Linux però supporta le estensioni POSIX.1b dei segnali che permettono di +superare il problema facendo ricorso alle informazioni aggiuntive restituite +attraverso la struttura \type{siginfo\_t}, utilizzando la forma estesa +\var{sa\_sigaction} del manipolatore (si riveda quanto illustrato in +\secref{sec:sig_sigaction}). + +Per far questo però occorre utilizzare le funzionalità dei segnali real-time +(vedi \secref{sec:sig_real_time}) impostando esplicitamente con il comando +\macro{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare in caso di +I/O asincrono (il segnale predefinito è \macro{SIGIO}). In questo caso il +manipolatore tutte le volte che riceverà \macro{SI\_SIGIO} come valore del +campo \var{si\_code}\footnote{il valore resta \macro{SI\_SIGIO} qualunque sia + il segnale che si è associato all'I/O asincrono, ed indica appunto che il + segnale è stato generato a causa di attività nell'I/O asincrono.} di +\type{siginfo\_t}, troverà nel campo \var{si\_fd} il valore del file +descriptor che ha generato il segnale. + +Un secondo vantaggio dell'uso dei segnali real-time è che essendo dotati di +una coda di consegna ogni segnale sarà associato ad uno solo file descriptor; +inoltre sarà possibile stabilire delle priorità nella risposta a seconda del +segnale usato. In questo modo si può identificare immediatamente un file su +cui l'accesso è diventato possibile evitando completamente l'uso di funzioni +come \func{poll} e \func{select}, almeno fintanto che non si satura la coda; +si eccedono le dimensioni di quest'ultima; in tal caso infatti il kernel, non +potendo più assicurare il comportamento corretto per un segnale real-time, +invierà al suo posto un \var{SIGIO}, su cui si accumuleranno tutti i segnali +in eccesso, e si dovrà determinare al solito modo quali sono i file diventati +attivi. + +Benché la modalità di apertura asincrona di un file possa risultare utile in +varie occasioni (in particolar modo con i socket e gli altri file per i quali +le funzioni di I/O sono system call lente), essa è comunque limitata alla +notifica della disponibilità del file descriptor per le operazioni di I/O, e +non ad uno svolgimento asincrono delle medesime. Lo standard POSIX.1b +definisce anche una interfaccia apposita per l'I/O asincrono, che prevede un +insieme di funzioni dedicate, completamente separate rispetto a quelle usate +normalmente. + +In generale questa interfaccia è completamente astratta e può essere +implementata sia direttamente nel kernel, che in user space attraverso l'uso +di thread. Al momento\footnote{fino ai kernel della serie 2.4.x, nella serie + 2.5.x è però iniziato un lavoro completo di riscrittura di tutto il sistema + di I/O, che prevede anche l'introduzione di un nuovo layer per l'I/O + asincrono (effettuato a partire dal 2.5.32).} esiste una sola versione +stabile di questa interfaccia, quella delle \acr{glibc}, che è realizzata +completamente in user space. Esistono comunque vari progetti sperimentali +(come il KAIO della SGI, o i patch di Benjamin La Haise) che prevedono un +supporto diretto da parte del kernel. + +Lo standard prevede che tutte le operazioni di I/O asincrono siano controllate +attraverso l'uso di una apposita struttura \type{aiocb} (il cui nome sta per +\textit{asyncronous I/O control block}), che viene passata come argomento a +tutte le funzioni dell'interfaccia. La sua definizione, come effettuata in +\file{aio.h}, è riportata in \figref{fig:file_aiocb}. Nello steso file è +definita la macro \macro{\_POSIX\_ASYNCHRONOUS\_IO}, che dichiara la +disponibilità dell'interfaccia per l'I/O asincrono. + +\begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{15cm} + \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{} +struct aiocb +{ + int aio_fildes; /* File descriptor. */ + off_t aio_offset; /* File offset */ + int aio_lio_opcode; /* Operation to be performed. */ + int aio_reqprio; /* Request priority offset. */ + volatile void *aio_buf; /* Location of buffer. */ + size_t aio_nbytes; /* Length of transfer. */ + struct sigevent aio_sigevent; /* Signal number and value. */ +}; + \end{lstlisting} + \end{minipage} + \normalsize + \caption{La struttura \type{aiocb}, usata per il controllo dell'I/O + asincrono.} + \label{fig:file_aiocb} +\end{figure} + +Le operazioni di I/O asincrono possono essere effettuate solo su un file già +aperto; il file deve inoltre supportare la funzione \func{lseek}, +pertanto terminali e pipe sono esclusi. Non c'è limite al numero di operazioni +contemporanee effettuabili su un singolo file. + +Ogni operazione deve inizializzare opportunamente un \textit{control block}. +Il file descriptor su cui operare deve essere specificato tramite il campo +\var{aio\_fildes}; dato che più operazioni possono essere eseguita in maniera +asincrona, il concetto di posizione corrente sul file viene a mancare; +pertanto si deve sempre specificare nel campo \var{aio\_offset} la posizione +sul file da cui i dati saranno letti o scritti. Nel campo \var{aio\_buf} deve +essere specificato l'indirizzo del buffer usato per l'I/O, ed in +\var{aio\_nbytes} la lunghezza del blocco di dati da trasferire. + +Il campo \var{aio\_reqprio} permette di impostare la priorità delle operazioni +di I/O.\footnote{in generale perché ciò sia possibile occorre che la + piattaforma supporti questa caratteristica, questo viene indicato definendo + le macro \macro{\_POSIX\_PRIORITIZED\_IO}, e + \macro{\_POSIX\_PRIORITY\_SCHEDULING}.} La priorità viene impostata a +partire da quella del processo chiamante (vedi \secref{sec:proc_priority}), +cui viene sottratto il valore di questo campo. + +Il campo \var{aio\_lio\_opcode} è usato soltanto dalla funzione +\func{lio\_listio}, che, come vedremo più avanti, permette di eseguire con una +sola chiamata una serie di operazioni, usando un vettore di \textit{control + block}. Tramite questo campo si specifica quale è la natura di ciascuna di +esse. + +\begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{15cm} + \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{} +struct sigevent +{ + sigval_t sigev_value; + int sigev_signo; + int sigev_notify; + sigev_notify_function; + sigev_notify_attributes; +}; + \end{lstlisting} + \end{minipage} + \normalsize + \caption{La struttura \type{sigevent}, usata per specificare le modalità di + notifica degli eventi relativi alle operazioni di I/O asincrono.} + \label{fig:file_sigevent} +\end{figure} + +Infine il campo \var{aio\_sigevent} è una struttura di tipo \type{sigevent} +che serve a specificare il modo in cui si vuole che venga effettuata la +notifica del completamento delle operazioni richieste. La struttura è +riportata in \secref{fig:file_sigevent}; il campo \var{sigev\_notify} è quello +che indica le modalità della notifica, esso può assumere i tre valori: +\begin{basedescript}{\desclabelwidth{3.0cm}} +\item[\macro{SIGEV\_NONE}] Non viene inviata nessuna notifica. +\item[\macro{SIGEV\_SIGNAL}] La notifica viene effettuata inviando al processo + chiamante il segnale specificato nel campo \var{sigev\_signo}, se il + manipolatore è installato con \macro{SA\_SIGINFO}, il gli verrà restituito + il valore di \var{sigev\_value} in come valore del campo \var{si\_value} per + \type{siginfo\_t}. +\item[\macro{SIGEV\_THREAD}] La notifica viene effettuata creando un nuovo + thread che esegue la funzione specificata da \var{sigev\_notify\_function}, + con gli attributi specificati da \var{sigev\_notify\_attribute}. +\end{basedescript} + +Le due funzioni base dell'interfaccia per l'I/O asincrono sono +\func{aio\_read} ed \func{aio\_write}. Esse permettono di richiedere una +lettura od una scrittura asincrona di dati, usando la struttura \type{aiocb} +appena descritta; i rispettivi prototipi sono: +\begin{functions} + \headdecl{aio.h} + + \funcdecl{int aio\_read(struct aiocb *aiocbp)} + Richiede una lettura asincrona secondo quanto specificato con \param{aiocbp}. + + \funcdecl{int aio\_write(struct aiocb *aiocbp)} + Richiede una scrittura asincrona secondo quanto specificato con + \param{aiocbp}. + + \bodydesc{Le funzioni restituiscono 0 in caso di successo, e -1 in caso di + errore, nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato. + \item[\macro{ENOSYS}] La funzione non è implementata. + \item[\macro{EINVAL}] Si è specificato un valore non valido per i campi + \var{aio\_offset} o \var{aio\_reqprio} di \param{aiocbp}. + \item[\macro{EAGAIN}] La coda delle richieste è momentaneamente piena. + \end{errlist} +} +\end{functions} + +Entrambe le funzioni ritornano immediatamente dopo aver messo in coda la +richiesta, o in caso di errore. Non è detto che gli errori \macro{EBADF} ed +\macro{EINVAL} siano rilevati immediatamente al momento della chiamata, +potrebbero anche emergere nelle fasi successive delle operazioni. Lettura e +scrittura avvengono alla posizione indicata da \var{aio\_offset}, a meno che +il file non sia stato aperto in \textit{append mode} (vedi +\secref{sec:file_open}), nel qual caso le scritture vengono effettuate +comunque alla fine de file, nell'ordine delle chiamate a \func{aio\_write}. + +Si tenga inoltre presente che deallocare la memoria indirizzata da +\param{aiocbp} o modificarne i valori prima della conclusione di una +operazione può dar luogo a risultati impredicibili, perché l'accesso ai vari +campi per eseguire l'operazione può avvenire in un momento qualsiasi dopo la +richiesta. Questo comporta che occorre evitare di usare per \param{aiocbp} +variabili automatiche e che non si deve riutilizzare la stessa struttura per +un ulteriore operazione fintanto che la precedente non sia stata ultimata. In +generale per ogni operazione di I/O asincrono si deve utilizzare una diversa +struttura \type{aiocb}. + +Dato che si opera in modalità asincrona, il successo di \func{aio\_read} o +\func{aio\_write} non implica che le operazioni siano state effettivamente +eseguite in maniera corretta; per verificarne l'esito l'interfaccia prevede +altre due funzioni, che permettono di controllare lo stato di esecuzione. La +prima è \func{aio\_error}, che serve a determinare un eventuale stato di +errore; il suo prototipo è: +\begin{prototype}{aio.h} + {int aio\_error(const struct aiocb *aiocbp)} + + Determina lo stato di errore delle operazioni di I/O associate a + \param{aiocbp}. + + \bodydesc{La funzione restituisce 0 se le operazioni si sono concluse con + successo, altrimenti restituisce il codice di errore relativo al loro + fallimento.} +\end{prototype} + +Se l'operazione non si è ancora completata viene restituito l'errore di +\macro{EINPROGRESS}. La funzione ritorna zero quando l'operazione si è +conclusa con successo, altrimenti restituisce il codice dell'errore +verificatosi, ed esegue la corrispondente impostazione di \var{errno}. Il +codice può essere sia \macro{EINVAL} ed \macro{EBADF}, dovuti ad un valore +errato per \param{aiocbp}, che uno degli errori possibili durante l'esecuzione +dell'operazione di I/O richiesta, nel qual caso saranno restituiti, a seconda +del caso, i codici di errore delle system call \func{read}, \func{write} e +\func{fsync}. + +Una volta che si sia certi che le operazioni siano state concluse (cioè dopo +che una chiamata ad \func{aio\_error} non ha restituito \macro{EINPROGRESS}, +si potrà usare la seconda funzione dell'interfaccia, \func{aio\_return}, che +permette di verificare il completamento delle operazioni di I/O asincrono; il +suo prototipo è: +\begin{prototype}{aio.h} +{ssize\_t aio\_return(const struct aiocb *aiocbp)} + +Recupera il valore dello stato di ritorno delle operazioni di I/O associate a +\param{aiocbp}. + +\bodydesc{La funzione restituisce lo stato di uscita dell'operazione + eseguita.} +\end{prototype} + +La funzione deve essere chiamata una sola volte per ciascuna operazione +asincrona, essa infatti fa sì che il sistema rilasci le risorse ad essa +associate. É per questo motivo che occorre chiamare la funzione solo dopo che +l'operazione cui \param{aiocbp} fa riferimento si è completata. Una chiamata +precedente il completamento delle operazioni darebbe risultati indeterminati. + +La funzione restituisce il valore di ritorno relativo all'operazione eseguita, +così come ricavato dalla sottostante system call (il numero di byte letti, +scritti o il valore di ritorno di \func{fsync}). É importante chiamare sempre +questa funzione, altrimenti le risorse disponibili per le operazioni di I/O +asincrono non verrebbero liberate, rischiando di arrivare ad un loro +esaurimento. + +Oltre alle operazioni di lettura e scrittura l'interfaccia POSIX.1b mette a +disposizione un'altra operazione, quella di sincronizzazione dell'I/O, essa è +compiuta dalla funzione \func{aio\_fsync}, che ha lo stesso effetto della +analoga \func{fsync}, ma viene eseguita in maniera asincrona; il suo prototipo +è: +\begin{prototype}{aio.h} +{ssize\_t aio\_return(int op, struct aiocb *aiocbp)} + +Richiede la sincronizzazione dei dati per il file indicato da \param{aiocbp}. + +\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di + errore, che può essere, con le stesse modalità di \func{aio\_read}, + \macro{EAGAIN}, \macro{EBADF} o \macro{EINVAL}.} +\end{prototype} + +La funzione richiede la sincronizzazione delle operazioni di I/O, ritornando +immediatamente. L'esecuzione effettiva della sincronizzazione dovrà essere +verificata con \func{aio\_error} e \func{aio\_return} come per le operazioni +di lettura e scrittura. L'argomento \param{op} permette di indicare la +modalità di esecuzione, se si specifica il valore \macro{O\_DSYNC} le +operazioni saranno completate con una chiamata a \func{fdatasync}, se si +specifica \macro{O\_SYNC} con una chiamata a \func{fsync} (per i dettagli vedi +\secref{sec:file_sync}). + +Il successo della chiamata assicura la sincronizzazione delle operazioni fino +allora richieste, niente è garantito riguardo la sincronizzazione dei dati +relativi ad eventuali operazioni richieste successivamente. Se si è +specificato un meccanismo di notifica questo sarà innescato una volta che le +operazioni di sincronizzazione dei dati saranno completate. + +In alcuni casi può essere necessario interrompere le operazioni (in genere +quando viene richiesta un'uscita immediata dal programma), per questo lo +standard POSIX.1b prevede una funzioni apposita, \func{aio\_cancel}, che +permette di cancellare una operazione richiesta in precedenza; il suo +prototipo è: +\begin{prototype}{aio.h} +{int aio\_cancel(int fildes, struct aiocb *aiocbp)} + +Richiede la cancellazione delle operazioni sul file \param{fildes} specificate +da \param{aiocbp}. + +\bodydesc{La funzione restituisce il risultato dell'operazione con un codice + di positivo, e -1 in caso di errore, che avviene qualora si sia specificato + un valore non valido di \param{fildes}, imposta \var{errno} al valore + \macro{EBADF}.} +\end{prototype} + +La funzione permette di cancellare una operazione specifica sul file +\param{fildes}, o tutte le operazioni pendenti, specificando \macro{NULL} come +valore di \param{aiocbp}. Quando una operazione viene cancellata una +successiva chiamata ad \func{aio\_error} riporterà \macro{ECANCELED} come +codice di errore, ed il suo codice di ritorno sarà -1, inoltre il meccanismo +di notifica non verrà invocato. Se si specifica una operazione relativa ad un +altro file descriptor il risultato è indeterminato. + +In caso di successo, i possibili valori di ritorno per \func{aio\_cancel} sono +tre (anch'essi definiti in \file{aio.h}): +\begin{basedescript}{\desclabelwidth{3.0cm}} +\item[\macro{AIO\_ALLDONE}] indica che le operazioni di cui si è richiesta la + cancellazione sono state già completate, + +\item[\macro{AIO\_CANCELED}] indica che tutte le operazioni richieste sono + state cancellate, + +\item[\macro{AIO\_NOTCANCELED}] indica che alcune delle operazioni erano in + corso e non sono state cancellate. +\end{basedescript} + +Nel caso si abbia \macro{AIO\_NOTCANCELED} occorrerà chiamare +\func{aio\_error} per determinare quali sono le operazioni effettivamente +cancellate. Le operazioni che non sono state cancellate proseguiranno il loro +corso normale, compreso quanto richiesto riguardo al meccanismo di notifica +del loro avvenuto completamento. + +Benché l'I/O asincrono preveda un meccanismo di notifica, l'interfaccia +fornisce anche una apposita funzione, \func{aio\_suspend}, che permette di +sospendere l'esecuzione del processo chiamante fino al completamento di una +specifica operazione; il suo prototipo è: +\begin{prototype}{aio.h} +{int aio\_suspend(const struct aiocb * const list[], int nent, const struct + timespec *timeout)} + + Attende, per un massimo di \param{timeout}, il completamento di una delle + operazioni specificate da \param{list}. + + \bodydesc{La funzione restituisce 0 se una (o più) operazioni sono state + completate, e -1 in caso di errore nel qual caso \var{errno} assumerà uno + dei valori: + \begin{errlist} + \item[\macro{EAGAIN}] Nessuna operazione è stata completata entro + \param{timeout}. + \item[\macro{ENOSYS}] La funzione non è implementata. + \item[\macro{EINTR}] La funzione è stata interrotta da un segnale. + \end{errlist} + } +\end{prototype} + +La funzione permette di bloccare il processo fintanto che almeno una delle +\param{nent} operazioni specificate nella lista \param{list} è completata, per +un tempo massimo specificato da \param{timout}, o fintanto che non arrivi un +segnale.\footnote{si tenga conto che questo segnale può anche essere quello + utilizzato come meccanismo di notifica.} La lista deve essere inizializzata +con delle strutture \var{aiocb} relative ad operazioni effettivamente +richieste, ma può contenere puntatori nulli, che saranno ignorati. In caso si +siano specificati valori non validi l'effetto è indefinito. Un valore +\macro{NULL} per \param{timout} comporta l'assenza di timeout. + +Lo standard POSIX.1b infine ha previsto pure una funzione, \func{lio\_listio}, +che permette di effettuare la richiesta di una intera lista di operazioni di +lettura o scrittura; il suo prototipo è: +\begin{prototype}{aio.h} + {int lio\_listio(int mode, struct aiocb * const list[], int nent, struct + sigevent *sig)} + + Richiede l'esecuzione delle operazioni di I/O elencata da \param{list}, + secondo la modalità \param{mode}. + + \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di + errore, nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\macro{EAGAIN}] Nessuna operazione è stata completata entro + \param{timeout}. + \item[\macro{ENOSYS}] La funzione non è implementata. + \item[\macro{EINTR}] La funzione è stata interrotta da un segnale. + \end{errlist} + } +\end{prototype} + +La funzione esegue la richiesta delle \param{nent} operazioni indicate dalla +lista \param{list}; questa deve contenere gli indirizzi di altrettanti +\textit{control block}, opportunamente inizializzati; in particolare nel caso +dovrà essere specificato il tipo di operazione tramite il campo +\var{aio\_lio\_opcode}, che può prendere i tre valori: +\begin{basedescript}{\desclabelwidth{2.0cm}} +\item[\macro{LIO\_READ}] si richiede una operazione di lettura. +\item[\macro{LIO\_WRITE}] si richiede una operazione di scrittura. +\item[\macro{LIO\_NOP}] non si effettua nessuna operazione. +\end{basedescript} +l'ultimo valore viene usato quando si ha a che fare con un vettore di +dimensione fissa, per poter specificare solo alcune operazioni, o quando si è +dovuto cancellare delle operazioni e si deve ripetere la richiesta per quelle +non completate. + +L'argomento \param{mode} permette di stabilire il comportamento della +funzione, se viene specificato il valore \macro{LIO\_WAIT} la funzione si +blocca fino al completamento di tutte le operazioni richieste; se invece si +specifica \macro{LIO\_NOWAIT} la funzione ritorna immediatamente dopo aver +messo in coda tutte le richieste. In questo caso il chiamante può richiedere +la notifica del completamento di tutte le richieste, impostando l'argomento +\param{sig} in maniera analoga a come si fa per il campo \var{aio\_sigevent} +di \type{aiocb}. + + + +\subsection{I/O vettorizzato} +\label{sec:file_multiple_io} + +Un caso abbastanza comune è quello in cui ci si trova a dover eseguire una +serie multipla di operazioni di I/O, come una serie di letture o scritture di +vari buffer. Un esempio tipico è quando i dati sono strutturati nei campi di +una struttura ed essi devono essere caricati o salvati su un file. Benché +l'operazione sia facilmente eseguibile attraverso una serie multipla di +chiamate, ci sono casi in cui si vuole poter contare sulla atomicità delle +operazioni. + +Per questo motivo BSD 4.2\footnote{Le due funzioni sono riprese da BSD4.4 ed + integrate anche dallo standard Unix 98; fino alle libc5 Linux usava + \type{size\_t} come tipo dell'argomento \param{count}, una scelta logica, + che però è stata dismessa per restare aderenti allo standard.} ha introdotto +due nuove system call, \func{readv} e \func{writev}, che permettono di +effettuare con una sola chiamata una lettura o una scrittura su una serie di +buffer (quello che viene chiamato \textsl{I/O vettorizzato}. I relativi +prototipi sono: +\begin{functions} + \headdecl{sys/uio.h} + + \funcdecl{int readv(int fd, const struct iovec *vector, int count)} Esegue + una lettura vettorizzata da \param{fd} nei \param{count} buffer specificati + da \param{vector}. + + \funcdecl{int writev(int fd, const struct iovec *vector, int count)} Esegue + una scrittura vettorizzata da \param{fd} nei \param{count} buffer + specificati da \param{vector}. + + \bodydesc{Le funzioni restituiscono il numero di byte letti o scritti in + caso di successo, e -1 in caso di errore, nel qual caso \var{errno} + assumerà uno dei valori: + \begin{errlist} + \item[\macro{EBADF}] si è specificato un file descriptor sbagliato. + \item[\macro{EINVAL}] si è specificato un valore non valido per uno degli + argomenti (ad esempio \param{count} è maggiore di \macro{MAX\_IOVEC}). + \item[\macro{EINTR}] la funzione è stata interrotta da un segnale prima di + di avere eseguito una qualunque lettura o scrittura. + \item[\macro{EAGAIN}] \param{fd} è stato aperto in modalità non bloccante e + non ci sono dati in lettura. + \item[\macro{EOPNOTSUPP}] La coda delle richieste è momentaneamente piena. + \end{errlist} + ed inoltre \macro{EISDIR}, \macro{ENOMEM}, \macro{EFAULT} (se non sono stato + allocati correttamente i buffer specificati nei campi \func{iov\_base}), più + tutti gli ulteriori errori che potrebbero avere le usuali funzioni di + lettura e scrittura eseguite su \param{fd}.} +\end{functions} + +Entrambe le funzioni usano una struttura \type{iovec}, definita in +\figref{fig:file_iovec}, che definisce dove i dati devono essere letti o +scritti. Il primo campo, \var{iov\_base}, contiene l'indirizzo del buffer ed +il secondo, \var{iov\_len}, la dimensione dello stesso. + +\begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{15cm} + \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{} +struct iovec { + __ptr_t iov_base; /* Starting address */ + size_t iov_len; /* Length in bytes */ +}; + \end{lstlisting} + \end{minipage} + \normalsize + \caption{La struttura \type{iovec}, usata dalle operazioni di I/O + vettorizzato.} + \label{fig:file_iovec} +\end{figure} + +I buffer da utilizzare sono indicati attraverso l'argomento \param{vector} che +è un vettore di strutture \var{iovec}, la cui lunghezza è specificata da +\param{count}. Ciascuna struttura dovrà essere inizializzata per +opportunamente per indicare i vari buffer da/verso i quali verrà eseguito il +trasferimento dei dati. Essi verranno letti (o scritti) nell'ordine in cui li +si sono specificati nel vettore \var{vector}. + + +\subsection{File mappati in memoria} +\label{sec:file_memory_map} + +Una modalità alternativa di I/O, che usa una interfaccia completamente diversa +rispetto a quella classica vista in \capref{cha:file_unix_interface}, è il +cosiddetto \textit{memory-mapped I/O}, che, attraverso il meccanismo della +\textsl{paginazione}\index{paginazione} usato dalla memoria virtuale (vedi +\secref{sec:proc_mem_gen}), permette di \textsl{mappare} il contenuto di un +file in una sezione dello spazio di indirizzi del processo. Il meccanismo è +illustrato in \figref{fig:file_mmap_layout}, una sezione del file viene +riportata direttamente nello spazio degli indirizzi del programma. Tutte le +operazioni su questa zona verranno riportate indietro sul file dal meccanismo +della memoria virtuale che trasferirà il contenuto di quel segmento sul file +invece che nella swap, per cui si può parlare tanto di file mappato in +memoria, quanto di memoria mappata su file. + +\begin{figure}[htb] + \centering + \includegraphics[width=9.5cm]{img/mmap_layout} + \caption{Disposizione della memoria di un processo quando si esegue la + mappatura in memoria di un file.} + \label{fig:file_mmap_layout} +\end{figure} + +Tutto questo comporta una notevole semplificazione delle operazioni di I/O, in +quanto non sarà più necessario utilizzare dei buffer intermedi su cui +appoggiare i dati da traferire, ma questi potranno essere acceduti +direttamente nella sezione di memoria mappata; inoltre questa interfaccia è +più efficiente delle usuali funzioni di I/O, in quanto permette di caricare in +memoria solo le parti del file che sono effettivamente usate ad un dato +istante. + +Infatti, dato che l'accesso è fatto direttamente attraverso la memoria +virtuale, la sezione di memoria mappata su cui si opera sarà a sua volta letta +o scritta sul file una pagina alla volta e solo per le parti effettivamente +usate, il tutto in maniera completamente trasparente al processo; l'accesso +alle pagine non ancora caricate avverrà allo stesso modo con cui vengono +caricate in memoria le pagine che sono state salvate sullo swap. + +Infine in situazioni in cui la memoria è scarsa, le pagine che mappano un +file vengono salvate automaticamente, così come le pagine dei programmi +vengono scritte sulla swap; questo consente di accedere ai file su dimensioni +il cui solo limite è quello dello spazio di indirizzi disponibile, e non della +memoria su cui possono esserne lette delle porzioni. + +L'interfaccia prevede varie funzioni per la gestione del \textit{memory mapped + I/O}, la prima di queste è \func{mmap}, che serve ad eseguire la mappatura +in memoria di un file; il suo prototipo è: +\begin{functions} + + \headdecl{unistd.h} + \headdecl{sys/mman.h} + + \funcdecl{void * mmap(void * start, size\_t length, int prot, int flags, int + fd, off\_t offset)} + + Esegue la mappatura in memoria del file \param{fd}. + + \bodydesc{La funzione restituisce il puntatore alla zona di memoria mappata + in caso di successo, e \macro{MAP\_FAILED} (-1) in caso di errore, nel + qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\macro{EBADF}] Il file descriptor non è valido, e non si è usato + \macro{MAP\_ANONYMOUS}. + \item[\macro{EACCES}] Il file descriptor non si riferisce ad un file + regolare, o si è richiesto \macro{MAP\_PRIVATE} ma \param{fd} non è + aperto in lettura, o si è richiesto \macro{MAP\_SHARED} e impostato + \macro{PROT\_WRITE} ed \param{fd} non è aperto in lettura/scrittura, o + si è impostato \macro{PROT\_WRITE} ed \param{fd} è in + \textit{append-only}. + \item[\macro{EINVAL}] I valori di \param{start}, \param{length} o + \param{offset} non sono validi (o troppo grandi o non allineati sulla + dimensione delle pagine). + \item[\macro{ETXTBSY}] Si è impostato \macro{MAP\_DENYWRITE} ma \param{fd} + è aperto in scrittura. + \item[\macro{EAGAIN}] Il file è bloccato, o si è bloccata troppa memoria. + \item[\macro{ENOMEM}] Non c'è memoria o si è superato il limite sul numero + di mappature possibili. + \item[\macro{ENODEV}] Il filesystem di \param{fd} non supporta il memory + mapping. + \end{errlist} + } +\end{functions} + +La funzione richiede di mappare in memoria la sezione del file \param{fd} a +partire da \param{offset} per \param{lenght} byte, preferibilmente +all'indirizzo \param{start}. Il valore di \param{offset} deve essere un +multiplo della dimensione di una pagina di memoria. + + +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|l|} + \hline + \textbf{Valore} & \textbf{Significato} \\ + \hline + \hline + \macro{PROT\_EXEC} & Le pagine possono essere eseguite.\\ + \macro{PROT\_READ} & Le pagine possono essere lette.\\ + \macro{PROT\_WRITE} & Le pagine possono essere scritte.\\ + \macro{PROT\_NONE} & L'accesso alle pagine è vietato.\\ + \hline + \end{tabular} + \caption{Valori dell'argomento \param{prot} di \func{mmap}, relativi alla + protezione applicate alle pagine del file mappate in memoria.} + \label{tab:file_mmap_prot} +\end{table} + + +Il valore dell'argomento \param{prot} indica la protezione\footnote{in Linux + la memoria reale è divisa in pagine: ogni processo vede la sua memoria + attraverso uno o più segmenti lineari di memoria virtuale. Per ciascuno di + questi segmenti il kernel mantiene nella \textit{page table} la mappatura + sulle pagine di memoria reale, ed le modalità di accesso (lettura, + esecuzione, scrittura); una loro violazione causa quella che si chiama una + \textit{segment violation}, e la relativa emissione del segnale + \macro{SIGSEGV}.} da applicare al segmento di memoria e deve essere +specificato come maschera binaria ottenuta dall'OR di uno o più dei valori +riportati in \tabref{tab:file_mmap_flag}; il valore specificato deve essere +compatibile con la modalità di accesso con cui si è aperto il file. + +L'argomento \param{flags} specifica infine qual'è il tipo di oggetto mappato, +le opzioni relative alle modalità con cui è effettuata la mappatura e alle +modalità con cui le modifiche alla memoria mappata vengono condivise o +mantenute private al processo che le ha effettuate. Deve essere specificato +come maschera binaria ottenuta dall'OR di uno o più dei valori riportati in +\tabref{tab:file_mmap_flag}. + +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|p{10cm}|} + \hline + \textbf{Valore} & \textbf{Significato} \\ + \hline + \hline + \macro{MAP\_FIXED} & Non permette di restituire un indirizzo diverso + da \param{start}, se questo non può essere usato + \func{mmap} fallisce. Se si imposta questo flag il + valore di \param{start} deve essere allineato + alle dimensioni di una pagina. \\ + \macro{MAP\_SHARED} & I cambiamenti sulla memoria mappata vengono + riportati sul file e saranno immediatamente + visibili agli altri processi che mappano lo stesso + file.\footnotemark Il file su disco però non sarà + aggiornato fino alla chiamata di \func{msync} o + \func{unmap}), e solo allora le modifiche saranno + visibili per l'I/O convenzionale. Incompatibile + con \macro{MAP\_PRIVATE}. \\ + \macro{MAP\_PRIVATE} & I cambiamenti sulla memoria mappata non vengono + riportati sul file. Ne viene fatta una copia + privata cui solo il processo chiamante ha + accesso. Le modifiche sono mantenute attraverso + il meccanismo del + \textit{copy on write}\index{copy on write} e + salvate su swap in caso di necessità. Non è + specificato se i cambiamenti sul file originale + vengano riportati sulla regione + mappata. Incompatibile con \macro{MAP\_SHARED}. \\ + \macro{MAP\_DENYWRITE} & In Linux viene ignorato per evitare + \textit{DoS}\index{DoS} (veniva usato per + segnalare che tentativi di scrittura sul file + dovevano fallire con \macro{ETXTBUSY}).\\ + \macro{MAP\_EXECUTABLE}& Ignorato. \\ + \macro{MAP\_NORESERVE} & Si usa con \macro{MAP\_PRIVATE}. Non riserva + delle pagine di swap ad uso del meccanismo di + \textit{copy on write}\index{copy on write} + per mantenere le + modifiche fatte alla regione mappata, in + questo caso dopo una scrittura, se non c'è più + memoria disponibile, si ha l'emissione di + un \macro{SIGSEGV}. \\ + \macro{MAP\_LOCKED} & Se impostato impedisce lo swapping delle pagine + mappate. \\ + \macro{MAP\_GROWSDOWN} & Usato per gli stack. Indica + che la mappatura deve essere effettuata con gli + indirizzi crescenti verso il basso.\\ + \macro{MAP\_ANONYMOUS} & La mappatura non è associata a nessun file. Gli + argomenti \param{fd} e \param{offset} sono + ignorati.\footnotemark\\ + \macro{MAP\_ANON} & Sinonimo di \macro{MAP\_ANONYMOUS}, deprecato.\\ + \macro{MAP\_FILE} & Valore di compatibilità, deprecato.\\ + \hline + \end{tabular} + \caption{Valori possibili dell'argomento \param{flag} di \func{mmap}.} + \label{tab:file_mmap_flag} +\end{table} + +\footnotetext{Dato che tutti faranno riferimento alle stesse pagine di + memoria.} +\footnotetext{L'uso di questo flag con \macro{MAP\_SHARED} è + stato implementato in Linux a partire dai kernel della serie 2.4.x.} + +Gli effetti dell'accesso ad una zona di memoria mappata su file possono essere +piuttosto complessi, essi si possono comprendere solo tenendo presente che +tutto quanto è comunque basato sul basato sul meccanismo della memoria +virtuale. Questo comporta allora una serie di conseguenze. La più ovvia è che +se si cerca di scrivere su una zona mappata in sola lettura si avrà +l'emissione di un segnale di violazione di accesso (\macro{SIGSEGV}), dato che +i permessi sul segmento di memoria relativo non consentono questo tipo di +accesso. + +È invece assai diversa la questione relativa agli accessi al di fuori della +regione di cui si è richiesta la mappatura. A prima vista infatti si potrebbe +ritenere che anch'essi debbano generare un segnale di violazione di accesso; +questo però non tiene conto del fatto che, essendo basata sul meccanismo della +paginazione, la mappatura in memoria non può che essere eseguita su un +segmento di dimensioni rigorosamente multiple di quelle di una pagina, ed in +generale queste potranno non corrispondere alle dimensioni effettive del file +o della sezione che si vuole mappare. Il caso più comune è quello illustrato +in \figref{fig:file_mmap_boundary}, in cui la sezione di file non rientra nei +confini di una pagina: in tal caso verrà il file sarà mappato su un segmento +di memoria che si estende fino al bordo della pagina successiva. + +\begin{figure}[htb] + \centering + \includegraphics[width=10cm]{img/mmap_boundary} + \caption{Schema della mappatura in memoria di una sezione di file di + dimensioni non corrispondenti al bordo di una pagina.} + \label{fig:file_mmap_boundary} +\end{figure} -\subsection{Le funzioni \func{poll} e \func{select}} -\label{sec:file_multiplexing} +In questo caso è possibile accedere a quella zona di memoria che eccede le +dimensioni specificate da \param{lenght}, senza ottenere un \macro{SIGSEGV} +poiché essa è presente nello spazio di indirizzi del processo, anche se non è +mappata sul file. Il comportamento del sistema è quello di restituire un +valore nullo per quanto viene letto, e di non riportare su file quanto viene +scritto. +Un caso più complesso è quello che si viene a creare quando le dimensioni del +file mappato sono più corte delle dimensioni della mappatura, oppure quando il +file è stato troncato, dopo che è stato mappato, ad una dimensione inferiore a +quella della mappatura in memoria. +\begin{figure}[htb] + \centering + \includegraphics[width=13cm]{img/mmap_exceed} + \caption{Schema della mappatura in memoria di file di dimensioni inferiori + alla lunghezza richiesta.} + \label{fig:file_mmap_exceed} +\end{figure} +In questa situazione, per la sezione di pagina parzialmente coperta dal +contenuto del file, vale esattamente quanto visto in precedenza; invece per la +parte che eccede, fino alle dimensioni date da \param{length}, l'accesso non +sarà più possibile, ma il segnale emesso non sarà \macro{SIGSEGV}, ma +\macro{SIGBUS}, come illustrato in \figref{fig:file_mmap_exceed}. +Non tutti i file possono venire mappati in memoria, dato che, come illustrato +in \figref{fig:file_mmap_layout}, la mappatura introduce una corrispondenza +biunivoca fra una sezione di un file ed una sezione di memoria. Questo +comporta che ad esempio non è possibile mappare in memoria file descriptor +relativi a pipe, socket e fifo, per i quali non ha senso parlare di +\textsl{sezione}. Lo stesso vale anche per alcuni file di dispositivo, che non +dispongono della relativa operazione \var{mmap} (si ricordi quanto esposto in +\secref{sec:file_vfs_work}). Si tenga presente però che esistono anche casi di +dispositivi (un esempio è l'interfaccia al ponte PCI-VME del chip Universe) +che sono utilizzabili solo con questa interfaccia. -\section{File locking} +Dato che passando attraverso una \func{fork} lo spazio di indirizzi viene +copiato integralmente, i file mappati in memoria verranno ereditati in maniera +trasparente dal processo figlio, mantenendo gli stessi attributi avuti nel +padre; così se si è usato \macro{MAP\_SHARED} padre e figlio accederanno allo +stesso file in maniera condivisa, mentre se si è usato \macro{MAP\_PRIVATE} +ciascuno di essi manterrà una sua versione privata indipendente. Non c'è +invece nessun passaggio attraverso una \func{exec}, dato che quest'ultima +sostituisce tutto lo spazio degli indirizzi di un processo con quello di un +nuovo programma. + +Quando si effettua la mappatura di un file vengono pure modificati i tempi ad +esso associati (di cui si è trattato in \secref{sec:file_file_times}). Il +valore di \var{st\_atime} può venir cambiato in qualunque istante a partire +dal momento in cui la mappatura è stata effettuata: il primo riferimento ad +una pagina mappata su un file aggiorna questo tempo. I valori di +\var{st\_ctime} e \var{st\_mtime} possono venir cambiati solo quando si è +consentita la scrittura sul file (cioè per un file mappato con +\macro{PROT\_WRITE} e \macro{MAP\_SHARED}) e sono aggiornati dopo la scrittura +o in corrispondenza di una eventuale \func{msync}. + +Dato per i file mappati in memoria le operazioni di I/O sono gestite +direttamente dalla memoria virtuale, occorre essere consapevoli delle +interazioni che possono esserci con operazioni effettuate con l'interfaccia +standard dei file di \capref{cha:file_unix_interface}. Il problema è che una +volta che si è mappato un file, le operazioni di lettura e scrittura saranno +eseguite sulla memoria, e riportate su disco in maniera autonoma dal sistema +della memoria virtuale. + +Pertanto se si modifica un file con l'interfaccia standard queste modifiche +potranno essere visibili o meno a seconda del momento in cui la memoria +virtuale trasporterà dal disco in memoria quella sezione del file, perciò è +del tutto imprevedibile il risultato della modifica di un file nei confronti +del contenuto della memoria mappata su cui è mappato. + +Per quanto appena visto, è sempre sconsigliabile eseguire scritture su file +attraverso l'interfaccia standard, quando lo si è mappato in memoria, è invece +possibile usare l'interfaccia standard per leggere un file mappato in memoria, +purché si abbia una certa cura; infatti l'interfaccia dell'I/O mappato in +memoria mette a disposizione la funzione \func{msync} per sincronizzare il +contenuto della memoria mappata con il file su disco; il suo prototipo è: +\begin{functions} + \headdecl{unistd.h} + \headdecl{sys/mman.h} + + \funcdecl{int msync(const void *start, size\_t length, int flags)} + + Sincronizza i contenuti di una sezione di un file mappato in memoria. + + \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di + errore nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\macro{EINVAL}] O \param{start} non è multiplo di \macro{PAGESIZE}, + o si è specificato un valore non valido per \param{flags}. + \item[\macro{EFAULT}] L'intervallo specificato non ricade in una zona + precedentemente mappata. + \end{errlist} + } +\end{functions} + +La funzione esegue la sincronizzazione di quanto scritto nella sezione di +memoria indicata da \param{start} e \param{offset}, scrivendo le modifiche sul +file (qualora questo non sia già stato fatto). Provvede anche ad aggiornare i +relativi tempi di modifica. In questo modo si è sicuri che dopo l'esecuzione +di \func{msync} le funzioni dell'interfaccia standard troveranno un contenuto +del file aggiornato. + +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|l|} + \hline + \textbf{Valore} & \textbf{Significato} \\ + \hline + \hline + \macro{MS\_ASYNC} & Richiede la sincronizzazione.\\ + \macro{MS\_SYNC} & Attende che la sincronizzazione si eseguita.\\ + \macro{MS\_INVALIDATE}& Richiede che le altre mappature dello stesso file + siano invalidate.\\ + \hline + \end{tabular} + \caption{Valori dell'argomento \param{flag} di \func{msync}.} + \label{tab:file_mmap_rsync} +\end{table} + +L'argomento \param{flag} è specificato come maschera binaria composta da un OR +dei valori riportati in \tabref{tab:file_mmap_rsync}, di questi però +\macro{MS\_ASYNC} e \macro{MS\_SYNC} sono incompatibili; con il primo valore +infatti la funzione si limita ad inoltrare la richiesta di sincronizzazione al +meccanismo della memoria virtuale, ritornando subito, mentre con il secondo +attende che la sincronizzazione sia stata effettivamente eseguita. Il terzo +flag fa invalidare le pagine di cui si richiede la sincronizzazione per tutte +le mappature dello stesso file, così che esse possano essere immediatamente +aggiornate ai nuovi valori. + +Una volta che si sono completate le operazioni di I/O si può eliminare la +mappatura della memoria usando la funzione \func{munmap}, il suo prototipo è: +\begin{functions} + \headdecl{unistd.h} + \headdecl{sys/mman.h} + + \funcdecl{int munmap(void *start, size\_t length)} + + Rilascia la mappatura sulla sezione di memoria specificata. + + \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di + errore nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\macro{EINVAL}] L'intervallo specificato non ricade in una zona + precedentemente mappata. + \end{errlist} + } +\end{functions} + +La funzione cancella la mappatura per l'intervallo specificato attraverso +\param{start} e \param{length}, ed ogni successivo accesso a tale regione +causerà un errore di accesso in memoria. L'argomento \param{start} deve essere +allineato alle dimensioni di una pagina di memoria, e la mappatura di tutte le +pagine contenute (anche parzialmente) nell'intervallo indicato, verrà rimossa. +Indicare un intervallo che non contiene pagine mappate non è un errore. + +Alla conclusione del processo, ogni pagina mappata verrà automaticamente +rilasciata, mentre la chiusura del file descriptor usato per effettuare la +mappatura in memoria non ha alcun effetto sulla stessa. + + +\section{Il file locking} \label{sec:file_locking} -In \secref{sec:file_sharing} abbiamo preso in esame le mosalità in cui un -sistema unix-like gestisce la condivisione dei file. In quell'occasione si è -visto come, con l'eccezione dei file aperti in \textit{append mode}, quando -più processi scrivono contemporaneamente sullo stesso file non è possibile -determinare la sequenza in cui essi opereranno. +In \secref{sec:file_sharing} abbiamo preso in esame le modalità in cui un +sistema unix-like gestisce la condivisione dei file da parte di processi +diversi. In quell'occasione si è visto come, con l'eccezione dei file aperti +in \textit{append mode}, quando più processi scrivono contemporaneamente sullo +stesso file non è possibile determinare la sequenza in cui essi opereranno. -Questo causa la possibilità di race condition; in generale le situazioni più -comuni sono due: l'interazione fra un processo che scrive e altri che leggono, -in cui questi ultimi possono leggere informazioni scritte solo in maniera -parziale o incompleta; o quella in cui diversi processi scrivono, mescolando -in maniera imprevedebile il loro output sul file. +Questo causa la possibilità di race condition\index{race condition}; in +generale le situazioni più comuni sono due: l'interazione fra un processo che +scrive e altri che leggono, in cui questi ultimi possono leggere informazioni +scritte solo in maniera parziale o incompleta; o quella in cui diversi +processi scrivono, mescolando in maniera imprevedibile il loro output sul +file. In tutti questi casi il \textit{file locking} è la tecnica che permette di evitare le race condition, attraverso una serie di funzioni che permettono di -bloccare l'accesso al file da parte di altri processi così da evitare le +bloccare l'accesso al file da parte di altri processi, così da evitare le sovrapposizioni, e garantire la atomicità delle operazioni di scrittura. -\subsection{Il \textit{advisory locking}} + +\subsection{L'\textit{advisory locking}} \label{sec:file_record_locking} La prima modalità di file locking che è stata implementata nei sistemi -unix-like è quella che viene usualmente chiamata \textit{advisory locking}, in -quanto è il processo, e non il sistema, che si incarica di verificare se -esiste una condizione di blocco per l'accesso ai file. +unix-like è quella che viene usualmente chiamata \textit{advisory + locking},\footnote{Stevens in \cite{APUE} fa riferimento a questo argomento + come al \textit{record locking}, dizione utilizzata anche dal manuale delle + \acr{glibc}; nelle pagine di manuale si parla di \textit{discretionary file + lock} per \func{fcntl} e di \textit{advisory locking} per \func{flock}, + mentre questo nome viene usato anche da Stevens per riferirsi al + \textit{file locking} di POSIX. Dato che la dizione \textit{record locking} + è quantomeno ambigua in quanto non esiste niente che possa fare riferimento + al concetto di \textit{record}, alla fine si è scelto di mantenere il nome + \textit{advisory locking}.} in quanto sono i singoli processi, e non il +sistema, che si incaricano di asserire e verificare se esistono delle +condizioni di blocco per l'accesso ai file. Questo significa che le funzioni +\func{read} o \func{write} non risentono affatto della presenza di un +eventuale blocco, e che sta ai vari processi controllare esplicitamente lo +stato dei file condivisi prima di accedervi, implementando un opportuno +protocollo. + +In generale si distinguono due tipologie di blocco per un file: la prima è il +cosiddetto \textit{shared lock}, detto anche \textit{read lock} in quanto +serve a bloccare l'accesso in scrittura su un file affinché non venga +modificato mentre lo si legge. Si parla di \textsl{blocco condiviso} in quanto +più processi possono richiedere contemporaneamente uno \textit{shared lock} +su un file per proteggere il loro accesso in lettura. + +La seconda tipologia è il cosiddetto \textit{exclusive lock}, detto anche +\textit{write lock} in quanto serve a bloccare l'accesso su un file (sia in +lettura che in scrittura) da parte di altri processi mentre lo si sta +scrivendo. Si parla di \textsl{blocco esclusivo} appunto perché un solo +processo alla volta può richiedere un \textit{exclusive lock} su un file per +proteggere il suo accesso in scrittura. + +In Linux sono disponibili due interfacce per utilizzare l'\textit{advisory + locking}, la prima è quella derivata da BSD, che è basata sulla funzione +\func{flock}, la seconda è quella standardizzata da POSIX.1 (derivata da +System V), che è basata sulla funzione \func{fcntl}. I \textit{file lock} +sono implementati in maniera completamente indipendente nelle due interfacce, +che pertanto possono coesistere senza interferenze. +Entrambe le interfacce prevedono la stessa procedura di funzionamento: si +inizia sempre con il richiedere l'opportuno \textit{file lock} (un +\textit{exclusive lock} per una scrittura, uno \textit{shared lock} per una +lettura) prima di eseguire l'accesso ad un file. Se il lock viene acquisito +il processo prosegue l'esecuzione, altrimenti (a meno di non aver richiesto un +comportamento non bloccante) viene posto in stato di sleep. Una volta finite +le operazioni sul file si deve provvedere a rimuovere il lock. Si ricordi che +la condizione per acquisire uno \textit{shared lock} è che il file non abbia +già un \textit{exclusive lock} attivo, mentre per acquisire un +\textit{exclusive lock} non deve essere presente nessun tipo di blocco. + + +\subsection{La funzione \func{flock}} +\label{sec:file_flock} + +La prima interfaccia per il file locking, quella derivata da BSD, permette di +eseguire un blocco solo su un intero file; la funzione usata per richiedere e +rimuovere un \textit{file lock} è \func{flock}, ed il suo prototipo è: +\begin{prototype}{sys/file.h}{int flock(int fd, int operation)} + + Applica o rimuove un \textit{file lock} sul file \param{fd}. + + \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di + errore, nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\macro{EWOULDBLOCK}] Il file ha già un blocco attivo, e si è + specificato \macro{LOCK\_NB}. + \end{errlist} + } +\end{prototype} + +La funzione può essere usata per acquisire o rilasciare un blocco a seconda di +quanto specificato tramite il valore dell'argomento \param{operation}, questo +viene interpretato come maschera binaria, e deve essere passato utilizzando le +costanti riportate in \tabref{tab:file_flock_operation}. + +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|l|} + \hline + \textbf{Valore} & \textbf{Significato} \\ + \hline + \hline + \macro{LOCK\_SH} & Asserisce uno \textit{shared lock} sul file.\\ + \macro{LOCK\_EX} & Asserisce un \textit{esclusive lock} sul file.\\ + \macro{LOCK\_UN} & Sblocca il file.\\ + \macro{LOCK\_NB} & Impedisce che la funzione si blocchi nella + richiesta di un \textit{file lock}.\\ + \hline + \end{tabular} + \caption{Valori dell'argomento \param{operation} di \func{flock}.} + \label{tab:file_flock_operation} +\end{table} + +I primi due valori, \macro{LOCK\_SH} e \macro{LOCK\_EX} permettono di +richiedere un \textit{file lock}, ed ovviamente devono essere usati in maniera +alternativa. Se si specifica anche \macro{LOCK\_NB} la funzione non si +bloccherà qualora il lock non possa essere acquisito, ma ritornerà subito con +un errore di \macro{EWOULDBLOCK}. Per rilasciare un lock si dovrà invece usare +\macro{LOCK\_NB}. + +La semantica del file locking di BSD è diversa da quella del file locking +POSIX, in particolare per quanto riguarda il comportamento dei lock nei +confronti delle due funzioni \func{dup} e \func{fork}. Per capire queste +differenze occorre prima descrivere con maggiore dettaglio come viene +realizzato il file locking nel kernel. + +In \figref{fig:file_flock_struct} si è riportato uno schema essenziale +dell'implementazione del file locking in Linux; il punto fondamentale da +capire è che un lock, qualunque sia l'interfaccia che si usa, anche se +richiesto attraverso un file descriptor, agisce sempre su un file; perciò le +informazioni relative agli eventuali \textit{file lock} sono mantenute a +livello di inode,\footnote{in particolare, come accennato in + \figref{fig:file_flock_struct}, i \textit{file lock} sono mantenuti un una + \textit{linked list}\index{linked list} di strutture \var{file\_lock}. La + lista è referenziata dall'indirizzo di partenza mantenuto dal campo + \var{i\_flock} della struttura \var{inode} (per le definizioni esatte si + faccia riferimento al file \file{fs.h} nei sorgenti del kernel). Un bit del + campo \var{fl\_flags} di specifica se si tratta di un lock in semantica BSD + (\macro{FL\_FLOCK}) o POSIX (\macro{FL\_POSIX}).} dato che questo è l'unico +riferimento in comune che possono avere due processi diversi che aprono lo +stesso file. + +\begin{figure}[htb] + \centering + \includegraphics[width=13cm]{img/file_flock} + \caption{Schema dell'architettura del file locking, nel caso particolare + del suo utilizzo da parte dalla funzione \func{flock}.} + \label{fig:file_flock_struct} +\end{figure} + +La richiesta di un file lock prevede una scansione della lista per determinare +se l'acquisizione è possibile, ed in caso positivo l'aggiunta di un nuovo +elemento.\footnote{cioè una nuova struttura \var{file\_lock}.} Nel caso dei +lock creati con \func{flock} la semantica della funzione prevede che sia +\func{dup} che \func{fork} non creino ulteriori istanze di un \textit{file + lock} quanto piuttosto degli ulteriori riferimenti allo stesso. Questo viene +realizzato dal kernel associando ad ogni nuovo \textit{file lock} un +puntatore\footnote{il puntatore è mantenuto nel campo \var{fl\_file} di + \var{file\_lock}, e viene utilizzato solo per i lock creati con la semantica + BSD.} alla voce nella \textit{file table} da cui si è richiesto il blocco, +che così ne identifica il titolare. + +Questa struttura comporta che, quando si richiede la rimozione di un file +lock, il kernel acconsenta solo se la richiesta proviene da un file descriptor +che fa riferimento ad una voce nella file table corrispondente a quella +registrata nel blocco. Allora se ricordiamo quanto visto in +\secref{sec:file_dup} e \secref{sec:file_sharing}, e cioè che i file +descriptor duplicati e quelli ereditati in un processo figlio puntano sempre +alla stessa voce nella file table, si può capire immediatamente quali sono le +conseguenze nei confronti delle funzioni \func{dup} e \func{fork}. + +Sarà cioè possibile rimuovere un file lock attraverso uno qualunque dei file +descriptor che fanno riferimento alla stessa voce nella file table, quindi +anche se questo è diverso da quello con cui lo si è +creato,\footnote{attenzione, questo non vale se il file descriptor fa + riferimento allo stesso file, ma attraverso una voce diversa della file + table, come accade tutte le volte che si apre più volte lo stesso file.} o +se si esegue la rimozione in un processo figlio; inoltre una volta tolto un +file lock, la rimozione avrà effetto su tutti i file descriptor che +condividono la stessa voce nella file table, e quindi, nel caso di file +descriptor ereditati attraverso una \func{fork}, anche su processi diversi. + +Infine, per evitare che la terminazione imprevista di un processo lasci attivi +dei file lock, quando un file viene chiuso il kernel provveda anche a +rimuovere tutti i lock ad esso associati. Anche in questo caso occorre tenere +presente cosa succede quando si hanno file descriptor duplicati; in tal caso +infatti il file non verrà effettivamente chiuso (ed il lock rimosso) fintanto +che non viene rilasciata la relativa voce nella file table; la rimozione cioè +avverrà solo quando tutti i file descriptor che fanno riferimento alla stessa +voce sono stati chiusi, quindi, nel caso ci siano processi figli che +mantengono ancora aperto un file descriptor, il lock non sarà rilasciato. + +Si tenga presente che \func{flock} non è in grado di funzionare per i file +mantenuti su NFS, in questo caso, se si ha la necessità di eseguire il +\textit{file locking}, occorre usare l'interfaccia basata su \func{fcntl} che +può funzionare anche attraverso NFS, a condizione che sia il client che il +server supportino questa funzionalità. + + +\subsection{Il file locking POSIX} +\label{sec:file_posix_lock} + +La seconda interfaccia per l'\textit{advisory locking} disponibile in Linux è +quella standardizzata da POSIX, basata sulla funzione \func{fcntl}. Abbiamo +già trattato questa funzione nelle sue molteplici funzionalità in +\secref{sec:file_fcntl}; quando la si impiega per il \textit{file locking} +però essa viene usata solo secondo il prototipo: +\begin{prototype}{fcntl.h}{int fcntl(int fd, int cmd, struct flock *lock)} + + Applica o rimuove un \textit{file lock} sul file \param{fd}. + + \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di + errore, nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\macro{EACCES}] L'operazione è proibita per la presenza di + \textit{file lock} da parte di altri processi. + \item[\macro{ENOLCK}] Il sistema non ha le risorse per il locking: ci sono + troppi segmenti di lock aperti, si è esaurita la tabella dei lock, o il + protocollo per il locking remoto è fallito. + \item[\macro{EDEADLK}] Si è richiesto un lock su una regione bloccata da + un altro processo che è a sua volta in attesa dello sblocco di un lock + mantenuto dal processo corrente; si avrebbe pertanto un + \textit{deadlock}. Non è garantito che il sistema riconosca sempre + questa situazione. + \item[\macro{EINTR}] La funzione è stata interrotta da un segnale prima di + poter acquisire un lock. + \end{errlist} + ed inoltre \macro{EBADF}, \macro{EFAULT}. + } +\end{prototype} + +Al contrario di quanto avviene con l'interfaccia basata su \func{flock} con +\func{fcntl} è possibile bloccare anche delle singole sezioni di un file; +inoltre la funzione permette di leggere le informazioni relative ai blocchi +esistenti. Per poter fare tutto questo la funzione utilizza come terzo +argomento una apposita struttura \var{flock} (la cui definizione è riportata +in \figref{fig:struct_flock}) che contiene tutte le specifiche di un dato file +lock. + +\begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{15cm} + \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{} +struct flock { + short int l_type; /* Type of lock: F_RDLCK, F_WRLCK, or F_UNLCK. */ + short int l_whence; /* Where `l_start' is relative to (like `lseek'). */ + off_t l_start; /* Offset where the lock begins. */ + off_t l_len; /* Size of the locked area; zero means until EOF. */ + pid_t l_pid; /* Process holding the lock. */ +}; + \end{lstlisting} + \end{minipage} + \normalsize + \caption{La struttura \type{flock}, usata da \func{fcntl} per il file + locking.} + \label{fig:struct_flock} +\end{figure} + +L'operazione effettivamente svolta dalla funzione è stabilita dal valore +dall'argomento \param{cmd} che, come già riportato in \secref{sec:file_fcntl}, +specifica l'azione da compiere; i valori relativi al file locking sono tre: +\begin{basedescript}{\desclabelwidth{2.0cm}} +\item[\macro{F\_GETLK}] verifica se il file lock specificato dalla struttura + puntata da \param{lock} non è bloccato da qualche altro lock: in caso + affermativo sovrascrive la struttura con i valori relativi a quest'ultimo, + altrimenti si limita a impostarne il campo \var{l\_type} con + \macro{F\_UNLCK}. +\item[\macro{F\_SETLK}] se il campo \var{l\_type} della struttura puntata da + \param{lock} è \macro{F\_RDLCK} o \macro{F\_WRLCK} richiede il + corrispondente file lock, se è \macro{F\_UNLCK} lo rilascia. Nel caso la + richiesta non possa essere soddisfatta a causa di un lock preesistente la + funzione ritorna immediatamente con un errore di \macro{EACCES} o di + \macro{EAGAIN}. +\item[\macro{F\_SETLKW}] è identica a \macro{F\_SETLK}, ma se la richiesta di + un lock non può essere soddisfatta per la presenza di un altro blocco, mette + il processo in stato di attesa fintanto che il lock precedente non viene + rilasciato. Se l'attesa viene interrotta da un segnale la funzione ritorna + con un errore di \macro{EINTR}. +\end{basedescript} + +Come accennato nell'interfaccia POSIX ogni file lock viene associato ad una +struttura \func{flock}; i tre campi \var{l\_whence}, \var{l\_start} e +\var{l\_len}, servono a specificare la sezione del file a cui fa riferimento +il lock, \var{l\_start} specifica il byte di partenza, e \var{l\_len} la +lunghezza della sezione; \var{l\_whence} infine imposta il riferimento da cui +contare \var{l\_start} e segue la stessa semantica dell'omonimo argomento di +\func{lseek}, coi tre possibili valori \macro{SEEK\_SET}, \macro{SEEK\_CUR} e +\macro{SEEK\_END} (si vedano le relative descrizioni in +\secref{sec:file_lseek}). + +Si tenga presente che un lock può essere richiesto anche per una regione al di +là della corrente fine del file, così che una eventuale estensione dello +stesso resti coperta dal blocco. Se si specifica un valore nullo per +\var{l\_len} il blocco si considera esteso fino alla dimensione massima del +file; in questo modo è possibile bloccare una qualunque regione a partire da +un certo punto fino alla fine del file, coprendo automaticamente quanto +eventualmente aggiunto in coda allo stesso. + +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|l|} + \hline + \textbf{Valore} & \textbf{Significato} \\ + \hline + \hline + \macro{F\_RDLCK} & Richiede un blocco condiviso (\textit{read lock}).\\ + \macro{F\_WRLCK} & Richiede un blocco esclusivo (\textit{write lock}).\\ + \macro{F\_UNLCK} & Richiede l'eliminazione di un lock.\\ + \hline + \end{tabular} + \caption{Valori possibili per il campo \var{l\_type} di \func{flock}.} + \label{tab:file_flock_type} +\end{table} + +Il tipo di file lock richiesto viene specificato dal campo \var{l\_type}, esso +può assumere i tre valori riportati in \tabref{tab:file_flock_type}, che +permettono di richiedere rispettivamente uno \textit{shared lock}, un +\textit{esclusive lock}, e la rimozione di un lock precedentemente acquisito. + +\begin{figure}[htb] + \centering + \includegraphics[width=13cm]{img/file_posix_lock} + \caption{Schema dell'architettura del file locking, nel caso particolare + del suo utilizzo secondo l'interfaccia standard POSIX.} + \label{fig:file_posix_lock} +\end{figure} + +Infine il campo \var{l\_pid} riporta (viene usato solo in lettura, quando si +chiama \func{fcntl} con \macro{F\_GETLK}) qual'è il processo cui appartiene il +file lock. Nella semantica POSIX infatti il comportamento dei lock è diverso +rispetto a quanto visto in precedenza per \func{flock}. Lo schema della +struttura usata in questo caso è riportato in \figref{fig:file_posix_lock}; +come si vede essa è molto simile a quanto visto in +\figref{fig:file_flock_struct} per \func{flock}:\footnote{in questo caso si + sono evidenziati nella figura i campi di \var{file\_lock} significativi per + la semantica POSIX, in particolare adesso ciascun lock contiene, oltre al + \acr{pid} del processo in \var{fl\_pid}, la sezione di file che viene + bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}. La struttura è + comunque la stessa, solo che in questo caso nel campo \var{fl\_flags} è + impostato il bit \macro{FL\_POSIX} ed il campo \var{fl\_file} non viene + usato.} il lock è sempre associato all'inode, solo che in questo caso la +titolarità non viene identificata con il riferimento ad una voce nella file +table, ma con il valore del \acr{pid} del processo. + +Tutto ciò significa che la rimozione di un blocco viene effettuata +controllando che il \acr{pid} del processo richiedente corrisponda a quello +contenuto nel lock. Questa diversa modalità ha delle conseguenze precise +riguardo il comportamento dei lock POSIX. La prima conseguenza è che un lock +POSIX non viene mai ereditato attraverso una \func{fork}, dato che il processo +figlio avrà un \acr{pid} diverso, mentre passa indenne attraverso una +\func{exec} in quanto il \acr{pid} resta lo stesso. Questo comporta che, al +contrario di quanto avveniva con la semantica BSD, quando processo termina +tutti i file lock da esso detenuti vengono immediatamente rilasciati. + +La seconda conseguenza è che qualunque file descriptor che faccia riferimento +allo stesso file (che sia stato ottenuto con una \func{dup} o con una +\func{open} non fa differenza) può essere usato per rimuovere un lock, dato +che quello che conta è solo il \acr{pid} del processo. Da questo deriva una +ulteriore sottile differenza di comportamento: dato che alla chiusura di un +file i lock ad esso associati vengono rimossi, nella semantica POSIX basterà +chiudere un file descriptor per cancellare tutti i lock relativi al file cui +esso faceva riferimento, anche se questi fossero stati creati usando altri +file descriptor che restano aperti. + +Abbiamo visto come l'interfaccia POSIX per il file locking sia molto più +potente e flessibile di quella di BSD, ma è anche molto più complicata da +usare per le varie opzioni da passare a \func{fcntl}. Per questo motivo è +disponibile anche una interfaccia semplificata (ripresa da System V) che +utilizza la funzione \func{lockf}, il cui prototipo è: +\begin{prototype}{sys/file.h}{int lockf(int fd, int cmd, off\_t len)} + + Applica, controlla o rimuove un \textit{file lock} sul file \param{fd}. + + \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di + errore, nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\macro{EWOULDBLOCK}] Non è possibile acquisire il lock, e si è + selezionato \macro{LOCK\_NB}, oppure l'operazione è proibita perché il + file è mappato in memoria. + \item[\macro{ENOLCK}] Il sistema non ha le risorse per il locking: ci sono + troppi segmenti di lock aperti, si è esaurita la tabella dei lock. + \end{errlist} + ed inoltre \macro{EBADF}, \macro{EINVAL}. + } +\end{prototype} + +Il comportamento della funzione dipende dal valore dell'argomento \param{cmd} +che specifica quale azione eseguire; i valori possibili sono riportati in +\tabref{tab:file_lockf_type}. + +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|p{8cm}|} + \hline + \textbf{Valore} & \textbf{Significato} \\ + \hline + \hline + \macro{LOCK\_SH}& Richiede uno \textit{shared lock}. Più processi possono + mantenere un lock condiviso sullo stesso file.\\ + \macro{LOCK\_EX}& Richiede un \textit{exclusive lock}. Un solo processo + alla volta può mantenere un lock esclusivo su un file. \\ + \macro{LOCK\_UN}& Sblocca il file.\\ + \macro{LOCK\_NB}& Non blocca la funzione quando il lock non è disponibile, + si specifica sempre insieme ad una delle altre operazioni + con un OR aritmetico dei valori.\\ + \hline + \end{tabular} + \caption{Valori possibili per il campo \var{cmd} di \func{lockf}.} + \label{tab:file_lockf_type} +\end{table} + +Qualora il lock non possa essere acquisito, a meno di non aver specificato +\macro{LOCK\_NB}, la funzione si blocca fino alla disponibilità dello stesso. +Dato che la funzione è implementata utilizzando \func{fcntl} la semantica +delle operazioni è la stessa di quest'ultima (pertanto la funzione non è +affatto equivalente a \func{flock}). \subsection{Il \textit{mandatory locking}} \label{sec:file_mand_locking} -Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVR4, +Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4, +per introdurre un file locking che, come dice il nome, fosse effettivo +indipendentemente dai controlli eseguiti da un processo. Con il +\textit{mandatory locking} infatti è possibile far eseguire il blocco del file +direttamente al sistema, così che, anche qualora non si predisponessero le +opportune verifiche nei processi, questo verrebbe comunque rispettato. +Per poter utilizzare il \textit{mandatory locking} è stato introdotto un +utilizzo particolare del bit \acr{sgid}. Se si ricorda quanto esposto in +\secref{sec:file_suid_sgid}), esso viene di norma utilizzato per cambiare il +groupid effettivo con cui viene eseguito un programma, ed è pertanto sempre +associato alla presenza del permesso di esecuzione per il gruppo. Impostando +questo bit su un file senza permesso di esecuzione in un sistema che supporta +il \textit{mandatory locking}, fa sì che quest'ultimo venga attivato per il +file in questione. In questo modo una combinazione dei permessi +originariamente non contemplata, in quanto senza significato, diventa +l'indicazione della presenza o meno del \textit{mandatory + locking}.\footnote{un lettore attento potrebbe ricordare quanto detto in + \secref{sec:file_chmod} e cioè che il bit \acr{sgid} viene cancellato (come + misura di sicurezza) quando di scrive su un file, questo non vale quando + esso viene utilizzato per attivare il \textit{mandatory locking}.} +L'uso del \textit{mandatory locking} presenta vari aspetti delicati, dato che +neanche root può passare sopra ad un lock; pertanto un processo che blocchi un +file cruciale può renderlo completamente inaccessibile, rendendo completamente +inutilizzabile il sistema\footnote{il problema si potrebbe risolvere + rimuovendo il bit \acr{sgid}, ma non è detto che sia così facile fare questa + operazione con un sistema bloccato.} inoltre con il \textit{mandatory + locking} si può bloccare completamente un server NFS richiedendo una lettura +su un file su cui è attivo un lock. Per questo motivo l'abilitazione del +mandatory locking è di norma disabilitata, e deve essere attivata filesystem +per filesystem in fase di montaggio (specificando l'apposita opzione di +\func{mount} riportata in \tabref{tab:sys_mount_flags}, o con l'opzione +\cmd{mand} per il comando). +Si tenga presente inoltre che il \textit{mandatory locking} funziona +sull'interfaccia POSIX di \func{fcntl}, questo significa che non ha nessun +effetto sui lock richiesti con l'interfaccia di \func{flock}, ed inoltre che +la granularità del lock è quella del singolo byte, come per \func{fcntl}. + +La sintassi di acquisizione dei lock è esattamente la stessa vista in +precedenza per \func{fcntl} e \func{lockf}, la differenza è che in caso di +mandatory lock attivato non è più necessario controllare la disponibilità di +accesso al file, ma si potranno usare direttamente le ordinarie funzioni di +lettura e scrittura e sarà compito del kernel gestire direttamente il file +locking. + +Questo significa che in caso di read lock la lettura dal file potrà avvenire +normalmente con \func{read}, mentre una \func{write} si bloccherà fino al +rilascio del lock, a meno di non aver aperto il file con \macro{O\_NONBLOCK}, +nel qual caso essa ritornerà immediatamente con un errore di \macro{EAGAIN}. + +Se invece si è acquisito un write lock tutti i tentativi di leggere o scrivere +sulla regione del file bloccata fermeranno il processo fino al rilascio del +lock, a meno che il file non sia stato aperto con \macro{O\_NONBLOCK}, nel +qual caso di nuovo si otterrà un ritorno immediato con l'errore di +\macro{EAGAIN}. + +Infine occorre ricordare che le funzioni di lettura e scrittura non sono le +sole ad operare sui contenuti di un file, e che sia \func{creat} che +\func{open} (quando chiamata con \macro{O\_TRUNC}) effettuano dei cambiamenti, +così come \func{truncate}, riducendone le dimensioni (a zero nei primi due +casi, a quanto specificato nel secondo). Queste operazioni sono assimilate a +degli accessi in scrittura e pertanto non potranno essere eseguite (fallendo +con un errore di \macro{EAGAIN}) su un file su cui sia presente un qualunque +lock (le prime due sempre, la terza solo nel caso che la riduzione delle +dimensioni del file vada a sovrapporsi ad una regione bloccata). + +L'ultimo aspetto della interazione del \textit{mandatory locking} con le +funzioni di accesso ai file è quello relativo ai file mappati in memoria +appena trattati in \secref{sec:file_memory_map}; anche in tal caso infatti, +quando si esegue la mappatura con l'opzione \macro{MAP\_SHARED}, si ha un +accesso al contenuto del file. Lo standard SVID prevede che sia impossibile +eseguire il memory mapping di un file su cui sono presenti dei +lock\footnote{alcuni sistemi, come HP-UX, sono ancora più restrittivi e lo + impediscono anche in caso di \textit{advisory locking}, anche se questo non + ha molto senso.} in Linux è stata però fatta la scelta implementativa di +seguire questo comportamento soltanto quando si chiama \func{mmap} con +l'opzione \macro{MAP\_SHARED} (nel qual caso la funzione fallisce con il +solito \macro{EAGAIN}). -\section{File mappati in memoria} -\label{sec:file_memory_map}