Correzioni minimali

diff --git a/Makefile b/Makefile
index d1fb1d0070eae7426e4afc233e079660657b456e..5792d756e3ce76c54cb8f870f83b16f76c1df29a 100644 (file)
--- a/Makefile
+++ b/Makefile
@@ -4,6 +4,7 @@ EPS_IMG = $(SOURCE_IMG:.dia=.eps)
 PDF_IMG = $(SOURCE_IMG:.dia=.pdf)
 SOURCE =  $(wildcard sources/*.c) $(wildcard sources/*.h) sources/Makefile
 
 PDF_IMG = $(SOURCE_IMG:.dia=.pdf)
 SOURCE =  $(wildcard sources/*.c) $(wildcard sources/*.h) sources/Makefile
 

+

 all: $(PDF_IMG) gapil.tgz htm 
 
 $(PDF_IMG): %.pdf: %.ps
 all: $(PDF_IMG) gapil.tgz htm 
 
 $(PDF_IMG): %.pdf: %.ps

diff --git a/ipc.tex b/ipc.tex
index 9dec79a907d64106343fb941ceac99990aed297b..0409edda7d80a3e657048bc702bae4859175eb1c 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -2925,13 +2925,14 @@ dal \textit{SysV IPC}.
 
 In realtà, grazie alla presenza del campo \var{mtype}, le code di messaggi
 hanno delle caratteristiche ulteriori, consentendo una classificazione dei
 
 In realtà, grazie alla presenza del campo \var{mtype}, le code di messaggi
 hanno delle caratteristiche ulteriori, consentendo una classificazione dei

-messaggi ed un accesso non rigidamente sequenziale, due caratteristiche che
-sono impossibili da ottenere con le pipe e i socket di \func{socketpair};
-a queste esigenze però si può comunque ovviare in maniera diversa con un uso
+messaggi ed un accesso non rigidamente sequenziale; due caratteristiche che
+sono impossibili da ottenere con le pipe e i socket di \func{socketpair}.  A
+queste esigenze però si può comunque ovviare in maniera diversa con un uso

 combinato della memoria condivisa e dei meccanismi di sincronizzazione, per
 cui alla fine l'uso delle code di messaggi classiche è poco diffuso.
 
 
 combinato della memoria condivisa e dei meccanismi di sincronizzazione, per
 cui alla fine l'uso delle code di messaggi classiche è poco diffuso.
 
 

+

 \subsection{La sincronizzazione con il \textit{file locking}}
 \label{sec:ipc_file_lock}
 
 \subsection{La sincronizzazione con il \textit{file locking}}
 \label{sec:ipc_file_lock}
 


@@ -2939,8 +2940,8 @@ Come illustrato in \secref{sec:ipc_sysv_sem} i semafori del \textit{SysV IPC}
 presentano una interfaccia inutilmente complessa e con alcuni difetti
 strutturali, per questo quando si ha una semplice esigenza di sincronizzazione
 per la quale basterebbe un semaforo binario (quello che abbiamo definito come
 presentano una interfaccia inutilmente complessa e con alcuni difetti
 strutturali, per questo quando si ha una semplice esigenza di sincronizzazione
 per la quale basterebbe un semaforo binario (quello che abbiamo definito come

-\textit{mutex}, che indica la disponibilità o meno di una risorsa, e non ha
-associato un contatore come i semafori) si possono utilizzare metodi
+\textit{mutex}), per indicare la disponibilità o meno di una risorsa, senza la
+necessità di un contatore come i semafori, si possono utilizzare metodi

 alternativi.
 
 La prima possibilità, utilizzata fin dalle origini di Unix, è quella di usare
 alternativi.
 
 La prima possibilità, utilizzata fin dalle origini di Unix, è quella di usare


@@ -2972,17 +2973,17 @@ una alternativa praticabile per la sincronizzazione:\footnote{ma pu
   una tecnica usata con successo quando l'esigenza è solo quella di segnalare
   l'occupazione di una risorsa, senza necessità di attendere che questa si
   liberi; ad esempio la si usa spesso per evitare interferenze sull'uso delle
   una tecnica usata con successo quando l'esigenza è solo quella di segnalare
   l'occupazione di una risorsa, senza necessità di attendere che questa si
   liberi; ad esempio la si usa spesso per evitare interferenze sull'uso delle

-  porte seriali da parte di più programmi: qualora trovi un file di lock il
+  porte seriali da parte di più programmi: qualora si trovi un file di lock il

   programma che cerca di accedere alla seriale si limita a segnalare che la
   risorsa non è disponibile.}  anzitutto anche in questo caso in caso di
 terminazione imprevista del processo lascia allocata la risorsa (il file di
 lock) e questa deve essere sempre cancellata esplicitamente.  Inoltre il
 controllo della disponibilità può essere fatto solo con una tecnica di
   programma che cerca di accedere alla seriale si limita a segnalare che la
   risorsa non è disponibile.}  anzitutto anche in questo caso in caso di
 terminazione imprevista del processo lascia allocata la risorsa (il file di
 lock) e questa deve essere sempre cancellata esplicitamente.  Inoltre il
 controllo della disponibilità può essere fatto solo con una tecnica di

-polling\index{polling}, che è molto inefficiente. 
+\textit{polling}\index{polling}, che è molto inefficiente.

 
 Per questo motivo la tecnica alternativa più pulita è quella di fare ricorso
 
 Per questo motivo la tecnica alternativa più pulita è quella di fare ricorso

-al \textit{file locking} visto in \secref{sec:file_locking} ed utilizzare
-\func{fcntl} su un file creato per l'occasione per ottenere un write lock; in
+al \textit{file locking} trattato in \secref{sec:file_locking} ed utilizzare
+\func{fcntl} su un file creato per l'occasione per ottenere un write lock. In

 questo modo potremo usare il lock come un \textit{mutex}: per bloccare la
 risorsa basterà acquisire il lock, per sbloccarla basterà rilasciare il lock;
 una richiesta fatta con un write lock metterà automaticamente il processo in
 questo modo potremo usare il lock come un \textit{mutex}: per bloccare la
 risorsa basterà acquisire il lock, per sbloccarla basterà rilasciare il lock;
 una richiesta fatta con un write lock metterà automaticamente il processo in


@@ -2998,12 +2999,21 @@ consuma risorse permanentemente allocate nel sistema, lo svantaggio 
 dovendo fare ricorso a delle operazioni sul filesystem esso è in genere
 leggermente più lento.
 
 dovendo fare ricorso a delle operazioni sul filesystem esso è in genere
 leggermente più lento.
 

+Il codice per implementare un mutex utilizzando il file locking è riportato in 
+
+
+

 
 
 \subsection{Il \textit{memory mapping} anonimo}
 \label{sec:ipc_mmap_anonymous}
 
 
 
 \subsection{Il \textit{memory mapping} anonimo}
 \label{sec:ipc_mmap_anonymous}
 

-Abbiamo visto in \secref{sec:file_memory_map} come sia possibile 
+Abbiamo visto in \secref{sec:file_memory_map} come sia possibile mappare il
+contenuto di un file nella memoria di un processo. Una della opzioni possibili
+utilizzabili con Linux è quella del \textit{memory mapping}
+anonimo\footnote{in altri sistemi una funzionalità simile a questa viene
+  implementata mappando il file speciale \file{/dev/zero}.}, in tal caso
+infatti 

 
 
 \section{La comunicazione fra processi di POSIX}
 
 
 \section{La comunicazione fra processi di POSIX}