Correzioni alle funzioni di locking
[gapil.git] / ipc.tex
diff --git a/ipc.tex b/ipc.tex
index 0409edda7d80a3e657048bc702bae4859175eb1c..6cb8cc482a4bdbd2811d480609a84c2f882b8854 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -1,3 +1,13 @@
+%% ipc.tex
+%%
+%% Copyright (C) 2000-2002 Simone Piccardi.  Permission is granted to
+%% copy, distribute and/or modify this document under the terms of the GNU Free
+%% Documentation License, Version 1.1 or any later version published by the
+%% Free Software Foundation; with the Invariant Sections being "Prefazione",
+%% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
+%% license is included in the section entitled "GNU Free Documentation
+%% License".
+%%
 \chapter{La comunicazione fra processi}
 \label{cha:IPC}
 
@@ -39,15 +49,15 @@ due file descriptor, nella forma di un \textsl{tubo} (da cui il nome)
 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 \macro{EMFILE},
-    \macro{ENFILE} e \macro{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
@@ -56,7 +66,7 @@ accennato concetto di funzionamento di una pipe 
 scrive nel file descriptor aperto in scrittura viene ripresentato tale e quale
 nel file descriptor aperto in lettura. I file descriptor infatti non sono
 connessi a nessun file reale, ma ad un buffer nel kernel, la cui dimensione è
-specificata dal parametro di sistema \macro{PIPE\_BUF}, (vedi
+specificata dal parametro di sistema \const{PIPE\_BUF}, (vedi
 \secref{sec:sys_file_limits}). Lo schema di funzionamento di una pipe è
 illustrato in \figref{fig:ipc_pipe_singular}, in cui sono illustrati i due
 capi della pipe, associati a ciascun file descriptor, con le frecce che
@@ -102,11 +112,11 @@ essere bloccante (qualora non siano presenti dati), inoltre se si legge da una
 pipe il cui capo in scrittura è stato chiuso, si avrà la ricezione di un EOF
 (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 \macro{EPIPE}, e la funzione di scrittura
-restituirà un errore di \macro{EPIPE} (al ritorno del manipolatore, o qualora
-il segnale sia ignorato o bloccato).
+processo riceverà il segnale \errcode{EPIPE}, e la funzione di scrittura
+restituirà un errore di \errcode{EPIPE} (al ritorno del gestore, o qualora il
+segnale sia ignorato o bloccato).
 
-La dimensione del buffer della pipe (\macro{PIPE\_BUF}) ci dà inoltre un'altra
+La dimensione del buffer della pipe (\const{PIPE\_BUF}) ci dà inoltre un'altra
 importante informazione riguardo il comportamento delle operazioni di lettura
 e scrittura su di una pipe; esse infatti sono atomiche fintanto che la
 quantità di dati da scrivere non supera questa dimensione. Qualora ad esempio
@@ -140,7 +150,7 @@ possa reinviarlo al browser che ha effettuato la richiesta, che in questo modo
 è in grado di visualizzarlo opportunamente.
 
 Per realizzare quanto voluto useremo in sequenza i programmi \cmd{barcode} e
-\cmd{gs}, il primo infatti è in grado di generare immagini postscript di
+\cmd{gs}, il primo infatti è in grado di generare immagini PostScript di
 codici a barre corrispondenti ad una qualunque stringa, mentre il secondo
 serve per poter effettuare la conversione della stessa immagine in formato
 JPEG. Usando una pipe potremo inviare l'output del primo sull'input del
@@ -159,13 +169,13 @@ direzione del flusso dei dati 
 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
@@ -249,7 +259,7 @@ richiesta.\footnote{la funzione \func{WriteMess} non 
 Una volta create le pipe, il programma può creare (\texttt{\small 13-17}) il
 primo processo figlio, che si incaricherà (\texttt{\small 19--25}) di eseguire
 \cmd{barcode}. Quest'ultimo legge dallo standard input una stringa di
-caratteri, la converte nell'immagine postscript del codice a barre ad essa
+caratteri, la converte nell'immagine PostScript del codice a barre ad essa
 corrispondente, e poi scrive il risultato direttamente sullo standard output.
 
 Per poter utilizzare queste caratteristiche prima di eseguire \cmd{barcode} si
@@ -258,7 +268,7 @@ ne collega (\texttt{\small 21}) il capo in lettura allo standard input, usando
 \func{dup2}. Si ricordi che invocando \func{dup2} il secondo file, qualora
 risulti aperto, viene, come nel caso corrente, chiuso prima di effettuare la
 duplicazione. Allo stesso modo, dato che \cmd{barcode} scrive l'immagine
-postscript del codice a barre sullo standard output, per poter effettuare una
+PostScript del codice a barre sullo standard output, per poter effettuare una
 ulteriore redirezione il capo in lettura della seconda pipe viene chiuso
 (\texttt{\small 22}) mentre il capo in scrittura viene collegato allo standard
 output (\texttt{\small 23}).
@@ -266,7 +276,7 @@ output (\texttt{\small 23}).
 In questo modo all'esecuzione (\texttt{\small 25}) di \cmd{barcode} (cui si
 passa in \var{size} la dimensione della pagina per l'immagine) quest'ultimo
 leggerà dalla prima pipe la stringa da codificare che gli sarà inviata dal
-padre, e scriverà l'immagine postscript del codice a barre sulla seconda.
+padre, e scriverà l'immagine PostScript del codice a barre sulla seconda.
 
 Al contempo una volta lanciato il primo figlio, il processo padre prima chiude
 (\texttt{\small 26}) il capo inutilizzato della prima pipe (quello in input) e
@@ -277,11 +287,11 @@ definitivamente chiusa (\texttt{\small 28}), si attende poi (\texttt{\small
   29}) che l'esecuzione di \cmd{barcode} sia completata.
 
 Alla conclusione della sua esecuzione \cmd{barcode} avrà inviato l'immagine
-postscript del codice a barre sul capo in scrittura della seconda pipe; a
+PostScript del codice a barre sul capo in scrittura della seconda pipe; a
 questo punto si può eseguire la seconda conversione, da PS a JPEG, usando il
 programma \cmd{gs}. Per questo si crea (\texttt{\small 30--34}) un secondo
 processo figlio, che poi (\texttt{\small 35--42}) eseguirà questo programma
-leggendo l'immagine postscript creata da \cmd{barcode} dallo standard input,
+leggendo l'immagine PostScript creata da \cmd{barcode} dallo standard input,
 per convertirla in JPEG.
 
 Per fare tutto ciò anzitutto si chiude (\texttt{\small 37}) il capo in
@@ -312,7 +322,7 @@ Come si 
 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)}
 
@@ -321,9 +331,9 @@ restituisce, lo standard input o lo standard output nella pipe collegata allo
 stream restituito come valore di ritorno.
   
 \bodydesc{La funzione restituisce l'indirizzo dello stream associato alla pipe
-  in caso di successo e \macro{NULL} per un errore, nel qual caso \var{errno}
+  in caso di successo e \val{NULL} per un errore, nel qual caso \var{errno}
   potrà assumere i valori relativi alle sottostanti invocazioni di \func{pipe}
-  e \func{fork} o \macro{EINVAL} se \param{type} non è valido.}
+  e \func{fork} o \errcode{EINVAL} se \param{type} non è valido.}
 \end{prototype}
 
 La funzione crea una pipe, esegue una \func{fork}, ed invoca il programma
@@ -338,11 +348,11 @@ programma indicato) in caso si sia indicato \code{"r"}, o in sola scrittura (e
 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)}
 
@@ -350,7 +360,7 @@ Chiude il file \param{stream}, restituito da una precedente \func{popen}
 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
@@ -362,8 +372,8 @@ precedente: il programma mostrato in \figref{fig:ipc_barcodepage_code} per
 quanto funzionante, è (volutamente) codificato in maniera piuttosto complessa,
 inoltre nella pratica sconta un problema di \cmd{gs} che non è in
 grado\footnote{nella versione GNU Ghostscript 6.53 (2002-02-13).} di
-riconoscere correttamente l'encapsulated postscript, per cui deve essere usato
-il postscript e tutte le volte viene generata una pagina intera, invece che
+riconoscere correttamente l'Encapsulated PostScript, per cui deve essere usato
+il PostScript e tutte le volte viene generata una pagina intera, invece che
 una immagine delle dimensioni corrispondenti al codice a barre.
 
 Se si vuole generare una immagine di dimensioni appropriate si deve usare un
@@ -376,12 +386,12 @@ originarie del codice a barre e produce un JPEG di dimensioni corrette.
 Questo approccio però non funziona, per via di una delle caratteristiche
 principali delle pipe. Per poter effettuare la conversione di un PDF infatti è
 necessario, per la struttura del formato, potersi spostare (con \func{lseek})
-all'interno del file da convertire; se si esegue la conversione con \cmd{gs} su
-un file regolare non ci sono problemi, una pipe però è rigidamente
+all'interno del file da convertire; se si esegue la conversione con \cmd{gs}
+su un file regolare non ci sono problemi, una pipe però è rigidamente
 sequenziale, e l'uso di \func{lseek} su di essa fallisce sempre con un errore
-di \macro{ESPIPE}, rendendo impossibile la conversione.  Questo ci dice che in
-generale la concatenazione di vari programmi funzionerà soltanto quando tutti
-prevedono una lettura sequenziale del loro input.
+di \errcode{ESPIPE}, rendendo impossibile la conversione.  Questo ci dice che
+in generale la concatenazione di vari programmi funzionerà soltanto quando
+tutti prevedono una lettura sequenziale del loro input.
 
 Per questo motivo si è dovuto utilizzare un procedimento diverso, eseguendo
 prima la conversione (sempre con \cmd{gs}) del PS in un altro formato
@@ -426,7 +436,7 @@ int main(int argc, char *argv[], char *envp[])
     };  
     char content[]="Content-type: image/png\n\n";
     int i;
-    /* write mime-type to stout */ 
+    /* write mime-type to stdout */ 
     write(STDOUT_FILENO, content, strlen(content));
     /* execute chain of command */
     for (i=0; i<4; i++) {
@@ -483,15 +493,16 @@ nella relazione padre/figlio; per superare questo problema lo standard POSIX.1
 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
@@ -508,7 +519,7 @@ eseguita quando l'altro capo non 
 Le fifo però possono essere anche aperte in modalità \textsl{non-bloccante},
 nel qual caso l'apertura del capo in lettura avrà successo solo quando anche
 l'altro capo è aperto, mentre l'apertura del capo in scrittura restituirà
-l'errore di \macro{ENXIO} fintanto che non verrà aperto il capo in lettura.
+l'errore di \errcode{ENXIO} fintanto che non verrà aperto il capo in lettura.
 
 In Linux è possibile aprire le fifo anche in lettura/scrittura,\footnote{lo
   standard POSIX lascia indefinito il comportamento in questo caso.}
@@ -518,15 +529,15 @@ comunque una fifo in scrittura anche se non ci sono ancora processi il
 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
 situazioni un processo deve ricevere informazioni da altri. In questo caso è
 fondamentale che le operazioni di scrittura siano atomiche; per questo si deve
 sempre tenere presente che questo è vero soltanto fintanto che non si supera
-il limite delle dimensioni di \macro{PIPE\_BUF} (si ricordi quanto detto in
+il limite delle dimensioni di \const{PIPE\_BUF} (si ricordi quanto detto in
 \secref{sec:ipc_pipes}).
 
 A parte il caso precedente, che resta probabilmente il più comune, Stevens
@@ -551,8 +562,8 @@ 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
+``\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
@@ -683,7 +694,7 @@ effettuando richieste) con la fifo chiusa sul lato in lettura e a questo punto
 restituendo un end-of-file.\footnote{Si è usata questa tecnica per
   compatibilità, Linux infatti supporta l'apertura delle fifo in
   lettura/scrittura, per cui si sarebbe potuto effettuare una singola apertura
-  con \macro{O\_RDWR}, la doppia apertura comunque ha il vantaggio che non si
+  con \const{O\_RDWR}, la doppia apertura comunque ha il vantaggio che non si
   può scrivere per errore sul capo aperto in sola lettura.}
 
 Per questo motivo, dopo aver eseguito l'apertura in lettura (\texttt{\small
@@ -782,7 +793,7 @@ Inoltrata la richiesta si pu
 si apre (\texttt{\small 26--30}) la fifo appena creata, da cui si deve
 riceverla, dopo di che si effettua una lettura (\texttt{\small 31})
 nell'apposito buffer; si è supposto, come è ragionevole, che le frasi inviate
-dal server siano sempre di dimensioni inferiori a \macro{PIPE\_BUF},
+dal server siano sempre di dimensioni inferiori a \const{PIPE\_BUF},
 tralasciamo la gestione del caso in cui questo non è vero. Infine si stampa
 (\texttt{\small 32}) a video la risposta, si chiude (\texttt{\small 33}) la
 fifo e si cancella (\texttt{\small 34}) il relativo file.
@@ -796,7 +807,7 @@ complessa e continua ad avere vari inconvenienti\footnote{lo stesso Stevens,
   che esamina questa architettura in \cite{APUE}, nota come sia impossibile
   per il server sapere se un client è andato in crash, con la possibilità di
   far restare le fifo temporanee sul filesystem, di come sia necessario
-  intercettare \macro{SIGPIPE} dato che un client può terminare dopo aver
+  intercettare \const{SIGPIPE} dato che un client può terminare dopo aver
   fatto una richiesta, ma prima che la risposta sia inviata (cosa che nel
   nostro esempio non è stata fatta).}; in generale infatti l'interfaccia delle
 fifo non è adatta a risolvere questo tipo di problemi, che possono essere
@@ -813,10 +824,10 @@ come quelli che esamineremo in seguito.
 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
@@ -825,47 +836,48 @@ una modalit
   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[\macro{EAFNOSUPPORT}] I socket locali non sono supportati.
-  \item[\macro{EPROTONOSUPPORT}] Il protocollo specificato non è supportato.
-  \item[\macro{EOPNOTSUPP}] Il protocollo specificato non supporta la
-  creazione di coppie di socket.
+  \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\index{socket}.
   \end{errlist}
-  ed inoltre \macro{EMFILE},  \macro{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
-\macro{AF\_UNIX}, \macro{SOCK\_STREAM} e \macro{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}
@@ -915,7 +927,7 @@ non 
 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
@@ -943,7 +955,8 @@ struct ipc_perm
     \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}
 
@@ -964,9 +977,9 @@ alternativa pi
 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} 
@@ -991,12 +1004,12 @@ significativi.\footnote{nelle libc4 e libc5, come avviene in SunOS,
 
 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
@@ -1005,7 +1018,7 @@ le chiavi che interessano. In ogni caso occorre sempre controllare, prima di
 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.
 
@@ -1022,7 +1035,7 @@ effettuata una revisione completa nello standard POSIX.1b, che tratteremo in
 \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,
@@ -1036,16 +1049,16 @@ propriamente un permesso di modifica). I valori di \var{mode} sono gli stessi
 ed hanno lo stesso significato di quelli riportati in
 \secref{tab:file_mode_flags}\footnote{se però si vogliono usare le costanti
   simboliche ivi definite occorrerà includere il file \file{sys/stat.h},
-  alcuni sistemi definiscono le costanti \macro{MSG\_R} (\texttt{0400}) e
-  \macro{MSG\_W} (\texttt{0200}) per indicare i permessi base di lettura e
+  alcuni sistemi definiscono le costanti \const{MSG\_R} (\texttt{0400}) e
+  \const{MSG\_W} (\texttt{0200}) per indicare i permessi base di lettura e
   scrittura per il proprietario, da utilizzare, con gli opportuni shift, pure
   per il gruppo e gli altri, in Linux, visto la loro scarsa utilità, queste
   costanti non sono definite.} e come per i file definiscono gli accessi per
 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
-rispettivamente al valore dell'userid e del groupid effettivo del processo che
+\struct{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono settati
+rispettivamente al valore dell'user-ID e del group-ID 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.
 
@@ -1065,12 +1078,12 @@ controlli 
 \begin{itemize}
 \item se il processo ha i privilegi di amministratore l'accesso è sempre
   consentito. 
-\item se l'userid effettivo del processo corrisponde o al valore del campo
+\item se l'user-ID effettivo del processo corrisponde o al valore del campo
   \var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario
   in \var{mode} è appropriato\footnote{per appropriato si intende che è
     settato il permesso di scrittura per le operazioni di scrittura e quello
     di lettura per le operazioni di lettura.} l'accesso è consentito.
-\item se il groupid effettivo del processo corrisponde o al
+\item se il group-ID effettivo del processo corrisponde o al
   valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso
   per il gruppo in \var{mode} è appropriato l'accesso è consentito.
 \item se il permesso per gli altri è appropriato l'accesso è consentito.
@@ -1086,7 +1099,7 @@ il valore di \var{umask} (si ricordi quanto esposto in
 \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
@@ -1109,18 +1122,18 @@ facciano in tempo ad accorgersi dell'avvenuto, e finiscano con l'interagire
 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 sistema dispone sempre di un numero fisso di oggetti di IPC,\footnote{fino
-  al kernel 2.2.x questi valori, definiti dalle costanti \macro{MSGMNI},
-  \macro{SEMMNI} e \macro{SHMMNI}, potevano essere cambiati (come tutti gli
+  al kernel 2.2.x questi valori, definiti dalle costanti \const{MSGMNI},
+  \const{SEMMNI} e \const{SHMMNI}, potevano essere cambiati (come tutti gli
   altri limiti relativi al \textit{SysV IPC}) solo con una ricompilazione del
   kernel, andando a modificarne la definizione nei relativi header file.  A
   partire dal kernel 2.4.x è possibile cambiare questi valori a sistema attivo
   scrivendo sui file \file{shmmni}, \file{msgmni} e \file{sem} di
-  \file{/proc/sys/kernel} o con l'uso di \texttt{syscntl}.} e per ciascuno di
+  \file{/proc/sys/kernel} o con l'uso di \func{sysctl}.} e per ciascuno di
 essi viene mantenuto in \var{seq} un numero di sequenza progressivo che viene
 incrementato di uno ogni volta che l'oggetto viene cancellato. Quando
 l'oggetto viene creato usando uno spazio che era già stato utilizzato in
@@ -1128,7 +1141,7 @@ precedenza per restituire l'identificatore al numero di oggetti presenti viene
 sommato il valore di \var{seq} moltiplicato per il numero massimo di oggetti
 di quel tipo,\footnote{questo vale fino ai kernel della serie 2.2.x, dalla
   serie 2.4.x viene usato lo stesso fattore per tutti gli oggetti, esso è dato
-  dalla costante \macro{IPCMNI}, definita in \file{include/linux/ipc.h}, che
+  dalla costante \const{IPCMNI}, definita in \file{include/linux/ipc.h}, che
   indica il limite massimo per il numero di tutti oggetti di IPC, ed il cui
   valore è 32768.}  si evita così il riutilizzo degli stessi numeri, e si fa
 sì che l'identificatore assuma tutti i valori possibili.
@@ -1219,8 +1232,12 @@ mantenuta staticamente all'interno del sistema.
 
 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} 
@@ -1233,18 +1250,18 @@ una 
   \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
     in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\macro{EACCES}] Il processo chiamante non ha i privilegi per accedere
+  \item[\errcode{EACCES}] Il processo chiamante non ha i privilegi per accedere
   alla coda richiesta.  
-  \item[\macro{EEXIST}] Si è richiesta la creazione di una coda che già
-  esiste, ma erano specificati sia \macro{IPC\_CREAT} che \macro{IPC\_EXCL}. 
-  \item[\macro{EIDRM}] La coda richiesta è marcata per essere cancellata.
-  \item[\macro{ENOENT}] Si è cercato di ottenere l'identificatore di una coda
-    di messaggi specificando una chiave che non esiste e \macro{IPC\_CREAT}
+  \item[\errcode{EEXIST}] Si è richiesta la creazione di una coda che già
+  esiste, ma erano specificati sia \const{IPC\_CREAT} che \const{IPC\_EXCL}. 
+  \item[\errcode{EIDRM}] La coda richiesta è marcata per essere cancellata.
+  \item[\errcode{ENOENT}] Si è cercato di ottenere l'identificatore di una coda
+    di messaggi specificando una chiave che non esiste e \const{IPC\_CREAT}
     non era specificato.
-  \item[\macro{ENOSPC}] Si è cercato di creare una coda di messaggi quando è
-    stato superato il limite massimo di code (\macro{MSGMNI}).
+  \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 \macro{ENOMEM}.
+  ed inoltre \errval{ENOMEM}.
 }
 \end{functions}
 
@@ -1252,33 +1269,34 @@ Le funzione (come le analoghe che si usano per gli altri oggetti) serve sia a
 ottenere l'identificatore di una coda di messaggi esistente, che a crearne una
 nuova. L'argomento \param{key} specifica la chiave che è associata
 all'oggetto, eccetto il caso in cui si specifichi il valore
-\macro{IPC\_PRIVATE}, nel qual caso la coda è creata ex-novo e non vi è
+\const{IPC\_PRIVATE}, nel qual caso la coda è creata ex-novo e non vi è
 associata alcuna chiave, il processo (ed i suoi eventuali figli) potranno
 farvi riferimento solo attraverso l'identificatore.
 
-Se invece si specifica un valore diverso da \macro{IPC\_PRIVATE}\footnote{in
+Se invece si specifica un valore diverso da \const{IPC\_PRIVATE}\footnote{in
   Linux questo significa un valore diverso da zero.} l'effetto della funzione
 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 \macro{ENOENT} se non
-esiste o di \macro{EACCESS} se si sono specificati dei permessi non validi.
+se trova una corrispondenza, o fallendo con un errore di \errcode{ENOENT} se
+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ò
 essere nullo e deve essere fornito come maschera binaria, impostando il bit
-corrispondente al valore \macro{IPC\_CREAT}. In questo caso i nove bit meno
+corrispondente al valore \const{IPC\_CREAT}. In questo caso i nove bit meno
 significativi di \param{flag} saranno usati come permessi per il nuovo
 oggetto, secondo quanto illustrato in \secref{sec:ipc_sysv_access_control}.
-Se si imposta anche il bit corrispondente a \macro{IPC\_EXCL} la funzione avrà
+Se si imposta anche il bit corrispondente a \const{IPC\_EXCL} la funzione avrà
 successo solo se l'oggetto non esiste già, fallendo con un errore di
-\macro{EEXIST} altrimenti.
+\errcode{EEXIST} altrimenti.
 
-Si tenga conto che l'uso di \macro{IPC\_PRIVATE} non impedisce ad altri
+Si tenga conto che l'uso di \const{IPC\_PRIVATE} non impedisce ad altri
 processi di accedere alla coda (se hanno privilegi sufficienti) una volta che
 questi possano indovinare o ricavare (ad esempio per tentativi)
 l'identificatore ad essa associato. Per come sono implementati gli oggetti di
 IPC infatti non esiste una maniera che  garantisca l'accesso esclusivo ad una
-coda di messaggi.  Usare \macro{IPC\_PRIVATE} o macro{IPC\_CREAT} e
-\macro{IPC\_EXCL} per \param{flag} comporta solo la creazione di una nuova
+coda di messaggi.  Usare \const{IPC\_PRIVATE} o const{IPC\_CREAT} e
+\const{IPC\_EXCL} per \param{flag} comporta solo la creazione di una nuova
 coda.
 
 \begin{table}[htb]
@@ -1290,11 +1308,11 @@ coda.
     & \textbf{Significato} \\
     \hline
     \hline
-    \macro{MSGMNI}&   16& \file{msgmni} & Numero massimo di code di
+    \const{MSGMNI}&   16& \file{msgmni} & Numero massimo di code di
                                           messaggi. \\
-    \macro{MSGMAX}& 8192& \file{msgmax} & Dimensione massima di un singolo
+    \const{MSGMAX}& 8192& \file{msgmax} & Dimensione massima di un singolo
                                           messaggio.\\
-    \macro{MSGMNB}&16384& \file{msgmnb} & Dimensione massima del contenuto di 
+    \const{MSGMNB}&16384& \file{msgmnb} & Dimensione massima del contenuto di 
                                           una coda.\\
     \hline
   \end{tabular}
@@ -1305,7 +1323,7 @@ coda.
 Le code di messaggi sono caratterizzate da tre limiti fondamentali, definiti
 negli header e corrispondenti alle prime tre costanti riportate in
 \tabref{tab:ipc_msg_limits}, come accennato però in Linux è possibile
-modificare questi limiti attraverso l'uso di \func{syscntl} o scrivendo nei
+modificare questi limiti attraverso l'uso di \func{sysctl} o scrivendo nei
 file \file{msgmax}, \file{msgmnb} e \file{msgmni} di \file{/proc/sys/kernel/}.
 
 
@@ -1353,21 +1371,21 @@ struct msqid_ds {
     \end{lstlisting}
   \end{minipage} 
   \normalsize 
-  \caption{La struttura \var{msgid\_ds}, associata a ciascuna coda di
+  \caption{La struttura \structd{msqid\_ds}, associata a ciascuna coda di
     messaggi.}
-  \label{fig:ipc_msgid_ds}
+  \label{fig:ipc_msqid_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_msqid_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
   sia una differenza con i campi mostrati nello schema di
   \figref{fig:ipc_mq_schema} che sono presi dalla definizione di
   \file{linux/msg.h}, e fanno riferimento alla definizione della omonima
-  struttura usata nel kernel.} In \figref{fig:ipc_msgid_ds} sono elencati i
+  struttura usata nel kernel.} In \figref{fig:ipc_msqid_ds} sono elencati i
 campi significativi definiti in \file{sys/msg.h}, a cui si sono aggiunti gli
 ultimi tre campi che sono previsti dalla implementazione originale di System
 V, ma non dallo standard Unix98.
@@ -1389,16 +1407,16 @@ gli altri campi invece:
   viene inizializzato al tempo corrente.
 \item il campo \var{msg\_qbytes} che esprime la dimensione massima del
   contenuto della coda (in byte) viene inizializzato al valore preimpostato
-  del sistema (\macro{MSGMNB}).
+  del sistema (\const{MSGMNB}).
 \item i campi \var{msg\_first} e \var{msg\_last} che esprimono l'indirizzo del
-  primo e ultimo messaggio sono inizializzati a \macro{NULL} e
+  primo e ultimo messaggio sono inizializzati a \val{NULL} e
   \var{msg\_cbytes}, che esprime la dimensione in byte dei messaggi presenti è
   inizializzato a zero. Questi campi sono ad uso interno dell'implementazione
   e non devono essere utilizzati da programmi in user space).
 \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}
@@ -1413,47 +1431,47 @@ prototipo 
   \bodydesc{La funzione restituisce 0 in caso di successo o -1 in caso di
     errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\macro{EACCES}] Si è richiesto \macro{IPC\_STAT} ma processo chiamante
-    non ha i privilegi di lettura sulla coda.
-  \item[\macro{EIDRM}] La coda richiesta è stata cancellata.
-  \item[\macro{EPERM}] Si è richiesto \macro{IPC\_SET} o \macro{IPC\_RMID} ma
+  \item[\errcode{EACCES}] Si è richiesto \const{IPC\_STAT} ma processo
+    chiamante non ha i privilegi di lettura sulla coda.
+  \item[\errcode{EIDRM}] La coda richiesta è stata cancellata.
+  \item[\errcode{EPERM}] Si è richiesto \const{IPC\_SET} o \const{IPC\_RMID} ma
     il processo non ha i privilegi, o si è richiesto di aumentare il valore di
-    \var{msg\_qbytes} oltre il limite \macro{MSGMNB} senza essere
+    \var{msg\_qbytes} oltre il limite \const{MSGMNB} senza essere
     amministratore.
   \end{errlist}
-  ed inoltre \macro{EFAULT} ed \macro{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
 eseguire; i valori possibili sono:
 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
-\item[\macro{IPC\_STAT}] Legge le informazioni riguardo la coda nella
+\item[\const{IPC\_STAT}] Legge le informazioni riguardo la coda nella
   struttura indicata da \param{buf}. Occorre avere il permesso di lettura
   sulla coda.
-\item[\macro{IPC\_RMID}] Rimuove la coda, cancellando tutti i dati, con
+\item[\const{IPC\_RMID}] Rimuove la coda, cancellando tutti i dati, con
   effetto immediato. Tutti i processi che cercheranno di accedere alla coda
-  riceveranno un errore di \macro{EIDRM}, e tutti processi in attesa su
+  riceveranno un errore di \errcode{EIDRM}, e tutti processi in attesa su
   funzioni di di lettura o di scrittura sulla coda saranno svegliati ricevendo
   il medesimo errore. Questo comando può essere eseguito solo da un processo
-  con userid effettivo corrispondente al creatore o al proprietario della
+  con user-ID effettivo corrispondente al creatore o al proprietario della
   coda, o all'amministratore.
-\item[\macro{IPC\_SET}] Permette di modificare i permessi ed il proprietario
+\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
-  incrementarne il valore a limiti superiori a \macro{MSGMNB}.
+  incrementarne il valore a limiti superiori a \const{MSGMNB}.
 \end{basedescript}
 
 
 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} 
@@ -1468,27 +1486,27 @@ messaggio su una coda si utilizza la funzione \func{msgsnd}; il suo prototipo
   \bodydesc{La funzione restituisce 0, e -1 in caso di errore, nel qual caso
     \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\macro{EACCES}] Non si hanno i privilegi di accesso sulla coda.
-  \item[\macro{EIDRM}] La coda è stata cancellata.
-  \item[\macro{EAGAIN}] Il messaggio non può essere inviato perché si è
+  \item[\errcode{EACCES}] Non si hanno i privilegi di accesso sulla coda.
+  \item[\errcode{EIDRM}] La coda è stata cancellata.
+  \item[\errcode{EAGAIN}] Il messaggio non può essere inviato perché si è
   superato il limite \var{msg\_qbytes} sul numero massimo di byte presenti
-  sulla coda, e si è richiesto \macro{IPC\_NOWAIT} in \param{flag}.
-  \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
-  \item[\macro{EINVAL}] Si è specificato un \param{msgid} invalido, o un
+  sulla coda, e si è richiesto \const{IPC\_NOWAIT} in \param{flag}.
+  \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
+  \item[\errcode{EINVAL}] Si è specificato un \param{msgid} invalido, o un
     valore non positivo per \param{mtype}, o un valore di \param{msgsz}
-    maggiore di \macro{MSGMAX}.
+    maggiore di \const{MSGMAX}.
   \end{errlist}
-  ed inoltre \macro{EFAULT} ed \macro{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 \macro{MSGMAX}.
+comunque superare il limite \const{MSGMAX}.
 
 La struttura di \figref{fig:ipc_msbuf} è comunque solo un modello, tanto che
 la definizione contenuta in \file{sys/msg.h} usa esplicitamente per il secondo
@@ -1511,7 +1529,7 @@ argomento 
 cioè \var{message} è una propria struttura che si passa alla funzione,
 \param{msgsz} dovrà essere uguale a \code{sizeof(message)-sizeof(long)}, (se
 consideriamo il caso dell'esempio in \figref{fig:ipc_msbuf}, \param{msgsz}
-dovrà essere pari a \macro{LENGTH}).
+dovrà essere pari a \const{LENGTH}).
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -1524,17 +1542,17 @@ dovr
     \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}.
@@ -1544,20 +1562,20 @@ della funzione. Di norma, quando si specifica un valore nullo, la funzione
 ritorna immediatamente a meno che si sia ecceduto il valore di
 \var{msg\_qbytes}, o il limite di sistema sul numero di messaggi, nel qual
 caso si blocca mandando il processo in stato di \textit{sleep}.  Se si
-specifica per \param{flag} il valore \macro{IPC\_NOWAIT} la funzione opera in
+specifica per \param{flag} il valore \const{IPC\_NOWAIT} la funzione opera in
 modalità non bloccante, ed in questi casi ritorna immediatamente con un errore
-di \macro{EAGAIN}.
+di \errcode{EAGAIN}.
 
-Se non si specifica \macro{IPC\_NOWAIT} la funzione resterà bloccata fintanto
+Se non si specifica \const{IPC\_NOWAIT} la funzione resterà bloccata fintanto
 che non si liberano risorse sufficienti per poter inserire nella coda il
 messaggio, nel qual caso ritornerà normalmente. La funzione può ritornare, con
 una condizione di errore anche in due altri casi: quando la coda viene rimossa
-(nel qual caso si ha un errore di \macro{EIDRM}) o quando la funzione viene
-interrotta da un segnale (nel qual caso si ha un errore di \macro{EINTR}).
+(nel qual caso si ha un errore di \errcode{EIDRM}) o quando la funzione viene
+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.
@@ -1566,7 +1584,7 @@ modificati:
 \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} 
@@ -1581,16 +1599,16 @@ La funzione che viene utilizzata per estrarre un messaggio da una coda 
     successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà uno
     dei valori:
   \begin{errlist}
-  \item[\macro{EACCES}] Non si hanno i privilegi di accesso sulla coda.
-  \item[\macro{EIDRM}] La coda è stata cancellata.
-  \item[\macro{E2BIG}] Il testo del messaggio è più lungo di \param{msgsz} e
-  non si è specificato \macro{MSG\_NOERROR} in \param{msgflg}.
-  \item[\macro{EINTR}] La funzione è stata interrotta da un segnale mentre era
-  in attesa di ricevere un messaggio.
-  \item[\macro{EINVAL}] Si è specificato un \param{msgid} invalido o un valore
-    di \param{msgsz} negativo.
+  \item[\errcode{EACCES}] Non si hanno i privilegi di accesso sulla coda.
+  \item[\errcode{EIDRM}] La coda è stata cancellata.
+  \item[\errcode{E2BIG}] Il testo del messaggio è più lungo di \param{msgsz} e
+    non si è specificato \const{MSG\_NOERROR} in \param{msgflg}.
+  \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale mentre
+    era in attesa di ricevere un messaggio.
+  \item[\errcode{EINVAL}] Si è specificato un \param{msgid} invalido o un
+    valore di \param{msgsz} negativo.
   \end{errlist}
-  ed inoltre \macro{EFAULT}.
+  ed inoltre \errval{EFAULT}.
 }
 \end{functions}
 
@@ -1598,14 +1616,14 @@ La funzione legge un messaggio dalla coda specificata, scrivendolo sulla
 struttura puntata da \param{msgp}, che dovrà avere un formato analogo a quello
 di \figref{fig:ipc_msbuf}.  Una volta estratto, il messaggio sarà rimosso dalla
 coda.  L'argomento \param{msgsz} indica la lunghezza massima del testo del
-messaggio (equivalente al valore del parametro \macro{LENGTH} nell'esempio di
+messaggio (equivalente al valore del parametro \const{LENGTH} nell'esempio di
 \figref{fig:ipc_msbuf}).
 
 Se il testo del messaggio ha lunghezza inferiore a \param{msgsz} esso viene
 rimosso dalla coda; in caso contrario, se \param{msgflg} è impostato a
-\macro{MSG\_NOERROR}, il messaggio viene troncato e la parte in eccesso viene
+\const{MSG\_NOERROR}, il messaggio viene troncato e la parte in eccesso viene
 perduta, altrimenti il messaggio non viene estratto e la funzione ritorna con
-un errore di \macro{E2BIG}.
+un errore di \errcode{E2BIG}.
 
 L'argomento \param{msgtyp} permette di restringere la ricerca ad un
 sottoinsieme dei messaggi presenti sulla coda; la ricerca infatti è fatta con
@@ -1626,24 +1644,24 @@ coda, 
 
 Il valore di \param{msgflg} permette di controllare il comportamento della
 funzione, esso può essere nullo o una maschera binaria composta da uno o più
-valori.  Oltre al precedente \macro{MSG\_NOERROR}, sono possibili altri due
-valori: \macro{MSG\_EXCEPT}, che permette, quando \param{msgtyp} è positivo,
+valori.  Oltre al precedente \const{MSG\_NOERROR}, sono possibili altri due
+valori: \const{MSG\_EXCEPT}, che permette, quando \param{msgtyp} è positivo,
 di leggere il primo messaggio nella coda con tipo diverso da \param{msgtyp}, e
-\macro{IPC\_NOWAIT} che causa il ritorno immediato della funzione quando non
+\const{IPC\_NOWAIT} che causa il ritorno immediato della funzione quando non
 ci sono messaggi sulla coda.
 
 Il comportamento usuale della funzione infatti, se non ci sono messaggi
 disponibili per la lettura, è di bloccare il processo in stato di
-\textit{sleep}. Nel caso però si sia specificato \macro{IPC\_NOWAIT} la
-funzione ritorna immediatamente con un errore \macro{ENOMSG}. Altrimenti la
+\textit{sleep}. Nel caso però si sia specificato \const{IPC\_NOWAIT} la
+funzione ritorna immediatamente con un errore \errcode{ENOMSG}. Altrimenti la
 funzione ritorna normalmente non appena viene inserito un messaggio del tipo
 desiderato, oppure ritorna con errore qualora la coda sia rimossa (con
-\var{errno} impostata a \macro{EIDRM}) o se il processo viene interrotto da un
-segnale (con \var{errno} impostata a \macro{EINTR}).
+\var{errno} impostata a \errcode{EIDRM}) o se il processo viene interrotto da
+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.
@@ -1752,11 +1770,11 @@ con \var{msgbuf\_write} (\texttt{\small 12--15}) vengono restituite le frasi.
 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
@@ -1771,7 +1789,7 @@ principale (\texttt{\small 32--41}). Questo inizia (\texttt{\small 33}) con il
 porsi in attesa di un messaggio di richiesta da parte di un client; si noti
 infatti come \func{msgrcv} richieda un messaggio con \var{mtype} uguale a 1:
 questo è il valore usato per le richieste dato che corrisponde al \acr{pid} di
-\cmd{init}, che non può essere un client. L'uso del flag \macro{MSG\_NOERROR}
+\cmd{init}, che non può essere un client. L'uso del flag \const{MSG\_NOERROR}
 è solo per sicurezza, dato che i messaggi di richiesta sono di dimensione
 fissa (e contengono solo il \acr{pid} del client).
 
@@ -1790,7 +1808,7 @@ messaggio di risposta. Si tenga conto che se la coda 
 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}).
 
@@ -1856,10 +1874,10 @@ viene interrotto dopo l'invio del messaggio di richiesta e prima della lettura
 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.
 
 
 
@@ -1904,11 +1922,11 @@ della risorsa; in generale per
 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} 
@@ -1921,19 +1939,19 @@ permette di creare o ottenere l'identificatore di un insieme di semafori 
   \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
     in caso di errore, nel qual caso \var{errno} assumerà i valori:
     \begin{errlist}
-    \item[\macro{ENOSPC}] Si è cercato di creare una insieme di semafori
+    \item[\errcode{ENOSPC}] Si è cercato di creare una insieme di semafori
       quando è stato superato o il limite per il numero totale di semafori
-      (\macro{SEMMNS}) o quello per il numero totale degli insiemi
-      (\macro{SEMMNI}) nel sistema.
-    \item[\macro{EINVAL}] L'argomento \param{nsems} è minore di zero o
+      (\const{SEMMNS}) o quello per il numero totale degli insiemi
+      (\const{SEMMNI}) nel sistema.
+    \item[\errcode{EINVAL}] L'argomento \param{nsems} è minore di zero o
       maggiore del limite sul numero di semafori per ciascun insieme
