From 52f9927779abf41607e5f7741a9aa978ac23d6e1 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Sat, 19 Oct 2002 14:42:17 +0000 Subject: [PATCH] Risistemata flock, aggiunta figura sulla struttura del sistema --- fileadv.tex | 112 ++++++++++++++++++++++++++------------------- img/struct_sys.dia | Bin 0 -> 2099 bytes intro.tex | 12 ++++- 3 files changed, 75 insertions(+), 49 deletions(-) create mode 100644 img/struct_sys.dia diff --git a/fileadv.tex b/fileadv.tex index c269d6a..349d157 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -1329,28 +1329,32 @@ costanti riportate in \tabref{tab:file_flock_operation}. I primi due valori, \macro{LOCK\_SH} e \macro{LOCK\_EX} permettono di richiedere un \textit{file lock}, ed ovviamente devono essere usati in maniera -esclusiva. Se si specifica anche \macro{LOCK\_NB} la funzione non si bloccherà -qualora il lock non possa essere aqcuisito, ma ritornerà subito con un errore -di \macro{EWOULDBLOCK}. Per rilasciare un lock si dovrà invece usare -\macro{LOCK\_NB}. +alternativa. Se si specifica anche \macro{LOCK\_NB} la funzione non si +bloccherà qualora il lock non possa essere aqcuisito, ma ritornerà subito con +un errore di \macro{EWOULDBLOCK}. Per rilasciare un lock si dovrà invece usare +\macro{LOCK\_NB}. La semantica del file locking di BSD è diversa da quella del file locking POSIX, in particolare per quanto riguarda il comportamento dei lock nei -confronti delle due funzioni \func{dup} e \func{fork}. Per capire cosa -succede in questi casi, occorre tenere presente che il file locking (qualunque -sia l'interfaccia che si usa), anche se richiesto attraverso un file -descriptor, agisce sempre su un file, secondo lo schema di -\figref{fig:file_lock_struct}. Questo significa che le informazioni relative -agli eventuali lock sono mantenute a livello di inode,\footnote{come mostrato - 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}, il - cui indirizzo iniziale è mantenuto dal campo \var{i\_flock} della struttura - \var{inode} (il tutto è definito nei sorgenti del kernel in \file{fs.h}). Un - bit del campo \var{fl\_flags} di specifica se si tratta di un lock in - semantica BSD (\macro{FL\_FLOCK}) o POSIX (\macro{FL\_POSIX}).} come è -naturale dato che l'inode è l'unica cosa in comune cui possono accedere due -processi diversi che aprono lo stesso file. - +confronti delle due funzioni \func{dup} e \func{fork}. Per capire queste +differenze occore prima descrivere con maggiore dettaglio come viene +realizzato il file locking nel kernel. + +In \figref{fig:file_flock_struct} si è riportato uno schema essenziale +dell'implementazione del file locking in Linux; il punto 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 + (\macro{FL\_FLOCK}) o POSIX (\macro{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 @@ -1360,36 +1364,48 @@ processi diversi che aprono lo stesso file. \label{fig:file_flock_struct} \end{figure} - - -Nel caso dei lock creati con \func{flock} la semantica prevede che sia -\func{dup} che \func{fork} non creano ulteriori istanze di un \textit{file +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 +\func{dup} che \func{fork} non creino ulteriori istanze di un \textit{file lock} quanto piuttosto degli ulteriori riferimenti allo stesso. Questo viene -realizzato dal kernel mantenendo per ciascun \textit{file lock} un -puntatore\footnote{nel campo \var{fl\_file} di \var{file\_lock}.} al file -nella \textit{file table} cui esso fa riferimento. - - -che il kernel mantiene per ciascuno di -essi\footnote{nel campo \var{fl\_file}.} anche un riferimento - -essi fanno riferimento al - - - - -Si tenga presente che la funzione blocca direttamente un file (cioè, rispetto -allo schema di \secref{fig:file_stat_struct}, il blocco è mantenuto in -riferimento alla struttura \var{file}, e non al file descriptor). Pertanto sia -\func{dup} che \func{fork} non creano ulteriori istanze di un \textit{file - lock} quanto piuttosto degli ulteriori riferimenti allo stesso. Questo -comporta che un \textit{file lock} può essere rimosso su uno qualunque dei -file descriptor che fanno riferimento allo stesso file: quindi se si toglie il -blocco in un processo figlio o su un file descriptor duplicato, questo sarà -cancellato rispettivamente anche nel processo padre e sul file descriptor -originario. - - +realizzato dal kernel 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 blocco, +che così ne identifica il titolare. + +Questa struttura comporta che, quando si richiede la rimozione di un file +lock, il kernel acconsenta solo se la richiesta proviene da un file descriptor +che fa riferimento ad una voce nella file table corrispondente a quella +registrata nel blocco. Allora se ricordiamo quanto visto in +\secref{sec:file_dup} e \secref{sec:file_sharing}, e cioè che i file +descriptor duplicati e quelli ereditati in un processo figlio puntano sempre +alla stessa voce nella file table, si può capire immediatamente quali sono le +conseguenze nei confronti delle funzioni \func{dup} e \func{fork}. + +Sarà cioè possibile rimuovere un file lock attraverso uno qualunque dei file +descriptor che fanno riferimento alla stessa voce nella file table, quindi +anche se questo è diverso da quello con cui lo si è +creato,\footnote{attenzione, questo non vale se il file descriptor fa + riferimento allo stesso file, ma attraverso una voce diversa della file + table, come accade tutte le volte che si apre più volte lo stesso file.} o +se si esegue la rimozione in un processo figlio; inoltre una volta tolto un +file lock, la rimozione avrà effetto su tutti i file descriptor che +condividono la stessa voce nella file table, e quindi, nel caso di file +descriptor ereditati attraverso una \func{fork}, anche su processi diversi. + +Infine, per evitare che la terminazione imprevista di un processo lasci attivi +dei file lock, è previsto che quando un file viene chiuso il kernel provveda +anche a rimuovere tutti i lock ad esso associati. Anche in questo caso occorre +tenere presente cosa succede quando si hanno file descriptor duplicati; in tal +caso infatti il file non verrà effettivamente chiuso (ed il lock rimosso) +fintanto che non viene rilasciata la relativa voce nella file table; la +rimozione cioè avverrà solo quando tutti i file descriptor che fanno +riferimento alla stessa voce sono stati chiusi, quindi, nel caso ci siano +processi figli che mantengono ancora aperto un file descriptor, il lock non +sarà rilasciato. \subsection{Il file locking POSIX} diff --git a/img/struct_sys.dia b/img/struct_sys.dia new file mode 100644 index 0000000000000000000000000000000000000000..96ef2d5f306dd3bbf25cc2942db1c0b610f0d5f5 GIT binary patch literal 2099 zcmV-32+a2%iwFP!000001MOYga-%p9eV?zOJg*rUBypQeGPRSv)K=}Sc4qc9g>8+^ zE(VvtN&K?kzLFua4Z;^BkvOYVITeW9O^en!>Q*B@e0-QE)*YdFoTXO-2iOCPq~mN7 zr_-y!*DpW53kDyr-+Y+F(R=op(r9k6Z=^Xtx*E)iV)1@ByuZH($tsVEjDjRyf}9Nh zjgll9vPQ$f^&89D7BGp5h@Y#@Mnys6(Xt>`8qLYoU=)r2nbK^TP6lPGs@*tCGHTsL z$<^TPxAo6pScw_#$k`)%5iJOL#l>2y6 z%x)j{b(ak!I;@nx(kA~d&f`%+L>9zpA$`9e#jhmA%iil{JR$jkyS>|{MbfNlHaui_ zz1^`El&5M$wN{ZtD?%&rpEeX_Ref9y{HIDEyKDz|PDlBpj7|tWbn!N@ zJIc>z+5N3xmUWoT#6y0#@%AI!{|k921pe>H`afje0=4=-bN$feE*S)u2>3R}OraNa z(^&9ssOhU?Vy#Wv?OabXciPqFqyG>#(vp@r=^jpLn?+=4AyUWBS53aebCSRNxnPr- z@ithWuBM|oElHR}jQq-Z;|vDZIxideT#(>W2}CXz1a0_xv4w-Ax1 z8Z`JNPKf{wpe!0Vz`4KxX=THZQJ@`MIskE1u$!)NmZrBPovg3@B#XpN(DronlnY^A zF<#X5i)M+Z2xYMh(MV)PM2p*q((Jx2e&gg&TJ~*1(&>H+6eu~^OC5DE-_q1YPm=X@ z&_;!-?&0H&4P=Hkd4qi)|6|Pc_!o8!i%v?=H6XTauIU9#5#*CiAF{s!iBz^Y`J%x%VG2fNI$NBG z5sU~|VueJUj5&ba2QsPK9^EZn;;L|82XJ5Vw7ahZYzHw-7`wiMdB7BK*Yehf-L;F; zBL|Zxr=(G8iIkf^zP4sj_D1Q)XHuHEl$&fxV>VWYvf6~Hl>PkCRaG;ga+LRVQzlBQ z9GO_@qOL8uawxsBKaC?!v7CS-<(VyNR7RDa3ao*^>4hpGuq&!$5kOy5DQ%pgN_|x6 zt8rhi7pi2Q#8`2|l`OP&F*-}KoRfJ*uYN0^}s_r<-?B?4Z6w?az{kmH_bY&nVZac0O;6aR6idH{9Tbo5eI!=7dnsSA0&g{*!`#-wY;FkiCN=uTWdyL(=UA#*9mgW&}R zHa~p%MPtjHP%B?VW72=&*q_-vO8clAL%Qq6Y996)s>bZ+uNrFu1gHWKkk%s7QUk0Y z0b`p}fO{U0P}Y$eP*4F1=(QD-_6Q5d=V-*wS~y6};(xOcNzdZH%L}X4i~kZd{23BLtz`QuN)8%sXwpK@w}R5b&aSF@1Kd}=0e-4C=!c!9jWg{0O4!*`Rou`A zJ3|1s*%^Y+u(M(3eQs#j`Ngrbuco-6pV%2a#m>0D*cqAF*|76^tSBi2!ac>#Xg7Ao zCU!RLyx$ECJ3n_xMJT`ErF)+QRPK`yu8Xt!ct98*-Y5Z=8zqw?U0meK zZzapUQtwk|zUMgHE32wS4+SCDc_xw3ct$46gisR~NyJ4BH#3ouR$TB@+GCT`H0I=Zm=YNAs{wEAB_QM0FQOV7YmRhX&@Q&pj|ssciZZP&4)ZP!ml&`?c; zisT@7A1bPOV(NnzojT{x#Pe_0D6WV&GatL)7KcRDdrLqmo!uRp{Yy_1Q z1OwlLn#-T;kUPHX20pKWLfGabBDC4z%TH_n^xIeKhRxnaG@>h$+?Fg0t~r~@a32Q{ d<#7_N2)%w&9}) e Linux non fa eccezione. Queste sono poi state codificate da vari -standard, che esamineremo brevemente in \secref{sec:intro_standard}. +standard, che esamineremo brevemente in \secref{sec:intro_standard}. Uno +schema elementare della struttura del sistema è riportato in +\figref{fig:intro_sys_struct}. + +\begin{figure}[htb] + \centering + \includegraphics[width=10cm]{img/struct_sys} + \caption{Schema di massima della struttura di interazione fra processi, + kernel e dispositivi in Linux.} + \label{fig:intro_sys_struct} +\end{figure} Normalmente ciascuna di queste chiamate al sistema viene rimappata in opportune funzioni con lo stesso nome definite dentro la Libreria Standard del -- 2.30.2