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.
+ 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.
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
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}.
+\textit{deadlock}\index{deadlock}.
Abbiamo già accennato in \secref{sec:file_open} che è possibile prevenire
questo tipo di comportamento aprendo un file in modalità
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
-è:
+ stata portata su tutti i sistemi che supportano i
+ \textit{socket}\index{socket}, compreso le varianti di System V.} con la
+funzione \funcd{select}, il cui prototipo è:
\begin{functions}
\headdecl{sys/time.h}
\headdecl{sys/types.h}
\item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
\item[\errcode{EINVAL}] Si è specificato per \param{n} un valore negativo.
\end{errlist}
- ed inoltre \const{ENOMEM}.
+ ed inoltre \errval{ENOMEM}.
}
\end{functions}
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 \val{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.
+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.
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
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 è
+ multiplexing}, basata sulla funzione \funcd{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 è:
degli insiemi.
\item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
\end{errlist}
- ed inoltre \const{EFAULT} e \const{ENOMEM}.}
+ ed inoltre \errval{EFAULT} e \errval{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).
+specificati attraverso un vettore di puntatori a strutture \struct{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
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \type{pollfd}, utilizzata per specificare le modalità
+ \caption{La struttura \struct{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
+struttura \struct{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
\hline
\end{tabular}
\caption{Costanti per l'identificazione dei vari bit dei campi
- \var{events} e \var{revents} di \type{pollfd}.}
+ \var{events} e \var{revents} di \struct{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
+relativa struttura \struct{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.
(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
+\funcd{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},
\item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
\item[\errcode{EINVAL}] Si è specificato per \param{n} un valore negativo.
\end{errlist}
- ed inoltre \const{ENOMEM}.}
+ ed inoltre \errval{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
+struttura \struct{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
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}.
+ possibilità di una race condition\index{race condition} resta.} quando si
+deve eseguire un test su una variabile assegnata da un gestore 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\index{race condition}
+diventa superabile disabilitando il segnale prima del test e riabilitandolo
+poi grazie all'uso di \param{sigmask}.
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
+attraverso la struttura \struct{siginfo\_t}, utilizzando la forma estesa
+\var{sa\_sigaction} del gestore (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
\const{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare in caso di
I/O asincrono (il segnale predefinito è \const{SIGIO}). In questo caso il
-manipolatore tutte le volte che riceverà \const{SI\_SIGIO} come valore del
+gestore tutte le volte che riceverà \const{SI\_SIGIO} come valore del
campo \var{si\_code}\footnote{il valore resta \const{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
+\struct{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
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
+invierà al suo posto un \const{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.
+varie occasioni (in particolar modo con i socket\index{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
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
+attraverso l'uso di una apposita struttura \struct{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 è
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \type{aiocb}, usata per il controllo dell'I/O
+ \caption{La struttura \struct{aiocb}, usata per il controllo dell'I/O
asincrono.}
\label{fig:file_aiocb}
\end{figure}
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \type{sigevent}, usata per specificare le modalità di
+ \caption{La struttura \struct{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}
+Infine il campo \var{aio\_sigevent} è una struttura di tipo \struct{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
\item[\const{SIGEV\_NONE}] Non viene inviata nessuna notifica.
\item[\const{SIGEV\_SIGNAL}] La notifica viene effettuata inviando al processo
chiamante il segnale specificato nel campo \var{sigev\_signo}, se il
- manipolatore è installato con \const{SA\_SIGINFO}, il gli verrà restituito
+ gestore è installato con \const{SA\_SIGINFO}, il gli verrà restituito
il valore di \var{sigev\_value} in come valore del campo \var{si\_value} per
- \type{siginfo\_t}.
+ \struct{siginfo\_t}.
\item[\const{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}
+\funcd{aio\_read} ed \funcd{aio\_write}. Esse permettono di richiedere una
+lettura od una scrittura asincrona di dati, usando la struttura \struct{aiocb}
appena descritta; i rispettivi prototipi sono:
\begin{functions}
\headdecl{aio.h}
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}.
+struttura \struct{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
+prima è \funcd{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)}
Una volta che si sia certi che le operazioni siano state concluse (cioè dopo
che una chiamata ad \func{aio\_error} non ha restituito \errcode{EINPROGRESS},
-si potrà usare la seconda funzione dell'interfaccia, \func{aio\_return}, che
+si potrà usare la seconda funzione dell'interfaccia, \funcd{aio\_return}, che
permette di verificare il completamento delle operazioni di I/O asincrono; il
suo prototipo è:
\begin{prototype}{aio.h}
\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},
- \const{EAGAIN}, \const{EBADF} o \const{EINVAL}.}
+ \errval{EAGAIN}, \errval{EBADF} o \errval{EINVAL}.}
\end{prototype}
La funzione richiede la sincronizzazione delle operazioni di I/O, ritornando
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
+standard POSIX.1b prevede una funzioni apposita, \funcd{aio\_cancel}, che
permette di cancellare una operazione richiesta in precedenza; il suo
prototipo è:
\begin{prototype}{aio.h}
\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
- \const{EBADF}.}
+ \errval{EBADF}.}
\end{prototype}
La funzione permette di cancellare una operazione specifica sul file
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
+fornisce anche una apposita funzione, \funcd{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}
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
+con delle strutture \struct{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
\val{NULL} per \param{timout} comporta l'assenza di timeout.
-Lo standard POSIX.1b infine ha previsto pure una funzione, \func{lio\_listio},
+Lo standard POSIX.1b infine ha previsto pure una funzione, \funcd{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}
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}.
+di \struct{aiocb}.
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
+ 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
+due nuove system call, \funcd{readv} e \funcd{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:
non ci sono dati in lettura.
\item[\errcode{EOPNOTSUPP}] La coda delle richieste è momentaneamente piena.
\end{errlist}
- ed inoltre \const{EISDIR}, \const{ENOMEM}, \const{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}.}
+ ed inoltre \errval{EISDIR}, \errval{ENOMEM}, \errval{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
+Entrambe le funzioni usano una struttura \struct{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.
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \type{iovec}, usata dalle operazioni di I/O
+ \caption{La struttura \struct{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
+è un vettore di strutture \struct{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}.
+si sono specificati nel vettore \param{vector}.
\subsection{File mappati in memoria}
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
+ I/O}, la prima di queste è \funcd{mmap}, che serve ad eseguire la mappatura
in memoria di un file; il suo prototipo è:
\begin{functions}
\item[\errcode{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[\errcode{ETXTBSY}] Si è impostato \const{MAP\_DENYWRITE} ma \param{fd}
- è aperto in scrittura.
+ \item[\errcode{ETXTBSY}] Si è impostato \const{MAP\_DENYWRITE} ma
+ \param{fd} è aperto in scrittura.
\item[\errcode{EAGAIN}] Il file è bloccato, o si è bloccata troppa memoria.
- \item[\errcode{ENOMEM}] Non c'è memoria o si è superato il limite sul numero
- di mappature possibili.
+ \item[\errcode{ENOMEM}] Non c'è memoria o si è superato il limite sul
+ numero di mappature possibili.
\item[\errcode{ENODEV}] Il filesystem di \param{fd} non supporta il memory
mapping.
\end{errlist}
\const{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 \errcode{ETXTBUSY}).\\
+ 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
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.
+paginazione\index{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
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
+dispongono della relativa operazione \func{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.
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 è:
+del contenuto della memoria su cui è mappato.
+
+Per questo, è 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 \funcd{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}
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 è:
+mappatura della memoria usando la funzione \funcd{munmap}, il suo prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{sys/mman.h}
\section{Il file locking}
\label{sec:file_locking}
+\index{file!locking|(}
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
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
-sovrapposizioni, e garantire la atomicità delle operazioni di scrittura.
+evitare le race condition\index{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.
In generale si distinguono due tipologie di \textit{file lock}:\footnote{di
seguito ci riferiremo sempre ai blocchi di accesso ai file con la
nomenclatura inglese di \textit{file lock}, o più brevemente con
- \textit{lock}, per evitare confuzioni linguistiche con il blocco di un
+ \textit{lock}, per evitare confusioni linguistiche con il blocco di un
processo (cioè la condizione in cui il processo viene posto in stato di
\textit{sleep}).} la prima è il cosiddetto \textit{shared lock}, detto anche
\textit{read lock} in quanto serve a bloccare l'accesso in scrittura su un
Si tenga presente infine che il controllo di accesso è effettuato quando si
apre un file, l'unico controllo residuo è che il tipo di lock che si vuole
-otternere deve essere compatibile con le modalità di apertura dello stesso (di
+ottenere deve essere compatibile con le modalità di apertura dello stesso (di
lettura per un read lock e di scrittura per un write lock).
%% Si ricordi che
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 è:
+rimuovere un \textit{file lock} è \funcd{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}.
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
- (\const{FL\_FLOCK}) o POSIX (\const{FL\_POSIX}).} dato che questo è l'unico
-riferimento in comune che possono avere due processi diversi che aprono lo
-stesso file.
+mantenute a livello di inode\index{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
+ \struct{file\_lock}. La lista è referenziata dall'indirizzo di partenza
+ mantenuto dal campo \var{i\_flock} della struttura \struct{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 (\const{FL\_FLOCK}) o POSIX (\const{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
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
+elemento.\footnote{cioè una nuova struttura \struct{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 file lock quanto
piuttosto degli ulteriori riferimenti allo stesso. Questo viene realizzato dal
kernel secondo lo schema di \figref{fig:file_flock_struct}, 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 lock, che così ne identifica il titolare.
+ campo \var{fl\_file} di \struct{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 lock, che così ne identifica il titolare.
Questa struttura prevede che, quando si richiede la rimozione di un file lock,
il kernel acconsenta solo se la richiesta proviene da un file descriptor che
\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}. Non è garantito che il sistema riconosca sempre
- questa situazione.
+ \textit{deadlock}\index{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}
- ed inoltre \const{EBADF}, \const{EFAULT}.
+ ed inoltre \errval{EBADF}, \errval{EFAULT}.
}
\end{prototype}
\func{fcntl} è possibile bloccare anche delle singole sezioni di un file, fino
al singolo byte. Inoltre la funzione permette di ottenere alcune informazioni
relative agli eventuali lock preesistenti. 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}) nella quale inserire
-tutti i dati relativi ad un determinato lock. Si tenga presente poi che un
-lock fa sempre riferimento ad una regione, per cui si potrà avere un conflitto
-anche se c'è soltanto una sovrapposizione parziale con un'altra regione
-bloccata.
+funzione utilizza come terzo argomento una apposita struttura \struct{flock}
+(la cui definizione è riportata in \figref{fig:struct_flock}) nella quale
+inserire tutti i dati relativi ad un determinato lock. Si tenga presente poi
+che un lock fa sempre riferimento ad una regione, per cui si potrà avere un
+conflitto anche se c'è soltanto una sovrapposizione parziale con un'altra
+regione bloccata.
\begin{figure}[!bht]
\footnotesize \centering
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \type{flock}, usata da \func{fcntl} per il file
+ \caption{La struttura \struct{flock}, usata da \func{fcntl} per il file
locking.}
\label{fig:struct_flock}
\end{figure}
\const{F\_UNLCK} & Richiede l'eliminazione di un file lock.\\
\hline
\end{tabular}
- \caption{Valori possibili per il campo \var{l\_type} di \func{flock}.}
+ \caption{Valori possibili per il campo \var{l\_type} di \struct{flock}.}
\label{tab:file_flock_type}
\end{table}
-Oltre a quanto richiesto tramite i campi di \var{flock}, l'operazione
+Oltre a quanto richiesto tramite i campi di \struct{flock}, 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{figure}[htb]
\centering \includegraphics[width=9cm]{img/file_lock_dead}
- \caption{Schema di una situazione di \textit{deadlock}.}
+ \caption{Schema di una situazione di \textit{deadlock}\index{deadlock}.}
\label{fig:file_flock_dead}
\end{figure}
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}.
+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}
strutture utilizzate è riportato in \figref{fig:file_posix_lock}; come si vede
esso è molto simile all'analogo di \figref{fig:file_flock_struct}:\footnote{in
questo caso nella figura si sono evidenziati solo i campi di
- \var{file\_lock} significativi per la semantica POSIX, in particolare adesso
- ciascuna struttura contiene, oltre al \acr{pid} del processo in
+ \struct{file\_lock} significativi per la semantica POSIX, in particolare
+ adesso ciascuna struttura 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
\const{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.
+sempre associato all'inode\index{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.
Quando si richiede un lock il kernel effettua una scansione di tutti i lock
presenti sul file\footnote{scandisce cioè la linked list delle strutture
- \var{file\_lock}, scartando automaticamente quelle per cui \var{fl\_flags}
- non è \const{FL\_POSIX}, così che le due interfacce restano ben separate.}
-per verificare se la regione richiesta non si sovrappone ad una già bloccata,
-in caso affermativo decide in base al tipo di lock, in caso negativo il nuovo
-lock viene comunque acquisito ed aggiunto alla lista.
+ \struct{file\_lock}, scartando automaticamente quelle per cui
+ \var{fl\_flags} non è \const{FL\_POSIX}, così che le due interfacce restano
+ ben separate.} per verificare se la regione richiesta non si sovrappone ad
+una già bloccata, in caso affermativo decide in base al tipo di lock, in caso
+negativo il nuovo lock viene comunque acquisito ed aggiunto alla lista.
Nel caso di rimozione invece questa viene effettuata controllando che il
\acr{pid} del processo richiedente corrisponda a quello contenuto nel lock.
stati creati usando altri file descriptor che restano aperti.
Dato che il controllo sull'accesso ai lock viene eseguito sulla base del
-\acr{pid} del processo, possiamo anche prendere in cosiderazione un'altro
+\acr{pid} del processo, possiamo anche prendere in considerazione un'altro
degli aspetti meno chiari di questa interfaccia e cioè cosa succede quando si
richiedono dei lock su regioni che si sovrappongono fra loro all'interno
stesso processo. Siccome il controllo, come nel caso della rimozione, si basa
Nel caso della semantica BSD, essendo i lock relativi a tutto un file e non
accumulandosi,\footnote{questa ultima caratteristica è vera in generale, se
- cioè si richiede più volte lo stesso file lock, o più lock sula stessa
+ cioè si richiede più volte lo stesso file lock, o più lock sulla stessa
sezione di file, le richieste non si cumulano e basta una sola richiesta di
rilascio per cancellare il lock.} la cosa non ha alcun effetto; la funzione
ritorna con successo, senza che il kernel debba modificare la lista dei lock.
\end{verbatim}%$
\end{minipage}\vspace{1mm}
\par\noindent
-come ci aspettimo questo non sarà consentito.
+come ci aspettiamo questo non sarà consentito.
Il programma di norma esegue il tentativo di acquisire il lock in modalità non
bloccante, se però usiamo l'opzione \cmd{-b} possiamo impostare la modalità
\end{minipage}\vspace{1mm}
\par\noindent
il primo comando acquisisce subito un read lock, e quindi non cambia nulla, ma
-se proviamo adesso a richidere un write lock che non potrà essere acquisito
+se proviamo adesso a richiedere un write lock che non potrà essere acquisito
otterremo:
\vspace{1mm}
potente e flessibile di quella di BSD, questo comporta anche una maggiore
complessità per via delle 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 è:
+che utilizza la funzione \funcd{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}.
\item[\errcode{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 \const{EBADF}, \const{EINVAL}.
+ ed inoltre \errval{EBADF}, \errval{EINVAL}.
}
\end{prototype}
con un OR aritmetico dei valori.\\
\hline
\end{tabular}
- \caption{Valori possibili per il campo \var{cmd} di \func{lockf}.}
+ \caption{Valori possibili per l'argomento \param{cmd} di \func{lockf}.}
\label{tab:file_lockf_type}
\end{table}
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
+group-ID 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
comportamento non ha molto senso, dato che comunque qualunque accesso
diretto al file è consentito.} in Linux è stata però fatta la scelta
implementativa\footnote{per i dettagli si possono leggere le note relative
- all'implementazione, mantenute insime ai sorgenti del kernel nel file
+ all'implementazione, mantenute insieme ai sorgenti del kernel nel file
\file{Documentation/mandatory.txt}.} di seguire questo comportamento
soltanto quando si chiama \func{mmap} con l'opzione \const{MAP\_SHARED} (nel
qual caso la funzione fallisce con il solito \errcode{EAGAIN}) che comporta la
possibilità di modificare il file.
+\index{file!locking|)}
projects / gapil.git / blobdiff