-      (\macro{SEMMSL}), o se l'insieme già esiste, maggiore del numero di
+      (\const{SEMMSL}), o se l'insieme già esiste, maggiore del numero di
       semafori che contiene.
-    \item[\macro{ENOMEM}] Il sistema non ha abbastanza memoria per poter
+    \item[\errcode{ENOMEM}] Il sistema non ha abbastanza memoria per poter
       contenere le strutture per un nuovo insieme di semafori.
     \end{errlist}
-    ed inoltre \macro{EACCES}, \macro{ENOENT}, \macro{EEXIST}, \macro{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
@@ -1953,7 +1971,7 @@ soffrono di altri due, ben pi
 Il primo difetto è che non esiste una funzione che permetta di creare ed
 inizializzare un semaforo in un'unica chiamata; occorre prima creare l'insieme
 dei semafori con \func{semget} e poi inizializzarlo con \func{semctl}, si
-perde così ogni possibilità di eseguire atomicamente questa operazione.
+perde così ogni possibilità di eseguire l'operazione atomicamente.
 
 Il secondo difetto deriva dalla caratteristica generale degli oggetti del
 \textit{SysV IPC} di essere risorse globali di sistema, che non vengono
@@ -1979,12 +1997,12 @@ struct semid_ds
     \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
@@ -2004,8 +2022,8 @@ semaforo), per quanto riguarda gli altri campi invece:
 
 
 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
@@ -2028,12 +2046,13 @@ struct sem {
     \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
@@ -2051,16 +2070,16 @@ indicano rispettivamente:
     \textbf{Costante} & \textbf{Valore} & \textbf{Significato} \\
     \hline
     \hline
-    \macro{SEMMNI}&          128 & Numero massimo di insiemi di semafori. \\
-    \macro{SEMMSL}&          250 & Numero massimo di semafori per insieme.\\
-    \macro{SEMMNS}&\macro{SEMMNI}*\macro{SEMMSL}& Numero massimo di semafori
+    \const{SEMMNI}&          128 & Numero massimo di insiemi di semafori. \\
+    \const{SEMMSL}&          250 & Numero massimo di semafori per insieme.\\
+    \const{SEMMNS}&\const{SEMMNI}*\const{SEMMSL}& Numero massimo di semafori
                                    nel sistema .\\
-    \macro{SEMVMX}&        32767 & Massimo valore per un semaforo.\\
-    \macro{SEMOPM}&           32 & Massimo numero di operazioni per chiamata a
+    \const{SEMVMX}&        32767 & Massimo valore per un semaforo.\\
+    \const{SEMOPM}&           32 & Massimo numero di operazioni per chiamata a
                                    \func{semop}. \\
-    \macro{SEMMNU}&\macro{SEMMNS}& Massimo numero di strutture di ripristino.\\
-    \macro{SEMUME}&\macro{SEMOPM}& Massimo numero di voci di ripristino.\\
-    \macro{SEMAEM}&\macro{SEMVMX}& valore massimo per l'aggiustamento
+    \const{SEMMNU}&\const{SEMMNS}& Massimo numero di strutture di ripristino.\\
+    \const{SEMUME}&\const{SEMOPM}& Massimo numero di voci di ripristino.\\
+    \const{SEMAEM}&\const{SEMVMX}& valore massimo per l'aggiustamento
                                    all'uscita. \\
     \hline
   \end{tabular}
@@ -2077,7 +2096,7 @@ direttamente nel file \file{/proc/sys/kernel/sem}.
 
 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} 
@@ -2093,16 +2112,16 @@ loro inizializzazione) 
     quattro. In caso di errore restituisce -1, ed \var{errno} assumerà uno dei
     valori:
     \begin{errlist}
-    \item[\macro{EACCES}] Il processo non ha i privilegi per eseguire
+    \item[\errcode{EACCES}] Il processo non ha i privilegi per eseguire
       l'operazione richiesta.
-    \item[\macro{EIDRM}] L'insieme di semafori è stato cancellato.
-    \item[\macro{EPERM}] Si è richiesto \macro{IPC\_SET} o \macro{IPC\_RMID} ma
-      il processo non ha  privilegi sufficienti ad eseguire l'operazione.
-    \item[\macro{ERANGE}] Si è richiesto \macro{SETALL} \macro{SETVAL} ma il
+    \item[\errcode{EIDRM}] L'insieme di semafori è stato cancellato.
+    \item[\errcode{EPERM}] Si è richiesto \const{IPC\_SET} o \const{IPC\_RMID}
+      ma il processo non ha privilegi sufficienti ad eseguire l'operazione.
+    \item[\errcode{ERANGE}] Si è richiesto \const{SETALL} \const{SETVAL} ma il
       valore a cui si vuole impostare il semaforo è minore di zero o maggiore
-      di \macro{SEMVMX}.
+      di \const{SEMVMX}.
   \end{errlist}
-  ed inoltre \macro{EFAULT} ed \macro{EINVAL}.
+  ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
 }
 \end{functions}
 
@@ -2111,12 +2130,6 @@ specificata con \param{cmd}, ed opera o sull'intero insieme specificato da
 \param{semid} o sul singolo semaforo di un insieme, specificato da
 \param{semnum}. 
 
-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}.
-
 \begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{15cm}
@@ -2131,69 +2144,76 @@ union semun {
     \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 \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
 \param{cmd}, che specifica l'azione da intraprendere; i valori validi (che
-cioè non causano un errore di \macro{EINVAL}) per questo argomento sono i
+cioè non causano un errore di \errcode{EINVAL}) per questo argomento sono i
 seguenti:
 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
-\item[\macro{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.
-\item[\macro{IPC\_RMID}] Rimuove l'insieme di semafori e le relative strutture
+\item[\const{IPC\_STAT}] Legge i dati dell'insieme di semafori, copiando il
+  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 \macro{EIDRM}.
-  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[\macro{IPC\_SET}] Permette di modificare i permessi ed il proprietario
+  \textit{sleep} vengono svegliati, ritornando con un errore di
+  \errcode{EIDRM}.  L'user-ID effettivo del processo deve corrispondere o al
+  creatore o al proprietario dell'insieme, o all'amministratore. L'argomento
+  \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
+  significativi di \var{sem\_perm.mode}. L'user-ID effettivo del processo deve
   corrispondere o al creatore o al proprietario dell'insieme, o
   all'amministratore.  L'argomento \param{semnum} viene ignorato.
-\item[\macro{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.
+\item[\const{GETALL}] Restituisce il valore corrente di ciascun semaforo
+  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[\macro{GETNCNT}] Restituisce come valore di ritorno della funzione il
+\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[\macro{GETPID}] Restituisce come valore di ritorno della funzione il
+\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.
-\item[\macro{GETVAL}] Restituisce come valore di ritorno della funzione il il
+  \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[\macro{GETZCNT}] Restituisce come valore di ritorno della funzione il
+\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[\macro{SETALL}] Inizializza il valore di tutti i semafori dell'insieme,
-  aggiornando il campo \var{sem\_ctime} di \var{semid\_ds}. I valori devono
+\item[\const{SETALL}] Inizializza il valore di tutti i semafori dell'insieme,
+  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[\macro{SETVAL}] Inizializza il semaforo \param{semnum} al valore passato
+\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
-l'insieme con \macro{SETALL}, che per un solo semaforo con \macro{SETVAL}), i
+l'insieme con \const{SETALL}, che per un solo semaforo con \const{SETVAL}), i
 processi in attesa su di esso reagiscono di conseguenza al cambiamento di
 valore.  Inoltre la coda delle operazioni di ripristino viene cancellata per
 tutti i semafori il cui valore viene modificato.
@@ -2206,10 +2226,10 @@ tutti i semafori il cui valore viene modificato.
     \textbf{Operazione}  & \textbf{Valore restituito} \\
     \hline
     \hline
-    \macro{GETNCNT}& valore di \var{semncnt}.\\
-    \macro{GETPID} & valore di \var{sempid}.\\
-    \macro{GETVAL} & valore di \var{semval}.\\
-    \macro{GETZCNT}& valore di \var{semzcnt}.\\
+    \const{GETNCNT}& valore di \var{semncnt}.\\
+    \const{GETPID} & valore di \var{sempid}.\\
+    \const{GETVAL} & valore di \var{semval}.\\
+    \const{GETZCNT}& valore di \var{semzcnt}.\\
     \hline
   \end{tabular}
   \caption{Valori di ritorno della funzione \func{semctl}.} 
@@ -2220,12 +2240,12 @@ Il valore di ritorno della funzione in caso di successo dipende
 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} 
@@ -2238,21 +2258,21 @@ vengono effettuate con la funzione \func{semop}, il cui prototipo 
   \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[\macro{EACCES}] Il processo non ha i privilegi per eseguire
+    \item[\errcode{EACCES}] Il processo non ha i privilegi per eseguire
       l'operazione richiesta.
-    \item[\macro{EIDRM}] L'insieme di semafori è stato cancellato.
-    \item[\macro{ENOMEM}] Si è richiesto un \macro{SEM\_UNDO} ma il sistema
+    \item[\errcode{EIDRM}] L'insieme di semafori è stato cancellato.
+    \item[\errcode{ENOMEM}] Si è richiesto un \const{SEM\_UNDO} ma il sistema
       non ha le risorse per allocare la struttura di ripristino.
-    \item[\macro{EAGAIN}] Un'operazione comporterebbe il blocco del processo,
-      ma si è specificato \macro{IPC\_NOWAIT} in \var{sem\_flg}.
-    \item[\macro{EINTR}] La funzione, bloccata in attesa dell'esecuzione
+    \item[\errcode{EAGAIN}] Un'operazione comporterebbe il blocco del processo,
+      ma si è specificato \const{IPC\_NOWAIT} in \var{sem\_flg}.
+    \item[\errcode{EINTR}] La funzione, bloccata in attesa dell'esecuzione
       dell'operazione, viene interrotta da un segnale.
-    \item[\macro{E2BIG}] L'argomento \param{nsops} è maggiore del numero
-      massimo di operazioni \macro{SEMOPM}.
-    \item[\macro{ERANGE}] Per alcune operazioni il valore risultante del
-      semaforo viene a superare il limite massimo \macro{SEMVMX}.
+    \item[\errcode{E2BIG}] L'argomento \param{nsops} è maggiore del numero
+      massimo di operazioni \const{SEMOPM}.
+    \item[\errcode{ERANGE}] Per alcune operazioni il valore risultante del
+      semaforo viene a superare il limite massimo \const{SEMVMX}.
   \end{errlist}
-  ed inoltre \macro{EFAULT} ed \macro{EINVAL}.
+  ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
 }
 \end{functions}
 
@@ -2261,7 +2281,7 @@ un insieme. La funzione richiede come primo argomento l'identificatore
 \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]
@@ -2277,13 +2297,13 @@ struct sembuf
     \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.
@@ -2293,11 +2313,11 @@ vettore, per cui il primo semaforo corrisponde ad un valore nullo di
 \var{sem\_num}.
 
 Il campo \var{sem\_flg} è un flag, mantenuto come maschera binaria, per il
-quale possono essere impostati i due valori \macro{IPC\_NOWAIT} e
-\macro{SEM\_UNDO}.  Impostando \macro{IPC\_NOWAIT} si fa si che, invece di
+quale possono essere impostati i due valori \const{IPC\_NOWAIT} e
+\const{SEM\_UNDO}.  Impostando \const{IPC\_NOWAIT} si fa si che, invece di
 bloccarsi (in tutti quei casi in cui l'esecuzione di una operazione richiede
 che il processo vada in stato di \textit{sleep}), \func{semop} ritorni
-immediatamente con un errore di \macro{EAGAIN}.  Impostando \macro{SEM\_UNDO}
+immediatamente con un errore di \errcode{EAGAIN}.  Impostando \const{SEM\_UNDO}
 si richiede invece che l'operazione venga registrata in modo che il valore del
 semaforo possa essere ripristinato all'uscita del processo.
 
@@ -2307,26 +2327,26 @@ possibili:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
 \item[\var{sem\_op}$>0$] In questo caso il valore di \var{sem\_op} viene
   aggiunto al valore corrente di \var{semval}. La funzione ritorna
-  immediatamente (con un errore di \macro{ERANGE} qualora si sia superato il
-  limite \macro{SEMVMX}) ed il processo non viene bloccato in nessun caso.
-  Specificando \macro{SEM\_UNDO} si aggiorna il contatore per il ripristino
+  immediatamente (con un errore di \errcode{ERANGE} qualora si sia superato il
+  limite \const{SEMVMX}) ed il processo non viene bloccato in nessun caso.
+  Specificando \const{SEM\_UNDO} si aggiorna il contatore per il ripristino
   del valore del semaforo. Al processo chiamante è richiesto il privilegio di
   alterazione (scrittura) sull'insieme di semafori.
   
 \item[\var{sem\_op}$=0$] Nel caso \var{semval} sia zero l'esecuzione procede
   immediatamente. Se \var{semval} è diverso da zero il comportamento è
-  controllato da \var{sem\_flg}, se è stato impostato \macro{IPC\_NOWAIT} la
-  funzione ritorna con un errore di \macro{EAGAIN}, altrimenti viene
+  controllato da \var{sem\_flg}, se è stato impostato \const{IPC\_NOWAIT} la
+  funzione ritorna con un errore di \errcode{EAGAIN}, altrimenti viene
   incrementato \var{semzcnt} di uno ed il processo resta in stato di
   \textit{sleep} fintanto che non si ha una delle condizioni seguenti:
   \begin{itemize*}
   \item \var{semval} diventa zero, nel qual caso \var{semzcnt} viene
     decrementato di uno.
   \item l'insieme di semafori viene rimosso, nel qual caso \func{semop} ritorna
-    un errore di \macro{EIDRM}.
+    un errore di \errcode{EIDRM}.
   \item il processo chiamante riceve un segnale, nel qual caso \var{semzcnt}
     viene decrementato di uno e \func{semop} ritorna un errore di
-    \macro{EINTR}.
+    \errcode{EINTR}.
   \end{itemize*}
   Al processo chiamante è richiesto il privilegio di lettura dell'insieme dei
   semafori.
@@ -2334,40 +2354,40 @@ possibili:
 \item[\var{sem\_op}$<0$] Nel caso in cui \var{semval} è maggiore o uguale del
   valore assoluto di \var{sem\_op} (se cioè la somma dei due valori resta
   positiva o nulla) i valori vengono sommati e la funzione ritorna
-  immediatamente; qualora si sia impostato \macro{SEM\_UNDO} viene anche
+  immediatamente; qualora si sia impostato \const{SEM\_UNDO} viene anche
   aggiornato il contatore per il ripristino del valore del semaforo. In caso
   contrario (quando cioè la somma darebbe luogo ad un valore di \var{semval}
-  negativo) se si è impostato \macro{IPC\_NOWAIT} la funzione ritorna con un
-  errore di \macro{EAGAIN}, altrimenti viene incrementato di uno \var{semncnt}
-  ed il processo resta in stato di \textit{sleep} fintanto che non si ha una
-  delle condizioni seguenti:
+  negativo) se si è impostato \const{IPC\_NOWAIT} la funzione ritorna con un
+  errore di \errcode{EAGAIN}, altrimenti viene incrementato di uno
+  \var{semncnt} ed il processo resta in stato di \textit{sleep} fintanto che
+  non si ha una delle condizioni seguenti:
   \begin{itemize*}
   \item \var{semval} diventa maggiore o uguale del valore assoluto di
     \var{sem\_op}, nel qual caso \var{semncnt} viene decrementato di uno, il
     valore di \var{sem\_op} viene sommato a \var{semval}, e se era stato
