3 %% Copyright (C) 2000-2007 Simone Piccardi. Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
12 \chapter{La comunicazione fra processi}
16 Uno degli aspetti fondamentali della programmazione in un sistema unix-like è
17 la comunicazione fra processi. In questo capitolo affronteremo solo i
18 meccanismi più elementari che permettono di mettere in comunicazione processi
19 diversi, come quelli tradizionali che coinvolgono \textit{pipe} e
20 \textit{fifo} e i meccanismi di intercomunicazione di System V e quelli POSIX.
22 Tralasceremo invece tutte le problematiche relative alla comunicazione
23 attraverso la rete (e le relative interfacce) che saranno affrontate in
24 dettaglio in un secondo tempo. Non affronteremo neanche meccanismi più
25 complessi ed evoluti come le RPC (\textit{Remote Procedure Calls}) e CORBA
26 (\textit{Common Object Request Brocker Architecture}) che in genere sono
27 implementati con un ulteriore livello sopra i meccanismi elementari.
30 \section{La comunicazione fra processi tradizionale}
33 Il primo meccanismo di comunicazione fra processi introdotto nei sistemi Unix,
34 è quello delle cosiddette \textit{pipe}; esse costituiscono una delle
35 caratteristiche peculiari del sistema, in particolar modo dell'interfaccia a
36 linea di comando. In questa sezione descriveremo le sue basi, le funzioni che
37 ne gestiscono l'uso e le varie forme in cui si è evoluto.
40 \subsection{Le \textit{pipe} standard}
43 Le \textit{pipe} nascono sostanzialmente con Unix, e sono il primo, e tuttora
44 uno dei più usati, meccanismi di comunicazione fra processi. Si tratta in
45 sostanza di una coppia di file descriptor\footnote{si tenga presente che
46 le pipe sono oggetti creati dal kernel e non risiedono su disco.} connessi
47 fra di loro in modo che se quanto scrive su di uno si può rileggere
48 dall'altro. Si viene così a costituire un canale di comunicazione tramite i
49 due file descriptor, nella forma di un \textsl{tubo} (da cui il nome)
50 attraverso cui fluiscono i dati.
52 La funzione che permette di creare questa speciale coppia di file descriptor
53 associati ad una \textit{pipe} è appunto \funcd{pipe}, ed il suo prototipo è:
54 \begin{prototype}{unistd.h}
55 {int pipe(int filedes[2])}
57 Crea una coppia di file descriptor associati ad una \textit{pipe}.
59 \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
60 errore, nel qual caso \var{errno} potrà assumere i valori \errval{EMFILE},
61 \errval{ENFILE} e \errval{EFAULT}.}
64 La funzione restituisce la coppia di file descriptor nel vettore
65 \param{filedes}; il primo è aperto in lettura ed il secondo in scrittura. Come
66 accennato concetto di funzionamento di una pipe è semplice: quello che si
67 scrive nel file descriptor aperto in scrittura viene ripresentato tale e quale
68 nel file descriptor aperto in lettura. I file descriptor infatti non sono
69 connessi a nessun file reale, ma ad un buffer nel kernel, la cui dimensione è
70 specificata dal parametro di sistema \const{PIPE\_BUF}, (vedi
71 sez.~\ref{sec:sys_file_limits}). Lo schema di funzionamento di una pipe è
72 illustrato in fig.~\ref{fig:ipc_pipe_singular}, in cui sono illustrati i due
73 capi della pipe, associati a ciascun file descriptor, con le frecce che
74 indicano la direzione del flusso dei dati.
78 \includegraphics[height=5cm]{img/pipe}
79 \caption{Schema della struttura di una pipe.}
80 \label{fig:ipc_pipe_singular}
83 Chiaramente creare una pipe all'interno di un singolo processo non serve a
84 niente; se però ricordiamo quanto esposto in sez.~\ref{sec:file_sharing}
85 riguardo al comportamento dei file descriptor nei processi figli, è immediato
86 capire come una pipe possa diventare un meccanismo di intercomunicazione. Un
87 processo figlio infatti condivide gli stessi file descriptor del padre,
88 compresi quelli associati ad una pipe (secondo la situazione illustrata in
89 fig.~\ref{fig:ipc_pipe_fork}). In questo modo se uno dei processi scrive su un
90 capo della pipe, l'altro può leggere.
94 \includegraphics[height=5cm]{img/pipefork}
95 \caption{Schema dei collegamenti ad una pipe, condivisi fra processo padre e
96 figlio dopo l'esecuzione \func{fork}.}
97 \label{fig:ipc_pipe_fork}
100 Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
101 comunicazione fra processi attraverso una pipe, utilizzando le proprietà
102 ordinarie dei file, ma ci mostra anche qual è il principale\footnote{Stevens
103 in \cite{APUE} riporta come limite anche il fatto che la comunicazione è
104 unidirezionale, ma in realtà questo è un limite facilmente superabile usando
105 una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i
106 processi possano condividere i file descriptor della pipe, e per questo essi
107 devono comunque essere \textsl{parenti} (dall'inglese \textit{siblings}), cioè
108 o derivare da uno stesso processo padre in cui è avvenuta la creazione della
109 pipe, o, più comunemente, essere nella relazione padre/figlio.
111 A differenza di quanto avviene con i file normali, la lettura da una pipe può
112 essere bloccante (qualora non siano presenti dati), inoltre se si legge da una
113 pipe il cui capo in scrittura è stato chiuso, si avrà la ricezione di un EOF
114 (vale a dire che la funzione \func{read} ritornerà restituendo 0). Se invece
115 si esegue una scrittura su una pipe il cui capo in lettura non è aperto il
116 processo riceverà il segnale \const{SIGPIPE}, e la funzione di scrittura
117 restituirà un errore di \errcode{EPIPE} (al ritorno del gestore, o qualora il
118 segnale sia ignorato o bloccato).
120 La dimensione del buffer della pipe (\const{PIPE\_BUF}) ci dà inoltre un'altra
121 importante informazione riguardo il comportamento delle operazioni di lettura
122 e scrittura su di una pipe; esse infatti sono atomiche fintanto che la
123 quantità di dati da scrivere non supera questa dimensione. Qualora ad esempio
124 si effettui una scrittura di una quantità di dati superiore l'operazione verrà
125 effettuata in più riprese, consentendo l'intromissione di scritture effettuate
129 \subsection{Un esempio dell'uso delle pipe}
130 \label{sec:ipc_pipe_use}
132 Per capire meglio il funzionamento delle pipe faremo un esempio di quello che
133 è il loro uso più comune, analogo a quello effettuato della shell, e che
134 consiste nell'inviare l'output di un processo (lo standard output) sull'input
135 di un altro. Realizzeremo il programma di esempio nella forma di un
136 \textit{CGI}\footnote{Un CGI (\textit{Common Gateway Interface}) è un
137 programma che permette la creazione dinamica di un oggetto da inserire
138 all'interno di una pagina HTML.} per Apache, che genera una immagine JPEG
139 di un codice a barre, specificato come argomento in ingresso.
141 Un programma che deve essere eseguito come \textit{CGI} deve rispondere a
142 delle caratteristiche specifiche, esso infatti non viene lanciato da una
143 shell, ma dallo stesso web server, alla richiesta di una specifica URL, che di
146 http://www.sito.it/cgi-bin/programma?argomento
148 ed il risultato dell'elaborazione deve essere presentato (con una intestazione
149 che ne descrive il mime-type) sullo standard output, in modo che il web-server
150 possa reinviarlo al browser che ha effettuato la richiesta, che in questo modo
151 è in grado di visualizzarlo opportunamente.
153 Per realizzare quanto voluto useremo in sequenza i programmi \cmd{barcode} e
154 \cmd{gs}, il primo infatti è in grado di generare immagini PostScript di
155 codici a barre corrispondenti ad una qualunque stringa, mentre il secondo
156 serve per poter effettuare la conversione della stessa immagine in formato
157 JPEG. Usando una pipe potremo inviare l'output del primo sull'input del
158 secondo, secondo lo schema mostrato in fig.~\ref{fig:ipc_pipe_use}, in cui la
159 direzione del flusso dei dati è data dalle frecce continue.
163 \includegraphics[height=5cm]{img/pipeuse}
164 \caption{Schema dell'uso di una pipe come mezzo di comunicazione fra
165 due processi attraverso l'esecuzione una \func{fork} e la chiusura dei
166 capi non utilizzati.}
167 \label{fig:ipc_pipe_use}
170 Si potrebbe obiettare che sarebbe molto più semplice salvare il risultato
171 intermedio su un file temporaneo. Questo però non tiene conto del fatto che un
172 \textit{CGI} deve poter gestire più richieste in concorrenza, e si avrebbe una
173 evidente \itindex{race~condition} \textit{race condition} in caso di accesso
174 simultaneo a detto file.\footnote{il problema potrebbe essere superato
175 determinando in anticipo un nome appropriato per il file temporaneo, che
176 verrebbe utilizzato dai vari sotto-processi, e cancellato alla fine della
177 loro esecuzione; ma a questo le cose non sarebbero più tanto semplici.}
178 L'uso di una pipe invece permette di risolvere il problema in maniera semplice
179 ed elegante, oltre ad essere molto più efficiente, dato che non si deve
182 Il programma ci servirà anche come esempio dell'uso delle funzioni di
183 duplicazione dei file descriptor che abbiamo trattato in
184 sez.~\ref{sec:file_dup}, in particolare di \func{dup2}. È attraverso queste
185 funzioni infatti che è possibile dirottare gli stream standard dei processi
186 (che abbiamo visto in sez.~\ref{sec:file_std_descr} e
187 sez.~\ref{sec:file_std_stream}) sulla pipe. In
188 fig.~\ref{fig:ipc_barcodepage_code} abbiamo riportato il corpo del programma,
189 il cui codice completo è disponibile nel file \file{BarCodePage.c} che si
190 trova nella directory dei sorgenti.
194 \footnotesize \centering
195 \begin{minipage}[c]{15cm}
196 \includecodesample{listati/BarCodePage.c}
199 \caption{Sezione principale del codice del \textit{CGI}
200 \file{BarCodePage.c}.}
201 \label{fig:ipc_barcodepage_code}
204 La prima operazione del programma (\texttt{\small 4--12}) è quella di creare
205 le due pipe che serviranno per la comunicazione fra i due comandi utilizzati
206 per produrre il codice a barre; si ha cura di controllare la riuscita della
207 chiamata, inviando in caso di errore un messaggio invece dell'immagine
208 richiesta.\footnote{la funzione \func{WriteMess} non è riportata in
209 fig.~\ref{fig:ipc_barcodepage_code}; essa si incarica semplicemente di
210 formattare l'uscita alla maniera dei CGI, aggiungendo l'opportuno
211 \textit{mime type}, e formattando il messaggio in HTML, in modo che
212 quest'ultimo possa essere visualizzato correttamente da un browser.}
214 Una volta create le pipe, il programma può creare (\texttt{\small 13-17}) il
215 primo processo figlio, che si incaricherà (\texttt{\small 19--25}) di eseguire
216 \cmd{barcode}. Quest'ultimo legge dallo standard input una stringa di
217 caratteri, la converte nell'immagine PostScript del codice a barre ad essa
218 corrispondente, e poi scrive il risultato direttamente sullo standard output.
220 Per poter utilizzare queste caratteristiche prima di eseguire \cmd{barcode} si
221 chiude (\texttt{\small 20}) il capo aperto in scrittura della prima pipe, e se
222 ne collega (\texttt{\small 21}) il capo in lettura allo standard input, usando
223 \func{dup2}. Si ricordi che invocando \func{dup2} il secondo file, qualora
224 risulti aperto, viene, come nel caso corrente, chiuso prima di effettuare la
225 duplicazione. Allo stesso modo, dato che \cmd{barcode} scrive l'immagine
226 PostScript del codice a barre sullo standard output, per poter effettuare una
227 ulteriore redirezione il capo in lettura della seconda pipe viene chiuso
228 (\texttt{\small 22}) mentre il capo in scrittura viene collegato allo standard
229 output (\texttt{\small 23}).
231 In questo modo all'esecuzione (\texttt{\small 25}) di \cmd{barcode} (cui si
232 passa in \var{size} la dimensione della pagina per l'immagine) quest'ultimo
233 leggerà dalla prima pipe la stringa da codificare che gli sarà inviata dal
234 padre, e scriverà l'immagine PostScript del codice a barre sulla seconda.
236 Al contempo una volta lanciato il primo figlio, il processo padre prima chiude
237 (\texttt{\small 26}) il capo inutilizzato della prima pipe (quello in input) e
238 poi scrive (\texttt{\small 27}) la stringa da convertire sul capo in output,
239 così che \cmd{barcode} possa riceverla dallo standard input. A questo punto
240 l'uso della prima pipe da parte del padre è finito ed essa può essere
241 definitivamente chiusa (\texttt{\small 28}), si attende poi (\texttt{\small
242 29}) che l'esecuzione di \cmd{barcode} sia completata.
244 Alla conclusione della sua esecuzione \cmd{barcode} avrà inviato l'immagine
245 PostScript del codice a barre sul capo in scrittura della seconda pipe; a
246 questo punto si può eseguire la seconda conversione, da PS a JPEG, usando il
247 programma \cmd{gs}. Per questo si crea (\texttt{\small 30--34}) un secondo
248 processo figlio, che poi (\texttt{\small 35--42}) eseguirà questo programma
249 leggendo l'immagine PostScript creata da \cmd{barcode} dallo standard input,
250 per convertirla in JPEG.
252 Per fare tutto ciò anzitutto si chiude (\texttt{\small 37}) il capo in
253 scrittura della seconda pipe, e se ne collega (\texttt{\small 38}) il capo in
254 lettura allo standard input. Per poter formattare l'output del programma in
255 maniera utilizzabile da un browser, si provvede anche \texttt{\small 40}) alla
256 scrittura dell'apposita stringa di identificazione del mime-type in testa allo
257 standard output. A questo punto si può invocare \texttt{\small 41}) \cmd{gs},
258 provvedendo gli appositi switch che consentono di leggere il file da
259 convertire dallo standard input e di inviare la conversione sullo standard
262 Per completare le operazioni il processo padre chiude (\texttt{\small 44}) il
263 capo in scrittura della seconda pipe, e attende la conclusione del figlio
264 (\texttt{\small 45}); a questo punto può (\texttt{\small 46}) uscire. Si tenga
265 conto che l'operazione di chiudere il capo in scrittura della seconda pipe è
266 necessaria, infatti, se non venisse chiusa, \cmd{gs}, che legge il suo
267 standard input da detta pipe, resterebbe bloccato in attesa di ulteriori dati
268 in ingresso (l'unico modo che un programma ha per sapere che l'input è
269 terminato è rilevare che lo standard input è stato chiuso), e la \func{wait}
273 \subsection{Le funzioni \func{popen} e \func{pclose}}
274 \label{sec:ipc_popen}
276 Come si è visto la modalità più comune di utilizzo di una pipe è quella di
277 utilizzarla per fare da tramite fra output ed input di due programmi invocati
278 in sequenza; per questo motivo lo standard POSIX.2 ha introdotto due funzioni
279 che permettono di sintetizzare queste operazioni. La prima di esse si chiama
280 \funcd{popen} ed il suo prototipo è:
281 \begin{prototype}{stdio.h}
282 {FILE *popen(const char *command, const char *type)}
284 Esegue il programma \param{command}, di cui, a seconda di \param{type},
285 restituisce, lo standard input o lo standard output nella pipe collegata allo
286 stream restituito come valore di ritorno.
288 \bodydesc{La funzione restituisce l'indirizzo dello stream associato alla pipe
289 in caso di successo e \val{NULL} per un errore, nel qual caso \var{errno}
290 potrà assumere i valori relativi alle sottostanti invocazioni di \func{pipe}
291 e \func{fork} o \errcode{EINVAL} se \param{type} non è valido.}
294 La funzione crea una pipe, esegue una \func{fork}, ed invoca il programma
295 \param{command} attraverso la shell (in sostanza esegue \file{/bin/sh} con il
296 flag \code{-c}); l'argomento \param{type} deve essere una delle due stringhe
297 \verb|"w"| o \verb|"r"|, per indicare se la pipe sarà collegata allo standard
298 input o allo standard output del comando invocato.
300 La funzione restituisce il puntatore allo stream associato alla pipe creata,
301 che sarà aperto in sola lettura (e quindi associato allo standard output del
302 programma indicato) in caso si sia indicato \code{"r"}, o in sola scrittura (e
303 quindi associato allo standard input) in caso di \code{"w"}.
305 Lo stream restituito da \func{popen} è identico a tutti gli effetti ai file
306 stream visti in cap.~\ref{cha:files_std_interface}, anche se è collegato ad
307 una pipe e non ad un file, e viene sempre aperto in modalità
308 \textit{fully-buffered} (vedi sez.~\ref{sec:file_buffering}); l'unica
309 differenza con gli usuali stream è che dovrà essere chiuso dalla seconda delle
310 due nuove funzioni, \funcd{pclose}, il cui prototipo è:
311 \begin{prototype}{stdio.h}
312 {int pclose(FILE *stream)}
314 Chiude il file \param{stream}, restituito da una precedente \func{popen}
315 attendendo la terminazione del processo ad essa associato.
317 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
318 errore; nel quel caso il valore di \var{errno} deriva dalle sottostanti
321 \noindent che oltre alla chiusura dello stream si incarica anche di attendere
322 (tramite \func{wait4}) la conclusione del processo creato dalla precedente
325 Per illustrare l'uso di queste due funzioni riprendiamo il problema
326 precedente: il programma mostrato in fig.~\ref{fig:ipc_barcodepage_code} per
327 quanto funzionante, è (volutamente) codificato in maniera piuttosto complessa,
328 inoltre nella pratica sconta un problema di \cmd{gs} che non è in
329 grado\footnote{nella versione GNU Ghostscript 6.53 (2002-02-13).} di
330 riconoscere correttamente l'Encapsulated PostScript, per cui deve essere usato
331 il PostScript e tutte le volte viene generata una pagina intera, invece che
332 una immagine delle dimensioni corrispondenti al codice a barre.
334 Se si vuole generare una immagine di dimensioni appropriate si deve usare un
335 approccio diverso. Una possibilità sarebbe quella di ricorrere ad ulteriore
336 programma, \cmd{epstopsf}, per convertire in PDF un file EPS (che può essere
337 generato da \cmd{barcode} utilizzando lo switch \cmd{-E}). Utilizzando un PDF
338 al posto di un EPS \cmd{gs} esegue la conversione rispettando le dimensioni
339 originarie del codice a barre e produce un JPEG di dimensioni corrette.
341 Questo approccio però non funziona, per via di una delle caratteristiche
342 principali delle pipe. Per poter effettuare la conversione di un PDF infatti è
343 necessario, per la struttura del formato, potersi spostare (con \func{lseek})
344 all'interno del file da convertire; se si esegue la conversione con \cmd{gs}
345 su un file regolare non ci sono problemi, una pipe però è rigidamente
346 sequenziale, e l'uso di \func{lseek} su di essa fallisce sempre con un errore
347 di \errcode{ESPIPE}, rendendo impossibile la conversione. Questo ci dice che
348 in generale la concatenazione di vari programmi funzionerà soltanto quando
349 tutti prevedono una lettura sequenziale del loro input.
351 Per questo motivo si è dovuto utilizzare un procedimento diverso, eseguendo
352 prima la conversione (sempre con \cmd{gs}) del PS in un altro formato
353 intermedio, il PPM,\footnote{il \textit{Portable PixMap file format} è un
354 formato usato spesso come formato intermedio per effettuare conversioni, è
355 infatti molto facile da manipolare, dato che usa caratteri ASCII per
356 memorizzare le immagini, anche se per questo è estremamente inefficiente.}
357 dal quale poi si può ottenere un'immagine di dimensioni corrette attraverso
358 vari programmi di manipolazione (\cmd{pnmcrop}, \cmd{pnmmargin}) che può
359 essere infine trasformata in PNG (con \cmd{pnm2png}).
361 In questo caso però occorre eseguire in sequenza ben quattro comandi diversi,
362 inviando l'output di ciascuno all'input del successivo, per poi ottenere il
363 risultato finale sullo standard output: un caso classico di utilizzazione
364 delle pipe, in cui l'uso di \func{popen} e \func{pclose} permette di
365 semplificare notevolmente la stesura del codice.
367 Nel nostro caso, dato che ciascun processo deve scrivere il suo output sullo
368 standard input del successivo, occorrerà usare \func{popen} aprendo la pipe in
369 scrittura. Il codice del nuovo programma è riportato in
370 fig.~\ref{fig:ipc_barcode_code}. Come si può notare l'ordine di invocazione
371 dei programmi è l'inverso di quello in cui ci si aspetta che vengano
372 effettivamente eseguiti. Questo non comporta nessun problema dato che la
373 lettura su una pipe è bloccante, per cui ciascun processo, per quanto lanciato
374 per primo, si bloccherà in attesa di ricevere sullo standard input il
375 risultato dell'elaborazione del precedente, benché quest'ultimo venga invocato
379 \footnotesize \centering
380 \begin{minipage}[c]{15cm}
381 \includecodesample{listati/BarCode.c}
384 \caption{Codice completo del \textit{CGI} \file{BarCode.c}.}
385 \label{fig:ipc_barcode_code}
388 Nel nostro caso il primo passo (\texttt{\small 14}) è scrivere il mime-type
389 sullo standard output; a questo punto il processo padre non necessita più di
390 eseguire ulteriori operazioni sullo standard output e può tranquillamente
391 provvedere alla redirezione.
393 Dato che i vari programmi devono essere lanciati in successione, si è
394 approntato un ciclo (\texttt{\small 15--19}) che esegue le operazioni in
395 sequenza: prima crea una pipe (\texttt{\small 17}) per la scrittura eseguendo
396 il programma con \func{popen}, in modo che essa sia collegata allo standard
397 input, e poi redirige (\texttt{\small 18}) lo standard output su detta pipe.
399 In questo modo il primo processo ad essere invocato (che è l'ultimo della
400 catena) scriverà ancora sullo standard output del processo padre, ma i
401 successivi, a causa di questa redirezione, scriveranno sulla pipe associata
402 allo standard input del processo invocato nel ciclo precedente.
404 Alla fine tutto quello che resta da fare è lanciare (\texttt{\small 21}) il
405 primo processo della catena, che nel caso è \cmd{barcode}, e scrivere
406 (\texttt{\small 23}) la stringa del codice a barre sulla pipe, che è collegata
407 al suo standard input, infine si può eseguire (\texttt{\small 24--27}) un
408 ciclo che chiuda, nell'ordine inverso rispetto a quello in cui le si sono
409 create, tutte le pipe create con \func{pclose}.
412 \subsection{Le \textit{pipe} con nome, o \textit{fifo}}
413 \label{sec:ipc_named_pipe}
415 Come accennato in sez.~\ref{sec:ipc_pipes} il problema delle \textit{pipe} è
416 che esse possono essere utilizzate solo da processi con un progenitore comune
417 o nella relazione padre/figlio; per superare questo problema lo standard
418 POSIX.1 ha definito dei nuovi oggetti, le \textit{fifo}, che hanno le stesse
419 caratteristiche delle pipe, ma che invece di essere strutture interne del
420 kernel, visibili solo attraverso un file descriptor, sono accessibili
421 attraverso un \index{inode} inode che risiede sul filesystem, così che i
422 processi le possono usare senza dovere per forza essere in una relazione di
425 Utilizzando una \textit{fifo} tutti i dati passeranno, come per le pipe,
426 attraverso un apposito buffer nel kernel, senza transitare dal filesystem;
427 \index{inode} l'inode allocato sul filesystem serve infatti solo a fornire un
428 punto di riferimento per i processi, che permetta loro di accedere alla stessa
429 fifo; il comportamento delle funzioni di lettura e scrittura è identico a
430 quello illustrato per le pipe in sez.~\ref{sec:ipc_pipes}.
432 Abbiamo già visto in sez.~\ref{sec:file_mknod} le funzioni \func{mknod} e
433 \func{mkfifo} che permettono di creare una fifo; per utilizzarne una un
434 processo non avrà che da aprire il relativo file speciale o in lettura o
435 scrittura; nel primo caso sarà collegato al capo di uscita della fifo, e dovrà
436 leggere, nel secondo al capo di ingresso, e dovrà scrivere.
438 Il kernel crea una singola pipe per ciascuna fifo che sia stata aperta, che può
439 essere acceduta contemporaneamente da più processi, sia in lettura che in
440 scrittura. Dato che per funzionare deve essere aperta in entrambe le
441 direzioni, per una fifo di norma la funzione \func{open} si blocca se viene
442 eseguita quando l'altro capo non è aperto.
444 Le fifo però possono essere anche aperte in modalità \textsl{non-bloccante},
445 nel qual caso l'apertura del capo in lettura avrà successo solo quando anche
446 l'altro capo è aperto, mentre l'apertura del capo in scrittura restituirà
447 l'errore di \errcode{ENXIO} fintanto che non verrà aperto il capo in lettura.
449 In Linux è possibile aprire le fifo anche in lettura/scrittura,\footnote{lo
450 standard POSIX lascia indefinito il comportamento in questo caso.}
451 operazione che avrà sempre successo immediato qualunque sia la modalità di
452 apertura (bloccante e non bloccante); questo può essere utilizzato per aprire
453 comunque una fifo in scrittura anche se non ci sono ancora processi il
454 lettura; è possibile anche usare la fifo all'interno di un solo processo, nel
455 qual caso però occorre stare molto attenti alla possibili situazioni di
456 stallo.\footnote{se si cerca di leggere da una fifo che non contiene dati si
457 avrà un \itindex{deadlock} deadlock immediato, dato che il processo si
458 blocca e non potrà quindi mai eseguire le funzioni di scrittura.}
460 Per la loro caratteristica di essere accessibili attraverso il filesystem, è
461 piuttosto frequente l'utilizzo di una fifo come canale di comunicazione nelle
462 situazioni un processo deve ricevere informazioni da altri. In questo caso è
463 fondamentale che le operazioni di scrittura siano atomiche; per questo si deve
464 sempre tenere presente che questo è vero soltanto fintanto che non si supera
465 il limite delle dimensioni di \const{PIPE\_BUF} (si ricordi quanto detto in
466 sez.~\ref{sec:ipc_pipes}).
468 A parte il caso precedente, che resta probabilmente il più comune, Stevens
469 riporta in \cite{APUE} altre due casistiche principali per l'uso delle fifo:
471 \item Da parte dei comandi di shell, per evitare la creazione di file
472 temporanei quando si devono inviare i dati di uscita di un processo
473 sull'input di parecchi altri (attraverso l'uso del comando \cmd{tee}).
475 \item Come canale di comunicazione fra client ed server (il modello
476 \textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}).
479 Nel primo caso quello che si fa è creare tante fifo, da usare come standard
480 input, quanti sono i processi a cui i vogliono inviare i dati, questi ultimi
481 saranno stati posti in esecuzione ridirigendo lo standard input dalle fifo, si
482 potrà poi eseguire il processo che fornisce l'output replicando quest'ultimo,
483 con il comando \cmd{tee}, sulle varie fifo.
485 Il secondo caso è relativamente semplice qualora si debba comunicare con un
486 processo alla volta (nel qual caso basta usare due fifo, una per leggere ed
487 una per scrivere), le cose diventano invece molto più complesse quando si
488 vuole effettuare una comunicazione fra il server ed un numero imprecisato di
489 client; se il primo infatti può ricevere le richieste attraverso una fifo
490 ``\textsl{nota}'', per le risposte non si può fare altrettanto, dato che, per
491 la struttura sequenziale delle fifo, i client dovrebbero sapere, prima di
492 leggerli, quando i dati inviati sono destinati a loro.
494 Per risolvere questo problema, si può usare un'architettura come quella
495 illustrata in fig.~\ref{fig:ipc_fifo_server_arch} in cui i client inviano le
496 richieste al server su una fifo nota mentre le risposte vengono reinviate dal
497 server a ciascuno di essi su una fifo temporanea creata per l'occasione.
501 \includegraphics[height=9cm]{img/fifoserver}
502 \caption{Schema dell'utilizzo delle fifo nella realizzazione di una
503 architettura di comunicazione client/server.}
504 \label{fig:ipc_fifo_server_arch}
507 Come esempio di uso questa architettura e dell'uso delle fifo, abbiamo scritto
508 un server di \textit{fortunes}, che restituisce, alle richieste di un client,
509 un detto a caso estratto da un insieme di frasi; sia il numero delle frasi
510 dell'insieme, che i file da cui esse vengono lette all'avvio, sono importabili
511 da riga di comando. Il corpo principale del server è riportato in
512 fig.~\ref{fig:ipc_fifo_server}, dove si è tralasciata la parte che tratta la
513 gestione delle opzioni a riga di comando, che effettua il settaggio delle
514 variabili \var{fortunefilename}, che indica il file da cui leggere le frasi,
515 ed \var{n}, che indica il numero di frasi tenute in memoria, ad un valore
516 diverso da quelli preimpostati. Il codice completo è nel file
517 \file{FortuneServer.c}.
520 \footnotesize \centering
521 \begin{minipage}[c]{15cm}
522 \includecodesample{listati/FortuneServer.c}
525 \caption{Sezione principale del codice del server di \textit{fortunes}
527 \label{fig:ipc_fifo_server}
530 Il server richiede (\texttt{\small 12}) che sia stata impostata una dimensione
531 dell'insieme delle frasi non nulla, dato che l'inizializzazione del vettore
532 \var{fortune} avviene solo quando questa dimensione viene specificata, la
533 presenza di un valore nullo provoca l'uscita dal programma attraverso la
534 funzione (non riportata) che ne stampa le modalità d'uso. Dopo di che
535 installa (\texttt{\small 13--15}) la funzione che gestisce i segnali di
536 interruzione (anche questa non è riportata in fig.~\ref{fig:ipc_fifo_server})
537 che si limita a rimuovere dal filesystem la fifo usata dal server per
540 Terminata l'inizializzazione (\texttt{\small 16}) si effettua la chiamata alla
541 funzione \code{FortuneParse} che legge dal file specificato in
542 \var{fortunefilename} le prime \var{n} frasi e le memorizza (allocando
543 dinamicamente la memoria necessaria) nel vettore di puntatori \var{fortune}.
544 Anche il codice della funzione non è riportato, in quanto non direttamente
545 attinente allo scopo dell'esempio.
547 Il passo successivo (\texttt{\small 17--22}) è quello di creare con
548 \func{mkfifo} la fifo nota sulla quale il server ascolterà le richieste,
549 qualora si riscontri un errore il server uscirà (escludendo ovviamente il caso
550 in cui la funzione \func{mkfifo} fallisce per la precedente esistenza della
553 Una volta che si è certi che la fifo di ascolto esiste la procedura di
554 inizializzazione è completata. A questo punto si può chiamare (\texttt{\small
555 23}) la funzione \func{daemon} per far proseguire l'esecuzione del programma
556 in background come demone. Si può quindi procedere (\texttt{\small 24--33})
557 alla apertura della fifo: si noti che questo viene fatto due volte, prima in
558 lettura e poi in scrittura, per evitare di dover gestire all'interno del ciclo
559 principale il caso in cui il server è in ascolto ma non ci sono client che
560 effettuano richieste. Si ricordi infatti che quando una fifo è aperta solo
561 dal capo in lettura, l'esecuzione di \func{read} ritorna con zero byte (si ha
562 cioè una condizione di end-of-file).
564 Nel nostro caso la prima apertura si bloccherà fintanto che un qualunque
565 client non apre a sua volta la fifo nota in scrittura per effettuare la sua
566 richiesta. Pertanto all'inizio non ci sono problemi, il client però, una volta
567 ricevuta la risposta, uscirà, chiudendo tutti i file aperti, compresa la fifo.
568 A questo punto il server resta (se non ci sono altri client che stanno
569 effettuando richieste) con la fifo chiusa sul lato in lettura, ed in questo
570 stato la funzione \func{read} non si bloccherà in attesa di input, ma
571 ritornerà in continuazione, restituendo un end-of-file.\footnote{Si è usata
572 questa tecnica per compatibilità, Linux infatti supporta l'apertura delle
573 fifo in lettura/scrittura, per cui si sarebbe potuto effettuare una singola
574 apertura con \const{O\_RDWR}, la doppia apertura comunque ha il vantaggio
575 che non si può scrivere per errore sul capo aperto in sola lettura.}
577 Per questo motivo, dopo aver eseguito l'apertura in lettura (\texttt{\small
578 24--28}),\footnote{di solito si effettua l'apertura del capo in lettura di
579 una fifo in modalità non bloccante, per evitare il rischio di uno stallo: se
580 infatti nessuno apre la fifo in scrittura il processo non ritornerà mai
581 dalla \func{open}. Nel nostro caso questo rischio non esiste, mentre è
582 necessario potersi bloccare in lettura in attesa di una richiesta.} si
583 esegue una seconda apertura in scrittura (\texttt{\small 29--32}), scartando
584 il relativo file descriptor, che non sarà mai usato, in questo modo però la
585 fifo resta comunque aperta anche in scrittura, cosicché le successive chiamate
586 a \func{read} possono bloccarsi.
588 A questo punto si può entrare nel ciclo principale del programma che fornisce
589 le risposte ai client (\texttt{\small 34--50}); questo viene eseguito
590 indefinitamente (l'uscita del server viene effettuata inviando un segnale, in
591 modo da passare attraverso la funzione di chiusura che cancella la fifo).
593 Il server è progettato per accettare come richieste dai client delle stringhe
594 che contengono il nome della fifo sulla quale deve essere inviata la risposta.
595 Per cui prima (\texttt{\small 35--39}) si esegue la lettura dalla stringa di
596 richiesta dalla fifo nota (che a questo punto si bloccherà tutte le volte che
597 non ci sono richieste). Dopo di che, una volta terminata la stringa
598 (\texttt{\small 40}) e selezionato (\texttt{\small 41}) un numero casuale per
599 ricavare la frase da inviare, si procederà (\texttt{\small 42--46})
600 all'apertura della fifo per la risposta, che poi \texttt{\small 47--48}) vi
601 sarà scritta. Infine (\texttt{\small 49}) si chiude la fifo di risposta che
604 Il codice del client è invece riportato in fig.~\ref{fig:ipc_fifo_client},
605 anche in questo caso si è omessa la gestione delle opzioni e la funzione che
606 stampa a video le informazioni di utilizzo ed esce, riportando solo la sezione
607 principale del programma e le definizioni delle variabili. Il codice completo
608 è nel file \file{FortuneClient.c} dei sorgenti allegati.
611 \footnotesize \centering
612 \begin{minipage}[c]{15cm}
613 \includecodesample{listati/FortuneClient.c}
616 \caption{Sezione principale del codice del client di \textit{fortunes}
618 \label{fig:ipc_fifo_client}
621 La prima istruzione (\texttt{\small 12}) compone il nome della fifo che dovrà
622 essere utilizzata per ricevere la risposta dal server. Si usa il \acr{pid}
623 del processo per essere sicuri di avere un nome univoco; dopo di che
624 (\texttt{\small 13-18}) si procede alla creazione del relativo file, uscendo
625 in caso di errore (a meno che il file non sia già presente sul filesystem).
627 A questo punto il client può effettuare l'interrogazione del server, per
628 questo prima si apre la fifo nota (\texttt{\small 19--23}), e poi ci si scrive
629 (\texttt{\small 24}) la stringa composta in precedenza, che contiene il nome
630 della fifo da utilizzare per la risposta. Infine si richiude la fifo del
631 server che a questo punto non serve più (\texttt{\small 25}).
633 Inoltrata la richiesta si può passare alla lettura della risposta; anzitutto
634 si apre (\texttt{\small 26--30}) la fifo appena creata, da cui si deve
635 riceverla, dopo di che si effettua una lettura (\texttt{\small 31})
636 nell'apposito buffer; si è supposto, come è ragionevole, che le frasi inviate
637 dal server siano sempre di dimensioni inferiori a \const{PIPE\_BUF},
638 tralasciamo la gestione del caso in cui questo non è vero. Infine si stampa
639 (\texttt{\small 32}) a video la risposta, si chiude (\texttt{\small 33}) la
640 fifo e si cancella (\texttt{\small 34}) il relativo file.
641 Si noti come la fifo per la risposta sia stata aperta solo dopo aver inviato
642 la richiesta, se non si fosse fatto così si avrebbe avuto uno stallo, in
643 quanto senza la richiesta, il server non avrebbe potuto aprirne il capo in
644 scrittura e l'apertura si sarebbe bloccata indefinitamente.
646 Verifichiamo allora il comportamento dei nostri programmi, in questo, come in
647 altri esempi precedenti, si fa uso delle varie funzioni di servizio, che sono
648 state raccolte nella libreria \file{libgapil.so}, per poter usare quest'ultima
649 occorrerà definire la speciale variabile di ambiente \code{LD\_LIBRARY\_PATH}
650 in modo che il linker dinamico possa accedervi.
652 In generale questa variabile indica il \itindex{pathname} \textit{pathname}
653 della directory contenente la libreria. Nell'ipotesi (che daremo sempre per
654 verificata) che si facciano le prove direttamente nella directory dei sorgenti
655 (dove di norma vengono creati sia i programmi che la libreria), il comando da
656 dare sarà \code{export LD\_LIBRARY\_PATH=./}; a questo punto potremo lanciare
657 il server, facendogli leggere una decina di frasi, con:
659 [piccardi@gont sources]$ ./fortuned -n10
662 Avendo usato \func{daemon} per eseguire il server in background il comando
663 ritornerà immediatamente, ma potremo verificare con \cmd{ps} che in effetti il
664 programma resta un esecuzione in background, e senza avere associato un
665 terminale di controllo (si ricordi quanto detto in sez.~\ref{sec:sess_daemon}):
667 [piccardi@gont sources]$ ps aux
669 piccardi 27489 0.0 0.0 1204 356 ? S 01:06 0:00 ./fortuned -n10
670 piccardi 27492 3.0 0.1 2492 764 pts/2 R 01:08 0:00 ps aux
672 e si potrà verificare anche che in \file{/tmp} è stata creata la fifo di
673 ascolto \file{fortune.fifo}. A questo punto potremo interrogare il server con
674 il programma client; otterremo così:
676 [piccardi@gont sources]$ ./fortune
677 Linux ext2fs has been stable for a long time, now it's time to break it
678 -- Linuxkongreß '95 in Berlin
679 [piccardi@gont sources]$ ./fortune
680 Let's call it an accidental feature.
682 [piccardi@gont sources]$ ./fortune
683 ......... Escape the 'Gates' of Hell
686 ::: .:: .:.::. .:: .:: `::. :'
687 ::: :: :: :: :: :: :::.
688 ::: .::. .:: ::. `::::. .:' ::.
689 ...:::.....................::' .::::..
690 -- William E. Roadcap
691 [piccardi@gont sources]$ ./fortune
692 Linux ext2fs has been stable for a long time, now it's time to break it
693 -- Linuxkongreß '95 in Berlin
695 e ripetendo varie volte il comando otterremo, in ordine casuale, le dieci
696 frasi tenute in memoria dal server.
698 Infine per chiudere il server basterà inviare un segnale di terminazione con
699 \code{killall fortuned} e potremo verificare che il gestore del segnale ha
700 anche correttamente cancellato la fifo di ascolto da \file{/tmp}.
702 Benché il nostro sistema client-server funzioni, la sua struttura è piuttosto
703 complessa e continua ad avere vari inconvenienti\footnote{lo stesso Stevens,
704 che esamina questa architettura in \cite{APUE}, nota come sia impossibile
705 per il server sapere se un client è andato in crash, con la possibilità di
706 far restare le fifo temporanee sul filesystem, di come sia necessario
707 intercettare \const{SIGPIPE} dato che un client può terminare dopo aver
708 fatto una richiesta, ma prima che la risposta sia inviata (cosa che nel
709 nostro esempio non è stata fatta).}; in generale infatti l'interfaccia delle
710 fifo non è adatta a risolvere questo tipo di problemi, che possono essere
711 affrontati in maniera più semplice ed efficace o usando i socket (che
712 tratteremo in dettaglio a partire da cap.~\ref{cha:socket_intro}) o ricorrendo
713 a meccanismi di comunicazione diversi, come quelli che esamineremo in seguito.
717 \subsection{La funzione \func{socketpair}}
718 \label{sec:ipc_socketpair}
720 Un meccanismo di comunicazione molto simile alle pipe, ma che non presenta il
721 problema della unidirezionalità del flusso dei dati, è quello dei cosiddetti
722 \textsl{socket locali} (o \textit{Unix domain socket}). Tratteremo l'argomento
723 dei socket in cap.~\ref{cha:socket_intro},\footnote{si tratta comunque di
724 oggetti di comunicazione che, come le pipe, sono utilizzati attraverso dei
725 file descriptor.} nell'ambito dell'interfaccia generale che essi forniscono
726 per la programmazione di rete; e vedremo anche
727 (in~sez.~\ref{sec:sock_sa_local}) come si possono definire dei file speciali
728 (di tipo socket, analoghi a quello associati alle fifo) cui si accede però
729 attraverso quella medesima interfaccia; vale però la pena esaminare qui una
730 modalità di uso dei socket locali\footnote{la funzione \func{socketpair} è
731 stata introdotta in BSD4.4, ma è supportata in genere da qualunque sistema
732 che fornisca l'interfaccia dei socket.} che li rende sostanzialmente
733 identici ad una pipe bidirezionale.
735 La funzione \funcd{socketpair} infatti consente di creare una coppia di file
736 descriptor connessi fra di loro (tramite un socket, appunto), senza dover
737 ricorrere ad un file speciale sul filesystem, i descrittori sono del tutto
738 analoghi a quelli che si avrebbero con una chiamata a \func{pipe}, con la sola
739 differenza è che in questo caso il flusso dei dati può essere effettuato in
740 entrambe le direzioni. Il prototipo della funzione è:
742 \headdecl{sys/types.h}
743 \headdecl{sys/socket.h}
745 \funcdecl{int socketpair(int domain, int type, int protocol, int sv[2])}
747 Crea una coppia di socket connessi fra loro.
749 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
750 errore, nel qual caso \var{errno} assumerà uno dei valori:
752 \item[\errcode{EAFNOSUPPORT}] i socket locali non sono supportati.
753 \item[\errcode{EPROTONOSUPPORT}] il protocollo specificato non è supportato.
754 \item[\errcode{EOPNOTSUPP}] il protocollo specificato non supporta la
755 creazione di coppie di socket.
757 ed inoltre \errval{EMFILE}, \errval{EFAULT}.
761 La funzione restituisce in \param{sv} la coppia di descrittori connessi fra di
762 loro: quello che si scrive su uno di essi sarà ripresentato in input
763 sull'altro e viceversa. Gli argomenti \param{domain}, \param{type} e
764 \param{protocol} derivano dall'interfaccia dei socket (vedi
765 sez.~\ref{sec:sock_creation}) che è quella che fornisce il substrato per
766 connettere i due descrittori, ma in questo caso i soli valori validi che
767 possono essere specificati sono rispettivamente \const{AF\_UNIX},
768 \const{SOCK\_STREAM} e \val{0}.
770 L'utilità di chiamare questa funzione per evitare due chiamate a \func{pipe}
771 può sembrare limitata; in realtà l'utilizzo di questa funzione (e dei socket
772 locali in generale) permette di trasmettere attraverso le linea non solo dei
773 dati, ma anche dei file descriptor: si può cioè passare da un processo ad un
774 altro un file descriptor, con una sorta di duplicazione dello stesso non
775 all'interno di uno stesso processo, ma fra processi distinti (torneremo su
776 questa funzionalità in sez.~\ref{sec:sock_fd_passing}).
779 \section{Il sistema di comunicazione fra processi di System V}
782 Benché le pipe e le fifo siano ancora ampiamente usate, esse scontano il
783 limite fondamentale che il meccanismo di comunicazione che forniscono è
784 rigidamente sequenziale: una situazione in cui un processo scrive qualcosa che
785 molti altri devono poter leggere non può essere implementata con una pipe.
787 Per questo nello sviluppo di System V vennero introdotti una serie di nuovi
788 oggetti per la comunicazione fra processi ed una nuova interfaccia di
789 programmazione, che fossero in grado di garantire una maggiore flessibilità.
790 In questa sezione esamineremo come Linux supporta quello che viene chiamato il
791 \textsl{Sistema di comunicazione fra processi} di System V, cui da qui in
792 avanti faremo riferimento come \textit{SysV IPC} (dove IPC è la sigla di
793 \textit{Inter-Process Comunication}).
797 \subsection{Considerazioni generali}
798 \label{sec:ipc_sysv_generic}
800 La principale caratteristica del \textit{SysV IPC} è quella di essere basato
801 su oggetti permanenti che risiedono nel kernel. Questi, a differenza di quanto
802 avviene per i file descriptor, non mantengono un contatore dei riferimenti, e
803 non vengono cancellati dal sistema una volta che non sono più in uso.
805 Questo comporta due problemi: il primo è che, al contrario di quanto avviene
806 per pipe e fifo, la memoria allocata per questi oggetti non viene rilasciata
807 automaticamente quando non c'è più nessuno che li utilizzi, ed essi devono
808 essere cancellati esplicitamente, se non si vuole che restino attivi fino al
809 riavvio del sistema. Il secondo problema è che, dato che non c'è, come per i
810 file, un contatore del numero di riferimenti che ne indichi l'essere in uso,
811 essi possono essere cancellati anche se ci sono dei processi che li stanno
812 utilizzando, con tutte le conseguenze (negative) del caso.
814 Un'ulteriore caratteristica negativa è che gli oggetti usati nel \textit{SysV
815 IPC} vengono creati direttamente dal kernel, e sono accessibili solo
816 specificando il relativo \textsl{identificatore}. Questo è un numero
817 progressivo (un po' come il \acr{pid} dei processi) che il kernel assegna a
818 ciascuno di essi quanto vengono creati (sul procedimento di assegnazione
819 torneremo in sez.~\ref{sec:ipc_sysv_id_use}). L'identificatore viene restituito
820 dalle funzioni che creano l'oggetto, ed è quindi locale al processo che le ha
821 eseguite. Dato che l'identificatore viene assegnato dinamicamente dal kernel
822 non è possibile prevedere quale sarà, né utilizzare un qualche valore statico,
823 si pone perciò il problema di come processi diversi possono accedere allo
826 Per risolvere il problema nella struttura \struct{ipc\_perm} che il kernel
827 associa a ciascun oggetto, viene mantenuto anche un campo apposito che
828 contiene anche una \textsl{chiave}, identificata da una variabile del tipo
829 primitivo \type{key\_t}, da specificare in fase di creazione dell'oggetto, e
830 tramite la quale è possibile ricavare l'identificatore.\footnote{in sostanza
831 si sposta il problema dell'accesso dalla classificazione in base
832 all'identificatore alla classificazione in base alla chiave, una delle tante
833 complicazioni inutili presenti nel \textit{SysV IPC}.} Oltre la chiave, la
834 struttura, la cui definizione è riportata in fig.~\ref{fig:ipc_ipc_perm},
835 mantiene varie proprietà ed informazioni associate all'oggetto.
838 \footnotesize \centering
839 \begin{minipage}[c]{15cm}
840 \includestruct{listati/ipc_perm.h}
843 \caption{La struttura \structd{ipc\_perm}, come definita in
845 \label{fig:ipc_ipc_perm}
848 Usando la stessa chiave due processi diversi possono ricavare l'identificatore
849 associato ad un oggetto ed accedervi. Il problema che sorge a questo punto è
850 come devono fare per accordarsi sull'uso di una stessa chiave. Se i processi
851 sono \textsl{imparentati} la soluzione è relativamente semplice, in tal caso
852 infatti si può usare il valore speciale \texttt{IPC\_PRIVATE} per creare un
853 nuovo oggetto nel processo padre, l'identificatore così ottenuto sarà
854 disponibile in tutti i figli, e potrà essere passato come argomento attraverso
857 Però quando i processi non sono \textsl{imparentati} (come capita tutte le
858 volte che si ha a che fare con un sistema client-server) tutto questo non è
859 possibile; si potrebbe comunque salvare l'identificatore su un file noto, ma
860 questo ovviamente comporta lo svantaggio di doverselo andare a rileggere. Una
861 alternativa più efficace è quella che i programmi usino un valore comune per
862 la chiave (che ad esempio può essere dichiarato in un header comune), ma c'è
863 sempre il rischio che questa chiave possa essere stata già utilizzata da
864 qualcun altro. Dato che non esiste una convenzione su come assegnare queste
865 chiavi in maniera univoca l'interfaccia mette a disposizione una funzione
866 apposita, \funcd{ftok}, che permette di ottenere una chiave specificando il
867 nome di un file ed un numero di versione; il suo prototipo è:
869 \headdecl{sys/types.h}
872 \funcdecl{key\_t ftok(const char *pathname, int proj\_id)}
874 Restituisce una chiave per identificare un oggetto del \textit{SysV IPC}.
876 \bodydesc{La funzione restituisce la chiave in caso di successo e -1
877 altrimenti, nel qual caso \var{errno} sarà uno dei possibili codici di
878 errore di \func{stat}.}
881 La funzione determina un valore della chiave sulla base di \param{pathname},
882 che deve specificare il \itindex{pathname} \textit{pathname} di un file
883 effettivamente esistente e di un numero di progetto \param{proj\_id)}, che di
884 norma viene specificato come carattere, dato che ne vengono utilizzati solo
885 gli 8 bit meno significativi.\footnote{nelle libc4 e libc5, come avviene in
886 SunOS, l'argomento \param{proj\_id} è dichiarato tipo \ctyp{char}, le
887 \acr{glibc} usano il prototipo specificato da XPG4, ma vengono lo stesso
888 utilizzati gli 8 bit meno significativi.}
890 Il problema è che anche così non c'è la sicurezza che il valore della chiave
891 sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
892 con i 16 bit meno significativi \index{inode} dell'inode del file
893 \param{pathname} (che vengono ottenuti attraverso \func{stat}, da cui derivano
894 i possibili errori), e gli 8 bit meno significativi del numero del dispositivo
895 su cui è il file. Diventa perciò relativamente facile ottenere delle
896 collisioni, specie se i file sono su dispositivi con lo stesso \textit{minor
897 number}, come \file{/dev/hda1} e \file{/dev/sda1}.
899 In genere quello che si fa è utilizzare un file comune usato dai programmi che
900 devono comunicare (ad esempio un header comune, o uno dei programmi che devono
901 usare l'oggetto in questione), utilizzando il numero di progetto per ottenere
902 le chiavi che interessano. In ogni caso occorre sempre controllare, prima di
903 creare un oggetto, che la chiave non sia già stata utilizzata. Se questo va
904 bene in fase di creazione, le cose possono complicarsi per i programmi che
905 devono solo accedere, in quanto, a parte gli eventuali controlli sugli altri
906 attributi di \struct{ipc\_perm}, non esiste una modalità semplice per essere
907 sicuri che l'oggetto associato ad una certa chiave sia stato effettivamente
908 creato da chi ci si aspetta.
910 Questo è, insieme al fatto che gli oggetti sono permanenti e non mantengono un
911 contatore di riferimenti per la cancellazione automatica, il principale
912 problema del \textit{SysV IPC}. Non esiste infatti una modalità chiara per
913 identificare un oggetto, come sarebbe stato se lo si fosse associato ad in
914 file, e tutta l'interfaccia è inutilmente complessa. Per questo ne è stata
915 effettuata una revisione completa nello standard POSIX.1b, che tratteremo in
916 sez.~\ref{sec:ipc_posix}.
919 \subsection{Il controllo di accesso}
920 \label{sec:ipc_sysv_access_control}
922 Oltre alle chiavi, abbiamo visto che ad ogni oggetto sono associate in
923 \struct{ipc\_perm} ulteriori informazioni, come gli identificatori del creatore
924 (nei campi \var{cuid} e \var{cgid}) e del proprietario (nei campi \var{uid} e
925 \var{gid}) dello stesso, e un insieme di permessi (nel campo \var{mode}). In
926 questo modo è possibile definire un controllo di accesso sugli oggetti di IPC,
927 simile a quello che si ha per i file (vedi sez.~\ref{sec:file_perm_overview}).
929 Benché questo controllo di accesso sia molto simile a quello dei file, restano
930 delle importanti differenze. La prima è che il permesso di esecuzione non
931 esiste (e se specificato viene ignorato), per cui si può parlare solo di
932 permessi di lettura e scrittura (nel caso dei semafori poi quest'ultimo è più
933 propriamente un permesso di modifica). I valori di \var{mode} sono gli stessi
934 ed hanno lo stesso significato di quelli riportati in
935 tab.~\ref{tab:file_mode_flags}\footnote{se però si vogliono usare le costanti
936 simboliche ivi definite occorrerà includere il file \file{sys/stat.h},
937 alcuni sistemi definiscono le costanti \const{MSG\_R} (\texttt{0400}) e
938 \const{MSG\_W} (\texttt{0200}) per indicare i permessi base di lettura e
939 scrittura per il proprietario, da utilizzare, con gli opportuni shift, pure
940 per il gruppo e gli altri, in Linux, visto la loro scarsa utilità, queste
941 costanti non sono definite.} e come per i file definiscono gli accessi per
942 il proprietario, il suo gruppo e tutti gli altri.
944 Quando l'oggetto viene creato i campi \var{cuid} e \var{uid} di
945 \struct{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono impostati
946 rispettivamente al valore dell'user-ID e del group-ID effettivo del processo
947 che ha chiamato la funzione, ma, mentre i campi \var{uid} e \var{gid} possono
948 essere cambiati, i campi \var{cuid} e \var{cgid} restano sempre gli stessi.
950 Il controllo di accesso è effettuato a due livelli. Il primo livello è nelle
951 funzioni che richiedono l'identificatore di un oggetto data la chiave. Queste
952 specificano tutte un argomento \param{flag}, in tal caso quando viene
953 effettuata la ricerca di una chiave, qualora \param{flag} specifichi dei
954 permessi, questi vengono controllati e l'identificatore viene restituito solo
955 se corrispondono a quelli dell'oggetto. Se ci sono dei permessi non presenti
956 in \var{mode} l'accesso sarà negato. Questo controllo però è di utilità
957 indicativa, dato che è sempre possibile specificare per \param{flag} un valore
958 nullo, nel qual caso l'identificatore sarà restituito comunque.
960 Il secondo livello di controllo è quello delle varie funzioni che accedono
961 direttamente (in lettura o scrittura) all'oggetto. In tal caso lo schema dei
962 controlli è simile a quello dei file, ed avviene secondo questa sequenza:
964 \item se il processo ha i privilegi di amministratore l'accesso è sempre
966 \item se l'user-ID effettivo del processo corrisponde o al valore del campo
967 \var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario
968 in \var{mode} è appropriato\footnote{per appropriato si intende che è
969 impostato il permesso di scrittura per le operazioni di scrittura e quello
970 di lettura per le operazioni di lettura.} l'accesso è consentito.
971 \item se il group-ID effettivo del processo corrisponde o al
972 valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso
973 per il gruppo in \var{mode} è appropriato l'accesso è consentito.
974 \item se il permesso per gli altri è appropriato l'accesso è consentito.
976 solo se tutti i controlli elencati falliscono l'accesso è negato. Si noti che
977 a differenza di quanto avviene per i permessi dei file, fallire in uno dei
978 passi elencati non comporta il fallimento dell'accesso. Un'ulteriore
979 differenza rispetto a quanto avviene per i file è che per gli oggetti di IPC
980 il valore di \var{umask} (si ricordi quanto esposto in
981 sez.~\ref{sec:file_perm_management}) non ha alcun significato.
984 \subsection{Gli identificatori ed il loro utilizzo}
985 \label{sec:ipc_sysv_id_use}
987 L'unico campo di \struct{ipc\_perm} del quale non abbiamo ancora parlato è
988 \var{seq}, che in fig.~\ref{fig:ipc_ipc_perm} è qualificato con un criptico
989 ``\textsl{numero di sequenza}'', ne parliamo adesso dato che esso è
990 strettamente attinente alle modalità con cui il kernel assegna gli
991 identificatori degli oggetti del sistema di IPC.
993 Quando il sistema si avvia, alla creazione di ogni nuovo oggetto di IPC viene
994 assegnato un numero progressivo, pari al numero di oggetti di quel tipo
995 esistenti. Se il comportamento fosse sempre questo sarebbe identico a quello
996 usato nell'assegnazione dei file descriptor nei processi, ed i valori degli
997 identificatori tenderebbero ad essere riutilizzati spesso e restare di piccole
998 dimensioni (inferiori al numero massimo di oggetti disponibili).
1000 Questo va benissimo nel caso dei file descriptor, che sono locali ad un
1001 processo, ma qui il comportamento varrebbe per tutto il sistema, e per
1002 processi del tutto scorrelati fra loro. Così si potrebbero avere situazioni
1003 come quella in cui un server esce e cancella le sue code di messaggi, ed il
1004 relativo identificatore viene immediatamente assegnato a quelle di un altro
1005 server partito subito dopo, con la possibilità che i client del primo non
1006 facciano in tempo ad accorgersi dell'avvenuto, e finiscano con l'interagire
1007 con gli oggetti del secondo, con conseguenze imprevedibili.
1009 Proprio per evitare questo tipo di situazioni il sistema usa il valore di
1010 \var{seq} per provvedere un meccanismo che porti gli identificatori ad
1011 assumere tutti i valori possibili, rendendo molto più lungo il periodo in cui
1012 un identificatore può venire riutilizzato.
1014 Il sistema dispone sempre di un numero fisso di oggetti di IPC,\footnote{fino
1015 al kernel 2.2.x questi valori, definiti dalle costanti \const{MSGMNI},
1016 \const{SEMMNI} e \const{SHMMNI}, potevano essere cambiati (come tutti gli
1017 altri limiti relativi al \textit{SysV IPC}) solo con una ricompilazione del
1018 kernel, andando a modificarne la definizione nei relativi header file. A
1019 partire dal kernel 2.4.x è possibile cambiare questi valori a sistema attivo
1020 scrivendo sui file \procrelfile{/proc/sys/kernel}{shmmni},
1021 \procrelfile{/proc/sys/kernel}{msgmni} e \procrelfile{/proc/sys/kernel}{sem}
1022 di \file{/proc/sys/kernel} o con l'uso di \func{sysctl}.} e per ciascuno di
1023 essi viene mantenuto in \var{seq} un numero di sequenza progressivo che viene
1024 incrementato di uno ogni volta che l'oggetto viene cancellato. Quando
1025 l'oggetto viene creato usando uno spazio che era già stato utilizzato in
1026 precedenza per restituire l'identificatore al numero di oggetti presenti viene
1027 sommato il valore di \var{seq} moltiplicato per il numero massimo di oggetti
1028 di quel tipo,\footnote{questo vale fino ai kernel della serie 2.2.x, dalla
1029 serie 2.4.x viene usato lo stesso fattore per tutti gli oggetti, esso è dato
1030 dalla costante \const{IPCMNI}, definita in \file{include/linux/ipc.h}, che
1031 indica il limite massimo per il numero di tutti oggetti di IPC, ed il cui
1032 valore è 32768.} si evita così il riutilizzo degli stessi numeri, e si fa
1033 sì che l'identificatore assuma tutti i valori possibili.
1035 \begin{figure}[!htb]
1036 \footnotesize \centering
1037 \begin{minipage}[c]{15cm}
1038 \includecodesample{listati/IPCTestId.c}
1041 \caption{Sezione principale del programma di test per l'assegnazione degli
1042 identificatori degli oggetti di IPC \file{IPCTestId.c}.}
1043 \label{fig:ipc_sysv_idtest}
1046 In fig.~\ref{fig:ipc_sysv_idtest} è riportato il codice di un semplice
1047 programma di test che si limita a creare un oggetto (specificato a riga di
1048 comando), stamparne il numero di identificatore e cancellarlo per un numero
1049 specificato di volte. Al solito non si è riportato il codice della gestione
1050 delle opzioni a riga di comando, che permette di specificare quante volte
1051 effettuare il ciclo \var{n}, e su quale tipo di oggetto eseguirlo.
1053 La figura non riporta il codice di selezione delle opzioni, che permette di
1054 inizializzare i valori delle variabili \var{type} al tipo di oggetto voluto, e
1055 \var{n} al numero di volte che si vuole effettuare il ciclo di creazione,
1056 stampa, cancellazione. I valori di default sono per l'uso delle code di
1057 messaggi e un ciclo di 5 volte. Se si lancia il comando si otterrà qualcosa
1060 piccardi@gont sources]$ ./ipctestid
1062 Identifier Value 32768
1063 Identifier Value 65536
1064 Identifier Value 98304
1065 Identifier Value 131072
1067 il che ci mostra che abbiamo un kernel della serie 2.4.x nel quale non avevamo
1068 ancora usato nessuna coda di messaggi. Se ripetiamo il comando otterremo
1071 [piccardi@gont sources]$ ./ipctestid
1072 Identifier Value 163840
1073 Identifier Value 196608
1074 Identifier Value 229376
1075 Identifier Value 262144
1076 Identifier Value 294912
1078 che ci mostra come il valore di \var{seq} sia in effetti una quantità
1079 mantenuta staticamente all'interno del sistema.
1082 \subsection{Code di messaggi}
1083 \label{sec:ipc_sysv_mq}
1085 Il primo oggetto introdotto dal \textit{SysV IPC} è quello delle code di
1086 messaggi. Le code di messaggi sono oggetti analoghi alle pipe o alle fifo,
1087 anche se la loro struttura è diversa, ed il loro scopo principale è appunto
1088 quello di permettere a processi diversi di scambiarsi dei dati.
1090 La funzione che permette di richiedere al sistema l'identificatore di una coda
1091 di messaggi esistente (o di crearne una se questa non esiste) è
1092 \funcd{msgget}; il suo prototipo è:
1094 \headdecl{sys/types.h}
1095 \headdecl{sys/ipc.h}
1096 \headdecl{sys/msg.h}
1098 \funcdecl{int msgget(key\_t key, int flag)}
1100 Restituisce l'identificatore di una coda di messaggi.
1102 \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
1103 in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
1105 \item[\errcode{EACCES}] il processo chiamante non ha i privilegi per accedere
1106 alla coda richiesta.
1107 \item[\errcode{EEXIST}] si è richiesta la creazione di una coda che già
1108 esiste, ma erano specificati sia \const{IPC\_CREAT} che \const{IPC\_EXCL}.
1109 \item[\errcode{EIDRM}] la coda richiesta è marcata per essere cancellata.
1110 \item[\errcode{ENOENT}] si è cercato di ottenere l'identificatore di una coda
1111 di messaggi specificando una chiave che non esiste e \const{IPC\_CREAT}
1112 non era specificato.
1113 \item[\errcode{ENOSPC}] si è cercato di creare una coda di messaggi quando è
1114 stato superato il limite massimo di code (\const{MSGMNI}).
1116 ed inoltre \errval{ENOMEM}.
1120 Le funzione (come le analoghe che si usano per gli altri oggetti) serve sia a
1121 ottenere l'identificatore di una coda di messaggi esistente, che a crearne una
1122 nuova. L'argomento \param{key} specifica la chiave che è associata
1123 all'oggetto, eccetto il caso in cui si specifichi il valore
1124 \const{IPC\_PRIVATE}, nel qual caso la coda è creata ex-novo e non vi è
1125 associata alcuna chiave, il processo (ed i suoi eventuali figli) potranno
1126 farvi riferimento solo attraverso l'identificatore.
1128 Se invece si specifica un valore diverso da \const{IPC\_PRIVATE}\footnote{in
1129 Linux questo significa un valore diverso da zero.} l'effetto della funzione
1130 dipende dal valore di \param{flag}, se questo è nullo la funzione si limita ad
1131 effettuare una ricerca sugli oggetti esistenti, restituendo l'identificatore
1132 se trova una corrispondenza, o fallendo con un errore di \errcode{ENOENT} se
1133 non esiste o di \errcode{EACCES} se si sono specificati dei permessi non
1136 Se invece si vuole creare una nuova coda di messaggi \param{flag} non può
1137 essere nullo e deve essere fornito come maschera binaria, impostando il bit
1138 corrispondente al valore \const{IPC\_CREAT}. In questo caso i nove bit meno
1139 significativi di \param{flag} saranno usati come permessi per il nuovo
1140 oggetto, secondo quanto illustrato in sez.~\ref{sec:ipc_sysv_access_control}.
1141 Se si imposta anche il bit corrispondente a \const{IPC\_EXCL} la funzione avrà
1142 successo solo se l'oggetto non esiste già, fallendo con un errore di
1143 \errcode{EEXIST} altrimenti.
1145 Si tenga conto che l'uso di \const{IPC\_PRIVATE} non impedisce ad altri
1146 processi di accedere alla coda (se hanno privilegi sufficienti) una volta che
1147 questi possano indovinare o ricavare (ad esempio per tentativi)
1148 l'identificatore ad essa associato. Per come sono implementati gli oggetti di
1149 IPC infatti non esiste una maniera che garantisca l'accesso esclusivo ad una
1150 coda di messaggi. Usare \const{IPC\_PRIVATE} o const{IPC\_CREAT} e
1151 \const{IPC\_EXCL} per \param{flag} comporta solo la creazione di una nuova
1157 \begin{tabular}[c]{|c|r|l|l|}
1159 \textbf{Costante} & \textbf{Valore} & \textbf{File in \texttt{proc}}
1160 & \textbf{Significato} \\
1163 \const{MSGMNI}& 16& \file{msgmni} & Numero massimo di code di
1165 \const{MSGMAX}& 8192& \file{msgmax} & Dimensione massima di un singolo
1167 \const{MSGMNB}&16384& \file{msgmnb} & Dimensione massima del contenuto di
1171 \caption{Valori delle costanti associate ai limiti delle code di messaggi.}
1172 \label{tab:ipc_msg_limits}
1175 Le code di messaggi sono caratterizzate da tre limiti fondamentali, definiti
1176 negli header e corrispondenti alle prime tre costanti riportate in
1177 tab.~\ref{tab:ipc_msg_limits}, come accennato però in Linux è possibile
1178 modificare questi limiti attraverso l'uso di \func{sysctl} o scrivendo nei
1179 file \procrelfile{/proc/sys/kernel}{msgmax},
1180 \procrelfile{/proc/sys/kernel}{msgmnb} e
1181 \procrelfile{/proc/sys/kernel}{msgmni} di \file{/proc/sys/kernel/}.
1185 \centering \includegraphics[width=15cm]{img/mqstruct}
1186 \caption{Schema della struttura di una coda messaggi.}
1187 \label{fig:ipc_mq_schema}
1191 Una coda di messaggi è costituita da una \itindex{linked~list} \textit{linked
1192 list};\footnote{una \itindex{linked~list} \textit{linked list} è una tipica
1193 struttura di dati, organizzati in una lista in cui ciascun elemento contiene
1194 un puntatore al successivo. In questo modo la struttura è veloce
1195 nell'estrazione ed immissione dei dati dalle estremità dalla lista (basta
1196 aggiungere un elemento in testa o in coda ed aggiornare un puntatore), e
1197 relativamente veloce da attraversare in ordine sequenziale (seguendo i
1198 puntatori), è invece relativamente lenta nell'accesso casuale e nella
1199 ricerca.} i nuovi messaggi vengono inseriti in coda alla lista e vengono
1200 letti dalla cima, in fig.~\ref{fig:ipc_mq_schema} si è riportato lo schema con
1201 cui queste strutture vengono mantenute dal kernel.\footnote{lo schema
1202 illustrato in fig.~\ref{fig:ipc_mq_schema} è in realtà una semplificazione
1203 di quello usato effettivamente fino ai kernel della serie 2.2.x, nei kernel
1204 della serie 2.4.x la gestione delle code di messaggi è stata modificata ed è
1205 effettuata in maniera diversa; abbiamo mantenuto lo schema precedente in
1206 quanto illustra comunque in maniera più che adeguata i principi di
1207 funzionamento delle code di messaggi.}
1209 \begin{figure}[!htb]
1210 \footnotesize \centering
1211 \begin{minipage}[c]{15cm}
1212 \includestruct{listati/msqid_ds.h}
1215 \caption{La struttura \structd{msqid\_ds}, associata a ciascuna coda di
1217 \label{fig:ipc_msqid_ds}
1220 A ciascuna coda è associata una struttura \struct{msgid\_ds}, la cui
1221 definizione, è riportata in fig.~\ref{fig:ipc_msqid_ds}. In questa struttura il
1222 kernel mantiene le principali informazioni riguardo lo stato corrente della
1223 coda.\footnote{come accennato questo vale fino ai kernel della serie 2.2.x,
1224 essa viene usata nei kernel della serie 2.4.x solo per compatibilità in
1225 quanto è quella restituita dalle funzioni dell'interfaccia. Si noti come ci
1226 sia una differenza con i campi mostrati nello schema di
1227 fig.~\ref{fig:ipc_mq_schema} che sono presi dalla definizione di
1228 \file{linux/msg.h}, e fanno riferimento alla definizione della omonima
1229 struttura usata nel kernel.} In fig.~\ref{fig:ipc_msqid_ds} sono elencati i
1230 campi significativi definiti in \file{sys/msg.h}, a cui si sono aggiunti gli
1231 ultimi tre campi che sono previsti dalla implementazione originale di System
1232 V, ma non dallo standard Unix98.
1234 Quando si crea una nuova coda con \func{msgget} questa struttura viene
1235 inizializzata, in particolare il campo \var{msg\_perm} viene inizializzato
1236 come illustrato in sez.~\ref{sec:ipc_sysv_access_control}, per quanto riguarda
1237 gli altri campi invece:
1239 \item il campo \var{msg\_qnum}, che esprime il numero di messaggi presenti
1240 sulla coda, viene inizializzato a 0.
1241 \item i campi \var{msg\_lspid} e \var{msg\_lrpid}, che esprimono
1242 rispettivamente il \acr{pid} dell'ultimo processo che ha inviato o ricevuto
1243 un messaggio sulla coda, sono inizializzati a 0.
1244 \item i campi \var{msg\_stime} e \var{msg\_rtime}, che esprimono
1245 rispettivamente il tempo in cui è stato inviato o ricevuto l'ultimo
1246 messaggio sulla coda, sono inizializzati a 0.
1247 \item il campo \var{msg\_ctime}, che esprime il tempo di creazione della coda,
1248 viene inizializzato al tempo corrente.
1249 \item il campo \var{msg\_qbytes} che esprime la dimensione massima del
1250 contenuto della coda (in byte) viene inizializzato al valore preimpostato
1251 del sistema (\const{MSGMNB}).
1252 \item i campi \var{msg\_first} e \var{msg\_last} che esprimono l'indirizzo del
1253 primo e ultimo messaggio sono inizializzati a \val{NULL} e
1254 \var{msg\_cbytes}, che esprime la dimensione in byte dei messaggi presenti è
1255 inizializzato a zero. Questi campi sono ad uso interno dell'implementazione
1256 e non devono essere utilizzati da programmi in user space).
1259 Una volta creata una coda di messaggi le operazioni di controllo vengono
1260 effettuate con la funzione \funcd{msgctl}, che (come le analoghe \func{semctl}
1261 e \func{shmctl}) fa le veci di quello che \func{ioctl} è per i file; il suo
1264 \headdecl{sys/types.h}
1265 \headdecl{sys/ipc.h}
1266 \headdecl{sys/msg.h}
1268 \funcdecl{int msgctl(int msqid, int cmd, struct msqid\_ds *buf)}
1270 Esegue l'operazione specificata da \param{cmd} sulla coda \param{msqid}.
1272 \bodydesc{La funzione restituisce 0 in caso di successo o -1 in caso di
1273 errore, nel qual caso \var{errno} assumerà uno dei valori:
1275 \item[\errcode{EACCES}] si è richiesto \const{IPC\_STAT} ma processo
1276 chiamante non ha i privilegi di lettura sulla coda.
1277 \item[\errcode{EIDRM}] la coda richiesta è stata cancellata.
1278 \item[\errcode{EPERM}] si è richiesto \const{IPC\_SET} o \const{IPC\_RMID} ma
1279 il processo non ha i privilegi, o si è richiesto di aumentare il valore di
1280 \var{msg\_qbytes} oltre il limite \const{MSGMNB} senza essere
1283 ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
1287 La funzione permette di accedere ai valori della struttura \struct{msqid\_ds},
1288 mantenuta all'indirizzo \param{buf}, per la coda specificata
1289 dall'identificatore \param{msqid}. Il comportamento della funzione dipende dal
1290 valore dell'argomento \param{cmd}, che specifica il tipo di azione da
1291 eseguire; i valori possibili sono:
1292 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
1293 \item[\const{IPC\_STAT}] Legge le informazioni riguardo la coda nella
1294 struttura indicata da \param{buf}. Occorre avere il permesso di lettura
1296 \item[\const{IPC\_RMID}] Rimuove la coda, cancellando tutti i dati, con
1297 effetto immediato. Tutti i processi che cercheranno di accedere alla coda
1298 riceveranno un errore di \errcode{EIDRM}, e tutti processi in attesa su
1299 funzioni di lettura o di scrittura sulla coda saranno svegliati ricevendo
1300 il medesimo errore. Questo comando può essere eseguito solo da un processo
1301 con user-ID effettivo corrispondente al creatore o al proprietario della
1302 coda, o all'amministratore.
1303 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
1304 della coda, ed il limite massimo sulle dimensioni del totale dei messaggi in
1305 essa contenuti (\var{msg\_qbytes}). I valori devono essere passati in una
1306 struttura \struct{msqid\_ds} puntata da \param{buf}. Per modificare i valori
1307 di \var{msg\_perm.mode}, \var{msg\_perm.uid} e \var{msg\_perm.gid} occorre
1308 essere il proprietario o il creatore della coda, oppure l'amministratore; lo
1309 stesso vale per \var{msg\_qbytes}, ma l'amministratore ha la facoltà di
1310 incrementarne il valore a limiti superiori a \const{MSGMNB}.
1314 Una volta che si abbia a disposizione l'identificatore, per inviare un
1315 messaggio su una coda si utilizza la funzione \funcd{msgsnd}; il suo prototipo
1318 \headdecl{sys/types.h}
1319 \headdecl{sys/ipc.h}
1320 \headdecl{sys/msg.h}
1322 \funcdecl{int msgsnd(int msqid, struct msgbuf *msgp, size\_t msgsz, int
1325 Invia un messaggio sulla coda \param{msqid}.
1327 \bodydesc{La funzione restituisce 0, e -1 in caso di errore, nel qual caso
1328 \var{errno} assumerà uno dei valori:
1330 \item[\errcode{EACCES}] non si hanno i privilegi di accesso sulla coda.
1331 \item[\errcode{EIDRM}] la coda è stata cancellata.
1332 \item[\errcode{EAGAIN}] il messaggio non può essere inviato perché si è
1333 superato il limite \var{msg\_qbytes} sul numero massimo di byte presenti
1334 sulla coda, e si è richiesto \const{IPC\_NOWAIT} in \param{flag}.
1335 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
1336 \item[\errcode{EINVAL}] si è specificato un \param{msgid} invalido, o un
1337 valore non positivo per \param{mtype}, o un valore di \param{msgsz}
1338 maggiore di \const{MSGMAX}.
1340 ed inoltre \errval{EFAULT} ed \errval{ENOMEM}.
1344 La funzione inserisce il messaggio sulla coda specificata da \param{msqid}; il
1345 messaggio ha lunghezza specificata da \param{msgsz} ed è passato attraverso il
1346 l'argomento \param{msgp}. Quest'ultimo deve venire passato sempre come
1347 puntatore ad una struttura \struct{msgbuf} analoga a quella riportata in
1348 fig.~\ref{fig:ipc_msbuf} che è quella che deve contenere effettivamente il
1349 messaggio. La dimensione massima per il testo di un messaggio non può
1350 comunque superare il limite \const{MSGMAX}.
1352 La struttura di fig.~\ref{fig:ipc_msbuf} è comunque solo un modello, tanto che
1353 la definizione contenuta in \file{sys/msg.h} usa esplicitamente per il secondo
1354 campo il valore \code{mtext[1]}, che non è di nessuna utilità ai fini pratici.
1355 La sola cosa che conta è che la struttura abbia come primo membro un campo
1356 \var{mtype} come nell'esempio; esso infatti serve ad identificare il tipo di
1357 messaggio e deve essere sempre specificato come intero positivo di tipo
1358 \ctyp{long}. Il campo \var{mtext} invece può essere di qualsiasi tipo e
1359 dimensione, e serve a contenere il testo del messaggio.
1361 In generale pertanto per inviare un messaggio con \func{msgsnd} si usa
1362 ridefinire una struttura simile a quella di fig.~\ref{fig:ipc_msbuf}, adattando
1363 alle proprie esigenze il campo \var{mtype}, (o ridefinendo come si vuole il
1364 corpo del messaggio, anche con più campi o con strutture più complesse) avendo
1365 però la cura di mantenere nel primo campo un valore di tipo \ctyp{long} che ne
1368 Si tenga presente che la lunghezza che deve essere indicata in questo
1369 argomento è solo quella del messaggio, non quella di tutta la struttura, se
1370 cioè \var{message} è una propria struttura che si passa alla funzione,
1371 \param{msgsz} dovrà essere uguale a \code{sizeof(message)-sizeof(long)}, (se
1372 consideriamo il caso dell'esempio in fig.~\ref{fig:ipc_msbuf}, \param{msgsz}
1373 dovrà essere pari a \const{LENGTH}).
1375 \begin{figure}[!htb]
1376 \footnotesize \centering
1377 \begin{minipage}[c]{15cm}
1378 \includestruct{listati/msgbuf.h}
1381 \caption{Schema della struttura \structd{msgbuf}, da utilizzare come
1382 argomento per inviare/ricevere messaggi.}
1383 \label{fig:ipc_msbuf}
1386 Per capire meglio il funzionamento della funzione riprendiamo in
1387 considerazione la struttura della coda illustrata in
1388 fig.~\ref{fig:ipc_mq_schema}. Alla chiamata di \func{msgsnd} il nuovo messaggio
1389 sarà aggiunto in fondo alla lista inserendo una nuova struttura \struct{msg},
1390 il puntatore \var{msg\_last} di \struct{msqid\_ds} verrà aggiornato, come pure
1391 il puntatore al messaggio successivo per quello che era il precedente ultimo
1392 messaggio; il valore di \var{mtype} verrà mantenuto in \var{msg\_type} ed il
1393 valore di \param{msgsz} in \var{msg\_ts}; il testo del messaggio sarà copiato
1394 all'indirizzo specificato da \var{msg\_spot}.
1396 Il valore dell'argomento \param{flag} permette di specificare il comportamento
1397 della funzione. Di norma, quando si specifica un valore nullo, la funzione
1398 ritorna immediatamente a meno che si sia ecceduto il valore di
1399 \var{msg\_qbytes}, o il limite di sistema sul numero di messaggi, nel qual
1400 caso si blocca mandando il processo in stato di \textit{sleep}. Se si
1401 specifica per \param{flag} il valore \const{IPC\_NOWAIT} la funzione opera in
1402 modalità non bloccante, ed in questi casi ritorna immediatamente con un errore
1403 di \errcode{EAGAIN}.
1405 Se non si specifica \const{IPC\_NOWAIT} la funzione resterà bloccata fintanto
1406 che non si liberano risorse sufficienti per poter inserire nella coda il
1407 messaggio, nel qual caso ritornerà normalmente. La funzione può ritornare, con
1408 una condizione di errore anche in due altri casi: quando la coda viene rimossa
1409 (nel qual caso si ha un errore di \errcode{EIDRM}) o quando la funzione viene
1410 interrotta da un segnale (nel qual caso si ha un errore di \errcode{EINTR}).
1412 Una volta completato con successo l'invio del messaggio sulla coda, la
1413 funzione aggiorna i dati mantenuti in \struct{msqid\_ds}, in particolare
1416 \item Il valore di \var{msg\_lspid}, che viene impostato al \acr{pid} del
1418 \item Il valore di \var{msg\_qnum}, che viene incrementato di uno.
1419 \item Il valore \var{msg\_stime}, che viene impostato al tempo corrente.
1422 La funzione che viene utilizzata per estrarre un messaggio da una coda è
1423 \funcd{msgrcv}; il suo prototipo è:
1425 \headdecl{sys/types.h}
1426 \headdecl{sys/ipc.h}
1427 \headdecl{sys/msg.h}
1429 \funcdecl{ssize\_t msgrcv(int msqid, struct msgbuf *msgp, size\_t msgsz,
1430 long msgtyp, int msgflg)}
1432 Legge un messaggio dalla coda \param{msqid}.
1434 \bodydesc{La funzione restituisce il numero di byte letti in caso di
1435 successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà uno
1438 \item[\errcode{EACCES}] non si hanno i privilegi di accesso sulla coda.
1439 \item[\errcode{EIDRM}] la coda è stata cancellata.
1440 \item[\errcode{E2BIG}] il testo del messaggio è più lungo di \param{msgsz} e
1441 non si è specificato \const{MSG\_NOERROR} in \param{msgflg}.
1442 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale mentre
1443 era in attesa di ricevere un messaggio.
1444 \item[\errcode{EINVAL}] si è specificato un \param{msgid} invalido o un
1445 valore di \param{msgsz} negativo.
1447 ed inoltre \errval{EFAULT}.
1451 La funzione legge un messaggio dalla coda specificata, scrivendolo sulla
1452 struttura puntata da \param{msgp}, che dovrà avere un formato analogo a quello
1453 di fig.~\ref{fig:ipc_msbuf}. Una volta estratto, il messaggio sarà rimosso
1454 dalla coda. L'argomento \param{msgsz} indica la lunghezza massima del testo
1455 del messaggio (equivalente al valore del parametro \const{LENGTH} nell'esempio
1456 di fig.~\ref{fig:ipc_msbuf}).
1458 Se il testo del messaggio ha lunghezza inferiore a \param{msgsz} esso viene
1459 rimosso dalla coda; in caso contrario, se \param{msgflg} è impostato a
1460 \const{MSG\_NOERROR}, il messaggio viene troncato e la parte in eccesso viene
1461 perduta, altrimenti il messaggio non viene estratto e la funzione ritorna con
1462 un errore di \errcode{E2BIG}.
1464 L'argomento \param{msgtyp} permette di restringere la ricerca ad un
1465 sottoinsieme dei messaggi presenti sulla coda; la ricerca infatti è fatta con
1466 una scansione della struttura mostrata in fig.~\ref{fig:ipc_mq_schema},
1467 restituendo il primo messaggio incontrato che corrisponde ai criteri
1468 specificati (che quindi, visto come i messaggi vengono sempre inseriti dalla
1469 coda, è quello meno recente); in particolare:
1471 \item se \param{msgtyp} è 0 viene estratto il messaggio in cima alla coda, cioè
1472 quello fra i presenti che è stato inserito per primo.
1473 \item se \param{msgtyp} è positivo viene estratto il primo messaggio il cui
1474 tipo (il valore del campo \var{mtype}) corrisponde al valore di
1476 \item se \param{msgtyp} è negativo viene estratto il primo fra i messaggi con
1477 il valore più basso del tipo, fra tutti quelli il cui tipo ha un valore
1478 inferiore al valore assoluto di \param{msgtyp}.
1481 Il valore di \param{msgflg} permette di controllare il comportamento della
1482 funzione, esso può essere nullo o una maschera binaria composta da uno o più
1483 valori. Oltre al precedente \const{MSG\_NOERROR}, sono possibili altri due
1484 valori: \const{MSG\_EXCEPT}, che permette, quando \param{msgtyp} è positivo,
1485 di leggere il primo messaggio nella coda con tipo diverso da \param{msgtyp}, e
1486 \const{IPC\_NOWAIT} che causa il ritorno immediato della funzione quando non
1487 ci sono messaggi sulla coda.
1489 Il comportamento usuale della funzione infatti, se non ci sono messaggi
1490 disponibili per la lettura, è di bloccare il processo in stato di
1491 \textit{sleep}. Nel caso però si sia specificato \const{IPC\_NOWAIT} la
1492 funzione ritorna immediatamente con un errore \errcode{ENOMSG}. Altrimenti la
1493 funzione ritorna normalmente non appena viene inserito un messaggio del tipo
1494 desiderato, oppure ritorna con errore qualora la coda sia rimossa (con
1495 \var{errno} impostata a \errcode{EIDRM}) o se il processo viene interrotto da
1496 un segnale (con \var{errno} impostata a \errcode{EINTR}).
1498 Una volta completata con successo l'estrazione del messaggio dalla coda, la
1499 funzione aggiorna i dati mantenuti in \struct{msqid\_ds}, in particolare
1502 \item Il valore di \var{msg\_lrpid}, che viene impostato al \acr{pid} del
1504 \item Il valore di \var{msg\_qnum}, che viene decrementato di uno.
1505 \item Il valore \var{msg\_rtime}, che viene impostato al tempo corrente.
1508 Le code di messaggi presentano il solito problema di tutti gli oggetti del
1509 SysV IPC; essendo questi permanenti restano nel sistema occupando risorse
1510 anche quando un processo è terminato, al contrario delle pipe per le quali
1511 tutte le risorse occupate vengono rilasciate quanto l'ultimo processo che le
1512 utilizzava termina. Questo comporta che in caso di errori si può saturare il
1513 sistema, e che devono comunque essere esplicitamente previste delle funzioni
1514 di rimozione in caso di interruzioni o uscite dal programma (come vedremo in
1515 fig.~\ref{fig:ipc_mq_fortune_server}).
1517 L'altro problema è non facendo uso di file descriptor le tecniche di
1518 \textit{I/O multiplexing} descritte in sez.~\ref{sec:file_multiplexing} non
1519 possono essere utilizzate, e non si ha a disposizione niente di analogo alle
1520 funzioni \func{select} e \func{poll}. Questo rende molto scomodo usare più di
1521 una di queste strutture alla volta; ad esempio non si può scrivere un server
1522 che aspetti un messaggio su più di una coda senza fare ricorso ad una tecnica
1523 di \itindex{polling} \textit{polling} che esegua un ciclo di attesa su
1526 Come esempio dell'uso delle code di messaggi possiamo riscrivere il nostro
1527 server di \textit{fortunes} usando queste al posto delle fifo. In questo caso
1528 useremo una sola coda di messaggi, usando il tipo di messaggio per comunicare
1529 in maniera indipendente con client diversi.
1531 \begin{figure}[!bht]
1532 \footnotesize \centering
1533 \begin{minipage}[c]{15.6cm}
1534 \includecodesample{listati/MQFortuneServer.c}
1537 \caption{Sezione principale del codice del server di \textit{fortunes}
1538 basato sulle \textit{message queue}.}
1539 \label{fig:ipc_mq_fortune_server}
1542 In fig.~\ref{fig:ipc_mq_fortune_server} si è riportato un estratto delle parti
1543 principali del codice del nuovo server (il codice completo è nel file
1544 \file{MQFortuneServer.c} nei sorgenti allegati). Il programma è basato su un
1545 uso accorto della caratteristica di poter associate un ``tipo'' ai messaggi
1546 per permettere una comunicazione indipendente fra il server ed i vari client,
1547 usando il \acr{pid} di questi ultimi come identificativo. Questo è possibile
1548 in quanto, al contrario di una fifo, la lettura di una coda di messaggi può
1549 non essere sequenziale, proprio grazie alla classificazione dei messaggi sulla
1552 Il programma, oltre alle solite variabili per il nome del file da cui leggere
1553 le \textit{fortunes} e per il vettore di stringhe che contiene le frasi,
1554 definisce due strutture appositamente per la comunicazione; con
1555 \var{msgbuf\_read} (\texttt{\small 8--11}) vengono passate le richieste mentre
1556 con \var{msgbuf\_write} (\texttt{\small 12--15}) vengono restituite le frasi.
1558 La gestione delle opzioni si è al solito omessa, essa si curerà di impostare
1559 in \var{n} il numero di frasi da leggere specificato a linea di comando ed in
1560 \var{fortunefilename} il file da cui leggerle; dopo aver installato
1561 (\texttt{\small 19--21}) i gestori dei segnali per trattare l'uscita dal
1562 server, viene prima controllato (\texttt{\small 22}) il numero di frasi
1563 richieste abbia senso (cioè sia maggiore di zero), le quali poi
1564 (\texttt{\small 23}) vengono lette nel vettore in memoria con la stessa
1565 funzione \code{FortuneParse} usata anche per il server basato sulle fifo.
1567 Una volta inizializzato il vettore di stringhe coi messaggi presi dal file
1568 delle \textit{fortune} si procede (\texttt{\small 25}) con la generazione di
1569 una chiave per identificare la coda di messaggi (si usa il nome del file dei
1570 sorgenti del server) con la quale poi si esegue (\texttt{\small 26}) la
1571 creazione della stessa (si noti come si sia chiamata \func{msgget} con un
1572 valore opportuno per l'argomento \param{flag}), avendo cura di abortire il
1573 programma (\texttt{\small 27--29}) in caso di errore.
1575 Finita la fase di inizializzazione il server prima (\texttt{\small 32}) chiama
1576 la funzione \func{daemon} per andare in background e poi esegue in permanenza
1577 il ciclo principale (\texttt{\small 33--40}). Questo inizia (\texttt{\small
1578 34}) con il porsi in attesa di un messaggio di richiesta da parte di un
1579 client; si noti infatti come \func{msgrcv} richieda un messaggio con
1580 \var{mtype} uguale a 1: questo è il valore usato per le richieste dato che
1581 corrisponde al \acr{pid} di \cmd{init}, che non può essere un client. L'uso
1582 del flag \const{MSG\_NOERROR} è solo per sicurezza, dato che i messaggi di
1583 richiesta sono di dimensione fissa (e contengono solo il \acr{pid} del
1586 Se non sono presenti messaggi di richiesta \func{msgrcv} si bloccherà,
1587 ritornando soltanto in corrispondenza dell'arrivo sulla coda di un messaggio
1588 di richiesta da parte di un client, in tal caso il ciclo prosegue
1589 (\texttt{\small 35}) selezionando una frase a caso, copiandola (\texttt{\small
1590 36}) nella struttura \var{msgbuf\_write} usata per la risposta e
1591 calcolandone (\texttt{\small 37}) la dimensione.
1593 Per poter permettere a ciascun client di ricevere solo la risposta indirizzata
1594 a lui il tipo del messaggio in uscita viene inizializzato (\texttt{\small 38})
1595 al valore del \acr{pid} del client ricevuto nel messaggio di richiesta.
1596 L'ultimo passo del ciclo (\texttt{\small 39}) è inviare sulla coda il
1597 messaggio di risposta. Si tenga conto che se la coda è piena anche questa
1598 funzione potrà bloccarsi fintanto che non venga liberato dello spazio.
1600 Si noti che il programma può terminare solo grazie ad una interruzione da
1601 parte di un segnale; in tal caso verrà eseguito (\texttt{\small 45--48}) il
1602 gestore \code{HandSIGTERM}, che semplicemente si limita a cancellare la coda
1603 (\texttt{\small 46}) ed ad uscire (\texttt{\small 47}).
1605 \begin{figure}[!bht]
1606 \footnotesize \centering
1607 \begin{minipage}[c]{15.6cm}
1608 \includecodesample{listati/MQFortuneClient.c}
1611 \caption{Sezione principale del codice del client di \textit{fortunes}
1612 basato sulle \textit{message queue}.}
1613 \label{fig:ipc_mq_fortune_client}
1616 In fig.~\ref{fig:ipc_mq_fortune_client} si è riportato un estratto il codice
1617 del programma client. Al solito il codice completo è con i sorgenti allegati,
1618 nel file \file{MQFortuneClient.c}. Come sempre si sono rimosse le parti
1619 relative alla gestione delle opzioni, ed in questo caso, anche la
1620 dichiarazione delle variabili, che, per la parte relative alle strutture usate
1621 per la comunicazione tramite le code, sono le stesse viste in
1622 fig.~\ref{fig:ipc_mq_fortune_server}.
1624 Il client in questo caso è molto semplice; la prima parte del programma
1625 (\texttt{\small 4--9}) si occupa di accedere alla coda di messaggi, ed è
1626 identica a quanto visto per il server, solo che in questo caso \func{msgget}
1627 non viene chiamata con il flag di creazione in quanto la coda deve essere
1628 preesistente. In caso di errore (ad esempio se il server non è stato avviato)
1629 il programma termina immediatamente.
1631 Una volta acquisito l'identificatore della coda il client compone il
1632 messaggio di richiesta (\texttt{\small 12--13}) in \var{msg\_read}, usando 1
1633 per il tipo ed inserendo il proprio \acr{pid} come dato da passare al server.
1634 Calcolata (\texttt{\small 14}) la dimensione, provvede (\texttt{\small 15}) ad
1635 immettere la richiesta sulla coda.
1637 A questo punto non resta che (\texttt{\small 16}) rileggere dalla coda la
1638 risposta del server richiedendo a \func{msgrcv} di selezionare i messaggi di
1639 tipo corrispondente al valore del \acr{pid} inviato nella richiesta. L'ultimo
1640 passo (\texttt{\small 17}) prima di uscire è quello di stampare a video il
1643 Proviamo allora il nostro nuovo sistema, al solito occorre definire
1644 \code{LD\_LIBRARY\_PATH} per accedere alla libreria \file{libgapil.so}, dopo di
1645 che, in maniera del tutto analoga a quanto fatto con il programma che usa le
1646 fifo, potremo far partire il server con:
1648 [piccardi@gont sources]$ ./mqfortuned -n10
1650 come nel caso precedente, avendo eseguito il server in background, il comando
1651 ritornerà immediatamente; potremo però verificare con \cmd{ps} che il
1652 programma è effettivamente in esecuzione, e che ha creato una coda di
1655 [piccardi@gont sources]$ ipcs
1657 ------ Shared Memory Segments --------
1658 key shmid owner perms bytes nattch status
1660 ------ Semaphore Arrays --------
1661 key semid owner perms nsems
1663 ------ Message Queues --------
1664 key msqid owner perms used-bytes messages
1665 0x0102dc6a 0 piccardi 666 0 0
1667 a questo punto potremo usare il client per ottenere le nostre frasi:
1669 [piccardi@gont sources]$ ./mqfortune
1670 Linux ext2fs has been stable for a long time, now it's time to break it
1671 -- Linuxkongreß '95 in Berlin
1672 [piccardi@gont sources]$ ./mqfortune
1673 Let's call it an accidental feature.
1676 con un risultato del tutto equivalente al precedente. Infine potremo chiudere
1677 il server inviando il segnale di terminazione con il comando \code{killall
1678 mqfortuned} verificando che effettivamente la coda di messaggi viene rimossa.
1680 Benché funzionante questa architettura risente dello stesso inconveniente
1681 visto anche nel caso del precedente server basato sulle fifo; se il client
1682 viene interrotto dopo l'invio del messaggio di richiesta e prima della lettura
1683 della risposta, quest'ultima resta nella coda (così come per le fifo si aveva
1684 il problema delle fifo che restavano nel filesystem). In questo caso però il
1685 problemi sono maggiori, sia perché è molto più facile esaurire la memoria
1686 dedicata ad una coda di messaggi che gli \index{inode} inode di un filesystem,
1687 sia perché, con il riutilizzo dei \acr{pid} da parte dei processi, un client
1688 eseguito in un momento successivo potrebbe ricevere un messaggio non
1693 \subsection{Semafori}
1694 \label{sec:ipc_sysv_sem}
1696 I semafori non sono meccanismi di intercomunicazione diretta come quelli
1697 (pipe, fifo e code di messaggi) visti finora, e non consentono di scambiare
1698 dati fra processi, ma servono piuttosto come meccanismi di sincronizzazione o
1699 di protezione per le \index{sezione~critica} \textsl{sezioni critiche} del
1700 codice (si ricordi quanto detto in sez.~\ref{sec:proc_race_cond}).
1702 Un semaforo è uno speciale contatore, mantenuto nel kernel, che permette, a
1703 seconda del suo valore, di consentire o meno la prosecuzione dell'esecuzione
1704 di un programma. In questo modo l'accesso ad una risorsa condivisa da più
1705 processi può essere controllato, associando ad essa un semaforo che consente
1706 di assicurare che non più di un processo alla volta possa usarla.
1708 Il concetto di semaforo è uno dei concetti base nella programmazione ed è
1709 assolutamente generico, così come del tutto generali sono modalità con cui lo
1710 si utilizza. Un processo che deve accedere ad una risorsa eseguirà un
1711 controllo del semaforo: se questo è positivo il suo valore sarà decrementato,
1712 indicando che si è consumato una unità della risorsa, ed il processo potrà
1713 proseguire nell'utilizzo di quest'ultima, provvedendo a rilasciarla, una volta
1714 completate le operazioni volute, reincrementando il semaforo.
1716 Se al momento del controllo il valore del semaforo è nullo, siamo invece in
1717 una situazione in cui la risorsa non è disponibile, ed il processo si
1718 bloccherà in stato di \textit{sleep} fin quando chi la sta utilizzando non la
1719 rilascerà, incrementando il valore del semaforo. Non appena il semaforo torna
1720 positivo, indicando che la risorsa è disponibile, il processo sarà svegliato,
1721 e si potrà operare come nel caso precedente (decremento del semaforo, accesso
1722 alla risorsa, incremento del semaforo).
1724 Per poter implementare questo tipo di logica le operazioni di controllo e
1725 decremento del contatore associato al semaforo devono essere atomiche,
1726 pertanto una realizzazione di un oggetto di questo tipo è necessariamente
1727 demandata al kernel. La forma più semplice di semaforo è quella del
1728 \textsl{semaforo binario}, o \textit{mutex}, in cui un valore diverso da zero
1729 (normalmente 1) indica la libertà di accesso, e un valore nullo l'occupazione
1730 della risorsa. In generale però si possono usare semafori con valori interi,
1731 utilizzando il valore del contatore come indicatore del ``numero di risorse''
1734 Il sistema di comunicazione inter-processo di \textit{SysV IPC} prevede anche i
1735 semafori, ma gli oggetti utilizzati non sono semafori singoli, ma gruppi di
1736 semafori detti \textsl{insiemi} (o \textit{semaphore set}); la funzione che
1737 permette di creare o ottenere l'identificatore di un insieme di semafori è
1738 \funcd{semget}, ed il suo prototipo è:
1740 \headdecl{sys/types.h}
1741 \headdecl{sys/ipc.h}
1742 \headdecl{sys/sem.h}
1744 \funcdecl{int semget(key\_t key, int nsems, int flag)}
1746 Restituisce l'identificatore di un insieme di semafori.
1748 \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
1749 in caso di errore, nel qual caso \var{errno} assumerà i valori:
1751 \item[\errcode{ENOSPC}] si è cercato di creare una insieme di semafori
1752 quando è stato superato o il limite per il numero totale di semafori
1753 (\const{SEMMNS}) o quello per il numero totale degli insiemi
1754 (\const{SEMMNI}) nel sistema.
1755 \item[\errcode{EINVAL}] l'argomento \param{nsems} è minore di zero o
1756 maggiore del limite sul numero di semafori per ciascun insieme
1757 (\const{SEMMSL}), o se l'insieme già esiste, maggiore del numero di
1758 semafori che contiene.
1759 \item[\errcode{ENOMEM}] il sistema non ha abbastanza memoria per poter
1760 contenere le strutture per un nuovo insieme di semafori.
1762 ed inoltre \errval{EACCES}, \errval{ENOENT}, \errval{EEXIST},
1763 \errval{EIDRM}, con lo stesso significato che hanno per \func{msgget}.}
1766 La funzione è del tutto analoga a \func{msgget}, solo che in questo caso
1767 restituisce l'identificatore di un insieme di semafori, in particolare è
1768 identico l'uso degli argomenti \param{key} e \param{flag}, per cui non
1769 ripeteremo quanto detto al proposito in sez.~\ref{sec:ipc_sysv_mq}. L'argomento
1770 \param{nsems} permette di specificare quanti semafori deve contenere l'insieme
1771 quando se ne richieda la creazione, e deve essere nullo quando si effettua una
1772 richiesta dell'identificatore di un insieme già esistente.
1774 Purtroppo questa implementazione complica inutilmente lo schema elementare che
1775 abbiamo descritto, dato che non è possibile definire un singolo semaforo, ma
1776 se ne deve creare per forza un insieme. Ma questa in definitiva è solo una
1777 complicazione inutile, il problema è che i semafori del \textit{SysV IPC}
1778 soffrono di altri due, ben più gravi, difetti.
1780 Il primo difetto è che non esiste una funzione che permetta di creare ed
1781 inizializzare un semaforo in un'unica chiamata; occorre prima creare l'insieme
1782 dei semafori con \func{semget} e poi inizializzarlo con \func{semctl}, si
1783 perde così ogni possibilità di eseguire l'operazione atomicamente.
1785 Il secondo difetto deriva dalla caratteristica generale degli oggetti del
1786 \textit{SysV IPC} di essere risorse globali di sistema, che non vengono
1787 cancellate quando nessuno le usa più; ci si così a trova a dover affrontare
1788 esplicitamente il caso in cui un processo termina per un qualche errore,
1789 lasciando un semaforo occupato, che resterà tale fino al successivo riavvio
1790 del sistema. Come vedremo esistono delle modalità per evitare tutto ciò, ma
1791 diventa necessario indicare esplicitamente che si vuole il ripristino del
1792 semaforo all'uscita del processo.
1794 \begin{figure}[!htb]
1795 \footnotesize \centering
1796 \begin{minipage}[c]{15cm}
1797 \includestruct{listati/semid_ds.h}
1800 \caption{La struttura \structd{semid\_ds}, associata a ciascun insieme di
1802 \label{fig:ipc_semid_ds}
1805 A ciascun insieme di semafori è associata una struttura \struct{semid\_ds},
1806 riportata in fig.~\ref{fig:ipc_semid_ds}.\footnote{non si sono riportati i
1807 campi ad uso interno del kernel, che vedremo in
1808 fig.~\ref{fig:ipc_sem_schema}, che dipendono dall'implementazione.} Come nel
1809 caso delle code di messaggi quando si crea un nuovo insieme di semafori con
1810 \func{semget} questa struttura viene inizializzata, in particolare il campo
1811 \var{sem\_perm} viene inizializzato come illustrato in
1812 sez.~\ref{sec:ipc_sysv_access_control} (si ricordi che in questo caso il
1813 permesso di scrittura è in realtà permesso di alterare il semaforo), per
1814 quanto riguarda gli altri campi invece:
1816 \item il campo \var{sem\_nsems}, che esprime il numero di semafori
1817 nell'insieme, viene inizializzato al valore di \param{nsems}.
1818 \item il campo \var{sem\_ctime}, che esprime il tempo di creazione
1819 dell'insieme, viene inizializzato al tempo corrente.
1820 \item il campo \var{sem\_otime}, che esprime il tempo dell'ultima operazione
1821 effettuata, viene inizializzato a zero.
1824 Ciascun semaforo dell'insieme è realizzato come una struttura di tipo
1825 \struct{sem} che ne contiene i dati essenziali, la sua definizione\footnote{si
1826 è riportata la definizione originaria del kernel 1.0, che contiene la prima
1827 realizzazione del \textit{SysV IPC} in Linux. In realtà questa struttura
1828 ormai è ridotta ai soli due primi membri, e gli altri vengono calcolati
1829 dinamicamente. La si è utilizzata a scopo di esempio, perché indica tutti i
1830 valori associati ad un semaforo, restituiti dalle funzioni di controllo, e
1831 citati dalle pagine di manuale.} è riportata in fig.~\ref{fig:ipc_sem}.
1832 Questa struttura, non è accessibile in user space, ma i valori in essa
1833 specificati possono essere letti in maniera indiretta, attraverso l'uso delle
1834 funzioni di controllo.
1836 \begin{figure}[!htb]
1837 \footnotesize \centering
1838 \begin{minipage}[c]{15cm}
1839 \includestruct{listati/sem.h}
1842 \caption{La struttura \structd{sem}, che contiene i dati di un singolo
1847 I dati mantenuti nella struttura, ed elencati in fig.~\ref{fig:ipc_sem},
1848 indicano rispettivamente:
1849 \begin{description*}
1850 \item[\var{semval}] il valore numerico del semaforo.
1851 \item[\var{sempid}] il \acr{pid} dell'ultimo processo che ha eseguito una
1852 operazione sul semaforo.
1853 \item[\var{semncnt}] il numero di processi in attesa che esso venga
1855 \item[\var{semzcnt}] il numero di processi in attesa che esso si annulli.
1861 \begin{tabular}[c]{|c|r|p{8cm}|}
1863 \textbf{Costante} & \textbf{Valore} & \textbf{Significato} \\
1866 \const{SEMMNI}& 128 & Numero massimo di insiemi di semafori.\\
1867 \const{SEMMSL}& 250 & Numero massimo di semafori per insieme.\\
1868 \const{SEMMNS}&\const{SEMMNI}*\const{SEMMSL}& Numero massimo di semafori
1870 \const{SEMVMX}& 32767 & Massimo valore per un semaforo.\\
1871 \const{SEMOPM}& 32 & Massimo numero di operazioni per chiamata a
1873 \const{SEMMNU}&\const{SEMMNS}& Massimo numero di strutture di ripristino.\\
1874 \const{SEMUME}&\const{SEMOPM}& Massimo numero di voci di ripristino.\\
1875 \const{SEMAEM}&\const{SEMVMX}& Valore massimo per l'aggiustamento
1879 \caption{Valori delle costanti associate ai limiti degli insiemi di
1880 semafori, definite in \file{linux/sem.h}.}
1881 \label{tab:ipc_sem_limits}
1884 Come per le code di messaggi anche per gli insiemi di semafori esistono una
1885 serie di limiti, i cui valori sono associati ad altrettante costanti, che si
1886 sono riportate in tab.~\ref{tab:ipc_sem_limits}. Alcuni di questi limiti sono
1887 al solito accessibili e modificabili attraverso \func{sysctl} o scrivendo
1888 direttamente nel file \procfile{/proc/sys/kernel/sem}.
1890 La funzione che permette di effettuare le varie operazioni di controllo sui
1891 semafori (fra le quali, come accennato, è impropriamente compresa anche la
1892 loro inizializzazione) è \funcd{semctl}; il suo prototipo è:
1894 \headdecl{sys/types.h}
1895 \headdecl{sys/ipc.h}
1896 \headdecl{sys/sem.h}
1898 \funcdecl{int semctl(int semid, int semnum, int cmd)}
1899 \funcdecl{int semctl(int semid, int semnum, int cmd, union semun arg)}
1901 Esegue le operazioni di controllo su un semaforo o un insieme di semafori.
1903 \bodydesc{La funzione restituisce in caso di successo un valore positivo
1904 quanto usata con tre argomenti ed un valore nullo quando usata con
1905 quattro. In caso di errore restituisce -1, ed \var{errno} assumerà uno dei
1908 \item[\errcode{EACCES}] il processo non ha i privilegi per eseguire
1909 l'operazione richiesta.
1910 \item[\errcode{EIDRM}] l'insieme di semafori è stato cancellato.
1911 \item[\errcode{EPERM}] si è richiesto \const{IPC\_SET} o \const{IPC\_RMID}
1912 ma il processo non ha privilegi sufficienti ad eseguire l'operazione.
1913 \item[\errcode{ERANGE}] si è richiesto \const{SETALL} \const{SETVAL} ma il
1914 valore a cui si vuole impostare il semaforo è minore di zero o maggiore
1917 ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
1921 La funzione può avere tre o quattro argomenti, a seconda dell'operazione
1922 specificata con \param{cmd}, ed opera o sull'intero insieme specificato da
1923 \param{semid} o sul singolo semaforo di un insieme, specificato da
1926 \begin{figure}[!htb]
1927 \footnotesize \centering
1928 \begin{minipage}[c]{15cm}
1929 \includestruct{listati/semun.h}
1932 \caption{La definizione dei possibili valori di una \direct{union}
1933 \structd{semun}, usata come quarto argomento della funzione
1935 \label{fig:ipc_semun}
1938 Qualora la funzione operi con quattro argomenti \param{arg} è un argomento
1939 generico, che conterrà un dato diverso a seconda dell'azione richiesta; per
1940 unificare l'argomento esso deve essere passato come una \struct{semun}, la cui
1941 definizione, con i possibili valori che può assumere, è riportata in
1942 fig.~\ref{fig:ipc_semun}.
1944 Come già accennato sia il comportamento della funzione che il numero di
1945 argomenti con cui deve essere invocata dipendono dal valore dell'argomento
1946 \param{cmd}, che specifica l'azione da intraprendere; i valori validi (che
1947 cioè non causano un errore di \errcode{EINVAL}) per questo argomento sono i
1949 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
1950 \item[\const{IPC\_STAT}] Legge i dati dell'insieme di semafori, copiando il
1951 contenuto della relativa struttura \struct{semid\_ds} all'indirizzo
1952 specificato con \var{arg.buf}. Occorre avere il permesso di lettura.
1953 L'argomento \param{semnum} viene ignorato.
1954 \item[\const{IPC\_RMID}] Rimuove l'insieme di semafori e le relative strutture
1955 dati, con effetto immediato. Tutti i processi che erano stato di
1956 \textit{sleep} vengono svegliati, ritornando con un errore di
1957 \errcode{EIDRM}. L'user-ID effettivo del processo deve corrispondere o al
1958 creatore o al proprietario dell'insieme, o all'amministratore. L'argomento
1959 \param{semnum} viene ignorato.
1960 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
1961 dell'insieme. I valori devono essere passati in una struttura
1962 \struct{semid\_ds} puntata da \param{arg.buf} di cui saranno usati soltanto i
1963 campi \var{sem\_perm.uid}, \var{sem\_perm.gid} e i nove bit meno
1964 significativi di \var{sem\_perm.mode}. L'user-ID effettivo del processo deve
1965 corrispondere o al creatore o al proprietario dell'insieme, o
1966 all'amministratore. L'argomento \param{semnum} viene ignorato.
1967 \item[\const{GETALL}] Restituisce il valore corrente di ciascun semaforo
1968 dell'insieme (corrispondente al campo \var{semval} di \struct{sem}) nel
1969 vettore indicato da \param{arg.array}. Occorre avere il permesso di lettura.
1970 L'argomento \param{semnum} viene ignorato.
1971 \item[\const{GETNCNT}] Restituisce come valore di ritorno della funzione il
1972 numero di processi in attesa che il semaforo \param{semnum} dell'insieme
1973 \param{semid} venga incrementato (corrispondente al campo \var{semncnt} di
1974 \struct{sem}); va invocata con tre argomenti. Occorre avere il permesso di
1976 \item[\const{GETPID}] Restituisce come valore di ritorno della funzione il
1977 \acr{pid} dell'ultimo processo che ha compiuto una operazione sul semaforo
1978 \param{semnum} dell'insieme \param{semid} (corrispondente al campo
1979 \var{sempid} di \struct{sem}); va invocata con tre argomenti. Occorre avere
1980 il permesso di lettura.
1981 \item[\const{GETVAL}] Restituisce come valore di ritorno della funzione il il
1982 valore corrente del semaforo \param{semnum} dell'insieme \param{semid}
1983 (corrispondente al campo \var{semval} di \struct{sem}); va invocata con tre
1984 argomenti. Occorre avere il permesso di lettura.
1985 \item[\const{GETZCNT}] Restituisce come valore di ritorno della funzione il
1986 numero di processi in attesa che il valore del semaforo \param{semnum}
1987 dell'insieme \param{semid} diventi nullo (corrispondente al campo
1988 \var{semncnt} di \struct{sem}); va invocata con tre argomenti. Occorre avere
1989 il permesso di lettura.
1990 \item[\const{SETALL}] Inizializza il valore di tutti i semafori dell'insieme,
1991 aggiornando il campo \var{sem\_ctime} di \struct{semid\_ds}. I valori devono
1992 essere passati nel vettore indicato da \param{arg.array}. Si devono avere i
1993 privilegi di scrittura sul semaforo. L'argomento \param{semnum} viene
1995 \item[\const{SETVAL}] Inizializza il semaforo \param{semnum} al valore passato
1996 dall'argomento \param{arg.val}, aggiornando il campo \var{sem\_ctime} di
1997 \struct{semid\_ds}. Si devono avere i privilegi di scrittura sul semaforo.
2000 Quando si imposta il valore di un semaforo (sia che lo si faccia per tutto
2001 l'insieme con \const{SETALL}, che per un solo semaforo con \const{SETVAL}), i
2002 processi in attesa su di esso reagiscono di conseguenza al cambiamento di
2003 valore. Inoltre la coda delle operazioni di ripristino viene cancellata per
2004 tutti i semafori il cui valore viene modificato.
2009 \begin{tabular}[c]{|c|l|}
2011 \textbf{Operazione} & \textbf{Valore restituito} \\
2014 \const{GETNCNT}& Valore di \var{semncnt}.\\
2015 \const{GETPID} & Valore di \var{sempid}.\\
2016 \const{GETVAL} & Valore di \var{semval}.\\
2017 \const{GETZCNT}& Valore di \var{semzcnt}.\\
2020 \caption{Valori di ritorno della funzione \func{semctl}.}
2021 \label{tab:ipc_semctl_returns}
2024 Il valore di ritorno della funzione in caso di successo dipende
2025 dall'operazione richiesta; per tutte le operazioni che richiedono quattro
2026 argomenti esso è sempre nullo, per le altre operazioni, elencate in
2027 tab.~\ref{tab:ipc_semctl_returns} viene invece restituito il valore richiesto,
2028 corrispondente al campo della struttura \struct{sem} indicato nella seconda
2029 colonna della tabella.
2031 Le operazioni ordinarie sui semafori, come l'acquisizione o il rilascio degli
2032 stessi (in sostanza tutte quelle non comprese nell'uso di \func{semctl})
2033 vengono effettuate con la funzione \funcd{semop}, il cui prototipo è:
2035 \headdecl{sys/types.h}
2036 \headdecl{sys/ipc.h}
2037 \headdecl{sys/sem.h}
2039 \funcdecl{int semop(int semid, struct sembuf *sops, unsigned nsops)}
2041 Esegue le operazioni ordinarie su un semaforo o un insieme di semafori.
2043 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
2044 errore, nel qual caso \var{errno} assumerà uno dei valori:
2046 \item[\errcode{EACCES}] il processo non ha i privilegi per eseguire
2047 l'operazione richiesta.
2048 \item[\errcode{EIDRM}] l'insieme di semafori è stato cancellato.
2049 \item[\errcode{ENOMEM}] si è richiesto un \const{SEM\_UNDO} ma il sistema
2050 non ha le risorse per allocare la struttura di ripristino.
2051 \item[\errcode{EAGAIN}] un'operazione comporterebbe il blocco del processo,
2052 ma si è specificato \const{IPC\_NOWAIT} in \var{sem\_flg}.
2053 \item[\errcode{EINTR}] la funzione, bloccata in attesa dell'esecuzione
2054 dell'operazione, viene interrotta da un segnale.
2055 \item[\errcode{E2BIG}] l'argomento \param{nsops} è maggiore del numero
2056 massimo di operazioni \const{SEMOPM}.
2057 \item[\errcode{ERANGE}] per alcune operazioni il valore risultante del
2058 semaforo viene a superare il limite massimo \const{SEMVMX}.
2060 ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
2064 La funzione permette di eseguire operazioni multiple sui singoli semafori di
2065 un insieme. La funzione richiede come primo argomento l'identificatore
2066 \param{semid} dell'insieme su cui si vuole operare. Il numero di operazioni da
2067 effettuare viene specificato con l'argomento \param{nsop}, mentre il loro
2068 contenuto viene passato con un puntatore ad un vettore di strutture
2069 \struct{sembuf} nell'argomento \param{sops}. Le operazioni richieste vengono
2070 effettivamente eseguite se e soltanto se è possibile effettuarle tutte quante.
2072 \begin{figure}[!htb]
2073 \footnotesize \centering
2074 \begin{minipage}[c]{15cm}
2075 \includestruct{listati/sembuf.h}
2078 \caption{La struttura \structd{sembuf}, usata per le operazioni sui
2080 \label{fig:ipc_sembuf}
2083 Il contenuto di ciascuna operazione deve essere specificato attraverso una
2084 opportuna struttura \struct{sembuf} (la cui definizione è riportata in
2085 fig.~\ref{fig:ipc_sembuf}) che il programma chiamante deve avere cura di
2086 allocare in un opportuno vettore. La struttura permette di indicare il
2087 semaforo su cui operare, il tipo di operazione, ed un flag di controllo.
2088 Il campo \var{sem\_num} serve per indicare a quale semaforo dell'insieme fa
2089 riferimento l'operazione; si ricordi che i semafori sono numerati come in un
2090 vettore, per cui il primo semaforo corrisponde ad un valore nullo di
2093 Il campo \var{sem\_flg} è un flag, mantenuto come maschera binaria, per il
2094 quale possono essere impostati i due valori \const{IPC\_NOWAIT} e
2095 \const{SEM\_UNDO}. Impostando \const{IPC\_NOWAIT} si fa si che, invece di
2096 bloccarsi (in tutti quei casi in cui l'esecuzione di una operazione richiede
2097 che il processo vada in stato di \textit{sleep}), \func{semop} ritorni
2098 immediatamente con un errore di \errcode{EAGAIN}. Impostando \const{SEM\_UNDO}
2099 si richiede invece che l'operazione venga registrata in modo che il valore del
2100 semaforo possa essere ripristinato all'uscita del processo.
2102 Infine \var{sem\_op} è il campo che controlla l'operazione che viene eseguita
2103 e determina il comportamento della chiamata a \func{semop}; tre sono i casi
2105 \begin{basedescript}{\desclabelwidth{2.0cm}}
2106 \item[\var{sem\_op}$>0$] In questo caso il valore di \var{sem\_op} viene
2107 aggiunto al valore corrente di \var{semval}. La funzione ritorna
2108 immediatamente (con un errore di \errcode{ERANGE} qualora si sia superato il
2109 limite \const{SEMVMX}) ed il processo non viene bloccato in nessun caso.
2110 Specificando \const{SEM\_UNDO} si aggiorna il contatore per il ripristino
2111 del valore del semaforo. Al processo chiamante è richiesto il privilegio di
2112 alterazione (scrittura) sull'insieme di semafori.
2114 \item[\var{sem\_op}$=0$] Nel caso \var{semval} sia zero l'esecuzione procede
2115 immediatamente. Se \var{semval} è diverso da zero il comportamento è
2116 controllato da \var{sem\_flg}, se è stato impostato \const{IPC\_NOWAIT} la
2117 funzione ritorna con un errore di \errcode{EAGAIN}, altrimenti viene
2118 incrementato \var{semzcnt} di uno ed il processo resta in stato di
2119 \textit{sleep} fintanto che non si ha una delle condizioni seguenti:
2121 \item \var{semval} diventa zero, nel qual caso \var{semzcnt} viene
2122 decrementato di uno.
2123 \item l'insieme di semafori viene rimosso, nel qual caso \func{semop} ritorna
2124 un errore di \errcode{EIDRM}.
2125 \item il processo chiamante riceve un segnale, nel qual caso \var{semzcnt}
2126 viene decrementato di uno e \func{semop} ritorna un errore di
2129 Al processo chiamante è richiesto il privilegio di lettura dell'insieme dei
2132 \item[\var{sem\_op}$<0$] Nel caso in cui \var{semval} è maggiore o uguale del
2133 valore assoluto di \var{sem\_op} (se cioè la somma dei due valori resta
2134 positiva o nulla) i valori vengono sommati e la funzione ritorna
2135 immediatamente; qualora si sia impostato \const{SEM\_UNDO} viene anche
2136 aggiornato il contatore per il ripristino del valore del semaforo. In caso
2137 contrario (quando cioè la somma darebbe luogo ad un valore di \var{semval}
2138 negativo) se si è impostato \const{IPC\_NOWAIT} la funzione ritorna con un
2139 errore di \errcode{EAGAIN}, altrimenti viene incrementato di uno
2140 \var{semncnt} ed il processo resta in stato di \textit{sleep} fintanto che
2141 non si ha una delle condizioni seguenti:
2143 \item \var{semval} diventa maggiore o uguale del valore assoluto di
2144 \var{sem\_op}, nel qual caso \var{semncnt} viene decrementato di uno, il
2145 valore di \var{sem\_op} viene sommato a \var{semval}, e se era stato
2146 impostato \const{SEM\_UNDO} viene aggiornato il contatore per il
2147 ripristino del valore del semaforo.
2148 \item l'insieme di semafori viene rimosso, nel qual caso \func{semop}
2149 ritorna un errore di \errcode{EIDRM}.
2150 \item il processo chiamante riceve un segnale, nel qual caso \var{semncnt}
2151 viene decrementato di uno e \func{semop} ritorna un errore di
2154 Al processo chiamante è richiesto il privilegio di alterazione (scrittura)
2155 sull'insieme di semafori.
2158 In caso di successo della funzione viene aggiornato il campo \var{sempid} per
2159 ogni semaforo modificato al valore del \acr{pid} del processo chiamante;
2160 inoltre vengono pure aggiornati al tempo corrente i campi \var{sem\_otime} e
2163 Dato che, come già accennato in precedenza, in caso di uscita inaspettata i
2164 semafori possono restare occupati, abbiamo visto come \func{semop} permetta di
2165 attivare un meccanismo di ripristino attraverso l'uso del flag
2166 \const{SEM\_UNDO}. Il meccanismo è implementato tramite una apposita struttura
2167 \struct{sem\_undo}, associata ad ogni processo per ciascun semaforo che esso
2168 ha modificato; all'uscita i semafori modificati vengono ripristinati, e le
2169 strutture disallocate. Per mantenere coerente il comportamento queste
2170 strutture non vengono ereditate attraverso una \func{fork} (altrimenti si
2171 avrebbe un doppio ripristino), mentre passano inalterate nell'esecuzione di
2172 una \func{exec} (altrimenti non si avrebbe ripristino).
2174 Tutto questo però ha un problema di fondo. Per capire di cosa si tratta
2175 occorre fare riferimento all'implementazione usata in Linux, che è riportata
2176 in maniera semplificata nello schema di fig.~\ref{fig:ipc_sem_schema}. Si è
2177 presa come riferimento l'architettura usata fino al kernel 2.2.x che è più
2178 semplice (ed illustrata in dettaglio in \cite{tlk}); nel kernel 2.4.x la
2179 struttura del \textit{SysV IPC} è stata modificata, ma le definizioni relative
2180 a queste strutture restano per compatibilità.\footnote{in particolare con le
2181 vecchie versioni delle librerie del C, come le libc5.}
2184 \centering \includegraphics[width=13cm]{img/semtruct}
2185 \caption{Schema della struttura di un insieme di semafori.}
2186 \label{fig:ipc_sem_schema}
2189 Alla creazione di un nuovo insieme viene allocata una nuova strutture
2190 \struct{semid\_ds} ed il relativo vettore di strutture \struct{sem}. Quando si
2191 richiede una operazione viene anzitutto verificato che tutte le operazioni
2192 possono avere successo; se una di esse comporta il blocco del processo il
2193 kernel crea una struttura \struct{sem\_queue} che viene aggiunta in fondo alla
2194 coda di attesa associata a ciascun insieme di semafori\footnote{che viene
2195 referenziata tramite i campi \var{sem\_pending} e \var{sem\_pending\_last}
2196 di \struct{semid\_ds}.}.
2198 Nella struttura viene memorizzato il riferimento alle operazioni richieste
2199 (nel campo \var{sops}, che è un puntatore ad una struttura \struct{sembuf}) e
2200 al processo corrente (nel campo \var{sleeper}) poi quest'ultimo viene messo
2201 stato di attesa e viene invocato lo \itindex{scheduler} scheduler per passare
2202 all'esecuzione di un altro processo.
2204 Se invece tutte le operazioni possono avere successo queste vengono eseguite
2205 immediatamente, dopo di che il kernel esegue una scansione della coda di
2206 attesa (a partire da \var{sem\_pending}) per verificare se qualcuna delle
2207 operazioni sospese in precedenza può essere eseguita, nel qual caso la
2208 struttura \struct{sem\_queue} viene rimossa e lo stato del processo associato
2209 all'operazione (\var{sleeper}) viene riportato a \textit{running}; il tutto
2210 viene ripetuto fin quando non ci sono più operazioni eseguibili o si è
2211 svuotata la coda. Per gestire il meccanismo del ripristino tutte le volte che
2212 per un'operazione si è specificato il flag \const{SEM\_UNDO} viene mantenuta
2213 per ciascun insieme di semafori una apposita struttura \struct{sem\_undo} che
2214 contiene (nel vettore puntato dal campo \var{semadj}) un valore di
2215 aggiustamento per ogni semaforo cui viene sommato l'opposto del valore usato
2218 Queste strutture sono mantenute in due liste,\footnote{rispettivamente
2219 attraverso i due campi \var{id\_next} e \var{proc\_next}.} una associata
2220 all'insieme di cui fa parte il semaforo, che viene usata per invalidare le
2221 strutture se questo viene cancellato o per azzerarle se si è eseguita una
2222 operazione con \func{semctl}; l'altra associata al processo che ha eseguito
2223 l'operazione;\footnote{attraverso il campo \var{semundo} di
2224 \struct{task\_struct}, come mostrato in \ref{fig:ipc_sem_schema}.} quando un
2225 processo termina, la lista ad esso associata viene scandita e le operazioni
2226 applicate al semaforo. Siccome un processo può accumulare delle richieste di
2227 ripristino per semafori differenti chiamate attraverso diverse chiamate a
2228 \func{semop}, si pone il problema di come eseguire il ripristino dei semafori
2229 all'uscita del processo, ed in particolare se questo può essere fatto
2232 Il punto è cosa succede quando una delle operazioni previste per il ripristino
2233 non può essere eseguita immediatamente perché ad esempio il semaforo è
2234 occupato; in tal caso infatti, se si pone il processo in stato di
2235 \textit{sleep} aspettando la disponibilità del semaforo (come faceva
2236 l'implementazione originaria) si perde l'atomicità dell'operazione. La scelta
2237 fatta dal kernel è pertanto quella di effettuare subito le operazioni che non
2238 prevedono un blocco del processo e di ignorare silenziosamente le altre;
2239 questo però comporta il fatto che il ripristino non è comunque garantito in
2242 Come esempio di uso dell'interfaccia dei semafori vediamo come implementare
2243 con essa dei semplici \textit{mutex} (cioè semafori binari), tutto il codice
2244 in questione, contenuto nel file \file{Mutex.c} allegato ai sorgenti, è
2245 riportato in fig.~\ref{fig:ipc_mutex_create}. Utilizzeremo l'interfaccia per
2246 creare un insieme contenente un singolo semaforo, per il quale poi useremo un
2247 valore unitario per segnalare la disponibilità della risorsa, ed un valore
2248 nullo per segnalarne l'indisponibilità.
2250 \begin{figure}[!bht]
2251 \footnotesize \centering
2252 \begin{minipage}[c]{15cm}
2253 \includecodesample{listati/Mutex.c}
2256 \caption{Il codice delle funzioni che permettono di creare o recuperare
2257 l'identificatore di un semaforo da utilizzare come \textit{mutex}.}
2258 \label{fig:ipc_mutex_create}
2261 La prima funzione (\texttt{\small 2--15}) è \func{MutexCreate} che data una
2262 chiave crea il semaforo usato per il mutex e lo inizializza, restituendone
2263 l'identificatore. Il primo passo (\texttt{\small 6}) è chiamare \func{semget}
2264 con \const{IPC\_CREATE} per creare il semaforo qualora non esista,
2265 assegnandogli i privilegi di lettura e scrittura per tutti. In caso di errore
2266 (\texttt{\small 7--9}) si ritorna subito il risultato di \func{semget},
2267 altrimenti (\texttt{\small 10}) si inizializza il semaforo chiamando
2268 \func{semctl} con il comando \const{SETVAL}, utilizzando l'unione
2269 \struct{semunion} dichiarata ed avvalorata in precedenza (\texttt{\small 4})
2270 ad 1 per significare che risorsa è libera. In caso di errore (\texttt{\small
2271 11--13}) si restituisce il valore di ritorno di \func{semctl}, altrimenti
2272 (\texttt{\small 14}) si ritorna l'identificatore del semaforo.
2274 La seconda funzione (\texttt{\small 17--20}) è \func{MutexFind}, che, data una
2275 chiave, restituisce l'identificatore del semaforo ad essa associato. La
2276 comprensione del suo funzionamento è immediata in quanto essa è soltanto un
2277 \textit{wrapper}\footnote{si chiama così una funzione usata per fare da
2278 \textsl{involucro} alla chiamata di un altra, usata in genere per
2279 semplificare un'interfaccia (come in questo caso) o per utilizzare con la
2280 stessa funzione diversi substrati (librerie, ecc.) che possono fornire le
2281 stesse funzionalità.} di una chiamata a \func{semget} per cercare
2282 l'identificatore associato alla chiave, il valore di ritorno di quest'ultima
2283 viene passato all'indietro al chiamante.
2285 La terza funzione (\texttt{\small 22--25}) è \func{MutexRead} che, dato un
2286 identificatore, restituisce il valore del semaforo associato al mutex. Anche
2287 in questo caso la funzione è un \textit{wrapper} per una chiamata a
2288 \func{semctl} con il comando \const{GETVAL}, che permette di restituire il
2289 valore del semaforo.
2291 La quarta e la quinta funzione (\texttt{\small 36--44}) sono \func{MutexLock},
2292 e \func{MutexUnlock}, che permettono rispettivamente di bloccare e sbloccare
2293 il mutex. Entrambe fanno da wrapper per \func{semop}, utilizzando le due
2294 strutture \var{sem\_lock} e \var{sem\_unlock} definite in precedenza
2295 (\texttt{\small 27--34}). Si noti come per queste ultime si sia fatto uso
2296 dell'opzione \const{SEM\_UNDO} per evitare che il semaforo resti bloccato in
2297 caso di terminazione imprevista del processo.
2299 L'ultima funzione (\texttt{\small 46--49}) della serie, è \func{MutexRemove},
2300 che rimuove il mutex. Anche in questo caso si ha un wrapper per una chiamata a
2301 \func{semctl} con il comando \const{IPC\_RMID}, che permette di cancellare il
2302 semaforo; il valore di ritorno di quest'ultima viene passato all'indietro.
2304 Chiamare \func{MutexLock} decrementa il valore del semaforo: se questo è
2305 libero (ha già valore 1) sarà bloccato (valore nullo), se è bloccato la
2306 chiamata a \func{semop} si bloccherà fintanto che la risorsa non venga
2307 rilasciata. Chiamando \func{MutexUnlock} il valore del semaforo sarà
2308 incrementato di uno, sbloccandolo qualora fosse bloccato.
2310 Si noti che occorre eseguire sempre prima \func{MutexLock} e poi
2311 \func{MutexUnlock}, perché se per un qualche errore si esegue più volte
2312 quest'ultima il valore del semaforo crescerebbe oltre 1, e \func{MutexLock}
2313 non avrebbe più l'effetto aspettato (bloccare la risorsa quando questa è
2314 considerata libera). Infine si tenga presente che usare \func{MutexRead} per
2315 controllare il valore dei mutex prima di proseguire in una operazione di
2316 sblocco non servirebbe comunque, dato che l'operazione non sarebbe atomica.
2317 Vedremo in sez.~\ref{sec:ipc_lock_file} come sia possibile ottenere
2318 un'interfaccia analoga a quella appena illustrata, senza incorrere in questi
2319 problemi, usando il \index{file!locking} \textit{file locking}.
2322 \subsection{Memoria condivisa}
2323 \label{sec:ipc_sysv_shm}
2325 Il terzo oggetto introdotto dal \textit{SysV IPC} è quello dei segmenti di
2326 memoria condivisa. La funzione che permette di ottenerne uno è \funcd{shmget},
2327 ed il suo prototipo è:
2329 \headdecl{sys/types.h}
2330 \headdecl{sys/ipc.h}
2331 \headdecl{sys/shm.h}
2333 \funcdecl{int shmget(key\_t key, int size, int flag)}
2335 Restituisce l'identificatore di una memoria condivisa.
2337 \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
2338 in caso di errore, nel qual caso \var{errno} assumerà i valori:
2340 \item[\errcode{ENOSPC}] si è superato il limite (\const{SHMMNI}) sul numero
2341 di segmenti di memoria nel sistema, o cercato di allocare un segmento le
2342 cui dimensioni fanno superare il limite di sistema (\const{SHMALL}) per
2343 la memoria ad essi riservata.
2344 \item[\errcode{EINVAL}] si è richiesta una dimensione per un nuovo segmento
2345 maggiore di \const{SHMMAX} o minore di \const{SHMMIN}, o se il segmento
2346 già esiste \param{size} è maggiore delle sue dimensioni.
2347 \item[\errcode{ENOMEM}] il sistema non ha abbastanza memoria per poter
2348 contenere le strutture per un nuovo segmento di memoria condivisa.
2350 ed inoltre \errval{EACCES}, \errval{ENOENT}, \errval{EEXIST},
2351 \errval{EIDRM}, con lo stesso significato che hanno per \func{msgget}.}
2354 La funzione, come \func{semget}, è del tutto analoga a \func{msgget}, ed
2355 identico è l'uso degli argomenti \param{key} e \param{flag} per cui non
2356 ripeteremo quanto detto al proposito in sez.~\ref{sec:ipc_sysv_mq}. L'argomento
2357 \param{size} specifica invece la dimensione, in byte, del segmento, che viene
2358 comunque arrotondata al multiplo superiore di \const{PAGE\_SIZE}.
2360 La memoria condivisa è la forma più veloce di comunicazione fra due processi,
2361 in quanto permette agli stessi di vedere nel loro spazio di indirizzi una
2362 stessa sezione di memoria. Pertanto non è necessaria nessuna operazione di
2363 copia per trasmettere i dati da un processo all'altro, in quanto ciascuno può
2364 accedervi direttamente con le normali operazioni di lettura e scrittura dei
2367 Ovviamente tutto questo ha un prezzo, ed il problema fondamentale della
2368 memoria condivisa è la sincronizzazione degli accessi. È evidente infatti che
2369 se un processo deve scambiare dei dati con un altro, si deve essere sicuri che
2370 quest'ultimo non acceda al segmento di memoria condivisa prima che il primo
2371 non abbia completato le operazioni di scrittura, inoltre nel corso di una
2372 lettura si deve essere sicuri che i dati restano coerenti e non vengono
2373 sovrascritti da un accesso in scrittura sullo stesso segmento da parte di un
2374 altro processo. Per questo in genere la memoria condivisa viene sempre
2375 utilizzata in abbinamento ad un meccanismo di sincronizzazione, il che, di
2376 norma, significa insieme a dei semafori.
2378 \begin{figure}[!htb]
2379 \footnotesize \centering
2380 \begin{minipage}[c]{15cm}
2381 \includestruct{listati/shmid_ds.h}
2384 \caption{La struttura \structd{shmid\_ds}, associata a ciascun segmento di
2386 \label{fig:ipc_shmid_ds}
2389 A ciascun segmento di memoria condivisa è associata una struttura
2390 \struct{shmid\_ds}, riportata in fig.~\ref{fig:ipc_shmid_ds}. Come nel caso
2391 delle code di messaggi quando si crea un nuovo segmento di memoria condivisa
2392 con \func{shmget} questa struttura viene inizializzata, in particolare il
2393 campo \var{shm\_perm} viene inizializzato come illustrato in
2394 sez.~\ref{sec:ipc_sysv_access_control}, e valgono le considerazioni ivi fatte
2395 relativamente ai permessi di accesso; per quanto riguarda gli altri campi
2398 \item il campo \var{shm\_segsz}, che esprime la dimensione del segmento, viene
2399 inizializzato al valore di \param{size}.
2400 \item il campo \var{shm\_ctime}, che esprime il tempo di creazione del
2401 segmento, viene inizializzato al tempo corrente.
2402 \item i campi \var{shm\_atime} e \var{shm\_dtime}, che esprimono
2403 rispettivamente il tempo dell'ultima volta che il segmento è stato
2404 agganciato o sganciato da un processo, vengono inizializzati a zero.
2405 \item il campo \var{shm\_lpid}, che esprime il \acr{pid} del processo che ha
2406 eseguito l'ultima operazione, viene inizializzato a zero.
2407 \item il campo \var{shm\_cpid}, che esprime il \acr{pid} del processo che ha
2408 creato il segmento, viene inizializzato al \acr{pid} del processo chiamante.
2409 \item il campo \var{shm\_nattac}, che esprime il numero di processi agganciati
2410 al segmento viene inizializzato a zero.
2413 Come per le code di messaggi e gli insiemi di semafori, anche per i segmenti
2414 di memoria condivisa esistono una serie di limiti imposti dal sistema. Alcuni
2415 di questi limiti sono al solito accessibili e modificabili attraverso
2416 \func{sysctl} o scrivendo direttamente nei rispettivi file di
2417 \file{/proc/sys/kernel/}.
2419 In tab.~\ref{tab:ipc_shm_limits} si sono riportate le
2420 costanti simboliche associate a ciascuno di essi, il loro significato, i
2421 valori preimpostati, e, quando presente, il file in \file{/proc/sys/kernel/}
2422 che permettono di cambiarne il valore.
2428 \begin{tabular}[c]{|c|r|c|p{7cm}|}
2430 \textbf{Costante} & \textbf{Valore} & \textbf{File in \texttt{proc}}
2431 & \textbf{Significato} \\
2434 \const{SHMALL}& 0x200000&\procrelfile{/proc/sys/kernel}{shmall}
2435 & Numero massimo di pagine che
2436 possono essere usate per i segmenti di
2437 memoria condivisa.\\
2438 \const{SHMMAX}&0x2000000&\procrelfile{/proc/sys/kernel}{shmmax}
2439 & Dimensione massima di un segmento di memoria
2441 \const{SHMMNI}& 4096&\procrelfile{/proc/sys/kernel}{msgmni}
2442 & Numero massimo di segmenti di memoria condivisa
2443 presenti nel kernel.\\
2444 \const{SHMMIN}& 1& --- & Dimensione minima di un segmento di
2445 memoria condivisa.\\
2446 \const{SHMLBA}&\const{PAGE\_SIZE}&--- & Limite inferiore per le dimensioni
2447 minime di un segmento (deve essere
2448 allineato alle dimensioni di una
2449 pagina di memoria).\\
2450 \const{SHMSEG}& --- & --- & Numero massimo di segmenti di
2451 memoria condivisa per ciascun
2457 \caption{Valori delle costanti associate ai limiti dei segmenti di memoria
2458 condivisa, insieme al relativo file in \file{/proc/sys/kernel/} ed al
2459 valore preimpostato presente nel sistema.}
2460 \label{tab:ipc_shm_limits}
2463 Al solito la funzione che permette di effettuare le operazioni di controllo su
2464 un segmento di memoria condivisa è \funcd{shmctl}; il suo prototipo è:
2466 \headdecl{sys/ipc.h}
2467 \headdecl{sys/shm.h}
2469 \funcdecl{int shmctl(int shmid, int cmd, struct shmid\_ds *buf)}
2471 Esegue le operazioni di controllo su un segmento di memoria condivisa.
2473 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
2474 errore, nel qual caso \var{errno} assumerà i valori:
2476 \item[\errcode{EACCES}] si è richiesto \const{IPC\_STAT} ma i permessi non
2477 consentono l'accesso in lettura al segmento.
2478 \item[\errcode{EINVAL}] O \param{shmid} non è un identificatore valido o
2479 \param{cmd} non è un comando valido.
2480 \item[\errcode{EIDRM}] l'argomento \param{shmid} fa riferimento ad un
2481 segmento che è stato cancellato.
2482 \item[\errcode{EPERM}] si è specificato un comando con \const{IPC\_SET} o
2483 \const{IPC\_RMID} senza i permessi necessari.
2484 \item[\errcode{EOVERFLOW}] si è tentato il comando \const{IPC\_STAT} ma il
2485 valore del group-ID o dell'user-ID è troppo grande per essere
2486 memorizzato nella struttura puntata da \param{buf}.
2487 \item[\errcode{EFAULT}] l'indirizzo specificato con \param{buf} non è
2493 Il comando specificato attraverso l'argomento \param{cmd} determina i diversi
2494 effetti della funzione; i possibili valori che esso può assumere, ed il
2495 corrispondente comportamento della funzione, sono i seguenti:
2497 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
2498 \item[\const{IPC\_STAT}] Legge le informazioni riguardo il segmento di memoria
2499 condivisa nella struttura \struct{shmid\_ds} puntata da \param{buf}. Occorre
2500 che il processo chiamante abbia il permesso di lettura sulla segmento.
2501 \item[\const{IPC\_RMID}] Marca il segmento di memoria condivisa per la
2502 rimozione, questo verrà cancellato effettivamente solo quando l'ultimo
2503 processo ad esso agganciato si sarà staccato. Questo comando può essere
2504 eseguito solo da un processo con user-ID effettivo corrispondente o al
2505 creatore del segmento, o al proprietario del segmento, o all'amministratore.
2506 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
2507 del segmento. Per modificare i valori di \var{shm\_perm.mode},
2508 \var{shm\_perm.uid} e \var{shm\_perm.gid} occorre essere il proprietario o
2509 il creatore del segmento, oppure l'amministratore. Compiuta l'operazione
2510 aggiorna anche il valore del campo \var{shm\_ctime}.
2511 \item[\const{SHM\_LOCK}] Abilita il \itindex{memory~locking} \textit{memory
2512 locking}\footnote{impedisce cioè che la memoria usata per il segmento
2513 venga salvata su disco dal meccanismo della \index{memoria~virtuale}
2514 memoria virtuale; si ricordi quanto trattato in
2515 sez.~\ref{sec:proc_mem_lock}.} sul segmento di memoria condivisa. Solo
2516 l'amministratore può utilizzare questo comando.
2517 \item[\const{SHM\_UNLOCK}] Disabilita il \itindex{memory~locking}
2518 \textit{memory locking} sul segmento di memoria condivisa. Solo
2519 l'amministratore può utilizzare questo comando.
2521 i primi tre comandi sono gli stessi già visti anche per le code di messaggi e
2522 gli insiemi di semafori, gli ultimi due sono delle estensioni specifiche
2523 previste da Linux, che permettono di abilitare e disabilitare il meccanismo
2524 della \index{memoria~virtuale} memoria virtuale per il segmento.
2526 L'argomento \param{buf} viene utilizzato solo con i comandi \const{IPC\_STAT}
2527 e \const{IPC\_SET} nel qual caso esso dovrà puntare ad una struttura
2528 \struct{shmid\_ds} precedentemente allocata, in cui nel primo caso saranno
2529 scritti i dati del segmento di memoria restituiti dalla funzione e da cui, nel
2530 secondo caso, verranno letti i dati da impostare sul segmento.
2532 Una volta che lo si è creato, per utilizzare un segmento di memoria condivisa
2533 l'interfaccia prevede due funzioni, \funcd{shmat} e \func{shmdt}. La prima di
2534 queste serve ad agganciare un segmento al processo chiamante, in modo che
2535 quest'ultimo possa inserirlo nel suo spazio di indirizzi per potervi accedere;
2538 \headdecl{sys/types.h}
2539 \headdecl{sys/shm.h}
2541 \funcdecl{void *shmat(int shmid, const void *shmaddr, int shmflg)}
2542 Aggancia al processo un segmento di memoria condivisa.
2544 \bodydesc{La funzione restituisce l'indirizzo del segmento in caso di
2545 successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà i
2548 \item[\errcode{EACCES}] il processo non ha i privilegi per accedere al
2549 segmento nella modalità richiesta.
2550 \item[\errcode{EINVAL}] si è specificato un identificatore invalido per
2551 \param{shmid}, o un indirizzo non allineato sul confine di una pagina
2552 per \param{shmaddr}.
2554 ed inoltre \errval{ENOMEM}.}
2557 La funzione inserisce un segmento di memoria condivisa all'interno dello
2558 spazio di indirizzi del processo, in modo che questo possa accedervi
2559 direttamente, la situazione dopo l'esecuzione di \func{shmat} è illustrata in
2560 fig.~\ref{fig:ipc_shmem_layout} (per la comprensione del resto dello schema si
2561 ricordi quanto illustrato al proposito in sez.~\ref{sec:proc_mem_layout}). In
2562 particolare l'indirizzo finale del segmento dati (quello impostato da
2563 \func{brk}, vedi sez.~\ref{sec:proc_mem_alloc}) non viene influenzato.
2564 Si tenga presente infine che la funzione ha successo anche se il segmento è
2565 stato marcato per la cancellazione.
2569 \includegraphics[height=10cm]{img/sh_memory_layout}
2570 \caption{Disposizione dei segmenti di memoria di un processo quando si è
2571 agganciato un segmento di memoria condivisa.}
2572 \label{fig:ipc_shmem_layout}
2575 L'argomento \param{shmaddr} specifica a quale indirizzo\footnote{Lo standard
2576 SVID prevede che l'argomento \param{shmaddr} sia di tipo \ctyp{char *}, così
2577 come il valore di ritorno della funzione. In Linux è stato così con le
2578 \acr{libc4} e le \acr{libc5}, con il passaggio alle \acr{glibc} il tipo di
2579 \param{shmaddr} è divenuto un \ctyp{const void *} e quello del valore di
2580 ritorno un \ctyp{void *}.} deve essere associato il segmento, se il valore
2581 specificato è \val{NULL} è il sistema a scegliere opportunamente un'area di
2582 memoria libera (questo è il modo più portabile e sicuro di usare la funzione).
2583 Altrimenti il kernel aggancia il segmento all'indirizzo specificato da
2584 \param{shmaddr}; questo però può avvenire solo se l'indirizzo coincide con il
2585 limite di una pagina, cioè se è un multiplo esatto del parametro di sistema
2586 \const{SHMLBA}, che in Linux è sempre uguale \const{PAGE\_SIZE}.
2588 Si tenga presente però che quando si usa \val{NULL} come valore di
2589 \param{shmaddr}, l'indirizzo restituito da \func{shmat} può cambiare da
2590 processo a processo; pertanto se nell'area di memoria condivisa si salvano
2591 anche degli indirizzi, si deve avere cura di usare valori relativi (in genere
2592 riferiti all'indirizzo di partenza del segmento).
2594 L'argomento \param{shmflg} permette di cambiare il comportamento della
2595 funzione; esso va specificato come maschera binaria, i bit utilizzati sono
2596 solo due e sono identificati dalle costanti \const{SHM\_RND} e
2597 \const{SHM\_RDONLY}, che vanno combinate con un OR aritmetico. Specificando
2598 \const{SHM\_RND} si evita che \func{shmat} ritorni un errore quando
2599 \param{shmaddr} non è allineato ai confini di una pagina. Si può quindi usare
2600 un valore qualunque per \param{shmaddr}, e il segmento verrà comunque
2601 agganciato, ma al più vicino multiplo di \const{SHMLBA} (il nome della
2602 costante sta infatti per \textit{rounded}, e serve per specificare un
2603 indirizzo come arrotondamento, in Linux è equivalente a \const{PAGE\_SIZE}).
2605 L'uso di \const{SHM\_RDONLY} permette di agganciare il segmento in sola
2606 lettura (si ricordi che anche le pagine di memoria hanno dei permessi), in tal
2607 caso un tentativo di scrivere sul segmento comporterà una violazione di
2608 accesso con l'emissione di un segnale di \const{SIGSEGV}. Il comportamento
2609 usuale di \func{shmat} è quello di agganciare il segmento con l'accesso in
2610 lettura e scrittura (ed il processo deve aver questi permessi in
2611 \var{shm\_perm}), non è prevista la possibilità di agganciare un segmento in
2614 In caso di successo la funzione aggiorna anche i seguenti campi di
2617 \item il tempo \var{shm\_atime} dell'ultima operazione di aggancio viene
2618 impostato al tempo corrente.
2619 \item il \acr{pid} \var{shm\_lpid} dell'ultimo processo che ha operato sul
2620 segmento viene impostato a quello del processo corrente.
2621 \item il numero \var{shm\_nattch} di processi agganciati al segmento viene
2625 Come accennato in sez.~\ref{sec:proc_fork} un segmento di memoria condivisa
2626 agganciato ad un processo viene ereditato da un figlio attraverso una
2627 \func{fork}, dato che quest'ultimo riceve una copia dello spazio degli
2628 indirizzi del padre. Invece, dato che attraverso una \func{exec} viene
2629 eseguito un diverso programma con uno spazio di indirizzi completamente
2630 diverso, tutti i segmenti agganciati al processo originario vengono
2631 automaticamente sganciati. Lo stesso avviene all'uscita del processo
2632 attraverso una \func{exit}.
2634 Una volta che un segmento di memoria condivisa non serve più, si può
2635 sganciarlo esplicitamente dal processo usando l'altra funzione
2636 dell'interfaccia, \funcd{shmdt}, il cui prototipo è:
2638 \headdecl{sys/types.h}
2639 \headdecl{sys/shm.h}
2641 \funcdecl{int shmdt(const void *shmaddr)}
2642 Sgancia dal processo un segmento di memoria condivisa.
2644 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
2645 errore, la funzione fallisce solo quando non c'è un segmento agganciato
2646 all'indirizzo \param{shmaddr}, con \var{errno} che assume il valore
2650 La funzione sgancia dallo spazio degli indirizzi del processo un segmento di
2651 memoria condivisa; questo viene identificato con l'indirizzo \param{shmaddr}
2652 restituito dalla precedente chiamata a \func{shmat} con il quale era stato
2653 agganciato al processo.
2655 In caso di successo la funzione aggiorna anche i seguenti campi di
2658 \item il tempo \var{shm\_dtime} dell'ultima operazione di sganciamento viene
2659 impostato al tempo corrente.
2660 \item il \acr{pid} \var{shm\_lpid} dell'ultimo processo che ha operato sul
2661 segmento viene impostato a quello del processo corrente.
2662 \item il numero \var{shm\_nattch} di processi agganciati al segmento viene
2663 decrementato di uno.
2665 inoltre la regione di indirizzi usata per il segmento di memoria condivisa
2666 viene tolta dallo spazio di indirizzi del processo.
2668 \begin{figure}[!bht]
2669 \footnotesize \centering
2670 \begin{minipage}[c]{15.6cm}
2671 \includecodesample{listati/SharedMem.c}
2674 \caption{Il codice delle funzioni che permettono di creare, trovare e
2675 rimuovere un segmento di memoria condivisa.}
2676 \label{fig:ipc_sysv_shm_func}
2679 Come esempio di uso di queste funzioni vediamo come implementare una serie di
2680 funzioni di libreria che ne semplifichino l'uso, automatizzando le operazioni
2681 più comuni; il codice, contenuto nel file \file{SharedMem.c}, è riportato in
2682 fig.~\ref{fig:ipc_sysv_shm_func}.
2684 La prima funzione (\texttt{\small 3--16}) è \func{ShmCreate} che, data una
2685 chiave, crea il segmento di memoria condivisa restituendo il puntatore allo
2686 stesso. La funzione comincia (\texttt{\small 6}) con il chiamare
2687 \func{shmget}, usando il flag \const{IPC\_CREATE} per creare il segmento
2688 qualora non esista, ed assegnandogli i privilegi specificati dall'argomento
2689 \var{perm} e la dimensione specificata dall'argomento \var{shm\_size}. In
2690 caso di errore (\texttt{\small 7--9}) si ritorna immediatamente un puntatore
2691 nullo, altrimenti (\texttt{\small 10}) si prosegue agganciando il segmento di
2692 memoria condivisa al processo con \func{shmat}. In caso di errore
2693 (\texttt{\small 11--13}) si restituisce di nuovo un puntatore nullo, infine
2694 (\texttt{\small 14}) si inizializza con \func{memset} il contenuto del
2695 segmento al valore costante specificato dall'argomento \var{fill}, e poi si
2696 ritorna il puntatore al segmento stesso.
2698 La seconda funzione (\texttt{\small 17--31}) è \func{ShmFind}, che, data una
2699 chiave, restituisce l'indirizzo del segmento ad essa associato. Anzitutto
2700 (\texttt{\small 22}) si richiede l'identificatore del segmento con
2701 \func{shmget}, ritornando (\texttt{\small 23--25}) un puntatore nullo in caso
2702 di errore. Poi si prosegue (\texttt{\small 26}) agganciando il segmento al
2703 processo con \func{shmat}, restituendo (\texttt{\small 27--29}) di nuovo un
2704 puntatore nullo in caso di errore, se invece non ci sono errori si restituisce
2705 il puntatore ottenuto da \func{shmat}.
2707 La terza funzione (\texttt{\small 32--51}) è \func{ShmRemove} che, data la
2708 chiave ed il puntatore associati al segmento di memoria condivisa, prima lo
2709 sgancia dal processo e poi lo rimuove. Il primo passo (\texttt{\small 37}) è
2710 la chiamata a \func{shmdt} per sganciare il segmento, restituendo
2711 (\texttt{\small 38--39}) un valore -1 in caso di errore. Il passo successivo
2712 (\texttt{\small 41}) è utilizzare \func{shmget} per ottenere l'identificatore
2713 associato al segmento data la chiave \var{key}. Al solito si restituisce un
2714 valore di -1 (\texttt{\small 42--45}) in caso di errore, mentre se tutto va
2715 bene si conclude restituendo un valore nullo.
2717 Benché la memoria condivisa costituisca il meccanismo di intercomunicazione
2718 fra processi più veloce, essa non è sempre il più appropriato, dato che, come
2719 abbiamo visto, si avrà comunque la necessità di una sincronizzazione degli
2720 accessi. Per questo motivo, quando la comunicazione fra processi è
2721 sequenziale, altri meccanismi come le pipe, le fifo o i socket, che non
2722 necessitano di sincronizzazione esplicita, sono da preferire. Essa diventa
2723 l'unico meccanismo possibile quando la comunicazione non è
2724 sequenziale\footnote{come accennato in sez.~\ref{sec:ipc_sysv_mq} per la
2725 comunicazione non sequenziale si possono usare le code di messaggi,
2726 attraverso l'uso del campo \var{mtype}, ma solo se quest'ultima può essere
2727 effettuata in forma di messaggio.} o quando non può avvenire secondo una
2728 modalità predefinita.
2730 Un esempio classico di uso della memoria condivisa è quello del
2731 ``\textit{monitor}'', in cui viene per scambiare informazioni fra un processo
2732 server, che vi scrive dei dati di interesse generale che ha ottenuto, e i
2733 processi client interessati agli stessi dati che così possono leggerli in
2734 maniera completamente asincrona. Con questo schema di funzionamento da una
2735 parte si evita che ciascun processo client debba compiere l'operazione,
2736 potenzialmente onerosa, di ricavare e trattare i dati, e dall'altra si evita
2737 al processo server di dover gestire l'invio a tutti i client di tutti i dati
2738 (non potendo il server sapere quali di essi servono effettivamente al singolo
2741 Nel nostro caso implementeremo un ``\textsl{monitor}'' di una directory: un
2742 processo si incaricherà di tenere sotto controllo alcuni parametri relativi ad
2743 una directory (il numero dei file contenuti, la dimensione totale, quante
2744 directory, link simbolici, file normali, ecc.) che saranno salvati in un
2745 segmento di memoria condivisa cui altri processi potranno accedere per
2746 ricavare la parte di informazione che interessa.
2748 In fig.~\ref{fig:ipc_dirmonitor_main} si è riportata la sezione principale del
2749 corpo del programma server, insieme alle definizioni delle altre funzioni
2750 usate nel programma e delle variabili globali, omettendo tutto quello che
2751 riguarda la gestione delle opzioni e la stampa delle istruzioni di uso a
2752 video; al solito il codice completo si trova con i sorgenti allegati nel file
2753 \file{DirMonitor.c}.
2755 \begin{figure}[!htb]
2756 \footnotesize \centering
2757 \begin{minipage}[c]{15.6cm}
2758 \includecodesample{listati/DirMonitor.c}
2761 \caption{Codice della funzione principale del programma \file{DirMonitor.c}.}
2762 \label{fig:ipc_dirmonitor_main}
2765 Il programma usa delle variabili globali (\texttt{\small 2--14}) per mantenere
2766 i valori relativi agli oggetti usati per la comunicazione inter-processo; si è
2767 definita inoltre una apposita struttura \struct{DirProp} che contiene i dati
2768 relativi alle proprietà che si vogliono mantenere nella memoria condivisa, per
2769 l'accesso da parte dei client.
2771 Il programma, dopo la sezione, omessa, relativa alla gestione delle opzioni da
2772 riga di comando (che si limitano alla eventuale stampa di un messaggio di
2773 aiuto a video ed all'impostazione della durata dell'intervallo con cui viene
2774 ripetuto il calcolo delle proprietà della directory) controlla (\texttt{\small
2775 20--23}) che sia stato specificato l'argomento necessario contenente il nome
2776 della directory da tenere sotto controllo, senza il quale esce immediatamente
2777 con un messaggio di errore.
2779 Poi, per verificare che l'argomento specifichi effettivamente una directory,
2780 si esegue (\texttt{\small 24--26}) su di esso una \func{chdir}, uscendo
2781 immediatamente in caso di errore. Questa funzione serve anche per impostare
2782 la directory di lavoro del programma nella directory da tenere sotto
2783 controllo, in vista del successivo uso della funzione
2784 \func{daemon}.\footnote{si noti come si è potuta fare questa scelta,
2785 nonostante le indicazioni illustrate in sez.~\ref{sec:sess_daemon}, per il
2786 particolare scopo del programma, che necessita comunque di restare
2787 all'interno di una directory.} Infine (\texttt{\small 27--29}) si installano
2788 i gestori per i vari segnali di terminazione che, avendo a che fare con un
2789 programma che deve essere eseguito come server, sono il solo strumento
2790 disponibile per concluderne l'esecuzione.
2792 Il passo successivo (\texttt{\small 30--39}) è quello di creare gli oggetti di
2793 intercomunicazione necessari. Si inizia costruendo (\texttt{\small 30}) la
2794 chiave da usare come riferimento con il nome del programma,\footnote{si è
2795 usato un riferimento relativo alla home dell'utente, supposto che i sorgenti
2796 di GaPiL siano stati installati direttamente in essa. Qualora si effettui
2797 una installazione diversa si dovrà correggere il programma.} dopo di che si
2798 richiede (\texttt{\small 31}) la creazione di un segmento di memoria condivisa
2799 con usando la funzione \func{ShmCreate} illustrata in precedenza (una pagina
2800 di memoria è sufficiente per i dati che useremo), uscendo (\texttt{\small
2801 32--35}) qualora la creazione ed il successivo agganciamento al processo non
2802 abbia successo. Con l'indirizzo \var{shmptr} così ottenuto potremo poi
2803 accedere alla memoria condivisa, che, per come abbiamo lo abbiamo definito,
2804 sarà vista nella forma data da \struct{DirProp}. Infine (\texttt{\small
2805 36--39}) utilizzando sempre la stessa chiave, si crea, tramite le funzioni
2806 di interfaccia già descritte in sez.~\ref{sec:ipc_sysv_sem}, anche un mutex,
2807 che utilizzeremo per regolare l'accesso alla memoria condivisa.
2809 \begin{figure}[!htb]
2810 \footnotesize \centering
2811 \begin{minipage}[c]{15.6cm}
2812 \includecodesample{listati/ComputeValues.c}
2815 \caption{Codice delle funzioni ausiliarie usate da \file{DirMonitor.c}.}
2816 \label{fig:ipc_dirmonitor_sub}
2819 Completata l'inizializzazione e la creazione degli oggetti di
2820 intercomunicazione il programma entra nel ciclo principale (\texttt{\small
2821 40--49}) dove vengono eseguite indefinitamente le attività di monitoraggio.
2822 Il primo passo (\texttt{\small 41}) è eseguire \func{daemon} per proseguire
2823 con l'esecuzione in background come si conviene ad un programma demone; si
2824 noti che si è mantenuta, usando un valore non nullo del primo argomento, la
2825 directory di lavoro corrente. Una volta che il programma è andato in
2826 background l'esecuzione prosegue (\texttt{\small 42--48}) all'interno di un
2827 ciclo infinito: si inizia (\texttt{\small 43}) bloccando il mutex con
2828 \func{MutexLock} per poter accedere alla memoria condivisa (la funzione si
2829 bloccherà automaticamente se qualche client sta leggendo), poi (\texttt{\small
2830 44}) si cancellano i valori precedentemente immagazzinati nella memoria
2831 condivisa con \func{memset}, e si esegue (\texttt{\small 45}) un nuovo calcolo
2832 degli stessi utilizzando la funzione \func{DirScan}; infine (\texttt{\small
2833 46}) si sblocca il mutex con \func{MutexUnlock}, e si attende
2834 (\texttt{\small 47}) per il periodo di tempo specificato a riga di comando con
2835 l'opzione \code{-p} con una \func{sleep}.
2837 Si noti come per il calcolo dei valori da mantenere nella memoria condivisa si
2838 sia usata ancora una volta la funzione \func{DirScan}, già utilizzata (e
2839 descritta in dettaglio) in sez.~\ref{sec:file_dir_read}, che ci permette di
2840 effettuare la scansione delle voci della directory, chiamando per ciascuna di
2841 esse la funzione \func{ComputeValues}, che esegue tutti i calcoli necessari.
2843 Il codice di quest'ultima è riportato in fig.~\ref{fig:ipc_dirmonitor_sub}.
2844 Come si vede la funzione (\texttt{\small 2--16}) è molto semplice e si limita
2845 a chiamare (\texttt{\small 5}) la funzione \func{stat} sul file indicato da
2846 ciascuna voce, per ottenerne i dati, che poi utilizza per incrementare i vari
2847 contatori nella memoria condivisa, cui accede grazie alla variabile globale
2850 Dato che la funzione è chiamata da \func{DirScan}, si è all'interno del ciclo
2851 principale del programma, con un mutex acquisito, perciò non è necessario
2852 effettuare nessun controllo e si può accedere direttamente alla memoria
2853 condivisa usando \var{shmptr} per riempire i campi della struttura
2854 \struct{DirProp}; così prima (\texttt{\small 6--7}) si sommano le dimensioni
2855 dei file ed il loro numero, poi, utilizzando le macro di
2856 tab.~\ref{tab:file_type_macro}, si contano (\texttt{\small 8--14}) quanti ce
2857 ne sono per ciascun tipo.
2859 In fig.~\ref{fig:ipc_dirmonitor_sub} è riportato anche il codice
2860 (\texttt{\small 17--23}) del gestore dei segnali di terminazione, usato per
2861 chiudere il programma. Esso, oltre a provocare l'uscita del programma, si
2862 incarica anche di cancellare tutti gli oggetti di intercomunicazione non più
2863 necessari. Per questo anzitutto (\texttt{\small 19}) acquisisce il mutex con
2864 \func{MutexLock}, per evitare di operare mentre un client sta ancora leggendo
2865 i dati, dopo di che (\texttt{\small 20}) distacca e rimuove il segmento di
2866 memoria condivisa usando \func{ShmRemove}. Infine (\texttt{\small 21})
2867 rimuove il mutex con \func{MutexRemove} ed esce (\texttt{\small 22}).
2869 \begin{figure}[!htb]
2870 \footnotesize \centering
2871 \begin{minipage}[c]{15.6 cm}
2872 \includecodesample{listati/ReadMonitor.c}
2875 \caption{Codice del programma client del monitor delle proprietà di una
2876 directory, \file{ReadMonitor.c}.}
2877 \label{fig:ipc_dirmonitor_client}
2880 Il codice del client usato per leggere le informazioni mantenute nella memoria
2881 condivisa è riportato in fig.~\ref{fig:ipc_dirmonitor_client}. Al solito si è
2882 omessa la sezione di gestione delle opzioni e la funzione che stampa a video
2883 le istruzioni; il codice completo è nei sorgenti allegati, nel file
2884 \file{ReadMonitor.c}.
2886 Una volta conclusa la gestione delle opzioni a riga di comando il programma
2887 rigenera (\texttt{\small 7}) con \func{ftok} la stessa chiave usata dal server
2888 per identificare il segmento di memoria condivisa ed il mutex, poi
2889 (\texttt{\small 8}) richiede con \func{ShmFind} l'indirizzo della memoria
2890 condivisa agganciando al contempo il segmento al processo, Infine
2891 (\texttt{\small 17--20}) con \func{MutexFind} si richiede l'identificatore del
2892 mutex. Completata l'inizializzazione ed ottenuti i riferimenti agli oggetti
2893 di intercomunicazione necessari viene eseguito il corpo principale del
2894 programma (\texttt{\small 21--33}); si comincia (\texttt{\small 22})
2895 acquisendo il mutex con \func{MutexLock}; qui avviene il blocco del processo
2896 se la memoria condivisa non è disponibile. Poi (\texttt{\small 23--31}) si
2897 stampano i vari valori mantenuti nella memoria condivisa attraverso l'uso di
2898 \var{shmptr}. Infine (\texttt{\small 41}) con \func{MutexUnlock} si rilascia
2899 il mutex, prima di uscire.
2901 Verifichiamo allora il funzionamento dei nostri programmi; al solito, usando
2902 le funzioni di libreria occorre definire opportunamente
2903 \code{LD\_LIBRARY\_PATH}; poi si potrà lanciare il server con:
2905 [piccardi@gont sources]$ ./dirmonitor ./
2907 ed avendo usato \func{daemon} il comando ritornerà immediatamente. Una volta
2908 che il server è in esecuzione, possiamo passare ad invocare il client per
2909 verificarne i risultati, in tal caso otterremo:
2911 [piccardi@gont sources]$ ./readmon
2912 Ci sono 68 file dati
2917 Ci sono 0 device a caratteri
2918 Ci sono 0 device a blocchi
2919 Totale 71 file, per 489831 byte
2921 ed un rapido calcolo (ad esempio con \code{ls -a | wc} per contare i file) ci
2922 permette di verificare che il totale dei file è giusto. Un controllo con
2923 \cmd{ipcs} ci permette inoltre di verificare la presenza di un segmento di
2924 memoria condivisa e di un semaforo:
2926 [piccardi@gont sources]$ ipcs
2927 ------ Shared Memory Segments --------
2928 key shmid owner perms bytes nattch status
2929 0xffffffff 54067205 piccardi 666 4096 1
2931 ------ Semaphore Arrays --------
2932 key semid owner perms nsems
2933 0xffffffff 229376 piccardi 666 1
2935 ------ Message Queues --------
2936 key msqid owner perms used-bytes messages
2939 Se a questo punto aggiungiamo un file, ad esempio con \code{touch prova},
2940 potremo verificare che, passati nel peggiore dei casi almeno 10 secondi (o
2941 l'eventuale altro intervallo impostato per la rilettura dei dati) avremo:
2943 [piccardi@gont sources]$ ./readmon
2944 Ci sono 69 file dati
2949 Ci sono 0 device a caratteri
2950 Ci sono 0 device a blocchi
2951 Totale 72 file, per 489887 byte
2954 A questo punto possiamo far uscire il server inviandogli un segnale di
2955 \const{SIGTERM} con il comando \code{killall dirmonitor}, a questo punto
2956 ripetendo la lettura, otterremo un errore:
2958 [piccardi@gont sources]$ ./readmon
2959 Cannot find shared memory: No such file or directory
2961 e inoltre potremo anche verificare che anche gli oggetti di intercomunicazione
2962 visti in precedenza sono stati regolarmente cancellati:
2964 [piccardi@gont sources]$ ipcs
2965 ------ Shared Memory Segments --------
2966 key shmid owner perms bytes nattch status
2968 ------ Semaphore Arrays --------
2969 key semid owner perms nsems
2971 ------ Message Queues --------
2972 key msqid owner perms used-bytes messages
2977 %% Per capire meglio il funzionamento delle funzioni facciamo ancora una volta
2978 %% riferimento alle strutture con cui il kernel implementa i segmenti di memoria
2979 %% condivisa; uno schema semplificato della struttura è illustrato in
2980 %% fig.~\ref{fig:ipc_shm_struct}.
2982 %% \begin{figure}[htb]
2984 %% \includegraphics[width=10cm]{img/shmstruct}
2985 %% \caption{Schema dell'implementazione dei segmenti di memoria condivisa in
2987 %% \label{fig:ipc_shm_struct}
2993 \section{Tecniche alternative}
2994 \label{sec:ipc_alternatives}
2996 Come abbiamo detto in sez.~\ref{sec:ipc_sysv_generic}, e ripreso nella
2997 descrizione dei singoli oggetti che ne fan parte, il \textit{SysV IPC}
2998 presenta numerosi problemi; in \cite{APUE}\footnote{in particolare nel
2999 capitolo 14.} Stevens ne effettua una accurata analisi (alcuni dei concetti
3000 sono già stati accennati in precedenza) ed elenca alcune possibili tecniche
3001 alternative, che vogliamo riprendere in questa sezione.
3004 \subsection{Alternative alle code di messaggi}
3005 \label{sec:ipc_mq_alternative}
3007 Le code di messaggi sono probabilmente il meno usato degli oggetti del
3008 \textit{SysV IPC}; esse infatti nacquero principalmente come meccanismo di
3009 comunicazione bidirezionale quando ancora le pipe erano unidirezionali; con la
3010 disponibilità di \func{socketpair} (vedi sez.~\ref{sec:ipc_socketpair}) o
3011 utilizzando una coppia di pipe, si può ottenere questo risultato senza
3012 incorrere nelle complicazioni introdotte dal \textit{SysV IPC}.
3014 In realtà, grazie alla presenza del campo \var{mtype}, le code di messaggi
3015 hanno delle caratteristiche ulteriori, consentendo una classificazione dei
3016 messaggi ed un accesso non rigidamente sequenziale; due caratteristiche che
3017 sono impossibili da ottenere con le pipe e i socket di \func{socketpair}. A
3018 queste esigenze però si può comunque ovviare in maniera diversa con un uso
3019 combinato della memoria condivisa e dei meccanismi di sincronizzazione, per
3020 cui alla fine l'uso delle code di messaggi classiche è relativamente poco
3023 \subsection{I \textsl{file di lock}}
3024 \label{sec:ipc_file_lock}
3026 \index{file!di lock|(}
3028 Come illustrato in sez.~\ref{sec:ipc_sysv_sem} i semafori del \textit{SysV IPC}
3029 presentano una interfaccia inutilmente complessa e con alcuni difetti
3030 strutturali, per questo quando si ha una semplice esigenza di sincronizzazione
3031 per la quale basterebbe un semaforo binario (quello che abbiamo definito come
3032 \textit{mutex}), per indicare la disponibilità o meno di una risorsa, senza la
3033 necessità di un contatore come i semafori, si possono utilizzare metodi
3036 La prima possibilità, utilizzata fin dalle origini di Unix, è quella di usare
3037 dei \textsl{file di lock} (per i quali esiste anche una opportuna directory,
3038 \file{/var/lock}, nel filesystem standard). Per questo si usa la
3039 caratteristica della funzione \func{open} (illustrata in
3040 sez.~\ref{sec:file_open}) che prevede\footnote{questo è quanto dettato dallo
3041 standard POSIX.1, ciò non toglie che in alcune implementazioni questa
3042 tecnica possa non funzionare; in particolare per Linux, nel caso di NFS, si
3043 è comunque soggetti alla possibilità di una \itindex{race~condition}
3044 \textit{race condition}.} che essa ritorni un errore quando usata con i
3045 flag di \const{O\_CREAT} e \const{O\_EXCL}. In tal modo la creazione di un
3046 \textsl{file di lock} può essere eseguita atomicamente, il processo che crea
3047 il file con successo si può considerare come titolare del lock (e della
3048 risorsa ad esso associata) mentre il rilascio si può eseguire con una chiamata
3051 Un esempio dell'uso di questa funzione è mostrato dalle funzioni
3052 \func{LockFile} ed \func{UnlockFile} riportate in fig.~\ref{fig:ipc_file_lock}
3053 (sono contenute in \file{LockFile.c}, un altro dei sorgenti allegati alla
3054 guida) che permettono rispettivamente di creare e rimuovere un \textsl{file di
3055 lock}. Come si può notare entrambe le funzioni sono elementari; la prima
3056 (\texttt{\small 4--10}) si limita ad aprire il file di lock (\texttt{\small
3057 9}) nella modalità descritta, mentre la seconda (\texttt{\small 11--17}) lo
3058 cancella con \func{unlink}.
3060 \begin{figure}[!htb]
3061 \footnotesize \centering
3062 \begin{minipage}[c]{15.6cm}
3063 \includecodesample{listati/LockFile.c}
3066 \caption{Il codice delle funzioni \func{LockFile} e \func{UnlockFile} che
3067 permettono di creare e rimuovere un \textsl{file di lock}.}
3068 \label{fig:ipc_file_lock}
3071 Uno dei limiti di questa tecnica è che, come abbiamo già accennato in
3072 sez.~\ref{sec:file_open}, questo comportamento di \func{open} può non
3073 funzionare (la funzione viene eseguita, ma non è garantita l'atomicità
3074 dell'operazione) se il filesystem su cui si va ad operare è su NFS; in tal
3075 caso si può adottare una tecnica alternativa che prevede l'uso della
3076 \func{link} per creare come \textsl{file di lock} un hard link ad un file
3077 esistente; se il link esiste già e la funzione fallisce, significa che la
3078 risorsa è bloccata e potrà essere sbloccata solo con un \func{unlink},
3079 altrimenti il link è creato ed il lock acquisito; il controllo e l'eventuale
3080 acquisizione sono atomici; la soluzione funziona anche su NFS, ma ha un altro
3081 difetto è che è quello di poterla usare solo se si opera all'interno di uno
3084 In generale comunque l'uso di un \textsl{file di lock} presenta parecchi
3085 problemi che non lo rendono una alternativa praticabile per la
3086 sincronizzazione: anzitutto in caso di terminazione imprevista del processo,
3087 si lascia allocata la risorsa (il \textsl{file di lock}) e questa deve essere
3088 sempre cancellata esplicitamente. Inoltre il controllo della disponibilità
3089 può essere eseguito solo con una tecnica di \itindex{polling}
3090 \textit{polling}, ed è quindi molto inefficiente.
3092 La tecnica dei file di lock ha comunque una sua utilità, e può essere usata
3093 con successo quando l'esigenza è solo quella di segnalare l'occupazione di una
3094 risorsa, senza necessità di attendere che questa si liberi; ad esempio la si
3095 usa spesso per evitare interferenze sull'uso delle porte seriali da parte di
3096 più programmi: qualora si trovi un file di lock il programma che cerca di
3097 accedere alla seriale si limita a segnalare che la risorsa non è disponibile.
3099 \index{file!di lock|)}
3102 \subsection{La sincronizzazione con il \textit{file locking}}
3103 \label{sec:ipc_lock_file}
3105 Dato che i \index{file!di lock} file di lock presentano gli inconvenienti
3106 illustrati in precedenza, la tecnica alternativa di sincronizzazione più
3107 comune è quella di fare ricorso al \index{file!locking} \textit{file locking}
3108 (trattato in sez.~\ref{sec:file_locking}) usando \func{fcntl} su un file
3109 creato per l'occasione per ottenere un write lock. In questo modo potremo
3110 usare il lock come un \textit{mutex}: per bloccare la risorsa basterà
3111 acquisire il lock, per sbloccarla basterà rilasciare il lock. Una richiesta
3112 fatta con un write lock metterà automaticamente il processo in stato di
3113 attesa, senza necessità di ricorrere al \itindex{polling} \textit{polling} per
3114 determinare la disponibilità della risorsa, e al rilascio della stessa da
3115 parte del processo che la occupava si otterrà il nuovo lock atomicamente.
3117 Questo approccio presenta il notevole vantaggio che alla terminazione di un
3118 processo tutti i lock acquisiti vengono rilasciati automaticamente (alla
3119 chiusura dei relativi file) e non ci si deve preoccupare di niente; inoltre
3120 non consuma risorse permanentemente allocate nel sistema. Lo svantaggio è che,
3121 dovendo fare ricorso a delle operazioni sul filesystem, esso è in genere
3122 leggermente più lento.
3124 \begin{figure}[!htb]
3125 \footnotesize \centering
3126 \begin{minipage}[c]{15.6cm}
3127 \includecodesample{listati/MutexLocking.c}
3130 \caption{Il codice delle funzioni che permettono per la gestione dei
3131 \textit{mutex} con il \index{file!locking} \textit{file locking}.}
3132 \label{fig:ipc_flock_mutex}
3135 Il codice delle varie funzioni usate per implementare un mutex utilizzando il
3136 \textit{file locking} \index{file!locking} è riportato in
3137 fig.~\ref{fig:ipc_flock_mutex}; si è mantenuta volutamente una struttura
3138 analoga alle precedenti funzioni che usano i semafori, anche se le due
3139 interfacce non possono essere completamente equivalenti, specie per quanto
3140 riguarda la rimozione del mutex.
3142 La prima funzione (\texttt{\small 1--5}) è \func{CreateMutex}, e serve a
3143 creare il mutex; la funzione è estremamente semplice, e si limita
3144 (\texttt{\small 4}) a creare, con una opportuna chiamata ad \func{open}, il
3145 file che sarà usato per il successivo \textit{file locking}, assicurandosi che
3146 non esista già (nel qual caso segnala un errore); poi restituisce il file
3147 descriptor che sarà usato dalle altre funzioni per acquisire e rilasciare il
3150 La seconda funzione (\texttt{\small 6--10}) è \func{FindMutex}, che, come la
3151 precedente, è stata definita per mantenere una analogia con la corrispondente
3152 funzione basata sui semafori. Anch'essa si limita (\texttt{\small 9}) ad
3153 aprire il file da usare per il \index{file!locking} \textit{file locking},
3154 solo che in questo caso le opzioni di \func{open} sono tali che il file in
3155 questione deve esistere di già.
3157 La terza funzione (\texttt{\small 11--22}) è \func{LockMutex} e serve per
3158 acquisire il mutex. La funzione definisce (\texttt{\small 14}) e inizializza
3159 (\texttt{\small 16--19}) la struttura \var{lock} da usare per acquisire un
3160 write lock sul file, che poi (\texttt{\small 21}) viene richiesto con
3161 \func{fcntl}, restituendo il valore di ritorno di quest'ultima. Se il file è
3162 libero il lock viene acquisito e la funzione ritorna immediatamente;
3163 altrimenti \func{fcntl} si bloccherà (si noti che la si è chiamata con
3164 \const{F\_SETLKW}) fino al rilascio del lock.
3166 La quarta funzione (\texttt{\small 24--34}) è \func{UnlockMutex} e serve a
3167 rilasciare il mutex. La funzione è analoga alla precedente, solo che in questo
3168 caso si inizializza (\texttt{\small 28--31}) la struttura \var{lock} per il
3169 rilascio del lock, che viene effettuato (\texttt{\small 33}) con la opportuna
3170 chiamata a \func{fcntl}. Avendo usato il \index{file!locking} \textit{file
3171 locking} in semantica POSIX (si riveda quanto detto
3172 sez.~\ref{sec:file_posix_lock}) solo il processo che ha precedentemente
3173 eseguito il lock può sbloccare il mutex.
3175 La quinta funzione (\texttt{\small 36--39}) è \func{RemoveMutex} e serve a
3176 cancellare il mutex. Anche questa funzione è stata definita per mantenere una
3177 analogia con le funzioni basate sui semafori, e si limita a cancellare
3178 (\texttt{\small 38}) il file con una chiamata ad \func{unlink}. Si noti che in
3179 questo caso la funzione non ha effetto sui mutex già ottenuti con precedenti
3180 chiamate a \func{FindMutex} o \func{CreateMutex}, che continueranno ad essere
3181 disponibili fintanto che i relativi file descriptor restano aperti. Pertanto
3182 per rilasciare un mutex occorrerà prima chiamare \func{UnlockMutex} oppure
3183 chiudere il file usato per il lock.
3185 La sesta funzione (\texttt{\small 41--55}) è \func{ReadMutex} e serve a
3186 leggere lo stato del mutex. In questo caso si prepara (\texttt{\small 46--49})
3187 la solita struttura \var{lock} come l'acquisizione del lock, ma si effettua
3188 (\texttt{\small 51}) la chiamata a \func{fcntl} usando il comando
3189 \const{F\_GETLK} per ottenere lo stato del lock, e si restituisce
3190 (\texttt{\small 52}) il valore di ritorno in caso di errore, ed il valore del
3191 campo \var{l\_type} (che descrive lo stato del lock) altrimenti
3192 (\texttt{\small 54}). Per questo motivo la funzione restituirà -1 in caso di
3193 errore e uno dei due valori \const{F\_UNLCK} o \const{F\_WRLCK}\footnote{non
3194 si dovrebbe mai avere il terzo valore possibile, \const{F\_RDLCK}, dato che
3195 la nostra interfaccia usa solo i write lock. Però è sempre possibile che
3196 siano richiesti altri lock sul file al di fuori dell'interfaccia, nel qual
3197 caso si potranno avere, ovviamente, interferenze indesiderate.} in caso di
3198 successo, ad indicare che il mutex è, rispettivamente, libero o occupato.
3200 Basandosi sulla semantica dei file lock POSIX valgono tutte le considerazioni
3201 relative al comportamento di questi ultimi fatte in
3202 sez.~\ref{sec:file_posix_lock}; questo significa ad esempio che, al contrario
3203 di quanto avveniva con l'interfaccia basata sui semafori, chiamate multiple a
3204 \func{UnlockMutex} o \func{LockMutex} non si cumulano e non danno perciò
3205 nessun inconveniente.
3208 \subsection{Il \textit{memory mapping} anonimo}
3209 \label{sec:ipc_mmap_anonymous}
3211 \itindbeg{memory~mapping}
3212 Abbiamo già visto che quando i processi sono \textsl{correlati}\footnote{se
3213 cioè hanno almeno un progenitore comune.} l'uso delle pipe può costituire
3214 una valida alternativa alle code di messaggi; nella stessa situazione si può
3215 evitare l'uso di una memoria condivisa facendo ricorso al cosiddetto
3216 \textit{memory mapping} anonimo.
3218 In sez.~\ref{sec:file_memory_map} abbiamo visto come sia possibile mappare il
3219 contenuto di un file nella memoria di un processo, e che, quando viene usato
3220 il flag \const{MAP\_SHARED}, le modifiche effettuate al contenuto del file
3221 vengono viste da tutti i processi che lo hanno mappato. Utilizzare questa
3222 tecnica per creare una memoria condivisa fra processi diversi è estremamente
3223 inefficiente, in quanto occorre passare attraverso il disco. Però abbiamo
3224 visto anche che se si esegue la mappatura con il flag \const{MAP\_ANONYMOUS}
3225 la regione mappata non viene associata a nessun file, anche se quanto scritto
3226 rimane in memoria e può essere riletto; allora, dato che un processo figlio
3227 mantiene nel suo spazio degli indirizzi anche le regioni mappate, esso sarà
3228 anche in grado di accedere a quanto in esse è contenuto.
3230 In questo modo diventa possibile creare una memoria condivisa fra processi
3231 diversi, purché questi abbiano almeno un progenitore comune che ha effettuato
3232 il \textit{memory mapping} anonimo.\footnote{nei sistemi derivati da SysV una
3233 funzionalità simile a questa viene implementata mappando il file speciale
3234 \file{/dev/zero}. In tal caso i valori scritti nella regione mappata non
3235 vengono ignorati (come accade qualora si scriva direttamente sul file), ma
3236 restano in memoria e possono essere riletti secondo le stesse modalità usate
3237 nel \textit{memory mapping} anonimo.} Vedremo come utilizzare questa tecnica
3238 più avanti, quando realizzeremo una nuova versione del monitor visto in
3239 sez.~\ref{sec:ipc_sysv_shm} che possa restituisca i risultati via rete.
3240 \itindend{memory~mapping}
3242 % TODO fare esempio di mmap anonima
3244 \section{Il sistema di comunicazione fra processi di POSIX}
3245 \label{sec:ipc_posix}
3247 Per superare i numerosi problemi del \textit{SysV IPC}, evidenziati per i suoi
3248 aspetti generali in coda a sez.~\ref{sec:ipc_sysv_generic} e per i singoli
3249 oggetti nei paragrafi successivi, lo standard POSIX.1b ha introdotto dei nuovi
3250 meccanismi di comunicazione, che vanno sotto il nome di POSIX IPC, definendo
3251 una interfaccia completamente nuova, che tratteremo in questa sezione.
3254 \subsection{Considerazioni generali}
3255 \label{sec:ipc_posix_generic}
3257 Oggi Linux supporta tutti gli oggetti definito nello standard POSIX per l'IPC,
3258 ma a lungo non è stato così; la memoria condivisa è presente a partire dal
3259 kernel 2.4.x, i semafori sono forniti dalle \acr{glibc} nella sezione che
3260 implementa i thread POSIX di nuova generazione che richiedono il kernel 2.6,
3261 le code di messaggi sono supportate a partire dal kernel 2.6.6.
3263 La caratteristica fondamentale dell'interfaccia POSIX è l'abbandono dell'uso
3264 degli identificatori e delle chiavi visti nel SysV IPC, per passare ai
3265 \itindex{POSIX~IPC~names} \textit{POSIX IPC names}, che sono sostanzialmente
3266 equivalenti ai nomi dei file. Tutte le funzioni che creano un oggetto di IPC
3267 POSIX prendono come primo argomento una stringa che indica uno di questi nomi;
3268 lo standard è molto generico riguardo l'implementazione, ed i nomi stessi
3269 possono avere o meno una corrispondenza sul filesystem; tutto quello che è
3272 \item i nomi devono essere conformi alle regole che caratterizzano i
3273 \itindex{pathname} \textit{pathname}, in particolare non essere più lunghi di
3274 \const{PATH\_MAX} byte e terminati da un carattere nullo.
3275 \item se il nome inizia per una \texttt{/} chiamate differenti allo stesso
3276 nome fanno riferimento allo stesso oggetto, altrimenti l'interpretazione del
3277 nome dipende dall'implementazione.
3278 \item l'interpretazione di ulteriori \texttt{/} presenti nel nome dipende
3279 dall'implementazione.
3282 Data la assoluta genericità delle specifiche, il comportamento delle funzioni
3283 è subordinato in maniera quasi completa alla relativa
3284 implementazione.\footnote{tanto che Stevens in \cite{UNP2} cita questo caso
3285 come un esempio della maniera standard usata dallo standard POSIX per
3286 consentire implementazioni non standardizzabili.} Nel caso di Linux, sia per
3287 quanto riguarda la memoria condivisa ed i semafori, che per quanto riguarda le
3288 code di messaggi, tutto viene creato usando come radici delle opportune
3289 directory (rispettivamente \file{/dev/shm} e \file{/dev/mqueue}, per i
3290 dettagli si faccia riferimento a sez.~\ref{sec:ipc_posix_shm},
3291 sez.~\ref{sec:ipc_posix_sem} e sez.~\ref{sec:ipc_posix_mq}) ed i nomi
3292 specificati nelle relative funzioni sono considerati come un
3293 \itindsub{pathname}{assoluto} \textit{pathname} assoluto (comprendente
3294 eventuali sottodirectory) rispetto a queste radici.
3296 Il vantaggio degli oggetti di IPC POSIX è comunque che essi vengono inseriti
3297 nell'albero dei file, e possono essere maneggiati con le usuali funzioni e
3298 comandi di accesso ai file,\footnote{questo è vero nel caso di Linux, che usa
3299 una implementazione che lo consente, non è detto che altrettanto valga per
3300 altri kernel; in particolare, come si può facilmente verificare con uno
3301 \cmd{strace}, sia per la memoria condivisa che per le code di messaggi le
3302 system call utilizzate da Linux sono le stesse di quelle dei file, essendo
3303 detti oggetti realizzati come tali in appositi filesystem.} che funzionano
3304 come su dei file normali.
3306 In particolare i permessi associati agli oggetti di IPC POSIX sono identici ai
3307 permessi dei file, ed il controllo di accesso segue esattamente la stessa
3308 semantica (quella illustrata in sez.~\ref{sec:file_access_control}), e non
3309 quella particolare (si ricordi quanto visto in
3310 sez.~\ref{sec:ipc_sysv_access_control}) che viene usata per gli oggetti del
3311 SysV IPC. Per quanto riguarda l'attribuzione dell'utente e del gruppo
3312 proprietari dell'oggetto alla creazione di quest'ultimo essa viene effettuata
3313 secondo la semantica SysV: corrispondono cioè a user-ID e group-ID effettivi
3314 del processo che esegue la creazione.
3317 \subsection{Code di messaggi}
3318 \label{sec:ipc_posix_mq}
3320 Le code di messaggi POSIX sono supportate da Linux a partire dalla versione
3321 2.6.6-rc1 del kernel,\footnote{l'implementazione è dovuta a Michal Wronski e
3322 Krzysztof Benedyczak, e le relative informazioni si possono trovare su
3323 \href{http://www.geocities.com/wronski12/posix_ipc/index.html}
3324 {\texttt{http://www.geocities.com/wronski12/posix\_ipc/index.html}}.} In
3325 generale, come le corrispettive del SysV IPC, le code di messaggi sono poco
3326 usate, dato che i socket, nei casi in cui sono sufficienti, sono più comodi, e
3327 che in casi più complessi la comunicazione può essere gestita direttamente con
3328 mutex (o semafori) e memoria condivisa con tutta la flessibilità che occorre.
3330 Per poter utilizzare le code di messaggi, oltre ad utilizzare un kernel
3331 superiore al 2.6.6 (o precedente, se sono stati opportunamente applicati i
3332 relativi patch) occorre utilizzare la libreria \file{libmqueue}\footnote{i
3333 programmi che usano le code di messaggi cioè devono essere compilati
3334 aggiungendo l'opzione \code{-lmqueue} al comando \cmd{gcc}; in
3335 corrispondenza all'inclusione del supporto nel kernel ufficiale anche
3336 \file{libmqueue} è stata inserita nelle \acr{glibc}, a partire dalla
3337 versione 2.3.4 delle medesime.} che contiene le funzioni dell'interfaccia
3338 POSIX.\footnote{in realtà l'implementazione è realizzata tramite delle
3339 opportune chiamate ad \func{ioctl} sui file del filesystem speciale su cui
3340 vengono mantenuti questi oggetti di IPC.}
3342 La libreria inoltre richiede la presenza dell'apposito filesystem di tipo
3343 \texttt{mqueue} montato su \file{/dev/mqueue}; questo può essere fatto
3344 aggiungendo ad \conffile{/etc/fstab} una riga come:
3346 mqueue /dev/mqueue mqueue defaults 0 0
3348 ed esso sarà utilizzato come radice sulla quale vengono risolti i nomi delle
3349 code di messaggi che iniziano con una \texttt{/}. Le opzioni di mount
3350 accettate sono \texttt{uid}, \texttt{gid} e \texttt{mode} che permettono
3351 rispettivamente di impostare l'utente, il gruppo ed i permessi associati al
3355 La funzione che permette di aprire (e crearla se non esiste ancora) una coda
3356 di messaggi POSIX è \funcd{mq\_open}, ed il suo prototipo è:
3360 \funcdecl{mqd\_t mq\_open(const char *name, int oflag)}
3362 \funcdecl{mqd\_t mq\_open(const char *name, int oflag, unsigned long mode,
3363 struct mq\_attr *attr)}
3365 Apre una coda di messaggi POSIX impostandone le caratteristiche.
3367 \bodydesc{La funzione restituisce il descrittore associato alla coda in caso
3368 di successo e -1 in caso di errore; nel quel caso \var{errno} assumerà i
3371 \item[\errcode{EACCES}] il processo non ha i privilegi per accedere al
3372 alla memoria secondo quanto specificato da \param{oflag}.
3373 \item[\errcode{EEXIST}] si è specificato \const{O\_CREAT} e
3374 \const{O\_EXCL} ma la coda già esiste.
3375 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
3376 \item[\errcode{EINVAL}] il file non supporta la funzione, o si è
3377 specificato \const{O\_CREAT} con una valore non nullo di \param{attr} e
3378 valori non validi di \var{mq\_maxmsg} e \var{mq\_msgsize}.
3379 \item[\errcode{ENOENT}] non si è specificato \const{O\_CREAT} ma la coda
3382 ed inoltre \errval{ENOMEM}, \errval{ENOSPC}, \errval{EFAULT},
3383 \errval{EMFILE} ed \errval{ENFILE}.}
3386 La funzione apre la coda di messaggi identificata dall'argomento \param{name}
3387 restituendo il descrittore ad essa associato, del tutto analogo ad un file
3388 descriptor, con l'unica differenza che lo standard prevede un apposito tipo
3389 \type{mqd\_t}.\footnote{nella implementazione citata questo è definito come
3390 \ctyp{int}.} Se la coda esiste già il descrittore farà riferimento allo
3391 stesso oggetto, consentendo così la comunicazione fra due processi diversi.
3393 La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
3394 possono essere specificati per \param{oflag}, che deve essere specificato come
3395 maschera binaria; i valori possibili per i vari bit sono quelli visti in
3396 tab.~\ref{tab:file_open_flags} dei quali però \func{mq\_open} riconosce solo i
3398 \begin{basedescript}{\desclabelwidth{2cm}\desclabelstyle{\nextlinelabel}}
3399 \item[\const{O\_RDONLY}] Apre la coda solo per la ricezione di messaggi. Il
3400 processo potrà usare il descrittore con \func{mq\_receive} ma non con
3402 \item[\const{O\_WRONLY}] Apre la coda solo per la trasmissione di messaggi. Il
3403 processo potrà usare il descrittore con \func{mq\_send} ma non con
3405 \item[\const{O\_RDWR}] Apre la coda solo sia per la trasmissione che per la
3407 \item[\const{O\_CREAT}] Necessario qualora si debba creare la coda; la
3408 presenza di questo bit richiede la presenza degli ulteriori argomenti
3409 \param{mode} e \param{attr}.
3410 \item[\const{O\_EXCL}] Se usato insieme a \const{O\_CREAT} fa fallire la
3411 chiamata se la coda esiste già, altrimenti esegue la creazione atomicamente.
3412 \item[\const{O\_NONBLOCK}] Imposta la coda in modalità non bloccante, le
3413 funzioni di ricezione e trasmissione non si bloccano quando non ci sono le
3414 risorse richieste, ma ritornano immediatamente con un errore di
3418 I primi tre bit specificano la modalità di apertura della coda, e sono fra
3419 loro esclusivi. Ma qualunque sia la modalità in cui si è aperta una coda,
3420 questa potrà essere riaperta più volte in una modalità diversa, e vi si potrà
3421 sempre accedere attraverso descrittori diversi, esattamente come si può fare
3424 Se la coda non esiste e la si vuole creare si deve specificare
3425 \const{O\_CREAT}, in tal caso occorre anche specificare i permessi di
3426 creazione con l'argomento \param{mode}; i valori di quest'ultimo sono identici
3427 a quelli usati per \func{open}, anche se per le code di messaggi han senso
3428 solo i permessi di lettura e scrittura. Oltre ai permessi di creazione possono
3429 essere specificati anche gli attributi specifici della coda tramite
3430 l'argomento \param{attr}; quest'ultimo è un puntatore ad una apposita
3431 struttura \struct{mq\_attr}, la cui definizione è riportata in
3432 fig.~\ref{fig:ipc_mq_attr}.
3434 \begin{figure}[!htb]
3435 \footnotesize \centering
3436 \begin{minipage}[c]{15cm}
3437 \includestruct{listati/mq_attr.h}
3440 \caption{La struttura \structd{mq\_attr}, contenente gli attributi di una
3441 coda di messaggi POSIX.}
3442 \label{fig:ipc_mq_attr}
3445 Per la creazione della coda i campi della struttura che devono essere
3446 specificati sono \var{mq\_msgsize} e \var{mq\_maxmsg}, che indicano
3447 rispettivamente la dimensione massima di un messaggio ed il numero massimo di
3448 messaggi che essa può contenere. Il valore dovrà essere positivo e minore dei
3449 rispettivi limiti di sistema \const{MQ\_MAXMSG} e \const{MQ\_MSGSIZE},
3450 altrimenti la funzione fallirà con un errore di \errcode{EINVAL}. Qualora si
3451 specifichi per \param{attr} un puntatore nullo gli attributi della coda
3452 saranno impostati ai valori predefiniti.
3454 Quando l'accesso alla coda non è più necessario si può chiudere il relativo
3455 descrittore con la funzione \funcd{mq\_close}, il cui prototipo è:
3456 \begin{prototype}{mqueue.h}
3457 {int mq\_close(mqd\_t mqdes)}
3459 Chiude la coda \param{mqdes}.
3461 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
3462 errore; nel quel caso \var{errno} assumerà i valori \errval{EBADF} o
3466 La funzione è analoga a \func{close},\footnote{in Linux, dove le code sono
3467 implementate come file su un filesystem dedicato, è esattamente la stessa
3468 funzione.} dopo la sua esecuzione il processo non sarà più in grado di usare
3469 il descrittore della coda, ma quest'ultima continuerà ad esistere nel sistema
3470 e potrà essere acceduta con un'altra chiamata a \func{mq\_open}. All'uscita di
3471 un processo tutte le code aperte, così come i file, vengono chiuse
3472 automaticamente. Inoltre se il processo aveva agganciato una richiesta di
3473 notifica sul descrittore che viene chiuso, questa sarà rilasciata e potrà
3474 essere richiesta da qualche altro processo.
3477 Quando si vuole effettivamente rimuovere una coda dal sistema occorre usare la
3478 funzione \funcd{mq\_unlink}, il cui prototipo è:
3479 \begin{prototype}{mqueue.h}
3480 {int mq\_unlink(const char *name)}
3482 Rimuove una coda di messaggi.
3484 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
3485 errore; nel quel caso \var{errno} assumerà gli stessi valori riportati da
3489 Anche in questo caso il comportamento della funzione è analogo a quello di
3490 \func{unlink} per i file,\footnote{di nuovo l'implementazione di Linux usa
3491 direttamente \func{unlink}.} la funzione rimuove la coda \param{name}, così
3492 che una successiva chiamata a \func{mq\_open} fallisce o crea una coda
3495 Come per i file ogni coda di messaggi ha un contatore di riferimenti, per cui
3496 la coda non viene effettivamente rimossa dal sistema fin quando questo non si
3497 annulla. Pertanto anche dopo aver eseguito con successo \func{mq\_unlink} la
3498 coda resterà accessibile a tutti i processi che hanno un descrittore aperto su
3499 di essa. Allo stesso modo una coda ed i suoi contenuti resteranno disponibili
3500 all'interno del sistema anche quando quest'ultima non è aperta da nessun
3501 processo (questa è una delle differenze più rilevanti nei confronti di pipe e
3504 La sola differenza fra code di messaggi POSIX e file normali è che, essendo il
3505 filesystem delle code di messaggi virtuale e basato su oggetti interni al
3506 kernel, il suo contenuto viene perduto con il riavvio del sistema.
3508 Come accennato in precedenza ad ogni coda di messaggi è associata una
3509 struttura \struct{mq\_attr}, che può essere letta e modificata attraverso le
3510 due funzioni \funcd{mq\_getattr} e \funcd{mq\_setattr}, i cui prototipi sono:
3514 \funcdecl{int mq\_getattr(mqd\_t mqdes, struct mq\_attr *mqstat)}
3515 Legge gli attributi di una coda di messaggi POSIX.
3517 \funcdecl{int mq\_setattr(mqd\_t mqdes, const struct mq\_attr *mqstat,
3518 struct mq\_attr *omqstat)}
3519 Modifica gli attributi di una coda di messaggi POSIX.
3521 \bodydesc{Entrambe le funzioni restituiscono 0 in caso di successo e -1 in
3522 caso di errore; nel quel caso \var{errno} assumerà i valori \errval{EBADF}
3526 La funzione \func{mq\_getattr} legge i valori correnti degli attributi della
3527 coda nella struttura puntata da \param{mqstat}; di questi l'unico relativo
3528 allo stato corrente della coda è \var{mq\_curmsgs} che indica il numero di
3529 messaggi da essa contenuti, gli altri indicano le caratteristiche generali
3532 La funzione \func{mq\_setattr} permette di modificare gli attributi di una
3533 coda tramite i valori contenuti nella struttura puntata da \param{mqstat}, ma
3534 può essere modificato solo il campo \var{mq\_flags}, gli altri campi vengono
3535 ignorati. In particolare i valori di \var{mq\_maxmsg} e \var{mq\_msgsize}
3536 possono essere specificati solo in fase ci creazione della coda. Inoltre i
3537 soli valori possibili per \var{mq\_flags} sono 0 e \const{O\_NONBLOCK}, per
3538 cui alla fine la funzione può essere utilizzata solo per abilitare o
3539 disabilitare la modalità non bloccante. L'argomento \param{omqstat} viene
3540 usato, quando diverso da \val{NULL}, per specificare l'indirizzo di una
3541 struttura su cui salvare i valori degli attributi precedenti alla chiamata
3544 Per inserire messaggi su di una coda sono previste due funzioni,
3545 \funcd{mq\_send} e \funcd{mq\_timedsend}, i cui prototipi sono:
3549 \funcdecl{int mq\_send(mqd\_t mqdes, const char *msg\_ptr, size\_t msg\_len,
3550 unsigned int msg\_prio)}
3551 Esegue l'inserimento di un messaggio su una coda.
3553 \funcdecl{int mq\_timedsend(mqd\_t mqdes, const char *msg\_ptr, size\_t
3554 msg\_len, unsigned msg\_prio, const struct timespec *abs\_timeout)}
3555 Esegue l'inserimento di un messaggio su una coda entro il tempo
3556 \param{abs\_timeout}.
3559 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
3560 errore; nel quel caso \var{errno} assumerà i valori:
3562 \item[\errcode{EAGAIN}] si è aperta la coda con \const{O\_NONBLOCK}, e la
3564 \item[\errcode{EMSGSIZE}] la lunghezza del messaggio \param{msg\_len}
3565 eccede il limite impostato per la coda.
3566 \item[\errcode{ENOMEM}] il kernel non ha memoria sufficiente. Questo
3567 errore può avvenire quando l'inserimento del messaggio
3568 \item[\errcode{EINVAL}] si è specificato un valore nullo per
3569 \param{msg\_len}, o un valore di \param{msg\_prio} fuori dai limiti, o
3570 un valore non valido per \param{abs\_timeout}.
3571 \item[\errcode{ETIMEDOUT}] l'inserimento del messaggio non è stato
3572 effettuato entro il tempo stabilito.
3574 ed inoltre \errval{EBADF} ed \errval{EINTR}.}
3577 Entrambe le funzioni richiedono un puntatore al testo del messaggio
3578 nell'argomento \param{msg\_ptr} e la relativa lunghezza in \param{msg\_len}.
3579 Se quest'ultima eccede la dimensione massima specificata da \var{mq\_msgsize}
3580 le funzioni ritornano immediatamente con un errore di \errcode{EMSGSIZE}.
3582 L'argomento \param{msg\_prio} indica la priorità dell'argomento; i messaggi di
3583 priorità maggiore vengono inseriti davanti a quelli di priorità inferiore (e
3584 quindi saranno riletti per primi). A parità del valore della priorità il
3585 messaggio sarà inserito in coda a tutti quelli con la stessa priorità. Il
3586 valore della priorità non può eccedere il limite di sistema
3587 \const{MQ\_PRIO\_MAX}, che nel caso è pari a 32768.
3589 Qualora la coda sia piena, entrambe le funzioni si bloccano, a meno che non
3590 sia stata selezionata in fase di apertura la modalità non
3591 bloccante,\footnote{o si sia impostato il flag \const{O\_NONBLOCK} sul file
3592 descriptor della coda.} nel qual caso entrambe ritornano \errcode{EAGAIN}.
3593 La sola differenza fra le due funzioni è che la seconda, passato il tempo
3594 massimo impostato con l'argomento \param{abs\_timeout},\footnote{deve essere
3595 specificato un tempo assoluto tramite una struttura \struct{timespec} (vedi
3596 fig.~\ref{fig:sys_timeval_struct}) indicato in numero di secondi e
3597 nanosecondi a partire dal 1 gennaio 1970.} ritorna comunque con un errore di
3598 \errcode{ETIMEDOUT}, se invece il tempo è già scaduto al momento della
3599 chiamata e la coda è vuota la funzione ritorna immediatamente.
3601 Come per l'inserimento, anche per l'estrazione dei messaggi da una coda sono
3602 previste due funzioni, \funcd{mq\_receive} e \funcd{mq\_timedreceive}, i cui
3607 \funcdecl{ssize\_t mq\_receive(mqd\_t mqdes, char *msg\_ptr, size\_t
3608 msg\_len, unsigned int *msg\_prio)}
3609 Effettua la ricezione di un messaggio da una coda.
3611 \funcdecl{ssize\_t mq\_timedreceive(mqd\_t mqdes, char *msg\_ptr, size\_t
3612 msg\_len, unsigned int *msg\_prio, const struct timespec *abs\_timeout)}
3613 Effettua la ricezione di un messaggio da una coda entro il tempo
3614 \param{abs\_timeout}.
3616 \bodydesc{Le funzioni restituiscono il numero di byte del messaggio in caso
3617 di successo e -1 in caso di errore; nel quel caso \var{errno} assumerà i
3620 \item[\errcode{EAGAIN}] si è aperta la coda con \const{O\_NONBLOCK}, e la
3622 \item[\errcode{EMSGSIZE}] la lunghezza del messaggio sulla coda eccede il
3623 valore \param{msg\_len} specificato per la ricezione.
3624 \item[\errcode{EINVAL}] si è specificato un valore nullo per
3625 \param{msg\_ptr}, o un valore non valido per \param{abs\_timeout}.
3626 \item[\errcode{ETIMEDOUT}] la ricezione del messaggio non è stata
3627 effettuata entro il tempo stabilito.
3629 ed inoltre \errval{EBADF}, \errval{EINTR}, \errval{ENOMEM}, o
3633 La funzione estrae dalla coda il messaggio a priorità più alta, o il più
3634 vecchio fra quelli della stessa priorità. Una volta ricevuto il messaggio
3635 viene tolto dalla coda e la sua dimensione viene restituita come valore di
3636 ritorno.\footnote{si tenga presente che 0 è una dimensione valida e che la
3637 condizione di errore è restituita dal valore -1; Stevens in \cite{UNP2} fa
3638 notare che questo è uno dei casi in cui vale ciò che lo standard
3639 \textsl{non} dice, una dimensione nulla infatti, pur non essendo citata, non
3642 Se la dimensione specificata da \param{msg\_len} non è sufficiente a contenere
3643 il messaggio, entrambe le funzioni, al contrario di quanto avveniva nelle code
3644 di messaggi di SysV, ritornano un errore di \errcode{EMSGSIZE} senza estrarre
3645 il messaggio. È pertanto opportuno eseguire sempre una chiamata a
3646 \func{mq\_getaddr} prima di eseguire una ricezione, in modo da ottenere la
3647 dimensione massima dei messaggi sulla coda, per poter essere in grado di
3648 allocare dei buffer sufficientemente ampi per la lettura.
3650 Se si specifica un puntatore per l'argomento \param{msg\_prio} il valore della
3651 priorità del messaggio viene memorizzato all'indirizzo da esso indicato.
3652 Qualora non interessi usare la priorità dei messaggi si può specificare
3653 \var{NULL}, ed usare un valore nullo della priorità nelle chiamate a
3656 Si noti che con le code di messaggi POSIX non si ha la possibilità di
3657 selezionare quale messaggio estrarre con delle condizioni sulla priorità, a
3658 differenza di quanto avveniva con le code di messaggi di SysV che permettono
3659 invece la selezione in base al valore del campo \var{mtype}.
3661 % TODO inserire i dati di /proc/sys/fs/mqueue
3663 Qualora la coda sia vuota entrambe le funzioni si bloccano, a meno che non si
3664 sia selezionata la modalità non bloccante; in tal caso entrambe ritornano
3665 immediatamente con l'errore \errcode{EAGAIN}. Anche in questo caso la sola
3666 differenza fra le due funzioni è che la seconda non attende indefinitamente e
3667 passato il tempo massimo \param{abs\_timeout} ritorna comunque con un errore
3668 di \errcode{ETIMEDOUT}.
3670 Uno dei problemi sottolineati da Stevens in \cite{UNP2}, comuni ad entrambe le
3671 tipologie di code messaggi, è che non è possibile per chi riceve identificare
3672 chi è che ha inviato il messaggio, in particolare non è possibile sapere da
3673 quale utente esso provenga. Infatti, in mancanza di un meccanismo interno al
3674 kernel, anche se si possono inserire delle informazioni nel messaggio, queste
3675 non possono essere credute, essendo completamente dipendenti da chi lo invia.
3676 Vedremo però come, attraverso l'uso del meccanismo di notifica, sia possibile
3677 superare in parte questo problema.
3679 Una caratteristica specifica delle code di messaggi POSIX è la possibilità di
3680 usufruire di un meccanismo di notifica asincrono; questo può essere attivato
3681 usando la funzione \funcd{mq\_notify}, il cui prototipo è:
3682 \begin{prototype}{mqueue.h}
3683 {int mq\_notify(mqd\_t mqdes, const struct sigevent *notification)}
3685 Attiva il meccanismo di notifica per la coda \param{mqdes}.
3687 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
3688 errore; nel quel caso \var{errno} assumerà i valori:
3690 \item[\errcode{EBUSY}] c'è già un processo registrato per la notifica.
3691 \item[\errcode{EBADF}] il descrittore non fa riferimento ad una coda di
3696 Il meccanismo di notifica permette di segnalare in maniera asincrona ad un
3697 processo la presenza di dati sulla coda, in modo da evitare la necessità di
3698 bloccarsi nell'attesa. Per far questo un processo deve registrarsi con la
3699 funzione \func{mq\_notify}, ed il meccanismo è disponibile per un solo
3700 processo alla volta per ciascuna coda.
3702 Il comportamento di \func{mq\_notify} dipende dal valore dell'argomento
3703 \param{notification}, che è un puntatore ad una apposita struttura
3704 \struct{sigevent}, (definita in fig.~\ref{fig:file_sigevent}) introdotta dallo
3705 standard POSIX.1b per gestire la notifica di eventi; per altri dettagli si può
3706 vedere quanto detto in sez.~\ref{sec:file_asyncronous_io} a proposito dell'uso
3707 della stessa struttura per l'invio dei segnali usati per l'I/O asincrono.
3709 Attraverso questa struttura si possono impostare le modalità con cui viene
3710 effettuata la notifica; in particolare il campo \var{sigev\_notify} deve
3711 essere posto a \const{SIGEV\_SIGNAL}\footnote{il meccanismo di notifica basato
3712 sui thread, specificato tramite il valore \const{SIGEV\_THREAD}, non è
3713 implementato.} ed il campo \var{sigev\_signo} deve indicare il valore del
3714 segnale che sarà inviato al processo. Inoltre il campo \var{sigev\_value} è il
3715 puntatore ad una struttura \struct{sigval\_t} (definita in
3716 fig.~\ref{fig:sig_sigval}) che permette di restituire al gestore del segnale un
3717 valore numerico o un indirizzo,\footnote{per il suo uso si riveda la
3718 trattazione fatta in sez.~\ref{sec:sig_real_time} a proposito dei segnali
3719 real-time.} posto che questo sia installato nella forma estesa vista in
3720 sez.~\ref{sec:sig_sigaction}.
3722 La funzione registra il processo chiamante per la notifica se
3723 \param{notification} punta ad una struttura \struct{sigevent} opportunamente
3724 inizializzata, o cancella una precedente registrazione se è \val{NULL}. Dato
3725 che un solo processo alla volta può essere registrato, la funzione fallisce
3726 con \errcode{EBUSY} se c'è un altro processo già registrato. Si tenga
3727 presente inoltre che alla chiusura del descrittore associato alla coda (e
3728 quindi anche all'uscita del processo) ogni eventuale registrazione di notifica
3729 presente viene cancellata.
3731 La notifica del segnale avviene all'arrivo di un messaggio in una coda vuota
3732 (cioè solo se sulla coda non ci sono messaggi) e se non c'è nessun processo
3733 bloccato in una chiamata a \func{mq\_receive}, in questo caso infatti il
3734 processo bloccato ha la precedenza ed il messaggio gli viene immediatamente
3735 inviato, mentre per il meccanismo di notifica tutto funziona come se la coda
3736 fosse rimasta vuota.
3738 Quando un messaggio arriva su una coda vuota al processo che si era registrato
3739 viene inviato il segnale specificato da \code{notification->sigev\_signo}, e
3740 la coda diventa disponibile per una ulteriore registrazione. Questo comporta
3741 che se si vuole mantenere il meccanismo di notifica occorre ripetere la
3742 registrazione chiamando nuovamente \func{mq\_notify} all'interno del gestore
3743 del segnale di notifica. A differenza della situazione simile che si aveva con
3744 i segnali non affidabili,\footnote{l'argomento è stato affrontato in
3745 \ref{sec:sig_semantics}.} questa caratteristica non configura una
3746 race-condition perché l'invio di un segnale avviene solo se la coda è vuota;
3747 pertanto se si vuole evitare di correre il rischio di perdere eventuali
3748 ulteriori segnali inviati nel lasso di tempo che occorre per ripetere la
3749 richiesta di notifica basta avere cura di eseguire questa operazione prima di
3750 estrarre i messaggi presenti dalla coda.
3752 L'invio del segnale di notifica avvalora alcuni campi di informazione
3753 restituiti al gestore attraverso la struttura \struct{siginfo\_t} (definita in
3754 fig.~\ref{fig:sig_siginfo_t}). In particolare \var{si\_pid} viene impostato al
3755 valore del \acr{pid} del processo che ha emesso il segnale, \var{si\_uid}
3756 all'userid effettivo, \var{si\_code} a \const{SI\_MESGQ}, e \var{si\_errno} a
3757 0. Questo ci dice che, se si effettua la ricezione dei messaggi usando
3758 esclusivamente il meccanismo di notifica, è possibile ottenere le informazioni
3759 sul processo che ha inserito un messaggio usando un gestore per il segnale in
3760 forma estesa.\footnote{di nuovo si faccia riferimento a quanto detto al
3761 proposito in sez.~\ref{sec:sig_sigaction} e sez.~\ref{sec:sig_real_time}.}
3765 \subsection{Memoria condivisa}
3766 \label{sec:ipc_posix_shm}
3768 La memoria condivisa è stato il primo degli oggetti di IPC POSIX inserito nel
3769 kernel ufficiale; il supporto a questo tipo di oggetti è realizzato attraverso
3770 il filesystem \texttt{tmpfs}, uno speciale filesystem che mantiene tutti i
3771 suoi contenuti in memoria,\footnote{il filesystem \texttt{tmpfs} è diverso da
3772 un normale RAM disk, anch'esso disponibile attraverso il filesystem
3773 \texttt{ramfs}, proprio perché realizza una interfaccia utilizzabile anche
3774 per la memoria condivisa; esso infatti non ha dimensione fissa, ed usa
3775 direttamente la cache interna del kernel (che viene usata anche per la
3776 shared memory in stile SysV). In più i suoi contenuti, essendo trattati
3777 direttamente dalla memoria virtuale \index{memoria~virtuale} possono essere
3778 salvati sullo swap automaticamente.} che viene attivato abilitando l'opzione
3779 \texttt{CONFIG\_TMPFS} in fase di compilazione del kernel.
3782 Per potere utilizzare l'interfaccia POSIX per la memoria condivisa le
3783 \acr{glibc}\footnote{le funzioni sono state introdotte con le glibc-2.2.}
3784 richiedono di compilare i programmi con l'opzione \code{-lrt}; inoltre è
3785 necessario che in \file{/dev/shm} sia montato un filesystem \texttt{tmpfs};
3786 questo di norma viene fatto aggiungendo una riga del tipo di:
3788 tmpfs /dev/shm tmpfs defaults 0 0
3790 ad \conffile{/etc/fstab}. In realtà si può montare un filesystem \texttt{tmpfs}
3791 dove si vuole, per usarlo come RAM disk, con un comando del tipo:
3793 mount -t tmpfs -o size=128M,nr_inodes=10k,mode=700 tmpfs /mytmpfs
3796 Il filesystem riconosce, oltre quelle mostrate, le opzioni \texttt{uid} e
3797 \texttt{gid} che identificano rispettivamente utente e gruppo cui assegnarne
3798 la titolarità, e \texttt{nr\_blocks} che permette di specificarne la
3799 dimensione in blocchi, cioè in multipli di \const{PAGECACHE\_SIZE} che in
3800 questo caso è l'unità di allocazione elementare.
3802 La funzione che permette di aprire un segmento di memoria condivisa POSIX, ed
3803 eventualmente di crearlo se non esiste ancora, è \funcd{shm\_open}; il suo
3805 \begin{prototype}{mqueue.h}
3806 {int shm\_open(const char *name, int oflag, mode\_t mode)}
3808 Apre un segmento di memoria condivisa.
3810 \bodydesc{La funzione restituisce un file descriptor positivo in caso di
3811 successo e -1 in caso di errore; nel quel caso \var{errno} assumerà gli
3812 stessi valori riportati da \func{open}.}
3815 La funzione apre un segmento di memoria condivisa identificato dal nome
3816 \param{name}. Come già spiegato in sez.~\ref{sec:ipc_posix_generic} questo nome
3817 può essere specificato in forma standard solo facendolo iniziare per \file{/}
3818 e senza ulteriori \file{/}, Linux supporta comunque nomi generici, che
3819 verranno interpretati prendendo come radice \file{/dev/shm}.\footnote{occorre
3820 pertanto evitare di specificare qualcosa del tipo \file{/dev/shm/nome}
3821 all'interno di \param{name}, perché questo comporta, da parte delle funzioni
3822 di libreria, il tentativo di accedere a \file{/dev/shm/dev/shm/nome}.}
3824 La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
3825 possono essere specificati per \param{oflag}, che deve essere specificato come
3826 maschera binaria comprendente almeno uno dei due valori \const{O\_RDONLY} e
3827 \const{O\_RDWR}; i valori possibili per i vari bit sono quelli visti in
3828 tab.~\ref{tab:file_open_flags} dei quali però \func{shm\_open} riconosce solo
3830 \begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
3831 \item[\const{O\_RDONLY}] Apre il file descriptor associato al segmento di
3832 memoria condivisa per l'accesso in sola lettura.
3833 \item[\const{O\_RDWR}] Apre il file descriptor associato al segmento di
3834 memoria condivisa per l'accesso in lettura e scrittura.
3835 \item[\const{O\_CREAT}] Necessario qualora si debba creare il segmento di
3836 memoria condivisa se esso non esiste; in questo caso viene usato il valore
3837 di \param{mode} per impostare i permessi, che devono essere compatibili con
3838 le modalità con cui si è aperto il file.
3839 \item[\const{O\_EXCL}] Se usato insieme a \const{O\_CREAT} fa fallire la
3840 chiamata a \func{shm\_open} se il segmento esiste già, altrimenti esegue la
3841 creazione atomicamente.
3842 \item[\const{O\_TRUNC}] Se il segmento di memoria condivisa esiste già, ne
3843 tronca le dimensioni a 0 byte.
3846 In caso di successo la funzione restituisce un file descriptor associato al
3847 segmento di memoria condiviso con le stesse modalità di
3848 \func{open}\footnote{in realtà, come accennato, \func{shm\_open} è un semplice
3849 wrapper per \func{open}, usare direttamente quest'ultima avrebbe lo stesso
3850 effetto.} viste in sez.~\ref{sec:file_open}; in particolare viene impostato
3851 il flag \const{FD\_CLOEXEC}. Chiamate effettuate da diversi processi usando
3852 lo stesso nome, restituiranno file descriptor associati allo stesso segmento
3853 (così come, nel caso di file di dati, essi sono associati allo stesso
3854 \index{inode} inode). In questo modo è possibile effettuare una chiamata ad
3855 \func{mmap} sul file descriptor restituito da \func{shm\_open} ed i processi
3856 vedranno lo stesso segmento di memoria condivisa.
3858 Quando il nome non esiste il segmento può essere creato specificando
3859 \const{O\_CREAT}; in tal caso il segmento avrà (così come i nuovi file)
3860 lunghezza nulla. Dato che un segmento di lunghezza nulla è di scarsa utilità,
3861 per impostarne la dimensione si deve usare \func{ftruncate} (vedi
3862 sez.~\ref{sec:file_file_size}), prima di mapparlo in memoria con \func{mmap}.
3863 Si tenga presente che una volta chiamata \func{mmap} si può chiudere il file
3864 descriptor (con \func{close}), senza che la mappatura ne risenta.
3867 Come per i file, quando si vuole effettivamente rimuovere segmento di memoria
3868 condivisa, occorre usare la funzione \funcd{shm\_unlink}, il cui prototipo è:
3869 \begin{prototype}{mqueue.h}
3870 {int shm\_unlink(const char *name)}
3872 Rimuove un segmento di memoria condivisa.
3874 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
3875 errore; nel quel caso \var{errno} assumerà gli stessi valori riportati da
3879 La funzione è del tutto analoga ad \func{unlink}, e si limita a cancellare il
3880 nome del segmento da \file{/dev/shm}, senza nessun effetto né sui file
3881 descriptor precedentemente aperti con \func{shm\_open}, né sui segmenti già
3882 mappati in memoria; questi verranno cancellati automaticamente dal sistema
3883 solo con le rispettive chiamate a \func{close} e \func{munmap}. Una volta
3884 eseguita questa funzione però, qualora si richieda l'apertura di un segmento
3885 con lo stesso nome, la chiamata a \func{shm\_open} fallirà, a meno di non aver
3886 usato \const{O\_CREAT}, in quest'ultimo caso comunque si otterrà un file
3887 descriptor che fa riferimento ad un segmento distinto da eventuali precedenti.
3889 \begin{figure}[!htb]
3890 \footnotesize \centering
3891 \begin{minipage}[c]{15.6cm}
3892 \includecodesample{listati/MemShared.c}
3895 \caption{Il codice delle funzioni di gestione dei segmenti di memoria
3897 \label{fig:ipc_posix_shmmem}
3900 Come esempio per l'uso di queste funzioni vediamo come è possibile riscrivere
3901 una interfaccia semplificata analoga a quella vista in
3902 fig.~\ref{fig:ipc_sysv_shm_func} per la memoria condivisa in stile SysV. Il
3903 codice, riportato in fig.~\ref{fig:ipc_posix_shmmem}, è sempre contenuto nel
3904 file \file{SharedMem.c} dei sorgenti allegati.
3906 La prima funzione (\texttt{\small 1--24}) è \func{CreateShm} che, dato un nome
3907 nell'argomento \var{name} crea un nuovo segmento di memoria condivisa,
3908 accessibile in lettura e scrittura, e ne restituisce l'indirizzo. Anzitutto si
3909 definiscono (\texttt{\small 8}) i flag per la successiva (\texttt{\small 9})
3910 chiamata a \func{shm\_open}, che apre il segmento in lettura e scrittura
3911 (creandolo se non esiste, ed uscendo in caso contrario) assegnandogli sul
3912 filesystem i permessi specificati dall'argomento \var{perm}. In caso di errore
3913 (\texttt{\small 10--12}) si restituisce un puntatore nullo, altrimenti si
3914 prosegue impostando (\texttt{\small 14}) la dimensione del segmento con
3915 \func{ftruncate}. Di nuovo (\texttt{\small 15--16}) si esce immediatamente
3916 restituendo un puntatore nullo in caso di errore. Poi si passa (\texttt{\small
3917 18}) a mappare in memoria il segmento con \func{mmap} specificando dei
3918 diritti di accesso corrispondenti alla modalità di apertura. Di nuovo si
3919 restituisce (\texttt{\small 19--21}) un puntatore nullo in caso di errore,
3920 altrimenti si inizializza (\texttt{\small 22}) il contenuto del segmento al
3921 valore specificato dall'argomento \var{fill} con \func{memset}, e se ne
3922 restituisce (\texttt{\small 23}) l'indirizzo.
3924 La seconda funzione (\texttt{\small 25--40}) è \func{FindShm} che trova un
3925 segmento di memoria condiviso già esistente, restituendone l'indirizzo. In
3926 questo caso si apre (\texttt{\small 31}) il segmento con \func{shm\_open}
3927 richiedendo che il segmento sia già esistente, in caso di errore
3928 (\texttt{\small 31--33}) si ritorna immediatamente un puntatore nullo.
3929 Ottenuto il file descriptor del segmento lo si mappa (\texttt{\small 35}) in
3930 memoria con \func{mmap}, restituendo (\texttt{\small 36--38}) un puntatore
3931 nullo in caso di errore, o l'indirizzo (\texttt{\small 39}) dello stesso in
3934 La terza funzione (\texttt{\small 40--45}) è \func{RemoveShm}, e serve a
3935 cancellare un segmento di memoria condivisa. Dato che al contrario di quanto
3936 avveniva con i segmenti del SysV IPC gli oggetti allocati nel kernel vengono
3937 rilasciati automaticamente quando nessuna li usa più, tutto quello che c'è da
3938 fare (\texttt{\small 44}) in questo caso è chiamare \func{shm\_unlink},
3939 restituendo al chiamante il valore di ritorno.
3944 \subsection{Semafori}
3945 \label{sec:ipc_posix_sem}
3947 Fino alla serie 2.4.x del kernel esisteva solo una implementazione parziale
3948 dei semafori POSIX che li realizzava solo a livello di thread e non di
3949 processi,\footnote{questo significava che i semafori erano visibili solo
3950 all'interno dei thread creati da un singolo processo, e non potevano essere
3951 usati come meccanismo di sincronizzazione fra processi diversi.} fornita
3952 attraverso la sezione delle estensioni \textit{real-time} delle
3953 \acr{glibc}.\footnote{quelle che si accedono collegandosi alla libreria
3954 \texttt{librt}.} Esisteva inoltre una libreria che realizzava (parzialmente)
3955 l'interfaccia POSIX usando le funzioni dei semafori di SysV IPC (mantenendo
3956 così tutti i problemi sottolineati in sez.~\ref{sec:ipc_sysv_sem}).
3958 A partire dal kernel 2.5.7 è stato introdotto un meccanismo di
3959 sincronizzazione completamente nuovo, basato sui cosiddetti
3960 \textit{futex},\footnote{la sigla sta per \textit{fast user mode mutex}.} con
3961 il quale è stato possibile implementare una versione nativa dei semafori
3962 POSIX. Grazie a questo con i kernel della serie 2.6 e le nuove versioni delle
3963 \acr{glibc} che usano questa nuova infrastruttura per quella che viene quella
3964 che viene chiamata \textit{New Posix Thread Library}, sono state implementate
3965 anche tutte le funzioni dell'interfaccia dei semafori POSIX.
3967 Anche in questo caso è necessario appoggiarsi alla libreria per le estensioni
3968 \textit{real-time} \texttt{librt}, questo significa che se si vuole utilizzare
3969 questa interfaccia, oltre ad utilizzare gli opportuni file di definizione,
3970 occorrerà compilare i programmi con l'opzione \texttt{-lrt}.
3972 La funzione che permette di creare un nuovo semaforo POSIX, creando il
3973 relativo file, o di accedere ad uno esistente, è \funcd{sem\_open}, questa
3974 prevede due forme diverse a seconda che sia utilizzata per aprire un semaforo
3975 esistente o per crearne uno nuovi, i relativi prototipi sono:
3977 \headdecl{semaphore.h}
3979 \funcdecl{sem\_t *sem\_open(const char *name, int oflag)}
3981 \funcdecl{sem\_t *sem\_open(const char *name, int oflag, mode\_t mode,
3982 unsigned int value)}
3984 Crea un semaforo o ne apre uno esistente.
3986 \bodydesc{La funzione restituisce l'indirizzo del semaforo in caso di
3987 successo e \const{SEM\_FAILED} in caso di errore; nel quel caso
3988 \var{errno} assumerà i valori:
3990 \item[\errcode{EACCESS}] il semaforo esiste ma non si hanno permessi
3991 sufficienti per accedervi.
3992 \item[\errcode{EEXIST}] si sono specificati \const{O\_CREAT} e
3993 \const{O\_EXCL} ma il semaforo esiste.
3994 \item[\errcode{EINVAL}] il valore di \param{value} eccede
3995 \const{SEM\_VALUE\_MAX}.
3996 \item[\errcode{ENAMETOOLONG}] si è utilizzato un nome troppo lungo.
3997 \item[\errcode{ENOENT}] non si è usato \const{O\_CREAT} ed il nome
3998 specificato non esiste.
4000 ed inoltre \errval{ENFILE} ed \errval{ENOMEM}.}
4003 L'argomento \param{name} definisce il nome del semaforo che si vuole
4004 utilizzare, ed è quello che permette a processi diversi di accedere allo
4005 stesso semaforo. Questo deve essere specificato con un pathname nella forma
4006 \texttt{/qualchenome}, che non ha una corrispondenza diretta con un pathname
4007 reale; con Linux infatti i file associati ai semafori sono mantenuti nel
4008 filesystem virtuale \texttt{/dev/shm}, e gli viene assegnato automaticamente
4009 un nome nella forma \texttt{sem.qualchenome}.\footnote{si ha cioè una
4010 corrispondenza per cui \texttt{/qualchenome} viene rimappato, nella
4011 creazione tramite \func{sem\_open}, su \texttt{/dev/shm/sem.qualchenome}.}
4013 L'argomento \param{oflag} è quello che controlla le modalità con cui opera la
4014 funzione, ed è passato come maschera binaria; i bit corrispondono a quelli
4015 utilizzati per l'analogo argomento di \func{open}, anche se dei possibili
4016 valori visti in sez.~\ref{sec:file_open} sono utilizzati soltanto
4017 \const{O\_CREAT} e \const{O\_EXCL}.
4019 Se si usa \const{O\_CREAT} si richiede la creazione del semaforo qualora
4020 questo non esista, ed in tal caso occorre utilizzare la seconda forma della
4021 funzione, in cui si devono specificare sia un valore iniziale con l'argomento
4022 \param{value},\footnote{e si noti come così diventa possibile, differenza di
4023 quanto avviene per i semafori del \textit{SysV IPC}, effettuare in maniera
4024 atomica creazione ed inizializzazione di un semaforo usando una unica
4025 funzione.} che una maschera dei permessi con l'argomento
4026 \param{mode};\footnote{anche questo argomento prende gli stessi valori
4027 utilizzati per l'analogo di \func{open}, che si sono illustrati in dettaglio
4028 sez.~\ref{sec:file_perm_overview}.} questi verranno assegnati al semaforo
4029 appena creato. Se il semaforo esiste già i suddetti valori saranno invece
4030 ignorati. Usando il flag \const{O\_EXCL} si richiede invece la verifica che il
4031 semaforo non esiste, usandolo insieme ad \const{O\_CREAT} la funzione fallisce
4032 qualora un semaforo con lo stesso nome sia già presente.
4034 La funzione restituisce in caso di successo un puntatore all'indirizzo del
4035 semaforo con un valore di tipo \ctyp{sem\_t *}, è questo valore che dovrà
4036 essere passato alle altre funzioni per operare sul semaforo stesso. Si tenga
4037 presente che, come accennato in sez.~\ref{sec:ipc_posix_generic}, i semafori
4038 usano la semantica standard dei file per quanto riguarda i controlli di
4041 Questo significa che un nuovo semaforo viene sempre creato con l'user-ID ed il
4042 group-ID effettivo del processo chiamante, e che i permessi indicati con
4043 \param{mode} vengono filtrati dal valore della \textit{umask} del processo.
4044 Inoltre per poter aprire un semaforo è necessario avere su di esso sia il
4045 permesso di lettura che quello di scrittura.
4047 Una volta che si sia ottenuto l'indirizzo di un semaforo, sarà possibile
4048 utilizzarlo; se si ricorda quanto detto all'inizio di
4049 sez.~\ref{sec:ipc_sysv_sem}, dove si sono introdotti i concetti generali
4050 relativi ai semafori, le operazioni principali sono due, quella che richiede
4051 l'uso di una risorsa bloccando il semaforo e quella che rilascia la risorsa
4052 liberando il semaforo. La prima operazione è effettuata dalla funzione
4053 \funcd{sem\_wait}, il cui prototipo è:
4055 \headdecl{semaphore.h}
4057 \funcdecl{int sem\_wait(sem\_t *sem)}
4059 Blocca il semaforo \param{sem}.
4061 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
4062 errore; nel quel caso \var{errno} assumerà i valori:
4064 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
4065 \item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
4070 La funzione cerca di decrementare il valore del semaforo indicato dal
4071 puntatore \param{sem}, se questo ha un valore positivo, cosa che significa che
4072 la risorsa è disponibile, la funzione ha successo, il valore del semaforo
4073 viene diminuito di 1 ed essa ritorna immediatamente; se il valore è nullo la
4074 funzione si blocca fintanto che il valore del semaforo non torni
4075 positivo\footnote{ovviamente per opera di altro processo che lo rilascia
4076 chiamando \func{sem\_post}.} così che poi essa possa decrementarlo con
4077 successo e proseguire.
4079 Si tenga presente che la funzione può sempre essere interrotta da un segnale
4080 (nel qual caso si avrà un errore di \const{EINTR}) e che questo avverrà
4081 comunque, anche se si è richiesta la semantica BSD installando il relativo
4082 gestore con \const{SA\_RESTART} (vedi sez.~\ref{sec:sig_sigaction}) per
4083 riavviare le system call interrotte.
4085 Della funzione \func{sem\_wait} esistono due varianti che consentono di
4086 gestire diversamente le modalità di attesa in caso di risorsa occupata, la
4087 prima di queste è \funcd{sem\_trywait}, che serve ad effettuare un tentativo
4088 di acquisizione senza bloccarsi; il suo prototipo è:
4090 \headdecl{semaphore.h}
4092 \funcdecl{int sem\_trywait(sem\_t *sem)}
4094 Tenta di bloccare il semaforo \param{sem}.
4096 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
4097 errore; nel quel caso \var{errno} assumerà gli stessi valori:
4099 \item[\errcode{EAGAIN}] il semaforo non può essere acquisito senza
4101 \item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
4106 La funzione è identica a \func{sem\_wait} ed se la risorsa è libera ha lo
4107 stesso effetto, vale a dire che in caso di semaforo diverso da zero la
4108 funzione lo decrementa e ritorna immediatamente; la differenza è che nel caso
4109 in cui il semaforo è occupato essa non si blocca e di nuovo ritorna
4110 immediatamente, restituendo però un errore di \errval{EAGAIN}, così che il
4111 programma possa proseguire.
4113 La seconda variante di \func{sem\_wait} è una estensione specifica che può
4114 essere utilizzata soltanto se viene definita la macro \macro{\_XOPEN\_SOURCE}
4115 ad un valore di 600 prima di includere \texttt{semaphore.h}, la funzione è
4116 \func{sem\_timedwait}, ed il suo prototipo è:
4118 \headdecl{semaphore.h}
4120 \funcdecl{int sem\_timedwait(sem\_t *sem, const struct timespec
4123 Blocca il semaforo \param{sem}.
4125 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
4126 errore; nel quel caso \var{errno} assumerà gli stessi valori:
4128 \item[\errcode{ETIMEDOUT}] è scaduto il tempo massimo di attesa.
4129 \item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
4130 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
4135 Anche in questo caso il comportamento della funzione è identico a quello di
4136 \func{sem\_wait}, la sola differenza consiste nel fatto che con questa
4137 funzione è possibile impostare tramite l'argomento \param{abs\_timeout} un
4138 tempo limite per l'attesa, scaduto il quale la funzione ritorna comunque,
4139 anche se non è possibile acquisire il semaforo. In tal caso la funzione
4140 fallirà, riportando un errore di \errval{ETIMEDOUT}.
4142 La seconda funzione principale utilizzata per l'uso dei semafori è
4143 \funcd{sem\_post}, che viene usata per rilasciare un semaforo occupato o, in
4144 generale, per aumentare di una unità il valore dello stesso anche qualora non
4145 fosse occupato;\footnote{si ricordi che in generale un semaforo viene usato
4146 come indicatore di un numero di risorse disponibili.} il suo prototipo è:
4148 \headdecl{semaphore.h}
4150 \funcdecl{int sem\_post(sem\_t *sem)}
4152 Rilascia il semaforo \param{sem}.
4154 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
4155 errore; nel quel caso \var{errno} assumerà i valori:
4157 \item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
4162 La funzione incrementa di uno il valore corrente del semaforo indicato
4163 dall'argomento \param{sem}, se questo era nullo la relativa risorsa risulterà
4164 sbloccata, cosicché un altro processo (o thread) eventualmente bloccato in una
4165 \func{sem\_wait} sul semaforo potrà essere svegliato e rimesso in esecuzione.
4166 Si tenga presente che la funzione è sicura \index{funzioni~sicure} per l'uso
4167 all'interno di un gestore di segnali (si ricordi quanto detto in
4168 sez.~\ref{sec:sig_signal_handler}).
4170 Se invece di operare su un semaforo se ne vuole solamente leggere il valore,
4171 si può usare la funzione \funcd{sem\_getvalue}, il cui prototipo è:
4173 \headdecl{semaphore.h}
4175 \funcdecl{int sem\_getvalue(sem\_t *sem, int *sval)}
4177 Richiede il valore del semaforo \param{sem}.
4179 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
4180 errore; nel quel caso \var{errno} assumerà i valori:
4182 \item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
4187 La funzione legge il valore del semaforo indicato dall'argomento \param{sem} e
4188 lo restituisce nella variabile intera puntata dall'argomento
4189 \param{sval}. Qualora ci siano uno o più processi bloccati in attesa sul
4190 semaforo lo standard prevede che la funzione possa restituire un valore nullo
4191 oppure il numero di processi bloccati in una \func{sem\_wait} sul suddetto
4192 semaforo; nel caso di Linux vale la prima opzione.
4194 Questa funzione può essere utilizzata per avere un suggerimento sullo stato di
4195 un semaforo, ovviamente non si può prendere il risultato riportato in
4196 \param{sval} che come indicazione, il valore del semaforo infatti potrebbe
4197 essere già stato modificato al ritorno della funzione.
4199 % TODO verificare comportamento sem_getvalue
4201 Una volta che non ci sia più la necessità di operare su un semaforo se ne può
4202 terminare l'uso con la funzione \funcd{sem\_close}, il cui prototipo è:
4204 \headdecl{semaphore.h}
4206 \funcdecl{int sem\_close(sem\_t *sem)}
4208 Chiude il semaforo \param{sem}.
4210 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
4211 errore; nel quel caso \var{errno} assumerà i valori:
4213 \item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
4218 La funzione chiude il semaforo indicato dall'argomento \param{sem}; questo
4219 comporta che tutte le risorse che il sistema può avere assegnato al processo
4220 nell'uso dello stesso vengono rilasciate. Questo significa che un altro
4221 processo bloccato sul semaforo a causa della acquisizione da parte del
4222 processo che chiama \func{sem\_close} potrà essere riavviato.
4224 Si tenga presente poi che come per i file all'uscita di un processo tutti i
4225 semafori che questo aveva aperto vengono automaticamente chiusi; questo
4226 comportamento risolve il problema che si aveva con i semafori del \textit{SysV
4227 IPC} (di cui si è parlato in sez.~\ref{sec:ipc_sysv_sem}) per i quali le
4228 risorse possono restare bloccate. Si tenga poi presente che, a differenza di
4229 quanto avviene per i file, in caso di una chiamata ad \func{execve} tutti i
4230 semafori vengono chiusi automaticamente.
4232 Come per i semafori del \textit{SysV IPC} anche quelli POSIX hanno una
4233 persistenza di sistema; questo significa che una volta che si è creato un
4234 semaforo con \func{sem\_open} questo continuerà ad esistere fintanto che il
4235 kernel resta attivo (vale a dire fino ad un successivo riavvio) a meno che non
4236 lo si cancelli esplicitamente. Per far questo si può utilizzare la funzione
4237 \funcd{sem\_unlink}, il cui prototipo è:
4239 \headdecl{semaphore.h}
4241 \funcdecl{int sem\_unlink(const char *name)}
4243 Rimuove il semaforo \param{name}.
4245 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
4246 errore; nel quel caso \var{errno} assumerà i valori:
4248 \item[\errcode{EACCESS}] non si hanno i permessi necessari a cancellare il
4250 \item[\errcode{ENAMETOOLONG}] il nome indicato è troppo lungo.
4251 \item[\errcode{ENOENT}] il semaforo \param{name} non esiste.
4256 La funzione rimuove il semaforo indicato dall'argomento \param{name}, che
4257 prende un valore identico a quello usato per creare il semaforo stesso con
4258 \func{sem\_open}. Il semaforo viene rimosso dal filesystem immediatamente; ma
4259 il semaforo viene effettivamente cancellato dal sistema soltanto quando tutti
4260 i processi che lo avevano aperto lo chiudono. Si segue cioè la stessa
4261 semantica usata con \func{unlink} per i file, trattata in dettaglio in
4262 sez.~\ref{sec:file_link}.
4264 Una delle caratteristiche peculiari dei semafori POSIX è che questi possono
4265 anche essere utilizzati anche in forma anonima, senza necessità di fare
4266 ricorso ad un nome sul filesystem o ad altri indicativi. In questo caso si
4267 dovrà porre la variabile che contiene l'indirizzo del semaforo in un tratto di
4268 memoria che sia accessibile a tutti i processi in gioco. La funzione che
4269 consente di inizializzare un semaforo anonimo è \funcd{sem\_init}, il cui
4272 \headdecl{semaphore.h}
4274 \funcdecl{int sem\_init(sem\_t *sem, int pshared, unsigned int value)}
4276 Inizializza il semaforo anonimo \param{sem}.
4278 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
4279 errore; nel quel caso \var{errno} assumerà i valori:
4281 \item[\errcode{EINVAL}] il valore di \param{value} eccede
4282 \const{SEM\_VALUE\_MAX}.
4283 \item[\errcode{ENOSYS}] il valore di \param{pshared} non è nullo ed il
4284 sistema non supporta i semafori per i processi.
4289 La funzione inizializza un semaforo all'indirizzo puntato dall'argomento
4290 \param{sem}, e come per \func{sem\_open} consente di impostare un valore
4291 iniziale con \param{value}. L'argomento \param{pshared} serve ad indicare se
4292 il semaforo deve essere utilizzato dai \itindex{thread} thread di uno stesso
4293 processo (con un valore nullo) o condiviso fra processi diversi (con un valore
4296 Qualora il semaforo debba essere condiviso dai \itindex{thread} thread di uno
4297 stesso processo (nel qual caso si parla di \textit{thread-shared semaphore}),
4298 occorrerà che \param{sem} sia l'indirizzo di una variabile visibile da tutti i
4299 \itindex{thread} thread, si dovrà usare cioè una variabile globale o una
4300 variabile allocata dinamicamente nello \itindex{heap} heap.
4302 Qualora il semaforo debba essere condiviso fra più processi (nel qual caso si
4303 parla di \textit{process-shared semaphore}) la sola scelta possibile per
4304 renderlo visibile a tutti è di porlo in un tratto di memoria condivisa. Questo
4305 potrà essere ottenuto direttamente sia con \func{shmget} (vedi
4306 sez.~\ref{sec:ipc_sysv_shm}) che con \func{shm\_open} (vedi
4307 sez.~\ref{sec:ipc_posix_shm}), oppure, nel caso che tutti i processi in gioco
4308 abbiano un genitore comune, con una mappatura anonima con \func{mmap} (vedi
4309 sez.~\ref{sec:file_memory_map}),\footnote{si ricordi che i tratti di memoria
4310 condivisa vengono mantenuti nei processi figli attraverso la funzione
4311 \func{fork}.} a cui essi poi potranno accedere.
4313 Una volta inizializzato il semaforo anonimo con \func{sem\_init} lo si potrà
4314 utilizzare nello stesso modo dei semafori normali con \func{sem\_wait} e
4315 \func{sem\_post}. Si tenga presente però che inizializzare due volte lo stesso
4316 semaforo può dar luogo ad un comportamento indefinito.
4319 Una volta che non si indenda più utilizzare un semaforo anonimo questo può
4320 essere eliminato da sistema; per far questo di deve utilizzare una apposita
4321 funzione, \funcd{sem\_destroy}, il cui prototipo è:
4323 \headdecl{semaphore.h}
4325 \funcdecl{int sem\_destroy(sem\_t *sem)}
4327 Elimina il semaforo anonimo \param{sem}.
4329 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
4330 errore; nel quel caso \var{errno} assumerà i valori:
4332 \item[\errcode{EINVAL}] il valore di \param{value} eccede
4333 \const{SEM\_VALUE\_MAX}.
4338 La funzione prende come unico argomento l'indirizzo di un semaforo che deve
4339 essere stato inizializzato con \func{sem\_init}; non deve quindi essere
4340 applicata a semafori creati con \func{sem\_open}. Inoltre si deve essere
4341 sicuri che il semaforo sia effettivamente inutilizzato, la distruzione di un
4342 semaforo su cui sono presenti processi (o thread) in attesa (cioè bloccati in
4343 una \func{sem\_wait}) provoca un comportamento indefinito.
4345 Si tenga presente infine che utilizzare un semaforo che è stato distrutto con
4346 \func{sem\_destroy} di nuovo può dare esito a comportamenti indefiniti. Nel
4347 caso ci si trovi in una tale evenienza occorre reinizializzare il semaforo una
4348 seconda volta con \func{sem\_init}.
4351 % LocalWords: like fifo System POSIX RPC Calls Common Object Request Brocker
4352 % LocalWords: Architecture descriptor kernel unistd int filedes errno EMFILE
4353 % LocalWords: ENFILE EFAULT BUF sez fig fork Stevens siblings EOF read SIGPIPE
4354 % LocalWords: EPIPE shell CGI Gateway Interface HTML JPEG URL mime type gs dup
4355 % LocalWords: barcode PostScript race condition stream BarCodePage WriteMess
4356 % LocalWords: size PS switch wait popen pclose stdio const char command NULL
4357 % LocalWords: EINVAL cap fully buffered Ghostscript l'Encapsulated epstopsf of
4358 % LocalWords: PDF EPS lseek ESPIPE PPM Portable PixMap format pnmcrop PNG pnm
4359 % LocalWords: pnmmargin png BarCode inode filesystem l'inode mknod mkfifo RDWR
4360 % LocalWords: ENXIO deadlock client reinviate fortunes fortunefilename daemon
4361 % LocalWords: FortuneServer FortuneParse FortuneClient pid libgapil LD librt
4362 % LocalWords: PATH linker pathname ps tmp killall fortuned crash socket domain
4363 % LocalWords: socketpair BSD sys protocol sv EAFNOSUPPORT EPROTONOSUPPORT AF
4364 % LocalWords: EOPNOTSUPP SOCK SysV IPC Process Comunication ipc perm key exec
4365 % LocalWords: header ftok proj stat libc SunOS glibc XPG dell'inode number uid
4366 % LocalWords: cuid cgid gid tab MSG shift group umask seq MSGMNI SEMMNI SHMMNI
4367 % LocalWords: shmmni msgmni sem sysctl IPCMNI IPCTestId msgget EACCES EEXIST
4368 % LocalWords: CREAT EXCL EIDRM ENOENT ENOSPC ENOMEM novo proc MSGMAX msgmax ds
4369 % LocalWords: MSGMNB msgmnb linked list msqid msgid linux msg qnum lspid lrpid
4370 % LocalWords: rtime ctime qbytes first last cbytes msgctl semctl shmctl ioctl
4371 % LocalWords: cmd struct buf EPERM RMID msgsnd msgbuf msgp msgsz msgflg EAGAIN
4372 % LocalWords: NOWAIT EINTR mtype mtext long message sizeof LENGTH ts sleep BIG
4373 % LocalWords: msgrcv ssize msgtyp NOERROR EXCEPT ENOMSG multiplexing select ls
4374 % LocalWords: poll polling queue MQFortuneServer write init HandSIGTERM l'IPC
4375 % LocalWords: MQFortuneClient mqfortuned mutex risorse' inter semaphore semget
4376 % LocalWords: nsems SEMMNS SEMMSL semid otime semval sempid semncnt semzcnt nr
4377 % LocalWords: SEMVMX SEMOPM semop SEMMNU SEMUME SEMAEM semnum union semun arg
4378 % LocalWords: ERANGE SETALL SETVAL GETALL array GETNCNT GETPID GETVAL GETZCNT
4379 % LocalWords: sembuf sops unsigned nsops UNDO flg nsop num undo pending semadj
4380 % LocalWords: sleeper scheduler running next semundo MutexCreate semunion lock
4381 % LocalWords: MutexFind wrapper MutexRead MutexLock MutexUnlock unlock locking
4382 % LocalWords: MutexRemove shmget SHMALL SHMMAX SHMMIN shmid shm segsz atime FD
4383 % LocalWords: dtime lpid cpid nattac shmall shmmax SHMLBA SHMSEG EOVERFLOW brk
4384 % LocalWords: memory shmat shmdt void shmaddr shmflg SVID RND RDONLY rounded
4385 % LocalWords: SIGSEGV nattch exit SharedMem ShmCreate memset fill ShmFind home
4386 % LocalWords: ShmRemove DirMonitor DirProp chdir GaPiL shmptr DirScan ipcs NFS
4387 % LocalWords: ComputeValues ReadMonitor touch SIGTERM dirmonitor unlink fcntl
4388 % LocalWords: LockFile UnlockFile CreateMutex FindMutex LockMutex SETLKW GETLK
4389 % LocalWords: UnlockMutex RemoveMutex ReadMutex UNLCK WRLCK RDLCK mapping MAP
4390 % LocalWords: SHARED ANONYMOUS thread patch names strace system call userid Di
4391 % LocalWords: groupid Michal Wronski Krzysztof Benedyczak wrona posix mqueue
4392 % LocalWords: lmqueue gcc mount mqd name oflag attr maxmsg msgsize receive ptr
4393 % LocalWords: send WRONLY NONBLOCK close mqdes EBADF getattr setattr mqstat
4394 % LocalWords: omqstat curmsgs flags timedsend len prio timespec abs EMSGSIZE
4395 % LocalWords: ETIMEDOUT timedreceive getaddr notify sigevent notification l'I
4396 % LocalWords: EBUSY sigev SIGNAL signo value sigval siginfo all'userid MESGQ
4397 % LocalWords: Konstantin Knizhnik futex tmpfs ramfs cache shared swap CONFIG
4398 % LocalWords: lrt blocks PAGECACHE TRUNC CLOEXEC mmap ftruncate munmap FindShm
4399 % LocalWords: CreateShm RemoveShm LIBRARY Library libmqueue FAILED EACCESS
4400 % LocalWords: ENAMETOOLONG qualchenome RESTART trywait XOPEN SOURCE timedwait
4401 % LocalWords: process getvalue sval execve pshared ENOSYS heap
4404 %%% Local Variables:
4406 %%% TeX-master: "gapil"