From: Simone Piccardi Date: Fri, 7 Feb 2014 22:51:26 +0000 (+0000) Subject: Piccole correzioni X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=2949b52da443a72eba0463bb01f5552adc31e937;p=gapil.git Piccole correzioni --- diff --git a/fileadv.tex b/fileadv.tex index 480b3da..278b303 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -382,9 +382,8 @@ tal caso l'intervallo coperto va da \var{l\_start}$+$\var{l\_len} a \var{l\_start}$-1$, mentre per un valore positivo l'intervallo va da \var{l\_start} a \var{l\_start}$+$\var{l\_len}$-1$. Si può però usare un valore negativo soltanto se l'inizio della regione indicata non cade prima -dell'inizio del file, con un valore positivo invece si può anche indicare una -regione che eccede la dimensione corrente del file, e questa verrà coperta in -una sua futura estensione. +dell'inizio del file, mentre come accennato con un valore positivo si +può anche indicare una regione che eccede la dimensione corrente del file. Il tipo di \textit{file lock} richiesto viene specificato dal campo \var{l\_type}, esso può assumere i tre valori definiti dalle costanti @@ -605,11 +604,11 @@ Nel caso si sia scelta la semantica BSD (\texttt{\small 25--34}) prima si controlla (\texttt{\small 27--31}) il valore di \var{cmd} per determinare se si vuole effettuare una chiamata bloccante o meno, reimpostandone il valore opportunamente, dopo di che a seconda del tipo di blocco al valore viene -aggiunta la relativa opzione (con un OR aritmetico, dato che \func{flock} +aggiunta la relativa opzione, con un OR aritmetico, dato che \func{flock} vuole un argomento \param{operation} in forma di maschera binaria. Nel caso invece che si sia scelta la semantica POSIX le operazioni sono molto più -immediate, si prepara (\texttt{\small 36--40}) la struttura per il lock, e lo -esegue (\texttt{\small 41}). +immediate si prepara (\texttt{\small 36--40}) la struttura per il lock, e lo +si esegue (\texttt{\small 41}). In entrambi i casi dopo aver richiesto il blocco viene controllato il risultato uscendo (\texttt{\small 44--46}) in caso di errore, o stampando un @@ -723,8 +722,8 @@ Lock acquired \end{Console} %$ che ci mostra come i due tipi di blocco siano assolutamente indipendenti; per -questo motivo occorre sempre tenere presente quale fra le due semantiche -disponibili stanno usando i programmi con cui si interagisce, dato che i +questo motivo occorre sempre tenere presente quale, fra le due semantiche +disponibili, stanno usando i programmi con cui si interagisce, dato che i blocchi applicati con l'altra non avrebbero nessun effetto. % \subsection{La funzione \func{lockf}} @@ -789,7 +788,7 @@ consentiti sono i seguenti: sovrappone ad una che è già stata bloccata da un altro processo; in caso di sovrapposizione con un altro blocco già ottenuto le sezioni vengono unite. \item[\const{F\_TLOCK}] Richiede un \textit{exclusive lock}, in maniera - identica a\const{F\_LOCK} ma in caso di indisponibilità non blocca il + identica a \const{F\_LOCK}, ma in caso di indisponibilità non blocca il processo restituendo un errore di \errval{EAGAIN}. \item[\const{F\_ULOCK}] Rilascia il blocco sulla sezione indicata, questo può anche causare la suddivisione di una sezione bloccata in precedenza nelle @@ -804,10 +803,10 @@ consentiti sono i seguenti: La funzione è semplicemente una diversa interfaccia al \textit{file locking} POSIX ed è realizzata utilizzando \func{fcntl}; pertanto la semantica delle operazioni è la stessa di quest'ultima e quindi la funzione presenta lo stesso -comportamento riguardo gli effetti della chiusura dei file, degli effetti sui -file duplicati e nel passaggio attraverso \func{fork} ed \func{exec}. Per -questo motivo la funzione non è affatto equivalente a \func{flock} e può -essere usata senza interferenze insieme a quest'ultima. +comportamento riguardo gli effetti della chiusura dei file, ed il +comportamento sui file duplicati e nel passaggio attraverso \func{fork} ed +\func{exec}. Per questo stesso motivo la funzione non è equivalente a +\func{flock} e può essere usata senza interferenze insieme a quest'ultima. @@ -824,20 +823,20 @@ direttamente al sistema, così che, anche qualora non si predisponessero le opportune verifiche nei processi, questo verrebbe comunque rispettato. Per poter utilizzare il \textit{mandatory locking} è stato introdotto un -utilizzo particolare del bit \itindex{sgid~bit} \acr{sgid}. Se si ricorda -quanto esposto in sez.~\ref{sec:file_special_perm}), esso viene di norma -utilizzato per cambiare il \ids{GID} 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 file in questione. In questo modo una -combinazione dei permessi originariamente non contemplata, in quanto senza -significato, diventa l'indicazione della presenza o meno del \textit{mandatory - locking}.\footnote{un lettore attento potrebbe ricordare quanto detto in - sez.~\ref{sec:file_perm_management} e cioè che il bit \acr{sgid} viene - cancellato (come misura di sicurezza) quando di scrive su un file, questo - non vale quando esso viene utilizzato per attivare il \textit{mandatory - locking}.} +utilizzo particolare del bit \itindex{sgid~bit} \acr{sgid} dei permessi dei +file. Se si ricorda quanto esposto in sez.~\ref{sec:file_special_perm}), esso +viene di norma utilizzato per cambiare il \ids{GID} 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 file in questione. In +questo modo una combinazione dei permessi originariamente non contemplata, in +quanto senza significato, diventa l'indicazione della presenza o meno del +\textit{mandatory locking}.\footnote{un lettore attento potrebbe ricordare + quanto detto in sez.~\ref{sec:file_perm_management} e cioè che il bit + \acr{sgid} viene cancellato (come misura di sicurezza) quando di scrive su + un file, questo non vale quando esso viene utilizzato per attivare il + \textit{mandatory locking}.} L'uso del \textit{mandatory locking} presenta vari aspetti delicati, dato che neanche l'amministratore può passare sopra ad un \textit{file lock}; pertanto @@ -849,9 +848,9 @@ inaccessibile, rendendo completamente inutilizzabile il sistema\footnote{il bloccare completamente un server NFS richiedendo una lettura su un file su cui è attivo un blocco. Per questo motivo l'abilitazione del \textit{mandatory locking} è di norma disabilitata, e deve essere attivata filesystem per -filesystem in fase di montaggio (specificando l'apposita opzione di -\func{mount} riportata in sez.~\ref{sec:filesystem_mounting}), o con l'opzione -\code{-o mand} per il comando omonimo). +filesystem in fase di montaggio, specificando l'apposita opzione di +\func{mount} riportata in sez.~\ref{sec:filesystem_mounting}, o con l'opzione +\code{-o mand} per il comando omonimo. Si tenga presente inoltre che il \textit{mandatory locking} funziona solo sull'interfaccia POSIX di \func{fcntl}. Questo ha due conseguenze: che non si @@ -915,7 +914,6 @@ può presentare anche con l'uso di file mappati in memoria; pertanto allo stato attuale delle cose è sconsigliabile fare affidamento sul \textit{mandatory locking}. - \itindend{file~locking} \itindend{mandatory~locking} @@ -940,25 +938,33 @@ I/O. Abbiamo visto in sez.~\ref{sec:sig_gen_beha}, affrontando la suddivisione fra \textit{fast} e \textit{slow} \textit{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 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 -più file descriptor eseguendo funzioni che possono bloccarsi senza che sia -possibile prevedere quando questo può avvenire (il caso più classico è quello -di un server in attesa di dati in ingresso da vari client). Quello che può -accadere è di restare bloccati nell'eseguire una operazione su un file -descriptor che non è ``\textsl{pronto}'', quando ce ne potrebbe essere 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 \itindex{deadlock} \textit{deadlock}. +che in certi casi le funzioni di I/O eseguite su un file descritor possono +bloccarsi indefinitamente. Questo non avviene mai per i file normali, per i +quali le funzioni di lettura e scrittura ritornano sempre subito, ma può +avvenire per alcuni \index{file!di~dispositivo} file di dispositivo, come ad +esempio una seriale, o con l'uso di file descriptor collegati a meccanismi di +intercomunicazione come le \textit{pipe} (vedi sez.~\ref{sec:ipc_unix}) ed i +socket (vedi sez.~\ref{sec:sock_socket_def}). In casi come questi ad esempio +una operazione di lettura potrebbe bloccarsi se non ci sono dati disponibili +sul descrittore su cui la si sta effettuando. + +Questo comportamento è alla radice di una delle problematiche più comuni che +ci si trova ad affrontare nelle operazioni di I/O, la necessità di operare su +su più file descriptor eseguendo funzioni che possono bloccarsi +indefinitamente senza che sia possibile prevedere quando questo può avvenire; +un caso classico è quello di un server di rete (tratteremo la problematica in +dettaglio nella seconda parte della guida) in attesa di dati in ingresso +prevenienti da vari client. + +In un caso di questo tipo, se si andasse ad operare sui vari file descriptor +aperti uno dopo l'altro, potrebbe accadere di restare bloccati nell'eseguire +una lettura su uno di quelli che non è ``\textsl{pronto}'', quando ce ne +potrebbe essere un altro con dati disponibili. 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 +\itindex{deadlock} \textit{deadlock}. 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 diff --git a/img/flock_boundary.dia b/img/flock_boundary.dia deleted file mode 100644 index ba91436..0000000 Binary files a/img/flock_boundary.dia and /dev/null differ