-    impostato \macro{SEM\_UNDO} viene aggiornato il contatore per il
+    impostato \const{SEM\_UNDO} viene aggiornato il contatore per il
     ripristino del valore del semaforo.
-  \item l'insieme di semafori viene rimosso, nel qual caso \func{semop} ritorna
-    un errore di \macro{EIDRM}.
+  \item l'insieme di semafori viene rimosso, nel qual caso \func{semop}
+    ritorna un errore di \errcode{EIDRM}.
   \item il processo chiamante riceve un segnale, nel qual caso \var{semncnt}
     viene decrementato di uno e \func{semop} ritorna un errore di
-    \macro{EINTR}.
+    \errcode{EINTR}.
   \end{itemize*}    
   Al processo chiamante è richiesto il privilegio di alterazione (scrittura)
   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
-\macro{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
+\const{SEM\_UNDO}. Il meccanismo è implementato tramite una apposita struttura
+\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
@@ -2389,15 +2409,15 @@ a queste strutture restano per compatibilit
 \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.
 
@@ -2405,14 +2425,14 @@ Se invece tutte le operazioni possono avere successo queste vengono eseguite
 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 \macro{SEM\_UNDO} viene mantenuta per ciascun insieme
-di semafori una apposita struttura \var{sem\_undo} che contiene (nel vettore
+si è specificato il flag \const{SEM\_UNDO} viene mantenuta per ciascun insieme
+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. 
 
@@ -2422,7 +2442,7 @@ all'insieme di cui fa parte il semaforo, che viene usata per invalidare le
 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.
 
@@ -2441,7 +2461,7 @@ ripristino non 
 
 Come esempio di uso dell'interfaccia dei semafori vediamo come implementare
 con essa dei semplici \textit{mutex} (cioè semafori binari), tutto il codice
-in questione, contenuto nel file \file{wrappers.h} allegato ai sorgenti, è
+in questione, contenuto nel file \file{Mutex.c} allegato ai sorgenti, è
 riportato in \figref{fig:ipc_mutex_create}. Utilizzeremo l'interfaccia per
 creare un insieme contenente un singolo semaforo, per il quale poi useremo un
 valore unitario per segnalare la disponibilità della risorsa, ed un valore
@@ -2451,10 +2471,8 @@ nullo per segnalarne l'indisponibilit
   \footnotesize \centering
   \begin{minipage}[c]{15cm}
     \begin{lstlisting}{} 
-/*
- * Function MutexCreate: create a mutex/semaphore
- */
-inline int MutexCreate(key_t ipc_key) 
+/* Function MutexCreate: create a mutex/semaphore */
+int MutexCreate(key_t ipc_key) 
 {
     const union semun semunion={1};             /* semaphore union structure */
     int sem_id, ret;
@@ -2468,23 +2486,17 @@ inline int MutexCreate(key_t ipc_key)
     }
     return sem_id;
 }
-/*
- * Function MutexFind: get the semaphore/mutex Id given the IPC key value
- */
-inline int MutexFind(key_t ipc_key) 
+/* Function MutexFind: get the semaphore/mutex Id given the IPC key value */
+int MutexFind(key_t ipc_key) 
 {
     return semget(ipc_key,1,0);
 }
-/*
- * Function MutexRead: read the current value of the mutex/semaphore
- */
-inline int MutexRead(int sem_id) 
+/* Function MutexRead: read the current value of the mutex/semaphore */
+int MutexRead(int sem_id) 
 {
     return semctl(sem_id, 0, GETVAL);
 }
-/*
- * Define sembuf structures to lock and unlock the semaphore 
- */
+/* Define sembuf structures to lock and unlock the semaphore  */
 struct sembuf sem_lock={                                /* to lock semaphore */
     0,                                   /* semaphore number (only one so 0) */
     -1,                                    /* operation (-1 to use resource) */
@@ -2492,20 +2504,21 @@ struct sembuf sem_lock={                                /* to lock semaphore */
 struct sembuf sem_ulock={                             /* to unlock semaphore */
     0,                                   /* semaphore number (only one so 0) */
     1,                                  /* operation (1 to release resource) */
-    SEM_UNO};                                       /* flag (in this case 0) */
-/*
- * Function MutexLock: to lock a mutex/semaphore
- */
-inline int MutexLock(int sem_id) 
+    SEM_UNDO};                                      /* flag (in this case 0) */
+/* Function MutexLock: to lock a mutex/semaphore */
+int MutexLock(int sem_id) 
 {
     return semop(sem_id, &sem_lock, 1);
 }
-/*
- * Function MutexUnlock: to unlock a mutex/semaphore
- */
-inline int MutexUnlock(int sem_id) 
+/* Function MutexUnlock: to unlock a mutex/semaphore */
+int MutexUnlock(int sem_id) 
 {
     return semop(sem_id, &sem_ulock, 1);
+}
+/* Function MutexRemove: remove a mutex/semaphore */
+int MutexRemove(int sem_id) 
+{
+    return semctl(sem_id, 0, IPC_RMID);
 }
     \end{lstlisting}
   \end{minipage} 
@@ -2515,58 +2528,48 @@ inline int MutexUnlock(int sem_id)
   \label{fig:ipc_mutex_create}
 \end{figure}
 
-La prima funzione (\texttt{\small 1--17}) è \func{MutexCreate} che data una
+La prima funzione (\texttt{\small 2--15}) è \func{MutexCreate} che data una
 chiave crea il semaforo usato per il mutex e lo inizializza, restituendone
-l'identificatore. Il primo passo (\texttt{\small 8}) è chiamare \func{semget}
-con \macro{IPC\_CREATE} per creare il semaforo qualora non esista,
+l'identificatore. Il primo passo (\texttt{\small 6}) è chiamare \func{semget}
+con \const{IPC\_CREATE} per creare il semaforo qualora non esista,
 assegnandogli i privilegi di lettura e scrittura per tutti. In caso di errore
-(\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 \macro{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
-  13--16}) si restituisce il valore di ritorno di \func{semctl}, altrimenti si
-ritorna l'identificatore del semaforo.
-
-La seconda funzione (\texttt{\small 18--24}) è \func{MutexFind}, che data una
+(\texttt{\small 7--9}) si ritorna subito il risultato di \func{semget},
+altrimenti (\texttt{\small 10}) si inizializza il semaforo chiamando
+\func{semctl} con il comando \const{SETVAL}, utilizzando l'unione
+\struct{semunion} dichiarata ed avvalorata in precedenza (\texttt{\small 4})
+ad 1 per significare che risorsa è libera. In caso di errore (\texttt{\small
+  11--13}) si restituisce il valore di ritorno di \func{semctl}, altrimenti
+(\texttt{\small 14}) si ritorna l'identificatore del semaforo.
+
+La seconda funzione (\texttt{\small 17--20}) è \func{MutexFind}, che, data una
 chiave, restituisce l'identificatore del semaforo ad essa associato. La
-comprensione del suo funzionamento è immediata in quanto è solo un
+comprensione del suo funzionamento è immediata in quanto essa è soltanto un
 \textit{wrapper}\footnote{si chiama così una funzione usata per fare da
   \textsl{involucro} alla chiamata di un altra, usata in genere per
   semplificare un'interfaccia (come in questo caso) o per utilizzare con la
   stessa funzione diversi substrati (librerie, ecc.)  che possono fornire le
-  stesse funzionalità.} di \func{semget} per cercare l'identificatore
-associato alla chiave, restituendo direttamente il valore di ritorno della
-funzione.
+  stesse funzionalità.} di una chiamata a \func{semget} per cercare
+l'identificatore associato alla chiave, il valore di ritorno di quest'ultima
+viene passato all'indietro al chiamante.
 
-La terza funzione (\texttt{\small 25--31}) è \func{MutexRead} che, dato
-l'identificatore, restituisce il valore del mutex. Anche in questo caso la
-funzione è un \textit{wrapper} per la chiamata di \func{semctl}, questa volta
-con il comando \macro{GETVAL}, che permette di restituire il valore del
-semaforo.
+La terza funzione (\texttt{\small 22--25}) è \func{MutexRead} che, dato un
+identificatore, restituisce il valore del semaforo associato al mutex. Anche
+in questo caso la funzione è un \textit{wrapper} per una chiamata a
+\func{semctl} con il comando \const{GETVAL}, che permette di restituire il
+valore del semaforo.
 
-La quarta e la quinta funzione (\texttt{\small 43--56}) sono \func{MutexLock},
+La quarta e la quinta funzione (\texttt{\small 36--44}) sono \func{MutexLock},
 e \func{MutexUnlock}, che permettono rispettivamente di bloccare e sbloccare
 il mutex. Entrambe fanno da wrapper per \func{semop}, utilizzando le due
 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 \macro{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.}
+(\texttt{\small 27--34}). 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.
 
+L'ultima funzione (\texttt{\small 46--49}) della serie, è \func{MutexRemove},
+che rimuove il mutex. Anche in questo caso si ha un wrapper per una chiamata a
+\func{semctl} con il comando \const{IPC\_RMID}, che permette di cancellare il
+smemaforo; il valore di ritorno di quest'ultima viene passato all'indietro.
 
 Chiamare \func{MutexLock} decrementa il valore del semaforo: se questo è
 libero (ha già valore 1) sarà bloccato (valore nullo), se è bloccato la
@@ -2579,10 +2582,9 @@ crescerebbe oltre 1, e \func{MutexLock} non avrebbe pi
 (bloccare la risorsa quando questa è considerata libera). Si tenga presente
 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.
-
-
+Vedremo in \secref{sec:ipc_lock_file} come sia possibile ottenere
+un'interfaccia analoga a quella appena illustrata, senza incorrere in questi
+problemi, usando il file locking\index{file!locking}.
 
 
 
@@ -2590,7 +2592,7 @@ analoga senza questo problemi usando il 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} 
@@ -2604,25 +2606,25 @@ ed il suo prototipo 
   \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
     in caso di errore, nel qual caso \var{errno} assumerà i valori:
     \begin{errlist}
-    \item[\macro{ENOSPC}] Si è superato il limite (\macro{SHMMNI}) sul numero
+    \item[\errcode{ENOSPC}] Si è superato il limite (\const{SHMMNI}) sul numero
       di segmenti di memoria nel sistema, o cercato di allocare un segmento le
-      cui dimensioni fanno superare il limite di sistema (\macro{SHMALL}) per
+      cui dimensioni fanno superare il limite di sistema (\const{SHMALL}) per
       la memoria ad essi riservata.
