X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=ce4842e602ec37500c52304567dc7bc919a4b483;hp=9dec79a907d64106343fb941ceac99990aed297b;hb=4263734ffe237b1a7249c1f8121bb7ebe8b60a50;hpb=3498a6fc0fd13e07cacdea210cb99126d5052fbc diff --git a/ipc.tex b/ipc.tex index 9dec79a..ce4842e 100644 --- a/ipc.tex +++ b/ipc.tex @@ -2925,13 +2925,14 @@ 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 +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. + \subsection{La sincronizzazione con il \textit{file locking}} \label{sec:ipc_file_lock} @@ -2939,14 +2940,14 @@ 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 per la quale basterebbe un semaforo binario (quello che abbiamo definito come -\textit{mutex}, che indica la disponibilità o meno di una risorsa, e non ha -associato un contatore come i semafori) si possono utilizzare metodi +\textit{mutex}), per indicare la disponibilità o meno di una risorsa, senza la +necessità di un contatore come i semafori, si possono utilizzare metodi alternativi. La prima possibilità, utilizzata fin dalle origini di Unix, è quella di usare -dei \textsl{file di lock} (per i quali esiste anche una opportuna directory, -\file{/var/lock}, nel filesystem standard). Per questo si usa la -caratteristica della funzione \func{open} (illustrata in +dei \textsl{file di lock}\index{file di lock} (per i quali esiste anche una +opportuna directory, \file{/var/lock}, nel filesystem standard). Per questo si +usa la 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 @@ -2960,29 +2961,28 @@ il rilascio si pu 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.} + 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; 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 trovi un file di lock il + 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 -polling\index{polling}, che è molto inefficiente. +\textit{polling}\index{polling}, che è molto inefficiente. Per questo motivo la tecnica alternativa più pulita è quella di fare ricorso -al \textit{file locking} visto in \secref{sec:file_locking} ed utilizzare -\func{fcntl} su un file creato per l'occasione per ottenere un write lock; in +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 @@ -2998,12 +2998,21 @@ consuma risorse permanentemente allocate nel sistema, lo svantaggio 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 + + + \subsection{Il \textit{memory mapping} anonimo} \label{sec:ipc_mmap_anonymous} -Abbiamo visto in \secref{sec:file_memory_map} come sia possibile +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 \section{La comunicazione fra processi di POSIX}