Aggiunti alcuni header alla lista e quattro chiacchiere sulle alternative

[gapil.git] / ipc.tex

diff --git a/ipc.tex b/ipc.tex
index f3fb316f85dafe8f6f2091a9401989ace8d34f89..d8ffa5f83268604dfaa2149b95c72f096f44a664 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -2609,10 +2609,10 @@ attraverso l'argomento \param{cmd}, i valori possibili sono i seguenti:
 i primi tre comandi sono gli stessi già visti anche per le code ed i semafori,
 gli ultimi due sono delle estensioni previste da Linux. 
 
 i primi tre comandi sono gli stessi già visti anche per le code ed i semafori,
 gli ultimi due sono delle estensioni previste da Linux. 
 

-Per utilizzare i segmenti di memoria condivisa si usano due funzioni, la prima
-di queste è \func{shmat}, che serve ad agganciare un segmento al processo
-chiamante, in modo che quest'ultimo possa vederlo nel suo spazio di indirizzi;
-il suo prototipo è:
+Per utilizzare i segmenti di memoria condivisa l'interfaccia prevede due
+funzioni, la prima è \func{shmat}, che serve ad agganciare un segmento al
+processo chiamante, in modo che quest'ultimo possa vederlo nel suo spazio di
+indirizzi; il suo prototipo è:

 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/shm.h}
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/shm.h}


@@ -2696,14 +2696,15 @@ Come accennato in \secref{sec:proc_fork} un segmento di memoria condivisa
 agganciato ad un precesso viene ereditato da un figlio attraverso una
 \func{fork}, dato che quest'ultimo riceve una copia dello spazio degli
 indirizzi del padre. Invece, dato che attraverso una \func{exec} viene
 agganciato ad un precesso viene ereditato da un figlio attraverso una
 \func{fork}, dato che quest'ultimo riceve una copia dello spazio degli
 indirizzi del padre. Invece, dato che attraverso una \func{exec} viene

-eseguito un diverso programma, tutti i segmenti eventualmente agganciati al
-processo vengono automaticamente sganciati. Lo stesso avviene all'uscita del
-processo attraverso una \func{exit}.
+eseguito un diverso programma con uno spazio di indirizzi completamente
+diverso, tutti i segmenti agganciati al processo originario vengono
+automaticamente sganciati. Lo stesso avviene all'uscita del processo
+attraverso una \func{exit}.

 
 
 
 

-La seconda funzione è \func{shmdt}, che consente di sganciare un segmento di
-memoria condivisa dal processo chiamante quando questo non è più necessario,
-il suo prototipo è:
+Una volta che un segmento di memoria condivisa non serve più si può sganciarlo
+esplicitamente dal processo usando la seconda funzione dell'interfaccia,
+\func{shmdt}, il cui  il suo prototipo è:

 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/shm.h}
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/shm.h}


@@ -2711,19 +2712,16 @@ il suo prototipo 
   \funcdecl{int shmdt(const void *shmaddr)}
   Sgancia dal processo un segmento di memoria condivisa.
   
   \funcdecl{int shmdt(const void *shmaddr)}
   Sgancia dal processo un segmento di memoria condivisa.
   

-  \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
+  \bodydesc{La funzione restituisce 0 in caso di succes so, e -1 in caso di

     errore, la funzione fallisce solo quando non c'è un segmento agganciato
     all'indirizzo \func{shmaddr}, con \var{errno} che assume il valore
     \macro{EINVAL}.}
 \end{functions}
 
     errore, la funzione fallisce solo quando non c'è un segmento agganciato
     all'indirizzo \func{shmaddr}, con \var{errno} che assume il valore
     \macro{EINVAL}.}
 \end{functions}
 

-La funzione esegue lo sganciamento del segmento di memoria condivisa
-agganciato all'indirizzo \param{shmaddr}; quest'ultimo deve essere uguale
-all'indirizzo ottenuto da una precedente chiamata a \func{shmat}. 
-
-
-
-
+La funzione sgancia dallo spazio degli indirizzi del processo un segmento di
+memoria condivisa; questo viene identificato con l'indirizzo \param{shmaddr}
+restituito dalla precedente chiamata a \func{shmat} con il quale era stato
+agganciato al processo.

 
 
 Per capire meglio il funzionamento delle funzioni facciamo ancora una volta
 
 
 Per capire meglio il funzionamento delle funzioni facciamo ancora una volta


@@ -2734,26 +2732,49 @@ condivisa; uno schema semplificato della struttura 
 \begin{figure}[htb]
   \centering
   \includegraphics[width=10cm]{img/shmstruct}
 \begin{figure}[htb]
   \centering
   \includegraphics[width=10cm]{img/shmstruct}

-  \caption{Schema dell'implementazione dei segmenti di memoria condivisa in
+   \caption{Schema dell'implementazione dei segmenti di memoria condivisa in

     Linux.}
   \label{fig:ipc_shm_struct}
 \end{figure}
 
 
     Linux.}
   \label{fig:ipc_shm_struct}
 \end{figure}
 
 

+
+

 \section{Tecniche alternative}
 \label{sec:ipc_alternatives}
 
 Come abbiamo visto in \secref{sec:ipc_sysv_generic} il sistema di IPC di
 \section{Tecniche alternative}
 \label{sec:ipc_alternatives}
 
 Come abbiamo visto in \secref{sec:ipc_sysv_generic} il sistema di IPC di

-System V presenta numerosi problemi; in \cite{APUE}\footnote{nel capitolo 14.}
-Stevens effettua una accurata analisi (i cui concetti sono già stati accennati
-in precedenza) ed elenca alcune possibili alternative, che vogliamo riprendere
-in questa sezione.
+System V presenta numerosi problemi; in \cite{APUE}\footnote{in particolare
+  nel capitolo 14.}  Stevens effettua una accurata analisi (alcuni dei
+concetti sono già stati accennati in precedenza) ed elenca alcune possibili
+alternative, che vogliamo riprendere in questa sezione.
+
+
+\subsection{Alternative alle code di messaggi}
+\label{sec:ipc_mq_alternative}
+
+Le code di messaggi sono probabilmente il meno usato degli oggetti di IPC di
+System V; esse infatti nacquero principalmente come meccanismo di
+comunicazione bidirezionale quando ancora le pipe erano ancora unidirezionali;
+abbiamo visto però in \secref{sec:ipc_socketpair} che la funzione
+\func{socketpair} permette di fare la stessa cosa senza incorrere nelle
+complicazioni introdotte dal sistema di IPC di System V. 
+
+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 cose che sono
+impossibili da ottenere con le pipe e i socket di \func{socketpair}.
+
+È però possibile implementare un meccanismo analogo attraverso l'uso di
+memoria condivisa e di meccanismi di sincronizzazione, (un esempio di
+reimplementazione di code di messaggi usando il \textit{memory mapping} e i
+semafori si trova in \cite{UNP2}). pertanto non è

 
 
 \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}
 

-Abbiamo esaminato il \textit{file locking} in \secref{sec:file_locking}, 
+Abbiamo esaminato il \textit{file locking} in \secref{sec:file_locking},