From 8f0ff8d62835c0dc1be10ade261dba276959fc4a Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Wed, 27 Nov 2002 22:37:48 +0000 Subject: [PATCH] Correzioni minimali --- Makefile | 1 + ipc.tex | 30 ++++++++++++++++++++---------- 2 files changed, 21 insertions(+), 10 deletions(-) diff --git a/Makefile b/Makefile index d1fb1d0..5792d75 100644 --- 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 + all: $(PDF_IMG) gapil.tgz htm $(PDF_IMG): %.pdf: %.ps diff --git a/ipc.tex b/ipc.tex index 9dec79a..0409edd 100644 --- 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 -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. + \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 -\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 @@ -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 - 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 -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 -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 @@ -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. +Il codice per implementare un mutex utilizzando il file locking è riportato in + + + \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} -- 2.30.2