X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=b0eb27ee76a651086eae29ee98b0fc9cc9efe8dc;hp=488e330b50620ec3b0e1386f0960cf118610a09b;hb=7b52687f914b7a496df8fe2e7ac834b5cad2e59e;hpb=3b25af0c70f61bf5bb4327f32c0abcc51e7f7332 diff --git a/ipc.tex b/ipc.tex index 488e330..b0eb27e 100644 --- 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}