X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=ipc.tex;h=4b569aadde0975b2a65045b0c8ee8ec8a3513f20;hb=f10ada1c0b49d3bbdb22dbe3a61e27914584d70b;hp=c7af63283aa8f317c9b47ccd05779bfefaf91b3a;hpb=4cbeb0e4fa1d31da798c8e68108eb6785586ab34;p=gapil.git diff --git a/ipc.tex b/ipc.tex index c7af632..4b569aa 100644 --- a/ipc.tex +++ b/ipc.tex @@ -418,13 +418,13 @@ o 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 \index{inode} inode che risiede sul filesystem, così che i +attraverso un \itindex{inode} 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; -\index{inode} l'inode allocato sul filesystem serve infatti solo a fornire un +\itindex{inode} 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 sez.~\ref{sec:ipc_pipes}. @@ -892,7 +892,7 @@ gli 8 bit meno significativi.\footnote{nelle libc4 e libc5, come avviene in 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 \index{inode} dell'inode del file +con i 16 bit meno significativi \itindex{inode} dell'inode del file \param{pathname} (che vengono ottenuti attraverso \func{stat}, da cui derivano i possibili errori), e gli 8 bit meno significativi del numero del dispositivo su cui è il file. Diventa perciò relativamente facile ottenere delle @@ -947,7 +947,7 @@ il proprietario, il suo gruppo e tutti gli altri. Quando l'oggetto viene creato i campi \var{cuid} e \var{uid} di \struct{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono impostati -rispettivamente al valore dell'user-ID e del group-ID effettivo del processo +rispettivamente al valore dell'\acr{uid} e del \acr{gid} 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. @@ -967,12 +967,12 @@ controlli è simile a quello dei file, ed avviene secondo questa sequenza: \begin{itemize*} \item se il processo ha i privilegi di amministratore l'accesso è sempre consentito. -\item se l'user-ID effettivo del processo corrisponde o al valore del campo +\item se l'\acr{uid} 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 è impostato il permesso di scrittura per le operazioni di scrittura e quello di lettura per le operazioni di lettura.} l'accesso è consentito. -\item se il group-ID effettivo del processo corrisponde o al +\item se il \acr{gid} 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. @@ -1021,8 +1021,8 @@ Il sistema dispone sempre di un numero fisso di oggetti di IPC,\footnote{fino 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 \procrelfile{/proc/sys/kernel}{shmmni}, - \procrelfile{/proc/sys/kernel}{msgmni} e \procrelfile{/proc/sys/kernel}{sem} + scrivendo sui file \sysctlrelfile{kernel}{shmmni}, + \sysctlrelfile{kernel}{msgmni} e \sysctlrelfile{kernel}{sem} 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 @@ -1182,9 +1182,9 @@ Le code di messaggi sono caratterizzate da tre limiti fondamentali, definiti negli header e corrispondenti alle prime tre costanti riportate in tab.~\ref{tab:ipc_msg_limits}, come accennato però in Linux è possibile modificare questi limiti attraverso l'uso di \func{sysctl} o scrivendo nei -file \procrelfile{/proc/sys/kernel}{msgmax}, -\procrelfile{/proc/sys/kernel}{msgmnb} e -\procrelfile{/proc/sys/kernel}{msgmni} di \file{/proc/sys/kernel/}. +file \sysctlrelfile{kernel}{msgmax}, +\sysctlrelfile{kernel}{msgmnb} e +\sysctlrelfile{kernel}{msgmni} di \file{/proc/sys/kernel/}. \begin{figure}[!htb] \centering \includegraphics[width=13cm]{img/mqstruct} @@ -1303,7 +1303,7 @@ eseguire; i valori possibili sono: riceveranno un errore di \errcode{EIDRM}, e tutti processi in attesa su funzioni di lettura o di scrittura sulla coda saranno svegliati ricevendo il medesimo errore. Questo comando può essere eseguito solo da un processo - con user-ID effettivo corrispondente al creatore o al proprietario della + con \acr{uid} effettivo corrispondente al creatore o al proprietario della coda, o all'amministratore. \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 @@ -1686,7 +1686,7 @@ 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 \index{inode} inode di un filesystem, +dedicata ad una coda di messaggi che gli \itindex{inode} 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. @@ -1888,7 +1888,7 @@ Come per le code di messaggi anche per gli insiemi di semafori esistono una serie di limiti, i cui valori sono associati ad altrettante costanti, che si sono riportate in tab.~\ref{tab:ipc_sem_limits}. Alcuni di questi limiti sono al solito accessibili e modificabili attraverso \func{sysctl} o scrivendo -direttamente nel file \procfile{/proc/sys/kernel/sem}. +direttamente nel file \sysctlfile{kernel/sem}. La funzione che permette di effettuare le varie operazioni di controllo sui semafori (fra le quali, come accennato, è impropriamente compresa anche la @@ -1957,14 +1957,14 @@ seguenti: \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 - \errcode{EIDRM}. L'user-ID effettivo del processo deve corrispondere o al + \errcode{EIDRM}. L'\acr{uid} 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 \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'user-ID effettivo del processo deve + significativi di \var{sem\_perm.mode}. L'\acr{uid} effettivo del processo deve corrispondere o al creatore o al proprietario dell'insieme, o all'amministratore. L'argomento \param{semnum} viene ignorato. \item[\const{GETALL}] Restituisce il valore corrente di ciascun semaforo @@ -2319,7 +2319,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 -problemi, usando il \index{file!locking} \textit{file locking}. +problemi, usando il \itindex{file~locking} \textit{file locking}. \subsection{Memoria condivisa} @@ -2434,14 +2434,14 @@ che permettono di cambiarne il valore. & \textbf{Significato} \\ \hline \hline - \const{SHMALL}& 0x200000&\procrelfile{/proc/sys/kernel}{shmall} + \const{SHMALL}& 0x200000&\sysctlrelfile{kernel}{shmall} & Numero massimo di pagine che possono essere usate per i segmenti di memoria condivisa.\\ - \const{SHMMAX}&0x2000000&\procrelfile{/proc/sys/kernel}{shmmax} + \const{SHMMAX}&0x2000000&\sysctlrelfile{kernel}{shmmax} & Dimensione massima di un segmento di memoria condivisa.\\ - \const{SHMMNI}& 4096&\procrelfile{/proc/sys/kernel}{msgmni} + \const{SHMMNI}& 4096&\sysctlrelfile{kernel}{msgmni} & Numero massimo di segmenti di memoria condivisa presenti nel kernel.\\ \const{SHMMIN}& 1& --- & Dimensione minima di un segmento di @@ -2485,7 +2485,7 @@ un segmento di memoria condivisa è \funcd{shmctl}; il suo prototipo è: \item[\errcode{EPERM}] si è specificato un comando con \const{IPC\_SET} o \const{IPC\_RMID} senza i permessi necessari. \item[\errcode{EOVERFLOW}] si è tentato il comando \const{IPC\_STAT} ma il - valore del group-ID o dell'user-ID è troppo grande per essere + valore del \acr{gid} o dell'\acr{uid} è troppo grande per essere memorizzato nella struttura puntata da \param{buf}. \item[\errcode{EFAULT}] l'indirizzo specificato con \param{buf} non è valido. @@ -2504,7 +2504,7 @@ corrispondente comportamento della funzione, sono i seguenti: \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 user-ID effettivo corrispondente o al + eseguito solo da un processo con \acr{uid} effettivo corrispondente o al creatore del segmento, o al proprietario del segmento, 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}, @@ -3117,9 +3117,9 @@ accedere alla seriale si limita a segnalare che la risorsa non è disponibile. Dato che i \index{file!di lock} file di lock presentano gli inconvenienti illustrati in precedenza, la tecnica alternativa di sincronizzazione più -comune è quella di fare ricorso al \index{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 +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 @@ -3141,12 +3141,12 @@ leggermente più lento. \end{minipage} \normalsize \caption{Il codice delle funzioni che permettono per la gestione dei - \textit{mutex} con il \index{file!locking} \textit{file locking}.} + \textit{mutex} con il \itindex{file~locking} \textit{file locking}.} \label{fig:ipc_flock_mutex} \end{figure} Il codice delle varie funzioni usate per implementare un mutex utilizzando il -\textit{file locking} \index{file!locking} è riportato in +\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 @@ -3163,7 +3163,7 @@ 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 -aprire il file da usare per il \index{file!locking} \textit{file locking}, +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à. @@ -3180,7 +3180,7 @@ 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 -chiamata a \func{fcntl}. Avendo usato il \index{file!locking} \textit{file +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. @@ -3324,7 +3324,7 @@ quella particolare (si ricordi quanto visto in sez.~\ref{sec:ipc_sysv_access_control}) che viene usata per gli oggetti del SysV IPC. Per quanto riguarda l'attribuzione dell'utente e del gruppo proprietari dell'oggetto alla creazione di quest'ultimo essa viene effettuata -secondo la semantica SysV: corrispondono cioè a user-ID e group-ID effettivi +secondo la semantica SysV: corrispondono cioè a \acr{uid} e \acr{gid} effettivi del processo che esegue la creazione. @@ -3868,7 +3868,7 @@ segmento di memoria condiviso con le stesse modalità di il flag \const{FD\_CLOEXEC}. Chiamate effettuate da diversi processi usando lo stesso nome, restituiranno file descriptor associati allo stesso segmento (così come, nel caso di file di dati, essi sono associati allo stesso -\index{inode} inode). In questo modo è possibile effettuare una chiamata ad +\itindex{inode} inode). In questo modo è possibile effettuare una chiamata ad \func{mmap} sul file descriptor restituito da \func{shm\_open} ed i processi vedranno lo stesso segmento di memoria condivisa. @@ -4055,8 +4055,8 @@ 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'user-ID ed il -group-ID effettivo del processo chiamante, e che i permessi indicati con +Questo significa che un nuovo semaforo viene sempre creato con l'\acr{uid} ed il +\acr{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.