X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=9e2bf77df693713c7f845d5b83c00828ddcdf0fa;hp=de7ae5d50ae1aa153e836965c4ffd8691b579a3a;hb=b26cbb461558b73852b680d524e8f91675998116;hpb=42701ce83e63097c7de382574ebe0074a65ed9b4 diff --git a/fileadv.tex b/fileadv.tex index de7ae5d..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", @@ -36,14 +36,14 @@ I/O. \label{sec:file_noblocking} Abbiamo visto in sez.~\ref{sec:sig_gen_beha}, affrontando la suddivisione fra -\textit{fast} e \textit{slow} system call,\index{system call lente} che in +\textit{fast} e \textit{slow} system call,\index{system~call~lente} 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\index{socket} ed alcuni file di dispositivo\index{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. + socket\index{socket} ed alcuni file di + dispositivo\index{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 si verifica quando si deve operare con @@ -56,7 +56,7 @@ un'altro disponibile. Questo comporta nel migliore dei casi una operazione ritardata inutilmente nell'attesa del completamento di quella bloccata, mentre nel peggiore dei casi (quando la conclusione della operazione bloccata dipende da quanto si otterrebbe dal file descriptor ``\textsl{disponibile}'') si -potrebbe addirittura arrivare ad un \textit{deadlock}\index{deadlock}. +potrebbe addirittura arrivare ad un \textit{deadlock}\index{\textit{deadlock}}. Abbiamo già accennato in sez.~\ref{sec:file_open} che è possibile prevenire questo tipo di comportamento delle funzioni di I/O aprendo un file in @@ -66,7 +66,7 @@ eseguite sul file che si sarebbero bloccate, ritornano immediatamente, restituendo l'errore \errcode{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}\index{polling}, è +Ovviamente questa tecnica, detta \textit{polling}\index{\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. @@ -123,11 +123,12 @@ degli insiemi specificati (\param{readfds}, \param{writefds} e \param{exceptfds}), non diventa attivo, per un tempo massimo specificato da \param{timeout}. +\index{\textit{file~descriptor~set}|(} 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 -\index{\textit{signal set}}\textit{signal set} (vedi +file descriptor, in maniera analoga a come un +\index{\textit{signal~set}}\textit{signal set} (vedi sez.~\ref{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: @@ -172,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 @@ -185,6 +186,7 @@ ritorni; se impostato a \val{NULL} la funzione attende indefinitamente. Si pu specificare anche un tempo nullo (cioè una struttura \struct{timeval} con i campi impostati a zero), qualora si voglia semplicemente controllare lo stato corrente dei file descriptor. +\index{\textit{file~descriptor~set}|)} La funzione restituisce il numero di file descriptor pronti,\footnote{questo è il comportamento previsto dallo standard, ma la standardizzazione della @@ -268,15 +270,15 @@ 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\index{race condition} quando ci si deve porre in attesa sia di -un segnale che di dati. La tecnica classica è quella di utilizzare il gestore -per impostare una variabile globale e controllare questa nel corpo principale -del programma; abbiamo visto in sez.~\ref{sec:sig_example} come questo lasci -spazio a possibili race condition, per cui diventa essenziale utilizzare -\func{sigprocmask} per disabilitare la ricezione del segnale prima di eseguire -il controllo e riabilitarlo dopo l'esecuzione delle relative operazioni, onde -evitare l'arrivo di un segnale immediatamente dopo il controllo, che andrebbe -perso. +race condition\index{\textit{race~condition}} quando ci si deve porre in +attesa sia di un segnale che di dati. La tecnica classica è quella di +utilizzare il gestore per impostare una variabile globale e controllare questa +nel corpo principale del programma; abbiamo visto in +sez.~\ref{sec:sig_example} come questo lasci spazio a possibili race +condition, per cui diventa essenziale utilizzare \func{sigprocmask} per +disabilitare la ricezione del segnale prima di eseguire il controllo e +riabilitarlo dopo l'esecuzione delle relative operazioni, onde evitare +l'arrivo di un segnale immediatamente dopo il controllo, che andrebbe perso. Nel nostro caso il problema si pone quando oltre al segnale si devono tenere sotto controllo anche dei file descriptor con \func{select}, in questo caso si @@ -284,9 +286,9 @@ pu e si potrebbero eseguire di conseguenza le operazioni relative al segnale e alla gestione dati con un ciclo del tipo: \includecodesnip{listati/select_race.c} qui però emerge una race -condition,\index{race condition} perché se il segnale arriva prima della -chiamata a \func{select}, questa non verrà interrotta, e la ricezione del -segnale non sarà rilevata. +condition,\index{\textit{race~condition}} perché se il segnale arriva prima +della chiamata a \func{select}, questa non verrà interrotta, e la ricezione +del segnale non sarà rilevata. Per questo è stata introdotta \func{pselect} che attraverso l'argomento \param{sigmask} permette di riabilitare la ricezione il segnale @@ -493,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 @@ -542,7 +544,7 @@ effettuare in contemporanea le operazioni di calcolo e quelle di I/O. Benché la modalità di apertura asincrona di un file possa risultare utile in varie occasioni (in particolar modo con i socket\index{socket} e gli altri -file per i quali le funzioni di I/O sono \index{system call lente}system call +file per i quali le funzioni di I/O sono \index{system~call~lente}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 una interfaccia apposita per l'I/O @@ -738,7 +740,7 @@ 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)} +{int aio\_fsync(int op, struct aiocb *aiocbp)} Richiede la sincronizzazione dei dati per il file indicato da \param{aiocbp}. @@ -980,45 +982,53 @@ 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 +virtuale,\index{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 è \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} @@ -1092,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 @@ -1124,8 +1134,8 @@ tab.~\ref{tab:file_mmap_flag}. 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 + il meccanismo del \textit{copy on + write}\index{\textit{copy~on~write}} e salvate su swap in caso di necessità. Non è specificato se i cambiamenti sul file originale vengano riportati sulla regione @@ -1136,8 +1146,9 @@ tab.~\ref{tab:file_mmap_flag}. dovevano fallire con \errcode{ETXTBSY}).\\ \const{MAP\_EXECUTABLE}& Ignorato. \\ \const{MAP\_NORESERVE} & Si usa con \const{MAP\_PRIVATE}. Non riserva - delle pagine di swap ad uso del meccanismo di - \textit{copy on write}\index{copy on write} + delle pagine di swap ad uso del meccanismo del + \textit{copy on + write}\index{\textit{copy~on~write}} per mantenere le modifiche fatte alla regione mappata, in questo caso dopo una scrittura, se non c'è più @@ -1167,7 +1178,7 @@ tab.~\ref{tab:file_mmap_flag}. 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.\index{memoria virtuale} Questo comporta allora una serie di +virtuale.\index{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 (\const{SIGSEGV}), dato che i permessi sul segmento di memoria relativo non @@ -1252,12 +1263,12 @@ consentita la scrittura sul file (cio 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 cap.~\ref{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. +direttamente dalla \index{memoria~virtuale}memoria virtuale, occorre essere +consapevoli delle interazioni che possono esserci con operazioni effettuate +con l'interfaccia standard dei file di cap.~\ref{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 @@ -1366,16 +1377,16 @@ diversi. In quell'occasione si 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\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. +Questo causa la possibilità di race condition\index{\textit{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\index{race condition}, attraverso una serie di -funzioni che permettono di bloccare l'accesso al file da parte di altri +evitare le race condition\index{\textit{race~condition}}, attraverso una serie +di funzioni che permettono di bloccare l'accesso al file da parte di altri processi, così da evitare le sovrapposizioni, e garantire la atomicità delle operazioni di scrittura. @@ -1625,8 +1636,8 @@ essa viene usata solo secondo il prototipo: \item[\errcode{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}\index{deadlock}. Non è garantito che il sistema - riconosca sempre questa situazione. + \textit{deadlock}\index{\textit{deadlock}}. Non è garantito che il + sistema riconosca sempre questa situazione. \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale prima di poter acquisire un lock. \end{errlist} @@ -1745,7 +1756,8 @@ stato effettivamente acquisito. \begin{figure}[htb] \centering \includegraphics[width=9cm]{img/file_lock_dead} - \caption{Schema di una situazione di \textit{deadlock}\index{deadlock}.} + \caption{Schema di una situazione di + \textit{deadlock}\index{\textit{deadlock}}.} \label{fig:file_flock_dead} \end{figure} @@ -1757,11 +1769,12 @@ un lock sulla regione 2 che non pu del processo 2; il processo 1 si bloccherà fintanto che il processo 2 non rilasci il blocco. Ma cosa accade se il processo 2 nel frattempo tenta a sua volta di ottenere un lock sulla regione A? Questa è una tipica situazione che -porta ad un \textit{deadlock}\index{deadlock}, dato che a quel punto anche il -processo 2 si bloccherebbe, e niente potrebbe sbloccare l'altro processo. Per -questo motivo il kernel si incarica di rilevare situazioni di questo tipo, ed -impedirle restituendo un errore di \errcode{EDEADLK} alla funzione che cerca -di acquisire un lock che porterebbe ad un \textit{deadlock}. +porta ad un \textit{deadlock}\index{\textit{deadlock}}, dato che a quel punto +anche il processo 2 si bloccherebbe, e niente potrebbe sbloccare l'altro +processo. Per questo motivo il kernel si incarica di rilevare situazioni di +questo tipo, ed impedirle restituendo un errore di \errcode{EDEADLK} alla +funzione che cerca di acquisire un lock che porterebbe ad un +\textit{deadlock}. \begin{figure}[!bht] \centering \includegraphics[width=13cm]{img/file_posix_lock} @@ -1872,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