X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=9e2bf77df693713c7f845d5b83c00828ddcdf0fa;hp=28cf2bf32512d5177bb88b216ceffdb4fdf16c39;hb=388493a5b44babce8434148b87562aea0f046db7;hpb=5f4b8bbb1f57385f442b83d48fc8fbdc12ab30a3 diff --git a/fileadv.tex b/fileadv.tex index 28cf2bf..9e2bf77 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -1,6 +1,6 @@ %% fileadv.tex %% -%% Copyright (C) 2000-2004 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2005 Simone Piccardi. Permission is granted to %% copy, distribute and/or modify this document under the terms of the GNU Free %% Documentation License, Version 1.1 or any later version published by the %% Free Software Foundation; with the Invariant Sections being "Un preambolo", @@ -173,7 +173,7 @@ sez.~\ref{sec:TCP_urgent_data}). Dato che in genere non si tengono mai sotto controllo fino a \const{FD\_SETSIZE} file contemporaneamente la funzione richiede di -specificare qual'è il numero massimo dei file descriptor indicati nei tre +specificare qual è il numero massimo dei file descriptor indicati nei tre insiemi precedenti. Questo viene fatto per efficienza, per evitare di passare e far controllare al kernel una quantità di memoria superiore a quella necessaria. Questo limite viene indicato tramite l'argomento \param{n}, che @@ -495,7 +495,7 @@ 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 i -file descriptor sono più di uno, qual'è quello responsabile dell'emissione del +file descriptor sono più di uno, qual è quello responsabile dell'emissione del segnale. Inoltre dato che i segnali normali non si accodano (si ricordi quanto illustrato in sez.~\ref{sec:sig_notification}), in presenza di più file descriptor attivi contemporaneamente, più segnali emessi nello stesso momento @@ -982,29 +982,34 @@ rispetto a quella classica vista in cap.~\ref{cha:file_unix_interface}, cosiddetto \textit{memory-mapped I/O}, che, attraverso il meccanismo della \textsl{paginazione}\index{paginazione} usato dalla memoria virtuale (vedi sez.~\ref{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 fig.~\ref{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\index{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. +file in una sezione dello spazio di indirizzi del processo. + +Il meccanismo è illustrato in fig.~\ref{fig:file_mmap_layout}, una sezione del +file viene \textsl{mappata} direttamente nello spazio degli indirizzi del +programma. Tutte le operazioni di lettura e scrittura su variabili contenute +in questa zona di memoria verranno eseguite leggendo e scrivendo dal contenuto +del file attraverso il sistema della memoria virtuale\index{memoria~virtuale} +che in maniera analoga a quanto avviene per le pagine che vengono salvate e +rilette nella swap, si incaricherà di sincronizzare il contenuto di quel +segmento di memoria con quello del file mappato su di esso. Per questo motivo +si può parlare tanto di \textsl{file mappato in memoria}, quanto di +\textsl{memoria mappata su file}. \begin{figure}[htb] \centering - \includegraphics[width=7.cm]{img/mmap_layout} + \includegraphics[width=14cm]{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. +L'uso del \textit{memory-mappung} 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, poiché 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,\index{memoria~virtuale} la sezione di memoria mappata su cui si @@ -1012,15 +1017,18 @@ opera sar 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 è \funcd{mmap}, che serve ad eseguire la mappatura -in memoria di un file; il suo prototipo è: +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 POSIX implementata da Linux prevede varie funzioni per la +gestione del \textit{memory mapped I/O}, la prima di queste, che serve ad +eseguire la mappatura in memoria di un file, è \funcd{mmap}; il suo prototipo +è: \begin{functions} \headdecl{unistd.h} @@ -1094,7 +1102,7 @@ specificato come maschera binaria ottenuta dall'OR di uno o pi riportati in tab.~\ref{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, +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 @@ -1877,7 +1885,7 @@ POSIX), e la variabile \var{cmd} che specifica la modalit lock (bloccante o meno), a seconda dell'opzione \cmd{-b}. Il programma inizia col controllare (\texttt{\small 11--14}) che venga passato -un parametro (il file da bloccare), che sia stato scelto (\texttt{\small +un argomento (il file da bloccare), che sia stato scelto (\texttt{\small 15--18}) il tipo di lock, dopo di che apre (\texttt{\small 19}) il file, uscendo (\texttt{\small 20--23}) in caso di errore. A questo punto il comportamento dipende dalla semantica scelta; nel caso sia BSD occorre