\param{pathname} (che vengono ottenuti attraverso \func{stat}, da cui derivano
i possibili errori), e gli 8 bit meno significativi del numero del dispositivo
su cui è il file. Diventa perciò relativamente facile ottenere delle
-collisioni, specie se i file sono su dispositivi con lo stesso
-\itindex{minor~number} \textit{minor number}, come \file{/dev/hda1} e
-\file{/dev/sda1}.
+collisioni, specie se i file sono su dispositivi con lo stesso \textit{minor
+ number}, come \file{/dev/hda1} e \file{/dev/sda1}.
In genere quello che si fa è utilizzare un file comune usato dai programmi che
devono comunicare (ad esempio un header comune, o uno dei programmi che devono
\sysctlrelfile{kernel}{msgmnb} e \sysctlrelfile{kernel}{msgmni} di
\file{/proc/sys/kernel/}.
-Una coda di messaggi è costituita da una \itindex{linked~list} \textit{linked
- list}.\footnote{una \itindex{linked~list} \textit{linked list} è una tipica
- struttura di dati, organizzati in una lista in cui ciascun elemento contiene
- un puntatore al successivo. In questo modo la struttura è veloce
- nell'estrazione ed immissione dei dati dalle estremità dalla lista (basta
- aggiungere un elemento in testa o in coda ed aggiornare un puntatore), e
- relativamente veloce da attraversare in ordine sequenziale (seguendo i
- puntatori), è invece relativamente lenta nell'accesso casuale e nella
- ricerca.} I nuovi messaggi vengono inseriti in coda alla lista e vengono
-letti dalla cima, in fig.~\ref{fig:ipc_mq_schema} si è riportato uno schema
-semplificato con cui queste strutture vengono mantenute dal kernel. Lo schema
-illustrato in realtà è una semplificazione di quello usato fino ai kernel
-della serie 2.2. A partire della serie 2.4 la gestione delle code di messaggi
-è effettuata in maniera diversa (e non esiste una struttura \struct{msqid\_ds}
-nel kernel), ma abbiamo mantenuto lo schema precedente dato che illustra in
-maniera più che adeguata i principi di funzionamento delle code di messaggi.
+\itindbeg{linked~list}
+
+Una coda di messaggi è costituita da una \textit{linked list}.\footnote{una
+ \itindex{linked~list} \textit{linked list} è una tipica struttura di dati,
+ organizzati in una lista in cui ciascun elemento contiene un puntatore al
+ successivo. In questo modo la struttura è veloce nell'estrazione ed
+ immissione dei dati dalle estremità dalla lista (basta aggiungere un
+ elemento in testa o in coda ed aggiornare un puntatore), e relativamente
+ veloce da attraversare in ordine sequenziale (seguendo i puntatori), è
+ invece relativamente lenta nell'accesso casuale e nella ricerca.} I nuovi
+messaggi vengono inseriti in coda alla lista e vengono letti dalla cima, in
+fig.~\ref{fig:ipc_mq_schema} si è riportato uno schema semplificato con cui
+queste strutture vengono mantenute dal kernel. Lo schema illustrato in realtà
+è una semplificazione di quello usato fino ai kernel della serie 2.2. A
+partire della serie 2.4 la gestione delle code di messaggi è effettuata in
+maniera diversa (e non esiste una struttura \struct{msqid\_ds} nel kernel), ma
+abbiamo mantenuto lo schema precedente dato che illustra in maniera più che
+adeguata i principi di funzionamento delle code di messaggi.
+
+\itindend{linked~list}
\begin{figure}[!htb]
\centering \includegraphics[width=13cm]{img/mqstruct}
\subsection{I \textsl{file di lock}}
\label{sec:ipc_file_lock}
-\index{file!di lock|(}
+\index{file!di~lock|(}
Come illustrato in sez.~\ref{sec:ipc_sysv_sem} i semafori del \textit{SysV-IPC}
presentano una interfaccia inutilmente complessa e con alcuni difetti
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.
-\index{file!di lock|)}
+\index{file!di~lock|)}
\subsection{La sincronizzazione con il \textit{file locking}}
\label{sec:ipc_lock_file}
-Dato che i \index{file!di lock} file di lock presentano gli inconvenienti
-illustrati in precedenza, la tecnica alternativa di sincronizzazione più
-comune è quella di fare ricorso al \itindex{file~locking} \textit{file
- locking} (trattato in sez.~\ref{sec:file_locking}) usando \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 stato di
-attesa, senza necessità di ricorrere al \itindex{polling} \textit{polling} per
-determinare la disponibilità della risorsa, e al rilascio della stessa da
-parte del processo che la occupava si otterrà il nuovo lock atomicamente.
+Dato che i file di lock presentano gli inconvenienti illustrati in precedenza,
+la tecnica alternativa di sincronizzazione più comune è quella di fare ricorso
+al \itindex{file~locking} \textit{file locking} (trattato in
+sez.~\ref{sec:file_locking}) usando \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 stato di attesa, senza necessità di
+ricorrere al \itindex{polling} \textit{polling} per determinare la
+disponibilità 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
projects / gapil.git / blobdiff