Aggiunta figura sulla struttura dello spazio indirizzi nel caso di memoria
authorSimone Piccardi <piccardi@gnulinux.it>
Fri, 1 Nov 2002 16:35:40 +0000 (16:35 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Fri, 1 Nov 2002 16:35:40 +0000 (16:35 +0000)
condivisa e completata shmctl.

img/sh_memory_layout.dia [new file with mode: 0644]
ipc.tex

diff --git a/img/sh_memory_layout.dia b/img/sh_memory_layout.dia
new file mode 100644 (file)
index 0000000..5d64ed2
Binary files /dev/null and b/img/sh_memory_layout.dia differ
diff --git a/ipc.tex b/ipc.tex
index 488e330..b0eb27e 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -2426,7 +2426,7 @@ ripristino non 
 \label{sec:ipc_sysv_shm}
 
 Il terzo oggetto introdotto dal \textit{System V IPC} è quello dei segmenti di
-memoria condivisa. La funzione che permette di ottenerne uno è \func{shmget}
+memoria condivisa. La funzione che permette di ottenerne uno è \func{shmget},
 ed il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
@@ -2460,6 +2460,24 @@ ripeteremo quanto detto al proposito in \secref{sec:ipc_sysv_mq}. L'argomento
 \param{size} specifica invece la dimensione, in byte, del segmento, che viene
 comunque arrotondata al multiplo superiore di \macro{PAGE\_SIZE}.
 
+La memoria condivisa è la forma più veloce di comunicazione fra due processi,
+in quanto permette agli stessi di vedere nel loro spazio di indirizzi una
+stessa sezione di memoria.  Pertanto non è necessaria nessuna operazione di
+copia per trasmettere i dati da un processo all'altro, in quanto ciascuno può
+accedervi direttamente con le normali operazioni di lettura e scrittura dei
+dati in memoria.
+
+Ovviamente tutto questo ha un prezzo, ed il problema fondamentale della
+memoria condivisa è la sincronizzazione degli accessi. È evidente infatti che
+se un processo deve scambiare dei dati con un altro, si deve essere sicuri che
+quest'ultimo non acceda al segmento di memoria condivisa prima che il primo
+non abbia completato le operazioni di scrittura, inoltre nel corso di una
+lettura si deve essere sicuri che i dati restano coerenti e non vengono
+sovrascritti da un accesso in scrittura sullo stesso segmento da parte di un
+altro processo; per questo in genere la memoria condivisa viene sempre
+utilizzata in abbinamento ad un meccanismo di sincronizzazione, il che, di
+norma, significa insime a dei semafori.
+
 \begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{15cm}
@@ -2506,6 +2524,12 @@ invece:
   al segmento viene inizializzato a zero.
 \end{itemize*}
 
+La struttura di come vengono gestiti i segmenti di memoria condivisa nel
+kernel è illustrata in . 
+
+
+
+
 Come per le code di messaggi e gli insiemi di semafori, anche per i segmenti
 di memoria condivisa esistono una serie di limiti, i cui valori, riportati in
 \tabref{tab:ipc_shm_limits} sono associati ad altrettante costanti.  Alcuni di
@@ -2618,19 +2642,46 @@ il suo prototipo 
 \end{functions}
 
 La funzione inserisce un segmento di memoria condivisa all'interno dello
-spazio di indirizzi del processo, come mostrato in così che questo possa
-accedervi, L'argomento \param{shmaddr} specifica a quale indirizzo\footnote{Lo
-  standard SVID prevede che l'argomento \param{shmaddr} sia di tipo \ctyp{char
-    *}, così come il valore di ritorno della funzione. In Linux è stato così
-  con le \acr{libc4} e le \acr{libc5}, con il passaggio alle \acr{glibc} il
-  tipo di \param{shmaddr} è divenuto un \ctyp{const void *} e quello del
-  valore di ritorno un \ctyp{void *}.} deve essere associato il segmento, che
-verrà restituito dalla funzione.
+spazio di indirizzi del processo, in modo che questo possa accedervi
+direttamente, la situazione dopo l'esecuzione di \func{shmat} è illustrata in
+\figref{fig:ipc_shmem_layout} (per la comprensione del resto dello schema si
+ricordi al proposito quanto illustrato in \secref{sec:proc_mem_layout}).
+
+
+\begin{figure}[htb]
+  \centering
+  \includegraphics[height=10cm]{img/sh_memory_layout}
+  \caption{Disposizione dei segmenti di memoria di un processo quando si è
+    agganciato un segmento di memoria condivisa.}
+  \label{fig:ipc_shmem_layout}
+\end{figure}
+
+
+L'argomento \param{shmaddr} specifica a quale indirizzo\footnote{Lo standard
+  SVID prevede che l'argomento \param{shmaddr} sia di tipo \ctyp{char *}, così
+  come il valore di ritorno della funzione. In Linux è stato così con le
+  \acr{libc4} e le \acr{libc5}, con il passaggio alle \acr{glibc} il tipo di
+  \param{shmaddr} è divenuto un \ctyp{const void *} e quello del valore di
+  ritorno un \ctyp{void *}.} deve essere associato il segmento, se il valore
+specificato è \macro{NULL} è il sistema a scegliere opportunamente un'area di
+memoria libera (questo è il modo più portabile e sicuro di usare la funzione).
+Altrimenti il kernel aggangia il segmento all'indirizzo specificato da
+\param{shmaddr}; questo però può avvenire solo se l'indirizzo coincide con il
+limite di una pagina, cioè se è un multiplo esatto del parametro di sistema
+\macro{SHMLBA}, che in Linux è sempre uguale \macro{PAGE\_SIZE}.
+
+
+
+
+L'argomento \param{shmflg} permette di cambiare il comportamento della
+funzione; esso va specificato come maschera binaria, i bit utilizzati sono
+
+
 
 
 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 è:
+memoria condivisa dal processo chiamante quando questo non è più necessario,
+il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/shm.h}
@@ -2645,10 +2696,27 @@ necessario, il suo prototipo 
 \end{functions}
 
 
+\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.
+
+
+\subsection{La sincronizzazione con il \textit{file locking}}
+\label{sec:ipc_file_lock}
+
+Abbiamo esaminato il \textit{file locking} in \secref{sec:file_locking}, 
 
 
 
+\subsection{Il \textit{memory mapping} anonimo}
+\label{sec:ipc_mmap_anonymous}
 
+Abbiamo visto in \secref{sec:file_memory_map} come sia possibile 
 
 
 \section{La comunicazione fra processi di POSIX}