devono eseguire operazioni che possono bloccarsi su più file descriptor:
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 deadlock.
+inutilmente, e nel peggiore si potrebbe addirittura arrivare ad un
+\textit{deadlock}.
Abbiamo già accennato in \secref{sec:file_open} che è possibile prevenire
questo tipo di comportamento aprendo un file in modalità
riportati sul file. Ne viene fatta una copia
privata cui solo il processo chiamante ha
accesso. Le modifiche sono mantenute attraverso
- il meccanismo del \textit{copy on write} e
+ il meccanismo del
+ \textit{copy on write}\index{copy on write} e
salvate su swap in caso di necessità. Non è
specificato se i cambiamenti sul file originale
vengano riportati sulla regione
\macro{MAP\_EXECUTABLE}& Ignorato. \\
\macro{MAP\_NORESERVE} & Si usa con \macro{MAP\_PRIVATE}. Non riserva
delle pagine di swap ad uso del meccanismo di
- \textit{copy on write} per mantenere le
+ \textit{copy on write}\index{copy on write}
+ per mantenere le
modifiche fatte alla regione mappata, in
questo caso dopo una scrittura, se non c'è più
memoria disponibile, si ha l'emissione di
mappate. \\
\macro{MAP\_GROWSDOWN} & Usato per gli stack. Indica
che la mappatura deve essere effettuata con gli
- indirizzi crecenti verso il basso.\\
+ indirizzi crescenti verso il basso.\\
\macro{MAP\_ANONYMOUS} & La mappatura non è associata a nessun file. Gli
argomenti \param{fd} e \param{offset} sono
ignorati.\footnotemark\\
La prima modalità di file locking che è stata implementata nei sistemi
unix-like è quella che viene usualmente chiamata \textit{advisory
- locking},\footnote{Stevens in APUE fa riferimento a questo argomento come al
- \textit{record locking}, dizione utilizzata anche dal manuale delle
+ locking},\footnote{Stevens in \cite{APUE} fa riferimento a questo argomento
+ come al \textit{record locking}, dizione utilizzata anche dal manuale delle
\acr{glibc}; nelle pagine di manuale si parla di \textit{discretionary file
lock} per \func{fcntl} e di \textit{advisory locking} per \func{flock},
mentre questo nome viene usato anche da Stevens per riferirsi al
che pertanto possono coesistere senza interferenze.
Entrambe le interfacce prevedono la stessa procedura di funzionamento: si
-inizia sempre con il richiere l'opportuno \textit{file lock} (un
+inizia sempre con il richiedere l'opportuno \textit{file lock} (un
\textit{exclusive lock} per una scrittura, uno \textit{shared lock} per una
lettura) prima di eseguire l'accesso ad un file. Se il lock viene acquisito
il processo prosegue l'esecuzione, altrimenti (a meno di non aver richiesto un
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
alternativa. Se si specifica anche \macro{LOCK\_NB} la funzione non si
-bloccherà qualora il lock non possa essere aqcuisito, ma ritornerà subito con
+bloccherà qualora il lock non possa essere acquisito, 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 queste
-differenze occore prima descrivere con maggiore dettaglio come viene
+differenze occorre prima descrivere con maggiore dettaglio come viene
realizzato il file locking nel kernel.
In \figref{fig:file_flock_struct} si è riportato uno schema essenziale
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 loking sono tre:
+specifica l'azione da compiere; i valori relativi al file locking sono tre:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\macro{F\_GETLK}] verifica se il file lock specificato dalla struttura
puntata da \param{lock} non è bloccato da qualche altro lock: in caso
che quello che conta è solo il \acr{pid} del processo. Da questo deriva una
ulteriore sottile differenza di comportamento: dato che alla chiusura di un
file i lock ad esso associati vengono rimossi, nella semantica POSIX basterà
-chiudere un file descriptor per cancellare tutti i lock realtivi al file cui
+chiudere un file descriptor per cancellare tutti i lock relativi al file cui
esso faceva riferimento, anche se questi fossero stati creati usando altri
file descriptor che restano aperti.
Abbiamo visto come l'interfaccia POSIX per il file locking sia molto più
potente e flessibile di quella di BSD, ma è anche molto più complicata da
-usare. Per questo motivo è disponibile anche una interfaccia semplificata
-(ripresa da System V) che utilizza la funzione \func{lockf}, il cui prototipo
-è:
+usare per le 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 è:
\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}.
\bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\macro{EAGAIN}] Non è possibile acquisire il lock, e si è
+ \item[\macro{EWOULDBLOCK}] Non è possibile acquisire il lock, e si è
selezionato \macro{LOCK\_NB}, oppure l'operazione è proibita perché il
file è mappato in memoria.
\item[\macro{ENOLCK}] Il sistema non ha le risorse per il locking: ci sono
troppi segmenti di lock aperti, si è esaurita la tabella dei lock.
- \item[\macro{EDEADLK}] Si è riconosciuta una situazione di
- \textit{deadlock}.
\end{errlist}
ed inoltre \macro{EBADF}, \macro{EINVAL}.
}
\end{prototype}
Il comportamento della funzione dipende dal valore dell'argomento \param{cmd}
-che specifica quale azione eseguire; i valori possibili sono riportati in
+che specifica quale azione eseguire; i valori possibili sono riportati in
+\tabref{tab:file_lockf_type}.
+
\begin{table}[htb]
\centering
\footnotesize
- \begin{tabular}[c]{|l|l|}
+ \begin{tabular}[c]{|l|p{8cm}|}
\hline
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \macro{F\_LOCK} & Richiede un \textit{exclusive lock}. Se non può essere
- ottenuto a causa di un lock preesistente la funzione
- blocca il processo chiamante fino al rilascio di
- quest'ultimo. \\
- \macro{F\_TLOCK}& Stesso comportamento di \macro{F\_LOCK} ma la funzione
- ritorna sempre subito, segnalando un errore quando il
- lock non può essere acquisito. \\
- \macro{F\_ULOCK}& Sblocca il file.\\
- \macro{F\_TEST} & Controlla il lock, la funzione restituisce 0 se il file
- non ha lock, o i lock appartengono al processo corrente,
- e -1, con un errore di \macro{EACCES}, se altri processi
- detengono un lock sul file.\\
+ \macro{LOCK\_SH}& Richiede uno \textit{shared lock}. Più processi possono
+ mantenere un lock condiviso sullo stesso file.\\
+ \macro{LOCK\_EX}& Richiede un \textit{exclusive lock}. Un solo processo
+ alla volta può mantenere un lock esclusivo su un file. \\
+ \macro{LOCK\_UN}& Sblocca il file.\\
+ \macro{LOCK\_NB}& Non blocca la funzione quando il lock non è disponibile,
+ si specifica sempre insieme ad una delle altre operazioni
+ con un OR aritmetico dei valori.\\
\hline
\end{tabular}
\caption{Valori possibili per il campo \var{cmd} di \func{lockf}.}
\label{tab:file_lockf_type}
\end{table}
+Qualora il lock non possa essere acquisito, a meno di non aver specificato
+\macro{LOCK\_NB}, la funzione si blocca fino alla disponibilità dello stesso.
+Dato che la funzione è implementata utilizzando \func{fcntl} la semantica
+delle operazioni è la stessa di quest'ultima (pertanto la funzione non è
+affatto equivalente a \func{flock}).
\label{sec:file_mand_locking}
Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4,
-per introdurre un file locking che come dice il nome, fosse effettivo
+per introdurre un file locking che, come dice il nome, fosse effettivo
indipendentemente dai controlli eseguiti da un processo. Con il
\textit{mandatory locking} infatti è possibile far eseguire il blocco del file
-direttamente al sistema, così che anche qualora non si predisponessero le
+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 \acr{suid}. Se si ricorda quanto esposto in
-\secref{sec:file_suid_sgid}), esso viene di norma utilizzato per cambiare
-l'userid effettivo con cui viene eseguito un programma, ed è pertanto sempre
-associato alla presenza del permesso di esecuzione. 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}.
+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
+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
+ \secref{sec:file_chmod} 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 root può passare sopra ad un lock; pertanto un processo che blocchi un
+file cruciale può renderlo completamente inaccessibile, rendendo completamente
+inutilizzabile il sistema\footnote{il problema si potrebbe risolvere
+ rimuovendo il bit \acr{sgid}, ma non è detto che sia così facile fare questa
+ operazione con un sistema bloccato.} inoltre con il \textit{mandatory
+ locking} si può bloccare completamente un server NFS richiedendo una lettura
+su un file su cui è attivo un lock. Per questo motivo l'abilitazione del
+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 \tabref{tab:sys_mount_flags}, o con l'opzione
+\cmd{mand} per il comando).
+
+Si tenga presente inoltre che il \textit{mandatory locking} funziona
+sull'interfaccia POSIX di \func{fcntl}, questo significa che non ha nessun
+effetto sui lock richiesti con l'interfaccia di \func{flock}, ed inoltre che
+la granularità del lock è quella del singolo byte, come per \func{fcntl}.
+
+La sintassi di acquisizione dei lock è esattamente la stessa vista in
+precedenza per \func{fcntl} e \func{lockf}, la differenza è che in caso di
+mandatory lock attivato non è più necessario controllare la disponibilità di
+accesso al file, ma si potranno usare direttamente le ordinarie funzioni di
+lettura e scrittura e sarà compito del kernel gestire direttamente il file
+locking.
+
+Questo significa che in caso di read lock la lettura dal file potrà avvenire
+normalmente con \func{read}, mentre una \func{write} si bloccherà fino al
+rilascio del lock, a meno di non aver aperto il file con \macro{O\_NONBLOCK},
+nel qual caso essa ritornerà immediatamente con un errore di \macro{EAGAIN}.
+
+Se invece si è acquisito un write lock tutti i tentativi di leggere o scrivere
+sulla regione del file bloccata fermeranno il processo fino al rilascio del
+lock, a meno che il file non sia stato aperto con \macro{O\_NONBLOCK}, nel
+qual caso di nuovo si otterrà un ritorno immediato con l'errore di
+\macro{EAGAIN}.
+
+Infine occorre ricordare che le funzioni di lettura e scrittura non sono le
+sole ad operare sui contenuti di un file, e che sia \func{creat} che
+\func{open} (quando chiamata con \macro{O\_TRUNC}) effettuano dei cambiamenti,
+così come \func{truncate}, riducendone le dimensioni (a zero nei primi due
+casi, a quanto specificato nel secondo). Queste operazioni sono assimilate a
+degli accessi in scrittura e pertanto non potranno essere eseguite (fallendo
+con un errore di \macro{EAGAIN}) su un file su cui sia presente un qualunque
+lock (le prime due sempre, la terza solo nel caso che la riduzione delle
+dimensioni del file vada a sovrapporsi ad una regione bloccata).
+
+L'ultimo aspetto della interazione del \textit{mandatory locking} con le
+funzioni di accesso ai file è quello relativo ai file mappati in memoria
+appena trattati in \secref{sec:file_memory_map}; anche in tal caso infatti,
+quando si esegue la mappatura con l'opzione \macro{MAP\_SHARED}, si ha un
+accesso al contenuto del file. Lo standard SVID prevede che sia impossibile
+eseguire il memory mapping di un file su cui sono presenti dei
+lock\footnote{alcuni sistemi, come HP-UX, sono ancora più restrittivi e lo
+ impediscono anche in caso di \textit{advisory locking}, anche se questo non
+ ha molto senso.} in Linux è stata però fatta la scelta implementativa di
+seguire questo comportamento soltanto quando si chiama \func{mmap} con
+l'opzione \macro{MAP\_SHARED} (nel qual caso la funzione fallisce con il
+solito \macro{EAGAIN}).
+
projects / gapil.git / blobdiff