From: Simone Piccardi <piccardi@gnulinux.it>
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