X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=c2d3c213cfbacf57bc8213e734f5039fb100ff16;hp=8428b47c73fccd51d2caf22778b38bb74d463d9a;hb=08e339a5f489c9401e931a214b37de26be6669a6;hpb=d6636dc7afc27b7ac5b9feb214031ae1e7fd2594 diff --git a/ipc.tex b/ipc.tex index 8428b47..c2d3c21 100644 --- a/ipc.tex +++ b/ipc.tex @@ -3779,29 +3779,59 @@ meccanismi di comunicazione, che vanno sotto il nome di POSIX IPC, definendo una interfaccia completamente nuova, che tratteremo in questa sezione. - \subsection{Considerazioni generali} \label{sec:ipc_posix_generic} -Il Linux non tutti gli oggetti del POSIX IPC sono supportati nel kernel -ufficiale; solo la memoria condivisa è presente, ma solo a partire dal kernel -2.4.x, per gli altri oggetti esistono patch e librerie non ufficiali. -Nonostante questo è importante esaminare questa interfaccia per la sua netta -superiorità nei confronti di quella del \textit{SysV IPC}. +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, 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 +\textit{Posix IPC names}\index{Posix IPC names}, che sono sostanzialmente +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; tutto quello che è +richiesto è che: +\begin{itemize} +\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{/} 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} \label{sec:ipc_posix_mq} -Le code di messaggi non sono ancora supportate nel kernel -ufficiale;\footnote{esiste però una proposta di implementazione di Krzysztof - Benedyczak, a partire dal kernel 2.5.50.} inoltre esse possono essere -implementate, usando la memoria condivisa ed i mutex, con funzioni di -libreria. 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. Per questo ci limiteremo ad una descrizione -essenziale. +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 +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. + @@ -3810,16 +3840,50 @@ essenziale. Dei semafori POSIX esistono sostanzialmente due implementazioni; una è fatta a livello di libreria ed è fornita dalla libreria dei thread; questa però li -implementa solo a livello di thread e non di processi. Esiste un'altra -versione, realizzata da Konstantin Knizhnik, che reimplementa l'interfaccia -POSIX usando i semafori di SysV IPC. +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 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. + + \subsection{Memoria condivisa} \label{sec:ipc_posix_shm} La memoria condivisa è l'unico degli oggetti di IPC POSIX già presente nel -kernel ufficiale. +kernel ufficiale. Per poterla utilizzare occorre abilitare il filesystem +\texttt{tmpfs}, uno speciale filesystem che mantiene tutti i suoi contenuti in +memoria,\footnote{il filesystem \texttt{tmpfs} è diverso da un normale RAM + disk, anch'esso disponibile attraverso il filesystem \texttt{ramfs}, proprio + perché realizza una interfaccia utilizzabile anche per la memoria condivisa; + esso infatti non ha dimensione fissa, ed usa direttamente la cache interna + del kernel (viene usato anche per la SysV shared memory). In più i suoi + contenuti, essendo trattati direttamente dalla memoria + virtuale\index{memoria virtuale} e possono essere salvati sullo swap + automaticamente.} abilitando l'opzione \texttt{CONFIG\_TMPFS} in fase di +compilazione del kernel, e montando il filesystem aggiungendo una riga tipo: +\begin{verbatim} +tmpfs /dev/shm tmpfs defaults 0 0 +\end{verbatim} +ad \file{/etc/fstab}, oppure dove si preferisce con un comando del +tipo:\footnote{il filesystem riconosce, oltre quelle mostrate, le opzioni + \texttt{uid} e \texttt{gid} che identificano rispettivamente utente e gruppo + cui assegnarne la titolarità, e \texttt{nr\_blocks} che permette di + specificarne la dimensione in blocchi, cioè in multipli di + \const{PAGECACHE\_SIZE}.} +\begin{verbatim} +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: