Utilizzando una \textit{fifo} tutti i dati passeranno, come per le
\textit{pipe}, attraverso un buffer nel kernel, senza transitare dal
-filesystem. Il fatto che siano associate ad un \itindex{inode}
-\textit{inode} presente sul filesystem serve infatti solo a fornire un punto
-di accesso per i processi, che permetta a questi ultimi di accedere alla
-stessa \textit{fifo} senza avere nessuna relazione, con una semplice
-\func{open}. Il comportamento delle funzioni di lettura e scrittura è identico
-a quello illustrato per le \textit{pipe} in sez.~\ref{sec:ipc_pipes}.
+filesystem. Il fatto che siano associate ad un \textit{inode} presente sul
+filesystem serve infatti solo a fornire un punto di accesso per i processi,
+che permetta a questi ultimi di accedere alla stessa \textit{fifo} senza avere
+nessuna relazione, con una semplice \func{open}. Il comportamento delle
+funzioni di lettura e scrittura è identico a quello illustrato per le
+\textit{pipe} in sez.~\ref{sec:ipc_pipes}.
Abbiamo già trattato in sez.~\ref{sec:file_mknod} le funzioni \func{mknod} e
\func{mkfifo} che permettono di creare una \textit{fifo}. Per utilizzarne una
lettura. Infine è possibile anche usare la \textit{fifo} all'interno di un
solo processo, nel qual caso però occorre stare molto attenti alla possibili
situazioni di stallo: se si cerca di leggere da una \textit{fifo} che non
-contiene dati si avrà infatti un \itindex{deadlock} \textit{deadlock}
-immediato, dato che il processo si blocca e quindi non potrà mai eseguire le
-funzioni di scrittura.
+contiene dati si avrà infatti un \textit{deadlock} immediato, dato che il
+processo si blocca e quindi non potrà mai eseguire le funzioni di scrittura.
Per la loro caratteristica di essere accessibili attraverso il filesystem, è
piuttosto frequente l'utilizzo di una \textit{fifo} come canale di
Verifichiamo allora il comportamento dei nostri programmi, in questo, come in
altri esempi precedenti, si fa uso delle varie funzioni di servizio, che sono
-state raccolte nella libreria \file{libgapil.so}, per poter usare quest'ultima
+state raccolte nella libreria \file{libgapil.so}, e per poterla usare
occorrerà definire la variabile di ambiente \envvar{LD\_LIBRARY\_PATH} in modo
che il linker dinamico possa accedervi.
possono essere specificati sono rispettivamente \const{AF\_UNIX},
\const{SOCK\_STREAM} e \val{0}.
-A partire dal kernel 2.6.27 la funzione supporta anche l'uso dei flag
-\const{SOCK\_NONBLOCK} e \const{SOCK\_CLOEXEC} (trattati in
-sez.~\ref{sec:sock_type}) nell'indicazione del tipo di socket, con effetto
-identico agli analoghi \const{O\_CLOEXEC} e \const{O\_NONBLOCK} di una
-\func{open} (vedi tab.~\ref{tab:open_operation_flag}).
+A partire dal kernel 2.6.27 la funzione supporta nell'indicazione del tipo di
+socket anche i due flag \const{SOCK\_NONBLOCK} e \const{SOCK\_CLOEXEC}
+(trattati in sez.~\ref{sec:sock_type}), con effetto identico agli analoghi
+\const{O\_CLOEXEC} e \const{O\_NONBLOCK} di una \func{open} (vedi
+tab.~\ref{tab:open_operation_flag}).
L'utilità di chiamare questa funzione per evitare due chiamate a \func{pipe}
può sembrare limitata; in realtà l'utilizzo di questa funzione (e dei socket
\end{minipage}
\normalsize
\caption{La struttura \structd{ipc\_perm}, come definita in
- \headfile{sys/ipc.h}.}
+ \headfiled{sys/ipc.h}.}
\label{fig:ipc_ipc_perm}
\end{figure}
Il problema è che anche così non c'è la sicurezza che il valore della chiave
sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
-con i 16 bit meno significativi \itindex{inode} dell'inode del file
-\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 \textit{minor
- number}, come \file{/dev/hda1} e \file{/dev/sda1}.
+con i 16 bit meno significativi dell'inode del file \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 \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
\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.
+ \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}
A ciascuna coda è associata una struttura \struct{msqid\_ds} la cui
definizione è riportata in fig.~\ref{fig:ipc_msqid_ds} ed a cui si accede
-includendo \headfile{sys/msg.h};
+includendo \headfiled{sys/msg.h};
%
% INFO: sotto materiale obsoleto e non interessante
% In questa struttura il
\textit{fifo} si aveva il problema delle \textit{fifo} che restavano nel
filesystem). In questo caso però il problemi sono maggiori, sia perché è molto
più facile esaurire la memoria dedicata ad una coda di messaggi che gli
-\itindex{inode} \textit{inode} di un filesystem, sia perché, con il riutilizzo
-dei \ids{PID} da parte dei processi, un client eseguito in un momento
-successivo potrebbe ricevere un messaggio non indirizzato a lui.
+\textit{inode} di un filesystem, sia perché, con il riutilizzo dei \ids{PID}
+da parte dei processi, un client eseguito in un momento successivo potrebbe
+ricevere un messaggio non indirizzato a lui.
\subsection{I semafori}
\includestruct{listati/semun.h}
\end{minipage}
\normalsize
- \caption{La definizione dei possibili valori di una \direct{union}
+ \caption{La definizione dei possibili valori di una \dirct{union}
\structd{semun}, usata come quarto argomento della funzione
\func{semctl}.}
\label{fig:ipc_semun}
impostato il flag \const{FD\_CLOEXEC}. Chiamate effettuate da diversi
processi usando lo stesso nome restituiranno file descriptor associati allo
stesso segmento, così come, nel caso di file ordinari, essi sono associati
-allo stesso \itindex{inode} inode. In questo modo è possibile effettuare una
-chiamata ad \func{mmap} sul file descriptor restituito da \func{shm\_open} ed
-i processi vedranno lo stesso segmento di memoria condivisa.
+allo stesso inode. In questo modo è possibile effettuare una chiamata ad
+\func{mmap} sul file descriptor restituito da \func{shm\_open} ed i processi
+vedranno lo stesso segmento di memoria condivisa.
Quando il nome non esiste si può creare un nuovo segmento specificando
\const{O\_CREAT}; in tal caso il segmento avrà (così come i nuovi file)
essere utilizzata soltanto se viene definita la macro \macro{\_XOPEN\_SOURCE}
ad un valore di almeno 600 o la macro \macro{\_POSIX\_C\_SOURCE} ad un valore
uguale o maggiore di \texttt{200112L} prima di includere
-\headfile{semaphore.h}, la funzione è \funcd{sem\_timedwait}, ed il suo
+\headfiled{semaphore.h}, la funzione è \funcd{sem\_timedwait}, ed il suo
prototipo è:
\begin{funcproto}{
sbloccata, cosicché un altro processo (o \itindex{thread} \textit{thread})
eventualmente bloccato in una \func{sem\_wait} sul semaforo possa essere
svegliato e rimesso in esecuzione. Si tenga presente che la funzione è sicura
-\index{funzioni!sicure} per l'uso all'interno di un gestore di segnali (si
-ricordi quanto detto in sez.~\ref{sec:sig_signal_handler}).
+per l'uso all'interno di un gestore di segnali (si ricordi quanto detto in
+sez.~\ref{sec:sig_signal_handler}).
Se invece di operare su un semaforo se ne volesse semplicemente leggere il
valore, si potrà usare la funzione \funcd{sem\_getvalue}, il cui prototipo è:
\end{Console}
%$
-E si noterà come nel momento in cui si è lanciato \file{message\_setter} le
-stampe di \file{message\_getter} si bloccheranno, come corretto, dopo aver
-registrato un valore nullo per il semaforo. Il programma infatti resterà
-bloccato nella \func{sem\_wait} (quella di riga (\texttt{\small 37}) in
+E si noterà come nel momento in cui si lancia \file{message\_setter} le stampe
+di \file{message\_getter} si bloccheranno, come corretto, dopo aver registrato
+un valore nullo per il semaforo. Il programma infatti resterà bloccato nella
+\func{sem\_wait} (quella di riga (\texttt{\small 37}) in
fig.~\ref{fig:ipc_posix_sem_shm_message_server}) fino alla scadenza
dell'attesa di \file{message\_setter} (con l'esecuzione della \func{sem\_post}
della riga (\texttt{\small 29}) di
projects / gapil.git / blobdiff