Inizio delle considerazioni sull'uso della shared memory.
authorSimone Piccardi <piccardi@gnulinux.it>
Sun, 22 Dec 2002 12:57:37 +0000 (12:57 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Sun, 22 Dec 2002 12:57:37 +0000 (12:57 +0000)
ipc.tex

diff --git a/ipc.tex b/ipc.tex
index 270113c21792b3bea832acfc24279a8c5c388d4d..47210133d3db4c92b29cd38486e3f5425e7b6792 100644 (file)
--- 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,
 
 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} 
 \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.
 
 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
 
 %% 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
 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
 
 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 è
 \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
 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}
 
 
 \subsection{Memoria condivisa}