attraverso cui fluiscono i dati.
La funzione che permette di creare questa speciale coppia di file descriptor
-associati ad una \textit{pipe} è appunto \func{pipe}, ed il suo prototipo è:
+associati ad una \textit{pipe} è appunto \funcd{pipe}, ed il suo prototipo è:
\begin{prototype}{unistd.h}
{int pipe(int filedes[2])}
Crea una coppia di file descriptor associati ad una \textit{pipe}.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per un
- errore, nel qual caso \var{errno} potrà assumere i valori \const{EMFILE},
- \const{ENFILE} e \const{EFAULT}.}
+ errore, nel qual caso \var{errno} potrà assumere i valori \errval{EMFILE},
+ \errval{ENFILE} e \errval{EFAULT}.}
\end{prototype}
La funzione restituisce la coppia di file descriptor nel vettore
(vale a dire che la funzione \func{read} ritornerà restituendo 0). Se invece
si esegue una scrittura su una pipe il cui capo in lettura non è aperto il
processo riceverà il segnale \errcode{EPIPE}, e la funzione di scrittura
-restituirà un errore di \errcode{EPIPE} (al ritorno del manipolatore, o qualora
-il segnale sia ignorato o bloccato).
+restituirà un errore di \errcode{EPIPE} (al ritorno del gestore, o qualora il
+segnale sia ignorato o bloccato).
La dimensione del buffer della pipe (\const{PIPE\_BUF}) ci dà inoltre un'altra
importante informazione riguardo il comportamento delle operazioni di lettura
Si potrebbe obiettare che sarebbe molto più semplice salvare il risultato
intermedio su un file temporaneo. Questo però non tiene conto del fatto che un
\textit{CGI} deve poter gestire più richieste in concorrenza, e si avrebbe una
-evidente race condition in caso di accesso simultaneo a detto
-file.\footnote{il problema potrebbe essere superato determinando in anticipo
- un nome appropriato per il file temporaneo, che verrebbe utilizzato dai vari
- sotto-processi, e cancellato alla fine della loro esecuzione; ma a questo le
- cose non sarebbero più tanto semplici.} L'uso di una pipe invece permette
-di risolvere il problema in maniera semplice ed elegante, oltre ad essere
-molto più efficiente, dato che non si deve scrivere su disco.
+evidente race condition\index{race condition} in caso di accesso simultaneo a
+detto file.\footnote{il problema potrebbe essere superato determinando in
+ anticipo un nome appropriato per il file temporaneo, che verrebbe utilizzato
+ dai vari sotto-processi, e cancellato alla fine della loro esecuzione; ma a
+ questo le cose non sarebbero più tanto semplici.} L'uso di una pipe invece
+permette di risolvere il problema in maniera semplice ed elegante, oltre ad
+essere molto più efficiente, dato che non si deve scrivere su disco.
Il programma ci servirà anche come esempio dell'uso delle funzioni di
duplicazione dei file descriptor che abbiamo trattato in
utilizzarla per fare da tramite fra output ed input di due programmi invocati
in sequenza; per questo motivo lo standard POSIX.2 ha introdotto due funzioni
che permettono di sintetizzare queste operazioni. La prima di esse si chiama
-\func{popen} ed il suo prototipo è:
+\funcd{popen} ed il suo prototipo è:
\begin{prototype}{stdio.h}
{FILE *popen(const char *command, const char *type)}
quindi associato allo standard input) in caso di \code{"w"}.
Lo stream restituito da \func{popen} è identico a tutti gli effetti ai file
-stream visti in \secref{cha:files_std_interface}, anche se è collegato ad una
-pipe e non ad un inode, e viene sempre aperto in modalità
+stream visti in \capref{cha:files_std_interface}, anche se è collegato ad una
+pipe e non ad un inode\index{inode}, e viene sempre aperto in modalità
\textit{fully-buffered} (vedi \secref{sec:file_buffering}); l'unica differenza
con gli usuali stream è che dovrà essere chiuso dalla seconda delle due nuove
-funzioni, \func{pclose}, il cui prototipo è:
+funzioni, \funcd{pclose}, il cui prototipo è:
\begin{prototype}{stdio.h}
{int pclose(FILE *stream)}
attendendo la terminazione del processo ad essa associato.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore; nel quel caso il valore di \func{errno} deriva dalle sottostanti
+ errore; nel quel caso il valore di \var{errno} deriva dalle sottostanti
chiamate.}
\end{prototype}
\noindent che oltre alla chiusura dello stream si incarica anche di attendere
ha definito dei nuovi oggetti, le \textit{fifo}, che hanno le stesse
caratteristiche delle pipe, ma che invece di essere strutture interne del
kernel, visibili solo attraverso un file descriptor, sono accessibili
-attraverso un inode che risiede sul filesystem, così che i processi le possono
-usare senza dovere per forza essere in una relazione di \textsl{parentela}.
+attraverso un inode\index{inode} che risiede sul filesystem, così che i
+processi le possono usare senza dovere per forza essere in una relazione di
+\textsl{parentela}.
Utilizzando una \textit{fifo} tutti i dati passeranno, come per le pipe,
attraverso un apposito buffer nel kernel, senza transitare dal filesystem;
-l'inode allocato sul filesystem serve infatti solo a fornire un punto di
-riferimento per i processi, che permetta loro di accedere alla stessa fifo; il
-comportamento delle funzioni di lettura e scrittura è identico a quello
-illustrato per le pipe in \secref{sec:ipc_pipes}.
+l'inode\index{inode} allocato sul filesystem serve infatti solo a fornire un
+punto di riferimento per i processi, che permetta loro di accedere alla stessa
+fifo; il comportamento delle funzioni di lettura e scrittura è identico a
+quello illustrato per le pipe in \secref{sec:ipc_pipes}.
Abbiamo già visto in \secref{sec:file_mknod} le funzioni \func{mknod} e
\func{mkfifo} che permettono di creare una fifo; per utilizzarne una un
lettura; è possibile anche usare la fifo all'interno di un solo processo, nel
qual caso però occorre stare molto attenti alla possibili situazioni di
stallo.\footnote{se si cerca di leggere da una fifo che non contiene dati si
- avrà un deadlock immediato, dato che il processo si blocca e non potrà
- quindi mai eseguire le funzioni di scrittura.}
+ avrà un deadlock\index{deadlock} immediato, dato che il processo si blocca e
+ non potrà quindi mai eseguire le funzioni di scrittura.}
Per la loro caratteristica di essere accessibili attraverso il filesystem, è
piuttosto frequente l'utilizzo di una fifo come canale di comunicazione nelle
processo alla volta (nel qual caso basta usare due fifo, una per leggere ed
una per scrivere), le cose diventano invece molto più complesse quando si
vuole effettuare una comunicazione fra il server ed un numero imprecisato di
-client; se il primo infatti può ricevere le richieste attraverso una fifo
-``nota'', per le risposte non si può fare altrettanto, dato che, per la
-struttura sequenziale delle fifo, i client dovrebbero sapere, prima di
+client; se il primo infatti può ricevere le richieste attraverso una fifo```\textsl{nota}'', per le risposte non si può fare altrettanto, dato che, per
+la struttura sequenziale delle fifo, i client dovrebbero sapere, prima di
leggerli, quando i dati inviati sono destinati a loro.
Per risolvere questo problema, si può usare un'architettura come quella
Un meccanismo di comunicazione molto simile alle pipe, ma che non presenta il
problema della unidirezionalità del flusso dei dati, è quello dei cosiddetti
\textsl{socket locali} (o \textit{Unix domain socket}). Tratteremo l'argomento
-dei \textit{socket} in \capref{cha:socket_intro},\footnote{si tratta comunque
- di oggetti di comunicazione che, come le pipe, sono utilizzati attraverso
- dei file descriptor.} nell'ambito dell'interfaccia generale che essi
-forniscono per la programmazione di rete; e vedremo anche
+dei \textit{socket}\index{socket} in \capref{cha:socket_intro},\footnote{si
+ tratta comunque di oggetti di comunicazione che, come le pipe, sono
+ utilizzati attraverso dei file descriptor.} nell'ambito dell'interfaccia
+generale che essi forniscono per la programmazione di rete; e vedremo anche
(in~\secref{sec:sock_sa_local}) come si possono definire dei file speciali (di
tipo \textit{socket}, analoghi a quello associati alle fifo) cui si accede
però attraverso quella medesima interfaccia; vale però la pena esaminare qui
che fornisca l'interfaccia dei socket.} che li rende sostanzialmente
identici ad una pipe bidirezionale.
-La funzione \func{socketpair} infatti consente di creare una coppia di file
-descriptor connessi fra di loro (tramite un socket, appunto), senza dover
-ricorrere ad un file speciale sul filesystem, i descrittori sono del tutto
-analoghi a quelli che si avrebbero con una chiamata a \func{pipe}, con la sola
-differenza è che in questo caso il flusso dei dati può essere effettuato in
-entrambe le direzioni. Il prototipo della funzione è:
+La funzione \funcd{socketpair} infatti consente di creare una coppia di file
+descriptor connessi fra di loro (tramite un socket\index{socket}, appunto),
+senza dover ricorrere ad un file speciale sul filesystem, i descrittori sono
+del tutto analoghi a quelli che si avrebbero con una chiamata a \func{pipe},
+con la sola differenza è che in questo caso il flusso dei dati può essere
+effettuato in entrambe le direzioni. Il prototipo della funzione è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/socket.h}
\funcdecl{int socketpair(int domain, int type, int protocol, int sv[2])}
- Crea una coppia di socket connessi fra loro.
+ Crea una coppia di socket\index{socket} connessi fra loro.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EAFNOSUPPORT}] I socket locali non sono supportati.
+ \item[\errcode{EAFNOSUPPORT}] I socket\index{socket} locali non sono
+ supportati.
\item[\errcode{EPROTONOSUPPORT}] Il protocollo specificato non è supportato.
\item[\errcode{EOPNOTSUPP}] Il protocollo specificato non supporta la
- creazione di coppie di socket.
+ creazione di coppie di socket\index{socket}.
\end{errlist}
- ed inoltre \const{EMFILE}, \const{EFAULT}.
+ ed inoltre \errval{EMFILE}, \errval{EFAULT}.
}
\end{functions}
La funzione restituisce in \param{sv} la coppia di descrittori connessi fra di
loro: quello che si scrive su uno di essi sarà ripresentato in input
sull'altro e viceversa. I parametri \param{domain}, \param{type} e
-\param{protocol} derivano dall'interfaccia dei socket (che è quella che
-fornisce il substrato per connettere i due descrittori), ma in questo caso i
-soli valori validi che possono essere specificati sono rispettivamente
-\const{AF\_UNIX}, \const{SOCK\_STREAM} e \var{0}.
+\param{protocol} derivano dall'interfaccia dei socket\index{socket} (che è
+quella che fornisce il substrato per connettere i due descrittori), ma in
+questo caso i soli valori validi che possono essere specificati sono
+rispettivamente \const{AF\_UNIX}, \const{SOCK\_STREAM} e \val{0}.
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
-locali in generale) permette di trasmettere attraverso le linea non solo dei
-dati, ma anche dei file descriptor: si può cioè passare da un processo ad un
-altro un file descriptor, con una sorta di duplicazione dello stesso non
-all'interno di uno stesso processo, ma fra processi distinti (torneremo su
-questa funzionalità in \secref{sec:xxx_fd_passing}).
+può sembrare limitata; in realtà l'utilizzo di questa funzione (e dei
+socket\index{socket} locali in generale) permette di trasmettere attraverso le
+linea non solo dei dati, ma anche dei file descriptor: si può cioè passare da
+un processo ad un altro un file descriptor, con una sorta di duplicazione
+dello stesso non all'interno di uno stesso processo, ma fra processi distinti
+(torneremo su questa funzionalità in \secref{sec:xxx_fd_passing}).
\section{La comunicazione fra processi di System V}
si pone perciò il problema di come processi diversi possono accedere allo
stesso oggetto.
-Per risolvere il problema nella struttura \var{ipc\_perm} che il kernel
+Per risolvere il problema nella struttura \struct{ipc\_perm} che il kernel
associa a ciascun oggetto, viene mantenuto anche un campo apposito che
contiene anche una \textsl{chiave}, identificata da una variabile del tipo
primitivo \type{key\_t}, da specificare in fase di creazione dell'oggetto, e
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \var{ipc\_perm}, come definita in \file{sys/ipc.h}.}
+ \caption{La struttura \structd{ipc\_perm}, come definita in
+ \file{sys/ipc.h}.}
\label{fig:ipc_ipc_perm}
\end{figure}
la chiave (che ad esempio può essere dichiarato in un header comune), ma c'è
sempre il rischio che questa chiave possa essere stata già utilizzata da
qualcun altro. Dato che non esiste una convenzione su come assegnare queste
-chiavi in maniera univoca l'interfaccia mette a disposizione una funzione,
-\func{ftok}, che permette di ottenere una chiave specificando il nome di un
-file ed un numero di versione; il suo prototipo è:
+chiavi in maniera univoca l'interfaccia mette a disposizione una funzione
+apposita, \funcd{ftok}, che permette di ottenere una chiave specificando il
+nome di un file ed un numero di versione; il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
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 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\index{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
creare un oggetto, che la chiave non sia già stata utilizzata. Se questo va
bene in fase di creazione, le cose possono complicarsi per i programmi che
devono solo accedere, in quanto, a parte gli eventuali controlli sugli altri
-attributi di \var{ipc\_perm}, non esiste una modalità semplice per essere
+attributi di \struct{ipc\_perm}, non esiste una modalità semplice per essere
sicuri che l'oggetto associato ad una certa chiave sia stato effettivamente
creato da chi ci si aspetta.
\label{sec:ipc_sysv_access_control}
Oltre alle chiavi, abbiamo visto che ad ogni oggetto sono associate in
-\var{ipc\_perm} ulteriori informazioni, come gli identificatori del creatore
+\struct{ipc\_perm} ulteriori informazioni, come gli identificatori del creatore
(nei campi \var{cuid} e \var{cgid}) e del proprietario (nei campi \var{uid} e
\var{gid}) dello stesso, e un insieme di permessi (nel campo \var{mode}). In
questo modo è possibile definire un controllo di accesso sugli oggetti di IPC,
il proprietario, il suo gruppo e tutti gli altri.
Quando l'oggetto viene creato i campi \var{cuid} e \var{uid} di
-\var{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono settati
+\struct{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono settati
rispettivamente al valore dell'userid e del groupid effettivo del processo che
ha chiamato la funzione, ma, mentre i campi \var{uid} e \var{gid} possono
essere cambiati, i campi \var{cuid} e \var{cgid} restano sempre gli stessi.
\subsection{Gli identificatori ed il loro utilizzo}
\label{sec:ipc_sysv_id_use}
-L'unico campo di \var{ipc\_perm} del quale non abbiamo ancora parlato è
+L'unico campo di \struct{ipc\_perm} del quale non abbiamo ancora parlato è
\var{seq}, che in \figref{fig:ipc_ipc_perm} è qualificato con un criptico
``\textsl{numero di sequenza}'', ne parliamo adesso dato che esso è
strettamente attinente alle modalità con cui il kernel assegna gli
con gli oggetti del secondo, con conseguenze imprevedibili.
Proprio per evitare questo tipo di situazioni il sistema usa il valore di
-\var{req} per provvedere un meccanismo che porti gli identificatori ad
+\var{seq} per provvedere un meccanismo che porti gli identificatori ad
assumere tutti i valori possibili, rendendo molto più lungo il periodo in cui
un identificatore può venire riutilizzato.
Il primo oggetto introdotto dal \textit{SysV IPC} è quello delle code di
messaggi. Le code di messaggi sono oggetti analoghi alle pipe o alle fifo,
-anche se la loro struttura è diversa. La funzione che permette di ottenerne
-una è \func{msgget} ed il suo prototipo è:
+anche se la loro struttura è diversa, ed il loro scopo principale è appunto
+quello di permettere a processi diversi di scambiarsi dei dati.
+
+La funzione che permette di richiedere al sistema l'identificatore di una coda
+di messaggi esistente (o di crearne una se questa non esiste) è
+\funcd{msgget}; il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
\item[\errcode{ENOSPC}] Si è cercato di creare una coda di messaggi quando è
stato superato il limite massimo di code (\const{MSGMNI}).
\end{errlist}
- ed inoltre \const{ENOMEM}.
+ ed inoltre \errval{ENOMEM}.
}
\end{functions}
dipende dal valore di \param{flag}, se questo è nullo la funzione si limita ad
effettuare una ricerca sugli oggetti esistenti, restituendo l'identificatore
se trova una corrispondenza, o fallendo con un errore di \errcode{ENOENT} se
-non esiste o di \errcode{EACCESS} se si sono specificati dei permessi non
+non esiste o di \errcode{EACCES} se si sono specificati dei permessi non
validi.
Se invece si vuole creare una nuova coda di messaggi \param{flag} non può
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \var{msgid\_ds}, associata a ciascuna coda di
+ \caption{La struttura \structd{msgid\_ds}, associata a ciascuna coda di
messaggi.}
\label{fig:ipc_msgid_ds}
\end{figure}
-A ciascuna coda è associata una struttura \var{msgid\_ds}, la cui definizione,
-è riportata in \secref{fig:ipc_msgid_ds}. In questa struttura il kernel
-mantiene le principali informazioni riguardo lo stato corrente della
+A ciascuna coda è associata una struttura \struct{msgid\_ds}, la cui
+definizione, è riportata in \secref{fig:ipc_msgid_ds}. In questa struttura il
+kernel mantiene le principali informazioni riguardo lo stato corrente della
coda.\footnote{come accennato questo vale fino ai kernel della serie 2.2.x,
essa viene usata nei kernel della serie 2.4.x solo per compatibilità in
quanto è quella restituita dalle funzioni dell'interfaccia. Si noti come ci
\end{itemize}
Una volta creata una coda di messaggi le operazioni di controllo vengono
-effettuate con la funzione \func{msgctl}, che (come le analoghe \func{semctl}
+effettuate con la funzione \funcd{msgctl}, che (come le analoghe \func{semctl}
e \func{shmctl}) fa le veci di quello che \func{ioctl} è per i file; il suo
prototipo è:
\begin{functions}
\var{msg\_qbytes} oltre il limite \const{MSGMNB} senza essere
amministratore.
\end{errlist}
- ed inoltre \const{EFAULT} ed \const{EINVAL}.
+ ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
}
\end{functions}
-La funzione permette di accedere ai valori della struttura \var{msqid\_ds},
+La funzione permette di accedere ai valori della struttura \struct{msqid\_ds},
mantenuta all'indirizzo \param{buf}, per la coda specificata
dall'identificatore \param{msqid}. Il comportamento della funzione dipende dal
valore dell'argomento \param{cmd}, che specifica il tipo di azione da
\item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
della coda, ed il limite massimo sulle dimensioni del totale dei messaggi in
essa contenuti (\var{msg\_qbytes}). I valori devono essere passati in una
- struttura \var{msqid\_ds} puntata da \param{buf}. Per modificare i valori
+ struttura \struct{msqid\_ds} puntata da \param{buf}. Per modificare i valori
di \var{msg\_perm.mode}, \var{msg\_perm.uid} e \var{msg\_perm.gid} occorre
essere il proprietario o il creatore della coda, oppure l'amministratore; lo
stesso vale per \var{msg\_qbytes}, ma l'amministratore ha la facoltà di
Una volta che si abbia a disposizione l'identificatore, per inviare un
-messaggio su una coda si utilizza la funzione \func{msgsnd}; il suo prototipo
+messaggio su una coda si utilizza la funzione \funcd{msgsnd}; il suo prototipo
è:
\begin{functions}
\headdecl{sys/types.h}
valore non positivo per \param{mtype}, o un valore di \param{msgsz}
maggiore di \const{MSGMAX}.
\end{errlist}
- ed inoltre \const{EFAULT} ed \const{ENOMEM}.
+ ed inoltre \errval{EFAULT} ed \errval{ENOMEM}.
}
\end{functions}
La funzione inserisce il messaggio sulla coda specificata da \param{msqid}; il
messaggio ha lunghezza specificata da \param{msgsz} ed è passato attraverso il
l'argomento \param{msgp}. Quest'ultimo deve venire passato sempre come
-puntatore ad una struttura \var{msgbuf} analoga a quella riportata in
+puntatore ad una struttura \struct{msgbuf} analoga a quella riportata in
\figref{fig:ipc_msbuf} che è quella che deve contenere effettivamente il
messaggio. La dimensione massima per il testo di un messaggio non può
comunque superare il limite \const{MSGMAX}.
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{Schema della struttura \var{msgbuf}, da utilizzare come argomento
- per inviare/ricevere messaggi.}
+ \caption{Schema della struttura \structd{msgbuf}, da utilizzare come
+ argomento per inviare/ricevere messaggi.}
\label{fig:ipc_msbuf}
\end{figure}
Per capire meglio il funzionamento della funzione riprendiamo in
considerazione la struttura della coda illustrata in
\figref{fig:ipc_mq_schema}. Alla chiamata di \func{msgsnd} il nuovo messaggio
-sarà aggiunto in fondo alla lista inserendo una nuova struttura \var{msg}, il
-puntatore \var{msg\_last} di \var{msqid\_ds} verrà aggiornato, come pure il
-puntatore al messaggio successivo per quello che era il precedente ultimo
+sarà aggiunto in fondo alla lista inserendo una nuova struttura \struct{msg},
+il puntatore \var{msg\_last} di \struct{msqid\_ds} verrà aggiornato, come pure
+il puntatore al messaggio successivo per quello che era il precedente ultimo
messaggio; il valore di \var{mtype} verrà mantenuto in \var{msg\_type} ed il
valore di \param{msgsz} in \var{msg\_ts}; il testo del messaggio sarà copiato
all'indirizzo specificato da \var{msg\_spot}.
interrotta da un segnale (nel qual caso si ha un errore di \errcode{EINTR}).
Una volta completato con successo l'invio del messaggio sulla coda, la
-funzione aggiorna i dati mantenuti in \var{msqid\_ds}, in particolare vengono
-modificati:
+funzione aggiorna i dati mantenuti in \struct{msqid\_ds}, in particolare
+vengono modificati:
\begin{itemize*}
\item Il valore di \var{msg\_lspid}, che viene impostato al \acr{pid} del
processo chiamante.
\end{itemize*}
La funzione che viene utilizzata per estrarre un messaggio da una coda è
-\func{msgrcv}; il suo prototipo è:
+\funcd{msgrcv}; il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
\item[\errcode{EINVAL}] Si è specificato un \param{msgid} invalido o un
valore di \param{msgsz} negativo.
\end{errlist}
- ed inoltre \const{EFAULT}.
+ ed inoltre \errval{EFAULT}.
}
\end{functions}
un segnale (con \var{errno} impostata a \errcode{EINTR}).
Una volta completata con successo l'estrazione del messaggio dalla coda, la
-funzione aggiorna i dati mantenuti in \var{msqid\_ds}, in particolare vengono
-modificati:
+funzione aggiorna i dati mantenuti in \struct{msqid\_ds}, in particolare
+vengono modificati:
\begin{itemize*}
\item Il valore di \var{msg\_lrpid}, che viene impostato al \acr{pid} del
processo chiamante.
La gestione delle opzioni si è al solito omessa, essa si curerà di impostare
in \var{n} il numero di frasi da leggere specificato a linea di comando ed in
\var{fortunefilename} il file da cui leggerle; dopo aver installato
-(\texttt{\small 19--21}) dei manipolatori per gestire l'uscita dal server,
-viene prima controllato (\texttt{\small 22}) il numero di frasi richieste
-abbia senso (cioè sia maggiore di zero), le quali poi (\texttt{\small 23})
-vengono lette nel vettore in memoria con la stessa funzione
-\code{FortuneParse()} usata anche per il server basato sulle fifo.
+(\texttt{\small 19--21}) i gestori dei segnali per trattare l'uscita dal
+server, viene prima controllato (\texttt{\small 22}) il numero di frasi
+richieste abbia senso (cioè sia maggiore di zero), le quali poi
+(\texttt{\small 23}) vengono lette nel vettore in memoria con la stessa
+funzione \code{FortuneParse()} usata anche per il server basato sulle fifo.
Una volta inizializzato il vettore di stringhe coi messaggi presi dal file
delle \textit{fortune} si procede (\texttt{\small 25}) con la generazione di
funzione potrà bloccarsi fintanto che non venga liberato dello spazio.
Si noti che il programma può terminare solo grazie ad una interruzione da
-parte di un segnale; in tal caso verrà eseguito il manipolatore
+parte di un segnale; in tal caso verrà eseguito il gestore
\code{HandSIGTERM}, che semplicemente si limita a cancellare la coda
(\texttt{\small 44}) ed ad uscire (\texttt{\small 45}).
della risposta, quest'ultima resta nella coda (così come per le fifo si aveva
il problema delle 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 inode di un filesystem, sia perché,
-con il riutilizzo dei \acr{pid} da parte dei processi, un client eseguito in
-un momento successivo potrebbe ricevere un messaggio non indirizzato a
-lui.
+dedicata ad una coda di messaggi che gli inode\index{inode} di un filesystem,
+sia perché, con il riutilizzo dei \acr{pid} da parte dei processi, un client
+eseguito in un momento successivo potrebbe ricevere un messaggio non
+indirizzato a lui.
utilizzando il valore del contatore come indicatore del ``numero di risorse''
ancora disponibili.
-Il sistema di comunicazione interprocesso di \textit{SysV IPC} prevede anche i
+Il sistema di comunicazione inter-processo di \textit{SysV IPC} prevede anche i
semafori, ma gli oggetti utilizzati non sono semafori singoli, ma gruppi di
semafori detti \textsl{insiemi} (o \textit{semaphore set}); la funzione che
permette di creare o ottenere l'identificatore di un insieme di semafori è
-\func{semget}, ed il suo prototipo è:
+\funcd{semget}, ed il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
\item[\errcode{ENOMEM}] Il sistema non ha abbastanza memoria per poter
contenere le strutture per un nuovo insieme di semafori.
\end{errlist}
- ed inoltre \const{EACCES}, \const{ENOENT}, \const{EEXIST}, \const{EIDRM},
- con lo stesso significato che hanno per \func{msgget}.}
+ ed inoltre \errval{EACCES}, \errval{ENOENT}, \errval{EEXIST},
+ \errval{EIDRM}, con lo stesso significato che hanno per \func{msgget}.}
\end{functions}
La funzione è del tutto analoga a \func{msgget}, solo che in questo caso
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \var{semid\_ds}, associata a ciascun insieme di
+ \caption{La struttura \structd{semid\_ds}, associata a ciascun insieme di
semafori.}
\label{fig:ipc_semid_ds}
\end{figure}
-A ciascun insieme di semafori è associata una struttura \var{semid\_ds},
+A ciascun insieme di semafori è associata una struttura \struct{semid\_ds},
riportata in \figref{fig:ipc_semid_ds}.\footnote{non si sono riportati i campi
ad uso interno del kernel, che vedremo in \figref{fig:ipc_sem_schema}, che
dipendono dall'implementazione.} Come nel caso delle code di messaggi quando
Ciascun semaforo dell'insieme è realizzato come una struttura di tipo
-\var{sem} che ne contiene i dati essenziali, la sua definizione\footnote{si è
- riportata la definizione originaria del kernel 1.0, che contiene la prima
+\struct{sem} che ne contiene i dati essenziali, la sua definizione\footnote{si
+ è riportata la definizione originaria del kernel 1.0, che contiene la prima
realizzazione del \textit{SysV IPC} in Linux. In realtà questa struttura
ormai è ridotta ai soli due primi membri, e gli altri vengono calcolati
dinamicamente. La si è utilizzata a scopo di esempio, perché indica tutti i
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \var{sem}, che contiene i dati di un singolo semaforo.}
+ \caption{La struttura \structd{sem}, che contiene i dati di un singolo
+ semaforo.}
\label{fig:ipc_sem}
\end{figure}
I dati mantenuti nella struttura, ed elencati in \figref{fig:ipc_sem},
-indicano rispettivamente:
+indicano rispettivamente:
\begin{description*}
\item[\var{semval}] il valore numerico del semaforo.
\item[\var{sempid}] il \acr{pid} dell'ultimo processo che ha eseguito una
La funzione che permette di effettuare le varie operazioni di controllo sui
semafori (fra le quali, come accennato, è impropriamente compresa anche la
-loro inizializzazione) è \func{semctl}; il suo prototipo è:
+loro inizializzazione) è \funcd{semctl}; il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
valore a cui si vuole impostare il semaforo è minore di zero o maggiore
di \const{SEMVMX}.
\end{errlist}
- ed inoltre \const{EFAULT} ed \const{EINVAL}.
+ ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
}
\end{functions}
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La definizione dei possibili valori di una \var{union semun}, usata
- come quarto argomento della funzione \func{semctl}.}
+ \caption{La definizione dei possibili valori di una \direct{union}
+ \structd{semun}, usata come quarto argomento della funzione
+ \func{semctl}.}
\label{fig:ipc_semun}
\end{figure}
-Qualora la funzione operi con quattro argomenti \param{arg} è
-un argomento generico, che conterrà un dato diverso a seconda dell'azione
-richiesta; per unificare l'argomento esso deve essere passato come una
-\var{union semun}, la cui definizione, con i possibili valori che può
-assumere, è riportata in \figref{fig:ipc_semun}.
+Qualora la funzione operi con quattro argomenti \param{arg} è un argomento
+generico, che conterrà un dato diverso a seconda dell'azione richiesta; per
+unificare l'argomento esso deve essere passato come una \struct{semun}, la cui
+definizione, con i possibili valori che può assumere, è riportata in
+\figref{fig:ipc_semun}.
Come già accennato sia il comportamento della funzione che il numero di
parametri con cui deve essere invocata, dipendono dal valore dell'argomento
seguenti:
\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
\item[\const{IPC\_STAT}] Legge i dati dell'insieme di semafori, copiando il
- contenuto della relativa struttura \var{semid\_ds} all'indirizzo specificato
- con \var{arg.buf}. Occorre avere il permesso di lettura. L'argomento
- \param{semnum} viene ignorato.
+ contenuto della relativa struttura \struct{semid\_ds} all'indirizzo
+ specificato con \var{arg.buf}. Occorre avere il permesso di lettura.
+ L'argomento \param{semnum} viene ignorato.
\item[\const{IPC\_RMID}] Rimuove l'insieme di semafori e le relative strutture
dati, con effetto immediato. Tutti i processi che erano stato di
\textit{sleep} vengono svegliati, ritornando con un errore di
\param{semnum} viene ignorato.
\item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
dell'insieme. I valori devono essere passati in una struttura
- \var{semid\_ds} puntata da \param{arg.buf} di cui saranno usati soltanto i
+ \struct{semid\_ds} puntata da \param{arg.buf} di cui saranno usati soltanto i
campi \var{sem\_perm.uid}, \var{sem\_perm.gid} e i nove bit meno
significativi di \var{sem\_perm.mode}. L'userid effettivo del processo deve
corrispondere o al creatore o al proprietario dell'insieme, o
all'amministratore. L'argomento \param{semnum} viene ignorato.
\item[\const{GETALL}] Restituisce il valore corrente di ciascun semaforo
- dell'insieme (corrispondente al campo \var{semval} di \var{sem}) nel vettore
- indicato da \param{arg.array}. Occorre avere il permesso di lettura.
+ dell'insieme (corrispondente al campo \var{semval} di \struct{sem}) nel
+ vettore indicato da \param{arg.array}. Occorre avere il permesso di lettura.
L'argomento \param{semnum} viene ignorato.
\item[\const{GETNCNT}] Restituisce come valore di ritorno della funzione il
numero di processi in attesa che il semaforo \param{semnum} dell'insieme
\param{semid} venga incrementato (corrispondente al campo \var{semncnt} di
- \var{sem}); va invocata con tre argomenti. Occorre avere il permesso di
+ \struct{sem}); va invocata con tre argomenti. Occorre avere il permesso di
lettura.
\item[\const{GETPID}] Restituisce come valore di ritorno della funzione il
\acr{pid} dell'ultimo processo che ha compiuto una operazione sul semaforo
\param{semnum} dell'insieme \param{semid} (corrispondente al campo
- \var{sempid} di \var{sem}); va invocata con tre argomenti. Occorre avere il
- permesso di lettura.
+ \var{sempid} di \struct{sem}); va invocata con tre argomenti. Occorre avere
+ il permesso di lettura.
\item[\const{GETVAL}] Restituisce come valore di ritorno della funzione il il
valore corrente del semaforo \param{semnum} dell'insieme \param{semid}
- (corrispondente al campo \var{semval} di \var{sem}); va invocata con tre
+ (corrispondente al campo \var{semval} di \struct{sem}); va invocata con tre
argomenti. Occorre avere il permesso di lettura.
\item[\const{GETZCNT}] Restituisce come valore di ritorno della funzione il
numero di processi in attesa che il valore del semaforo \param{semnum}
dell'insieme \param{semid} diventi nullo (corrispondente al campo
- \var{semncnt} di \var{sem}); va invocata con tre argomenti. Occorre avere
+ \var{semncnt} di \struct{sem}); va invocata con tre argomenti. Occorre avere
il permesso di lettura.
\item[\const{SETALL}] Inizializza il valore di tutti i semafori dell'insieme,
- aggiornando il campo \var{sem\_ctime} di \var{semid\_ds}. I valori devono
+ aggiornando il campo \var{sem\_ctime} di \struct{semid\_ds}. I valori devono
essere passati nel vettore indicato da \param{arg.array}. Si devono avere i
privilegi di scrittura sul semaforo. L'argomento \param{semnum} viene
ignorato.
\item[\const{SETVAL}] Inizializza il semaforo \param{semnum} al valore passato
dall'argomento \param{arg.val}, aggiornando il campo \var{sem\_ctime} di
- \var{semid\_ds}. Si devono avere i privilegi di scrittura sul semaforo.
+ \struct{semid\_ds}. Si devono avere i privilegi di scrittura sul semaforo.
\end{basedescript}
Quando si imposta il valore di un semaforo (sia che lo si faccia per tutto
dall'operazione richiesta; per tutte le operazioni che richiedono quattro
argomenti esso è sempre nullo, per le altre operazioni, elencate in
\tabref{tab:ipc_semctl_returns} viene invece restituito il valore richiesto,
-corrispondente al campo della struttura \var{sem} indicato nella seconda
+corrispondente al campo della struttura \struct{sem} indicato nella seconda
colonna della tabella.
Le operazioni ordinarie sui semafori, come l'acquisizione o il rilascio degli
stessi (in sostanza tutte quelle non comprese nell'uso di \func{semctl})
-vengono effettuate con la funzione \func{semop}, il cui prototipo è:
+vengono effettuate con la funzione \funcd{semop}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
\item[\errcode{ERANGE}] Per alcune operazioni il valore risultante del
semaforo viene a superare il limite massimo \const{SEMVMX}.
\end{errlist}
- ed inoltre \const{EFAULT} ed \const{EINVAL}.
+ ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
}
\end{functions}
\param{semid} dell'insieme su cui si vuole operare. Il numero di operazioni da
effettuare viene specificato con l'argomento \param{nsop}, mentre il loro
contenuto viene passato con un puntatore ad un vettore di strutture
-\var{sembuf} nell'argomento \param{sops}. Le operazioni richieste vengono
+\struct{sembuf} nell'argomento \param{sops}. Le operazioni richieste vengono
effettivamente eseguite se e soltanto se è possibile effettuarle tutte quante.
\begin{figure}[!htb]
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \var{sembuf}, usata per le operazioni sui
+ \caption{La struttura \structd{sembuf}, usata per le operazioni sui
semafori.}
\label{fig:ipc_sembuf}
\end{figure}
Il contenuto di ciascuna operazione deve essere specificato attraverso una
-opportuna struttura \var{sembuf} (la cui definizione è riportata in
+opportuna struttura \struct{sembuf} (la cui definizione è riportata in
\figref{fig:ipc_sembuf}) che il programma chiamante deve avere cura di
allocare in un opportuno vettore. La struttura permette di indicare il
semaforo su cui operare, il tipo di operazione, ed un flag di controllo.
sull'insieme di semafori.
\end{basedescript}
-In caso di successo della funzione viene aggiornato di \var{sempid} per ogni
-semaforo modificato al valore del \acr{pid} del processo chiamante; inoltre
-vengono pure aggiornati al tempo corrente i campi \var{sem\_otime} e
+In caso di successo della funzione viene aggiornato il campo \var{sempid} per
+ogni semaforo modificato al valore del \acr{pid} del processo chiamante;
+inoltre vengono pure aggiornati al tempo corrente i campi \var{sem\_otime} e
\var{sem\_ctime}.
Dato che, come già accennato in precedenza, in caso di uscita inaspettata i
semafori possono restare occupati, abbiamo visto come \func{semop} permetta di
attivare un meccanismo di ripristino attraverso l'uso del flag
\const{SEM\_UNDO}. Il meccanismo è implementato tramite una apposita struttura
-\var{sem\_undo}, associata ad ogni processo per ciascun semaforo che esso ha
-modificato; all'uscita i semafori modificati vengono ripristinati, e le
+\struct{sem\_undo}, associata ad ogni processo per ciascun semaforo che esso
+ha modificato; all'uscita i semafori modificati vengono ripristinati, e le
strutture disallocate. Per mantenere coerente il comportamento queste
strutture non vengono ereditate attraverso una \func{fork} (altrimenti si
avrebbe un doppio ripristino), mentre passano inalterate nell'esecuzione di
\end{figure}
Alla creazione di un nuovo insieme viene allocata una nuova strutture
-\var{semid\_ds} ed il relativo vettore di strutture \var{sem}. Quando si
+\struct{semid\_ds} ed il relativo vettore di strutture \struct{sem}. Quando si
richiede una operazione viene anzitutto verificato che tutte le operazioni
possono avere successo; se una di esse comporta il blocco del processo il
-kernel crea una struttura \var{sem\_queue} che viene aggiunta in fondo alla
+kernel crea una struttura \struct{sem\_queue} che viene aggiunta in fondo alla
coda di attesa associata a ciascun insieme di semafori\footnote{che viene
referenziata tramite i campi \var{sem\_pending} e \var{sem\_pending\_last}
- di \var{semid\_ds}.}. Nella struttura viene memorizzato il riferimento alle
-operazioni richieste (nel campo \var{sops}, che è un puntatore ad una
-struttura \var{sembuf}) e al processo corrente (nel campo \var{sleeper}) poi
+ di \struct{semid\_ds}.}. Nella struttura viene memorizzato il riferimento
+alle operazioni richieste (nel campo \var{sops}, che è un puntatore ad una
+struttura \struct{sembuf}) e al processo corrente (nel campo \var{sleeper}) poi
quest'ultimo viene messo stato di attesa e viene invocato lo
scheduler\index{scheduler} per passare all'esecuzione di un altro processo.
immediatamente, dopo di che il kernel esegue una scansione della coda di
attesa (a partire da \var{sem\_pending}) per verificare se qualcuna delle
operazioni sospese in precedenza può essere eseguita, nel qual caso la
-struttura \var{sem\_queue} viene rimossa e lo stato del processo associato
+struttura \struct{sem\_queue} viene rimossa e lo stato del processo associato
all'operazione (\var{sleeper}) viene riportato a \textit{running}; il tutto
viene ripetuto fin quando non ci sono più operazioni eseguibili o si è
svuotata la coda.
Per gestire il meccanismo del ripristino tutte le volte che per un'operazione
si è specificato il flag \const{SEM\_UNDO} viene mantenuta per ciascun insieme
-di semafori una apposita struttura \var{sem\_undo} che contiene (nel vettore
+di semafori una apposita struttura \struct{sem\_undo} che contiene (nel vettore
puntato dal campo \var{semadj}) un valore di aggiustamento per ogni semaforo
cui viene sommato l'opposto del valore usato per l'operazione.
strutture se questo viene cancellato o per azzerarle se si è eseguita una
operazione con \func{semctl}; l'altra associata al processo che ha eseguito
l'operazione;\footnote{attraverso il campo \var{semundo} di
- \var{task\_struct}, come mostrato in \ref{fig:ipc_sem_schema}.} quando un
+ \struct{task\_struct}, come mostrato in \ref{fig:ipc_sem_schema}.} quando un
processo termina, la lista ad esso associata viene scandita e le operazioni
applicate al semaforo.
(\texttt{\small 9--11}) si ritorna subito il risultato di \func{semget},
altrimenti (\texttt{\small 12}) si inizializza il semaforo chiamando
\func{semctl} con il comando \const{SETVAL}, utilizzando l'unione
-\var{semunion} dichiarata ed avvalorata in precedenza (\texttt{\small 6}) ad 1
-per significare che risorsa è libera. In caso di errore (\texttt{\small
+\struct{semunion} dichiarata ed avvalorata in precedenza (\texttt{\small 6})
+ad 1 per significare che risorsa è libera. In caso di errore (\texttt{\small
13--16}) si restituisce il valore di ritorno di \func{semctl}, altrimenti si
ritorna l'identificatore del semaforo.
strutture \var{sem\_lock} e \var{sem\_unlock} definite in precedenza
(\texttt{\small 32--42}). Si noti come per queste ultime si sia fatto uso
dell'opzione \const{SEM\_UNDO} per evitare che il semaforo resti bloccato in
-caso di terminazione imprevista del processo.%% Si noti infine come, essendo
-%% tutte le funzioni riportate in \figref{fig:ipc_mutex_create} estremamente
-%% semplici, se si sono definite tutte 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{PratC} che in questo modo possono
-%% essere evitati.}
-
+caso di terminazione imprevista del processo.
Chiamare \func{MutexLock} decrementa il valore del semaforo: se questo è
libero (ha già valore 1) sarà bloccato (valore nullo), se è bloccato la
che usare \func{MutexRead} per controllare il valore dei mutex prima di
proseguire non servirebbe comunque, dato che l'operazione non sarebbe atomica.
Vedremo in \secref{sec:ipc_posix_sem} come è possibile ottenere un'interfaccia
-analoga senza questo problemi usando il file locking.
+analoga senza questo problemi usando il file locking\index{file!locking}.
\label{sec:ipc_sysv_shm}
Il terzo oggetto introdotto dal \textit{SysV IPC} è quello dei segmenti di
-memoria condivisa. La funzione che permette di ottenerne uno è \func{shmget},
+memoria condivisa. La funzione che permette di ottenerne uno è \funcd{shmget},
ed il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\item[\errcode{ENOMEM}] Il sistema non ha abbastanza memoria per poter
contenere le strutture per un nuovo segmento di memoria condivisa.
\end{errlist}
- ed inoltre \const{EACCES}, \const{ENOENT}, \const{EEXIST}, \const{EIDRM},
- con lo stesso significato che hanno per \func{msgget}.}
+ ed inoltre \errval{EACCES}, \errval{ENOENT}, \errval{EEXIST},
+ \errval{EIDRM}, con lo stesso significato che hanno per \func{msgget}.}
\end{functions}
La funzione, come \func{semget}, è del tutto analoga a \func{msgget}, ed
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \var{shmid\_ds}, associata a ciascun segmento di
+ \caption{La struttura \structd{shmid\_ds}, associata a ciascun segmento di
memoria condivisa.}
\label{fig:ipc_shmid_ds}
\end{figure}
A ciascun segmento di memoria condivisa è associata una struttura
-\var{shmid\_ds}, riportata in \figref{fig:ipc_shmid_ds}. Come nel caso delle
-code di messaggi quando si crea un nuovo segmento di memoria condivisa con
-\func{shmget} questa struttura viene inizializzata, in particolare il campo
-\var{shm\_perm} viene inizializzato come illustrato in
+\struct{shmid\_ds}, riportata in \figref{fig:ipc_shmid_ds}. Come nel caso
+delle code di messaggi quando si crea un nuovo segmento di memoria condivisa
+con \func{shmget} questa struttura viene inizializzata, in particolare il
+campo \var{shm\_perm} viene inizializzato come illustrato in
\secref{sec:ipc_sysv_access_control}, e valgono le considerazioni ivi fatte
relativamente ai permessi di accesso; per quanto riguarda gli altri campi
invece:
\end{table}
Al solito la funzione che permette di effettuare le operazioni di controllo su
-un segmento di memoria condivisa è \func{shmctl}; il suo prototipo è:
+un segmento di memoria condivisa è \funcd{shmctl}; il suo prototipo è:
\begin{functions}
\headdecl{sys/ipc.h}
\headdecl{sys/shm.h}
\item[\errcode{EOVERFLOW}] L'argomento \param{shmid} fa riferimento ad un
segmento che è stato cancellato.
\end{errlist}
- ed inoltre \const{EFAULT}.}
+ ed inoltre \errval{EFAULT}.}
\end{functions}
Il comportamento della funzione dipende dal valore del comando passato
attraverso l'argomento \param{cmd}, i valori possibili sono i seguenti:
\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
\item[\const{IPC\_STAT}] Legge le informazioni riguardo il segmento di memoria
- condivisa nella struttura \var{shmid\_ds} puntata da \param{buf}. Occorre
+ condivisa nella struttura \struct{shmid\_ds} puntata da \param{buf}. Occorre
avere il permesso di lettura sulla coda.
\item[\const{IPC\_RMID}] Marca il segmento di memoria condivisa per la
rimozione, questo verrà cancellato effettivamente solo quando l'ultimo
gli ultimi due sono delle estensioni previste da Linux.
Per utilizzare i segmenti di memoria condivisa l'interfaccia prevede due
-funzioni, la prima è \func{shmat}, che serve ad agganciare un segmento al
+funzioni, la prima è \funcd{shmat}, che serve ad agganciare un segmento al
processo chiamante, in modo che quest'ultimo possa vederlo nel suo spazio di
indirizzi; il suo prototipo è:
\begin{functions}
\param{shmid}, o un indirizzo non allineato sul confine di una pagina
per \param{shmaddr}.
\end{errlist}
- ed inoltre \const{ENOMEM}.}
+ ed inoltre \errval{ENOMEM}.}
\end{functions}
La funzione inserisce un segmento di memoria condivisa all'interno dello
sola scrittura.
In caso di successo la funzione aggiorna anche i seguenti campi di
-\var{shmid\_ds}:
+\struct{shmid\_ds}:
\begin{itemize*}
\item il tempo \var{shm\_atime} dell'ultima operazione di aggancio viene
impostato al tempo corrente.
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 è:
+dell'interfaccia, \funcd{shmdt}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/shm.h}
\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
- \const{EINVAL}.}
+ \errval{EINVAL}.}
\end{functions}
La funzione sgancia dallo spazio degli indirizzi del processo un segmento di
agganciato al processo.
In caso di successo la funzione aggiorna anche i seguenti campi di
-\var{shmid\_ds}:
+\struct{shmid\_ds}:
\begin{itemize*}
\item il tempo \var{shm\_dtime} dell'ultima operazione di sganciamento viene
impostato al tempo corrente.
inoltre la regione di indirizzi usata per il segmento di memoria condivisa
viene tolta dallo spazio di indirizzi del processo.
+Benché la memoria condivisa costituisca il meccanismo di intercomunicazione
+fra processi più veloce, essa non è sempre il più appropriato, dato che, come
+abbiamo visto, si avrà comunque la necessità di una sincronizzazione degli
+accessi. Per questo motivo, quando la comunicazione fra processi è
+sequenziale, altri meccanismi come le pipe, le fifo o i socket, che non
+necessitano di sincronizzazione esplicita, sono da preferire. Essa diventa
+l'unico meccanismo possibile quando la comunicazione non è
+sequenziale\footnote{come accennato in \secref{sec:ipc_sysv_mq} per la
+ comunicazione non sequenziale si possono usare le code di messaggi,
+ attraverso l'uso del campo \var{mtype}, ma solo se quest'ultima può essere
+ effettuata in forma di messaggio.} o quando non può avvenire secondo una
+modalità predefinita.
+
+Un esempio classico di uso della memoria condivisa è quello del
+``\textit{monitor}'', in cui essa viene per scambiare informazioni fra un
+processo ``server'' che vi scrive dei dati di interesse generale che ha
+ottenuto, e tutti i processi ``client'' interessati agli stessi dati che così
+possono leggerli in maniera completamente asincrona. Con questo schema di
+funzionamento da una parte si evita che ciascun processo ``client'' debba
+compiere l'operazione, potenzialmente onerosa, di ricavare e trattare i dati,
+e dall'altra si evita al processo ``server'' di dover gestire l'invio a tutti
+i client di tutti i dati (non potendo il server sapere quali di essi servono
+effettivamente al singolo client).
+
+Nel nostro caso implementeremo un ``monitor'' di una directory: un processo si
+incaricherà di tenere sotto controllo alcuni parametri relativi ad una
+directory (il numero dei file contenuti, la dimensione totale, ecc.) che
+saranno salvati in un segmento di memoria condivisa cui altri processi
+potranno accedere per ricavare la parte di informazione che interessa.
+
+
+
%% Per capire meglio il funzionamento delle funzioni facciamo ancora una volta
%% riferimento alle strutture con cui il kernel implementa i segmenti di memoria
\label{sec:ipc_alternatives}
Come abbiamo detto in \secref{sec:ipc_sysv_generic}, e ripreso nella
-descrizione dei signoli oggetti che ne fan parte, il \textit{SysV IPC}
+descrizione dei singoli oggetti che ne fan parte, il \textit{SysV IPC}
presenta numerosi problemi; in \cite{APUE}\footnote{in particolare nel
- capitolo 14.} Stevens ne eeffettua una accurata analisi (alcuni dei
+ capitolo 14.} Stevens ne effettua una accurata analisi (alcuni dei
concetti sono già stati accennati in precedenza) ed elenca alcune possibili
tecniche alternative, che vogliamo riprendere in questa sezione.
Le code di messaggi sono probabilmente il meno usato degli oggetti del
\textit{SysV IPC}; esse infatti nacquero principalmente come meccanismo di
comunicazione bidirezionale quando ancora le pipe erano unidirezionali; con la
-disponibilità di \func{socketpair} (vedi \secref{sec:ipc_socketpair}) si può
-ottenere lo stesso risultato senza incorrere nelle complicazioni introdotte
-dal \textit{SysV IPC}.
+disponibilità di \func{socketpair} (vedi \secref{sec:ipc_socketpair}) o
+utilizzando una coppia di pipe, si può ottenere questo risultato senza
+incorrere nelle complicazioni introdotte dal \textit{SysV IPC}.
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
-combinato della memoria condivisa e dei meccanismi di sincronizzazione, per
-cui alla fine l'uso delle code di messaggi classiche è poco diffuso.
+sono impossibili da ottenere con le pipe e i socket\index{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 è
+relativamente poco diffuso.
\subsection{I \textsl{file di lock}}
\label{sec:ipc_file_lock}
+\index{file!di lock|(}
Come illustrato in \secref{sec:ipc_sysv_sem} i semafori del \textit{SysV IPC}
presentano una interfaccia inutilmente complessa e con alcuni difetti
strutturali, per questo quando si ha una semplice esigenza di sincronizzazione
alternativi.
La prima possibilità, utilizzata fin dalle origini di Unix, è quella di usare
-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
+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
\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
(la funzione viene eseguita, ma non è garantita l'atomicità dell'operazione)
se il filesystem su cui si va ad operare è su NFS; in tal caso si può adottare
una tecnica alternativa che prevede l'uso della \func{link} per creare come
-file di lock un hard link ad un file esistente; se il link esiste già e la
-funzione fallisce, significa che la risorsa è bloccata e potrà essere
+\textsl{file di lock} un hard link ad un file 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; la soluzione
funziona anche su NFS, ma ha un'altro difetto è che è quello di poterla usare
Un generale comunque l'uso di un \textsl{file di lock} presenta parecchi
problemi, che non lo rendono una alternativa praticabile per la
sincronizzazione: anzitutto anche in questo caso, in caso di terminazione
-imprevista del processo, si lascia allocata la risorsa (il file di lock) e
-questa deve essere sempre cancellata esplicitamente. Inoltre il controllo
-della disponibilità può essere eseguito solo con una tecnica di
+imprevista del processo, si lascia allocata la risorsa (il \textsl{file di
+ lock}) e questa deve essere sempre cancellata esplicitamente. Inoltre il
+controllo della disponibilità può essere eseguito solo con una tecnica di
\textit{polling}\index{polling}, ed è quindi molto inefficiente.
La tecnica dei file di lock non di meno ha una sua utilità, e può essere usata
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 si trovi un file di lock il programma che cerca di
-accedere alla seriale si limita a segnalare che la risorsa non è disponibile.
+accedere alla seriale si limita a segnalare che la risorsa non è
+disponibile.\index{file!di lock|)}
\subsection{La sincronizzazione con il \textit{file locking}}
\label{sec:ipc_lock_file}
Dato che i file di lock presentano gli inconvenienti illustrati in precedenza,
la tecnica alternativa più comune è quella di fare ricorso al \textit{file
- locking} (trattato in \secref{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 \textit{polling}\index{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.
+ locking}\index{file!locking} (trattato in \secref{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
+\textit{polling}\index{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
\end{minipage}
\normalsize
\caption{Il codice delle funzioni che permettono di creare un
- \textit{mutex} utilizzando il file locking.}
+ \textit{mutex} utilizzando il file locking\index{file!locking}.}
\label{fig:ipc_flock_mutex}
\end{figure}
-Il codice per implementare un mutex utilizzando il file locking è riportato in
-\figref{fig:ipc_flock_mutex}; a differenza del precedente caso in cui si sono
-usati i semafori le funzioni questa volta sono sufficienti due funzioni,
-\func{LockMutex} e \func{UnlockMutex}, usate rispettivamente per acquisire e
-rilasciare il mutex.
+Il codice per implementare un mutex utilizzando il file
+locking\index{file!locking} è riportato in \figref{fig:ipc_flock_mutex}; a
+differenza del precedente caso in cui si sono usati i semafori le funzioni
+questa volta sono sufficienti due funzioni, \func{LockMutex} e
+\func{UnlockMutex}, usate rispettivamente per acquisire e rilasciare il mutex.
La prima funzione (\texttt{\small 1--22}) serve per acquisire il mutex.
Anzitutto si apre (\texttt{\small 9--11}), creandolo se non esiste, il file
specificato dall'argomento \param{pathname}. In caso di errore si ritorna
immediatamente, altrimenti si prosegue impostando (\texttt{\small 12--16}) la
-struttura \var{lock} in modo da poter acquisire un write lock sul file. Infine
-si richiede (\texttt{\small 17--20}) il file lock (restituendo il codice di
-ritorno di \func{fcntl} caso di errore). Se il file è libero il lock è
-acquisito e la funzione ritorna immediatamente; altrimenti \func{fcntl} si
+struttura \var{lock} in modo da poter acquisire un write lock sul file.
+Infine si richiede (\texttt{\small 17--20}) il file lock (restituendo il
+codice di ritorno di \func{fcntl} caso di errore). Se il file è libero il lock
+è acquisito e la funzione ritorna immediatamente; altrimenti \func{fcntl} si
bloccherà (si noti che la si è chiamata con \func{F\_SETLKW}) fino al rilascio
del lock.
\file{/dev/zero}. In tal caso i valori scritti nella regione mappata non
vengono ignorati (come accade qualora si scriva direttamente sul file), ma
restano in memoria e possono essere riletti secondo le stesse modalità usate
- nele \textit{memory mapping} anonimo.} Un esempio di utilizzo di questa
+ nel \textit{memory mapping} anonimo.} Un esempio di utilizzo di questa
tecnica è mostrato in
\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.
+Le code di messaggi non sono ancora supportate nel kernel
+ufficiale;\footnote{esiste però una proposta di implementazione di Krzysztof
+ Benedyczak, a partire dal kernel 2.5.50.} inoltre esse possono essere
+implementate, usando la memoria condivisa ed i mutex, con funzioni di
+libreria. In generale, come le corrispettive del SysV IPC, sono poco usate,
+dato che i socket\index{socket}, nei casi in cui sono sufficienti, sono più
+comodi, e negli altri casi la comunicazione può essere gestita direttamente
+con mutex e memoria condivisa. Per questo ci limiteremo ad una descrizione
+essenziale.
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
+implementa solo a livello di thread e non di processi. Esiste un'altra
+versione, realizzata da Konstantin Knizhnik, che reimplementa l'interfaccia
+POSIX usando i semafori di SysV IPC.
\subsection{Memoria condivisa}