From fe017ba5da165123761dbb85036ad3ed8bbd7ad2 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Thu, 7 Nov 2002 23:31:45 +0000 Subject: [PATCH] Aggiunti alcuni header alla lista e quattro chiacchiere sulle alternative alle message queue --- intro.tex | 23 +++++++++++------- ipc.tex | 69 +++++++++++++++++++++++++++++++++++------------------- system.tex | 12 +++++----- 3 files changed, 65 insertions(+), 39 deletions(-) diff --git a/intro.tex b/intro.tex index 9c682f7..cc730a2 100644 --- a/intro.tex +++ b/intro.tex @@ -293,11 +293,16 @@ qualunque sistema operativo. Per questo motivo, anche se lo standard non ha alcun riferimento ad un sistema di tipo Unix, GNU/Linux (per essere precisi le \acr{glibc}), come molti Unix moderni, provvede la compatibilità con questo standard, fornendo le funzioni -di libreria da esso previste. Queste sono dichiarate in quindici header file -(anch'essi provvisti dalla \acr{glibc}), uno per ciascuna delle quindici aree -in cui è stata suddivisa una libreria standard. In -\tabref{tab:intro_posix_header} si sono riportati questi header, insieme a -quelli definiti negli altri standard descritti nelle sezioni successive. +di libreria da esso previste. Queste sono dichiarate in una serie di +\textit{header file}\footnote{i file di dichiarazione di variabili, tipi e + funzioni, usati normalmente da un compilatore C. Per poter accedere alle + funzioni occorre includere con la direttiva \code{\#include} questi file nei + propri programmi; per ciascuna funzione che tratteremo in seguito + indicheremo anche gli \textit{header file} necessari ad usarla.} (anch'essi +provvisti dalla \acr{glibc}), In \tabref{tab:intro_posix_header} si sono +riportati i principali \textit{header file} definiti nello standard POSIX, +insieme a quelli definiti negli altri standard descritti nelle sezioni +successive. \begin{table}[htb] \footnotesize @@ -309,9 +314,8 @@ quelli definiti negli altri standard descritti nelle sezioni successive. \hline \file{assert.h}& Verifica le asserzioni fatte in un programma.\\ \file{cpio.h} & .\\ - \file{} & .\\ - \file{} & .\\ - \file{} & .\\ + \file{dirent.h}& .\\ + \file{errno.h} & .\\ \file{} & .\\ \file{} & .\\ \file{} & .\\ @@ -320,9 +324,10 @@ quelli definiti negli altri standard descritti nelle sezioni successive. \file{} & .\\ \file{stdio.h} & I/O bufferizzato in standard ANSI C.\\ \file{stdlib.h}& definizioni della libreria standard.\\ + \file{unistd.h}& .\\ \hline \end{tabular} - \caption{Elenco dei vari file di include definiti dallo standard POSIX.} + \caption{Elenco dei vari header file definiti dallo standard POSIX.} \label{tab:intro_posix_header} \end{table} diff --git a/ipc.tex b/ipc.tex index f3fb316..d8ffa5f 100644 --- a/ipc.tex +++ b/ipc.tex @@ -2609,10 +2609,10 @@ attraverso l'argomento \param{cmd}, i valori possibili sono i seguenti: 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 si usano due funzioni, la prima -di queste è \func{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 è: +Per utilizzare i segmenti di memoria condivisa l'interfaccia prevede due +funzioni, la prima è \func{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} \headdecl{sys/types.h} \headdecl{sys/shm.h} @@ -2696,14 +2696,15 @@ Come accennato in \secref{sec:proc_fork} un segmento di memoria condivisa agganciato ad un precesso viene ereditato da un figlio attraverso una \func{fork}, dato che quest'ultimo riceve una copia dello spazio degli indirizzi del padre. Invece, dato che attraverso una \func{exec} viene -eseguito un diverso programma, tutti i segmenti eventualmente agganciati al -processo vengono automaticamente sganciati. Lo stesso avviene all'uscita del -processo attraverso una \func{exit}. +eseguito un diverso programma con uno spazio di indirizzi completamente +diverso, tutti i segmenti agganciati al processo originario vengono +automaticamente sganciati. Lo stesso avviene all'uscita del processo +attraverso una \func{exit}. -La seconda funzione è \func{shmdt}, che consente di sganciare un segmento di -memoria condivisa dal processo chiamante quando questo non è più necessario, -il suo prototipo è: +Una volta che un segmento di memoria condivisa non serve più si può sganciarlo +esplicitamente dal processo usando la seconda funzione dell'interfaccia, +\func{shmdt}, il cui il suo prototipo è: \begin{functions} \headdecl{sys/types.h} \headdecl{sys/shm.h} @@ -2711,19 +2712,16 @@ il suo prototipo \funcdecl{int shmdt(const void *shmaddr)} Sgancia dal processo un segmento di memoria condivisa. - \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di + \bodydesc{La funzione restituisce 0 in caso di succes so, 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}.} \end{functions} -La funzione esegue lo sganciamento del segmento di memoria condivisa -agganciato all'indirizzo \param{shmaddr}; quest'ultimo deve essere uguale -all'indirizzo ottenuto da una precedente chiamata a \func{shmat}. - - - - +La funzione sgancia dallo spazio degli indirizzi del processo un segmento di +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 @@ -2734,26 +2732,49 @@ condivisa; uno schema semplificato della struttura \begin{figure}[htb] \centering \includegraphics[width=10cm]{img/shmstruct} - \caption{Schema dell'implementazione dei segmenti di memoria condivisa in + \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 sistema di IPC di -System V presenta numerosi problemi; in \cite{APUE}\footnote{nel capitolo 14.} -Stevens effettua una accurata analisi (i cui concetti sono già stati accennati -in precedenza) ed elenca alcune possibili alternative, che vogliamo riprendere -in questa sezione. +System V 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 +alternative, che vogliamo riprendere in questa sezione. + + +\subsection{Alternative alle code di messaggi} +\label{sec:ipc_mq_alternative} + +Le code di messaggi sono probabilmente il meno usato degli oggetti di IPC di +System V; esse infatti nacquero principalmente come meccanismo di +comunicazione bidirezionale quando ancora le pipe erano ancora unidirezionali; +abbiamo visto però in \secref{sec:ipc_socketpair} che la funzione +\func{socketpair} permette di fare la stessa cosa senza incorrere nelle +complicazioni introdotte dal sistema di IPC di System V. + +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 cose che sono +impossibili da ottenere con le pipe e i socket di \func{socketpair}. + +È però possibile implementare un meccanismo analogo attraverso l'uso di +memoria condivisa e di meccanismi di sincronizzazione, (un esempio di +reimplementazione di code di messaggi usando il \textit{memory mapping} e i +semafori si trova in \cite{UNP2}). pertanto non è \subsection{La sincronizzazione con il \textit{file locking}} \label{sec:ipc_file_lock} -Abbiamo esaminato il \textit{file locking} in \secref{sec:file_locking}, +Abbiamo esaminato il \textit{file locking} in \secref{sec:file_locking}, diff --git a/system.tex b/system.tex index c474854..07e74f7 100644 --- a/system.tex +++ b/system.tex @@ -878,8 +878,8 @@ Queste funzioni permettono di ottenere una serie di informazioni generali riguardo al filesystem su cui si trova il file specificato; queste vengono restituite una struttura \param{buf} di tipo \type{statfs} definita come in \ref{fig:sys_statfs}, ed i campi che sono indefiniti per il filesystem in -esame sono impostati a zero. I valori del campo \var{f\_type} sono definiti per -i vari filesystem nei relativi file di header dei sorgenti del kernel da +esame sono impostati a zero. I valori del campo \var{f\_type} sono definiti +per i vari filesystem nei relativi file di header dei sorgenti del kernel da costanti del tipo \macro{XXX\_SUPER\_MAGIC}, dove \macro{XXX} in genere è il nome del filesystem stesso. @@ -1475,10 +1475,10 @@ struct rlimit { \end{figure} In genere il superamento di un limite comporta o l'emissione di un segnale o -il fallimento della system call che lo ha provocato; per far leggere o impostare -i limiti di utilizzo delle risorse da parte di un processo le \acr{glibc} -prevedono due funzioni, \func{getrlimit} e \func{setrlimit}, i cui prototipi -sono: +il fallimento della system call che lo ha provocato; per far leggere o +impostare i limiti di utilizzo delle risorse da parte di un processo le +\acr{glibc} prevedono due funzioni, \func{getrlimit} e \func{setrlimit}, i cui +prototipi sono: \begin{functions} \headdecl{sys/time.h} \headdecl{sys/resource.h} -- 2.30.2