Ancora reindicizzazioni

[gapil.git] / ipc.tex

diff --git a/ipc.tex b/ipc.tex
index 9b7ac1a21a90ed2c395f4542f728556604db5f25..7520e3300f590af435762bb65bba1d707c1bb89e 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -1088,7 +1088,7 @@ solo se tutti i controlli elencati falliscono l'accesso è negato. Si noti che
 a differenza di quanto avviene per i permessi dei file, fallire in uno dei
 passi elencati non comporta il fallimento dell'accesso. Un'ulteriore
 differenza rispetto a quanto avviene per i file è che per gli oggetti di IPC
 a differenza di quanto avviene per i permessi dei file, fallire in uno dei
 passi elencati non comporta il fallimento dell'accesso. Un'ulteriore
 differenza rispetto a quanto avviene per i file è che per gli oggetti di IPC

-il valore di \itindex{umask} \textit{umask} (si ricordi quanto esposto in
+il valore di \textit{umask} (si ricordi quanto esposto in

 sez.~\ref{sec:file_perm_management}) non ha alcun significato.
 
 
 sez.~\ref{sec:file_perm_management}) non ha alcun significato.
 
 


@@ -1127,8 +1127,8 @@ Il sistema dispone sempre di un numero fisso di oggetti di IPC, fino al kernel
 \const{SHMMNI}, e potevano essere cambiati (come tutti gli altri limiti
 relativi al \textit{SysV-IPC}) solo con una ricompilazione del kernel.  A
 partire dal kernel 2.4.x è possibile cambiare questi valori a sistema attivo
 \const{SHMMNI}, e potevano essere cambiati (come tutti gli altri limiti
 relativi al \textit{SysV-IPC}) solo con una ricompilazione del kernel.  A
 partire dal kernel 2.4.x è possibile cambiare questi valori a sistema attivo

-scrivendo sui file \sysctlrelfile{kernel}{shmmni},
-\sysctlrelfile{kernel}{msgmni} e \sysctlrelfile{kernel}{sem} di
+scrivendo sui file \sysctlrelfiled{kernel}{shmmni},
+\sysctlrelfiled{kernel}{msgmni} e \sysctlrelfiled{kernel}{sem} di

 \file{/proc/sys/kernel} o con l'uso di \func{sysctl}.
 
 \begin{figure}[!htb]
 \file{/proc/sys/kernel} o con l'uso di \func{sysctl}.
 
 \begin{figure}[!htb]


@@ -1308,8 +1308,8 @@ Le code di messaggi sono caratterizzate da tre limiti fondamentali, un tempo
 definiti staticamente e corrispondenti alle prime tre costanti riportate in
 tab.~\ref{tab:ipc_msg_limits}.  Come accennato però con tutte le versioni più
 recenti del kernel con Linux è possibile modificare questi limiti attraverso
 definiti staticamente e corrispondenti alle prime tre costanti riportate in
 tab.~\ref{tab:ipc_msg_limits}.  Come accennato però con tutte le versioni più
 recenti del kernel con Linux è possibile modificare questi limiti attraverso

-l'uso di \func{sysctl} o scrivendo nei file \sysctlrelfile{kernel}{msgmax},
-\sysctlrelfile{kernel}{msgmnb} e \sysctlrelfile{kernel}{msgmni} di
+l'uso di \func{sysctl} o scrivendo nei file \sysctlrelfiled{kernel}{msgmax},
+\sysctlrelfiled{kernel}{msgmnb} e \sysctlrelfiled{kernel}{msgmni} di

 \file{/proc/sys/kernel/}.
 
 \itindbeg{linked~list}
 \file{/proc/sys/kernel/}.
 
 \itindbeg{linked~list}


