From: Simone Piccardi <piccardi@gnulinux.it>
Date: Sun, 22 Dec 2002 12:57:37 +0000 (+0000)
Subject: Inizio delle considerazioni sull'uso della shared memory.
X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=46029a05c9009df38022e82b0f20732290388ef1;p=gapil.git

Inizio delle considerazioni sull'uso della shared memory.
---

diff --git a/ipc.tex b/ipc.tex
index 270113c..4721013 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -1231,8 +1231,12 @@ mantenuta staticamente all'interno del sistema.
 
 Il primo oggetto introdotto dal \textit{SysV IPC} è quello delle code di
 messaggi.  Le code di messaggi sono oggetti analoghi alle pipe o alle fifo,
-anche se la loro struttura è diversa. La funzione che permette di ottenerne
-una è \func{msgget} ed il suo prototipo è:
+anche se la loro struttura è diversa, ed il loro scopo principale è appunto
+quello di permettere a processi diversi di scambiarsi dei dati.
+
+La funzione che permette di richiedere al sistema l'identificatore di una coda
+di messaggi esistente (o di crearne una se questa non esiste) è \func{msgget};
+il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/ipc.h} 
@@ -2919,6 +2923,38 @@ In caso di successo la funzione aggiorna anche i seguenti campi di
 inoltre la regione di indirizzi usata per il segmento di memoria condivisa
 viene tolta dallo spazio di indirizzi del processo.
 
+Benché la memoria condivisa costituisca il meccanismo di intercomunicazione
+fra processi più veloce, essa non è sempre il più appropriato, dato che, come
+abbiamo visto, si avrà comunque la necessità di una sincronizzazione degli
+accessi.  Per questo motivo, quando la comunicazione fra processi è
+sequenziale, altri meccanismi come le pipe, le fifo o i socket, che non
+necessitano di sincronizzazione esplicita, sono da preferire. Essa diventa
+l'unico meccanismo possibile quando la comunicazione non è
+sequenziale\footnote{come accennato in \secref{sec:ipc_sysv_mq} per la
+  comunicazione non sequenziale si possono usare le code di messaggi,
+  attraverso l'uso del campo \var{mtype}, ma solo se quest'ultima può essere
+  effettuata in forma di messaggio.} o quando non può avvenire secondo una
+modalità predefinita.
+
+Un esempio classico di uso della memoria condivisa è quello del ``monitor'',
+in cui essa viene per scambiare informazioni fra un processo ``server'' che vi
+scrive dei dati di interesse generale che ha ottenuto, e tutti i processi
+``client'' interessati agli stessi dati che così possono leggerli in maniera
+completamente asincrona.  Con questo schema di funzionamento da una parte si
+evita che ciascun processo ``client'' debbia compiere l'operazione,
+potenzialmente onerosa, di ricavare e trattare i dati, e dall'altra si evita
+al processo ``server'' di dover gestire l'invio a tutti i client di tutti i
+dati (non potendo il server sapere quali di essi servono effettivamente al
+singolo client).
+
+Nel nostro caso implementeremo un ``monitor'' di una directory: un processo si
+incaricherà di tenere sotto controllo alcuni parametri relativi ad una
+directory (il numero dei file contenuti, la dimenzione totale, ecc.) che
+saranno salvati in un segmento di memoria condivisa cui altri processi
+potranno accedere per ricavare la parte di informazione che interessa.
+
+
+
 
 %% Per capire meglio il funzionamento delle funzioni facciamo ancora una volta
 %% riferimento alle strutture con cui il kernel implementa i segmenti di memoria
@@ -2953,9 +2989,9 @@ tecniche alternative, che vogliamo riprendere in questa sezione.
 Le code di messaggi sono probabilmente il meno usato degli oggetti del
 \textit{SysV IPC}; esse infatti nacquero principalmente come meccanismo di
 comunicazione bidirezionale quando ancora le pipe erano unidirezionali; con la
-disponibilità di \func{socketpair} (vedi \secref{sec:ipc_socketpair}) si può
-ottenere lo stesso risultato senza incorrere nelle complicazioni introdotte
-dal \textit{SysV IPC}.
+disponibilità di \func{socketpair} (vedi \secref{sec:ipc_socketpair}) o
+utilizzando una coppia di pipe, si può ottenere questo risultato senza
+incorrere nelle complicazioni introdotte 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
@@ -2964,7 +3000,7 @@ sono impossibili da ottenere con le pipe e i socket\index{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.
+relativamente poco diffuso.
 
 
 
@@ -3239,7 +3275,7 @@ Dei semafori POSIX esistono sostanzialmente due implementazioni; una 
 livello di libreria ed è fornita dalla libreria dei thread; questa però li
 implementa solo a livello di thread e non di processi. Esiste un'altra
 versione, realizzata da Konstantin Knizhnik, che reimplementa l'interfaccia
-POSIX usando i semafori di SysV IPC.
+POSIX usando i semafori di SysV IPC. 
 
 
 \subsection{Memoria condivisa}