From: Simone Piccardi Date: Mon, 2 Dec 2002 21:45:02 +0000 (+0000) Subject: Sistemati alcuni cross ref per i file di lock X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=4263734ffe237b1a7249c1f8121bb7ebe8b60a50;p=gapil.git Sistemati alcuni cross ref per i file di lock --- diff --git a/fileunix.tex b/fileunix.tex index d5221ca..8a39680 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -295,10 +295,10 @@ sempre il file descriptor con il valore pi \footnotetext[2]{la pagina di manuale di \func{open} segnala che questa opzione è difettosa su NFS, e che i programmi che la usano per stabilire un - file di lock (vedi \secref{sec:ipc_file_lock}) possono incorrere in una race + \textsl{file di lock}\index{file di lock} possono incorrere in una race condition\index{race condition}. Si consiglia come alternativa di usare un file con un nome univoco e la funzione \func{link} per verificarne - l'esistenza.} + l'esistenza (vedi \secref{sec:ipc_file_lock}).} \footnotetext[3]{\textit{Denial of Service}, si chiamano così attacchi miranti ad impedire un servizio causando una qualche forma di carico eccessivo per @@ -767,7 +767,7 @@ problema, quando si andr maniera imprevedibile. Il sistema però fornisce in alcuni casi la possibilità di eseguire alcune operazioni di scrittura in maniera coordinata anche senza utilizzare meccanismi di sincronizzazione più complessi (come il \textit{file - locking}, che esamineremo in \secref{cha:file_advanced}). + locking}, che esamineremo in \secref{sec:file_locking}). Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui vari processi devono scrivere alla fine di un file (ad esempio un file di @@ -789,17 +789,19 @@ avviene all'interno di una singola system call (la \func{write}) che non essendo interrompibile da un altro processo costituisce un'operazione atomica. Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole -creare un file di lock, bloccandosi se il file esiste. In questo caso la -sequenza logica porterebbe a verificare prima l'esistenza del file con una -\func{stat} per poi crearlo con una \func{creat}; di nuovo avremmo la -possibilità di una race condition\index{race condition} da parte di un altro -processo che crea lo stesso file fra il controllo e la creazione. +creare un \textsl{file di lock}\index{file di lock}, bloccandosi se il file +esiste. In questo caso la sequenza logica porterebbe a verificare prima +l'esistenza del file con una \func{stat} per poi crearlo con una \func{creat}; +di nuovo avremmo la possibilità di una race condition\index{race condition} da +parte di un altro processo che crea lo stesso file fra il controllo e la +creazione. Per questo motivo sono stati introdotti per \func{open} i due flag \macro{O\_CREAT} e \macro{O\_EXCL}. In questo modo l'operazione di controllo dell'esistenza del file (con relativa uscita dalla funzione con un errore) e creazione in caso di assenza, diventa atomica essendo svolta tutta all'interno -di una singola system call. +di una singola system call (per i dettagli sull'uso di questa caratteristica +si veda \secref{sec:ipc_file_lock}). \subsection{La funzioni \func{sync} e \func{fsync}} diff --git a/gapil.tex b/gapil.tex index e3c27df..f6de7cf 100644 --- a/gapil.tex +++ b/gapil.tex @@ -21,8 +21,8 @@ \usepackage{listings} \lstloadlanguages{C++} \usepackage{color} -%\usepackage{mdwlist} % scommentare per la stampa (PS e PDF) -%\usepackage{boxedminipage} % scommentare per la stampa (PS e PDF) +\usepackage{mdwlist} % scommentare per la stampa (PS e PDF) +\usepackage{boxedminipage} % scommentare per la stampa (PS e PDF) \usepackage{multirow} %\usepackage{footnote} %\usepackage{mdwtab} @@ -73,8 +73,9 @@ \tableofcontents \clearemptydoublepage - -\include{compatib} % commentare per la stampa PS e PDF +% commentare per la stampa PS e PDF +%\include{compatib} % commentare per la stampa PS e PDF +% commentare per la stampa PS e PDF \include{macro} \setcounter{secnumdepth}{-2} \include{pref} diff --git a/ipc.tex b/ipc.tex index 0409edd..ce4842e 100644 --- a/ipc.tex +++ b/ipc.tex @@ -2945,9 +2945,9 @@ necessit alternativi. La prima possibilità, utilizzata fin dalle origini di Unix, è quella di usare -dei \textsl{file di lock} (per i quali esiste anche una opportuna directory, -\file{/var/lock}, nel filesystem standard). Per questo si usa la -caratteristica della funzione \func{open} (illustrata in +dei \textsl{file di lock}\index{file di lock} (per i quali esiste anche una +opportuna directory, \file{/var/lock}, nel filesystem standard). Per questo si +usa la caratteristica della funzione \func{open} (illustrata in \secref{sec:file_open}) che prevede\footnote{questo è quanto dettato dallo standard POSIX.1, ciò non toglie che in alcune implementazioni questa tecnica possa non funzionare; in particolare per Linux, nel caso di NFS, si @@ -2961,12 +2961,11 @@ il rilascio si pu questa tecnica può non funzionare se il filesystem su cui si va ad operare è su NFS; in tal caso si può adottare una tecnica alternativa che prevede l'uso di \func{link} per creare come file di lock un hard link ad un file - esistente; se il link esiste già e la funzione fallisce, la risorsa - significa che la risorsa è bloccata e potrà essere sbloccata solo con un - \func{unlink}, altrimenti il link è creato ed il lock acquisito; il - controllo e l'eventuale acquisizione sono atomici; il difetto di questa - soluzione è che funziona solo se si opera all'interno di uno stesso - filesystem.} + esistente; se il link esiste già e la funzione fallisce, significa che la + risorsa è bloccata e potrà essere sbloccata solo con un \func{unlink}, + altrimenti il link è creato ed il lock acquisito; il controllo e l'eventuale + acquisizione sono atomici; il difetto di questa soluzione è che funziona + solo se si opera all'interno di uno stesso filesystem.} L'uso di un file di lock presenta però parecchi problemi, che non lo rendono una alternativa praticabile per la sincronizzazione:\footnote{ma può essere