@@ -1327,7 +1327,7 @@ coda alla lista e vengono letti dalla cima, in fig.~\ref{fig:ipc_mq_schema} si
 dal kernel. Lo schema illustrato in realtà è una semplificazione di quello
 usato fino ai kernel della serie 2.2. A partire della serie 2.4 la gestione
 delle code di messaggi è effettuata in maniera diversa (e non esiste una
 dal kernel. Lo schema illustrato in realtà è una semplificazione di quello
 usato fino ai kernel della serie 2.2. A partire della serie 2.4 la gestione
 delle code di messaggi è effettuata in maniera diversa (e non esiste una

-struttura \struct{msqid\_ds} nel kernel), ma abbiamo mantenuto lo schema
+struttura \kstruct{msqid\_ds} nel kernel), ma abbiamo mantenuto lo schema

 precedente dato che illustra in maniera più che adeguata i principi di
 funzionamento delle code di messaggi.
 
 precedente dato che illustra in maniera più che adeguata i principi di
 funzionamento delle code di messaggi.
 


@@ -1335,12 +1335,13 @@ funzionamento delle code di messaggi.
 
 \begin{figure}[!htb]
   \centering \includegraphics[width=13cm]{img/mqstruct}
 
 \begin{figure}[!htb]
   \centering \includegraphics[width=13cm]{img/mqstruct}

-  \caption{Schema della struttura di una coda messaggi.}
+  \caption{Schema delle strutture di una coda di messaggi
+    (\kstructd{msqid\_ds} e \kstructd{msg}).}

   \label{fig:ipc_mq_schema}
 \end{figure}
 
 
   \label{fig:ipc_mq_schema}
 \end{figure}
 
 

-A ciascuna coda è associata una struttura \struct{msqid\_ds} la cui
+A ciascuna coda è associata una struttura \kstruct{msqid\_ds} la cui

 definizione è riportata in fig.~\ref{fig:ipc_msqid_ds} ed a cui si accede
 includendo \headfiled{sys/msg.h};
 %
 definizione è riportata in fig.~\ref{fig:ipc_msqid_ds} ed a cui si accede
 includendo \headfiled{sys/msg.h};
 %


@@ -1536,13 +1537,13 @@ dovrà essere pari a \const{LENGTH}).
 
 Per capire meglio il funzionamento della funzione riprendiamo in
 considerazione la struttura della coda illustrata in
 
 Per capire meglio il funzionamento della funzione riprendiamo in
 considerazione la struttura della coda illustrata in

-fig.~\ref{fig:ipc_mq_schema}. Alla chiamata di \func{msgsnd} il nuovo messaggio
-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}.
+fig.~\ref{fig:ipc_mq_schema}. Alla chiamata di \func{msgsnd} il nuovo
+messaggio sarà aggiunto in fondo alla lista inserendo una nuova struttura
+\kstruct{msg}, il puntatore \var{msg\_last} di \kstruct{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}.

 
 Il valore dell'argomento \param{flag} permette di specificare il comportamento
 della funzione. Di norma, quando si specifica un valore nullo, la funzione
 
 Il valore dell'argomento \param{flag} permette di specificare il comportamento
 della funzione. Di norma, quando si specifica un valore nullo, la funzione


@@ -1668,8 +1669,7 @@ possono essere utilizzate, e non si ha a disposizione niente di analogo alle
 funzioni \func{select} e \func{poll}. Questo rende molto scomodo usare più di
 una di queste strutture alla volta; ad esempio non si può scrivere un server
 che aspetti un messaggio su più di una coda senza fare ricorso ad una tecnica
 funzioni \func{select} e \func{poll}. Questo rende molto scomodo usare più di
 una di queste strutture alla volta; ad esempio non si può scrivere un server
 che aspetti un messaggio su più di una coda senza fare ricorso ad una tecnica

-di \itindex{polling} \textit{polling} che esegua un ciclo di attesa su
-ciascuna di esse.
+di \textit{polling} che esegua un ciclo di attesa su ciascuna di esse.

 
 Come esempio dell'uso delle code di messaggi possiamo riscrivere il nostro
 server di \textit{fortunes} usando queste al posto delle \textit{fifo}. In
 
 Come esempio dell'uso delle code di messaggi possiamo riscrivere il nostro
 server di \textit{fortunes} usando queste al posto delle \textit{fifo}. In


