From 2949b52da443a72eba0463bb01f5552adc31e937 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Fri, 7 Feb 2014 22:51:26 +0000 Subject: [PATCH] Piccole correzioni --- fileadv.tex | 106 ++++++++++++++++++++++------------------- img/flock_boundary.dia | Bin 1491 -> 0 bytes 2 files changed, 56 insertions(+), 50 deletions(-) delete mode 100644 img/flock_boundary.dia 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 ba91436443fd893a9453a26df0009aaade168b4b..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 1491 zcmV;^1uXg>iwFP!000021MOT{kE2EqexF}~7%4BAY12S+tk<*3MvAmjq&#HuY_*|{ zJA=V$+T(Gw%5P6|j1MqAxU%emG=o6x`nrm$uZpg=KYn^!`qC?55e-o1wOaAn9_tB;JgZT3pUP|HsA~JQ@^ngl+uP5Gt@#RTaiSwq+}(Zo+q)+zvPE7S8V$j&%!1 zqvgFRV&+PZ(&z9^-q$IjN}=vV{zEx7R$e_JOmJnv zTB~s9QjZF-9xR~dEl}i`GWoMvUOW>D;K1|A9zsO|1e$0JMTI3UY+$IU8Yc0{a_WRE zD3%h9>6Kt41XI*)$NdmkW!!Qz)`C!P!OwsJ{Rm5~2sR6uOV}mV6ri9Sacb4@qD8ow zo+xN9XY13fG1`a76*2QW4akY0fpvpM^eq|_(GlPJq&yre&f3M%;)*ydU+!%pDxS$3KZpvLMFpyzr-T!=nWc1q z%oqd4D{u(tY656fL*%g$F03}^#*~(DEZ<+rb^C8B@odcg+At3mJ(kU_Os+n#INC+QNj)b{`Pqk7W+>6vaV|J0Zm1Rnr$j}JF0TpY|gh#PObXi78b9`l*)Ne>x7Dox>TeB>%nf3 zid4bTaiMI+RHOmTj(Y)052#2aAL%Ebk0oW`qi*;p=ZXU#^^lLux_o2;qg6gKfwJc# z3&4KykvH&BcYKs{#et8$Wj-odz_6NlRcmwkB9T8v?Jr%R%N^fg+2Z?HwkU}OyKXE% zrRAMNDZsc!pYG~#$m{Y$cME^ebv&pvv%IahyO|CdyR|$8*hZh$^1g~k|8=NWyQx_c9H+x*xf^p$%`qXtnQV>+x$8(6YuGO0JB4 zWa}YMchq+)IO33~d$`mMwFcg&TP7qMsM?;8#Mw0Z#7IAjY&7f#=!%yL?l{m=A8ARi zUnuDhMyu}+8i1CG9uTm^X>0-ms`0K`)#?Q+(SL-&iR6Tg3HKvXwDzSr^+~rp6%j_~ zJBHd3)H7X@=2>mRF;90#zbEr__a91t?);Zd007Yf