X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=8fb7ab8efcde16b4f455cd4bc08cea28840772cd;hp=105c757073319cc936011e100b84d8b2949c498c;hb=b2fde72b2f308cb35873f1fd050501af6a742bc0;hpb=6ca77550fb420b3948b95a60ff79f7e282c12d34 diff --git a/ipc.tex b/ipc.tex index 105c757..8fb7ab8 100644 --- a/ipc.tex +++ b/ipc.tex @@ -175,10 +175,10 @@ evidente \itindex{race~condition} \textit{race condition} in caso di accesso simultaneo a detto file.\footnote{il problema potrebbe essere superato determinando in anticipo un nome appropriato per il file temporaneo, che verrebbe utilizzato dai vari sotto-processi, e cancellato alla fine della - loro esecuzione; ma a questo le cose non sarebbero più tanto semplici.} -L'uso di una pipe invece permette di risolvere il problema in maniera semplice -ed elegante, oltre ad essere molto più efficiente, dato che non si deve -scrivere su disco. + loro esecuzione; ma a questo punto le cose non sarebbero più tanto + semplici.} L'uso di una pipe invece permette di risolvere il problema in +maniera semplice ed elegante, oltre ad essere molto più efficiente, dato che +non si deve scrivere su disco. Il programma ci servirà anche come esempio dell'uso delle funzioni di duplicazione dei file descriptor che abbiamo trattato in @@ -2605,12 +2605,12 @@ indirizzo come arrotondamento, in Linux L'uso di \const{SHM\_RDONLY} permette di agganciare il segmento in sola lettura (si ricordi che anche le pagine di memoria hanno dei permessi), in tal -caso un tentativo di scrivere sul segmento comporterà una violazione di -accesso con l'emissione di un segnale di \const{SIGSEGV}. Il comportamento -usuale di \func{shmat} è quello di agganciare il segmento con l'accesso in -lettura e scrittura (ed il processo deve aver questi permessi in -\var{shm\_perm}), non è prevista la possibilità di agganciare un segmento in -sola scrittura. +caso un tentativo di scrivere sul segmento comporterà una +\itindex{segment~violation} violazione di accesso con l'emissione di un +segnale di \const{SIGSEGV}. Il comportamento usuale di \func{shmat} è quello +di agganciare il segmento con l'accesso in lettura e scrittura (ed il processo +deve aver questi permessi in \var{shm\_perm}), non è prevista la possibilità +di agganciare un segmento in sola scrittura. In caso di successo la funzione aggiorna anche i seguenti campi di \struct{shmid\_ds}: @@ -3258,8 +3258,9 @@ 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 dalle \acr{glibc} nella sezione che -implementa i 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 \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. La caratteristica fondamentale dell'interfaccia POSIX è l'abbandono dell'uso degli identificatori e delle chiavi visti nel SysV IPC, per passare ai @@ -3710,15 +3711,15 @@ della stessa struttura per l'invio dei segnali usati per l'I/O asincrono. Attraverso questa struttura si possono impostare le modalità con cui viene effettuata la notifica; in particolare il campo \var{sigev\_notify} deve essere posto a \const{SIGEV\_SIGNAL}\footnote{il meccanismo di notifica basato - sui thread, specificato tramite il valore \const{SIGEV\_THREAD}, non è - implementato.} ed il campo \var{sigev\_signo} deve indicare il valore del -segnale che sarà inviato al processo. Inoltre il campo \var{sigev\_value} è il -puntatore ad una struttura \struct{sigval\_t} (definita in -fig.~\ref{fig:sig_sigval}) che permette di restituire al gestore del segnale un -valore numerico o un indirizzo,\footnote{per il suo uso si riveda la - trattazione fatta in sez.~\ref{sec:sig_real_time} a proposito dei segnali - real-time.} posto che questo sia installato nella forma estesa vista in -sez.~\ref{sec:sig_sigaction}. + sui \itindex{thread} \textit{thread}, specificato tramite il valore + \const{SIGEV\_THREAD}, non è implementato.} ed il campo \var{sigev\_signo} +deve indicare il valore del segnale che sarà inviato al processo. Inoltre il +campo \var{sigev\_value} è il puntatore ad una struttura \struct{sigval\_t} +(definita in fig.~\ref{fig:sig_sigval}) che permette di restituire al gestore +del segnale un valore numerico o un indirizzo,\footnote{per il suo uso si + riveda la trattazione fatta in sez.~\ref{sec:sig_real_time} a proposito dei + segnali real-time.} posto che questo sia installato nella forma estesa vista +in sez.~\ref{sec:sig_sigaction}. La funzione registra il processo chiamante per la notifica se \param{notification} punta ad una struttura \struct{sigevent} opportunamente @@ -3946,15 +3947,16 @@ 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 -dei semafori POSIX che li realizzava solo a livello di thread e non di -processi,\footnote{questo significava che i semafori erano visibili solo - all'interno dei 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} delle -\acr{glibc}.\footnote{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 SysV IPC (mantenendo -così tutti i problemi sottolineati in sez.~\ref{sec:ipc_sysv_sem}). +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} delle \acr{glibc}.\footnote{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 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 sincronizzazione completamente nuovo, basato sui cosiddetti @@ -4162,11 +4164,11 @@ fosse occupato;\footnote{si ricordi che in generale un semaforo viene usato 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 thread) eventualmente bloccato in una -\func{sem\_wait} sul semaforo potrà essere svegliato e rimesso in esecuzione. -Si tenga presente che la funzione è sicura \index{funzioni~sicure} per l'uso -all'interno di un gestore di segnali (si ricordi quanto detto in -sez.~\ref{sec:sig_signal_handler}). +sbloccata, cosicché un altro processo (o \itindex{thread} \textit{thread}) +eventualmente bloccato in una \func{sem\_wait} sul semaforo potrà essere +svegliato e rimesso in esecuzione. Si tenga presente che la funzione è sicura +\index{funzioni!sicure} 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 vuole solamente leggere il valore, si può usare la funzione \funcd{sem\_getvalue}, il cui prototipo è: @@ -4290,15 +4292,16 @@ 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 -il semaforo deve essere utilizzato dai \itindex{thread} 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 \itindex{thread} \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 \itindex{thread} thread di uno -stesso processo (nel qual caso si parla di \textit{thread-shared semaphore}), -occorrerà che \param{sem} sia l'indirizzo di una variabile visibile da tutti i -\itindex{thread} thread, si dovrà usare cioè una variabile globale o una -variabile allocata dinamicamente nello \itindex{heap} heap. +Qualora il semaforo debba essere condiviso dai \itindex{thread} +\textit{thread} di uno stesso processo (nel qual caso si parla di +\textit{thread-shared semaphore}), occorrerà che \param{sem} sia l'indirizzo +di una variabile visibile da tutti i \itindex{thread} \textit{thread}, si +dovrà usare cioè una variabile globale o una variabile allocata dinamicamente +nello \itindex{heap} heap. Qualora il semaforo debba essere condiviso fra più processi (nel qual caso si parla di \textit{process-shared semaphore}) la sola scelta possibile per @@ -4340,8 +4343,9 @@ 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 -semaforo su cui sono presenti processi (o thread) in attesa (cioè bloccati in -una \func{sem\_wait}) provoca un comportamento indefinito. +semaforo su cui sono presenti processi (o \itindex{thread} \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