Inizio delle considerazioni sull'uso della shared memory.

[gapil.git] / ipc.tex

diff --git a/ipc.tex b/ipc.tex
index da8d31719fb989b7878b2087d3db17360d19bd70..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} 


@@ -2564,22 +2568,7 @@ il mutex. Entrambe fanno da wrapper per \func{semop}, utilizzando le due
 strutture \var{sem\_lock} e \var{sem\_unlock} definite in precedenza
 (\texttt{\small 32--42}). Si noti come per queste ultime si sia fatto uso
 dell'opzione \const{SEM\_UNDO} per evitare che il semaforo resti bloccato in
 strutture \var{sem\_lock} e \var{sem\_unlock} definite in precedenza
 (\texttt{\small 32--42}). Si noti come per queste ultime si sia fatto uso
 dell'opzione \const{SEM\_UNDO} per evitare che il semaforo resti bloccato in

-caso di terminazione imprevista del processo.%%  Si noti infine come, essendo
-%% tutte le funzioni riportate in \figref{fig:ipc_mutex_create} estremamente
-%% semplici, se si sono definite tutte come \ctyp{inline}.\footnote{la direttiva
-%%   \func{inline} viene usata per dire al compilatore di non trattare la
-%%   funzione cui essa fa riferimento come una funzione, ma di inserire il codice
-%%   direttamente nel testo del programma.  Anche se i compilatori più moderni
-%%   sono in grado di effettuare da soli queste manipolazioni (impostando le
-%%   opportune ottimizzazioni) questa è una tecnica usata per migliorare le
-%%   prestazioni per le funzioni piccole ed usate di frequente, in tal caso
-%%   infatti le istruzioni per creare un nuovo frame nello stack per chiamare la
-%%   funzione costituirebbero una parte rilevante del codice, appesantendo
-%%   inutilmente il programma. Originariamente questa era fatto utilizzando delle
-%%   macro, ma queste hanno tutta una serie di problemi di sintassi nel passaggio
-%%   degli argomenti (si veda ad esempio \cite{PratC} che in questo modo possono
-%%   essere evitati.}
-
+caso di terminazione imprevista del processo.

 
 Chiamare \func{MutexLock} decrementa il valore del semaforo: se questo è
 libero (ha già valore 1) sarà bloccato (valore nullo), se è bloccato la
 
 Chiamare \func{MutexLock} decrementa il valore del semaforo: se questo è
 libero (ha già valore 1) sarà bloccato (valore nullo), se è bloccato la


@@ -2934,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


@@ -2968,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


@@ -2979,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.

 
 
 
 
 
 


@@ -3235,13 +3256,15 @@ superiorit
 \subsection{Code di messaggi}
 \label{sec:ipc_posix_mq}
 
 \subsection{Code di messaggi}
 \label{sec:ipc_posix_mq}
 

-Le code di messaggi non sono supportate a livello del kernel, esse però
-possono essere implementate, usando la memoria condivisa ed i mutex, con
-funzioni di libreria. In generale esse sono comunque poco usate, i
-socket\index{socket}, nei casi in cui sono sufficienti, sono più comodi, e
-negli altri casi la comunicazione può essere gestita direttamente con la
-stessa metodologia usata per implementare le code di messaggi. Per questo ci
-limiteremo ad una descrizione essenziale.
+Le code di messaggi non sono ancora supportate nel kernel
+ufficiale;\footnote{esiste però una proposta di implementazione di Krzysztof
+  Benedyczak, a partire dal kernel 2.5.50.}  inoltre esse possono essere
+implementate, usando la memoria condivisa ed i mutex, con funzioni di
+libreria. In generale, come le corrispettive del SysV IPC, sono poco usate,
+dato che i socket\index{socket}, nei casi in cui sono sufficienti, sono più
+comodi, e negli altri casi la comunicazione può essere gestita direttamente
+con mutex e memoria condivisa. Per questo ci limiteremo ad una descrizione
+essenziale.

 
 
 
 
 
 


@@ -3250,7 +3273,9 @@ limiteremo ad una descrizione essenziale.
 
 Dei semafori POSIX esistono sostanzialmente due implementazioni; una è fatta a
 livello di libreria ed è fornita dalla libreria dei thread; questa però li
 
 Dei semafori POSIX esistono sostanzialmente due implementazioni; una è fatta a
 livello di libreria ed è fornita dalla libreria dei thread; questa però li

-implementa solo a livello di thread e non di processi. Esiste una 
+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. 

 
 
 \subsection{Memoria condivisa}
 
 
 \subsection{Memoria condivisa}