X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=fileadv.tex;h=a4ca6e28ae80d4cd30656cb521cd36fa588be2c8;hb=7d039accae81b30524e7a01f0b3d24ae79ddbaf1;hp=240c0582524d1d7eab149b336df1cde0276a4106;hpb=05658e26bf54190b200d77d7301ee34c4690f187;p=gapil.git diff --git a/fileadv.tex b/fileadv.tex index 240c058..a4ca6e2 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -26,12 +26,12 @@ controllo più dettagliato delle modalità di I/O. \itindbeg{file~locking} -In sez.~\ref{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 \itindex{append~mode} \textit{append mode}, quando più processi scrivono -contemporaneamente sullo stesso file non è possibile determinare la sequenza -in cui essi opereranno. +In sez.~\ref{sec:file_shared_access} abbiamo preso in esame le modalità in cui +un sistema unix-like gestisce l'accesso concorrente ai file da parte di +processi diversi. In quell'occasione si è visto come, con l'eccezione dei file +aperti in \itindex{append~mode} \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 una \itindex{race~condition} \textit{race condition}; in generale le situazioni più comuni sono due: l'interazione fra @@ -260,8 +260,8 @@ Questa struttura prevede che, quando si richiede la rimozione di un file descriptor che fa riferimento ad una voce nella \itindex{file~table} \textit{file table} corrispondente a quella registrata nel blocco. Allora se ricordiamo quanto visto in sez.~\ref{sec:file_dup} e -sez.~\ref{sec:file_sharing}, e cioè che i file descriptor duplicati e quelli -ereditati in un processo figlio puntano sempre alla stessa voce nella +sez.~\ref{sec:file_shared_access}, e cioè che i file descriptor duplicati e +quelli ereditati in un processo figlio puntano sempre alla stessa voce nella \itindex{file~table} \textit{file table}, si può capire immediatamente quali sono le conseguenze nei confronti delle funzioni \func{dup} e \func{fork}. @@ -934,18 +934,18 @@ 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 \itindex{deadlock} \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 -\textsl{modalità non-bloccante}, attraverso l'uso del flag \const{O\_NONBLOCK} -nella chiamata di \func{open}. In questo caso le funzioni di input/output -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 \itindex{polling} \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. +Abbiamo già accennato in sez.~\ref{sec:file_open_close} che è possibile +prevenire questo tipo di comportamento delle funzioni di I/O aprendo un file +in \textsl{modalità non-bloccante}, attraverso l'uso del flag +\const{O\_NONBLOCK} nella chiamata di \func{open}. In questo caso le funzioni +di input/output 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 \itindex{polling} +\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 superare questo problema è stato introdotto il concetto di \textit{I/O multiplexing}, una nuova modalità di operazioni che consente di tenere sotto @@ -1547,7 +1547,7 @@ maschera binaria in fase di creazione del file descriptor. Al momento l'unico valore legale per \param{flags} (a parte lo zero) è \const{EPOLL\_CLOEXEC}, che consente di impostare in maniera atomica sul file descriptor il flag di \itindex{close-on-exec} \textit{close-on-exec} (si veda il significato di -\const{O\_CLOEXEC} in sez.~\ref{sec:file_open}), senza che sia +\const{O\_CLOEXEC} in sez.~\ref{sec:file_open_close}), senza che sia necessaria una successiva chiamata a \func{fcntl}. Una volta ottenuto un file descriptor per \textit{epoll} il passo successivo è @@ -2478,19 +2478,19 @@ operazioni di I/O volute. \itindbeg{signal~driven~I/O} -Abbiamo accennato in sez.~\ref{sec:file_open} che è possibile, attraverso -l'uso del flag \const{O\_ASYNC},\footnote{l'uso del flag di \const{O\_ASYNC} e - dei comandi \const{F\_SETOWN} e \const{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 \const{F\_SETFL} (vedi -sez.~\ref{sec:file_fcntl}). In realtà parlare di apertura in modalità -asincrona non significa che le operazioni di lettura o scrittura del file -vengono eseguite in modo asincrono (tratteremo questo, che è ciò che più +Abbiamo accennato in sez.~\ref{sec:file_open_close} che è definito un flag +\const{O\_ASYNC}, che consentirebbe di aprire un file in modalità asincrona, +anche se in realtà è opportuno attivare in un secondo tempo questa modalità +impostando questo flag attraverso l'uso di \func{fcntl} con il comando +\const{F\_SETFL} (vedi sez.~\ref{sec:file_fcntl}).\footnote{l'uso del flag di + \const{O\_ASYNC} e dei comandi \const{F\_SETOWN} e \const{F\_GETOWN} per + \func{fcntl} è specifico di Linux e BSD.} In realtà parlare di apertura in +modalità asincrona non significa che le operazioni di lettura o scrittura del +file vengono eseguite in modo asincrono (tratteremo questo, che è ciò che più propriamente viene chiamato \textsl{I/O asincrono}, in sez.~\ref{sec:file_asyncronous_io}), quanto dell'attivazione un meccanismo di notifica asincrona delle variazione dello stato del file descriptor aperto in -questo modo. +questo modo. Quello che succede è che per tutti i file posti in questa modalità\footnote{si tenga presente però che essa non è utilizzabile con i file ordinari ma solo @@ -3314,7 +3314,9 @@ raggruppati in un solo evento. \subsection{L'interfaccia POSIX per l'I/O asincrono} \label{sec:file_asyncronous_io} -% vedere anche http://davmac.org/davpage/linux/async-io.html +% vedere anche http://davmac.org/davpage/linux/async-io.html e +% http://www.ibm.com/developerworks/linux/library/l-async/ + Una modalità alternativa all'uso dell'\textit{I/O multiplexing} per gestione dell'I/O simultaneo su molti file è costituita dal cosiddetto \textsl{I/O @@ -3425,8 +3427,9 @@ richiesta, o in caso di errore. Non è detto che gli errori \errcode{EBADF} ed 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 \itindex{append~mode} \textit{append mode} -(vedi sez.~\ref{sec:file_open}), nel qual caso le scritture vengono effettuate -comunque alla fine de file, nell'ordine delle chiamate a \func{aio\_write}. +(vedi sez.~\ref{sec:file_open_close}), 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 @@ -5408,10 +5411,6 @@ livello di kernel. % vedi http://lwn.net/Articles/226710/ e http://lwn.net/Articles/240571/ % http://kernelnewbies.org/Linux_2_6_23 - - - - % TODO non so dove trattarli, ma dal 2.6.39 ci sono i file handle, vedi % http://lwn.net/Articles/432757/