\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}
\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}
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
\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}
\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}
projects / gapil.git / commitdiff