1 \chapter{La comunicazione fra processi}
5 Uno degli aspetti fondamentali della programmazione in un sistema unix-like è
6 la comunicazione fra processi. In questo capitolo affronteremo solo i
7 meccanismi più elementari che permettono di mettere in comunicazione processi
8 diversi, come quelli tradizionali che coinvolgono \textit{pipe} e
9 \textit{fifo} e i meccanismi di intercomunicazione di System V e quelli POSIX.
11 Tralasceremo invece tutte le problematiche relative alla comunicazione
12 attraverso la rete (e le relative interfacce) che saranno affrontate in
13 dettaglio in un secondo tempo. Non affronteremo neanche meccanismi più
14 complessi ed evoluti come le RPC (\textit{Remote Procedure Calls}) e CORBA
15 (\textit{Common Object Request Brocker Architecture}) che in genere sono
16 implementati con un ulteriore livello sopra i meccanismi elementari.
19 \section{La comunicazione fra processi tradizionale}
22 Il primo meccanismo di comunicazione fra processi introdotto nei sistemi Unix,
23 è quello delle cosiddette \textit{pipe}; esse costituiscono una delle
24 caratteristiche peculiari del sistema, in particolar modo dell'interfaccia a
25 linea di comando. In questa sezione descriveremo le sue basi, le funzioni che
26 ne gestiscono l'uso e le varie forme in cui si è evoluto.
29 \subsection{Le \textit{pipe} standard}
32 Le \textit{pipe} nascono sostanzialmente con Unix, e sono il primo, e tuttora
33 uno dei più usati, meccanismi di comunicazione fra processi. Si tratta in
34 sostanza di una una coppia di file descriptor\footnote{si tenga presente che
35 le pipe sono oggetti creati dal kernel e non risiedono su disco.} connessi
36 fra di loro in modo che se quanto scrive su di uno si può rileggere
37 dall'altro. Si viene così a costituire un canale di comunicazione tramite i
38 due file descriptor, nella forma di un \textsl{tubo} (da cui il nome)
39 attraverso cui fluiscono i dati.
41 La funzione che permette di creare questa speciale coppia di file descriptor
42 associati ad una \textit{pipe} è appunto \func{pipe}, ed il suo prototipo è:
43 \begin{prototype}{unistd.h}
44 {int pipe(int filedes[2])}
46 Crea una coppia di file descriptor associati ad una \textit{pipe}.
48 \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
49 errore, nel qual caso \var{errno} potrà assumere i valori \macro{EMFILE},
50 \macro{ENFILE} e \macro{EFAULT}.}
53 La funzione restituisce la coppia di file descriptor nel vettore
54 \param{filedes}; il primo è aperto in lettura ed il secondo in scrittura. Come
55 accennato concetto di funzionamento di una pipe è semplice: quello che si
56 scrive nel file descriptor aperto in scrittura viene ripresentato tale e quale
57 nel file descriptor aperto in lettura. I file descriptor infatti non sono
58 connessi a nessun file reale, ma ad un buffer nel kernel, la cui dimensione è
59 specificata dal parametro di sistema \macro{PIPE\_BUF}, (vedi
60 \secref{sec:sys_file_limits}). Lo schema di funzionamento di una pipe è
61 illustrato in \figref{fig:ipc_pipe_singular}, in cui sono illustrati i due
62 capi della pipe, associati a ciascun file descriptor, con le frecce che
63 indicano la direzione del flusso dei dati.
67 \includegraphics[height=5cm]{img/pipe}
68 \caption{Schema della struttura di una pipe.}
69 \label{fig:ipc_pipe_singular}
72 Chiaramente creare una pipe all'interno di un singolo processo non serve a
73 niente; se però ricordiamo quanto esposto in \secref{sec:file_sharing}
74 riguardo al comportamento dei file descriptor nei processi figli, è immediato
75 capire come una pipe possa diventare un meccanismo di intercomunicazione. Un
76 processo figlio infatti condivide gli stessi file descriptor del padre,
77 compresi quelli associati ad una pipe (secondo la situazione illustrata in
78 \figref{fig:ipc_pipe_fork}). In questo modo se uno dei processi scrive su un
79 capo della pipe, l'altro può leggere.
83 \includegraphics[height=5cm]{img/pipefork}
84 \caption{Schema dei collegamenti ad una pipe, condivisi fra processo padre e
85 figlio dopo l'esecuzione \func{fork}.}
86 \label{fig:ipc_pipe_fork}
89 Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
90 comunicazione fra processi attraverso una pipe, utilizzando le proprietà
91 ordinarie dei file, ma ci mostra anche qual'è il principale\footnote{Stevens
92 in \cite{APUE} riporta come limite anche il fatto che la comunicazione è
93 unidirezionale, ma in realtà questo è un limite facilmente superabile usando
94 una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i
95 processi possano condividere i file descriptor della pipe, e per questo essi
96 devono comunque essere \textsl{parenti} (dall'inglese \textit{siblings}), cioè
97 o derivare da uno stesso processo padre in cui è avvenuta la creazione della
98 pipe, o, più comunemente, essere nella relazione padre/figlio.
100 A differenza di quanto avviene con i file normali, la lettura da una pipe può
101 essere bloccante (qualora non siano presenti dati), inoltre se si legge da una
102 pipe il cui capo in scrittura è stato chiuso, si avrà la ricezione di un EOF
103 (vale a dire che la funzione \func{read} ritornerà restituendo 0). Se invece
104 si esegue una scrittura su una pipe il cui capo in lettura non è aperto il
105 processo riceverà il segnale \macro{EPIPE}, e la funzione di scrittura
106 restituirà un errore di \macro{EPIPE} (al ritorno del manipolatore, o qualora
107 il segnale sia ignorato o bloccato).
109 La dimensione del buffer della pipe (\macro{PIPE\_BUF}) ci dà inoltre un'altra
110 importante informazione riguardo il comportamento delle operazioni di lettura
111 e scrittura su di una pipe; esse infatti sono atomiche fintanto che la
112 quantità di dati da scrivere non supera questa dimensione. Qualora ad esempio
113 si effettui una scrittura di una quantità di dati superiore l'operazione verrà
114 effettuata in più riprese, consentendo l'intromissione di scritture effettuate
118 \subsection{Un esempio dell'uso delle pipe}
119 \label{sec:ipc_pipe_use}
121 Per capire meglio il funzionamento delle pipe faremo un esempio di quello che
122 è il loro uso più comune, analogo a quello effettuato della shell, e che
123 consiste nell'inviare l'output di un processo (lo standard output) sull'input
124 di un'altro. Realizzeremo il programma di esempio nella forma di un
125 \textit{CGI}\footnote{Un CGI (\textit{Common Gateway Interface}) è un
126 programma che permette la creazione dinamica di un oggetto da inserire
127 all'interno di una pagina HTML.} per Apache, che genera una immagine JPEG
128 di un codice a barre, specificato come parametro di input.
130 Un programma che deve essere eseguito come \textit{CGI} deve rispondere a
131 delle caratteristiche specifiche, esso infatti non viene lanciato da una
132 shell, ma dallo stesso web server, alla richiesta di una specifica URL, che di
135 http://www.sito.it/cgi-bin/programma?parametro
137 ed il risultato dell'elaborazione deve essere presentato (con una intestazione
138 che ne descrive il mime-type) sullo standard output, in modo che il web-server
139 possa reinviarlo al browser che ha effettuato la richiesta, che in questo modo
140 è in grado di visualizzarlo opportunamente.
142 Per realizzare quanto voluto useremo in sequenza i programmi \cmd{barcode} e
143 \cmd{gs}, il primo infatti è in grado di generare immagini postscript di
144 codici a barre corrispondenti ad una qualunque stringa, mentre il secondo
145 serve per poter effettuare la conversione della stessa immagine in formato
146 JPEG. Usando una pipe potremo inviare l'output del primo sull'input del
147 secondo, secondo lo schema mostrato in \figref{fig:ipc_pipe_use}, in cui la
148 direzione del flusso dei dati è data dalle frecce continue.
152 \includegraphics[height=5cm]{img/pipeuse}
153 \caption{Schema dell'uso di una pipe come mezzo di comunicazione fra
154 due processi attraverso attraverso l'esecuzione una \func{fork} e la
155 chiusura dei capi non utilizzati.}
156 \label{fig:ipc_pipe_use}
159 Si potrebbe obiettare che sarebbe molto più semplice salvare il risultato
160 intermedio su un file temporaneo. Questo però non tiene conto del fatto che un
161 \textit{CGI} deve poter gestire più richieste in concorrenza, e si avrebbe una
162 evidente race condition in caso di accesso simultaneo a detto
163 file.\footnote{il problema potrebbe essere superato determinando in anticipo
164 un nome appropriato per il file temporaneo, che verrebbe utilizzato dai vari
165 sotto-processi, e cancellato alla fine della loro esecuzione; ma a questo le
166 cose non sarebbero più tanto semplici.} L'uso di una pipe invece permette
167 di risolvere il problema in maniera semplice ed elegante, oltre ad essere
168 molto più efficiente, dato che non si deve scrivere su disco.
170 Il programma ci servirà anche come esempio dell'uso delle funzioni di
171 duplicazione dei file descriptor che abbiamo trattato in
172 \secref{sec:file_dup}, in particolare di \func{dup2}. È attraverso queste
173 funzioni infatti che è possibile dirottare gli stream standard dei processi
174 (che abbiamo visto in \secref{sec:file_std_descr} e
175 \secref{sec:file_std_stream}) sulla pipe. In \figref{fig:ipc_barcodepage_code}
176 abbiamo riportato il corpo del programma, il cui codice completo è disponibile
177 nel file \file{BarCodePage.c} che si trova nella directory dei sorgenti.
181 \footnotesize \centering
182 \begin{minipage}[c]{15cm}
184 int main(int argc, char *argv[], char *envp[])
187 /* create two pipes, pipein and pipeout, to handle communication */
188 if ( (retval = pipe(pipein)) ) {
189 WriteMess("input pipe creation error");
192 if ( (retval = pipe(pipeout)) ) {
193 WriteMess("output pipe creation error");
196 /* First fork: use child to run barcode program */
197 if ( (pid = fork()) == -1) { /* on error exit */
198 WriteMess("child creation error");
203 close(pipein[1]); /* close pipe write end */
204 dup2(pipein[0], STDIN_FILENO); /* remap stdin to pipe read end */
206 dup2(pipeout[1], STDOUT_FILENO); /* remap stdout in pipe output */
207 execlp("barcode", "barcode", size, NULL);
209 close(pipein[0]); /* close input side of input pipe */
210 write(pipein[1], argv[1], strlen(argv[1])); /* write parameter to pipe */
211 close(pipein[1]); /* closing write end */
212 waitpid(pid, NULL, 0); /* wait child completion */
213 /* Second fork: use child to run ghostscript */
214 if ( (pid = fork()) == -1) {
215 WriteMess("child creation error");
218 /* second child, convert PS to JPEG */
220 close(pipeout[1]); /* close write end */
221 dup2(pipeout[0], STDIN_FILENO); /* remap read end to stdin */
223 write(STDOUT_FILENO, content, strlen(content));
224 execlp("gs", "gs", "-q", "-sDEVICE=jpeg", "-sOutputFile=-", "-", NULL);
228 waitpid(pid, NULL, 0);
234 \caption{Sezione principale del codice del \textit{CGI}
235 \file{BarCodePage.c}.}
236 \label{fig:ipc_barcodepage_code}
239 La prima operazione del programma (\texttt{\small 4--12}) è quella di creare
240 le due pipe che serviranno per la comunicazione fra i due comandi utilizzati
241 per produrre il codice a barre; si ha cura di controllare la riuscita della
242 chiamata, inviando in caso di errore un messaggio invece dell'immagine
243 richiesta.\footnote{la funzione \func{WriteMess} non è riportata in
244 \secref{fig:ipc_barcodepage_code}; essa si incarica semplicemente di
245 formattare l'uscita alla maniera dei CGI, aggiungendo l'opportuno
246 \textit{mime type}, e formattando il messaggio in HTML, in modo che
247 quest'ultimo possa essere visualizzato correttamente da un browser.}
249 Una volta create le pipe, il programma può creare (\texttt{\small 13-17}) il
250 primo processo figlio, che si incaricherà (\texttt{\small 19--25}) di eseguire
251 \cmd{barcode}. Quest'ultimo legge dallo standard input una stringa di
252 caratteri, la converte nell'immagine postscript del codice a barre ad essa
253 corrispondente, e poi scrive il risultato direttamente sullo standard output.
255 Per poter utilizzare queste caratteristiche prima di eseguire \cmd{barcode} si
256 chiude (\texttt{\small 20}) il capo aperto in scrittura della prima pipe, e se
257 ne collega (\texttt{\small 21}) il capo in lettura allo standard input, usando
258 \func{dup2}. Si ricordi che invocando \func{dup2} il secondo file, qualora
259 risulti aperto, viene, come nel caso corrente, chiuso prima di effettuare la
260 duplicazione. Allo stesso modo, dato che \cmd{barcode} scrive l'immagine
261 postscript del codice a barre sullo standard output, per poter effettuare una
262 ulteriore redirezione il capo in lettura della seconda pipe viene chiuso
263 (\texttt{\small 22}) mentre il capo in scrittura viene collegato allo standard
264 output (\texttt{\small 23}).
266 In questo modo all'esecuzione (\texttt{\small 25}) di \cmd{barcode} (cui si
267 passa in \var{size} la dimensione della pagina per l'immagine) quest'ultimo
268 leggerà dalla prima pipe la stringa da codificare che gli sarà inviata dal
269 padre, e scriverà l'immagine postscript del codice a barre sulla seconda.
271 Al contempo una volta lanciato il primo figlio, il processo padre prima chiude
272 (\texttt{\small 26}) il capo inutilizzato della prima pipe (quello in input) e
273 poi scrive (\texttt{\small 27}) la stringa da convertire sul capo in output,
274 così che \cmd{barcode} possa riceverla dallo standard input. A questo punto
275 l'uso della prima pipe da parte del padre è finito ed essa può essere
276 definitivamente chiusa (\texttt{\small 28}), si attende poi (\texttt{\small
277 29}) che l'esecuzione di \cmd{barcode} sia completata.
279 Alla conclusione della sua esecuzione \cmd{barcode} avrà inviato l'immagine
280 postscript del codice a barre sul capo in scrittura della seconda pipe; a
281 questo punto si può eseguire la seconda conversione, da PS a JPEG, usando il
282 programma \cmd{gs}. Per questo si crea (\texttt{\small 30--34}) un secondo
283 processo figlio, che poi (\texttt{\small 35--42}) eseguirà questo programma
284 leggendo l'immagine postscript creata da \cmd{barcode} dallo standard input,
285 per convertirla in JPEG.
287 Per fare tutto ciò anzitutto si chiude (\texttt{\small 37}) il capo in
288 scrittura della seconda pipe, e se ne collega (\texttt{\small 38}) il capo in
289 lettura allo standard input. Per poter formattare l'output del programma in
290 maniera utilizzabile da un browser, si provvede anche \texttt{\small 40}) alla
291 scrittura dell'apposita stringa di identificazione del mime-type in testa allo
292 standard output. A questo punto si può invocare \texttt{\small 41}) \cmd{gs},
293 provvedendo gli appositi switch che consentono di leggere il file da
294 convertire dallo standard input e di inviare la conversione sullo standard
297 Per completare le operazioni il processo padre chiude (\texttt{\small 44}) il
298 capo in scrittura della seconda pipe, e attende la conclusione del figlio
299 (\texttt{\small 45}); a questo punto può (\texttt{\small 46}) uscire. Si tenga
300 conto che l'operazione di chiudere il capo in scrittura della seconda pipe è
301 necessaria, infatti, se non venisse chiusa, \cmd{gs}, che legge il suo
302 standard input da detta pipe, resterebbe bloccato in attesa di ulteriori dati
303 in ingresso (l'unico modo che un programma ha per sapere che l'input è
304 terminato è rilevare che lo standard input è stato chiuso), e la \func{wait}
308 \subsection{Le funzioni \func{popen} e \func{pclose}}
309 \label{sec:ipc_popen}
311 Come si è visto la modalità più comune di utilizzo di una pipe è quella di
312 utilizzarla per fare da tramite fra output ed input di due programmi invocati
313 in sequenza; per questo motivo lo standard POSIX.2 ha introdotto due funzioni
314 che permettono di sintetizzare queste operazioni. La prima di esse si chiama
315 \func{popen} ed il suo prototipo è:
316 \begin{prototype}{stdio.h}
317 {FILE *popen(const char *command, const char *type)}
319 Esegue il programma \param{command}, di cui, a seconda di \param{type},
320 restituisce, lo standard input o lo standard output nella pipe collegata allo
321 stream restituito come valore di ritorno.
323 \bodydesc{La funzione restituisce l'indirizzo dello stream associato alla pipe
324 in caso di successo e \macro{NULL} per un errore, nel qual caso \var{errno}
325 potrà assumere i valori relativi alle sottostanti invocazioni di \func{pipe}
326 e \func{fork} o \macro{EINVAL} se \param{type} non è valido.}
329 La funzione crea una pipe, esegue una \func{fork}, ed invoca il programma
330 \param{command} attraverso la shell (in sostanza esegue \file{/bin/sh} con il
331 flag \code{-c}); l'argomento \param{type} deve essere una delle due stringhe
332 \verb|"w"| o \verb|"r"|, per indicare se la pipe sarà collegata allo standard
333 input o allo standard output del comando invocato.
335 La funzione restituisce il puntatore allo stream associato alla pipe creata,
336 che sarà aperto in sola lettura (e quindi associato allo standard output del
337 programma indicato) in caso si sia indicato \code{"r"}, o in sola scrittura (e
338 quindi associato allo standard input) in caso di \code{"w"}.
340 Lo stream restituito da \func{popen} è identico a tutti gli effetti ai file
341 stream visti in \secref{cha:files_std_interface}, anche se è collegato ad una
342 pipe e non ad un inode, e viene sempre aperto in modalità
343 \textit{fully-buffered} (vedi \secref{sec:file_buffering}); l'unica differenza
344 con gli usuali stream è che dovrà essere chiuso dalla seconda delle due nuove
345 funzioni, \func{pclose}, il cui prototipo è:
346 \begin{prototype}{stdio.h}
347 {int pclose(FILE *stream)}
349 Chiude il file \param{stream}, restituito da una precedente \func{popen}
350 attendendo la terminazione del processo ad essa associato.
352 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
353 errore; nel quel caso il valore di \func{errno} deriva dalle sottostanti
356 \noindent che oltre alla chiusura dello stream si incarica anche di attendere
357 (tramite \func{wait4}) la conclusione del processo creato dalla precedente
360 Per illustrare l'uso di queste due funzioni riprendiamo il problema
361 precedente: il programma mostrato in \figref{fig:ipc_barcodepage_code} per
362 quanto funzionante, è (volutamente) codificato in maniera piuttosto complessa,
363 inoltre nella pratica sconta un problema di \cmd{gs} che non è in
364 grado\footnote{nella versione GNU Ghostscript 6.53 (2002-02-13).} di
365 riconoscere correttamente l'encapsulated postscript, per cui deve essere usato
366 il postscript e tutte le volte viene generata una pagina intera, invece che
367 una immagine delle dimensioni corrispondenti al codice a barre.
369 Se si vuole generare una immagine di dimensioni appropriate si deve usare un
370 approccio diverso. Una possibilità sarebbe quella di ricorrere ad ulteriore
371 programma, \cmd{epstopsf}, per convertire in PDF un file EPS (che può essere
372 generato da \cmd{barcode} utilizzando lo switch \cmd{-E}). Utilizzando un PDF
373 al posto di un EPS \cmd{gs} esegue la conversione rispettando le dimensioni
374 originarie del codice a barre e produce un JPEG di dimensioni corrette.
376 Questo approccio però non funziona, per via di una delle caratteristiche
377 principali delle pipe. Per poter effettuare la conversione di un PDF infatti è
378 necessario, per la struttura del formato, potersi spostare (con \func{lseek})
379 all'interno del file da convertire; se si esegue la conversione con \cmd{gs} su
380 un file regolare non ci sono problemi, una pipe però è rigidamente
381 sequenziale, e l'uso di \func{lseek} su di essa fallisce sempre con un errore
382 di \macro{ESPIPE}, rendendo impossibile la conversione. Questo ci dice che in
383 generale la concatenazione di vari programmi funzionerà soltanto quando tutti
384 prevedono una lettura sequenziale del loro input.
386 Per questo motivo si è dovuto utilizzare un procedimento diverso, eseguendo
387 prima la conversione (sempre con \cmd{gs}) del PS in un altro formato
388 intermedio, il PPM,\footnote{il \textit{Portable PixMap file format} è un
389 formato usato spesso come formato intermedio per effettuare conversioni, è
390 infatti molto facile da manipolare, dato che usa caratteri ASCII per
391 memorizzare le immagini, anche se per questo è estremamente inefficiente.}
392 dal quale poi si può ottenere un'immagine di dimensioni corrette attraverso
393 vari programmi di manipolazione (\cmd{pnmcrop}, \cmd{pnmmargin}) che può
394 essere infine trasformata in PNG (con \cmd{pnm2png}).
396 In questo caso però occorre eseguire in sequenza ben quattro comandi diversi,
397 inviando l'output di ciascuno all'input del successivo, per poi ottenere il
398 risultato finale sullo standard output: un caso classico di utilizzazione
399 delle pipe, in cui l'uso di \func{popen} e \func{pclose} permette di
400 semplificare notevolmente la stesura del codice.
402 Nel nostro caso, dato che ciascun processo deve scrivere il suo output sullo
403 standard input del successivo, occorrerà usare \func{popen} aprendo la pipe in
404 scrittura. Il codice del nuovo programma è riportato in
405 \figref{fig:ipc_barcode_code}. Come si può notare l'ordine di invocazione dei
406 programmi è l'inverso di quello in cui ci si aspetta che vengano
407 effettivamente eseguiti. Questo non comporta nessun problema dato che la
408 lettura su una pipe è bloccante, per cui ciascun processo, per quanto lanciato
409 per primo, si bloccherà in attesa di ricevere sullo standard input il
410 risultato dell'elaborazione del precedente, benchè quest'ultimo venga
414 \footnotesize \centering
415 \begin{minipage}[c]{15cm}
417 int main(int argc, char *argv[], char *envp[])
421 char *cmd_string[4]={
423 "pnmmargin -white 10",
425 "gs -sDEVICE=ppmraw -sOutputFile=- -sNOPAUSE -q - -c showpage -c quit"
427 char content[]="Content-type: image/png\n\n";
429 /* write mime-type to stout */
430 write(STDOUT_FILENO, content, strlen(content));
431 /* execute chain of command */
432 for (i=0; i<4; i++) {
433 pipe[i] = popen(cmd_string[i], "w");
434 dup2(fileno(pipe[i]), STDOUT_FILENO);
436 /* create barcode (in PS) */
437 pipein = popen("barcode", "w");
438 /* send barcode string to barcode program */
439 write(fileno(pipein), argv[1], strlen(argv[1]));
440 /* close all pipes (in reverse order) */
441 for (i=4; i==0; i--) {
449 \caption{Codice completo del \textit{CGI} \file{BarCode.c}.}
450 \label{fig:ipc_barcode_code}
453 Nel nostro caso il primo passo (\texttt{\small 14}) è scrivere il mime-type
454 sullo standard output; a questo punto il processo padre non necessita più di
455 eseguire ulteriori operazioni sullo standard output e può tranquillamente
456 provvedere alla redirezione.
458 Dato che i vari programmi devono essere lanciati in successione, si è
459 approntato un ciclo (\texttt{\small 15--19}) che esegue le operazioni in
460 sequenza: prima crea una pipe (\texttt{\small 17}) per la scrittura eseguendo
461 il programma con \func{popen}, in modo che essa sia collegata allo standard
462 input, e poi redirige (\texttt{\small 18}) lo standard output su detta pipe.
464 In questo modo il primo processo ad essere invocato (che è l'ultimo della
465 catena) scriverà ancora sullo standard output del processo padre, ma i
466 successivi, a causa di questa redirezione, scriveranno sulla pipe associata
467 allo standard input del processo invocato nel ciclo precedente.
469 Alla fine tutto quello che resta da fare è lanciare (\texttt{\small 21}) il
470 primo processo della catena, che nel caso è \cmd{barcode}, e scrivere
471 (\texttt{\small 23}) la stringa del codice a barre sulla pipe, che è collegata
472 al suo standard input, infine si può eseguire (\texttt{\small 24--27}) un
473 ciclo che chiuda, nell'ordine inverso rispetto a quello in cui le si sono
474 create, tutte le pipe create con \func{pclose}.
477 \subsection{Le \textit{pipe} con nome, o \textit{fifo}}
478 \label{sec:ipc_named_pipe}
480 Come accennato in \secref{sec:ipc_pipes} il problema delle \textit{pipe} è che
481 esse possono essere utilizzate solo da processi con un progenitore comune o
482 nella relazione padre/figlio; per superare questo problema lo standard POSIX.1
483 ha definito dei nuovi oggetti, le \textit{fifo}, che hanno le stesse
484 caratteristiche delle pipe, ma che invece di essere strutture interne del
485 kernel, visibili solo attraverso un file descriptor, sono accessibili
486 attraverso un inode che risiede sul filesystem, così che i processi le possono
487 usare senza dovere per forza essere in una relazione di \textsl{parentela}.
489 Utilizzando una \textit{fifo} tutti i dati passeranno, come per le pipe,
490 attraverso un apposito buffer nel kernel, senza transitare dal filesystem;
491 l'inode allocato sul filesystem serve infatti solo a fornire un punto di
492 riferimento per i processi, che permetta loro di accedere alla stessa fifo; il
493 comportamento delle funzioni di lettura e scrittura è identico a quello
494 illustrato per le pipe in \secref{sec:ipc_pipes}.
496 Abbiamo già visto in \secref{sec:file_mknod} le funzioni \func{mknod} e
497 \func{mkfifo} che permettono di creare una fifo; per utilizzarne una un
498 processo non avrà che da aprire il relativo file speciale o in lettura o
499 scrittura; nel primo caso sarà collegato al capo di uscita della fifo, e dovrà
500 leggere, nel secondo al capo di ingresso, e dovrà scrivere.
502 Il kernel crea una singola pipe per ciascuna fifo che sia stata aperta, che può
503 essere acceduta contemporaneamente da più processi, sia in lettura che in
504 scrittura. Dato che per funzionare deve essere aperta in entrambe le
505 direzioni, per una fifo di norma la funzione \func{open} si blocca se viene
506 eseguita quando l'altro capo non è aperto.
508 Le fifo però possono essere anche aperte in modalità \textsl{non-bloccante},
509 nel qual caso l'apertura del capo in lettura avrà successo solo quando anche
510 l'altro capo è aperto, mentre l'apertura del capo in scrittura restituirà
511 l'errore di \macro{ENXIO} fintanto che non verrà aperto il capo in lettura.
513 In Linux è possibile aprire le fifo anche in lettura/scrittura,\footnote{lo
514 standard POSIX lascia indefinito il comportamento in questo caso.}
515 operazione che avrà sempre successo immediato qualunque sia la modalità di
516 apertura (bloccante e non bloccante); questo può essere utilizzato per aprire
517 comunque una fifo in scrittura anche se non ci sono ancora processi il
518 lettura; è possibile anche usare la fifo all'interno di un solo processo, nel
519 qual caso però occorre stare molto attenti alla possibili
520 situazioni di stallo.\footnote{se si cerca di leggere da una fifo che non contiene dati si
521 avrà un deadlock immediato, dato che il processo si blocca e non potrà
522 quindi mai eseguire le funzioni di scrittura.}
524 Per la loro caratteristica di essere accessibili attraverso il filesystem, è
525 piuttosto frequente l'utilizzo di una fifo come canale di comunicazione nelle
526 situazioni un processo deve ricevere informazioni da altri. In questo caso è
527 fondamentale che le operazioni di scrittura siano atomiche; per questo si deve
528 sempre tenere presente che questo è vero soltanto fintanto che non si supera
529 il limite delle dimensioni di \macro{PIPE\_BUF} (si ricordi quanto detto in
530 \secref{sec:ipc_pipes}).
532 A parte il caso precedente, che resta probabilmente il più comune, Stevens
533 riporta in \cite{APUE} altre due casistiche principali per l'uso delle fifo:
535 \item Da parte dei comandi di shell, per evitare la creazione di file
536 temporanei quando si devono inviare i dati di uscita di un processo
537 sull'input di parecchi altri (attraverso l'uso del comando \cmd{tee}).
539 \item Come canale di comunicazione fra client ed server (il modello
540 \textit{client-server} è illustrato in \secref{sec:net_cliserv}).
543 Nel primo caso quello che si fa è creare tante fifo, da usare come standard
544 input, quanti sono i processi a cui i vogliono inviare i dati, questi ultimi
545 saranno stati posti in esecuzione ridirigendo lo standard input dalle fifo, si
546 potrà poi eseguire il processo che fornisce l'output replicando quest'ultimo,
547 con il comando \cmd{tee}, sulle varie fifo.
549 Il secondo caso è relativamente semplice qualora si debba comunicare con un
550 processo alla volta (nel qual caso basta usare due fifo, una per leggere ed
551 una per scrivere), le cose diventano invece molto più complesse quando si
552 vuole effettuare una comunicazione fra il server ed un numero imprecisato di
553 client; se il primo infatti può ricevere le richieste attraverso una fifo
554 ``nota'', per le risposte non si può fare altrettanto, dato che, per la
555 struttura sequenziale delle fifo, i client dovrebbero sapere, prima di
556 leggerli, quando i dati inviati sono destinati a loro.
558 Per risolvere questo problema, si può usare un'architettura come quella
559 illustrata in \figref{fig:ipc_fifo_server_arch} in cui i client inviano le
560 richieste al server su una fifo nota mentre le risposte vengono reinviate dal
561 server a ciascuno di essi su una fifo temporanea creata per l'occasione.
565 \includegraphics[height=9cm]{img/fifoserver}
566 \caption{Schema dell'utilizzo delle fifo nella realizzazione di una
567 architettura di comunicazione client/server.}
568 \label{fig:ipc_fifo_server_arch}
571 Come esempio di uso questa architettura e dell'uso delle fifo, abbiamo scritto
572 un server di \textit{fortunes}, che restituisce, alle richieste di un client,
573 un detto a caso estratto da un insieme di frasi; sia il numero delle frasi
574 dell'insieme, che i file da cui esse vengono lette all'avvio, sono importabili
575 da riga di comando. Il corpo principale del server è riportato in
576 \figref{fig:ipc_fifo_server}, dove si è tralasciata la parte che tratta la
577 gestione delle opzioni a riga di comando, che effettua il settaggio delle
578 variabili \var{fortunefilename}, che indica il file da cui leggere le frasi,
579 ed \var{n}, che indica il numero di frasi tenute in memoria, ad un valore
580 diverso da quelli preimpostati. Il codice completo è nel file
581 \file{FortuneServer.c}.
584 \footnotesize \centering
585 \begin{minipage}[c]{15cm}
587 char *fifoname = "/tmp/fortune.fifo";
588 int main(int argc, char *argv[])
590 /* Variables definition */
592 char *fortunefilename = "/usr/share/games/fortunes/italia";
595 int fifo_server, fifo_client;
598 if (n==0) usage(); /* if no pool depth exit printing usage info */
599 Signal(SIGTERM, HandSIGTERM); /* set handlers for termination */
600 Signal(SIGINT, HandSIGTERM);
601 Signal(SIGQUIT, HandSIGTERM);
602 i = FortuneParse(fortunefilename, fortune, n); /* parse phrases */
603 if (mkfifo(fifoname, 0622)) { /* create well known fifo if does't exist */
605 perror("Cannot create well known fifo");
609 /* open fifo two times to avoid EOF */
610 fifo_server = open(fifoname, O_RDONLY);
611 if (fifo_server < 0) {
612 perror("Cannot open read only well known fifo");
615 if (open(fifoname, O_WRONLY) < 0) {
616 perror("Cannot open write only well known fifo");
619 /* Main body: loop over requests */
621 nread = read(fifo_server, line, 79); /* read request */
623 perror("Read Error");
626 line[nread] = 0; /* terminate fifo name string */
627 n = random() % i; /* select random value */
628 fifo_client = open(line, O_WRONLY); /* open client fifo */
629 if (fifo_client < 0) {
630 perror("Cannot open");
633 nread = write(fifo_client, /* write phrase */
634 fortune[n], strlen(fortune[n])+1);
635 close(fifo_client); /* close client fifo */
641 \caption{Sezione principale del codice del server di \textit{fortunes}
643 \label{fig:ipc_fifo_server}
646 Il server richiede (\texttt{\small 12}) che sia stata impostata una dimensione
647 dell'insieme delle frasi non nulla, dato che l'inizializzazione del vettore
648 \var{fortune} avviene solo quando questa dimensione viene specificata, la
649 presenza di un valore nullo provoca l'uscita dal programma attraverso la
650 routine (non riportata) che ne stampa le modalità d'uso. Dopo di che installa
651 (\texttt{\small 13--15}) la funzione che gestisce i segnali di interruzione
652 (anche questa non è riportata in \figref{fig:ipc_fifo_server}) che si limita a
653 rimuovere dal filesystem la fifo usata dal server per comunicare.
655 Terminata l'inizializzazione (\texttt{\small 16}) si effettua la chiamata alla
656 funzione \code{FortuneParse} che legge dal file specificato in
657 \var{fortunefilename} le prime \var{n} frasi e le memorizza (allocando
658 dinamicamente la memoria necessaria) nel vettore di puntatori \var{fortune}.
659 Anche il codice della funzione non è riportato, in quanto non direttamente
660 attinente allo scopo dell'esempio.
662 Il passo successivo (\texttt{\small 17--22}) è quello di creare con
663 \func{mkfifo} la fifo nota sulla quale il server ascolterà le richieste,
664 qualora si riscontri un errore il server uscirà (escludendo ovviamente il caso
665 in cui la funzione \func{mkfifo} fallisce per la precedente esistenza della
668 Una volta che si è certi che la fifo di ascolto esiste si procede
669 (\texttt{\small 23--32}) alla sua apertura. Questo viene fatto due volte
670 per evitare di dover gestire all'interno del ciclo principale il caso in cui
671 il server è in ascolto ma non ci sono client che effettuano richieste.
672 Si ricordi infatti che quando una fifo è aperta solo dal capo in lettura,
673 l'esecuzione di \func{read} ritorna con zero byte (si ha cioè una condizione
676 Nel nostro caso la prima apertura si bloccherà fintanto che un qualunque
677 client non apre a sua volta la fifo nota in scrittura per effettuare la sua
678 richiesta. Pertanto all'inizio non ci sono problemi, il client però, una volta
679 ricevuta la risposta, uscirà, chiudendo tutti i file aperti, compresa la fifo.
680 A questo punto il server resta (se non ci sono altri client che stanno
681 effettuando richieste) con la fifo chiusa sul lato in lettura e a questo punto
682 \func{read} non si bloccherà in attesa di input, ma ritornerà in continuazione
683 restituendo un end-of-file.\footnote{Si è usata questa tecnica per
684 compatibilità, Linux infatti supporta l'apertura delle fifo in
685 lettura/scrittura, per cui si sarebbe potuto effettuare una singola apertura
686 con \macro{O\_RDWR}, la doppia apertura comunque ha il vantaggio che non si
687 può scrivere per errore sul capo aperto in sola lettura.}
689 Per questo motivo, dopo aver eseguito l'apertura in lettura (\texttt{\small
690 24--28}),\footnote{di solito si effettua l'apertura del capo in lettura in
691 modalità non bloccante, per evitare il rischio di uno stallo (se nessuno
692 apre la fifo in scrittura il processo non ritornerà mai dalla \func{open})
693 che nel nostro caso non esiste, mentre è necessario potersi bloccare in
694 lettura in attesa di una richiesta.} si esegue una seconda apertura in
695 scrittura (\texttt{\small 29--32}), scartando il relativo file descriptor che
696 non sarà mai usato, ma lasciando la fifo comunque aperta anche in scrittura,
697 cosicché le successive possano bloccarsi.
699 A questo punto si può entrare nel ciclo principale del programma che fornisce
700 le risposte ai client (\texttt{\small 34--50}), che viene eseguito
701 indefinitamente (l'uscita del server viene effettuata inviando un segnale, in
702 modo da passare attraverso la routine di chiusura che cancella la fifo).
704 Il server è progettato per accettare come richieste dai client delle stringhe
705 che contengono il nome della fifo sulla quale deve essere inviata la risposta.
706 Per cui prima (\texttt{\small 35--39}) si esegue la lettura dalla stringa di
707 richiesta dalla fifo nota (che a questo punto si bloccherà tutte le volte che
708 non ci sono richieste). Dopo di che, una volta terminata la stringa
709 (\texttt{\small 40}) e selezionato (\texttt{\small 41}) un numero casuale per
710 ricavare la frase da inviare, si procederà (\texttt{\small 42--46})
711 all'apertura della fifo per la risposta, che \texttt{\small 47--48}) poi vi
712 sarà scritta. Infine (\texttt{\small 49}) si chiude la fifo di risposta che
715 Il codice del client è invece riportato in \figref{fig:ipc_fifo_client}, anche
716 in questo caso si è omessa la gestione delle opzioni e la funzione che stampa
717 a video le informazioni di utilizzo ed esce, riportando solo la sezione
718 principale del programma e le definizioni delle variabili. Il codice completo
719 è nel file \file{FortuneClient.c} dei sorgenti allegati.
722 \footnotesize \centering
723 \begin{minipage}[c]{15cm}
725 int main(int argc, char *argv[])
727 /* Variables definition */
729 char *fortunefilename = "/tmp/fortune.fifo";
731 int fifo_server, fifo_client;
734 char buffer[PIPE_BUF];
736 snprintf(fifoname, 80, "/tmp/fortune.%d", getpid()); /* compose name */
737 if (mkfifo(fifoname, 0622)) { /* open client fifo */
739 perror("Cannot create well known fifo");
743 fifo_server = open(fortunefilename, O_WRONLY); /* open server fifo */
744 if (fifo_server < 0) {
745 perror("Cannot open well known fifo");
748 nread = write(fifo_server, fifoname, strlen(fifoname)+1); /* write name */
749 close(fifo_server); /* close server fifo */
750 fifo_client = open(fifoname, O_RDONLY); /* open client fifo */
751 if (fifo_client < 0) {
752 perror("Cannot open well known fifo");
755 nread = read(fifo_client, buffer, sizeof(buffer)); /* read answer */
756 printf("%s", buffer); /* print fortune */
757 close(fifo_client); /* close client */
758 close(fifo_server); /* close server */
759 unlink(fifoname); /* remove client fifo */
764 \caption{Sezione principale del codice del client di \textit{fortunes}
766 \label{fig:ipc_fifo_client}
769 La prima istruzione (\texttt{\small 12}) compone il nome della fifo che dovrà
770 essere utilizzata per ricevere la risposta dal server. Si usa il \acr{pid}
771 del processo per essere sicuri di avere un nome univoco; dopo di che
772 (\texttt{\small 13-18}) si procede alla creazione del relativo file, uscendo
773 in caso di errore (a meno che il file non sia già presente sul filesystem).
775 A questo punto il client può effettuare l'interrogazione del server, per
776 questo prima si apre la fifo nota (\texttt{\small 19--23}), e poi ci si scrive
777 (\texttt{\small 24}) la stringa composta in precedenza, che contiene il nome
778 della fifo da utilizzare per la risposta. Infine si richiude la fifo del
779 server che a questo punto non serve più (\texttt{\small 25}).
781 Inoltrata la richiesta si può passare alla lettura della risposta; anzitutto
782 si apre (\texttt{\small 26--30}) la fifo appena creata, da cui si deve
783 riceverla, dopo di che si effettua una lettura (\texttt{\small 31})
784 nell'apposito buffer; si è supposto, come è ragionevole, che le frasi inviate
785 dal server siano sempre di dimensioni inferiori a \macro{PIPE\_BUF},
786 tralasciamo la gestione del caso in cui questo non è vero. Infine si stampa
787 (\texttt{\small 32}) a video la risposta, si chiude (\texttt{\small 33}) la
788 fifo e si cancella (\texttt{\small 34}) il relativo file.
789 Si noti come la fifo per la risposta sia stata aperta solo dopo aver inviato
790 la richiesta, se non si fosse fatto così si avrebbe avuto uno stallo, in
791 quanto senza la richiesta, il server non avrebbe potuto aprirne il capo in
792 scrittura e l'apertura si sarebbe bloccata indefinitamente.
794 Benché il nostro sistema client-server funzioni, la sua struttura è piuttosto
795 complessa e continua ad avere vari inconvenienti\footnote{lo stesso Stevens,
796 che esamina questa architettura in \cite{APUE}, nota come sia impossibile
797 per il server sapere se un client è andato in crash, con la possibilità di
798 far restare le fifo temporanee sul filesystem, di come sia necessario
799 intercettare \macro{SIGPIPE} dato che un client può terminare dopo aver
800 fatto una richiesta, ma prima che la risposta sia inviata (cosa che nel
801 nostro esempio non è stata fatta).}; in generale infatti l'interfaccia delle
802 fifo non è adatta a risolvere questo tipo di problemi, che possono essere
803 affrontati in maniera più semplice ed efficace o usando i
804 \textit{socket}\index{socket} (che tratteremo in dettaglio a partire da
805 \capref{cha:socket_intro}) o ricorrendo a meccanismi di comunicazione diversi,
806 come quelli che esamineremo in seguito.
810 \subsection{La funzione \func{socketpair}}
811 \label{sec:ipc_socketpair}
813 Un meccanismo di comunicazione molto simile alle pipe, ma che non presenta il
814 problema della unidirezionalità del flusso dei dati, è quello dei cosiddetti
815 \textit{socket} locali (o \textit{Unix domain socket}). Tratteremo l'argomento
816 dei socket in \capref{cha:socket_intro}, nell'ambito dell'interfaccia generale
817 che essi forniscono per la programmazione di rete; e vedremo
818 (in~\secref{sec:sock_sa_local}) come in tal caso si possono definire dei file
819 speciali (di tipo \textit{socket}, analoghi alle fifo) cui si accede però
820 attraverso quella interfaccia; vale però la pena esaminare qui una
821 modalità\footnote{la funzione \func{socketpair} è stata introdotta in BSD4.4,
822 ma è supportata in genere da qualunque sistema che fornisca l'interfaccia
823 dei socket.} di uso di questi socket che li rende sostanzialmente identici
824 ad una pipe bidirezionale.
826 Attraverso la funzione \func{socketpair} infatti è possibile creare una coppia
827 di socket (che sono trattati com file descriptor) connessi fra di loro, senza
828 fare nessun riferimento ad un file speciale sul filesystem, in maniera analoga
829 a quello che si fa con \func{pipe}; la differenza è che in questo caso il
830 flusso dei dati è bidirezionale. Il prototipo della funzione è:
832 \headdecl{sys/types.h}
833 \headdecl{sys/socket.h}
835 \funcdecl{int socketpair(int domain, int type, int protocol, int sv[2])}
837 Crea una coppia di socket connessi fra loro.
839 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
840 errore, nel qual caso \var{errno} assumerà uno dei valori:
842 \item[\macro{EAFNOSUPPORT}] I socket locali non sono supportati.
843 \item[\macro{EPROTONOSUPPORT}] Il protocollo specificato non è supportato.
844 \item[\macro{EOPNOTSUPP}] Il protocollo specificato non supporta la
845 creazione di coppie di socket.
847 ed inoltre \macro{EMFILE}, \macro{EFAULT}.
851 La funzione restituisce in \param{sv} una coppia di descrittori di socket
852 (come vedremo in \capref{cha:socket_intro} i file descriptor vengono usati
853 anche per i socket) connessi fra di loro, così che quello che si scrive da una
854 parte può essere riletto dall'altra e viceversa. I parametri \param{domain},
855 \param{type} e \param{protocol} derivano dall'interfaccia dei socket, ma in
856 questo caso i soli valori validi sono rispettivamente \macro{AF\_UNIX},
857 \macro{SOCK\_STREAM} e \macro{0}.
861 \section{La comunicazione fra processi di System V}
864 Benché le pipe e le fifo siano ancora ampiamente usate, esse scontano il
865 limite fondamentale che il meccanismo di comunicazione che forniscono è
866 rigidamente sequenziale: una situazione in cui un processo scrive qualcosa che
867 molti altri devono poter leggere non può essere implementata con una pipe.
869 Per questo nello sviluppo di System V vennero introdotti una serie di nuovi
870 oggetti per la comunicazione fra processi ed una nuova interfaccia di
871 programmazione, che fossero in grado di garantire una maggiore flessibilità.
872 In questa sezione esamineremo come Linux supporta quello che viene ormai
873 chiamato il \textsl{Sistema di comunicazione inter-processo} di System V, o
874 \textit{System V IPC (Inter-Process Comunication)}.
878 \subsection{Considerazioni generali}
879 \label{sec:ipc_sysv_generic}
881 La principale caratteristica del sistema di IPC di System V è quella di essere
882 basato su oggetti permanenti che risiedono nel kernel. Questi, a differenza di
883 quanto avviene per i file descriptor, non mantengono un contatore dei
884 riferimenti, e non vengono cancellati dal sistema una volta che non sono più
887 Questo comporta due problemi: il primo è che, al contrario di quanto avviene
888 per pipe e fifo, la memoria allocata per questi oggetti non viene rilasciata
889 automaticamente quando nessuno li vuole più utilizzare, ed essi devono essere
890 cancellati esplicitamente, se non si vuole che restino attivi fino al riavvio
891 del sistema. Il secondo è che, dato che non c'è un contatore di riferimenti,
892 essi possono essere cancellati anche se ci sono dei processi che li stanno
893 utilizzando, con tutte le conseguenze (negative) del caso.
895 Gli oggetti usati nel System V IPC vengono creati direttamente dal kernel, e
896 sono accessibili solo specificando il relativo \textsl{identificatore}. Questo
897 è un numero progressivo (un po' come il \acr{pid} dei processi) che il kernel
898 assegna a ciascuno di essi quanto vengono creati (sul procedimento di
899 assegnazione torneremo in \secref{sec:ipc_sysv_id_use}). L'identificatore
900 viene restituito dalle funzioni che creano l'oggetto, ed è quindi locale al
901 processo che le ha eseguite. Dato che l'identificatore viene assegnato
902 dinamicamente dal kernel non è possibile prevedere quale sarà, ne utilizzare
903 un qualche valore statico, si pone perciò il problema di come processi diversi
904 possono accedere allo stesso oggetto.
906 Per risolvere il problema il kernel associa a ciascun oggetto una struttura
907 \var{ipc\_perm}; questa contiene una \textsl{chiave}, identificata da una
908 variabile del tipo primitivo \type{key\_t}, che viene specificata in fase di
909 creazione e tramite la quale è possibile ricavare l'identificatore. La
910 struttura, la cui definizione è riportata in \figref{fig:ipc_ipc_perm},
911 contiene anche le varie proprietà associate all'oggetto.
914 \footnotesize \centering
915 \begin{minipage}[c]{15cm}
916 \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm ]{}
919 key_t key; /* Key. */
920 uid_t uid; /* Owner's user ID. */
921 gid_t gid; /* Owner's group ID. */
922 uid_t cuid; /* Creator's user ID. */
923 gid_t cgid; /* Creator's group ID. */
924 unsigned short int mode; /* Read/write permission. */
925 unsigned short int seq; /* Sequence number. */
930 \caption{La struttura \var{ipc\_perm}, come definita in \file{sys/ipc.h}.}
931 \label{fig:ipc_ipc_perm}
934 Usando la stessa chiave due processi diversi possono ricavare l'identificatore
935 associato ad un oggetto ed accedervi. Il problema che sorge a questo punto è
936 come devono fare per accordarsi sull'uso di una stessa chiave. Se i processi
937 sono \textsl{parenti} la soluzione è relativamente semplice, in tal caso
938 infatti si può usare il valore speciale \texttt{IPC\_PRIVATE} per creare un
939 nuovo oggetto nel processo padre, l'identificatore così ottenuto sarà
940 disponibile in tutti i figli, e potrà essere passato come parametro attraverso
943 Però quando i processi non sono \textsl{parenti} (come capita tutte le volte
944 che si ha a che fare con un sistema client-server) tutto questo non è
945 possibile; si potrebbe comunque salvare l'identificatore su un file noto, ma
946 questo ovviamente comporta lo svantaggio di doverselo andare a rileggere. Una
947 alternativa più efficace è quella che i programmi usino un valore comune per
948 la chiave (che ad esempio può essere dichiarato in un header comune), ma c'è
949 sempre il rischio che questa chiave possa essere stata già utilizzata da
950 qualcun altro. Dato che non esiste una convenzione su come assegnare queste
951 chiavi in maniera univoca l'interfaccia mette a disposizione una funzione,
952 \func{ftok}, che permette di ottenere una chiave specificando il nome di un
953 file ed un numero di versione; il suo prototipo è:
955 \headdecl{sys/types.h}
958 \funcdecl{key\_t ftok(const char *pathname, int proj\_id)}
960 Restituisce una chiave per identificare un oggetto del System V IPC.
962 \bodydesc{La funzione restituisce la chiave in caso di successo e -1
963 altrimenti, nel qual caso \var{errno} sarà uno dei possibili codici di
964 errore di \func{stat}.}
967 La funzione determina un valore della chiave sulla base di \param{pathname},
968 che deve specificare il pathname di un file effettivamente esistente e di un
969 numero di progetto \param{proj\_id)}, che di norma viene specificato come
970 carattere, dato che ne vengono utilizzati solo gli 8 bit meno
971 significativi.\footnote{nelle libc4 e libc5, come avviene in SunOS,
972 l'argomento \param{proj\_id} è dichiarato tipo \ctyp{char}, le \acr{glibc}
973 usano il prototipo specificato da XPG4, ma vengono lo stesso utilizzati gli
974 8 bit meno significativi.}
976 Il problema è che anche così non c'è la sicurezza che il valore della chiave
977 sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
978 con i 16 bit meno significativi dell'inode del file \param{pathname} (che
979 vengono ottenuti attraverso \func{stat}, da cui derivano i possibili errori),
980 e gli 8 bit meno significativi del numero del dispositivo su cui è il file.
981 Diventa perciò relativamente facile ottenere delle collisioni, specie se i
982 file sono su dispositivi con lo stesso \textit{minor number}, come
983 \file{/dev/hda1} e \file{/dev/sda1}.
985 In genere quello che si fa è utilizzare un file comune usato dai programmi che
986 devono comunicare (ad esempio un header comune, o uno dei programmi che devono
987 usare l'oggetto in questione), utilizzando il numero di progetto per ottenere
988 le chiavi che interessano. In ogni caso occorre sempre controllare, prima di
989 creare un oggetto, che la chiave non sia già stata utilizzata. Se questo va
990 bene in fase di creazione, le cose possono complicarsi per i programmi che
991 devono solo accedere, in quanto, a parte gli eventuali controlli sugli altri
992 attributi di \var{ipc\_perm}, non esiste una modalità semplice per essere
993 sicuri che l'oggetto associato ad una certa chiave sia stato effettivamente
994 creato da chi ci si aspetta.
996 Questo è, insieme al fatto che gli oggetti sono permanenti e non mantengono un
997 contatore di riferimenti per la cancellazione automatica, il principale
998 problema del sistema di IPC di System V. Non esiste infatti una modalità
999 chiara per identificare un oggetto, come sarebbe stato se lo si fosse
1000 associato ad in file, e tutta l'interfaccia è inutilmente complessa. Per
1001 questo ne è stata effettuata una revisione completa nello standard POSIX.1b,
1002 che tratteremo in \secref{sec:ipc_posix}.
1005 \subsection{Il controllo di accesso}
1006 \label{sec:ipc_sysv_access_control}
1008 Oltre alle chiavi, abbiamo visto che ad ogni oggetto sono associate in
1009 \var{ipc\_perm} ulteriori informazioni, come gli identificatori del creatore
1010 (nei campi \var{cuid} e \var{cgid}) e del proprietario (nei campi \var{uid} e
1011 \var{gid}) dello stesso, e un insieme di permessi (nel campo \var{mode}). In
1012 questo modo è possibile definire un controllo di accesso sugli oggetti di IPC,
1013 simile a quello che si ha per i file (vedi \secref{sec:file_perm_overview}).
1015 Benché questo controllo di accesso sia molto simile a quello dei file, restano
1016 delle importanti differenze. La prima è che il permesso di esecuzione non
1017 esiste (e se specificato viene ignorato), per cui si può parlare solo di
1018 permessi di lettura e scrittura (nel caso dei semafori poi quest'ultimo è più
1019 propriamente un permesso di modifica). I valori di \var{mode} sono gli stessi
1020 ed hanno lo stesso significato di quelli riportati in
1021 \secref{tab:file_mode_flags}\footnote{se però si vogliono usare le costanti
1022 simboliche ivi definite occorrerà includere il file \file{sys/stat.h},
1023 alcuni sistemi definiscono le costanti \macro{MSG\_R} (\texttt{0400}) e
1024 \macro{MSG\_W} (\texttt{0200}) per indicare i permessi base di lettura e
1025 scrittura per il proprietario, da utilizzare, con gli opportuni shift, pure
1026 per il gruppo e gli altri, in Linux, visto la loro scarsa utilità, queste
1027 costanti non sono definite.} e come per i file definiscono gli accessi per
1028 il proprietario, il suo gruppo e tutti gli altri.
1030 Quando l'oggetto viene creato i campi \var{cuid} e \var{uid} di
1031 \var{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono settati
1032 rispettivamente al valore dell'userid e del groupid effettivo del processo che
1033 ha chiamato la funzione, ma, mentre i campi \var{uid} e \var{gid} possono
1034 essere cambiati, i campi \var{cuid} e \var{cgid} restano sempre gli stessi.
1036 Il controllo di accesso è effettuato a due livelli. Il primo livello è nelle
1037 funzioni che richiedono l'identificatore di un oggetto data la chiave. Queste
1038 specificano tutte un argomento \param{flag}, in tal caso quando viene
1039 effettuata la ricerca di una chiave, qualora \param{flag} specifichi dei
1040 permessi, questi vengono controllati e l'identificatore viene restituito solo
1041 se corrispondono a quelli dell'oggetto. Se ci sono dei permessi non presenti
1042 in \var{mode} l'accesso sarà negato. Questo controllo però è di utilità
1043 indicativa, dato che è sempre possibile specificare per \param{flag} un valore
1044 nullo, nel qual caso l'identificatore sarà restituito comunque.
1046 Il secondo livello di controllo è quello delle varie funzioni che accedono
1047 direttamente (in lettura o scrittura) all'oggetto. In tal caso lo schema dei
1048 controlli è simile a quello dei file, ed avviene secondo questa sequenza:
1050 \item se il processo ha i privilegi di amministratore l'accesso è sempre
1052 \item se l'userid effettivo del processo corrisponde o al valore del campo
1053 \var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario
1054 in \var{mode} è appropriato\footnote{per appropriato si intende che è
1055 settato il permesso di scrittura per le operazioni di scrittura e quello
1056 di lettura per le operazioni di lettura.} l'accesso è consentito.
1057 \item se il groupid effettivo del processo corrisponde o al
1058 valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso
1059 per il gruppo in \var{mode} è appropriato l'accesso è consentito.
1060 \item se il permesso per gli altri è appropriato l'accesso è consentito.
1062 solo se tutti i controlli elencati falliscono l'accesso è negato. Si noti che
1063 a differenza di quanto avviene per i permessi dei file, fallire in uno dei
1064 passi elencati non comporta il fallimento dell'accesso. Un'ulteriore
1065 differenza rispetto a quanto avviene per i file è che per gli oggetti di IPC
1066 il valore di \var{umask} (si ricordi quanto esposto in
1067 \secref{sec:file_umask}) non ha alcun significato.
1070 \subsection{Gli identificatori ed il loro utilizzo}
1071 \label{sec:ipc_sysv_id_use}
1073 L'unico campo di \var{ipc\_perm} del quale non abbiamo ancora parlato è
1074 \var{seq}, che in \figref{fig:ipc_ipc_perm} è qualificato con un criptico
1075 ``\textsl{numero di sequenza}'', ne parliamo adesso dato che esso è
1076 strettamente attinente alle modalità con cui il kernel assegna gli
1077 identificatori degli oggetti del sistema di IPC.
1079 Quando il sistema si avvia, alla creazione di ogni nuovo oggetto di IPC viene
1080 assegnato un numero progressivo, pari al numero di oggetti di quel tipo
1081 esistenti. Se il comportamento fosse sempre questo sarebbe identico a quello
1082 usato nell'assegnazione dei file descriptor nei processi, ed i valori degli
1083 identificatori tenderebbero ad essere riutilizzati spesso e restare di piccole
1084 dimensioni (inferiori al numero massimo di oggetti disponibili).
1086 Questo va benissimo nel caso dei file descriptor, che sono locali ad un
1087 processo, ma qui il comportamento varrebbe per tutto il sistema, e per
1088 processi del tutto scorrelati fra loro. Così si potrebbero avere situazioni
1089 come quella in cui un server esce e cancella le sue code di messaggi, ed il
1090 relativo identificatore viene immediatamente assegnato a quelle di un altro
1091 server partito subito dopo, con la possibilità che i client del primo non
1092 facciano in tempo ad accorgersi dell'avvenuto, e finiscano con l'interagire
1093 con gli oggetti del secondo, con conseguenze imprevedibili.
1095 Proprio per evitare questo tipo di situazioni il sistema usa il valore di
1096 \var{req} per provvedere un meccanismo che porti gli identificatori ad
1097 assumere tutti i valori possibili, rendendo molto più lungo il periodo in cui
1098 un identificatore può venire riutilizzato.
1100 Il sistema dispone sempre di un numero fisso di oggetti di IPC,\footnote{fino
1101 al kernel 2.2.x questi valori, definiti dalle costanti \macro{MSGMNI},
1102 \macro{SEMMNI} e \macro{SHMMNI}, potevano essere cambiati (come tutti gli
1103 altri limiti relativi al \textit{System V IPC}) solo con una ricompilazione
1104 del kernel, andando a modificarne la definizione nei relativi header file.
1105 A partire dal kernel 2.4.x è possibile cambiare questi valori a sistema
1106 attivo scrivendo sui file \file{shmmni}, \file{msgmni} e \file{sem} di
1107 \file{/proc/sys/kernel} o con l'uso di \texttt{syscntl}.} e per ciascuno di
1108 essi viene mantenuto in \var{seq} un numero di sequenza progressivo che viene
1109 incrementato di uno ogni volta che l'oggetto viene cancellato. Quando
1110 l'oggetto viene creato usando uno spazio che era già stato utilizzato in
1111 precedenza per restituire l'identificatore al numero di oggetti presenti viene
1112 sommato il valore di \var{seq} moltiplicato per il numero massimo di oggetti
1113 di quel tipo,\footnote{questo vale fino ai kernel della serie 2.2.x, dalla
1114 serie 2.4.x viene usato lo stesso fattore per tutti gli oggetti, esso è dato
1115 dalla costante \macro{IPCMNI}, definita in \file{include/linux/ipc.h}, che
1116 indica il limite massimo per il numero di tutti oggetti di IPC, ed il cui
1117 valore è 32768.} si evita così il riutilizzo degli stessi numeri, e si fa
1118 sì che l'identificatore assuma tutti i valori possibili.
1120 \begin{figure}[!htb]
1121 \footnotesize \centering
1122 \begin{minipage}[c]{15cm}
1123 \begin{lstlisting}{}
1124 int main(int argc, char *argv[])
1128 case 'q': /* Message Queue */
1129 debug("Message Queue Try\n");
1130 for (i=0; i<n; i++) {
1131 id = msgget(IPC_PRIVATE, IPC_CREAT|0666);
1132 printf("Identifier Value %d \n", id);
1133 msgctl(id, IPC_RMID, NULL);
1136 case 's': /* Semaphore */
1137 debug("Semaphore\n");
1138 for (i=0; i<n; i++) {
1139 id = semget(IPC_PRIVATE, 1, IPC_CREAT|0666);
1140 printf("Identifier Value %d \n", id);
1141 semctl(id, 0, IPC_RMID);
1144 case 'm': /* Shared Memory */
1145 debug("Shared Memory\n");
1146 for (i=0; i<n; i++) {
1147 id = shmget(IPC_PRIVATE, 1000, IPC_CREAT|0666);
1148 printf("Identifier Value %d \n", id);
1149 shmctl(id, IPC_RMID, NULL);
1152 default: /* should not reached */
1160 \caption{Sezione principale del programma di test per l'assegnazione degli
1161 identificatori degli oggetti di IPC \file{IPCTestId.c}.}
1162 \label{fig:ipc_sysv_idtest}
1165 In \figref{fig:ipc_sysv_idtest} è riportato il codice di un semplice programma
1166 di test che si limita a creare un oggetto (specificato a riga di comando),
1167 stamparne il numero di identificatore e cancellarlo per un numero specificato
1168 di volte. Al solito non si è riportato il codice della gestione delle opzioni
1169 a riga di comando, che permette di specificare quante volte effettuare il
1170 ciclo \var{n}, e su quale tipo di oggetto eseguirlo.
1172 La figura non riporta il codice di selezione delle opzioni, che permette di
1173 inizializzare i valori delle variabili \var{type} al tipo di oggetto voluto, e
1174 \var{n} al numero di volte che si vuole effettuare il ciclo di creazione,
1175 stampa, cancellazione. I valori di default sono per l'uso delle code di
1176 messaggi e un ciclo di 5 volte. Se si lancia il comando si otterrà qualcosa
1179 piccardi@gont sources]$ ./ipctestid
1181 Identifier Value 32768
1182 Identifier Value 65536
1183 Identifier Value 98304
1184 Identifier Value 131072
1186 il che ci mostra che abbiamo un kernel della serie 2.4.x nel quale non avevamo
1187 ancora usato nessuna coda di messaggi. Se ripetiamo il comando otterremo
1190 [piccardi@gont sources]$ ./ipctestid
1191 Identifier Value 163840
1192 Identifier Value 196608
1193 Identifier Value 229376
1194 Identifier Value 262144
1195 Identifier Value 294912
1197 che ci mostra come il valore di \var{seq} sia in effetti una quantità
1198 mantenuta staticamente all'interno del sistema.
1201 \subsection{Code di messaggi}
1202 \label{sec:ipc_sysv_mq}
1204 Il primo oggetto introdotto dal \textit{System V IPC} è quello delle code di
1205 messaggi. Le code di messaggi sono oggetti analoghi alle pipe o alle fifo,
1206 anche se la loro struttura è diversa. La funzione che permette di ottenerne
1207 una è \func{msgget} ed il suo prototipo è:
1209 \headdecl{sys/types.h}
1210 \headdecl{sys/ipc.h}
1211 \headdecl{sys/msg.h}
1213 \funcdecl{int msgget(key\_t key, int flag)}
1215 Restituisce l'identificatore di una coda di messaggi.
1217 \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
1218 in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
1220 \item[\macro{EACCES}] Il processo chiamante non ha i privilegi per accedere
1221 alla coda richiesta.
1222 \item[\macro{EEXIST}] Si è richiesta la creazione di una coda che già
1223 esiste, ma erano specificati sia \macro{IPC\_CREAT} che \macro{IPC\_EXCL}.
1224 \item[\macro{EIDRM}] La coda richiesta è marcata per essere cancellata.
1225 \item[\macro{ENOENT}] Si è cercato di ottenere l'identificatore di una coda
1226 di messaggi specificando una chiave che non esiste e \macro{IPC\_CREAT}
1227 non era specificato.
1228 \item[\macro{ENOSPC}] Si è cercato di creare una coda di messaggi quando è
1229 stato il limite massimo del sistema.
1231 ed inoltre \macro{ENOMEM}.
1235 Le funzione (come le analoghe che si usano per gli altri oggetti) serve sia a
1236 ottenere l'identificatore di una coda di messaggi esistente, che a crearne una
1237 nuova. L'argomento \param{key} specifica la chiave che è associata
1238 all'oggetto, eccetto il caso in cui si specifichi il valore
1239 \macro{IPC\_PRIVATE}, nel qual caso la coda è creata ex-novo e non vi è
1240 associata alcuna chiave, il processo (ed i suoi eventuali figli) potranno
1241 farvi riferimento solo attraverso l'identificatore.
1243 Se invece si specifica un valore diverso da \macro{IPC\_PRIVATE}\footnote{in
1244 Linux questo significa un valore diverso da zero.} l'effetto della funzione
1245 dipende dal valore di \param{flag}, se questo è nullo la funzione si limita ad
1246 effettuare una ricerca sugli oggetti esistenti, restituendo l'identificatore
1247 se trova una corrispondenza, o fallendo con un errore di \macro{ENOENT} se non
1248 esiste o di \macro{EACCESS} se si sono specificati dei permessi non validi.
1250 Se invece si vuole creare una nuova coda di messaggi \param{flag} non può
1251 essere nullo e deve essere fornito come maschera binaria, impostando il bit
1252 corrispondente al valore \macro{IPC\_CREAT}. In questo caso i nove bit meno
1253 significativi di \param{flag} saranno usati come permessi per il nuovo
1254 oggetto, secondo quanto illustrato in \secref{sec:ipc_sysv_access_control}.
1255 Se si imposta anche il bit corrispondente a \macro{IPC\_EXCL} la funzione avrà
1256 successo solo se l'oggetto non esiste già, fallendo con un errore di
1257 \macro{EEXIST} altrimenti.
1259 Si tenga conto che l'uso di \macro{IPC\_PRIVATE} non impedisce ad altri
1260 processi di accedere alla coda (se hanno privilegi sufficienti) una volta che
1261 questi possano indovinare o ricavare (ad esempio per tentativi)
1262 l'identificatore ad essa associato. Per come sono implementati gli oggetti di
1263 IPC infatti non esiste una maniera che garantisca l'accesso esclusivo ad una
1264 coda di messaggi. Usare \macro{IPC\_PRIVATE} o macro{IPC\_CREAT} e
1265 \macro{IPC\_EXCL} per \param{flag} comporta solo la creazione di una nuova
1271 \begin{tabular}[c]{|c|r|l|l|}
1273 \textbf{Costante} & \textbf{Valore} & \textbf{File in \texttt{proc}}
1274 & \textbf{Significato} \\
1277 \macro{MSGMNI}& 16& \file{msgmni} & Numero massimo di code di
1279 \macro{MSGMAX}& 8192& \file{msgmax} & Dimensione massima di un singolo
1281 \macro{MSGMNB}&16384& \file{msgmnb} & Dimensione massima del contenuto di
1285 \caption{Valori delle costanti associate ai limiti delle code di messaggi.}
1286 \label{tab:ipc_msg_limits}
1289 Le code di messaggi sono caratterizzate da tre limiti fondamentali, definiti
1290 negli header e corrispondenti alle prime tre costanti riportate in
1291 \tabref{tab:ipc_msg_limits}, come accennato però in Linux è possibile
1292 modificare questi limiti attraverso l'uso di \func{syscntl} o scrivendo nei
1293 file \file{msgmax}, \file{msgmnb} e \file{msgmni} di \file{/proc/sys/kernel/}.
1297 \centering \includegraphics[width=15cm]{img/mqstruct}
1298 \caption{Schema della struttura di una coda messaggi.}
1299 \label{fig:ipc_mq_schema}
1303 Una coda di messaggi è costituita da una \textit{linked list};\footnote{una
1304 \textit{linked list} è una tipica struttura di dati, organizzati in una
1305 lista in cui ciascun elemento contiene un puntatore al successivo. In questo
1306 modo la struttura è veloce nell'estrazione ed immissione dei dati dalle
1307 estremità dalla lista (basta aggiungere un elemento in testa o in coda ed
1308 aggiornare un puntatore), e relativamente veloce da attraversare in ordine
1309 sequenziale (seguendo i puntatori), è invece relativamente lenta
1310 nell'accesso casuale e nella ricerca.} i nuovi messaggi vengono inseriti in
1311 coda alla lista e vengono letti dalla cima, in \figref{fig:ipc_mq_schema} si è
1312 riportato lo schema con cui queste strutture vengono mantenute dal
1313 kernel.\footnote{lo schema illustrato in figura è in realtà una semplificazione
1314 di quanto usato fino ai kernel della serie 2.2.x, nei kernel della serie
1315 2.4.x la gestione è effettuata in maniera diversa; ma esso illustra comunque
1316 in maniera adeguata i principi di funzionamento delle code di messaggi.}
1318 \begin{figure}[!htb]
1319 \footnotesize \centering
1320 \begin{minipage}[c]{15cm}
1321 \begin{lstlisting}[labelstep=0]{}
1323 struct ipc_perm msg_perm; /* structure for operation permission */
1324 time_t msg_stime; /* time of last msgsnd command */
1325 time_t msg_rtime; /* time of last msgrcv command */
1326 time_t msg_ctime; /* time of last change */
1327 msgqnum_t msg_qnum; /* number of messages currently on queue */
1328 msglen_t msg_qbytes; /* max number of bytes allowed on queue */
1329 pid_t msg_lspid; /* pid of last msgsnd() */
1330 pid_t msg_lrpid; /* pid of last msgrcv() */
1331 struct msg *msg_first; /* first message on queue, unused */
1332 struct msg *msg_last; /* last message in queue, unused */
1333 unsigned long int msg_cbytes; /* current number of bytes on queue */
1338 \caption{La struttura \var{msgid\_ds}, associata a ciascuna coda di
1340 \label{fig:ipc_msgid_sd}
1343 A ciascuna coda è associata una struttura \var{msgid\_ds}, la cui definizione
1344 è riportata in \secref{fig:ipc_msgid_sd}, il significato dei vari campi è
1345 riportato nella figura. In questa struttura il kernel\footnote{come accennato
1346 questo vale fino ai kernel della serie 2.2.x, essa viene usata nei kernel
1347 della serie 2.4.x solo per compatibilità in quanto è quella restituita dalle
1348 funzioni dell'interfaccia. In \figref{fig:ipc_msgid_sd} sono elencati i
1349 campi significativi definiti in \file{sys/msg.h}, a cui si sono aggiunti gli
1350 ultimi tre campi che sono previsti dalla implementazione originale di System
1351 V, ma non dallo standard Unix98.} mantiene le principali informazioni
1352 riguardo lo stato corrente della coda. Quando si crea una nuova coda con
1353 \func{msgget} questa struttura viene inizializzata, in particolare il campo
1354 \var{msg\_perm} viene inizializzato come illustrato in
1355 \secref{sec:ipc_sysv_access_control}, per quanto riguarda gli altri campi
1358 \item il campo \var{msg\_qnum}, che esprime il numero di messaggi presenti
1359 sulla coda, viene inizializzato a 0.
1360 \item i campi \var{msg\_lspid} e \var{msg\_lrpid}, che esprimono
1361 rispettivamente il \acr{pid} dell'ultimo processo che ha inviato o ricevuto
1362 un messaggio sulla coda, sono inizializzati a 0.
1363 \item i campi \var{msg\_stime} e \var{msg\_rtime}, che esprimono
1364 rispettivamente il tempo in cui è stato inviato o ricevuto l'ultimo
1365 messaggio sulla coda, sono inizializzati a 0.
1366 \item il campo \var{msg\_ctime}, che esprime il tempo di creazione della coda,
1367 viene inizializzato al tempo corrente.
1368 \item il campo \var{msg\_qbytes} che esprime la dimensione massima del
1369 contenuto della coda (in byte) viene inizializzato al valore preimpostato
1370 del sistema (\macro{MSGMNB}).
1371 \item i campi \var{msg\_first} e \var{msg\_last} che esprimono l'indirizzo del
1372 primo e ultimo messaggio sono inizializzati a \macro{NULL} e
1373 \var{msg\_cbytes}, che esprime la dimensione in byte dei messaggi presenti è
1374 inizializzato a zero. Questi campi sono ad uso interno dell'implementazione
1375 e non devono essere utilizzati da programmi in user space).
1378 Una volta creata una coda di messaggi le operazioni di controllo vengono
1379 effettuate con la funzione \func{msgctl}, che (come le analoghe \func{semctl}
1380 e \func{shmctl}) fa le veci di quello che \func{ioctl} è per i file; il suo
1383 \headdecl{sys/types.h}
1384 \headdecl{sys/ipc.h}
1385 \headdecl{sys/msg.h}
1387 \funcdecl{int msgctl(int msqid, int cmd, struct msqid\_ds *buf)}
1389 Esegue l'operazione specificata da \param{cmd} sulla coda \param{msqid}.
1391 \bodydesc{La funzione restituisce 0 in caso di successo o -1 in caso di
1392 errore, nel qual caso \var{errno} assumerà uno dei valori:
1394 \item[\macro{EACCES}] Si è richiesto \macro{IPC\_STAT} ma processo chiamante
1395 non ha i privilegi di lettura sulla coda.
1396 \item[\macro{EIDRM}] La coda richiesta è stata cancellata.
1397 \item[\macro{EPERM}] Si è richiesto \macro{IPC\_SET} o \macro{IPC\_RMID} ma
1398 il processo non ha i privilegi, o si è richiesto di aumentare il valore di
1399 \var{msg\_qbytes} oltre il limite \macro{MSGMNB} senza essere
1402 ed inoltre \macro{EFAULT} ed \macro{EINVAL}.
1406 La funzione permette di accedere ai valori della struttura \var{msqid\_ds},
1407 mantenuta all'indirizzo \param{buf}, per la coda specificata
1408 dall'identificatore \param{msqid}. Il comportamento della funzione dipende dal
1409 valore dell'argomento \param{cmd}, che specifica il tipo di azione da
1410 eseguire; i valori possibili sono:
1411 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
1412 \item[\macro{IPC\_STAT}] Legge le informazioni riguardo la coda nella
1413 struttura indicata da \param{buf}. Occorre avere il permesso di lettura
1415 \item[\macro{IPC\_RMID}] Rimuove la coda, cancellando tutti i dati, con
1416 effetto immediato. Tutti i processi che cercheranno di accedere alla coda
1417 riceveranno un errore di \macro{EIDRM}, e tutti processi in attesa su
1418 funzioni di di lettura o di scrittura sulla coda saranno svegliati ricevendo
1419 il medesimo errore. Questo comando può essere eseguito solo da un processo
1420 con userid effettivo corrispondente al creatore o al proprietario della
1421 coda, o all'amministratore.
1422 \item[\macro{IPC\_SET}] Permette di modificare i permessi ed il proprietario
1423 della coda, ed il limite massimo sulle dimensioni del totale dei messaggi in
1424 essa contenuti (\var{msg\_qbytes}). I valori devono essere passati in una
1425 struttura \var{msqid\_ds} puntata da \param{buf}. Per modificare i valori
1426 di \var{msg\_perm.mode}, \var{msg\_perm.uid} e \var{msg\_perm.gid} occorre
1427 essere il proprietario o il creatore della coda, oppure l'amministratore; lo
1428 stesso vale per \var{msg\_qbytes}, ma l'amministratore ha la facoltà di
1429 incrementarne il valore a limiti superiori a \macro{MSGMNB}.
1433 Una volta che si abbia a disposizione l'identificatore, per inviare un
1434 messaggio su una coda si utilizza la funzione \func{msgsnd}; il suo prototipo
1437 \headdecl{sys/types.h}
1438 \headdecl{sys/ipc.h}
1439 \headdecl{sys/msg.h}
1441 \funcdecl{int msgsnd(int msqid, struct msgbuf *msgp, size\_t msgsz, int
1444 Invia un messaggio sulla coda \param{msqid}.
1446 \bodydesc{La funzione restituisce 0, e -1 in caso di errore, nel qual caso
1447 \var{errno} assumerà uno dei valori:
1449 \item[\macro{EACCES}] Non si hanno i privilegi di accesso sulla coda.
1450 \item[\macro{EIDRM}] La coda è stata cancellata.
1451 \item[\macro{EAGAIN}] Il messaggio non può essere inviato perché si è
1452 superato il limite \var{msg\_qbytes} sul numero massimo di byte presenti
1453 sulla coda, e si è richiesto \macro{IPC\_NOWAIT} in \param{flag}.
1454 \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
1455 \item[\macro{EINVAL}] Si è specificato un \param{msgid} invalido, o un
1456 valore non positivo per \param{mtype}, o un valore di \param{msgsz}
1457 maggiore di \macro{MSGMAX}.
1459 ed inoltre \macro{EFAULT} ed \macro{ENOMEM}.
1463 La funzione inserisce il messaggio sulla coda specificata da \param{msqid}; il
1464 messaggio ha lunghezza specificata da \param{msgsz} ed è passato attraverso
1465 l'argomento \param{msgp}. Quest'ultimo deve venire passato sempre in una
1466 forma che corrisponda alla struttura \var{msgbuf} riportata in
1467 \figref{fig:ipc_msbuf}. La dimensione massima per il testo di un messaggio
1468 non può comunque superare il limite \macro{MSGMAX}.
1470 La struttura di \figref{fig:ipc_msbuf} comunque è solo un modello, tanto che
1471 la definizione contenuta in \file{sys/msg.h} usa esplicitamente per il secondo
1472 campo il valore \code{mtext[1]}, che non è di nessuna utilità ai fini pratici.
1473 La sola cosa che conta è che abbia come primo membro un campo \var{mtype},
1474 come nell'esempio; esso infatti serve ad identificare il tipo di messaggio e
1475 deve essere sempre specificato come intero positivo. Il campo \var{mtext}
1476 invece può essere di qualsiasi tipo e dimensione, e deve contenere il testo
1479 In generale pertanto per inviare un messaggio con \func{msgsnd} si usa
1480 ridefinire una struttura simile a quella di \figref{fig:ipc_msbuf}, adattando
1481 alle proprie esigenze il campo \var{mtype}, (o ridefinendo come si vuole il
1482 corpo del messaggio, anche con più campi o con strutture più complesse) avendo
1483 però la cura di mantenere nel primo campo un valore di tipo \ctyp{long} che ne
1486 Si tenga presente che la lunghezza che deve essere indicata in questo
1487 argomento è solo quella del messaggio, non quella di tutta la struttura, se
1488 cioè \var{message} è una propria struttura che si passa alla funzione,
1489 \param{msgsz} dovrà essere uguale a \code{sizeof(message)-sizeof(long)}, (se
1490 consideriamo il caso dell'esempio in \figref{fig:ipc_msbuf}, \param{msgsz}
1491 dovrà essere pari a \macro{LENGTH}).
1493 \begin{figure}[!htb]
1494 \footnotesize \centering
1495 \begin{minipage}[c]{15cm}
1496 \begin{lstlisting}[labelstep=0]{}
1498 long mtype; /* message type, must be > 0 */
1499 char mtext[LENGTH]; /* message data */
1504 \caption{Schema della struttura \var{msgbuf}, da utilizzare come argomento
1505 per inviare/ricevere messaggi.}
1506 \label{fig:ipc_msbuf}
1509 Per capire meglio il funzionamento della funzione riprendiamo in
1510 considerazione la struttura della coda illustrata in
1511 \figref{fig:ipc_mq_schema}. Alla chiamata di \func{msgsnd} il nuovo messaggio
1512 sarà aggiunto in fondo alla lista inserendo una nuova struttura \var{msg}, il
1513 puntatore \var{msg\_last} di \var{msqid\_ds} verrà aggiornato, come pure il
1514 puntatore al messaggio successivo per quello che era il precedente ultimo
1515 messaggio; il valore di \var{mtype} verrà mantenuto in \var{msg\_type} ed il
1516 valore di \param{msgsz} in \var{msg\_ts}; il testo del messaggio sarà copiato
1517 all'indirizzo specificato da \var{msg\_spot}.
1519 Il valore dell'argomento \param{flag} permette di specificare il comportamento
1520 della funzione. Di norma, quando si specifica un valore nullo, la funzione
1521 ritorna immediatamente a meno che si sia ecceduto il valore di
1522 \var{msg\_qbytes}, o il limite di sistema sul numero di messaggi, nel qual
1523 caso si blocca mandando il processo in stato di \textit{sleep}. Se si
1524 specifica per \param{flag} il valore \macro{IPC\_NOWAIT} la funzione opera in
1525 modalità non bloccante, ed in questi casi ritorna immediatamente con un errore
1528 Se non si specifica \macro{IPC\_NOWAIT} la funzione resterà bloccata fintanto
1529 che non si liberano risorse sufficienti per poter inserire nella coda il
1530 messaggio, nel qual caso ritornerà normalmente. La funzione può ritornare, con
1531 una condizione di errore anche in due altri casi: quando la coda viene rimossa
1532 (nel qual caso si ha un errore di \macro{EIDRM}) o quando la funzione viene
1533 interrotta da un segnale (nel qual caso si ha un errore di \macro{EINTR}).
1535 Una volta completato con successo l'invio del messaggio sulla coda, la
1536 funzione aggiorna i dati mantenuti in \var{msqid\_ds}, in particolare vengono
1539 \item Il valore di \var{msg\_lspid}, che viene impostato al \acr{pid} del
1541 \item Il valore di \var{msg\_qnum}, che viene incrementato di uno.
1542 \item Il valore \var{msg\_stime}, che viene impostato al tempo corrente.
1546 La funzione che permette di estrarre da una coda un messaggio (che sarà
1547 rimosso dalla stessa) è \func{msgrcv}; il suo prototipo è:
1549 \headdecl{sys/types.h}
1550 \headdecl{sys/ipc.h}
1551 \headdecl{sys/msg.h}
1553 \funcdecl{ssize\_t msgrcv(int msqid, struct msgbuf *msgp, size\_t msgsz,
1554 long msgtyp, int msgflg)}
1556 Legge un messaggio dalla coda \param{msqid}.
1558 \bodydesc{La funzione restituisce il numero di byte letti in caso di
1559 successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà uno
1562 \item[\macro{EACCES}] Non si hanno i privilegi di accesso sulla coda.
1563 \item[\macro{EIDRM}] La coda è stata cancellata.
1564 \item[\macro{E2BIG}] Il testo del messaggio è più lungo di \param{msgsz} e
1565 non si è specificato \macro{MSG\_NOERROR} in \param{msgflg}.
1566 \item[\macro{EINTR}] La funzione è stata interrotta da un segnale mentre era
1567 in attesa di ricevere un messaggio.
1568 \item[\macro{EINVAL}] Si è specificato un \param{msgid} invalido o un valore
1569 di \param{msgsz} negativo.
1571 ed inoltre \macro{EFAULT}.
1575 La funzione legge un messaggio dalla coda specificata scrivendolo nel buffer
1576 indicato da \param{msgp}, che avrà un formato analogo a quello di
1577 \figref{fig:ipc_msbuf}. L'argomento \param{msgsz} indica la lunghezza massima
1578 del testo del messaggio (equivalente al valore del parametro \macro{LENGTH}
1579 nell'esempio di \figref{fig:ipc_msbuf}).
1581 Se il testo del messaggio ha lunghezza inferiore a \param{msgsz} esso viene
1582 rimosso dalla coda; in caso contrario, se \param{msgflg} è impostato a
1583 \macro{MSG\_NOERROR}, il messaggio viene troncato e la parte in eccesso viene
1584 perduta, altrimenti il messaggio non viene estratto e la funzione ritorna con
1585 un errore di \macro{E2BIG}.
1587 L'argomento \param{msgtyp} permette di restringere la ricerca ad un
1588 sottoinsieme dei messaggi presenti sulla coda; la ricerca infatti è fatta con
1589 una scansione della struttura mostrata in \figref{fig:ipc_mq_schema},
1590 restituendo il primo messaggio incontrato che corrisponde ai criteri
1591 specificati (che quindi, visto che i messaggi vengono sempre inseriti dalla
1592 coda, è quello meno recente); in particolare:
1594 \item se \param{msgtyp} è 0 viene estratto il messaggio in cima alla coda, cioè
1595 quello fra i presenti che è stato inserito inserito per primo.
1596 \item se \param{msgtyp} è positivo viene estratto il primo messaggio il cui
1597 tipo (il valore del campo \var{mtype}) corrisponde al valore di
1599 \item se \param{msgtyp} è negativo viene estratto il primo fra i messaggi con
1600 il tipo di valore più basso, fra tutti quelli con un tipo inferiore al
1601 valore assoluto di \param{msgtyp}.
1604 Il valore di \param{msgflg} permette di controllare il comportamento della
1605 funzione, esso può essere nullo o una maschera binaria composta da uno o più
1606 valori. Oltre al precedente \macro{MSG\_NOERROR}, sono possibili altri due
1607 valori: \macro{MSG\_EXCEPT}, che permette, quando \param{msgtyp} è positivo,
1608 di leggere il primo messaggio nella coda con tipo diverso da \param{msgtyp}, e
1609 \macro{IPC\_NOWAIT} che causa il ritorno immediato della funzione quando non
1610 ci sono messaggi sulla coda.
1612 Il comportamento usuale della funzione infatti, se non ci sono messaggi
1613 disponibili per la lettura, è di bloccare il processo in stato di
1614 \textit{sleep}. Nel caso però si sia specificato \macro{IPC\_NOWAIT} la
1615 funzione ritorna immediatamente con un errore \macro{ENOMSG}. Altrimenti la
1616 funzione ritorna normalmente non appena viene inserito un messaggio del tipo
1617 desiderato, oppure ritorna con errore qualora la coda sia rimossa (con
1618 \var{errno} impostata a \macro{EIDRM}) o se il processo viene interrotto da un
1619 segnale (con \var{errno} impostata a \macro{EINTR}).
1621 Una volta completata con successo l'estrazione del messaggio dalla coda, la
1622 funzione aggiorna i dati mantenuti in \var{msqid\_ds}, in particolare vengono
1625 \item Il valore di \var{msg\_lrpid}, che viene impostato al \acr{pid} del
1627 \item Il valore di \var{msg\_qnum}, che viene decrementato di uno.
1628 \item Il valore \var{msg\_rtime}, che viene impostato al tempo corrente.
1631 Come esempio dell'uso delle code di messaggi possiamo riscrivere il nostro
1632 server di \textit{fortunes} usando queste al posto delle fifo. In questo caso
1633 useremo una coda di messaggi, usando il \acr{pid} del client come valore per
1634 il tipo di messaggio, per restituire indietro le frasi ai client.
1636 \subsection{Semafori}
1637 \label{sec:ipc_sysv_sem}
1639 I semafori non sono meccanismi di intercomunicazione diretta come quelli
1640 (pipe, fifo e code di messaggi) visti finora, e non consentono di scambiare
1641 dati fra processi, ma servono piuttosto come meccanismi di sincronizzazione o
1642 di protezione per le \textsl{sezioni critiche}\index{sezioni critiche} del
1643 codice (si ricordi quanto detto in \secref{sec:proc_race_cond}).
1645 Un semaforo è uno speciale contatore, mantenuto nel kernel, che permette, a
1646 seconda del suo valore, di consentire o meno la prosecuzione dell'esecuzione
1647 di un programma. In questo modo l'accesso ad una risorsa condivisa da più
1648 processi può essere controllato, associando ad essa un semaforo che consente
1649 di assicurare che non più di un processo alla volta possa usarla.
1651 Il concetto di semaforo è uno dei concetti base nella programmazione ed è
1652 assolutamente generico, così come del tutto generali sono modalità con cui lo
1653 si utilizza. Un processo che deve accedere ad una risorsa eseguirà un
1654 controllo del semaforo: se questo è positivo il suo valore sarà decrementato,
1655 indicando che si è consumato una unità della risorsa, ed il processo potrà
1656 proseguire nell'utilizzo di quest'ultima, provvedendo a rilasciarla, una volta
1657 completate le operazioni volute, reincrementando il semaforo.
1659 Se al momento del controllo il valore del semaforo è nullo, siamo invece in
1660 una situazione in cui la risorsa non è disponibile, ed il processo si
1661 bloccherà in stato di \textit{sleep} fin quando chi la sta utilizzando non la
1662 rilascerà, incrementando il valore del semaforo. Non appena il semaforo torna
1663 positivo, indicando che la risorsa è disponibile, il processo sarà svegliato,
1664 e si potrà operare come nel caso precedente (decremento del semaforo, accesso
1665 alla risorsa, incremento del semaforo).
1667 Per poter implementare questo tipo di logica le operazioni di controllo e
1668 decremento del contatore associato al semaforo devono essere atomiche,
1669 pertanto una realizzazione di un oggetto di questo tipo è necessariamente
1670 demandata al kernel. La forma più semplice di semaforo è quella del
1671 \textsl{semaforo binario}, o \textit{mutex}, in cui un valore diverso da zero
1672 (normalmente 1) indica la libertà di accesso, e un valore nullo l'occupazione
1673 della risorsa; in generale però si possono usare semafori con valori interi,
1674 utilizzando il valore del contatore come indicatore del ``numero di risorse''
1677 Il sistema di comunicazione interprocesso di System V IPC prevede anche i
1678 semafori, ma gli oggetti utilizzati non sono semafori singoli, ma gruppi di
1679 semafori detti \textsl{insiemi} (o \textit{semaphore set}); la funzione che
1680 permette di creare o ottenere l'identificatore di un insieme di semafori è
1681 \func{semget}, ed il suo prototipo è:
1683 \headdecl{sys/types.h}
1684 \headdecl{sys/ipc.h}
1685 \headdecl{sys/sem.h}
1687 \funcdecl{int semget(key\_t key, int nsems, int flag)}
1689 Restituisce l'identificatore di un insieme di semafori.
1691 \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
1692 in caso di errore, nel qual caso \var{errno} assumerà gli stessi valori
1693 visti per \func{msgget}.}
1696 La funzione è del tutto analoga a \func{msgget}, solo che in questo caso
1697 restituisce l'identificatore di un insieme di semafori, in particolare è
1698 identico l'uso degli argomenti \param{key} e \param{flag}, per cui non
1699 ripeteremo quanto detto al proposito in \secref{sec:ipc_sysv_mq}. L'argomento
1700 \param{nsems} permette di specificare quanti semafori deve contenere l'insieme
1701 quando se ne richieda la creazione, e deve essere nullo quando si effettua una
1702 richiesta dell'identificatore di un insieme già esistente.
1704 Purtroppo questa implementazione complica inutilmente lo schema elementare che
1705 abbiamo descritto, dato che non è possibile definire un singolo semaforo, ma
1706 se ne deve creare per forza un insieme. Ma questa in definitiva è solo una
1707 complicazione inutile, il problema è che i semafori del System V IPC soffrono
1708 di altri due, ben più gravi, difetti.
1710 Il primo difetto è che non esiste una funzione che permetta di creare ed
1711 inizializzare un semaforo in un'unica chiamata; occorre prima creare l'insieme
1712 dei semafori con \func{semget} e poi inizializzarlo con \func{semctl}, si
1713 perde così ogni possibilità di eseguire atomicamente questa operazione.
1715 Il secondo difetto deriva dalla caratteristica generale degli oggetti del
1716 System V IPC di essere risorse globali di sistema, che non vengono cancellate
1717 quando nessuno le usa più; ci si così a trova a dover affrontare
1718 esplicitamente il caso in cui un processo termina per un qualche errore,
1719 lasciando un semaforo occupato, che resterà tale fino al successivo riavvio
1720 del sistema. Come vedremo esistono delle modalità per evitare tutto ciò, ma
1721 diventa necessario indicare esplicitamente che si vuole il ripristino del
1722 semaforo all'uscita del processo.
1724 \begin{figure}[!htb]
1725 \footnotesize \centering
1726 \begin{minipage}[c]{15cm}
1727 \begin{lstlisting}[labelstep=0]{}
1730 struct ipc_perm sem_perm; /* operation permission struct */
1731 time_t sem_otime; /* last semop() time */
1732 time_t sem_ctime; /* last time changed by semctl() */
1733 unsigned long int sem_nsems; /* number of semaphores in set */
1738 \caption{La struttura \var{semid\_ds}, associata a ciascun insieme di
1740 \label{fig:ipc_semid_sd}
1743 A ciascun insieme di semafori è associata una struttura \var{semid\_ds},
1744 riportata in \figref{fig:ipc_semid_sd}. Come nel caso delle code di messaggi
1745 quando si crea un nuovo insieme di semafori con \func{semget} questa struttura
1746 viene inizializzata, in particolare il campo \var{sem\_perm} viene
1747 inizializzato come illustrato in \secref{sec:ipc_sysv_access_control} (si
1748 ricordi che in questo caso il permesso di scrittura è in realtà permesso di
1749 alterare il semaforo), per quanto riguarda gli altri campi invece:
1751 \item il campo \var{sem\_nsems}, che esprime il numero di semafori
1752 nell'insieme, viene inizializzato al valore di \param{nsems}.
1753 \item il campo \var{sem\_ctime}, che esprime il tempo di creazione
1754 dell'insieme, viene inizializzato al tempo corrente
1755 \item il campo \var{sem\_otime}, che esprime il tempo dell'ultima operazione
1756 effettuata, viene inizializzato a zero.
1759 Ciascun semaforo dell'insieme è realizzato come una struttura di tipo
1760 \var{sem} che ne contiene i dati essenziali, la sua definizione\footnote{si è
1761 riportata la definizione originaria del kernel 1.0, che contiene la prima
1762 realizzazione del System V IPC in Linux. In realtà questa struttura ormai è
1763 ridotta ai soli due primi membri, e gli altri vengono calcolati
1764 dinamicamente. La si è utilizzata a scopo di esempio, perché indica tutti i
1765 valori associati ad un semaforo, restituiti dalle funzioni di controllo, e
1766 citati dalla pagine di manuale.} è riportata in \figref{fig:ipc_sem}. Di
1767 norma questa struttura non è accessibile in user space, ma lo sono, in maniera
1768 indiretta, tramite l'uso delle funzioni di controllo, i valori in essa
1769 specificati, che indicano rispettivamente: il valore del semaforo, il
1770 \acr{pid} dell'ultimo processo che ha eseguito una operazione, il numero di
1771 processi in attesa che esso venga incrementato ed il numero di processi in
1772 attesa che esso si annulli.
1774 \begin{figure}[!htb]
1775 \footnotesize \centering
1776 \begin{minipage}[c]{15cm}
1777 \begin{lstlisting}[labelstep=0]{}
1779 short sempid; /* pid of last operation */
1780 ushort semval; /* current value */
1781 ushort semncnt; /* num procs awaiting increase in semval */
1782 ushort semzcnt; /* num procs awaiting semval = 0 */
1787 \caption{La struttura \var{sem}, che contiene i dati di un singolo semaforo.}
1791 Come per le code di messaggi anche per gli insiemi di semafori esistono una
1792 serie di limiti, i cui valori sono associati ad altrettante costanti, che si
1793 sono riportate in \tabref{tab:ipc_sem_limits}. Alcuni di questi limiti sono
1794 al solito accessibili e modificabili attraverso \func{sysctl} o scrivendo
1795 direttamente nel file \file{/proc/sys/kernel/sem}.
1800 \begin{tabular}[c]{|c|r|p{8cm}|}
1802 \textbf{Costante} & \textbf{Valore} & \textbf{Significato} \\
1805 \macro{SEMMNI}& 128 & Numero massimo di insiemi di semafori. \\
1806 \macro{SEMMSL}& 250 & Numero massimo di semafori per insieme.\\
1807 \macro{SEMMNS}&\macro{SEMMNI}*\macro{SEMMSL}& Numero massimo di semafori
1809 \macro{SEMVMX}& 32767 & Massimo valore per un semaforo.\\
1810 \macro{SEMOPM}& 32 & Massimo numero di operazioni per chiamata a
1812 \macro{SEMMNU}&\macro{SEMMNS}& Massimo numero di strutture di ripristino.\\
1813 \macro{SEMUME}&\macro{SEMOPM}& Massimo numero di voci di ripristino.\\
1814 \macro{SEMAEM}&\macro{SEMVMX}& valore massimo per l'aggiustamento
1818 \caption{Valori delle costanti associate ai limiti degli insiemi di
1819 semafori, definite in \file{linux/sem.h}.}
1820 \label{tab:ipc_sem_limits}
1823 La funzione che permette di effettuare le varie operazioni di controllo sui
1824 semafori (fra le quali, come accennato, è impropriamente compresa anche la
1825 loro inizializzazione) è \func{semctl}; il suo prototipo è:
1827 \headdecl{sys/types.h}
1828 \headdecl{sys/ipc.h}
1829 \headdecl{sys/sem.h}
1831 \funcdecl{int semctl(int semid, int semnum, int cmd)}
1832 \funcdecl{int semctl(int semid, int semnum, int cmd, union semun arg)}
1834 Esegue le operazioni di controllo su un semaforo o un insieme di semafori.
1836 \bodydesc{La funzione restituisce in caso di successo un valore positivo
1837 quanto usata con tre argomenti ed un valore nullo quando usata con
1838 quattro. In caso di errore restituisce -1, ed \var{errno} assumerà uno dei
1841 \item[\macro{EACCES}] Il processo non ha i privilegi per eseguire
1842 l'operazione richiesta.
1843 \item[\macro{EIDRM}] L'insieme di semafori è stato cancellato.
1844 \item[\macro{EPERM}] Si è richiesto \macro{IPC\_SET} o \macro{IPC\_RMID} ma
1845 il processo non ha privilegi sufficienti ad eseguire l'operazione.
1846 \item[\macro{ERANGE}] Si è richiesto \macro{SETALL} \macro{SETVAL} ma il
1847 valore a cui si vuole impostare il semaforo è minore di zero o maggiore
1850 ed inoltre \macro{EFAULT} ed \macro{EINVAL}.
1854 La funzione può avere tre o quattro parametri, a seconda dell'operazione
1855 specificata con \param{cmd}, ed opera o sull'intero insieme specificato da
1856 \param{semid} o sul singolo semaforo di un insieme, specificato da
1859 Qualora la funzione operi con quattro argomenti \param{arg} è
1860 un argomento generico, che conterrà un dato diverso a seconda dell'azione
1861 richiesta; per unificare l'argomento esso deve essere passato come una
1862 \var{union semun}, la cui definizione, con i possibili valori che può
1863 assumere, è riportata in \figref{fig:ipc_semun}.
1865 \begin{figure}[!htb]
1866 \footnotesize \centering
1867 \begin{minipage}[c]{15cm}
1868 \begin{lstlisting}[labelstep=0]{}
1870 int val; /* value for SETVAL */
1871 struct semid_ds *buf; /* buffer for IPC_STAT, IPC_SET */
1872 unsigned short *array; /* array for GETALL, SETALL */
1873 /* Linux specific part: */
1874 struct seminfo *__buf; /* buffer for IPC_INFO */
1879 \caption{La definizione dei possibili valori di una \var{union semun}, usata
1880 come quarto argomento della funzione \func{semctl}.}
1881 \label{fig:ipc_semun}
1884 Come già accennato sia il comportamento della funzione che il numero di
1885 parametri con cui deve essere invocata, dipendono dal valore dell'argomento
1886 \param{cmd}, che specifica l'azione da intraprendere; i valori validi (che
1887 cioè non causano un errore di \macro{EINVAL}) per questo argomento sono i
1889 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
1890 \item[\macro{IPC\_STAT}] Legge i dati dell'insieme di semafori, copiando il
1891 contenuto della relativa struttura \var{semid\_ds} all'indirizzo specificato
1892 con \var{arg.buf}. Occorre avere il permesso di lettura. L'argomento
1893 \param{semnum} viene ignorato.
1894 \item[\macro{IPC\_RMID}] Rimuove l'insieme di semafori e le relative strutture
1895 dati, con effetto immediato. Tutti i processi che erano stato di
1896 \textit{sleep} vengono svegliati, ritornando con un errore di \macro{EIDRM}.
1897 L'userid effettivo del processo deve corrispondere o al creatore o al
1898 proprietario dell'insieme, o all'amministratore. L'argomento \param{semnum}
1900 \item[\macro{IPC\_SET}] Permette di modificare i permessi ed il proprietario
1901 dell'insieme. I valori devono essere passati in una struttura
1902 \var{semid\_ds} puntata da \param{arg.buf} di cui saranno usati soltanto i
1903 campi \var{sem\_perm.uid}, \var{sem\_perm.gid} e i nove bit meno
1904 significativi di \var{sem\_perm.mode}. L'userid effettivo del processo deve
1905 corrispondere o al creatore o al proprietario dell'insieme, o
1906 all'amministratore. L'argomento \param{semnum} viene ignorato.
1907 \item[\macro{GETALL}] Restituisce il valore corrente di ciascun semaforo
1908 dell'insieme (corrispondente al campo \var{semval} di \var{sem}) nel vettore
1909 indicato da \param{arg.array}. Occorre avere il permesso di lettura.
1910 L'argomento \param{semnum} viene ignorato.
1911 \item[\macro{GETNCNT}] Restituisce come valore di ritorno della funzione il
1912 numero di processi in attesa che il semaforo \param{semnum} dell'insieme
1913 \param{semid} venga incrementato (corrispondente al campo \var{semncnt} di
1914 \var{sem}); va invocata con tre argomenti. Occorre avere il permesso di
1916 \item[\macro{GETPID}] Restituisce come valore di ritorno della funzione il
1917 \acr{pid} dell'ultimo processo che ha compiuto una operazione sul semaforo
1918 \param{semnum} dell'insieme \param{semid} (corrispondente al campo
1919 \var{sempid} di \var{sem}); va invocata con tre argomenti. Occorre avere il
1920 permesso di lettura.
1921 \item[\macro{GETVAL}] Restituisce come valore di ritorno della funzione il il
1922 valore corrente del semaforo \param{semnum} dell'insieme \param{semid}
1923 (corrispondente al campo \var{semval} di \var{sem}); va invocata con tre
1924 argomenti. Occorre avere il permesso di lettura.
1925 \item[\macro{GETZCNT}] Restituisce come valore di ritorno della funzione il
1926 numero di processi in attesa che il valore del semaforo \param{semnum}
1927 dell'insieme \param{semid} diventi nullo (corrispondente al campo
1928 \var{semncnt} di \var{sem}); va invocata con tre argomenti. Occorre avere
1929 il permesso di lettura.
1930 \item[\macro{SETALL}] Inizializza il valore di tutti i semafori dell'insieme,
1931 aggiornando il campo \var{sem\_ctime} di \var{semid\_ds}. I valori devono
1932 essere passati nel vettore indicato da \param{arg.array}. Si devono avere i
1933 privilegi di scrittura sul semaforo. L'argomento \param{semnum} viene
1935 \item[\macro{SETVAL}] Inizializza il semaforo \param{semnum} al valore passato
1936 dall'argomento \param{arg.val}, aggiornando il campo \var{sem\_ctime} di
1937 \var{semid\_ds}. Si devono avere i privilegi di scrittura sul semaforo.
1940 Quando si imposta il valore di un semaforo (sia che lo si faccia per tutto
1941 l'insieme con \macro{SETALL}, che per un solo semaforo con \macro{SETVAL}), i
1942 processi in attesa su di esso reagiscono di conseguenza al cambiamento di
1943 valore. Inoltre la coda delle operazioni di ripristino viene cancellata per
1944 tutti i semafori il cui valore viene modificato.
1949 \begin{tabular}[c]{|c|l|}
1951 \textbf{Operazione} & \textbf{Valore restituito} \\
1954 \macro{GETNCNT}& valore di \var{semncnt}.\\
1955 \macro{GETPID} & valore di \var{sempid}.\\
1956 \macro{GETVAL} & valore di \var{semval}.\\
1957 \macro{GETZCNT}& valore di \var{semzcnt}.\\
1960 \caption{Valori di ritorno della funzione \func{semctl}.}
1961 \label{tab:ipc_semctl_returns}
1964 Il valore di ritorno della funzione in caso di successo dipende
1965 dall'operazione richiesta; per tutte le operazioni che richiedono quattro
1966 argomenti esso è sempre nullo, per le altre operazioni, elencate in
1967 \tabref{tab:ipc_semctl_returns} viene invece restituito il valore richiesto,
1968 corrispondente al campo della struttura \var{sem} indicato nella seconda
1969 colonna della tabella.
1971 Le operazioni ordinarie sui semafori, come l'acquisizione o il rilascio degli
1972 stessi (in sostanza tutte quelle non comprese nell'uso di \func{semctl})
1973 vengono effettuate con la funzione \func{semop}, il cui prototipo è:
1975 \headdecl{sys/types.h}
1976 \headdecl{sys/ipc.h}
1977 \headdecl{sys/sem.h}
1979 \funcdecl{int semop(int semid, struct sembuf *sops, unsigned nsops)}
1981 Esegue le operazioni ordinarie su un semaforo o un insieme di semafori.
1983 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1984 errore, nel qual caso \var{errno} assumerà uno dei valori:
1986 \item[\macro{EACCES}] Il processo non ha i privilegi per eseguire
1987 l'operazione richiesta.
1988 \item[\macro{EIDRM}] L'insieme di semafori è stato cancellato.
1989 \item[\macro{ENOMEM}] Si è richiesto un \macro{SEM\_UNDO} ma il sistema
1990 non ha le risorse per allocare la struttura di ripristino.
1991 \item[\macro{EAGAIN}] Un'operazione comporterebbe il blocco del processo,
1992 ma si è specificato \macro{IPC\_NOWAIT} in \var{sem\_flg}.
1993 \item[\macro{EINTR}] La funzione, bloccata in attesa dell'esecuzione
1994 dell'operazione, viene interrotta da un segnale.
1995 \item[\macro{E2BIG}] L'argomento \param{nsops} è maggiore del numero
1996 massimo di operazioni \macro{SEMOPM}.
1997 \item[\macro{ERANGE}] Per alcune operazioni il valore risultante del
1998 semaforo viene a superare il limite massimo \macro{SEMVMX}.
2000 ed inoltre \macro{EFAULT} ed \macro{EINVAL}.
2004 La funzione permette di eseguire operazioni multiple sui singoli semafori di
2005 un insieme. La funzione richiede come primo argomento l'identificatore
2006 \param{semid} dell'insieme su cui si vuole operare. Il numero di operazioni da
2007 effettuare viene specificato con l'argomento \param{nsop}, mentre il loro
2008 contenuto viene passato con un puntatore ad un vettore di strutture
2009 \var{sembuf} nell'argomento \param{sops}. Le operazioni richieste vengono
2010 effettivamente eseguite se e soltanto se è possibile effettuarle tutte quante.
2012 \begin{figure}[!htb]
2013 \footnotesize \centering
2014 \begin{minipage}[c]{15cm}
2015 \begin{lstlisting}[labelstep=0]{}
2018 unsigned short int sem_num; /* semaphore number */
2019 short int sem_op; /* semaphore operation */
2020 short int sem_flg; /* operation flag */
2025 \caption{La struttura \var{sembuf}, usata per le operazioni sui
2027 \label{fig:ipc_sembuf}
2030 Il contenuto di ciascuna operazione deve essere specificato attraverso una
2031 opportuna struttura \var{sembuf} (la cui definizione è riportata in
2032 \figref{fig:ipc_sembuf}) che il programma chiamante deve avere cura di
2033 allocare in un opportuno vettore. La struttura permette di indicare il
2034 semaforo su cui operare, il tipo di operazione, ed un flag di controllo.
2036 Il campo \var{sem\_num} serve per indicare a quale semaforo dell'insieme fa
2037 riferimento l'operazione; si ricordi che i semafori sono numerati come in un
2038 vettore, per cui il primo semaforo corrisponde ad un valore nullo di
2041 Il campo \var{sem\_flg} è un flag, mantenuto come maschera binaria, per il
2042 quale possono essere impostati i due valori \macro{IPC\_NOWAIT} e
2043 \macro{SEM\_UNDO}. Impostando \macro{IPC\_NOWAIT} si fa si che, invece di
2044 bloccarsi (in tutti quei casi in cui l'esecuzione di una operazione richiede
2045 che il processo vada in stato di \textit{sleep}), \func{semop} ritorni
2046 immediatamente con un errore di \macro{EAGAIN}. Impostando \macro{SEM\_UNDO}
2047 si richiede invece che l'operazione venga registrata in modo che il valore del
2048 semaforo possa essere ripristinato all'uscita del processo.
2050 Infine \var{sem\_op} è il campo che controlla l'operazione che viene eseguita
2051 e determina il comportamento della chiamata a \func{semop}; tre sono i casi
2053 \begin{basedescript}{\desclabelwidth{2.0cm}}
2054 \item[\var{sem\_op}$>0$] In questo caso il valore di \var{sem\_op} viene
2055 aggiunto al valore corrente di \var{semval}. La funzione ritorna
2056 immediatamente (con un errore di \macro{ERANGE} qualora si sia superato il
2057 limite \macro{SEMVMX}) ed il processo non viene bloccato in nessun caso.
2058 Specificando \macro{SEM\_UNDO} si aggiorna il contatore per il ripristino
2059 del valore del semaforo. Al processo chiamante è richiesto il privilegio di
2060 alterazione (scrittura) sull'insieme di semafori.
2062 \item[\var{sem\_op}$=0$] Nel caso \var{semval} sia zero l'esecuzione procede
2063 immediatamente. Se \var{semval} è diverso da zero il comportamento è
2064 controllato da \var{sem\_flg}, se è stato impostato \macro{IPC\_NOWAIT} la
2065 funzione ritorna con un errore di \macro{EAGAIN}, altrimenti viene
2066 incrementato \var{semzcnt} di uno ed il processo resta in stato di
2067 \textit{sleep} fintanto che non si ha una delle condizioni seguenti:
2069 \item \var{semval} diventa zero, nel qual caso \var{semzcnt} viene
2070 decrementato di uno.
2071 \item l'insieme di semafori viene rimosso, nel qual caso \func{semop} ritorna
2072 un errore di \macro{EIDRM}.
2073 \item il processo chiamante riceve un segnale, nel qual caso \var{semzcnt}
2074 viene decrementato di uno e \func{semop} ritorna un errore di
2077 Al processo chiamante è richiesto il privilegio di lettura dell'insieme dei
2080 \item[\var{sem\_op}$<0$] Nel caso in cui \var{semval} è maggiore o uguale del
2081 valore assoluto di \var{sem\_op} (se cioè la somma dei due valori resta
2082 positiva o nulla) i valori vengono sommati e la funzione ritorna
2083 immediatamente; qualora si sia impostato \macro{SEM\_UNDO} viene anche
2084 aggiornato il contatore per il ripristino del valore del semaforo. In caso
2085 contrario (quando cioè la somma darebbe luogo ad un valore di \var{semval}
2086 negativo) se si è impostato \macro{IPC\_NOWAIT} la funzione ritorna con un
2087 errore di \macro{EAGAIN}, altrimenti viene incrementato di uno \var{semncnt}
2088 ed il processo resta in stato di \textit{sleep} fintanto che non si ha una
2089 delle condizioni seguenti:
2091 \item \var{semval} diventa maggiore o uguale del valore assoluto di
2092 \var{sem\_op}, nel qual caso \var{semncnt} viene decrementato di uno, il
2093 valore di \var{sem\_op} viene sommato a \var{semval}, e se era stato
2094 impostato \macro{SEM\_UNDO} viene aggiornato il contatore per il
2095 ripristino del valore del semaforo.
2096 \item l'insieme di semafori viene rimosso, nel qual caso \func{semop} ritorna
2097 un errore di \macro{EIDRM}.
2098 \item il processo chiamante riceve un segnale, nel qual caso \var{semncnt}
2099 viene decrementato di uno e \func{semop} ritorna un errore di
2102 Al processo chiamante è richiesto il privilegio di alterazione (scrittura)
2103 sull'insieme di semafori.
2106 In caso di successo della funzione viene aggiornato di \var{sempid} per ogni
2107 semaforo modificato al valore del \acr{pid} del processo chiamante; inoltre
2108 vengono pure aggiornati al tempo corrente i campi \var{sem\_otime} e
2111 Dato che, come già accennato in precedenza, in caso di uscita inaspettata i
2112 semafori possono restare occupati, abbiamo visto come \func{semop} permetta di
2113 attivare un meccanismo di ripristino attraverso l'uso del flag
2114 \macro{SEM\_UNDO}. Il meccanismo è implementato tramite una apposita struttura
2115 \var{sem\_undo}, associata ad ogni processo per ciascun semaforo che esso ha
2116 modificato; all'uscita i semafori modificati vengono ripristinati, e le
2117 strutture disallocate. Per mantenere coerente il comportamento queste
2118 strutture non vengono ereditate attraverso una \func{fork} (altrimenti si
2119 avrebbe un doppio ripristino), mentre vengono passate nell'esecuzione di una
2120 \func{exec} (altrimenti non si avrebbe ripristino).
2122 Resta comunque insoluto il problema di fondo di questo meccanismo, che non si
2123 adatta al concetto di operazioni atomiche su un semaforo, dato che le
2124 richieste di ripristino si accumulano attraverso diverse chiamate a
2125 \func{semop}, cosa succede se all'uscita del processo? Si deve porre il
2126 processo in stato di \textit{sleep} o andare avanti come se fosse stato
2127 impostato \macro{IPC\_NOWAIT}. La scelta del kernel è quella di effettuare le
2128 operazioni che non prevedono un blocco del processo ed ignorare
2129 silenziosamente le altre. Questo comporta che un comportamento senza problemi
2130 può essere garantito solo per i semafori privati.
2133 \subsection{Memoria condivisa}
2134 \label{sec:ipc_sysv_shm}
2136 Il terzo oggetto introdotto dal \textit{System V IPC} è quello della memoria
2137 condivisa. La funzione che permette di ottenerne uno è \func{shmget} ed il suo
2140 \headdecl{sys/types.h}
2141 \headdecl{sys/ipc.h}
2142 \headdecl{sys/shm.h}
2144 \funcdecl{int shmget(key\_t key, int size, int flag)}
2146 Restituisce l'identificatore di una memoria condivisa.
2148 \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
2149 in caso di errore, nel qual caso \var{errno} assumerà gli stessi valori
2150 visti per \func{msgget}.}
2153 La funzione, come \func{semget}, è del tutto analoga a \func{msgget}, ed
2154 identico è l'uso degli argomenti \param{key} e \param{flag}. L'argomento
2158 \section{La comunicazione fra processi di POSIX}
2159 \label{sec:ipc_posix}
2161 Lo standard POSIX.1b ha introdotto dei nuovi meccanismi di comunicazione,
2162 rifacendosi a quelli di System V, introducendo una nuova interfaccia che
2163 evitasse i principali problemi evidenziati in coda a
2164 \secref{sec:ipc_sysv_generic}.
2168 \subsection{Considerazioni generali}
2169 \label{sec:ipc_posix_generic}
2173 \subsection{Code di messaggi}
2174 \label{sec:ipc_posix_mq}
2177 \subsection{Semafori}
2178 \label{sec:ipc_posix_sem}
2181 \subsection{Memoria condivisa}
2182 \label{sec:ipc_posix_shm}
2184 %%% Local Variables:
2186 %%% TeX-master: "gapil"