-    \item[\macro{EINVAL}] Si è richiesta una dimensione per un nuovo segmento
-      maggiore di \macro{SHMMAX} o minore di \macro{SHMMIN}, o se il segmento
+    \item[\errcode{EINVAL}] Si è richiesta una dimensione per un nuovo segmento
+      maggiore di \const{SHMMAX} o minore di \const{SHMMIN}, o se il segmento
       già esiste \param{size} è maggiore delle sue dimensioni.
-    \item[\macro{ENOMEM}] Il sistema non ha abbastanza memoria per poter
+    \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 \macro{EACCES}, \macro{ENOENT}, \macro{EEXIST}, \macro{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
 identico è l'uso degli argomenti \param{key} e \param{flag} per cui non
 ripeteremo quanto detto al proposito in \secref{sec:ipc_sysv_mq}. L'argomento
 \param{size} specifica invece la dimensione, in byte, del segmento, che viene
-comunque arrotondata al multiplo superiore di \macro{PAGE\_SIZE}.
+comunque arrotondata al multiplo superiore di \const{PAGE\_SIZE}.
 
 La memoria condivisa è la forma più veloce di comunicazione fra due processi,
 in quanto permette agli stessi di vedere nel loro spazio di indirizzi una
@@ -2638,7 +2640,7 @@ quest'ultimo non acceda al segmento di memoria condivisa prima che il primo
 non abbia completato le operazioni di scrittura, inoltre nel corso di una
 lettura si deve essere sicuri che i dati restano coerenti e non vengono
 sovrascritti da un accesso in scrittura sullo stesso segmento da parte di un
-altro processo; per questo in genere la memoria condivisa viene sempre
+altro processo. Per questo in genere la memoria condivisa viene sempre
 utilizzata in abbinamento ad un meccanismo di sincronizzazione, il che, di
 norma, significa insieme a dei semafori.
 
@@ -2659,16 +2661,16 @@ struct shmid_ds {
     \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:
@@ -2677,7 +2679,7 @@ invece:
   inizializzato al valore di \param{size}.
 \item il campo \var{shm\_ctime}, che esprime il tempo di creazione del
   segmento, viene inizializzato al tempo corrente.
-\item i campi \var{shm\_atime} e \var{shm\_atime}, che esprimono
+\item i campi \var{shm\_atime} e \var{shm\_dtime}, che esprimono
   rispettivamente il tempo dell'ultima volta che il segmento è stato
   agganciato o sganciato da un processo, vengono inizializzati a zero.
 \item il campo \var{shm\_lpid}, che esprime il \acr{pid} del processo che ha
@@ -2689,11 +2691,14 @@ invece:
 \end{itemize*}
 
 Come per le code di messaggi e gli insiemi di semafori, anche per i segmenti
-di memoria condivisa esistono una serie di limiti, i cui valori, riportati in
-\tabref{tab:ipc_shm_limits} sono associati ad altrettante costanti.  Alcuni di
-questi limiti sono al solito accessibili e modificabili attraverso
+di memoria condivisa esistono una serie di limiti imposti dal sistema.  Alcuni
+di questi limiti sono al solito accessibili e modificabili attraverso
 \func{sysctl} o scrivendo direttamente nei rispettivi file di
-\file{/proc/sys/kernel/}.
+\file{/proc/sys/kernel/}. In \tabref{tab:ipc_shm_limits} si sono riportate le
+costanti simboliche associate a ciascuno di essi, il loro significato, i
+valori preimpostati, e, quando presente, il file in \file{/proc/sys/kernel/}
+che permettono di cambiarne il valore. 
+
 
 \begin{table}[htb]
   \footnotesize
@@ -2704,15 +2709,25 @@ questi limiti sono al solito accessibili e modificabili attraverso
     & \textbf{Significato} \\
     \hline
     \hline
-    \macro{SHMALL}&0x200000&\file{shmall}& Numero massimo di pagine che 
+    \const{SHMALL}& 0x200000&\file{shmall}& Numero massimo di pagine che 
                                        possono essere usate per i segmenti di
                                        memoria condivisa. \\
-    \macro{SHMMAX}&0x2000000&\file{shmmax}& Dimensione massima di un segmento 
-                                       di memoria condivisa.\\
-    \macro{SHMMNI}&4096&\file{msgmni}& Numero massimo di segmenti di memoria
-                                       condivisa presenti nel kernel.\\
-    \macro{SHMMIN}&   1& ---         & Dimensione minima di un segmento di
-                                       memoria condivisa. \\
+    \const{SHMMAX}&0x2000000&\file{shmmax}& Dimensione massima di un segmento 
+                                            di memoria condivisa.\\
+    \const{SHMMNI}&     4096&\file{msgmni}& Numero massimo di segmenti di 
+                                            memoria condivisa presenti nel
+                                            kernel.\\ 
+    \const{SHMMIN}&        1& ---         & Dimensione minima di un segmento di
+                                            memoria condivisa. \\
+    \const{SHMLBA}&\const{PAGE\_SIZE}&--- & Limite inferiore per le dimensioni
+                                            minime di un segmento (deve essere
+                                            allineato alle dimensioni di una
+                                            pagina di memoria). \\
+    \const{SHMSEG}&   ---   &     ---     & Numero massimo di segmenti di
+                                            memoria condivisa 
+                                            per ciascun processo.\\
+
+
     \hline
   \end{tabular}
   \caption{Valori delle costanti associate ai limiti dei segmenti di memoria
@@ -2722,7 +2737,7 @@ questi limiti sono al solito accessibili e modificabili attraverso
 \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}
@@ -2734,47 +2749,49 @@ un segmento di memoria condivisa 
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
     errore, nel qual caso \var{errno} assumerà i valori:
     \begin{errlist}
-    \item[\macro{EACCES}] Si è richiesto \macro{IPC\_STAT} ma i permessi non
+    \item[\errcode{EACCES}] Si è richiesto \const{IPC\_STAT} ma i permessi non
       consentono l'accesso in lettura al segmento.
-    \item[\macro{EINVAL}] O \param{shmid} o \param{cmd} hanno valori non
+    \item[\errcode{EINVAL}] O \param{shmid} o \param{cmd} hanno valori non
       validi.
-    \item[\macro{EIDRM}] L'argomento \param{shmid} fa riferimento ad un
+    \item[\errcode{EIDRM}] L'argomento \param{shmid} fa riferimento ad un
       segmento che è stato cancellato.
-    \item[\macro{EPERM}] Si è specificato un comando con \macro{IPC\_SET} o
-      \macro{IPC\_RMID} senza i permessi necessari.
-    \item[\macro{EOVERFLOW}] L'argomento \param{shmid} fa riferimento ad un
+    \item[\errcode{EPERM}] Si è specificato un comando con \const{IPC\_SET} o
+      \const{IPC\_RMID} senza i permessi necessari.
+    \item[\errcode{EOVERFLOW}] L'argomento \param{shmid} fa riferimento ad un
       segmento che è stato cancellato.
     \end{errlist}
-  ed inoltre \macro{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[\macro{IPC\_STAT}] Legge le informazioni riguardo il segmento di memoria
-  condivisa nella struttura \var{shmid\_ds} puntata da \param{buf}. Occorre
+\item[\const{IPC\_STAT}] Legge le informazioni riguardo il segmento di memoria
+  condivisa nella struttura \struct{shmid\_ds} puntata da \param{buf}. Occorre
   avere il permesso di lettura sulla coda.
-\item[\macro{IPC\_RMID}] Marca il segmento di memoria condivisa per la
+\item[\const{IPC\_RMID}] Marca il segmento di memoria condivisa per la
   rimozione, questo verrà cancellato effettivamente solo quando l'ultimo
   processo ad esso agganciato si sarà staccato. Questo comando può essere
-  eseguito solo da un processo con userid effettivo, corrispondente al
-  creatore o al proprietario della coda, o all'amministratore.
-\item[\macro{IPC\_SET}] Permette di modificare i permessi ed il proprietario
+  eseguito solo da un processo con user-ID effettivo corrispondente o al
+  creatore della coda, o al proprietario della coda, o all'amministratore.
+\item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
   del segmento.  Per modificare i valori di \var{shm\_perm.mode},
   \var{shm\_perm.uid} e \var{shm\_perm.gid} occorre essere il proprietario o
   il creatore della coda, oppure l'amministratore. Compiuta l'operazione
   aggiorna anche il valore del campo \var{shm\_ctime}.
-\item[\macro{SHM\_LOCK}] Abilita il \textit{memory locking}\index{memory
-    locking} (vedi \secref{sec:proc_mem_lock}) sul segmento di memoria
+\item[\const{SHM\_LOCK}] Abilita il \textit{memory locking}\index{memory
+    locking}\footnote{impedisce cioè che la memoria usata per il segmento
+    venga salvata su disco dal meccanismo della memoria virtuale; si ricordi
+    quanto trattato in \secref{sec:proc_mem_lock}.} sul segmento di memoria
   condivisa. Solo l'amministratore può utilizzare questo comando.
-\item[\macro{SHM\_UNLOCK}] Disabilita il \textit{memory locking}. Solo
-  l'amministratore può utilizzare questo comando.
+\item[\const{SHM\_UNLOCK}] Disabilita il \textit{memory locking} sul segmento
+  di memoria condivisa. Solo l'amministratore può utilizzare questo comando.
 \end{basedescript}
 i primi tre comandi sono gli stessi già visti anche per le code ed i semafori,
 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}
@@ -2788,21 +2805,23 @@ indirizzi; il suo prototipo 
     successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà i
     valori:
     \begin{errlist}
-    \item[\macro{EACCES}] Il processo non ha i privilegi per accedere al
+    \item[\errcode{EACCES}] Il processo non ha i privilegi per accedere al
       segmento nella modalità richiesta.
-    \item[\macro{EINVAL}] Si è specificato un identificatore invalido per
+    \item[\errcode{EINVAL}] Si è specificato un identificatore invalido per
       \param{shmid}, o un indirizzo non allineato sul confine di una pagina
       per \param{shmaddr}.
     \end{errlist}
-    ed inoltre \macro{ENOMEM}.}
+    ed inoltre \errval{ENOMEM}.}
 \end{functions}
 
 La funzione inserisce un segmento di memoria condivisa all'interno dello
 spazio di indirizzi del processo, in modo che questo possa accedervi
 direttamente, la situazione dopo l'esecuzione di \func{shmat} è illustrata in
 \figref{fig:ipc_shmem_layout} (per la comprensione del resto dello schema si
-ricordi quanto illustrato al proposito in \secref{sec:proc_mem_layout}). Si
-tenga presente che la funzione ha successo anche se il segmento è stato
+ricordi quanto illustrato al proposito in \secref{sec:proc_mem_layout}). In
+particolare l'indirizzo finale del segmento dati (quello impostato da
+\func{brk}, vedi \secref{sec:proc_mem_sbrk}) non viene influenzato. Si tenga
+presente infine che la funzione ha successo anche se il segmento è stato
 marcato per la cancellazione.
 
 \begin{figure}[htb]
@@ -2819,34 +2838,41 @@ L'argomento \param{shmaddr} specifica a quale indirizzo\footnote{Lo standard
   \acr{libc4} e le \acr{libc5}, con il passaggio alle \acr{glibc} il tipo di
   \param{shmaddr} è divenuto un \ctyp{const void *} e quello del valore di
   ritorno un \ctyp{void *}.} deve essere associato il segmento, se il valore
-specificato è \macro{NULL} è il sistema a scegliere opportunamente un'area di
+specificato è \val{NULL} è il sistema a scegliere opportunamente un'area di
 memoria libera (questo è il modo più portabile e sicuro di usare la funzione).
 Altrimenti il kernel aggancia il segmento all'indirizzo specificato da
 \param{shmaddr}; questo però può avvenire solo se l'indirizzo coincide con il
 limite di una pagina, cioè se è un multiplo esatto del parametro di sistema