@@ -2408,18 +2408,20 @@ versioni delle librerie del C, come le \acr{libc5}).
 
 \begin{figure}[!htb]
   \centering \includegraphics[width=12cm]{img/semtruct}
 
 \begin{figure}[!htb]
   \centering \includegraphics[width=12cm]{img/semtruct}

-  \caption{Schema della struttura di un insieme di semafori.}
+  \caption{Schema delle varie strutture di un insieme di semafori
+    (\kstructd{semid\_ds}, \kstructd{sem}, \kstructd{sem\_queue} e
+    \kstructd{sem\_undo}).}

   \label{fig:ipc_sem_schema}
 \end{figure}
 
 Alla creazione di un nuovo insieme viene allocata una nuova strutture
   \label{fig:ipc_sem_schema}
 \end{figure}
 
 Alla creazione di un nuovo insieme viene allocata una nuova strutture

-\struct{semid\_ds} ed il relativo vettore di strutture \struct{sem}. Quando si
-richiede una operazione viene anzitutto verificato che tutte le operazioni
+\kstruct{semid\_ds} ed il relativo vettore di strutture \kstruct{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 \kstruct{sem\_queue} che viene aggiunta in fondo
 alla coda di attesa associata a ciascun insieme di semafori, che viene
 referenziata tramite i campi \var{sem\_pending} e \var{sem\_pending\_last} di
 possono avere successo; se una di esse comporta il blocco del processo il
 kernel crea una struttura \kstruct{sem\_queue} che viene aggiunta in fondo
 alla coda di attesa associata a ciascun insieme di semafori, che viene
 referenziata tramite i campi \var{sem\_pending} e \var{sem\_pending\_last} di

-\struct{semid\_ds}.  Nella struttura viene memorizzato il riferimento alle
+\kstruct{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
 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


@@ -2539,7 +2541,7 @@ controllare il valore dei mutex prima di proseguire in una operazione di
 sblocco non servirebbe comunque, dato che l'operazione non sarebbe atomica.
 Vedremo in sez.~\ref{sec:ipc_lock_file} come sia possibile ottenere
 un'interfaccia analoga a quella appena illustrata, senza incorrere in questi
 sblocco non servirebbe comunque, dato che l'operazione non sarebbe atomica.
 Vedremo in sez.~\ref{sec:ipc_lock_file} come sia possibile ottenere
 un'interfaccia analoga a quella appena illustrata, senza incorrere in questi

-problemi, usando il \itindex{file~locking} \textit{file locking}.
+problemi, usando il \textit{file locking}.

 
 
 \subsection{Memoria condivisa}
 
 
 \subsection{Memoria condivisa}


@@ -3388,8 +3390,8 @@ 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à
 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 \itindex{polling}
-\textit{polling}, ed è quindi molto inefficiente.
+può essere eseguito solo con una tecnica di \textit{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
 
 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


@@ -3406,15 +3408,14 @@ accedere alla seriale si limita a segnalare che la risorsa non è disponibile.
 
 Dato che i file di lock presentano gli inconvenienti illustrati in precedenza,
 la tecnica alternativa di sincronizzazione più comune è quella di fare ricorso
 
 Dato che i file di lock presentano gli inconvenienti illustrati in precedenza,
 la tecnica alternativa di sincronizzazione più comune è quella di fare ricorso

-al \itindex{file~locking} \textit{file locking} (trattato in
-sez.~\ref{sec:file_locking}) usando \func{fcntl} su un file creato per
-l'occasione per ottenere un write lock. In questo modo potremo usare il lock
-come un \textit{mutex}: per bloccare la risorsa basterà acquisire il lock, per
-sbloccarla basterà rilasciare il lock. Una richiesta fatta con un write lock
-metterà automaticamente il processo in stato di attesa, senza necessità di
-ricorrere al \itindex{polling} \textit{polling} per determinare la
-disponibilità della risorsa, e al rilascio della stessa da parte del processo
-che la occupava si otterrà il nuovo lock atomicamente.
+al \textit{file locking} (trattato in sez.~\ref{sec:file_locking}) usando
+\func{fcntl} su un file creato per l'occasione per ottenere un write lock. In
+questo modo potremo usare il lock come un \textit{mutex}: per bloccare la
+risorsa basterà acquisire il lock, per sbloccarla basterà rilasciare il
+lock. Una richiesta fatta con un write lock metterà automaticamente il
+processo in stato di attesa, senza necessità di ricorrere al \textit{polling}
+per determinare la disponibilità della risorsa, e al rilascio della stessa da
+parte del processo che la occupava si otterrà il nuovo lock atomicamente.

 
 Questo approccio presenta il notevole vantaggio che alla terminazione di un
 processo tutti i lock acquisiti vengono rilasciati automaticamente (alla
 
 Questo approccio presenta il notevole vantaggio che alla terminazione di un
 processo tutti i lock acquisiti vengono rilasciati automaticamente (alla


@@ -3429,17 +3430,16 @@ leggermente più lento.
     \includecodesample{listati/MutexLocking.c}
   \end{minipage} 
   \normalsize 
     \includecodesample{listati/MutexLocking.c}
   \end{minipage} 
   \normalsize 

-  \caption{Il codice delle funzioni che permettono per la gestione dei 
-    \textit{mutex} con il \itindex{file~locking} \textit{file locking}.}
+  \caption{Il codice delle funzioni che permettono per la gestione dei
+    \textit{mutex} con il \textit{file locking}.}

   \label{fig:ipc_flock_mutex}
 \end{figure}
 
 Il codice delle varie funzioni usate per implementare un mutex utilizzando il
   \label{fig:ipc_flock_mutex}
 \end{figure}
 
 Il codice delle varie funzioni usate per implementare un mutex utilizzando il

-\textit{file locking} \itindex{file~locking} è riportato in
-fig.~\ref{fig:ipc_flock_mutex}; si è mantenuta volutamente una struttura
-analoga alle precedenti funzioni che usano i semafori, anche se le due
-interfacce non possono essere completamente equivalenti, specie per quanto
-riguarda la rimozione del mutex.
+\textit{file locking} è riportato in fig.~\ref{fig:ipc_flock_mutex}; si è
+mantenuta volutamente una struttura analoga alle precedenti funzioni che usano
+i semafori, anche se le due interfacce non possono essere completamente
+equivalenti, specie per quanto riguarda la rimozione del mutex.

 
 La prima funzione (\texttt{\small 1-5}) è \func{CreateMutex}, e serve a
 creare il mutex; la funzione è estremamente semplice, e si limita
 
 La prima funzione (\texttt{\small 1-5}) è \func{CreateMutex}, e serve a
 creare il mutex; la funzione è estremamente semplice, e si limita


@@ -3452,9 +3452,9 @@ mutex.
 La seconda funzione (\texttt{\small 6-10}) è \func{FindMutex}, che, come la
 precedente, è stata definita per mantenere una analogia con la corrispondente
 funzione basata sui semafori. Anch'essa si limita (\texttt{\small 9}) ad
 La seconda funzione (\texttt{\small 6-10}) è \func{FindMutex}, che, come la
 precedente, è stata definita per mantenere una analogia con la corrispondente
 funzione basata sui semafori. Anch'essa si limita (\texttt{\small 9}) ad

-aprire il file da usare per il \itindex{file~locking} \textit{file locking},
-solo che in questo caso le opzioni di \func{open} sono tali che il file in
-questione deve esistere di già.
+aprire il file da usare per il \textit{file locking}, solo che in questo caso
+le opzioni di \func{open} sono tali che il file in questione deve esistere di
+già.

 
 La terza funzione (\texttt{\small 11-22}) è \func{LockMutex} e serve per
 acquisire il mutex. La funzione definisce (\texttt{\small 14}) e inizializza
 
 La terza funzione (\texttt{\small 11-22}) è \func{LockMutex} e serve per
 acquisire il mutex. La funzione definisce (\texttt{\small 14}) e inizializza


@@ -3469,10 +3469,9 @@ La quarta funzione (\texttt{\small 24-34}) è \func{UnlockMutex} e serve a
 rilasciare il mutex. La funzione è analoga alla precedente, solo che in questo
 caso si inizializza (\texttt{\small 28-31}) la struttura \var{lock} per il
 rilascio del lock, che viene effettuato (\texttt{\small 33}) con la opportuna
 rilasciare il mutex. La funzione è analoga alla precedente, solo che in questo
 caso si inizializza (\texttt{\small 28-31}) la struttura \var{lock} per il
 rilascio del lock, che viene effettuato (\texttt{\small 33}) con la opportuna

-chiamata a \func{fcntl}. Avendo usato il \itindex{file~locking} \textit{file
-  locking} in semantica POSIX (si riveda quanto detto
-sez.~\ref{sec:file_posix_lock}) solo il processo che ha precedentemente
-eseguito il lock può sbloccare il mutex.
+chiamata a \func{fcntl}. Avendo usato il \textit{file locking} in semantica
+POSIX (si riveda quanto detto sez.~\ref{sec:file_posix_lock}) solo il processo
+che ha precedentemente eseguito il lock può sbloccare il mutex.

 
 La quinta funzione (\texttt{\small 36-39}) è \func{RemoveMutex} e serve a
 cancellare il mutex. Anche questa funzione è stata definita per mantenere una
 
 La quinta funzione (\texttt{\small 36-39}) è \func{RemoveMutex} e serve a
 cancellare il mutex. Anche questa funzione è stata definita per mantenere una


@@ -3510,11 +3509,13 @@ nessun inconveniente.
 \subsection{Il \textit{memory mapping} anonimo}
 \label{sec:ipc_mmap_anonymous}
 
 \subsection{Il \textit{memory mapping} anonimo}
 \label{sec:ipc_mmap_anonymous}
 

-\itindbeg{memory~mapping} Abbiamo già visto che quando i processi sono
-\textsl{correlati}, se cioè hanno almeno un progenitore comune, l'uso delle
-\textit{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.
+\itindbeg{memory~mapping} 
+
+Abbiamo già visto che quando i processi sono \textsl{correlati}, se cioè hanno
+almeno un progenitore comune, l'uso delle \textit{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.

 
 In sez.~\ref{sec:file_memory_map} abbiamo visto come sia possibile mappare il
 contenuto di un file nella memoria di un processo, e che, quando viene usato
 
 In sez.~\ref{sec:file_memory_map} abbiamo visto come sia possibile mappare il
 contenuto di un file nella memoria di un processo, e che, quando viene usato


@@ -3540,6 +3541,7 @@ il \textit{memory mapping} anonimo.\footnote{nei sistemi derivati da SysV una
   nel \textit{memory mapping} anonimo.} Vedremo come utilizzare questa tecnica
 più avanti, quando realizzeremo una nuova versione del monitor visto in
 sez.~\ref{sec:ipc_sysv_shm} che possa restituisca i risultati via rete.
   nel \textit{memory mapping} anonimo.} Vedremo come utilizzare questa tecnica
 più avanti, quando realizzeremo una nuova versione del monitor visto in
 sez.~\ref{sec:ipc_sysv_shm} che possa restituisca i risultati via rete.

+

 \itindend{memory~mapping}
 
 % TODO: fare esempio di mmap anonima
 \itindend{memory~mapping}
 
 % TODO: fare esempio di mmap anonima


@@ -3570,9 +3572,8 @@ una interfaccia completamente nuova, che tratteremo in questa sezione.
 Oggi Linux supporta tutti gli oggetti definito nello standard POSIX per l'IPC,
 ma a lungo non è stato così; la memoria condivisa è presente a partire dal
 kernel 2.4.x, i semafori sono forniti dalla \acr{glibc} nella sezione che
 Oggi Linux supporta tutti gli oggetti definito nello standard POSIX per l'IPC,
 ma a lungo non è stato così; la memoria condivisa è presente a partire dal
 kernel 2.4.x, i semafori sono forniti dalla \acr{glibc} nella sezione che

-implementa i \itindex{thread} \textit{thread} POSIX di nuova generazione che
-richiedono il kernel 2.6, le code di messaggi sono supportate a partire dal
-kernel 2.6.6.
+implementa i \textit{thread} POSIX di nuova generazione che richiedono il
+kernel 2.6, le code di messaggi sono supportate a partire dal kernel 2.6.6.

 
 La caratteristica fondamentale dell'interfaccia POSIX è l'abbandono dell'uso
 degli identificatori e delle chiavi visti nel \textit{SysV-IPC}, per passare ai
 
 La caratteristica fondamentale dell'interfaccia POSIX è l'abbandono dell'uso
 degli identificatori e delle chiavi visti nel \textit{SysV-IPC}, per passare ai


@@ -3702,7 +3703,7 @@ una coda di messaggi POSIX è \funcd{mq\_open}, ed il suo prototipo è:
 La funzione apre la coda di messaggi identificata dall'argomento \param{name}
 restituendo il descrittore ad essa associato, del tutto analogo ad un file
 descriptor, con l'unica differenza che lo standard prevede un apposito tipo
 La funzione apre la coda di messaggi identificata dall'argomento \param{name}
 restituendo il descrittore ad essa associato, del tutto analogo ad un file
 descriptor, con l'unica differenza che lo standard prevede un apposito tipo

-\type{mqd\_t}. Nel caso di Linux si tratta in effetti proprio di un normale
+\typed{mqd\_t}. Nel caso di Linux si tratta in effetti proprio di un normale

 file descriptor; pertanto, anche se questo comportamento non è portabile, lo
 si può tenere sotto osservazione con le funzioni dell'I/O multiplexing (vedi
 sez.~\ref{sec:file_multiplexing}) come possibile alternativa all'uso
 file descriptor; pertanto, anche se questo comportamento non è portabile, lo
 si può tenere sotto osservazione con le funzioni dell'I/O multiplexing (vedi
 sez.~\ref{sec:file_multiplexing}) come possibile alternativa all'uso


@@ -3781,7 +3782,7 @@ I suddetti limiti di sistema sono impostati attraverso altrettanti file in
 \texttt{/proc/sys/fs/mqueue}, in particolare i file che controllano i valori
 dei limiti sono:
 \begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
 \texttt{/proc/sys/fs/mqueue}, in particolare i file che controllano i valori
 dei limiti sono:
 \begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}

-\item[\sysctlfile{fs/mqueue/msg\_max}] Indica il valore massimo del numero di
+\item[\sysctlfiled{fs/mqueue/msg\_max}] Indica il valore massimo del numero di

   messaggi in una coda e agisce come limite superiore per il valore di
   \var{attr->mq\_maxmsg} in \func{mq\_open}. Il suo valore di default è 10. Il
   valore massimo è \const{HARD\_MAX} che vale \code{(131072/sizeof(void *))},
   messaggi in una coda e agisce come limite superiore per il valore di
   \var{attr->mq\_maxmsg} in \func{mq\_open}. Il suo valore di default è 10. Il
   valore massimo è \const{HARD\_MAX} che vale \code{(131072/sizeof(void *))},


@@ -3790,7 +3791,7 @@ dei limiti sono:
   precisamente con la \textit{capability} \const{CAP\_SYS\_RESOURCE}) ma
   \const{HARD\_MAX} resta comunque non superabile.
 
   precisamente con la \textit{capability} \const{CAP\_SYS\_RESOURCE}) ma
   \const{HARD\_MAX} resta comunque non superabile.
 

