X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=783bfee98646f71c1683a4f133c0768828d19dd9;hp=ce4842e602ec37500c52304567dc7bc919a4b483;hb=9c3be0a6a901fad667ba1abcd8b46c712020cf26;hpb=4263734ffe237b1a7249c1f8121bb7ebe8b60a50 diff --git a/ipc.tex b/ipc.tex index ce4842e..783bfee 100644 --- 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} @@ -2441,7 +2451,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 @@ -2887,18 +2897,18 @@ 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}. +%% 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} +%% \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} @@ -2968,38 +2978,56 @@ il rilascio si pu 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. +una alternativa praticabile per la sincronizzazione: 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. + +La tecnica può comunque 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; in \file{LockFile.c} (un'altro dei +sorgenti allegati alla guida) si sono predisposte due funzioni, +\func{LockFile} e \func{UnlockFile}, da utilizzare allo scopo. + +Dato che i file di lock presentano gli inconvenienti illustrati in precedenza, +la tecnica alternativa più comune è quella di fare ricorso al \textit{file + locking} (trattato in \secref{sec:file_locking}) usando \func{fcntl} su un +file creato per l'occasione per ottenere un write lock. In questo modo potremo +usare il lock come un \textit{mutex}: per bloccare la risorsa basterà +acquisire il lock, per sbloccarla basterà rilasciare il lock; una richiesta +fatta con un write lock metterà automaticamente il processo in stato di +attesa, senza necessità di ricorrere al \textit{polling}\index{polling} per +determinare la disponibilità della risorsa, e al rilascio della stessa da +parte del processo che la occupava si otterrà il nuovo lock atomicamente. 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}[!bht] + \footnotesize \centering + \begin{minipage}[c]{15cm} + \begin{lstlisting}{} + + \end{lstlisting} + \end{minipage} + \normalsize + \caption{Il codice delle funzioni che permettono di creare un + \textit{mutex} utilizzando il file locking.} + \label{fig:ipc_flock_mutex} +\end{figure} +Il codice per implementare un mutex utilizzando il file locking è riportato in +\figref{fig:ipc_flock_mutex}; come nel precedente caso dei mutex implementato +con i semafori le funzioni sono tre @@ -3012,7 +3040,7 @@ 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 +infatti \section{La comunicazione fra processi di POSIX}