-\macro{SHMLBA}, che in Linux è sempre uguale \macro{PAGE\_SIZE}.
+\const{SHMLBA}, che in Linux è sempre uguale \const{PAGE\_SIZE}. 
+
+Si tenga presente però che quando si usa \val{NULL} come valore di
+\param{shmaddr}, l'indirizzo restituito da \func{shmat} può cambiare da
+processo a processo; pertanto se nell'area di memoria condivisa si salvano
+anche degli indirizzi, si deve avere cura di usare valori relativi (in genere
+riferiti all'indirizzo di partenza del segmento).
 
 L'argomento \param{shmflg} permette di cambiare il comportamento della
 funzione; esso va specificato come maschera binaria, i bit utilizzati sono
-solo due e sono identificati dalle costanti \macro{SHM\_RND} e
-\macro{SHM\_RDONLY}, che vanno combinate con un OR aritmetico.  Specificando
-\macro{SHM\_RND} si evita che \func{shmat} ritorni un errore quando
+solo due e sono identificati dalle costanti \const{SHM\_RND} e
+\const{SHM\_RDONLY}, che vanno combinate con un OR aritmetico.  Specificando
+\const{SHM\_RND} si evita che \func{shmat} ritorni un errore quando
 \param{shmaddr} non è allineato ai confini di una pagina. Si può quindi usare
 un valore qualunque per \param{shmaddr}, e il segmento verrà comunque
-agganciato, ma al più vicino multiplo di \macro{SHMLBA} (il nome della
+agganciato, ma al più vicino multiplo di \const{SHMLBA} (il nome della
 costante sta infatti per \textit{rounded}, e serve per specificare un
-indirizzo come arrotondamento).
+indirizzo come arrotondamento, in Linux è equivalente a \const{PAGE\_SIZE}).
 
-Il secondo bit permette di agganciare il segmento in sola lettura (si ricordi
-che anche le pagine di memoria hanno dei permessi), in tal caso un tentativo
-di scrivere sul segmento comporterà una violazione di accesso con l'emissione
-di un segnale di \macro{SIGSEGV}. Il comportamento usuale di \func{shmat} è
-quello di agganciare il segmento con l'accesso in lettura e scrittura (ed il
-processo deve aver questi permessi in \var{shm\_perm}), non è prevista la
-possibilità di agganciare un segmento in sola scrittura.
+L'uso di \const{SHM\_RDONLY} permette di agganciare il segmento in sola
+lettura (si ricordi che anche le pagine di memoria hanno dei permessi), in tal
+caso un tentativo di scrivere sul segmento comporterà una violazione di
+accesso con l'emissione di un segnale di \const{SIGSEGV}. Il comportamento
+usuale di \func{shmat} è quello di agganciare il segmento con l'accesso in
+lettura e scrittura (ed il processo deve aver questi permessi in
+\var{shm\_perm}), non è prevista la possibilità di agganciare un segmento in
+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.
@@ -2865,10 +2891,9 @@ diverso, tutti i segmenti agganciati al processo originario vengono
 automaticamente sganciati. Lo stesso avviene all'uscita del processo
 attraverso una \func{exit}.
 
-
 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}
@@ -2879,7 +2904,7 @@ dell'interfaccia, \func{shmdt}, il cui prototipo 
   \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
-    \macro{EINVAL}.}
+    \errval{EINVAL}.}
 \end{functions}
 
 La funzione sgancia dallo spazio degli indirizzi del processo un segmento di
@@ -2887,29 +2912,339 @@ memoria condivisa; questo viene identificato con l'indirizzo \param{shmaddr}
 restituito dalla precedente chiamata a \func{shmat} con il quale era stato
 agganciato al processo.
 
-Per capire meglio il funzionamento delle funzioni facciamo ancora una volta
-riferimento alle strutture con cui il kernel implementa i segmenti di memoria
-condivisa; uno schema semplificato della struttura è illustrato in
-\figref{fig:ipc_shm_struct}. 
+In caso di successo la funzione aggiorna anche i seguenti campi di
+\struct{shmid\_ds}:
+\begin{itemize*}
+\item il tempo \var{shm\_dtime} dell'ultima operazione di sganciamento viene
+  impostato al tempo corrente.
+\item il \acr{pid} \var{shm\_lpid} dell'ultimo processo che ha operato sul
+  segmento viene impostato a quello del processo corrente.
+\item il numero \var{shm\_nattch} di processi agganciati al segmento viene
+  decrementato di uno.
+\end{itemize*} 
+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 viene per scambiare informazioni fra un processo
+server, che vi scrive dei dati di interesse generale che ha ottenuto, e 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 ``\textsl{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, quante
+directory, link simbolici, file normali, ecc.) che saranno salvati in un
+segmento di memoria condivisa cui altri processi potranno accedere per
+ricavare la parte di informazione che interessa.
+
+In \figref{fig:ipc_dirmonitor_main} si è riportata la sezione principale del
+corpo del programma server, insieme alle definizioni delle altre funzioni
+usate nel programma e delle variabili globali, omettendo tutto quello che
+riguarda la gestione delle opzioni e la stampa delle istruzioni di uso a
+video; al solito il codice completo si trova con i sorgenti allegati nel file
+\file{DirMonitor.c}.
 
-\begin{figure}[htb]
-  \centering
-  \includegraphics[width=10cm]{img/shmstruct}
-   \caption{Schema dell'implementazione dei segmenti di memoria condivisa in
-    Linux.}
-  \label{fig:ipc_shm_struct}
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \begin{lstlisting}{} 
+/* computation function for DirScan */
+int ComputeValues(struct dirent * direntry);
+void HandSIGTERM(int signo);
+/* global variables for shared memory segment */
+struct DirProp {
+    int tot_size;    
+    int tot_files;   
+    int tot_regular; 
+    int tot_fifo;    
+    int tot_link;    
+    int tot_dir;     
+    int tot_block;   
+    int tot_char;    
+    int tot_sock;
+};
+struct DirProp *shmptr;
+int shmid; 
+int mutex;
+/* main body */
+int main(int argc, char *argv[]) 
+{
+    int i;
+    key_t key;
+    ...
+    if ((argc - optind) != 1) {          /* There must be remaing parameters */
+        printf("Wrong number of arguments %d\n", argc - optind);
+        usage();
+    }
+    Signal(SIGTERM, HandSIGTERM);            /* set handlers for termination */
+    Signal(SIGINT, HandSIGTERM);
+    Signal(SIGQUIT, HandSIGTERM);
+    /* create needed IPC objects */
+    key = ftok("./DirMonitor.c", 1);                         /* define a key */
+    shmid = shmget(key, 4096, IPC_CREAT|0666);        /* get a shared memory */
+    if (shmid < 0) {
+        perror("Cannot create shared memory");
+        exit(1);
+    }
+    if ( (shmptr = shmat(shmid, NULL, 0)) == NULL ) {   /* attach to process */
+        perror("Cannot attach segment");
+    }
+    if ((mutex = MutexCreate(key)) == -1) {                   /* get a Mutex */
+        perror("Cannot create mutex");
+        exit(1);
+    }
+    /* main loop, monitor directory properties each 10 sec */
+    while (1) {
+        MutexLock(mutex);                              /* lock shared memory */
+        memset(shmptr, 0, sizeof(struct DirProp));    /* erase previous data */
+        DirScan(argv[1], ComputeValues);                     /* execute scan */
+        MutexUnlock(mutex);                          /* unlock shared memory */
+        sleep(pause);                              /* sleep until next watch */
+    }
+}
+    \end{lstlisting}
+  \end{minipage} 
+  \normalsize 
+  \caption{Codice della funzione principale del programma \file{DirMonitor.c}.}
+  \label{fig:ipc_dirmonitor_main}
+\end{figure}
+
+Il programma usa delle variabili globali (\texttt{\small 4--18}) per mantenere
+i valori relativi agli oggetti usati per la comunicazione inter-processo; si è
+definita inoltre una apposita struttura \struct{DirProp} che contiene i dati
+relativi alle proprietà che si vogliono mantenere nella memoria condivisa, per
+l'accesso da parte dei client.
+
+Il programma, dopo la sezione, omessa, relativa alla gestione delle opzioni da
+riga di comando, che si limitano alla eventuale stampa di un messaggio di
+aiuto a video ed all'impostazione della durata dell'intervallo con cui viene
+ripetuto il calcolo delle proprietà della directory, controlla (\texttt{\small
+  25--28}) che sia stato specificato un parametro (il nome della directory da
+tenere sotto controllo) senza il quale esce immediatamente con un messaggio di
+errore.
+
+Il passo successivo (\texttt{\small 29--31}) è quello di installare i gestori
+per i segnali di terminazione, infatti, visto che il programma è progettato
+come server, non è prevista una conclusione esplicita nel corpo principale,
+per cui, per gestire l'uscita, si è fatto uso di questi ultimi.
+
+Si può poi passare a creare (\texttt{\small 32--45}) gli oggetti di
+intercomunicazione necessari. Si ricava (\texttt{\small 33}) una chiave usando
+il nome del programma, con questa si ottiene (\texttt{\small 34--38}) un
+segmento di memoria condivisa \var{shmid} (uscendo in caso di errore), che si
+aggancia (\texttt{\small 39--41}) al processo all'indirizzo \var{shmptr}; sarà
+attraverso questo puntatore che potremo accedere alla memoria condivisa, che
+sarà vista nella forma data da \struct{DirProp}. Infine con la stessa chiave
+si crea (\texttt{\small 42--45}) anche un mutex (utilizzando le funzioni di
+interfaccia già descritte in \secref{sec:ipc_sysv_sem}) che utilizzeremo per
+regolare l'accesso alla memoria condivisa.
+
+Una volta completata l'inizializzazione e la creazione degli oggetti di
+intercomunicazione il programma eseguirà indefinitamente (\texttt{\small
+  46--53}) il ciclo principale: si inizia bloccando il mutex (\texttt{\small
+  48}) per poter accedere alla memoria condivisa (la funzione si bloccherà
+automaticamente se qualche client sta leggendo), poi si cancellano
+(\texttt{\small 49}) i valori precedentemente memorizzati, e si esegue
+(\texttt{\small 50}) un nuovo calcolo degli stessi; infine si sblocca il mutex
+(\texttt{\small 51}), e si attende (\texttt{\small 52}) per il periodo di
+tempo specificato a riga di comando con l'opzione \code{-p}.
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \begin{lstlisting}{} 
+...
+/*
+ * Routine  to compute directory properties inside DirScan
+ */
+int ComputeValues(struct dirent * direntry) 
+{
+    struct stat data;
+    stat(direntry->d_name, &data);                          /* get stat data */
+    shmptr->tot_size += data.st_size;
+    shmptr->tot_files++;
+    if (S_ISREG(data.st_mode)) shmptr->tot_regular++;
+    if (S_ISFIFO(data.st_mode)) shmptr->tot_fifo++;
+    if (S_ISLNK(data.st_mode)) shmptr->tot_link++;
+    if (S_ISDIR(data.st_mode)) shmptr->tot_dir;
+    if (S_ISBLK(data.st_mode)) shmptr->tot_block;
+    if (S_ISCHR(data.st_mode)) shmptr->tot_char;
+    if (S_ISSOCK(data.st_mode)) shmptr->tot_sock;
+    return 0;
+}
+/*
+ * Signal Handler to manage termination
+ */
+void HandSIGTERM(int signo) {
+    MutexLock(mutex);
+    if (shmdt(shmptr)) {
+        perror("Error detaching shared memory");
+        exit(1);
+    }
+    if (shmctl(shmid, IPC_RMID, NULL)) {
+        perror("Cannot remove shared memory segment");
+        exit(1);
+    }
+    MutexRemove(mutex);
+    exit(0);
+}
+    \end{lstlisting}
+  \end{minipage} 
+  \normalsize 
+  \caption{Codice delle funzione ausiliarie usate da \file{DirMonitor.c}.}
+  \label{fig:ipc_dirmonitor_sub}
 \end{figure}
 
