From f34bc210398c21e197ec81dc2acc1798330431fb Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Thu, 1 Aug 2002 16:36:41 +0000 Subject: [PATCH] Completato I/O vettorizzato, si comincia il memory mapped. --- Makefile | 9 +- fileadv.tex | 316 +++++++++++++++++++++++++++++++++------------------- gapil.tex | 1 - 3 files changed, 208 insertions(+), 118 deletions(-) diff --git a/Makefile b/Makefile index 21ca364..e50363e 100644 --- a/Makefile +++ b/Makefile @@ -1,15 +1,14 @@ -all: html dvi ps pdf img -html: +html: *.tex latex2html -local_icons -no_math -no_footnode gapil.tex -dvi: +gapil.dvi: *.tex latex gapil.tex -pdf: +gapil.pdf: *.tex pdflatex gapil.tex -ps: +gapil.ps: gapil.dvi dvips -o gapil.ps gapil.dvi install: diff --git a/fileadv.tex b/fileadv.tex index a0c5f05..9adbf64 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -398,7 +398,7 @@ attraverso l'uso di una apposita struttura \type{aiocb} (il cui nome sta per 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à di questa funzionalità. +disponibilità dell'interfaccia per l'I/O asincrono. \begin{figure}[!htb] \footnotesize \centering @@ -423,17 +423,18 @@ struct aiocb \end{figure} Le operazioni di I/O asincrono possono essere effettuate solo su un file già -aperto, il cui file descriptor deve essere specificato tramite il campo -\var{aio\_fildes}; il file deve inoltre supportare la funzione \func{lseek}, +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. -Dato che più operazioni possono essere eseguita in maniera asincrona, il -concetto di posizione corrente sul file viene a mancare; pertanto ciascuna -operazione 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} poi -andrà specificato l'indirizzo del buffer usato per l'I/O, ed in -\var{aio\_nbytes} la lunghezza del trasferimento. +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 settare la priorità delle operazioni di I/O.\footnote{in generale perché ciò sia possibile occorre che la @@ -443,9 +444,10 @@ di I/O.\footnote{in generale perch 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 dalla funzione \func{lio\_listio}, che -permette di far partire una serie di operazioni in contemporanea su una lista -di file. Tramite questo campo si specifica quale è la natura di ciascuna di +Il campo \var{aio\_lio\_opcode} è usato soltanto dalla funzione +\func{lio\_listio}, che, come vedremo più avanti, permette di eseguire con una +sola chiamanta 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] @@ -485,10 +487,10 @@ che indica le modalit con gli attributi specificati da \var{sigev\_notify\_attribute}. \end{basedescript} -Le due funzioni base dell'interfaccia POSIX.1b per l'I/O asincrono sono -\func{aio\_read} e \func{aio\_write}. Esse servono a richiedere una lettura -od una scrittura asincrona di dati usando la struttura \type{aiocb} appena -descritta; i rispettivi prototipi sono: +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} @@ -525,18 +527,17 @@ Si tenga inoltre presente che deallocare la memoria indirizzata da 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, effettuando le chiamate all'interno di una subroutine, -e che non si deve riutilizzare la stessa struttura per un'ulteriore operazione -fintanto che la precedente non si sia ultimata. In generale per ogni -operazione di I/O asincrono si deve utilizzare una ed una sola struttura -\type{aiocb}. - -Si ricordi che, operando in modalità asincrona, il successo di queste funzioni -non implica che le operazioni richieste siano state effettivamente eseguite in -maniera corretta. Per verificare l'esito delle operazioni 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 è: +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)} @@ -559,19 +560,19 @@ stato di errore; il suo prototipo 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 di errore, ed esegue -il settaggio di \var{errno}. In caso caso di errore esso può essere sia uno -dei precedentemente specificati \macro{EINVAL} ed \macro{EBADF}, dovuti ad un -valore errato per \param{aiocbp} che uno dei possibili errori dovuti alle -chiamate al sistema sottostanti l'esecuzione dell'operazione di I/O richiesta, -relativi alle funzioni \func{read}, \func{write} e \func{fsync}. - - -Una volta che si sia certi che le operazioni si siano concluse (cioè dopo che -una chiamata ad \func{aio\_error} non ha restituito \macro{EINPROGRESS}, si -può usare la seconda funzione dell'interfaccia, \func{aio\_return}, per -verificare il completamento delle operazioni di I/O asincrono, il cui -prototipo è: +conclusa con successo, altrimenti restituisce il codice dell'errore +verificatosi, ed esegue il corrispondente settaggio 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)} @@ -583,11 +584,12 @@ Recupera il valore dello stato di ritorno delle operazioni di I/O associate a \end{prototype} La funzione deve essere chiamata una sola volte per ciascuna operazione -asincrona, essa infatti fa sì che il sistema rilasci le risorse associate a -ciascuna operazione. Per questo motivo occorre chiamare la funzione solo dopo -che l'operazione cui \param{aiocbp} fa riferimento si è completata. +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 relativa all'operazione eseguita, +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 @@ -609,14 +611,14 @@ Richiede la sincronizzazione dei dati per il file indicato da \param{aiocbp}. \macro{EAGAIN}, \macro{EBADF} o \macro{EINVAL}.} \end{prototype} -La funzione richiede la sincronizzazione delle operazioni di I/O, essendo la -richiesta asincrona, 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} (vedi \secref{sec:file_sync}). +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 @@ -643,29 +645,35 @@ da \param{aiocbp}. 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 -\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. - -I possibili valori di ritorno di \func{aio\_cancel} sono tre: -\macro{AIO\_ALLDONE} indica che le operazioni di cui si è richiesta la -cancellazione sono state già completate, \macro{AIO\_CANCELED} indica che -tutte le operazioni richieste sono state cancellate, e -\macro{AIO\_NOTCANCELED} che alcune delle operazioni erano in corso e non sono -state cancellate. - -In quest'ultimo caso occorre chiamare \func{aio\_error} per determinare quali -sono le operazioni cancellate. Le operazioni che non sono state cancellate -proseguono il loro corso normale, compreso quanto relativo al meccanismo di -notifica del loro avvenuto completamento. - -Benché l'I/O asincrono preveda un meccanismo di notifica, che permette di -bloccare un processo in maniera relativamente semplice fino al completamento -di una determinata operazione, lo standard fornisce anche una apposita -funzione, \func{aio\_suspend}, che permette di sospendere l'esecuzione di un -processo fino al completamento di una specifica operazione; il suo prototipo -è: +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)} @@ -685,20 +693,19 @@ processo fino al completamento di una specifica operazione; il suo prototipo } \end{prototype} -La funzione permette di bloccare il processo chiamante 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 una attesa -infinita. - -Lo standard 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 è: +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)} @@ -718,36 +725,104 @@ lettura o scrittura; il suo prototipo \end{prototype} La funzione esegue la richiesta delle \param{nent} operazioni indicate dalla -lista \param{list}; questa deve contenere gli indirizzi di altrettanti 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{description*} -\item[\macro{LIO\_READ}] richiede una operazione di lettura. -\item[\macro{LIO\_WRITE}] richiede una operazione di scrittura. -\item[\macro{LIO\_NOP}] non effettua nessuna operazione. -\end{description*} -l'ultimo 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. +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 spercifica \macro{LIO\_NOWAIT} la funzione ritorna immediatamente dopo aver messo in coda tutte le richieste. In questo caso il chiamante può richiedere -una notifica del completamento di tutte le richieste settando \param{sig}. - +la notifica del completamento di tutte le richieste, settando l'argomento +\param{sig} in maniera analoga a come si fa per il campo \var{aio\_sigevent} +di \type{aiocb}. -\subsection{I/O multiplo} +\subsection{I/O vettorizzato} \label{sec:file_multiple_io} -Un caso abbastanza comune è quello in cui ci si trova a dover affrontare una +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. In questo caso +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 è stata dismessa per restare aderenti allo standard.} ha introdotto due +nuove system call, \func{readv} e \func{writev}, che permettono di effettare +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} viene + settata ai 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 utlizzare sono specificati attraverso l'argomento \var{vector} che +è un array di tale strutture, la cui lunghezza è specificata da \param{count}. +Essi verranno letti (o scritti) nell'ordine in cui li si sono specificati. @@ -758,10 +833,27 @@ Una modalit rispetto a quella classica, è quella dei file \textsl{mappati in memoria}. In sostanza quello che si fa è usare il meccanismo della \textsl{paginazione}\index{paginazione} usato per la memoria virtuale (vedi -\secref{sec:proc_mem_gen}) per trasformare vedere il file in una sezione dello -spazio di indirizzi del processo, in modo che l'accesso a quest'ultimo con le -normali operazioni di lettura e scrittura delle variabili in memoria, si -trasformi in I/O sul file stesso. +\secref{sec:proc_mem_gen}) vedere il file in una sezione dello spazio di +indirizzi del processo, in modo che l'accesso a quest'ultimo avvenga con le +normali operazioni di lettura e scrittura delle variabili in memoria. + +Questa interfaccia è più efficiente dell'uso 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, non è necessario trasferire in un +buffer tutti i dati che potrebbero servire, e poi riscrivere il tutto una +volta completate le operazioni, la scrittura e la lettura avverranno invece +direttamente sulla sezione di memoria mappata, che sarà a sua volta letta o +scritta sul file, una pagina alla volta (e solo per le parti effettivamente +usate) in maniera trasparente attraverso il meccanismo della paginazione. +L'acceso alle pagine non ancora caricate avverrà allo stesso modo con cui +vengono caricate in memoria le pagine che sono state salvate sullo swap. + +Inoltre 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, + diff --git a/gapil.tex b/gapil.tex index 2eeaa99..be7b703 100644 --- a/gapil.tex +++ b/gapil.tex @@ -74,7 +74,6 @@ \clearemptydoublepage %\include{compatib} % commentare per la stampa PS e PDF - \include{macro} \setcounter{secnumdepth}{-2} \include{pref} -- 2.30.2