Programma per scrivere su una shared memory.

[gapil.git] / ipc.tex

diff --git a/ipc.tex b/ipc.tex
index 920787398b707674e396f1f056911993c7f8faf4..c2d3c213cfbacf57bc8213e734f5039fb100ff16 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -3785,13 +3785,9 @@ una interfaccia completamente nuova, che tratteremo in questa sezione.
 In Linux non tutti gli oggetti del POSIX IPC sono pienamente supportati nel
 kernel ufficiale; solo la memoria condivisa è presente con l'interfaccia
 completa, ma solo a partire dal kernel 2.4.x, i semafori sono forniti dalle
-\acr{glibc} nella sezione che implementa i thread POSIX, e sono utilizzabili
-solo all'interno dei thread generati dallo stesso processo,\footnote{sono cioè
-  oggetti che non possono, al contrario dei semafori del SysV IPC, essere
-  utilizzati per sincronizzare processi diversi.} le code di messaggi non
-hanno alcun tipo di supporto ufficiale.  Esistono tuttavia dei patch e delle
-librerie aggiuntive che supportano alcune di queste interfacce, anche se
-sperimentali e di uso limitato.
+\acr{glibc} nella sezione che implementa i thread POSIX, le code di messaggi
+non hanno alcun tipo di supporto ufficiale.  Per queste ultime esistono
+tuttavia dei patch e una libreria aggiuntiva.
 
 La caratteristica fondamentale dell'interfaccia POSIX è l'abbandono dell'uso
 degli identificatori e delle chiavi visti nel SysV IPC, per passare ai
@@ -3799,19 +3795,29 @@ degli identificatori e delle chiavi visti nel SysV IPC, per passare ai
 equivalenti ai nomi dei file. Tutte le funzioni che creano un oggetto di IPC
 Posix prendono come primo argomento una stringa che indica uno di questi nomi;
 lo standard è molto generico riguardo l'implementazione, ed i nomi stessi
-possono avere o meno una corrispondenza sul filesystem. 
-
-
- le caratteristiche di questi nomi,
-per i quali richiede che:
+possono avere o meno una corrispondenza sul filesystem; tutto quello che è
+richiesto è che:
 \begin{itemize}
-\item debbano essere conformi alle regole che caratterizzano i
+\item i nomi devono essere conformi alle regole che caratterizzano i
   \textit{pathname}, in particolare non essere più lunghi di \const{PATH\_MAX}
   byte e terminati da un carattere nullo.
-\item se il nome inizia per una \texttt{/} 
+\item se il nome inizia per una \texttt{/} chiamate differenti allo stesso
+  nome fanno riferimento allo stesso oggetto, altrimenti l'interpretazione del
+  nome dipende dall'implementazione.
+\item l'interpretazione di ulteriori \texttt{/} presenti nel nome dipende
+  dall'implementazione.
 \end{itemize}
 
-
+Il comportamento delle funzioni è pertanto subordinato in maniera quasi
+completa alla relativa implementazione.\footnote{tanto che Stevens in
+  \cite{UNP2} cita questo caso come un esempio della maniera standard per
+  consentire soluzioni non standard.} Nel caso di Linux per quanto riguarda la
+memoria condivisa, tutto viene creato nella directory \file{/dev/shm}, ed i
+nomi sono presi come pathname assoluto (comprendente eventuali sottodirectory)
+rispetto a questa radice (per maggiori dettagli si veda quanto illustrato in
+\secref{sec:ipc_posix_shm}). Lo stesso accade per l'implementazione
+sperimentale delle code di messaggi, che però fa riferimento alla directory
+\file{/dev/mqueue}.
 
 
 \subsection{Code di messaggi}
@@ -3821,7 +3827,7 @@ Le code di messaggi non sono ancora supportate nel kernel ufficiale, esiste
 però una implementazione sperimentale di Michal Wronski e Krzysztof
 Benedyczak,\footnote{i patch al kernel e la relativa libreria possono essere
   trovati \href{http://www.mat.uni.torun.pl/~wrona/posix_ipc}
-  {http://www.mat.uni.torun.pl/\~wrona/posix_ipc}.}.  In generale, come le
+  {http://www.mat.uni.torun.pl/\~{}wrona/posix\_ipc}.}.  In generale, come le
 corrispettive del SysV IPC, sono poco usate, dato che i socket\index{socket},
 nei casi in cui sono sufficienti, sono più comodi, e negli altri casi la
 comunicazione può essere gestita direttamente con mutex e memoria condivisa.
@@ -3829,7 +3835,6 @@ comunicazione pu
 
 
 
-
 \subsection{Semafori}
 \label{sec:ipc_posix_sem}
 
@@ -3837,10 +3842,12 @@ Dei semafori POSIX esistono sostanzialmente due implementazioni; una 
 livello di libreria ed è fornita dalla libreria dei thread; questa però li
 implementa solo a livello di thread e non di processi.\footnote{questo
   significa che i semafori sono visibili solo all'interno dei thread creati da
-  un sngolo processo.} Esiste un'altra versione, realizzata da Konstantin
-Knizhnik, che reimplementa l'interfaccia POSIX usando i semafori di SysV IPC,
-e che non vale comunque la pena di usare visto che i problemi sottolineati in
-\secref{sec:ipc_sysv_sem} restano invariati.
+  un singolo processo, e non possono essere usati come meccanismo di
+  sincronizzazione fra processi diversi.} Esiste però anche una libreria
+realizzata da Konstantin Knizhnik, che reimplementa l'interfaccia POSIX usando
+i semafori di SysV IPC, e che non vale comunque la pena di usare visto che i
+problemi sottolineati in \secref{sec:ipc_sysv_sem} rimangono, anche se
+mascherati.
 
 
 
@@ -3874,6 +3881,11 @@ mount -t tmpfs -o size=10G,nr_inodes=10k,mode=700 tmpfs /mytmpfs
 \end{verbatim}
 
 
+ la memoria
+condivisa è trattata come un filesystem separato, con tutte le caratteristiche
+di un qualunque filesystem,
+
+
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"