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
-dei \textsl{file di lock} (per i quali esiste anche una opportuna directory,
-\file{/var/lock}, nel filesystem standard). Per questo si usa la
-caratteristica della funzione \func{open} (illustrata in
+dei \textsl{file di lock}\index{file di lock} (per i quali esiste anche una
+opportuna directory, \file{/var/lock}, nel filesystem standard). Per questo si
+usa la caratteristica della funzione \func{open} (illustrata in
\secref{sec:file_open}) che prevede\footnote{questo è quanto dettato dallo
standard POSIX.1, ciò non toglie che in alcune implementazioni questa
tecnica possa non funzionare; in particolare per Linux, nel caso di NFS, si
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.}
+ esistente; se il link esiste già e la funzione fallisce, 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
+ 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 / blobdiff