In questa sezione esamineremo come Linux supporta quello che viene chiamato il
\textsl{Sistema di comunicazione inter-processo} di System V, cui da qui in
avanti faremo riferimento come \textit{SysV IPC} (dove IPC è la sigla di
-\textit{Inter-Process Comunication})}.
+\textit{Inter-Process Comunication}).
ignorare silenziosamente le altre; questo però comporta il fatto che il
ripristino non è comunque garantito in tutte le occasioni.
+Come esempio di uso dell'interfaccia dei semafori vediamo come implementare
+con essa dei semplici \textit{mutex} (cioè semafori binari), tutte le funzioni
+relative sono definite come \ctyp{inline}\footnote{la direttiva \func{inline}
+ viene usata per dire al compilatore di non trattare la funzione cui essa fa
+ riferimento come una funzione, ma di inserire il codice direttamente nel
+ testo del programma. Anche se i compilatori più moderni sono in grado di
+ effettuare da soli queste manipolazioni (impostando le opportune
+ ottimizzazioni) questa è una tecnica usata per migliorare le prestazioni per
+ le funzioni piccole ed usate di frequente, in tal caso infatti le istruzioni
+ per creare un nuovo frame nello stack per chiamare la funzione
+ costituirebbero una parte rilevante del codice, appesantendo inutilmente il
+ programma. Originariamente questa era fatto utilizzando delle macro, ma
+ queste hanno tutta una serie di problemi di sintassi nel passaggio degli
+ argomenti (si veda ad esempio \cite[oullaine]) che in questo modo possono
+ essere evitati.} nel file \file{wrappers.h}. In
+\secref{fig:ipc_mutex_create} si è riportata la definizione delle due funzioni
+che permettono di acquisire il \textit{mutex}; la prima è \func{MutexCreate}
+che crea il semaforo usato per il mutex e lo inizializza, restituendone
+l'identificatore; la seconda è \func{MutexFind}, che data una chiave
+restitituisce l'identificatore del semaforo ad essa associato.
+
+\begin{figure}[!bht]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}{}
+/*
+ * Function MutexCreate:
+ *
+ * Input: an IPC key value (to create an unique semaphore)
+ * Return: the semaphore id#
+ */
+const union semun semunion={1}; /* semaphore union structure */
+inline int MutexCreate(key_t ipc_key)
+{
+ int sem_id;
+ if( (sem_id=semget(ipc_key,1,IPC_CREAT|0666))<0 ){ /* get sem ID */
+ perror("cannot create semaphore"); /* a sem_id <0 is an error */
+ printf("semid=%d",sem_id);
+ exit(1);
+ }
+ if ( (semctl(sem_id,0,SETVAL,semunion)) < 0 ) {
+ perror("cannot init semaphore"); /* <0 is an error */
+ printf("on semid=%d",sem_id);
+ exit(1);
+ }
+ return sem_id;
+}
+/*
+ * Find Mutex
+ * get the semaphore/mutex Id given the IPC key value
+ *
+ * Input: an IPC key value
+ */
+inline int MutexFind(key_t ipc_key)
+{
+ int sem_id;
+ if( (sem_id=semget(ipc_key,1,0))<0 ){ /* find sem .ID */
+ perror("cannot find semaphore");
+ exit(1);
+ }
+ return sem_id;
+}
+ \end{lstlisting}
+ \end{minipage}
+ \normalsize
+ \caption{Il codice delle funzioni che permettono di creare o recuperare
+ l'identificatore di un semaforo da utilizzare come \textit{mutex}.}
+ \label{fig:ipc_mutex_create}
+\end{figure}
+
+
+La prima funzione definita (\texttt{\small 8--22}) è \func{MutexCreate},
+anzitutto (\texttt{\small 11--15}) si chiama \func{semget} con
+\macro{IPC\_CREATE} per creare il semaforo qualora non esista, assegnandogli i
+privilegi di lettura e scrittura per l'utente. In caso di errore si
+scrive un errore e si esce.
+
+
+
+
+
+
+
+
\subsection{Memoria condivisa}
\label{sec:ipc_sysv_shm}
attraverso una \func{exit}.
-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 è:
+Una volta che un segmento di memoria condivisa non serve più, si può
+sganciarlo esplicitamente dal processo usando l'altra funzione
+dell'interfaccia, \func{shmdt}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/shm.h}
\funcdecl{int shmdt(const void *shmaddr)}
Sgancia dal processo un segmento di memoria condivisa.
- \bodydesc{La funzione restituisce 0 in caso di succes so, e -1 in caso di
+ \bodydesc{La funzione restituisce 0 in caso di successo, 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}.}
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
riferimento alle strutture con cui il kernel implementa i segmenti di memoria
condivisa; uno schema semplificato della struttura è illustrato in
\macro{O\_EXCL}. In tal modo la creazione di un file di lock può essere
eseguita atomicamente, il processo che crea il file con successo si può
considerare come titolare del lock (e della risorsa ad esso associata) mentre
-il rilascio si può eseguire con una chiamata ad \func{unlink}.
-
-Questa tecnica ha però parecchi problemi, che non la rendono una alternativa
-praticabile; anzitutto anche in questo caso in caso di terminazione imprevista
-del processo lascia allocata la risorsa (il file di lock) che deve comunque
-essere cancellata esplicitamente. Inoltre il controllo della disponibilità può
-essere fatto solo con una tecnica di polling, che è molto inefficiente.
-Modalità alternative prevedono l'uso di \func{link}, che fallisce se il nome
-esiste già, ma i problemi sono gli stessi.
-
-Per questo motivo la tecnica più pulita è quella di utilizzare \func{fcntl} su
-un file creato per l'occazione per ottenere un write lock sul primo byte del
-file (che non è detto debba esistere); in questo modo potremo usare il lock
-come un \textit{mutex}: per bloccare la risorsa basterà acquisire il lock, per
-sbloccarla basterà rilasciare il lock; l'accesso sarà controllabile, senza
-necessità di ricorrere al \textit{polling}\index{polling}.
-
-
+il rilascio si può eseguire con una chiamata ad
+\func{unlink}.\footnote{abbiamo già accennato in \secref{sec:file_open} che
+ questa tecnica può non funzionare se il filesystem su cui si va ad operare è
+ su NFS; in tal caso si può adottare una tecnica alternativa che prevede
+ l'uso di \func{link} per creare come file di lock un hard link ad un file
+ esistente; se il link esiste già e la funzione fallisce, la risorsa
+ significa che la risorsa è bloccata e potrà essere sbloccata solo con un
+ \func{unlink}, altrimenti il link è creato ed il lock acquisito; il
+ controllo e l'eventuale acquisizione sono atomici; il difetto di questa
+ soluzione è che funziona solo se si opera all'interno di uno stesso
+ filesystem.}
+
+L'uso di un file di lock presenta però parecchi problemi, che non lo rendono
+una alternativa praticabile per la sincronizzazione:\footnote{ma può essere
+ una tecnica usata con successo quando l'esigenza è solo quella di segnalare
+ l'occupazione di una risorsa, senza necessità di attendere che questa si
+ liberi; ad esempio la si usa spesso per evitare interferenze sull'uso delle
+ porte seriali da parte di più programmi: qualora trovi un file di lock il
+ programma che cerca di accedere alla seriale si limita a segnalare che la
+ risorsa non è disponibile.} anzitutto anche in questo caso in caso di
+terminazione imprevista del processo lascia allocata la risorsa (il file di
+lock) e questa deve essere sempre cancellata esplicitamente. Inoltre il
+controllo della disponibilità può essere fatto solo con una tecnica di
+polling\index{polling}, che è molto inefficiente.
+
+Per questo motivo la tecnica alternativa più pulita è quella di fare ricorso
+al \textit{file locking} visto in \secref{sec:file_locking} ed utilizzare
+\func{fcntl} su un file creato per l'occazione per ottenere un write lock; in
+questo modo potremo usare il lock come un \textit{mutex}: per bloccare la
+risorsa basterà acquisire il lock, per sbloccarla basterà rilasciare il lock;
+una richiesta fatta con un write lock metterà automaticamente il processo in
+stato di attesa, senza necessità di ricorrere al
+\textit{polling}\index{polling} per determimanare la dispobilità della
+risorsa, e al rilascio della stessa da parte del processo che la occupava si
+otterrà il nuovo lock atomicamente.
+
+Questo approccio presenta il notevole vantaggio che alla terminazione di un
+processo tutti i lock acquisiti vengono rilasciati automaticamente (alla
+chiusura dei relativi file) e non ci si deve preoccupare di niente, e non
+consuma risorse permanentemente allocate nel sistema, lo svantaggio è che
+dovendo fare ricorso a delle operazioni sul filesystem esso è in genere
+leggermente più lento.
-Una possibile alternativa all'uso dei semafori come meccanismo di
-sincronizzazione è quello di fare ricorso al \textit{file locking} visto in
-\secref{sec:file_locking}.
\subsection{Il \textit{memory mapping} anonimo}
\section{La comunicazione fra processi di POSIX}
\label{sec:ipc_posix}
-Lo standard POSIX.1b ha introdotto dei nuovi meccanismi di comunicazione,
-rifacendosi a quelli di System V, introducendo una nuova interfaccia che
-evitasse i principali problemi evidenziati in coda a
-\secref{sec:ipc_sysv_generic}.
+Per superare i numerosi problemi del \textit{SysV IPC}, evidenziati per i suoi
+aspetti generali in coda a \secref{sec:ipc_sysv_generic} e per i singoli
+oggetti nei paragrafi successivi, lo standard POSIX.1b ha introdotto dei nuovi
+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}.
\subsection{Code di messaggi}
\label{sec:ipc_posix_mq}
+Le code di messaggi non sono supportate a livello del kernel, esse però
+possono essere implementate, usando la memoria condivisa ed i mutex, con
+funzioni di libreria. In generale esse sono comunque poco usate, i socket, nei
+casi in cui sono sufficienti, sono più comodi, e negli altri casi la
+comunicazione può essere gestita direttamente con la stessa metodologia usata
+per implementare le code di messaggi. Per questo ci limiteremo ad una
+descrizione essenziale.
+
+
\subsection{Semafori}
\label{sec:ipc_posix_sem}
+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 una
+
\subsection{Memoria condivisa}
\label{sec:ipc_posix_shm}
+La memoria condivisa è l'unico degli oggetti di IPC POSIX già presente nel
+kernel ufficiale.
+
+
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
projects / gapil.git / blobdiff