+Si noti come per il calcolo dei valori da mantenere nella memoria condivisa si
+sia usata ancora una volta la funzione \func{DirScan}, già utilizzata (e
+descritta in dettaglio) in \secref{sec:file_dir_read}, che ci permette di
+effettuare la scansione delle voci della directory, chiamando per ciascuna di
+esse la funzione \func{ComputeValues}, che esegue tutti i calcoli necessari.
+
+Il codice di quest'ultima è riportato in \figref{fig:ipc_dirmonitor_sub}. Come
+si vede la funzione (\texttt{\small 5--19}) è molto semplice e si limita a
+chiamare (\texttt{\small 8}) la funzione \func{stat} sul file indicato da
+ciascuna voce, per ottenerne i dati, che poi utilizza per incrementare i vari
+contatori.
+
+Dato che la funzione è chiamata da \func{DirScan}, si è all'interno del ciclo
+principale del programma, con un mutex acquisito, perciò non è necessario
+effettuare nessun controllo e si può accedere direttamente alla memoria
+condivisa usando \var{shmptr} riempiendo i campi della struttura
+\struct{DirProp}; così prima (\texttt{\small 9--10}) si sommano le dimensioni
+dei file ed il loro numero, poi utilizzando le macro di
+\tabref{tab:file_type_macro}, si contano (\texttt{\small 11--17}) quanti ce ne
+sono per ciascun tipo.
+
+In \figref{fig:ipc_dirmonitor_sub} è riportato anche (\texttt{\small 23--35})
+il codice del gestore di segnali di terminazione usato per chiudere il
+programma, che oltre a provocare l'uscita del programma si incarica anche di
+cancellare tutti gli oggetti di intercomunicazione non più necessari.  Nel
+caso anzitutto (\texttt{\small 24}) si acquisisce il mutex per evitare di
+operare mentre un client sta ancora leggendo i dati, dopo di che prima si
+distacca (\texttt{\small 25--28}) il segmento e poi lo si cancella
+(\texttt{\small 29--32}). Infine (\texttt{\small 33}) si rimuove il mutex e si
+esce.
+
+Il codice del client che permette di leggere le informazioni mantenute nella
+memoria condivisa è riportato in \figref{fig:ipc_dirmonitor_client}, al solito
+si è omessa la sezione di gestione delle opzioni e la funzione che stampa a
+video le istruzioni; il codice completo è nei sorgenti allegati, nel file
+\file{ReadMonitor.c}.
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \begin{lstlisting}{} 
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <dirent.h>        /* directory */
+#include <stdlib.h>        /* C standard library */
+#include <unistd.h>
+
+#include "Gapil.h"
+#include "macros.h"
+
+int main(int argc, char *argv[]) 
+{
+    int i;
+    key_t key;
+    ..
+    /* find needed IPC objects */
+    key = ftok("./DirMonitor.c", 1);                         /* define a key */
+    shmid = shmget(key, 4096, 0);                /* get the shared memory ID */
+    if (shmid < 0) {
+        perror("Cannot find shared memory");
+        exit(1);
+    }
+    if ( (shmptr = shmat(shmid, NULL, 0)) == NULL ) {   /* attach to process */
+        perror("Cannot attach segment");
+        exit(1);
+    }
+    if ((mutex = MutexFind(key)) == -1) {                   /* get the Mutex */
+        perror("Cannot find mutex");
+        exit(1);
+    }
+    /* main loop */
+    MutexLock(mutex);                                  /* lock shared memory */
+    printf("File presenti %d file, per un totale di %d byte\n",
+           shmptr->tot_files, shmptr->tot_size);
+    printf("Ci sono %d file dati\n", shmptr->tot_regular);
+    printf("Ci sono %d directory\n", shmptr->tot_dir);
+    printf("Ci sono %d link\n", shmptr->tot_link);
+    printf("Ci sono %d fifo\n", shmptr->tot_fifo);
+    printf("Ci sono %d socket\n", shmptr->tot_sock);
+    printf("Ci sono %d device a caratteri\n", shmptr->tot_char);
+    printf("Ci sono %d device a blocchi\n", shmptr->tot_block);
+    MutexUnlock(mutex);                              /* unlock shared memory */
+}
+    \end{lstlisting}
+  \end{minipage} 
+  \normalsize 
+  \caption{Codice del programma client \file{ReadMonitor.c}.}
+  \label{fig:ipc_dirmonitor_client}
+\end{figure}
+
+Una volta completata la gestione delle opzioni a riga di comando il programma
+rigenera (\texttt{\small 16}) la chiave usata per identificare memoria
+condivisa e mutex, richiede (\texttt{\small 17}) l'identificatore della
+memoria condivisa (che in questo caso deve già esistere), uscendo in caso di
+errore (\texttt{\small 18--21}). Una volta ottenuto l'identificatore si può
+(\texttt{\small 22--25}) agganciare il segmento al processo (anche in questo
+caso uscendo se qualcosa non funziona). Infine (\texttt{\small 26--29}) si
+richiede pure l'identificatore del mutex.
+
+Una volta completata l'inizializzazione ed ottenuti i riferimenti agli oggetti
+di intercomunicazione necessari viene eseguito il corpo principale del
+programma (\texttt{\small 30--41}); si acquisisce (\texttt{\small 31}) il
+mutex (qui avviene il blocco se la memoria condivisa non è disponibile), e poi
+(\texttt{\small 32--40}) si stampano i vari valori in essa contenuti. Infine
+(\texttt{\small 41}) si rilascia il mutex. 
+
+
+%% Per capire meglio il funzionamento delle funzioni facciamo ancora una volta
+%% riferimento alle strutture con cui il kernel implementa i segmenti di memoria
+%% condivisa; uno schema semplificato della struttura è illustrato in
+%% \figref{fig:ipc_shm_struct}. 
+
+%% \begin{figure}[htb]
+%%   \centering
+%%   \includegraphics[width=10cm]{img/shmstruct}
+%%    \caption{Schema dell'implementazione dei segmenti di memoria condivisa in
+%%     Linux.}
+%%   \label{fig:ipc_shm_struct}
+%% \end{figure}
+
 
 
 
 \section{Tecniche alternative}
 \label{sec:ipc_alternatives}
 
-Come abbiamo visto in \secref{sec:ipc_sysv_generic} il \textit{SysV IPC}
+Come abbiamo detto in \secref{sec:ipc_sysv_generic}, e ripreso nella
+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 effettua una accurata analisi (alcuni dei concetti
-sono già stati accennati in precedenza) ed elenca alcune possibili
+  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.
 
 
@@ -2919,23 +3254,23 @@ 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{La sincronizzazione con il \textit{file locking}}
+\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
@@ -2951,69 +3286,230 @@ 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
-  è comunque soggetti alla possibilità di una race condition.} che essa
-ritorni un errore quando usata con i flag di \macro{O\_CREAT} e
-\macro{O\_EXCL}. In tal modo la creazione di un file di lock può essere
-eseguita atomicamente, il processo che crea il file con successo si può
-considerare come titolare del lock (e della risorsa ad esso associata) mentre
-il rilascio si può eseguire con una chiamata ad
-\func{unlink}.\footnote{abbiamo già accennato in \secref{sec:file_open} che
-  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.}
-
-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 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
-\textit{polling}\index{polling}, che è molto inefficiente.
-
-Per questo motivo la tecnica alternativa più pulita è quella di fare ricorso
-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
-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.
+  è comunque soggetti alla possibilità di una race   
+  condition\index{race condition}.} che essa ritorni un errore quando usata
+con i flag di \const{O\_CREAT} e \const{O\_EXCL}. In tal modo la creazione di
+un \textsl{file di lock} può essere eseguita atomicamente, il processo che
+crea il file con successo si può considerare come titolare del lock (e della
+risorsa ad esso associata) mentre il rilascio si può eseguire con una chiamata
+ad \func{unlink}.
+
+Un esempio dell'uso di questa funzione è mostrato dalle funzioni
+\func{LockFile} ed \func{UnlockFile} riportate in \figref{fig:ipc_file_lock}
+(sono contenute in \file{LockFile.c}, un'altro dei sorgenti allegati alla
+guida) che permettono rispettivamente di creare e rimuovere un \textsl{file di
+  lock}. Come si può notare entrambe le funzioni sono elementari; la prima
+(\texttt{\small 4--10}) si limita ad aprire il file di lock (\texttt{\small
+  9}) nella modalità descritta, mentre la seconda (\texttt{\small 11--17}) lo
+cancella con \func{unlink}.
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \begin{lstlisting}{} 
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>                               /* unix standard functions */
+/*
+ * Function LockFile:
+ */
+int LockFile(const char* path_name)
+{
+    return open(path_name, O_EXCL|O_CREAT);
+}
+/*
+ * Function UnlockFile:
+ */
+int UnlockFile(const char* path_name) 
+{
+    return unlink(path_name);
+}
+    \end{lstlisting}
+  \end{minipage} 
+  \normalsize 
+  \caption{Il codice delle funzioni \func{LockFile} e \func{UnlockFile} che
+    permettono di creare e rimuovere un \textsl{file di lock}.}
+  \label{fig:ipc_file_lock}
+\end{figure}
+
+Uno dei limiti di questa tecnica è che, come abbiamo già accennato in
+\secref{sec:file_open}, questo comportamento di \func{open} può non funzionare
+(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
+\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
+solo se si opera all'interno di uno stesso filesystem.
+
+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 in caso di terminazione 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 ha comunque una sua utilità, e può essere 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 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|)}
+
+
+\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 di sincronizzazione più comune è quella di fare ricorso
+al \textit{file 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
-chiusura dei relativi file) e non ci si deve preoccupare di niente, e non
-consuma risorse permanentemente allocate nel sistema, lo svantaggio è che
+chiusura dei relativi file) e non ci si deve preoccupare di niente, inoltre
+non consuma risorse permanentemente allocate nel sistema, lo svantaggio è che
 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 
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \begin{lstlisting}{} 
+/* Function CreateMutex: Create a mutex using file locking. */
+int CreateMutex(const char *path_name)
+{
+    return open(path_name, O_EXCL|O_CREAT);
+}
+/* Function UnlockMutex: unlock a file. */
+int FindMutex(const char *path_name)
+{
+    return open(path_name, O_RDWR);
+}
+/* Function LockMutex: lock mutex using file locking. */
+int LockMutex(int fd)
+{
+    struct flock lock;                                /* file lock structure */
+    /* first open the file (creating it if not existent) */
+    /* set flock structure */
+    lock.l_type = F_WRLCK;                        /* set type: read or write */
+    lock.l_whence = SEEK_SET;        /* start from the beginning of the file */
+    lock.l_start = 0;                  /* set the start of the locked region */
+    lock.l_len = 0;                   /* set the length of the locked region */
+    /* do locking */
+    return fcntl(fd, F_SETLKW, &lock);
+}
+/* Function UnlockMutex: unlock a file. */
+int UnlockMutex(int fd)
+{
+    struct flock lock;                                /* file lock structure */
+    /* set flock structure */
+    lock.l_type = F_UNLCK;                               /* set type: unlock */
+    lock.l_whence = SEEK_SET;        /* start from the beginning of the file */
+    lock.l_start = 0;                  /* set the start of the locked region */
+    lock.l_len = 0;                   /* set the length of the locked region */
+    /* do locking */
+    return fcntl(fd, F_SETLK, &lock);
+}
+/* Function RemoveMutex: remove a mutex (unlinking the lock file). */
+int RemoveMutex(const char *path_name)
+{
+    return unlink(path_name);
+}
+/* Function ReadMutex: read a mutex status. */
+int ReadMutex(int fd)
+{
+    int res;
+    struct flock lock;                                /* file lock structure */
+    /* set flock structure */
+    lock.l_type = F_WRLCK;                               /* set type: unlock */
+    lock.l_whence = SEEK_SET;        /* start from the beginning of the file */
+    lock.l_start = 0;                  /* set the start of the locked region */
+    lock.l_len = 0;                   /* set the length of the locked region */
+    /* do locking */
+    if ( (res = fcntl(fd, F_GETLK, &lock)) ) {
+        return res;
+    }
+    return lock.l_type;
+}
+    \end{lstlisting}
+  \end{minipage} 
+  \normalsize 
+  \caption{Il codice delle funzioni che permettono di creare un
+    \textit{mutex} utilizzando il file locking\index{file!locking}.}
+  \label{fig:ipc_flock_mutex}
+\end{figure}
+
+Il codice delle varie funzioni definite per implementare un mutex utilizzando
+il file locking\index{file!locking} è riportato in
+\figref{fig:ipc_flock_mutex}; si è mantenuta una struttura analoga a quelle
+viste in precedenza, anche se le due interfacce non possono essere
+completamente equivalenti, specie per quanto riguarda la rimozione del 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
+bloccherà (si noti che la si è chiamata con \func{F\_SETLKW}) fino al rilascio
+del lock.
+
+La seconda funzione (\texttt{\small 23--44}) serve a rilasciare il mutex. Di
+nuovo si apre (\texttt{\small 30--33}) il file specificato dall'argomento
+\param{pathname} (che stavolta deve esistere), ritornando immediatamente in
+caso di errore. Poi si passa ad inizializzare (\texttt{\small 34--38}) la
+struttura \var{lock} per il rilascio del lock, che viene effettuato
+(\texttt{\small 39--42}) subito dopo.
 
 
 \subsection{Il \textit{memory mapping} anonimo}
 \label{sec:ipc_mmap_anonymous}
 
-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 
+Abbiamo già visto che quando i processi sono \textsl{correlati}\footnote{se
+  cioè hanno almeno un progenitore comune.} l'uso delle pipe può costituire
+una valida alternativa alle code di messaggi; nella stessa situazione si può
+evitare l'uso di una memoria condivisa facendo ricorso al cosiddetto
+\textit{memory mapping} anonimo.
+
+Abbiamo visto in \secref{sec:file_memory_map} che è possibile mappare il
+contenuto di un file nella memoria di un processo, e che, quando viene usato
+il flag \const{MAP\_SHARED}, le modifiche effettuate al contenuto del file
+vengono viste da tutti i processi che lo hanno mappato. Utilizzare questa
+tecnica per creare una memoria condivisa fra processi diversi è estremamente
+inefficiente, in quanto occorre passare attraverso il disco. Però abbiamo
+visto anche che se si esegue la mappatura con il flag \const{MAP\_ANONYMOUS}
+la regione mappata non viene associata a nessun file, anche se quanto scritto
+rimane in memoria e può essere riletto; allora, dato che un processo figlio
+mantiene nel suo spazio degli indirizzi anche le regioni mappate, esso sarà
+anche in grado di accedere a quanto in esse è contenuto.
+
+In questo modo diventa possibile creare una memoria condivisa fra processi
+diversi, purché questi abbiano almeno un progenitore comune che ha effettuato
+il \textit{memory mapping} anonimo.\footnote{nei sistemi derivati da SysV una
+  funzionalità simile a questa viene implementata mappando il file speciale
+  \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
+  nel \textit{memory mapping} anonimo.} Un esempio di utilizzo di questa
+tecnica è mostrato in 
+
 
 
 \section{La comunicazione fra processi di POSIX}
@@ -3032,21 +3528,23 @@ una interfaccia completamente nuova, che tratteremo in questa sezione.
 
 Il Linux non tutti gli oggetti del POSIX IPC sono supportati nel kernel
 ufficiale; solo la memoria condivisa è presente, ma solo a partire dal kernel
-2.4.x, per gli altri oggetti esistono patch e librerie non
-ufficiali. Nonostante questo è importante esaminare questa interfaccia per la
-sua netta superiorità nei confronti di quella del \textit{SysV IPC}.
+2.4.x, per gli altri oggetti esistono patch e librerie non ufficiali.
+Nonostante questo è importante esaminare questa interfaccia per la sua netta
+superiorità nei confronti di quella del \textit{SysV IPC}.
 
 
 \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.
 
 
 
@@ -3055,7 +3553,9 @@ 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}