X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=d8ffa5f83268604dfaa2149b95c72f096f44a664;hp=f3fb316f85dafe8f6f2091a9401989ace8d34f89;hb=fe017ba5da165123761dbb85036ad3ed8bbd7ad2;hpb=789a38451310ab1b56885887e36f97124e8f86e6 diff --git a/ipc.tex b/ipc.tex index f3fb316..d8ffa5f 100644 --- 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. -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} @@ -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 -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} @@ -2711,19 +2712,16 @@ il suo prototipo \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} -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 @@ -2734,26 +2732,49 @@ condivisa; uno schema semplificato della struttura \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} + + \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} -Abbiamo esaminato il \textit{file locking} in \secref{sec:file_locking}, +Abbiamo esaminato il \textit{file locking} in \secref{sec:file_locking},