-\item[\sysctlfile{fs/mqueue/msgsize\_max}] Indica il valore massimo della
+\item[\sysctlfiled{fs/mqueue/msgsize\_max}] Indica il valore massimo della

   dimensione in byte di un messaggio sulla coda ed agisce come limite
   superiore per il valore di \var{attr->mq\_msgsize} in \func{mq\_open}. Il
   suo valore di default è 8192.  Il valore massimo è 1048576 ed il valore
   dimensione in byte di un messaggio sulla coda ed agisce come limite
   superiore per il valore di \var{attr->mq\_msgsize} in \func{mq\_open}. Il
   suo valore di default è 8192.  Il valore massimo è 1048576 ed il valore


@@ -3799,7 +3800,7 @@ dei limiti sono:
   processi con privilegi amministrativi (con la \textit{capability}
   \const{CAP\_SYS\_RESOURCE}).
 
   processi con privilegi amministrativi (con la \textit{capability}
   \const{CAP\_SYS\_RESOURCE}).
 

-\item[\sysctlfile{fs/mqueue/queues\_max}] Indica il numero massimo di code di
+\item[\sysctlfiled{fs/mqueue/queues\_max}] Indica il numero massimo di code di

   messaggi creabili in totale sul sistema, il valore di default è 256 ma si
   può usare un valore qualunque fra $0$ e \const{INT\_MAX}. Il limite non
   viene applicato ai processi con privilegi amministrativi (cioè con la
   messaggi creabili in totale sul sistema, il valore di default è 256 ma si
   può usare un valore qualunque fra $0$ e \const{INT\_MAX}. Il limite non
   viene applicato ai processi con privilegi amministrativi (cioè con la


@@ -4381,15 +4382,15 @@ restituendo al chiamante il valore di ritorno.
 \label{sec:ipc_posix_sem}
 
 Fino alla serie 2.4.x del kernel esisteva solo una implementazione parziale
 \label{sec:ipc_posix_sem}
 
 Fino alla serie 2.4.x del kernel esisteva solo una implementazione parziale

-dei semafori POSIX che li realizzava solo a livello di \itindex{thread}
-\textit{thread} e non di processi,\footnote{questo significava che i semafori
-  erano visibili solo all'interno dei \itindex{thread} \textit{thread} creati
-  da un singolo processo, e non potevano essere usati come meccanismo di
-  sincronizzazione fra processi diversi.} fornita attraverso la sezione delle
-estensioni \textit{real-time} della \acr{glibc} (quelle che si accedono
-collegandosi alla libreria \texttt{librt}). Esisteva inoltre una libreria che
-realizzava (parzialmente) l'interfaccia POSIX usando le funzioni dei semafori
-di \textit{SysV-IPC} (mantenendo così tutti i problemi sottolineati in
+dei semafori POSIX che li realizzava solo a livello di \textit{thread} e non
+di processi,\footnote{questo significava che i semafori erano visibili solo
+  all'interno dei \textit{thread} creati da un singolo processo, e non
+  potevano essere usati come meccanismo di sincronizzazione fra processi
+  diversi.} fornita attraverso la sezione delle estensioni \textit{real-time}
+della \acr{glibc} (quelle che si accedono collegandosi alla libreria
+\texttt{librt}). Esisteva inoltre una libreria che realizzava (parzialmente)
+l'interfaccia POSIX usando le funzioni dei semafori di \textit{SysV-IPC}
+(mantenendo così tutti i problemi sottolineati in

 sez.~\ref{sec:ipc_sysv_sem}).
 
 A partire dal kernel 2.5.7 è stato introdotto un meccanismo di
 sez.~\ref{sec:ipc_sysv_sem}).
 
 A partire dal kernel 2.5.7 è stato introdotto un meccanismo di


@@ -4479,10 +4480,9 @@ Si tenga presente che, come accennato in sez.~\ref{sec:ipc_posix_generic}, i
 semafori usano la semantica standard dei file per quanto riguarda i controlli
 di accesso, questo significa che un nuovo semaforo viene sempre creato con
 l'\ids{UID} ed il \ids{GID} effettivo del processo chiamante, e che i permessi
 semafori usano la semantica standard dei file per quanto riguarda i controlli
 di accesso, questo significa che un nuovo semaforo viene sempre creato con
 l'\ids{UID} ed il \ids{GID} effettivo del processo chiamante, e che i permessi

-indicati con \param{mode} vengono filtrati dal valore della \itindex{umask}
-\textit{umask} del processo.  Inoltre per poter aprire un semaforo è
-necessario avere su di esso sia il permesso di lettura che quello di
-scrittura.
+indicati con \param{mode} vengono filtrati dal valore della \textit{umask} del
+processo.  Inoltre per poter aprire un semaforo è necessario avere su di esso
+sia il permesso di lettura che quello di scrittura.

 
 La funzione restituisce in caso di successo un puntatore all'indirizzo del
 semaforo con un valore di tipo \ctyp{sem\_t *}, è questo valore che dovrà
 
 La funzione restituisce in caso di successo un puntatore all'indirizzo del
 semaforo con un valore di tipo \ctyp{sem\_t *}, è questo valore che dovrà


@@ -4623,10 +4623,10 @@ prototipo è:
 
 La funzione incrementa di uno il valore corrente del semaforo indicato
 dall'argomento \param{sem}, se questo era nullo la relativa risorsa risulterà
 
 La funzione incrementa di uno il valore corrente del semaforo indicato
 dall'argomento \param{sem}, se questo era nullo la relativa risorsa risulterà

-sbloccata, cosicché un altro processo (o \itindex{thread} \textit{thread})
-eventualmente bloccato in una \func{sem\_wait} sul semaforo possa essere
-svegliato e rimesso in esecuzione.  Si tenga presente che la funzione è sicura
-per l'uso all'interno di un gestore di segnali (si ricordi quanto detto in
+sbloccata, cosicché un altro processo (o \textit{thread}) eventualmente
+bloccato in una \func{sem\_wait} sul semaforo possa essere svegliato e rimesso
+in esecuzione.  Si tenga presente che la funzione è sicura per l'uso
+all'interno di un gestore di segnali (si ricordi quanto detto in

 sez.~\ref{sec:sig_signal_handler}).
 
 Se invece di operare su un semaforo se ne volesse semplicemente leggere il
 sez.~\ref{sec:sig_signal_handler}).
 
 Se invece di operare su un semaforo se ne volesse semplicemente leggere il


@@ -4757,9 +4757,9 @@ prototipo è:
 La funzione inizializza un semaforo all'indirizzo puntato dall'argomento
 \param{sem}, e come per \func{sem\_open} consente di impostare un valore
 iniziale con \param{value}. L'argomento \param{pshared} serve ad indicare se
 La funzione inizializza un semaforo all'indirizzo puntato dall'argomento
 \param{sem}, e come per \func{sem\_open} consente di impostare un valore
 iniziale con \param{value}. L'argomento \param{pshared} serve ad indicare se

-il semaforo deve essere utilizzato dai \itindex{thread} \textit{thread} di uno
-stesso processo (con un valore nullo) o condiviso fra processi diversi (con un
-valore non nullo).
+il semaforo deve essere utilizzato dai \textit{thread} di uno stesso processo
+(con un valore nullo) o condiviso fra processi diversi (con un valore non
+nullo).

 
 Qualora il semaforo debba essere condiviso dai \textit{thread} di uno stesso
 processo (nel qual caso si parla di \textit{thread-shared semaphore}),
 
 Qualora il semaforo debba essere condiviso dai \textit{thread} di uno stesso
 processo (nel qual caso si parla di \textit{thread-shared semaphore}),


@@ -4805,9 +4805,8 @@ La funzione prende come unico argomento l'indirizzo di un semaforo che deve
 essere stato inizializzato con \func{sem\_init}; non deve quindi essere
 applicata a semafori creati con \func{sem\_open}. Inoltre si deve essere
 sicuri che il semaforo sia effettivamente inutilizzato, la distruzione di un
 essere stato inizializzato con \func{sem\_init}; non deve quindi essere
 applicata a semafori creati con \func{sem\_open}. Inoltre si deve essere
 sicuri che il semaforo sia effettivamente inutilizzato, la distruzione di un

-semaforo su cui sono presenti processi (o \itindex{thread} \textit{thread}) in
-attesa (cioè bloccati in una \func{sem\_wait}) provoca un comportamento
-indefinito.
+semaforo su cui sono presenti processi (o \textit{thread}) in attesa (cioè
+bloccati in una \func{sem\_wait}) provoca un comportamento indefinito.

 
 Si tenga presente infine che utilizzare un semaforo che è stato distrutto con
 \func{sem\_destroy} di nuovo può dare esito a comportamenti indefiniti.  Nel
 
 Si tenga presente infine che utilizzare un semaforo che è stato distrutto con
 \func{sem\_destroy} di nuovo può dare esito a comportamenti indefiniti.  Nel