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 caratteristiche che
-sono impossibili da ottenere con le pipe e i socket di \func{socketpair};
-a queste esigenze però si può comunque ovviare in maniera diversa con un uso
+messaggi ed un accesso non rigidamente sequenziale; due caratteristiche che
+sono impossibili da ottenere con le pipe e i socket di \func{socketpair}. A
+queste esigenze però si può comunque ovviare in maniera diversa con un uso
combinato della memoria condivisa e dei meccanismi di sincronizzazione, per
cui alla fine l'uso delle code di messaggi classiche è poco diffuso.
+
\subsection{La sincronizzazione con il \textit{file locking}}
\label{sec:ipc_file_lock}
presentano una interfaccia inutilmente complessa e con alcuni difetti
strutturali, per questo quando si ha una semplice esigenza di sincronizzazione
per la quale basterebbe un semaforo binario (quello che abbiamo definito come
-\textit{mutex}, che indica la disponibilità o meno di una risorsa, e non ha
-associato un contatore come i semafori) si possono utilizzare metodi
+\textit{mutex}), per indicare la disponibilità o meno di una risorsa, senza la
+necessità di un contatore come i semafori, si possono utilizzare metodi
alternativi.
La prima possibilità, utilizzata fin dalle origini di Unix, è quella di usare
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
+ porte seriali da parte di più programmi: qualora si 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.
+\textit{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'occasione per ottenere un write lock; in
+al \textit{file locking} trattato in \secref{sec:file_locking} ed utilizzare
+\func{fcntl} su un file creato per l'occasione 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
dovendo fare ricorso a delle operazioni sul filesystem esso è in genere
leggermente più lento.
+Il codice per implementare un mutex utilizzando il file locking è riportato in
+
+
+
\subsection{Il \textit{memory mapping} anonimo}
\label{sec:ipc_mmap_anonymous}
-Abbiamo visto in \secref{sec:file_memory_map} come sia possibile
+Abbiamo visto in \secref{sec:file_memory_map} come sia possibile mappare il
+contenuto di un file nella memoria di un processo. Una della opzioni possibili
+utilizzabili con Linux è quella del \textit{memory mapping}
+anonimo\footnote{in altri sistemi una funzionalità simile a questa viene
+ implementata mappando il file speciale \file{/dev/zero}.}, in tal caso
+infatti
\section{La comunicazione fra processi di POSIX}
projects / gapil.git / commitdiff