Correzione ortografica.
[gapil.git] / ipc.tex
1 %% ipc.tex
2 %%
3 %% Copyright (C) 2000-2002 Simone Piccardi.  Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Prefazione",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
9 %% License".
10 %%
11 \chapter{La comunicazione fra processi}
12 \label{cha:IPC}
13
14
15 Uno degli aspetti fondamentali della programmazione in un sistema unix-like è
16 la comunicazione fra processi. In questo capitolo affronteremo solo i
17 meccanismi più elementari che permettono di mettere in comunicazione processi
18 diversi, come quelli tradizionali che coinvolgono \textit{pipe} e
19 \textit{fifo} e i meccanismi di intercomunicazione di System V e quelli POSIX.
20
21 Tralasceremo invece tutte le problematiche relative alla comunicazione
22 attraverso la rete (e le relative interfacce) che saranno affrontate in
23 dettaglio in un secondo tempo.  Non affronteremo neanche meccanismi più
24 complessi ed evoluti come le RPC (\textit{Remote Procedure Calls}) e CORBA
25 (\textit{Common Object Request Brocker Architecture}) che in genere sono
26 implementati con un ulteriore livello sopra i meccanismi elementari.
27
28
29 \section{La comunicazione fra processi tradizionale}
30 \label{sec:ipc_unix}
31
32 Il primo meccanismo di comunicazione fra processi introdotto nei sistemi Unix,
33 è quello delle cosiddette \textit{pipe}; esse costituiscono una delle
34 caratteristiche peculiari del sistema, in particolar modo dell'interfaccia a
35 linea di comando. In questa sezione descriveremo le sue basi, le funzioni che
36 ne gestiscono l'uso e le varie forme in cui si è evoluto.
37
38
39 \subsection{Le \textit{pipe} standard}
40 \label{sec:ipc_pipes}
41
42 Le \textit{pipe} nascono sostanzialmente con Unix, e sono il primo, e tuttora
43 uno dei più usati, meccanismi di comunicazione fra processi. Si tratta in
44 sostanza di una una coppia di file descriptor\footnote{si tenga presente che
45   le pipe sono oggetti creati dal kernel e non risiedono su disco.} connessi
46 fra di loro in modo che se quanto scrive su di uno si può rileggere
47 dall'altro. Si viene così a costituire un canale di comunicazione tramite i
48 due file descriptor, nella forma di un \textsl{tubo} (da cui il nome)
49 attraverso cui fluiscono i dati.
50
51 La funzione che permette di creare questa speciale coppia di file descriptor
52 associati ad una \textit{pipe} è appunto \funcd{pipe}, ed il suo prototipo è:
53 \begin{prototype}{unistd.h}
54 {int pipe(int filedes[2])} 
55   
56 Crea una coppia di file descriptor associati ad una \textit{pipe}.
57   
58   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
59     errore, nel qual caso \var{errno} potrà assumere i valori \errval{EMFILE},
60     \errval{ENFILE} e \errval{EFAULT}.}
61 \end{prototype}
62
63 La funzione restituisce la coppia di file descriptor nel vettore
64 \param{filedes}; il primo è aperto in lettura ed il secondo in scrittura. Come
65 accennato concetto di funzionamento di una pipe è semplice: quello che si
66 scrive nel file descriptor aperto in scrittura viene ripresentato tale e quale
67 nel file descriptor aperto in lettura. I file descriptor infatti non sono
68 connessi a nessun file reale, ma ad un buffer nel kernel, la cui dimensione è
69 specificata dal parametro di sistema \const{PIPE\_BUF}, (vedi
70 \secref{sec:sys_file_limits}). Lo schema di funzionamento di una pipe è
71 illustrato in \figref{fig:ipc_pipe_singular}, in cui sono illustrati i due
72 capi della pipe, associati a ciascun file descriptor, con le frecce che
73 indicano la direzione del flusso dei dati.
74
75 \begin{figure}[htb]
76   \centering
77   \includegraphics[height=5cm]{img/pipe}
78   \caption{Schema della struttura di una pipe.}
79   \label{fig:ipc_pipe_singular}
80 \end{figure}
81
82 Chiaramente creare una pipe all'interno di un singolo processo non serve a
83 niente; se però ricordiamo quanto esposto in \secref{sec:file_sharing}
84 riguardo al comportamento dei file descriptor nei processi figli, è immediato
85 capire come una pipe possa diventare un meccanismo di intercomunicazione. Un
86 processo figlio infatti condivide gli stessi file descriptor del padre,
87 compresi quelli associati ad una pipe (secondo la situazione illustrata in
88 \figref{fig:ipc_pipe_fork}). In questo modo se uno dei processi scrive su un
89 capo della pipe, l'altro può leggere.
90
91 \begin{figure}[htb]
92   \centering
93   \includegraphics[height=5cm]{img/pipefork}
94   \caption{Schema dei collegamenti ad una pipe, condivisi fra processo padre e
95     figlio dopo l'esecuzione \func{fork}.}
96   \label{fig:ipc_pipe_fork}
97 \end{figure}
98
99 Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
100 comunicazione fra processi attraverso una pipe, utilizzando le proprietà
101 ordinarie dei file, ma ci mostra anche qual'è il principale\footnote{Stevens
102   in \cite{APUE} riporta come limite anche il fatto che la comunicazione è
103   unidirezionale, ma in realtà questo è un limite facilmente superabile usando
104   una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i
105 processi possano condividere i file descriptor della pipe, e per questo essi
106 devono comunque essere \textsl{parenti} (dall'inglese \textit{siblings}), cioè
107 o derivare da uno stesso processo padre in cui è avvenuta la creazione della
108 pipe, o, più comunemente, essere nella relazione padre/figlio.
109
110 A differenza di quanto avviene con i file normali, la lettura da una pipe può
111 essere bloccante (qualora non siano presenti dati), inoltre se si legge da una
112 pipe il cui capo in scrittura è stato chiuso, si avrà la ricezione di un EOF
113 (vale a dire che la funzione \func{read} ritornerà restituendo 0).  Se invece
114 si esegue una scrittura su una pipe il cui capo in lettura non è aperto il
115 processo riceverà il segnale \errcode{EPIPE}, e la funzione di scrittura
116 restituirà un errore di \errcode{EPIPE} (al ritorno del gestore, o qualora il
117 segnale sia ignorato o bloccato).
118
119 La dimensione del buffer della pipe (\const{PIPE\_BUF}) ci dà inoltre un'altra
120 importante informazione riguardo il comportamento delle operazioni di lettura
121 e scrittura su di una pipe; esse infatti sono atomiche fintanto che la
122 quantità di dati da scrivere non supera questa dimensione. Qualora ad esempio
123 si effettui una scrittura di una quantità di dati superiore l'operazione verrà
124 effettuata in più riprese, consentendo l'intromissione di scritture effettuate
125 da altri processi.
126
127
128 \subsection{Un esempio dell'uso delle pipe}
129 \label{sec:ipc_pipe_use}
130
131 Per capire meglio il funzionamento delle pipe faremo un esempio di quello che
132 è il loro uso più comune, analogo a quello effettuato della shell, e che
133 consiste nell'inviare l'output di un processo (lo standard output) sull'input
134 di un'altro. Realizzeremo il programma di esempio nella forma di un
135 \textit{CGI}\footnote{Un CGI (\textit{Common Gateway Interface}) è un
136   programma che permette la creazione dinamica di un oggetto da inserire
137   all'interno di una pagina HTML.}  per Apache, che genera una immagine JPEG
138 di un codice a barre, specificato come parametro di input.
139
140 Un programma che deve essere eseguito come \textit{CGI} deve rispondere a
141 delle caratteristiche specifiche, esso infatti non viene lanciato da una
142 shell, ma dallo stesso web server, alla richiesta di una specifica URL, che di
143 solito ha la forma:
144 \begin{verbatim}
145     http://www.sito.it/cgi-bin/programma?parametro
146 \end{verbatim}
147 ed il risultato dell'elaborazione deve essere presentato (con una intestazione
148 che ne descrive il mime-type) sullo standard output, in modo che il web-server
149 possa reinviarlo al browser che ha effettuato la richiesta, che in questo modo
150 è in grado di visualizzarlo opportunamente.
151
152 Per realizzare quanto voluto useremo in sequenza i programmi \cmd{barcode} e
153 \cmd{gs}, il primo infatti è in grado di generare immagini postscript di
154 codici a barre corrispondenti ad una qualunque stringa, mentre il secondo
155 serve per poter effettuare la conversione della stessa immagine in formato
156 JPEG. Usando una pipe potremo inviare l'output del primo sull'input del
157 secondo, secondo lo schema mostrato in \figref{fig:ipc_pipe_use}, in cui la
158 direzione del flusso dei dati è data dalle frecce continue.
159
160 \begin{figure}[htb]
161   \centering
162   \includegraphics[height=5cm]{img/pipeuse}
163   \caption{Schema dell'uso di una pipe come mezzo di comunicazione fra
164     due processi attraverso attraverso l'esecuzione una \func{fork} e la
165     chiusura dei capi non utilizzati.}
166   \label{fig:ipc_pipe_use}
167 \end{figure}
168
169 Si potrebbe obiettare che sarebbe molto più semplice salvare il risultato
170 intermedio su un file temporaneo. Questo però non tiene conto del fatto che un
171 \textit{CGI} deve poter gestire più richieste in concorrenza, e si avrebbe una
172 evidente race condition\index{race condition} in caso di accesso simultaneo a
173 detto file.\footnote{il problema potrebbe essere superato determinando in
174   anticipo un nome appropriato per il file temporaneo, che verrebbe utilizzato
175   dai vari sotto-processi, e cancellato alla fine della loro esecuzione; ma a
176   questo le cose non sarebbero più tanto semplici.}  L'uso di una pipe invece
177 permette di risolvere il problema in maniera semplice ed elegante, oltre ad
178 essere molto più efficiente, dato che non si deve scrivere su disco.
179
180 Il programma ci servirà anche come esempio dell'uso delle funzioni di
181 duplicazione dei file descriptor che abbiamo trattato in
182 \secref{sec:file_dup}, in particolare di \func{dup2}. È attraverso queste
183 funzioni infatti che è possibile dirottare gli stream standard dei processi
184 (che abbiamo visto in \secref{sec:file_std_descr} e
185 \secref{sec:file_std_stream}) sulla pipe. In \figref{fig:ipc_barcodepage_code}
186 abbiamo riportato il corpo del programma, il cui codice completo è disponibile
187 nel file \file{BarCodePage.c} che si trova nella directory dei sorgenti.
188
189
190 \begin{figure}[!htb]
191   \footnotesize \centering
192   \begin{minipage}[c]{15cm}
193     \begin{lstlisting}{}
194 int main(int argc, char *argv[], char *envp[])
195 {
196     ...
197     /* create two pipes, pipein and pipeout, to handle communication */
198     if ( (retval = pipe(pipein)) ) {
199         WriteMess("input pipe creation error");
200         exit(0);        
201     }
202     if ( (retval = pipe(pipeout)) ) {
203         WriteMess("output pipe creation error");
204         exit(0);        
205     }    
206     /* First fork: use child to run barcode program */
207     if ( (pid = fork()) == -1) {          /* on error exit */
208         WriteMess("child creation error");
209         exit(0);        
210     }
211     /* if child */
212     if (pid == 0) {
213         close(pipein[1]);                /* close pipe write end  */
214         dup2(pipein[0], STDIN_FILENO);   /* remap stdin to pipe read end */
215         close(pipeout[0]);
216         dup2(pipeout[1], STDOUT_FILENO); /* remap stdout in pipe output */
217         execlp("barcode", "barcode", size, NULL);
218     } 
219     close(pipein[0]);                    /* close input side of input pipe */
220     write(pipein[1], argv[1], strlen(argv[1]));  /* write parameter to pipe */
221     close(pipein[1]);                    /* closing write end */
222     waitpid(pid, NULL, 0);               /* wait child completion */
223     /* Second fork: use child to run ghostscript */
224     if ( (pid = fork()) == -1) {
225         WriteMess("child creation error");
226         exit(0);
227     }
228     /* second child, convert PS to JPEG  */
229     if (pid == 0) {                     
230         close(pipeout[1]);              /* close write end */
231         dup2(pipeout[0], STDIN_FILENO); /* remap read end to stdin */
232         /* send mime type */
233         write(STDOUT_FILENO, content, strlen(content));
234         execlp("gs", "gs", "-q", "-sDEVICE=jpeg", "-sOutputFile=-", "-", NULL);
235     }
236     /* still parent */
237     close(pipeout[1]); 
238     waitpid(pid, NULL, 0);
239     exit(0);
240 }
241     \end{lstlisting}
242   \end{minipage} 
243   \normalsize 
244   \caption{Sezione principale del codice del \textit{CGI} 
245     \file{BarCodePage.c}.}
246   \label{fig:ipc_barcodepage_code}
247 \end{figure}
248
249 La prima operazione del programma (\texttt{\small 4--12}) è quella di creare
250 le due pipe che serviranno per la comunicazione fra i due comandi utilizzati
251 per produrre il codice a barre; si ha cura di controllare la riuscita della
252 chiamata, inviando in caso di errore un messaggio invece dell'immagine
253 richiesta.\footnote{la funzione \func{WriteMess} non è riportata in
254   \secref{fig:ipc_barcodepage_code}; essa si incarica semplicemente di
255   formattare l'uscita alla maniera dei CGI, aggiungendo l'opportuno
256   \textit{mime type}, e formattando il messaggio in HTML, in modo che
257   quest'ultimo possa essere visualizzato correttamente da un browser.}
258
259 Una volta create le pipe, il programma può creare (\texttt{\small 13-17}) il
260 primo processo figlio, che si incaricherà (\texttt{\small 19--25}) di eseguire
261 \cmd{barcode}. Quest'ultimo legge dallo standard input una stringa di
262 caratteri, la converte nell'immagine postscript del codice a barre ad essa
263 corrispondente, e poi scrive il risultato direttamente sullo standard output.
264
265 Per poter utilizzare queste caratteristiche prima di eseguire \cmd{barcode} si
266 chiude (\texttt{\small 20}) il capo aperto in scrittura della prima pipe, e se
267 ne collega (\texttt{\small 21}) il capo in lettura allo standard input, usando
268 \func{dup2}. Si ricordi che invocando \func{dup2} il secondo file, qualora
269 risulti aperto, viene, come nel caso corrente, chiuso prima di effettuare la
270 duplicazione. Allo stesso modo, dato che \cmd{barcode} scrive l'immagine
271 postscript del codice a barre sullo standard output, per poter effettuare una
272 ulteriore redirezione il capo in lettura della seconda pipe viene chiuso
273 (\texttt{\small 22}) mentre il capo in scrittura viene collegato allo standard
274 output (\texttt{\small 23}).
275
276 In questo modo all'esecuzione (\texttt{\small 25}) di \cmd{barcode} (cui si
277 passa in \var{size} la dimensione della pagina per l'immagine) quest'ultimo
278 leggerà dalla prima pipe la stringa da codificare che gli sarà inviata dal
279 padre, e scriverà l'immagine postscript del codice a barre sulla seconda.
280
281 Al contempo una volta lanciato il primo figlio, il processo padre prima chiude
282 (\texttt{\small 26}) il capo inutilizzato della prima pipe (quello in input) e
283 poi scrive (\texttt{\small 27}) la stringa da convertire sul capo in output,
284 così che \cmd{barcode} possa riceverla dallo standard input. A questo punto
285 l'uso della prima pipe da parte del padre è finito ed essa può essere
286 definitivamente chiusa (\texttt{\small 28}), si attende poi (\texttt{\small
287   29}) che l'esecuzione di \cmd{barcode} sia completata.
288
289 Alla conclusione della sua esecuzione \cmd{barcode} avrà inviato l'immagine
290 postscript del codice a barre sul capo in scrittura della seconda pipe; a
291 questo punto si può eseguire la seconda conversione, da PS a JPEG, usando il
292 programma \cmd{gs}. Per questo si crea (\texttt{\small 30--34}) un secondo
293 processo figlio, che poi (\texttt{\small 35--42}) eseguirà questo programma
294 leggendo l'immagine postscript creata da \cmd{barcode} dallo standard input,
295 per convertirla in JPEG.
296
297 Per fare tutto ciò anzitutto si chiude (\texttt{\small 37}) il capo in
298 scrittura della seconda pipe, e se ne collega (\texttt{\small 38}) il capo in
299 lettura allo standard input. Per poter formattare l'output del programma in
300 maniera utilizzabile da un browser, si provvede anche \texttt{\small 40}) alla
301 scrittura dell'apposita stringa di identificazione del mime-type in testa allo
302 standard output. A questo punto si può invocare \texttt{\small 41}) \cmd{gs},
303 provvedendo gli appositi switch che consentono di leggere il file da
304 convertire dallo standard input e di inviare la conversione sullo standard
305 output.
306
307 Per completare le operazioni il processo padre chiude (\texttt{\small 44}) il
308 capo in scrittura della seconda pipe, e attende la conclusione del figlio
309 (\texttt{\small 45}); a questo punto può (\texttt{\small 46}) uscire. Si tenga
310 conto che l'operazione di chiudere il capo in scrittura della seconda pipe è
311 necessaria, infatti, se non venisse chiusa, \cmd{gs}, che legge il suo
312 standard input da detta pipe, resterebbe bloccato in attesa di ulteriori dati
313 in ingresso (l'unico modo che un programma ha per sapere che l'input è
314 terminato è rilevare che lo standard input è stato chiuso), e la \func{wait}
315 non ritornerebbe.
316
317
318 \subsection{Le funzioni \func{popen} e \func{pclose}}
319 \label{sec:ipc_popen}
320
321 Come si è visto la modalità più comune di utilizzo di una pipe è quella di
322 utilizzarla per fare da tramite fra output ed input di due programmi invocati
323 in sequenza; per questo motivo lo standard POSIX.2 ha introdotto due funzioni
324 che permettono di sintetizzare queste operazioni. La prima di esse si chiama
325 \funcd{popen} ed il suo prototipo è:
326 \begin{prototype}{stdio.h}
327 {FILE *popen(const char *command, const char *type)}
328
329 Esegue il programma \param{command}, di cui, a seconda di \param{type},
330 restituisce, lo standard input o lo standard output nella pipe collegata allo
331 stream restituito come valore di ritorno.
332   
333 \bodydesc{La funzione restituisce l'indirizzo dello stream associato alla pipe
334   in caso di successo e \val{NULL} per un errore, nel qual caso \var{errno}
335   potrà assumere i valori relativi alle sottostanti invocazioni di \func{pipe}
336   e \func{fork} o \errcode{EINVAL} se \param{type} non è valido.}
337 \end{prototype}
338
339 La funzione crea una pipe, esegue una \func{fork}, ed invoca il programma
340 \param{command} attraverso la shell (in sostanza esegue \file{/bin/sh} con il
341 flag \code{-c}); l'argomento \param{type} deve essere una delle due stringhe
342 \verb|"w"| o \verb|"r"|, per indicare se la pipe sarà collegata allo standard
343 input o allo standard output del comando invocato.
344
345 La funzione restituisce il puntatore allo stream associato alla pipe creata,
346 che sarà aperto in sola lettura (e quindi associato allo standard output del
347 programma indicato) in caso si sia indicato \code{"r"}, o in sola scrittura (e
348 quindi associato allo standard input) in caso di \code{"w"}.
349
350 Lo stream restituito da \func{popen} è identico a tutti gli effetti ai file
351 stream visti in \capref{cha:files_std_interface}, anche se è collegato ad una
352 pipe e non ad un inode\index{inode}, e viene sempre aperto in modalità
353 \textit{fully-buffered} (vedi \secref{sec:file_buffering}); l'unica differenza
354 con gli usuali stream è che dovrà essere chiuso dalla seconda delle due nuove
355 funzioni, \funcd{pclose}, il cui prototipo è:
356 \begin{prototype}{stdio.h}
357 {int pclose(FILE *stream)}
358
359 Chiude il file \param{stream}, restituito da una precedente \func{popen}
360 attendendo la terminazione del processo ad essa associato.
361   
362 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
363   errore; nel quel caso il valore di \var{errno} deriva dalle sottostanti
364   chiamate.}
365 \end{prototype}
366 \noindent che oltre alla chiusura dello stream si incarica anche di attendere
367 (tramite \func{wait4}) la conclusione del processo creato dalla precedente
368 \func{popen}.
369
370 Per illustrare l'uso di queste due funzioni riprendiamo il problema
371 precedente: il programma mostrato in \figref{fig:ipc_barcodepage_code} per
372 quanto funzionante, è (volutamente) codificato in maniera piuttosto complessa,
373 inoltre nella pratica sconta un problema di \cmd{gs} che non è in
374 grado\footnote{nella versione GNU Ghostscript 6.53 (2002-02-13).} di
375 riconoscere correttamente l'encapsulated postscript, per cui deve essere usato
376 il postscript e tutte le volte viene generata una pagina intera, invece che
377 una immagine delle dimensioni corrispondenti al codice a barre.
378
379 Se si vuole generare una immagine di dimensioni appropriate si deve usare un
380 approccio diverso. Una possibilità sarebbe quella di ricorrere ad ulteriore
381 programma, \cmd{epstopsf}, per convertire in PDF un file EPS (che può essere
382 generato da \cmd{barcode} utilizzando lo switch \cmd{-E}).  Utilizzando un PDF
383 al posto di un EPS \cmd{gs} esegue la conversione rispettando le dimensioni
384 originarie del codice a barre e produce un JPEG di dimensioni corrette.
385
386 Questo approccio però non funziona, per via di una delle caratteristiche
387 principali delle pipe. Per poter effettuare la conversione di un PDF infatti è
388 necessario, per la struttura del formato, potersi spostare (con \func{lseek})
389 all'interno del file da convertire; se si esegue la conversione con \cmd{gs}
390 su un file regolare non ci sono problemi, una pipe però è rigidamente
391 sequenziale, e l'uso di \func{lseek} su di essa fallisce sempre con un errore
392 di \errcode{ESPIPE}, rendendo impossibile la conversione.  Questo ci dice che
393 in generale la concatenazione di vari programmi funzionerà soltanto quando
394 tutti prevedono una lettura sequenziale del loro input.
395
396 Per questo motivo si è dovuto utilizzare un procedimento diverso, eseguendo
397 prima la conversione (sempre con \cmd{gs}) del PS in un altro formato
398 intermedio, il PPM,\footnote{il \textit{Portable PixMap file format} è un
399   formato usato spesso come formato intermedio per effettuare conversioni, è
400   infatti molto facile da manipolare, dato che usa caratteri ASCII per
401   memorizzare le immagini, anche se per questo è estremamente inefficiente.}
402 dal quale poi si può ottenere un'immagine di dimensioni corrette attraverso
403 vari programmi di manipolazione (\cmd{pnmcrop}, \cmd{pnmmargin}) che può
404 essere infine trasformata in PNG (con \cmd{pnm2png}).
405
406 In questo caso però occorre eseguire in sequenza ben quattro comandi diversi,
407 inviando l'output di ciascuno all'input del successivo, per poi ottenere il
408 risultato finale sullo standard output: un caso classico di utilizzazione
409 delle pipe, in cui l'uso di \func{popen} e \func{pclose} permette di
410 semplificare notevolmente la stesura del codice.
411
412 Nel nostro caso, dato che ciascun processo deve scrivere il suo output sullo
413 standard input del successivo, occorrerà usare \func{popen} aprendo la pipe in
414 scrittura. Il codice del nuovo programma è riportato in
415 \figref{fig:ipc_barcode_code}.  Come si può notare l'ordine di invocazione dei
416 programmi è l'inverso di quello in cui ci si aspetta che vengano
417 effettivamente eseguiti. Questo non comporta nessun problema dato che la
418 lettura su una pipe è bloccante, per cui ciascun processo, per quanto lanciato
419 per primo, si bloccherà in attesa di ricevere sullo standard input il
420 risultato dell'elaborazione del precedente, benchè quest'ultimo venga
421 invocato dopo.
422
423 \begin{figure}[!htb]
424   \footnotesize \centering
425   \begin{minipage}[c]{15cm}
426     \begin{lstlisting}{}
427 int main(int argc, char *argv[], char *envp[])
428 {
429     FILE *pipe[4];
430     FILE *pipein;
431     char *cmd_string[4]={
432         "pnmtopng",
433         "pnmmargin -white 10",
434         "pnmcrop",
435         "gs -sDEVICE=ppmraw -sOutputFile=- -sNOPAUSE -q - -c showpage -c quit"
436     };  
437     char content[]="Content-type: image/png\n\n";
438     int i;
439     /* write mime-type to stout */ 
440     write(STDOUT_FILENO, content, strlen(content));
441     /* execute chain of command */
442     for (i=0; i<4; i++) {
443         pipe[i] = popen(cmd_string[i], "w");
444         dup2(fileno(pipe[i]), STDOUT_FILENO); 
445     }
446     /* create barcode (in PS) */
447     pipein = popen("barcode", "w");
448     /* send barcode string to barcode program */
449     write(fileno(pipein), argv[1], strlen(argv[1]));
450     /* close all pipes (in reverse order) */
451     for (i=4; i==0; i--) {
452         pclose((pipe[i]));
453     }
454     exit(0);
455 }
456     \end{lstlisting}
457   \end{minipage} 
458   \normalsize 
459   \caption{Codice completo del \textit{CGI} \file{BarCode.c}.}
460   \label{fig:ipc_barcode_code}
461 \end{figure}
462
463 Nel nostro caso il primo passo (\texttt{\small 14}) è scrivere il mime-type
464 sullo standard output; a questo punto il processo padre non necessita più di
465 eseguire ulteriori operazioni sullo standard output e può tranquillamente
466 provvedere alla redirezione.
467
468 Dato che i vari programmi devono essere lanciati in successione, si è
469 approntato un ciclo (\texttt{\small 15--19}) che esegue le operazioni in
470 sequenza: prima crea una pipe (\texttt{\small 17}) per la scrittura eseguendo
471 il programma con \func{popen}, in modo che essa sia collegata allo standard
472 input, e poi redirige (\texttt{\small 18}) lo standard output su detta pipe.
473
474 In questo modo il primo processo ad essere invocato (che è l'ultimo della
475 catena) scriverà ancora sullo standard output del processo padre, ma i
476 successivi, a causa di questa redirezione, scriveranno sulla pipe associata
477 allo standard input del processo invocato nel ciclo precedente.
478
479 Alla fine tutto quello che resta da fare è lanciare (\texttt{\small 21}) il
480 primo processo della catena, che nel caso è \cmd{barcode}, e scrivere
481 (\texttt{\small 23}) la stringa del codice a barre sulla pipe, che è collegata
482 al suo standard input, infine si può eseguire (\texttt{\small 24--27}) un
483 ciclo che chiuda, nell'ordine inverso rispetto a quello in cui le si sono
484 create, tutte le pipe create con \func{pclose}.
485
486
487 \subsection{Le \textit{pipe} con nome, o \textit{fifo}}
488 \label{sec:ipc_named_pipe}
489
490 Come accennato in \secref{sec:ipc_pipes} il problema delle \textit{pipe} è che
491 esse possono essere utilizzate solo da processi con un progenitore comune o
492 nella relazione padre/figlio; per superare questo problema lo standard POSIX.1
493 ha definito dei nuovi oggetti, le \textit{fifo}, che hanno le stesse
494 caratteristiche delle pipe, ma che invece di essere strutture interne del
495 kernel, visibili solo attraverso un file descriptor, sono accessibili
496 attraverso un inode\index{inode} che risiede sul filesystem, così che i
497 processi le possono usare senza dovere per forza essere in una relazione di
498 \textsl{parentela}.
499
500 Utilizzando una \textit{fifo} tutti i dati passeranno, come per le pipe,
501 attraverso un apposito buffer nel kernel, senza transitare dal filesystem;
502 l'inode\index{inode} allocato sul filesystem serve infatti solo a fornire un
503 punto di riferimento per i processi, che permetta loro di accedere alla stessa
504 fifo; il comportamento delle funzioni di lettura e scrittura è identico a
505 quello illustrato per le pipe in \secref{sec:ipc_pipes}.
506
507 Abbiamo già visto in \secref{sec:file_mknod} le funzioni \func{mknod} e
508 \func{mkfifo} che permettono di creare una fifo; per utilizzarne una un
509 processo non avrà che da aprire il relativo file speciale o in lettura o
510 scrittura; nel primo caso sarà collegato al capo di uscita della fifo, e dovrà
511 leggere, nel secondo al capo di ingresso, e dovrà scrivere.
512
513 Il kernel crea una singola pipe per ciascuna fifo che sia stata aperta, che può
514 essere acceduta contemporaneamente da più processi, sia in lettura che in
515 scrittura. Dato che per funzionare deve essere aperta in entrambe le
516 direzioni, per una fifo di norma la funzione \func{open} si blocca se viene
517 eseguita quando l'altro capo non è aperto.
518
519 Le fifo però possono essere anche aperte in modalità \textsl{non-bloccante},
520 nel qual caso l'apertura del capo in lettura avrà successo solo quando anche
521 l'altro capo è aperto, mentre l'apertura del capo in scrittura restituirà
522 l'errore di \errcode{ENXIO} fintanto che non verrà aperto il capo in lettura.
523
524 In Linux è possibile aprire le fifo anche in lettura/scrittura,\footnote{lo
525   standard POSIX lascia indefinito il comportamento in questo caso.}
526 operazione che avrà sempre successo immediato qualunque sia la modalità di
527 apertura (bloccante e non bloccante); questo può essere utilizzato per aprire
528 comunque una fifo in scrittura anche se non ci sono ancora processi il
529 lettura; è possibile anche usare la fifo all'interno di un solo processo, nel
530 qual caso però occorre stare molto attenti alla possibili situazioni di
531 stallo.\footnote{se si cerca di leggere da una fifo che non contiene dati si
532   avrà un deadlock\index{deadlock} immediato, dato che il processo si blocca e
533   non potrà quindi mai eseguire le funzioni di scrittura.}
534
535 Per la loro caratteristica di essere accessibili attraverso il filesystem, è
536 piuttosto frequente l'utilizzo di una fifo come canale di comunicazione nelle
537 situazioni un processo deve ricevere informazioni da altri. In questo caso è
538 fondamentale che le operazioni di scrittura siano atomiche; per questo si deve
539 sempre tenere presente che questo è vero soltanto fintanto che non si supera
540 il limite delle dimensioni di \const{PIPE\_BUF} (si ricordi quanto detto in
541 \secref{sec:ipc_pipes}).
542
543 A parte il caso precedente, che resta probabilmente il più comune, Stevens
544 riporta in \cite{APUE} altre due casistiche principali per l'uso delle fifo:
545 \begin{itemize}
546 \item Da parte dei comandi di shell, per evitare la creazione di file
547   temporanei quando si devono inviare i dati di uscita di un processo
548   sull'input di parecchi altri (attraverso l'uso del comando \cmd{tee}).
549   
550 \item Come canale di comunicazione fra client ed server (il modello
551   \textit{client-server} è illustrato in \secref{sec:net_cliserv}).
552 \end{itemize}
553
554 Nel primo caso quello che si fa è creare tante fifo, da usare come standard
555 input, quanti sono i processi a cui i vogliono inviare i dati, questi ultimi
556 saranno stati posti in esecuzione ridirigendo lo standard input dalle fifo, si
557 potrà poi eseguire il processo che fornisce l'output replicando quest'ultimo,
558 con il comando \cmd{tee}, sulle varie fifo.
559
560 Il secondo caso è relativamente semplice qualora si debba comunicare con un
561 processo alla volta (nel qual caso basta usare due fifo, una per leggere ed
562 una per scrivere), le cose diventano invece molto più complesse quando si
563 vuole effettuare una comunicazione fra il server ed un numero imprecisato di
564 client; se il primo infatti può ricevere le richieste attraverso una fifo```\textsl{nota}'', per le risposte non si può fare altrettanto, dato che, per
565 la struttura sequenziale delle fifo, i client dovrebbero sapere, prima di
566 leggerli, quando i dati inviati sono destinati a loro.
567
568 Per risolvere questo problema, si può usare un'architettura come quella
569 illustrata in \figref{fig:ipc_fifo_server_arch} in cui i client inviano le
570 richieste al server su una fifo nota mentre le risposte vengono reinviate dal
571 server a ciascuno di essi su una fifo temporanea creata per l'occasione.
572
573 \begin{figure}[htb]
574   \centering
575   \includegraphics[height=9cm]{img/fifoserver}
576   \caption{Schema dell'utilizzo delle fifo nella realizzazione di una
577   architettura di comunicazione client/server.}
578   \label{fig:ipc_fifo_server_arch}
579 \end{figure}
580
581 Come esempio di uso questa architettura e dell'uso delle fifo, abbiamo scritto
582 un server di \textit{fortunes}, che restituisce, alle richieste di un client,
583 un detto a caso estratto da un insieme di frasi; sia il numero delle frasi
584 dell'insieme, che i file da cui esse vengono lette all'avvio, sono importabili
585 da riga di comando. Il corpo principale del server è riportato in
586 \figref{fig:ipc_fifo_server}, dove si è tralasciata la parte che tratta la
587 gestione delle opzioni a riga di comando, che effettua il settaggio delle
588 variabili \var{fortunefilename}, che indica il file da cui leggere le frasi,
589 ed \var{n}, che indica il numero di frasi tenute in memoria, ad un valore
590 diverso da quelli preimpostati. Il codice completo è nel file
591 \file{FortuneServer.c}.
592
593 \begin{figure}[!htb]
594   \footnotesize \centering
595   \begin{minipage}[c]{15cm}
596     \begin{lstlisting}{}
597 char *fifoname = "/tmp/fortune.fifo";
598 int main(int argc, char *argv[])
599 {
600 /* Variables definition */
601     int i, n = 0;
602     char *fortunefilename = "/usr/share/games/fortunes/italia";
603     char **fortune;
604     char line[80];
605     int fifo_server, fifo_client;
606     int nread;
607     ...
608     if (n==0) usage();          /* if no pool depth exit printing usage info */
609     Signal(SIGTERM, HandSIGTERM);            /* set handlers for termination */
610     Signal(SIGINT, HandSIGTERM);
611     Signal(SIGQUIT, HandSIGTERM);
612     i = FortuneParse(fortunefilename, fortune, n);          /* parse phrases */
613     if (mkfifo(fifoname, 0622)) {  /* create well known fifo if does't exist */
614         if (errno!=EEXIST) {
615             perror("Cannot create well known fifo");
616             exit(1);
617         }
618     }
619     /* open fifo two times to avoid EOF */
620     fifo_server = open(fifoname, O_RDONLY);
621     if (fifo_server < 0) {
622         perror("Cannot open read only well known fifo");
623         exit(1);
624     }
625     if (open(fifoname, O_WRONLY) < 0) {                        
626         perror("Cannot open write only well known fifo");
627         exit(1);
628     }
629     /* Main body: loop over requests */
630     while (1) {
631         nread = read(fifo_server, line, 79);                 /* read request */
632         if (nread < 0) {
633             perror("Read Error");
634             exit(1);
635         }
636         line[nread] = 0;                       /* terminate fifo name string */
637         n = random() % i;                             /* select random value */
638         fifo_client = open(line, O_WRONLY);              /* open client fifo */
639         if (fifo_client < 0) {
640             perror("Cannot open");
641             exit(1);
642         }
643         nread = write(fifo_client,                           /* write phrase */
644                       fortune[n], strlen(fortune[n])+1);
645         close(fifo_client);                             /* close client fifo */
646     }
647 }
648     \end{lstlisting}
649   \end{minipage} 
650   \normalsize 
651   \caption{Sezione principale del codice del server di \textit{fortunes}
652     basato sulle fifo.}
653   \label{fig:ipc_fifo_server}
654 \end{figure}
655
656 Il server richiede (\texttt{\small 12}) che sia stata impostata una dimensione
657 dell'insieme delle frasi non nulla, dato che l'inizializzazione del vettore
658 \var{fortune} avviene solo quando questa dimensione viene specificata, la
659 presenza di un valore nullo provoca l'uscita dal programma attraverso la
660 routine (non riportata) che ne stampa le modalità d'uso.  Dopo di che installa
661 (\texttt{\small 13--15}) la funzione che gestisce i segnali di interruzione
662 (anche questa non è riportata in \figref{fig:ipc_fifo_server}) che si limita a
663 rimuovere dal filesystem la fifo usata dal server per comunicare.
664
665 Terminata l'inizializzazione (\texttt{\small 16}) si effettua la chiamata alla
666 funzione \code{FortuneParse} che legge dal file specificato in
667 \var{fortunefilename} le prime \var{n} frasi e le memorizza (allocando
668 dinamicamente la memoria necessaria) nel vettore di puntatori \var{fortune}.
669 Anche il codice della funzione non è riportato, in quanto non direttamente
670 attinente allo scopo dell'esempio.
671
672 Il passo successivo (\texttt{\small 17--22}) è quello di creare con
673 \func{mkfifo} la fifo nota sulla quale il server ascolterà le richieste,
674 qualora si riscontri un errore il server uscirà (escludendo ovviamente il caso
675 in cui la funzione \func{mkfifo} fallisce per la precedente esistenza della
676 fifo).
677
678 Una volta che si è certi che la fifo di ascolto esiste si procede
679 (\texttt{\small 23--32}) alla sua apertura. Questo viene fatto due volte
680 per evitare di dover gestire all'interno del ciclo principale il caso in cui
681 il server è in ascolto ma non ci sono client che effettuano richieste.
682 Si ricordi infatti che quando una fifo è aperta solo dal capo in lettura,
683 l'esecuzione di \func{read} ritorna con zero byte (si ha cioè una condizione
684 di end-of-file).
685
686 Nel nostro caso la prima apertura si bloccherà fintanto che un qualunque
687 client non apre a sua volta la fifo nota in scrittura per effettuare la sua
688 richiesta. Pertanto all'inizio non ci sono problemi, il client però, una volta
689 ricevuta la risposta, uscirà, chiudendo tutti i file aperti, compresa la fifo.
690 A questo punto il server resta (se non ci sono altri client che stanno
691 effettuando richieste) con la fifo chiusa sul lato in lettura e a questo punto
692 \func{read} non si bloccherà in attesa di input, ma ritornerà in continuazione
693 restituendo un end-of-file.\footnote{Si è usata questa tecnica per
694   compatibilità, Linux infatti supporta l'apertura delle fifo in
695   lettura/scrittura, per cui si sarebbe potuto effettuare una singola apertura
696   con \const{O\_RDWR}, la doppia apertura comunque ha il vantaggio che non si
697   può scrivere per errore sul capo aperto in sola lettura.}
698
699 Per questo motivo, dopo aver eseguito l'apertura in lettura (\texttt{\small
700   24--28}),\footnote{di solito si effettua l'apertura del capo in lettura in
701   modalità non bloccante, per evitare il rischio di uno stallo (se nessuno
702   apre la fifo in scrittura il processo non ritornerà mai dalla \func{open})
703   che nel nostro caso non esiste, mentre è necessario potersi bloccare in
704   lettura in attesa di una richiesta.} si esegue una seconda apertura in
705 scrittura (\texttt{\small 29--32}), scartando il relativo file descriptor che
706 non sarà mai usato, ma lasciando la fifo comunque aperta anche in scrittura,
707 cosicché le successive possano bloccarsi.
708
709 A questo punto si può entrare nel ciclo principale del programma che fornisce
710 le risposte ai client (\texttt{\small 34--50}), che viene eseguito
711 indefinitamente (l'uscita del server viene effettuata inviando un segnale, in
712 modo da passare attraverso la routine di chiusura che cancella la fifo). 
713
714 Il server è progettato per accettare come richieste dai client delle stringhe
715 che contengono il nome della fifo sulla quale deve essere inviata la risposta.
716 Per cui prima (\texttt{\small 35--39}) si esegue la lettura dalla stringa di
717 richiesta dalla fifo nota (che a questo punto si bloccherà tutte le volte che
718 non ci sono richieste). Dopo di che, una volta terminata la stringa
719 (\texttt{\small 40}) e selezionato (\texttt{\small 41}) un numero casuale per
720 ricavare la frase da inviare, si procederà (\texttt{\small 42--46})
721 all'apertura della fifo per la risposta, che \texttt{\small 47--48}) poi vi
722 sarà scritta. Infine (\texttt{\small 49}) si chiude la fifo di risposta che
723 non serve più. 
724
725 Il codice del client è invece riportato in \figref{fig:ipc_fifo_client}, anche
726 in questo caso si è omessa la gestione delle opzioni e la funzione che stampa
727 a video le informazioni di utilizzo ed esce, riportando solo la sezione
728 principale del programma e le definizioni delle variabili. Il codice completo
729 è nel file \file{FortuneClient.c} dei sorgenti allegati.
730
731 \begin{figure}[!htb]
732   \footnotesize \centering
733   \begin{minipage}[c]{15cm}
734     \begin{lstlisting}{}
735 int main(int argc, char *argv[])
736 {
737 /* Variables definition */
738     int n = 0;
739     char *fortunefilename = "/tmp/fortune.fifo";
740     char line[80];
741     int fifo_server, fifo_client;
742     char fifoname[80];
743     int nread;
744     char buffer[PIPE_BUF];
745     ...
746     snprintf(fifoname, 80, "/tmp/fortune.%d", getpid());     /* compose name */
747     if (mkfifo(fifoname, 0622)) {                        /* open client fifo */
748         if (errno!=EEXIST) {
749             perror("Cannot create well known fifo");
750             exit(-1);
751         }
752     }
753     fifo_server = open(fortunefilename, O_WRONLY);       /* open server fifo */
754     if (fifo_server < 0) {
755         perror("Cannot open well known fifo");
756         exit(-1);
757     }
758     nread = write(fifo_server, fifoname, strlen(fifoname)+1);  /* write name */
759     close(fifo_server);                                 /* close server fifo */
760     fifo_client = open(fifoname, O_RDONLY);              /* open client fifo */
761     if (fifo_client < 0) {
762         perror("Cannot open well known fifo");
763         exit(-1);
764     }
765     nread = read(fifo_client, buffer, sizeof(buffer));        /* read answer */
766     printf("%s", buffer);                                   /* print fortune */
767     close(fifo_client);                                      /* close client */
768     close(fifo_server);                                      /* close server */
769     unlink(fifoname);                                  /* remove client fifo */
770 }
771     \end{lstlisting}
772   \end{minipage} 
773   \normalsize 
774   \caption{Sezione principale del codice del client di \textit{fortunes}
775     basato sulle fifo.}
776   \label{fig:ipc_fifo_client}
777 \end{figure}
778
779 La prima istruzione (\texttt{\small 12}) compone il nome della fifo che dovrà
780 essere utilizzata per ricevere la risposta dal server.  Si usa il \acr{pid}
781 del processo per essere sicuri di avere un nome univoco; dopo di che
782 (\texttt{\small 13-18}) si procede alla creazione del relativo file, uscendo
783 in caso di errore (a meno che il file non sia già presente sul filesystem).
784
785 A questo punto il client può effettuare l'interrogazione del server, per
786 questo prima si apre la fifo nota (\texttt{\small 19--23}), e poi ci si scrive
787 (\texttt{\small 24}) la stringa composta in precedenza, che contiene il nome
788 della fifo da utilizzare per la risposta. Infine si richiude la fifo del
789 server che a questo punto non serve più (\texttt{\small 25}).
790
791 Inoltrata la richiesta si può passare alla lettura della risposta; anzitutto
792 si apre (\texttt{\small 26--30}) la fifo appena creata, da cui si deve
793 riceverla, dopo di che si effettua una lettura (\texttt{\small 31})
794 nell'apposito buffer; si è supposto, come è ragionevole, che le frasi inviate
795 dal server siano sempre di dimensioni inferiori a \const{PIPE\_BUF},
796 tralasciamo la gestione del caso in cui questo non è vero. Infine si stampa
797 (\texttt{\small 32}) a video la risposta, si chiude (\texttt{\small 33}) la
798 fifo e si cancella (\texttt{\small 34}) il relativo file.
799 Si noti come la fifo per la risposta sia stata aperta solo dopo aver inviato
800 la richiesta, se non si fosse fatto così si avrebbe avuto uno stallo, in
801 quanto senza la richiesta, il server non avrebbe potuto aprirne il capo in
802 scrittura e l'apertura si sarebbe bloccata indefinitamente.
803
804 Benché il nostro sistema client-server funzioni, la sua struttura è piuttosto
805 complessa e continua ad avere vari inconvenienti\footnote{lo stesso Stevens,
806   che esamina questa architettura in \cite{APUE}, nota come sia impossibile
807   per il server sapere se un client è andato in crash, con la possibilità di
808   far restare le fifo temporanee sul filesystem, di come sia necessario
809   intercettare \const{SIGPIPE} dato che un client può terminare dopo aver
810   fatto una richiesta, ma prima che la risposta sia inviata (cosa che nel
811   nostro esempio non è stata fatta).}; in generale infatti l'interfaccia delle
812 fifo non è adatta a risolvere questo tipo di problemi, che possono essere
813 affrontati in maniera più semplice ed efficace o usando i
814 \textit{socket}\index{socket} (che tratteremo in dettaglio a partire da
815 \capref{cha:socket_intro}) o ricorrendo a meccanismi di comunicazione diversi,
816 come quelli che esamineremo in seguito.
817
818
819
820 \subsection{La funzione \func{socketpair}}
821 \label{sec:ipc_socketpair}
822
823 Un meccanismo di comunicazione molto simile alle pipe, ma che non presenta il
824 problema della unidirezionalità del flusso dei dati, è quello dei cosiddetti
825 \textsl{socket locali} (o \textit{Unix domain socket}). Tratteremo l'argomento
826 dei \textit{socket}\index{socket} in \capref{cha:socket_intro},\footnote{si
827   tratta comunque di oggetti di comunicazione che, come le pipe, sono
828   utilizzati attraverso dei file descriptor.} nell'ambito dell'interfaccia
829 generale che essi forniscono per la programmazione di rete; e vedremo anche
830 (in~\secref{sec:sock_sa_local}) come si possono definire dei file speciali (di
831 tipo \textit{socket}, analoghi a quello associati alle fifo) cui si accede
832 però attraverso quella medesima interfaccia; vale però la pena esaminare qui
833 una modalità di uso dei socket locali\footnote{la funzione \func{socketpair} è
834   stata introdotta in BSD4.4, ma è supportata in genere da qualunque sistema
835   che fornisca l'interfaccia dei socket.} che li rende sostanzialmente
836 identici ad una pipe bidirezionale.
837
838 La funzione \funcd{socketpair} infatti consente di creare una coppia di file
839 descriptor connessi fra di loro (tramite un socket\index{socket}, appunto),
840 senza dover ricorrere ad un file speciale sul filesystem, i descrittori sono
841 del tutto analoghi a quelli che si avrebbero con una chiamata a \func{pipe},
842 con la sola differenza è che in questo caso il flusso dei dati può essere
843 effettuato in entrambe le direzioni. Il prototipo della funzione è:
844 \begin{functions}
845   \headdecl{sys/types.h} 
846   \headdecl{sys/socket.h} 
847   
848   \funcdecl{int socketpair(int domain, int type, int protocol, int sv[2])}
849   
850   Crea una coppia di socket\index{socket} connessi fra loro.
851   
852   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
853     errore, nel qual caso \var{errno} assumerà uno dei valori:
854   \begin{errlist}
855   \item[\errcode{EAFNOSUPPORT}] I socket\index{socket} locali non sono
856     supportati.
857   \item[\errcode{EPROTONOSUPPORT}] Il protocollo specificato non è supportato.
858   \item[\errcode{EOPNOTSUPP}] Il protocollo specificato non supporta la
859   creazione di coppie di socket\index{socket}.
860   \end{errlist}
861   ed inoltre \errval{EMFILE},  \errval{EFAULT}.
862 }
863 \end{functions}
864
865 La funzione restituisce in \param{sv} la coppia di descrittori connessi fra di
866 loro: quello che si scrive su uno di essi sarà ripresentato in input
867 sull'altro e viceversa. I parametri \param{domain}, \param{type} e
868 \param{protocol} derivano dall'interfaccia dei socket\index{socket} (che è
869 quella che fornisce il substrato per connettere i due descrittori), ma in
870 questo caso i soli valori validi che possono essere specificati sono
871 rispettivamente \const{AF\_UNIX}, \const{SOCK\_STREAM} e \val{0}.
872
873 L'utilità di chiamare questa funzione per evitare due chiamate a \func{pipe}
874 può sembrare limitata; in realtà l'utilizzo di questa funzione (e dei
875 socket\index{socket} locali in generale) permette di trasmettere attraverso le
876 linea non solo dei dati, ma anche dei file descriptor: si può cioè passare da
877 un processo ad un altro un file descriptor, con una sorta di duplicazione
878 dello stesso non all'interno di uno stesso processo, ma fra processi distinti
879 (torneremo su questa funzionalità in \secref{sec:xxx_fd_passing}).
880
881
882 \section{La comunicazione fra processi di System V}
883 \label{sec:ipc_sysv}
884
885 Benché le pipe e le fifo siano ancora ampiamente usate, esse scontano il
886 limite fondamentale che il meccanismo di comunicazione che forniscono è
887 rigidamente sequenziale: una situazione in cui un processo scrive qualcosa che
888 molti altri devono poter leggere non può essere implementata con una pipe.
889
890 Per questo nello sviluppo di System V vennero introdotti una serie di nuovi
891 oggetti per la comunicazione fra processi ed una nuova interfaccia di
892 programmazione, che fossero in grado di garantire una maggiore flessibilità.
893 In questa sezione esamineremo come Linux supporta quello che viene chiamato il
894 \textsl{Sistema di comunicazione inter-processo} di System V, cui da qui in
895 avanti faremo riferimento come \textit{SysV IPC} (dove IPC è la sigla di
896 \textit{Inter-Process Comunication}).
897
898
899
900 \subsection{Considerazioni generali}
901 \label{sec:ipc_sysv_generic}
902
903 La principale caratteristica del \textit{SysV IPC} è quella di essere basato
904 su oggetti permanenti che risiedono nel kernel. Questi, a differenza di quanto
905 avviene per i file descriptor, non mantengono un contatore dei riferimenti, e
906 non vengono cancellati dal sistema una volta che non sono più in uso.
907
908 Questo comporta due problemi: il primo è che, al contrario di quanto avviene
909 per pipe e fifo, la memoria allocata per questi oggetti non viene rilasciata
910 automaticamente quando non c'è più nessuno che li utilizzi, ed essi devono
911 essere cancellati esplicitamente, se non si vuole che restino attivi fino al
912 riavvio del sistema. Il secondo problema è che, dato che non c'è, come per i
913 file, un contatore del numero di riferimenti che ne indichi l'essere in uso,
914 essi possono essere cancellati anche se ci sono dei processi che li stanno
915 utilizzando, con tutte le conseguenze (negative) del caso.
916
917 Un'ulteriore caratteristica negativa è che gli oggetti usati nel \textit{SysV
918   IPC} vengono creati direttamente dal kernel, e sono accessibili solo
919 specificando il relativo \textsl{identificatore}. Questo è un numero
920 progressivo (un po' come il \acr{pid} dei processi) che il kernel assegna a
921 ciascuno di essi quanto vengono creati (sul procedimento di assegnazione
922 torneremo in \secref{sec:ipc_sysv_id_use}). L'identificatore viene restituito
923 dalle funzioni che creano l'oggetto, ed è quindi locale al processo che le ha
924 eseguite. Dato che l'identificatore viene assegnato dinamicamente dal kernel
925 non è possibile prevedere quale sarà, né utilizzare un qualche valore statico,
926 si pone perciò il problema di come processi diversi possono accedere allo
927 stesso oggetto.
928
929 Per risolvere il problema nella struttura \struct{ipc\_perm} che il kernel
930 associa a ciascun oggetto, viene mantenuto anche un campo apposito che
931 contiene anche una \textsl{chiave}, identificata da una variabile del tipo
932 primitivo \type{key\_t}, da specificare in fase di creazione dell'oggetto, e
933 tramite la quale è possibile ricavare l'identificatore.\footnote{in sostanza
934   si sposta il problema dell'accesso dalla classificazione in base
935   all'identificatore alla classificazione in base alla chiave, una delle tante
936   complicazioni inutili presenti nel \textit{SysV IPC}.} Oltre la chiave, la
937 struttura, la cui definizione è riportata in \figref{fig:ipc_ipc_perm},
938 mantiene varie proprietà ed informazioni associate all'oggetto.
939
940 \begin{figure}[!htb]
941   \footnotesize \centering
942   \begin{minipage}[c]{15cm}
943     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm ]{}
944 struct ipc_perm
945 {
946     key_t key;                        /* Key.  */
947     uid_t uid;                        /* Owner's user ID.  */
948     gid_t gid;                        /* Owner's group ID.  */
949     uid_t cuid;                       /* Creator's user ID.  */
950     gid_t cgid;                       /* Creator's group ID.  */
951     unsigned short int mode;          /* Read/write permission.  */
952     unsigned short int seq;           /* Sequence number.  */
953 };
954     \end{lstlisting}
955   \end{minipage} 
956   \normalsize 
957   \caption{La struttura \structd{ipc\_perm}, come definita in
958     \file{sys/ipc.h}.}
959   \label{fig:ipc_ipc_perm}
960 \end{figure}
961
962 Usando la stessa chiave due processi diversi possono ricavare l'identificatore
963 associato ad un oggetto ed accedervi. Il problema che sorge a questo punto è
964 come devono fare per accordarsi sull'uso di una stessa chiave. Se i processi
965 sono \textsl{parenti} la soluzione è relativamente semplice, in tal caso
966 infatti si può usare il valore speciale \texttt{IPC\_PRIVATE} per creare un
967 nuovo oggetto nel processo padre, l'identificatore così ottenuto sarà
968 disponibile in tutti i figli, e potrà essere passato come parametro attraverso
969 una \func{exec}.
970
971 Però quando i processi non sono \textsl{parenti} (come capita tutte le volte
972 che si ha a che fare con un sistema client-server) tutto questo non è
973 possibile; si potrebbe comunque salvare l'identificatore su un file noto, ma
974 questo ovviamente comporta lo svantaggio di doverselo andare a rileggere.  Una
975 alternativa più efficace è quella che i programmi usino un valore comune per
976 la chiave (che ad esempio può essere dichiarato in un header comune), ma c'è
977 sempre il rischio che questa chiave possa essere stata già utilizzata da
978 qualcun altro.  Dato che non esiste una convenzione su come assegnare queste
979 chiavi in maniera univoca l'interfaccia mette a disposizione una funzione
980 apposita, \funcd{ftok}, che permette di ottenere una chiave specificando il
981 nome di un file ed un numero di versione; il suo prototipo è:
982 \begin{functions}
983   \headdecl{sys/types.h} 
984   \headdecl{sys/ipc.h} 
985   
986   \funcdecl{key\_t ftok(const char *pathname, int proj\_id)}
987   
988   Restituisce una chiave per identificare un oggetto del \textit{SysV IPC}.
989   
990   \bodydesc{La funzione restituisce la chiave in caso di successo e -1
991     altrimenti, nel qual caso \var{errno} sarà uno dei possibili codici di
992     errore di \func{stat}.}
993 \end{functions}
994
995 La funzione determina un valore della chiave sulla base di \param{pathname},
996 che deve specificare il pathname di un file effettivamente esistente e di un
997 numero di progetto \param{proj\_id)}, che di norma viene specificato come
998 carattere, dato che ne vengono utilizzati solo gli 8 bit meno
999 significativi.\footnote{nelle libc4 e libc5, come avviene in SunOS,
1000   l'argomento \param{proj\_id} è dichiarato tipo \ctyp{char}, le \acr{glibc}
1001   usano il prototipo specificato da XPG4, ma vengono lo stesso utilizzati gli
1002   8 bit meno significativi.}
1003
1004 Il problema è che anche così non c'è la sicurezza che il valore della chiave
1005 sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
1006 con i 16 bit meno significativi dell'inode\index{inode} del file
1007 \param{pathname} (che vengono ottenuti attraverso \func{stat}, da cui derivano
1008 i possibili errori), e gli 8 bit meno significativi del numero del dispositivo
1009 su cui è il file.  Diventa perciò relativamente facile ottenere delle
1010 collisioni, specie se i file sono su dispositivi con lo stesso \textit{minor
1011   number}, come \file{/dev/hda1} e \file{/dev/sda1}.
1012
1013 In genere quello che si fa è utilizzare un file comune usato dai programmi che
1014 devono comunicare (ad esempio un header comune, o uno dei programmi che devono
1015 usare l'oggetto in questione), utilizzando il numero di progetto per ottenere
1016 le chiavi che interessano. In ogni caso occorre sempre controllare, prima di
1017 creare un oggetto, che la chiave non sia già stata utilizzata. Se questo va
1018 bene in fase di creazione, le cose possono complicarsi per i programmi che
1019 devono solo accedere, in quanto, a parte gli eventuali controlli sugli altri
1020 attributi di \struct{ipc\_perm}, non esiste una modalità semplice per essere
1021 sicuri che l'oggetto associato ad una certa chiave sia stato effettivamente
1022 creato da chi ci si aspetta.
1023
1024 Questo è, insieme al fatto che gli oggetti sono permanenti e non mantengono un
1025 contatore di riferimenti per la cancellazione automatica, il principale
1026 problema del \textit{SysV IPC}. Non esiste infatti una modalità chiara per
1027 identificare un oggetto, come sarebbe stato se lo si fosse associato ad in
1028 file, e tutta l'interfaccia è inutilmente complessa.  Per questo ne è stata
1029 effettuata una revisione completa nello standard POSIX.1b, che tratteremo in
1030 \secref{sec:ipc_posix}.
1031
1032
1033 \subsection{Il controllo di accesso}
1034 \label{sec:ipc_sysv_access_control}
1035
1036 Oltre alle chiavi, abbiamo visto che ad ogni oggetto sono associate in
1037 \struct{ipc\_perm} ulteriori informazioni, come gli identificatori del creatore
1038 (nei campi \var{cuid} e \var{cgid}) e del proprietario (nei campi \var{uid} e
1039 \var{gid}) dello stesso, e un insieme di permessi (nel campo \var{mode}). In
1040 questo modo è possibile definire un controllo di accesso sugli oggetti di IPC,
1041 simile a quello che si ha per i file (vedi \secref{sec:file_perm_overview}).
1042
1043 Benché questo controllo di accesso sia molto simile a quello dei file, restano
1044 delle importanti differenze. La prima è che il permesso di esecuzione non
1045 esiste (e se specificato viene ignorato), per cui si può parlare solo di
1046 permessi di lettura e scrittura (nel caso dei semafori poi quest'ultimo è più
1047 propriamente un permesso di modifica). I valori di \var{mode} sono gli stessi
1048 ed hanno lo stesso significato di quelli riportati in
1049 \secref{tab:file_mode_flags}\footnote{se però si vogliono usare le costanti
1050   simboliche ivi definite occorrerà includere il file \file{sys/stat.h},
1051   alcuni sistemi definiscono le costanti \const{MSG\_R} (\texttt{0400}) e
1052   \const{MSG\_W} (\texttt{0200}) per indicare i permessi base di lettura e
1053   scrittura per il proprietario, da utilizzare, con gli opportuni shift, pure
1054   per il gruppo e gli altri, in Linux, visto la loro scarsa utilità, queste
1055   costanti non sono definite.} e come per i file definiscono gli accessi per
1056 il proprietario, il suo gruppo e tutti gli altri.
1057
1058 Quando l'oggetto viene creato i campi \var{cuid} e \var{uid} di
1059 \struct{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono settati
1060 rispettivamente al valore dell'userid e del groupid effettivo del processo che
1061 ha chiamato la funzione, ma, mentre i campi \var{uid} e \var{gid} possono
1062 essere cambiati, i campi \var{cuid} e \var{cgid} restano sempre gli stessi.
1063
1064 Il controllo di accesso è effettuato a due livelli. Il primo livello è nelle
1065 funzioni che richiedono l'identificatore di un oggetto data la chiave. Queste
1066 specificano tutte un argomento \param{flag}, in tal caso quando viene
1067 effettuata la ricerca di una chiave, qualora \param{flag} specifichi dei
1068 permessi, questi vengono controllati e l'identificatore viene restituito solo
1069 se corrispondono a quelli dell'oggetto. Se ci sono dei permessi non presenti
1070 in \var{mode} l'accesso sarà negato. Questo controllo però è di utilità
1071 indicativa, dato che è sempre possibile specificare per \param{flag} un valore
1072 nullo, nel qual caso l'identificatore sarà restituito comunque.
1073
1074 Il secondo livello di controllo è quello delle varie funzioni che accedono
1075 direttamente (in lettura o scrittura) all'oggetto. In tal caso lo schema dei
1076 controlli è simile a quello dei file, ed avviene secondo questa sequenza:
1077 \begin{itemize}
1078 \item se il processo ha i privilegi di amministratore l'accesso è sempre
1079   consentito. 
1080 \item se l'userid effettivo del processo corrisponde o al valore del campo
1081   \var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario
1082   in \var{mode} è appropriato\footnote{per appropriato si intende che è
1083     settato il permesso di scrittura per le operazioni di scrittura e quello
1084     di lettura per le operazioni di lettura.} l'accesso è consentito.
1085 \item se il groupid effettivo del processo corrisponde o al
1086   valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso
1087   per il gruppo in \var{mode} è appropriato l'accesso è consentito.
1088 \item se il permesso per gli altri è appropriato l'accesso è consentito.
1089 \end{itemize}
1090 solo se tutti i controlli elencati falliscono l'accesso è negato. Si noti che
1091 a differenza di quanto avviene per i permessi dei file, fallire in uno dei
1092 passi elencati non comporta il fallimento dell'accesso. Un'ulteriore
1093 differenza rispetto a quanto avviene per i file è che per gli oggetti di IPC
1094 il valore di \var{umask} (si ricordi quanto esposto in
1095 \secref{sec:file_umask}) non ha alcun significato.
1096
1097
1098 \subsection{Gli identificatori ed il loro utilizzo}
1099 \label{sec:ipc_sysv_id_use}
1100
1101 L'unico campo di \struct{ipc\_perm} del quale non abbiamo ancora parlato è
1102 \var{seq}, che in \figref{fig:ipc_ipc_perm} è qualificato con un criptico
1103 ``\textsl{numero di sequenza}'', ne parliamo adesso dato che esso è
1104 strettamente attinente alle modalità con cui il kernel assegna gli
1105 identificatori degli oggetti del sistema di IPC.
1106
1107 Quando il sistema si avvia, alla creazione di ogni nuovo oggetto di IPC viene
1108 assegnato un numero progressivo, pari al numero di oggetti di quel tipo
1109 esistenti. Se il comportamento fosse sempre questo sarebbe identico a quello
1110 usato nell'assegnazione dei file descriptor nei processi, ed i valori degli
1111 identificatori tenderebbero ad essere riutilizzati spesso e restare di piccole
1112 dimensioni (inferiori al numero massimo di oggetti disponibili).
1113
1114 Questo va benissimo nel caso dei file descriptor, che sono locali ad un
1115 processo, ma qui il comportamento varrebbe per tutto il sistema, e per
1116 processi del tutto scorrelati fra loro. Così si potrebbero avere situazioni
1117 come quella in cui un server esce e cancella le sue code di messaggi, ed il
1118 relativo identificatore viene immediatamente assegnato a quelle di un altro
1119 server partito subito dopo, con la possibilità che i client del primo non
1120 facciano in tempo ad accorgersi dell'avvenuto, e finiscano con l'interagire
1121 con gli oggetti del secondo, con conseguenze imprevedibili.
1122
1123 Proprio per evitare questo tipo di situazioni il sistema usa il valore di
1124 \var{seq} per provvedere un meccanismo che porti gli identificatori ad
1125 assumere tutti i valori possibili, rendendo molto più lungo il periodo in cui
1126 un identificatore può venire riutilizzato.
1127
1128 Il sistema dispone sempre di un numero fisso di oggetti di IPC,\footnote{fino
1129   al kernel 2.2.x questi valori, definiti dalle costanti \const{MSGMNI},
1130   \const{SEMMNI} e \const{SHMMNI}, potevano essere cambiati (come tutti gli
1131   altri limiti relativi al \textit{SysV IPC}) solo con una ricompilazione del
1132   kernel, andando a modificarne la definizione nei relativi header file.  A
1133   partire dal kernel 2.4.x è possibile cambiare questi valori a sistema attivo
1134   scrivendo sui file \file{shmmni}, \file{msgmni} e \file{sem} di
1135   \file{/proc/sys/kernel} o con l'uso di \texttt{syscntl}.} e per ciascuno di
1136 essi viene mantenuto in \var{seq} un numero di sequenza progressivo che viene
1137 incrementato di uno ogni volta che l'oggetto viene cancellato. Quando
1138 l'oggetto viene creato usando uno spazio che era già stato utilizzato in
1139 precedenza per restituire l'identificatore al numero di oggetti presenti viene
1140 sommato il valore di \var{seq} moltiplicato per il numero massimo di oggetti
1141 di quel tipo,\footnote{questo vale fino ai kernel della serie 2.2.x, dalla
1142   serie 2.4.x viene usato lo stesso fattore per tutti gli oggetti, esso è dato
1143   dalla costante \const{IPCMNI}, definita in \file{include/linux/ipc.h}, che
1144   indica il limite massimo per il numero di tutti oggetti di IPC, ed il cui
1145   valore è 32768.}  si evita così il riutilizzo degli stessi numeri, e si fa
1146 sì che l'identificatore assuma tutti i valori possibili.
1147
1148 \begin{figure}[!htb]
1149   \footnotesize \centering
1150   \begin{minipage}[c]{15cm}
1151     \begin{lstlisting}{}
1152 int main(int argc, char *argv[])
1153 {
1154     ...
1155     switch (type) {
1156     case 'q':   /* Message Queue */
1157         debug("Message Queue Try\n");
1158         for (i=0; i<n; i++) {
1159             id = msgget(IPC_PRIVATE, IPC_CREAT|0666);
1160             printf("Identifier Value %d \n", id);
1161             msgctl(id, IPC_RMID, NULL);
1162         }
1163         break;
1164     case 's':   /* Semaphore */
1165         debug("Semaphore\n");
1166         for (i=0; i<n; i++) {
1167             id = semget(IPC_PRIVATE, 1, IPC_CREAT|0666);
1168             printf("Identifier Value %d \n", id);
1169             semctl(id, 0, IPC_RMID);
1170         }
1171         break;
1172     case 'm':   /* Shared Memory */
1173         debug("Shared Memory\n");
1174         for (i=0; i<n; i++) {
1175             id = shmget(IPC_PRIVATE, 1000, IPC_CREAT|0666);
1176             printf("Identifier Value %d \n", id);
1177             shmctl(id, IPC_RMID, NULL);
1178         }
1179         break;
1180     default:    /* should not reached */
1181         return -1;
1182     }
1183     return 0;
1184 }
1185     \end{lstlisting}
1186   \end{minipage} 
1187   \normalsize 
1188   \caption{Sezione principale del programma di test per l'assegnazione degli
1189     identificatori degli oggetti di IPC \file{IPCTestId.c}.}
1190   \label{fig:ipc_sysv_idtest}
1191 \end{figure}
1192
1193 In \figref{fig:ipc_sysv_idtest} è riportato il codice di un semplice programma
1194 di test che si limita a creare un oggetto (specificato a riga di comando),
1195 stamparne il numero di identificatore e cancellarlo per un numero specificato
1196 di volte. Al solito non si è riportato il codice della gestione delle opzioni
1197 a riga di comando, che permette di specificare quante volte effettuare il
1198 ciclo \var{n}, e su quale tipo di oggetto eseguirlo.
1199
1200 La figura non riporta il codice di selezione delle opzioni, che permette di
1201 inizializzare i valori delle variabili \var{type} al tipo di oggetto voluto, e
1202 \var{n} al numero di volte che si vuole effettuare il ciclo di creazione,
1203 stampa, cancellazione. I valori di default sono per l'uso delle code di
1204 messaggi e un ciclo di 5 volte. Se si lancia il comando si otterrà qualcosa
1205 del tipo:
1206 \begin{verbatim}
1207 piccardi@gont sources]$ ./ipctestid
1208 Identifier Value 0 
1209 Identifier Value 32768 
1210 Identifier Value 65536 
1211 Identifier Value 98304 
1212 Identifier Value 131072 
1213 \end{verbatim}%$
1214 il che ci mostra che abbiamo un kernel della serie 2.4.x nel quale non avevamo
1215 ancora usato nessuna coda di messaggi. Se ripetiamo il comando otterremo
1216 ancora:
1217 \begin{verbatim}
1218 [piccardi@gont sources]$ ./ipctestid
1219 Identifier Value 163840 
1220 Identifier Value 196608 
1221 Identifier Value 229376 
1222 Identifier Value 262144 
1223 Identifier Value 294912 
1224 \end{verbatim}%$
1225 che ci mostra come il valore di \var{seq} sia in effetti una quantità
1226 mantenuta staticamente all'interno del sistema.
1227
1228
1229 \subsection{Code di messaggi}
1230 \label{sec:ipc_sysv_mq}
1231
1232 Il primo oggetto introdotto dal \textit{SysV IPC} è quello delle code di
1233 messaggi.  Le code di messaggi sono oggetti analoghi alle pipe o alle fifo,
1234 anche se la loro struttura è diversa, ed il loro scopo principale è appunto
1235 quello di permettere a processi diversi di scambiarsi dei dati.
1236
1237 La funzione che permette di richiedere al sistema l'identificatore di una coda
1238 di messaggi esistente (o di crearne una se questa non esiste) è
1239 \funcd{msgget}; il suo prototipo è:
1240 \begin{functions}
1241   \headdecl{sys/types.h} 
1242   \headdecl{sys/ipc.h} 
1243   \headdecl{sys/msg.h} 
1244   
1245   \funcdecl{int msgget(key\_t key, int flag)}
1246   
1247   Restituisce l'identificatore di una coda di messaggi.
1248   
1249   \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
1250     in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
1251   \begin{errlist}
1252   \item[\errcode{EACCES}] Il processo chiamante non ha i privilegi per accedere
1253   alla coda richiesta.  
1254   \item[\errcode{EEXIST}] Si è richiesta la creazione di una coda che già
1255   esiste, ma erano specificati sia \const{IPC\_CREAT} che \const{IPC\_EXCL}. 
1256   \item[\errcode{EIDRM}] La coda richiesta è marcata per essere cancellata.
1257   \item[\errcode{ENOENT}] Si è cercato di ottenere l'identificatore di una coda
1258     di messaggi specificando una chiave che non esiste e \const{IPC\_CREAT}
1259     non era specificato.
1260   \item[\errcode{ENOSPC}] Si è cercato di creare una coda di messaggi quando è
1261     stato superato il limite massimo di code (\const{MSGMNI}).
1262   \end{errlist}
1263   ed inoltre \errval{ENOMEM}.
1264 }
1265 \end{functions}
1266
1267 Le funzione (come le analoghe che si usano per gli altri oggetti) serve sia a
1268 ottenere l'identificatore di una coda di messaggi esistente, che a crearne una
1269 nuova. L'argomento \param{key} specifica la chiave che è associata
1270 all'oggetto, eccetto il caso in cui si specifichi il valore
1271 \const{IPC\_PRIVATE}, nel qual caso la coda è creata ex-novo e non vi è
1272 associata alcuna chiave, il processo (ed i suoi eventuali figli) potranno
1273 farvi riferimento solo attraverso l'identificatore.
1274
1275 Se invece si specifica un valore diverso da \const{IPC\_PRIVATE}\footnote{in
1276   Linux questo significa un valore diverso da zero.} l'effetto della funzione
1277 dipende dal valore di \param{flag}, se questo è nullo la funzione si limita ad
1278 effettuare una ricerca sugli oggetti esistenti, restituendo l'identificatore
1279 se trova una corrispondenza, o fallendo con un errore di \errcode{ENOENT} se
1280 non esiste o di \errcode{EACCES} se si sono specificati dei permessi non
1281 validi.
1282
1283 Se invece si vuole creare una nuova coda di messaggi \param{flag} non può
1284 essere nullo e deve essere fornito come maschera binaria, impostando il bit
1285 corrispondente al valore \const{IPC\_CREAT}. In questo caso i nove bit meno
1286 significativi di \param{flag} saranno usati come permessi per il nuovo
1287 oggetto, secondo quanto illustrato in \secref{sec:ipc_sysv_access_control}.
1288 Se si imposta anche il bit corrispondente a \const{IPC\_EXCL} la funzione avrà
1289 successo solo se l'oggetto non esiste già, fallendo con un errore di
1290 \errcode{EEXIST} altrimenti.
1291
1292 Si tenga conto che l'uso di \const{IPC\_PRIVATE} non impedisce ad altri
1293 processi di accedere alla coda (se hanno privilegi sufficienti) una volta che
1294 questi possano indovinare o ricavare (ad esempio per tentativi)
1295 l'identificatore ad essa associato. Per come sono implementati gli oggetti di
1296 IPC infatti non esiste una maniera che  garantisca l'accesso esclusivo ad una
1297 coda di messaggi.  Usare \const{IPC\_PRIVATE} o const{IPC\_CREAT} e
1298 \const{IPC\_EXCL} per \param{flag} comporta solo la creazione di una nuova
1299 coda.
1300
1301 \begin{table}[htb]
1302   \footnotesize
1303   \centering
1304   \begin{tabular}[c]{|c|r|l|l|}
1305     \hline
1306     \textbf{Costante} & \textbf{Valore} & \textbf{File in \texttt{proc}}
1307     & \textbf{Significato} \\
1308     \hline
1309     \hline
1310     \const{MSGMNI}&   16& \file{msgmni} & Numero massimo di code di
1311                                           messaggi. \\
1312     \const{MSGMAX}& 8192& \file{msgmax} & Dimensione massima di un singolo
1313                                           messaggio.\\
1314     \const{MSGMNB}&16384& \file{msgmnb} & Dimensione massima del contenuto di 
1315                                           una coda.\\
1316     \hline
1317   \end{tabular}
1318   \caption{Valori delle costanti associate ai limiti delle code di messaggi.}
1319   \label{tab:ipc_msg_limits}
1320 \end{table}
1321
1322 Le code di messaggi sono caratterizzate da tre limiti fondamentali, definiti
1323 negli header e corrispondenti alle prime tre costanti riportate in
1324 \tabref{tab:ipc_msg_limits}, come accennato però in Linux è possibile
1325 modificare questi limiti attraverso l'uso di \func{syscntl} o scrivendo nei
1326 file \file{msgmax}, \file{msgmnb} e \file{msgmni} di \file{/proc/sys/kernel/}.
1327
1328
1329 \begin{figure}[htb]
1330   \centering \includegraphics[width=15cm]{img/mqstruct}
1331   \caption{Schema della struttura di una coda messaggi.}
1332   \label{fig:ipc_mq_schema}
1333 \end{figure}
1334
1335
1336 Una coda di messaggi è costituita da una \textit{linked list};\footnote{una
1337   \textit{linked list} è una tipica struttura di dati, organizzati in una
1338   lista in cui ciascun elemento contiene un puntatore al successivo. In questo
1339   modo la struttura è veloce nell'estrazione ed immissione dei dati dalle
1340   estremità dalla lista (basta aggiungere un elemento in testa o in coda ed
1341   aggiornare un puntatore), e relativamente veloce da attraversare in ordine
1342   sequenziale (seguendo i puntatori), è invece relativamente lenta
1343   nell'accesso casuale e nella ricerca.}  i nuovi messaggi vengono inseriti in
1344 coda alla lista e vengono letti dalla cima, in \figref{fig:ipc_mq_schema} si è
1345 riportato lo schema con cui queste strutture vengono mantenute dal
1346 kernel.\footnote{lo schema illustrato in \figref{fig:ipc_mq_schema} è in
1347   realtà una semplificazione di quello usato effettivamente fino ai kernel
1348   della serie 2.2.x, nei kernel della serie 2.4.x la gestione delle code di
1349   messaggi è stata modificata ed è effettuata in maniera diversa; abbiamo
1350   mantenuto lo schema precedente in quanto illustra comunque in maniera più
1351   che adeguata i principi di funzionamento delle code di messaggi.}
1352
1353 \begin{figure}[!htb]
1354   \footnotesize \centering
1355   \begin{minipage}[c]{15cm}
1356     \begin{lstlisting}[labelstep=0]{}
1357 struct msqid_ds {
1358     struct ipc_perm msg_perm;     /* structure for operation permission */
1359     time_t msg_stime;             /* time of last msgsnd command */
1360     time_t msg_rtime;             /* time of last msgrcv command */
1361     time_t msg_ctime;             /* time of last change */
1362     msgqnum_t msg_qnum;           /* number of messages currently on queue */
1363     msglen_t msg_qbytes;          /* max number of bytes allowed on queue */
1364     pid_t msg_lspid;              /* pid of last msgsnd() */
1365     pid_t msg_lrpid;              /* pid of last msgrcv() */
1366     struct msg *msg_first;        /* first message on queue, unused  */
1367     struct msg *msg_last;         /* last message in queue, unused */
1368     unsigned long int msg_cbytes; /* current number of bytes on queue */
1369 };
1370     \end{lstlisting}
1371   \end{minipage} 
1372   \normalsize 
1373   \caption{La struttura \structd{msgid\_ds}, associata a ciascuna coda di
1374     messaggi.}
1375   \label{fig:ipc_msgid_ds}
1376 \end{figure}
1377
1378 A ciascuna coda è associata una struttura \struct{msgid\_ds}, la cui
1379 definizione, è riportata in \secref{fig:ipc_msgid_ds}. In questa struttura il
1380 kernel mantiene le principali informazioni riguardo lo stato corrente della
1381 coda.\footnote{come accennato questo vale fino ai kernel della serie 2.2.x,
1382   essa viene usata nei kernel della serie 2.4.x solo per compatibilità in
1383   quanto è quella restituita dalle funzioni dell'interfaccia.  Si noti come ci
1384   sia una differenza con i campi mostrati nello schema di
1385   \figref{fig:ipc_mq_schema} che sono presi dalla definizione di
1386   \file{linux/msg.h}, e fanno riferimento alla definizione della omonima
1387   struttura usata nel kernel.} In \figref{fig:ipc_msgid_ds} sono elencati i
1388 campi significativi definiti in \file{sys/msg.h}, a cui si sono aggiunti gli
1389 ultimi tre campi che sono previsti dalla implementazione originale di System
1390 V, ma non dallo standard Unix98.
1391
1392 Quando si crea una nuova coda con \func{msgget} questa struttura viene
1393 inizializzata, in particolare il campo \var{msg\_perm} viene inizializzato
1394 come illustrato in \secref{sec:ipc_sysv_access_control}, per quanto riguarda
1395 gli altri campi invece:
1396 \begin{itemize}
1397 \item il campo \var{msg\_qnum}, che esprime il numero di messaggi presenti
1398   sulla coda, viene inizializzato a 0.
1399 \item i campi \var{msg\_lspid} e \var{msg\_lrpid}, che esprimono
1400   rispettivamente il \acr{pid} dell'ultimo processo che ha inviato o ricevuto
1401   un messaggio sulla coda, sono inizializzati a 0.
1402 \item i campi \var{msg\_stime} e \var{msg\_rtime}, che esprimono
1403   rispettivamente il tempo in cui è stato inviato o ricevuto l'ultimo
1404   messaggio sulla coda, sono inizializzati a 0.
1405 \item il campo \var{msg\_ctime}, che esprime il tempo di creazione della coda,
1406   viene inizializzato al tempo corrente.
1407 \item il campo \var{msg\_qbytes} che esprime la dimensione massima del
1408   contenuto della coda (in byte) viene inizializzato al valore preimpostato
1409   del sistema (\const{MSGMNB}).
1410 \item i campi \var{msg\_first} e \var{msg\_last} che esprimono l'indirizzo del
1411   primo e ultimo messaggio sono inizializzati a \val{NULL} e
1412   \var{msg\_cbytes}, che esprime la dimensione in byte dei messaggi presenti è
1413   inizializzato a zero. Questi campi sono ad uso interno dell'implementazione
1414   e non devono essere utilizzati da programmi in user space).
1415 \end{itemize}
1416
1417 Una volta creata una coda di messaggi le operazioni di controllo vengono
1418 effettuate con la funzione \funcd{msgctl}, che (come le analoghe \func{semctl}
1419 e \func{shmctl}) fa le veci di quello che \func{ioctl} è per i file; il suo
1420 prototipo è:
1421 \begin{functions}
1422   \headdecl{sys/types.h} 
1423   \headdecl{sys/ipc.h} 
1424   \headdecl{sys/msg.h} 
1425   
1426   \funcdecl{int msgctl(int msqid, int cmd, struct msqid\_ds *buf)}
1427   
1428   Esegue l'operazione specificata da \param{cmd} sulla coda \param{msqid}.
1429   
1430   \bodydesc{La funzione restituisce 0 in caso di successo o -1 in caso di
1431     errore, nel qual caso \var{errno} assumerà uno dei valori:
1432   \begin{errlist}
1433   \item[\errcode{EACCES}] Si è richiesto \const{IPC\_STAT} ma processo
1434     chiamante non ha i privilegi di lettura sulla coda.
1435   \item[\errcode{EIDRM}] La coda richiesta è stata cancellata.
1436   \item[\errcode{EPERM}] Si è richiesto \const{IPC\_SET} o \const{IPC\_RMID} ma
1437     il processo non ha i privilegi, o si è richiesto di aumentare il valore di
1438     \var{msg\_qbytes} oltre il limite \const{MSGMNB} senza essere
1439     amministratore.
1440   \end{errlist}
1441   ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
1442 }
1443 \end{functions}
1444
1445 La funzione permette di accedere ai valori della struttura \struct{msqid\_ds},
1446 mantenuta all'indirizzo \param{buf}, per la coda specificata
1447 dall'identificatore \param{msqid}. Il comportamento della funzione dipende dal
1448 valore dell'argomento \param{cmd}, che specifica il tipo di azione da
1449 eseguire; i valori possibili sono:
1450 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
1451 \item[\const{IPC\_STAT}] Legge le informazioni riguardo la coda nella
1452   struttura indicata da \param{buf}. Occorre avere il permesso di lettura
1453   sulla coda.
1454 \item[\const{IPC\_RMID}] Rimuove la coda, cancellando tutti i dati, con
1455   effetto immediato. Tutti i processi che cercheranno di accedere alla coda
1456   riceveranno un errore di \errcode{EIDRM}, e tutti processi in attesa su
1457   funzioni di di lettura o di scrittura sulla coda saranno svegliati ricevendo
1458   il medesimo errore. Questo comando può essere eseguito solo da un processo
1459   con userid effettivo corrispondente al creatore o al proprietario della
1460   coda, o all'amministratore.
1461 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
1462   della coda, ed il limite massimo sulle dimensioni del totale dei messaggi in
1463   essa contenuti (\var{msg\_qbytes}). I valori devono essere passati in una
1464   struttura \struct{msqid\_ds} puntata da \param{buf}.  Per modificare i valori
1465   di \var{msg\_perm.mode}, \var{msg\_perm.uid} e \var{msg\_perm.gid} occorre
1466   essere il proprietario o il creatore della coda, oppure l'amministratore; lo
1467   stesso vale per \var{msg\_qbytes}, ma l'amministratore ha la facoltà di
1468   incrementarne il valore a limiti superiori a \const{MSGMNB}.
1469 \end{basedescript}
1470
1471
1472 Una volta che si abbia a disposizione l'identificatore, per inviare un
1473 messaggio su una coda si utilizza la funzione \funcd{msgsnd}; il suo prototipo
1474 è:
1475 \begin{functions}
1476   \headdecl{sys/types.h} 
1477   \headdecl{sys/ipc.h} 
1478   \headdecl{sys/msg.h} 
1479   
1480   \funcdecl{int msgsnd(int msqid, struct msgbuf *msgp, size\_t msgsz, int
1481     msgflg)} 
1482
1483   Invia un messaggio sulla coda \param{msqid}.
1484   
1485   \bodydesc{La funzione restituisce 0, e -1 in caso di errore, nel qual caso
1486     \var{errno} assumerà uno dei valori:
1487   \begin{errlist}
1488   \item[\errcode{EACCES}] Non si hanno i privilegi di accesso sulla coda.
1489   \item[\errcode{EIDRM}] La coda è stata cancellata.
1490   \item[\errcode{EAGAIN}] Il messaggio non può essere inviato perché si è
1491   superato il limite \var{msg\_qbytes} sul numero massimo di byte presenti
1492   sulla coda, e si è richiesto \const{IPC\_NOWAIT} in \param{flag}.
1493   \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
1494   \item[\errcode{EINVAL}] Si è specificato un \param{msgid} invalido, o un
1495     valore non positivo per \param{mtype}, o un valore di \param{msgsz}
1496     maggiore di \const{MSGMAX}.
1497   \end{errlist}
1498   ed inoltre \errval{EFAULT} ed \errval{ENOMEM}.
1499 }
1500 \end{functions}
1501
1502 La funzione inserisce il messaggio sulla coda specificata da \param{msqid}; il
1503 messaggio ha lunghezza specificata da \param{msgsz} ed è passato attraverso il
1504 l'argomento \param{msgp}.  Quest'ultimo deve venire passato sempre come
1505 puntatore ad una struttura \struct{msgbuf} analoga a quella riportata in
1506 \figref{fig:ipc_msbuf} che è quella che deve contenere effettivamente il
1507 messaggio.  La dimensione massima per il testo di un messaggio non può
1508 comunque superare il limite \const{MSGMAX}.
1509
1510 La struttura di \figref{fig:ipc_msbuf} è comunque solo un modello, tanto che
1511 la definizione contenuta in \file{sys/msg.h} usa esplicitamente per il secondo
1512 campo il valore \code{mtext[1]}, che non è di nessuna utilità ai fini pratici.
1513 La sola cosa che conta è che la struttura abbia come primo membro un campo
1514 \var{mtype} come nell'esempio; esso infatti serve ad identificare il tipo di
1515 messaggio e deve essere sempre specificato come intero positivo di tipo
1516 \ctyp{long}.  Il campo \var{mtext} invece può essere di qualsiasi tipo e
1517 dimensione, e serve a contenere il testo del messaggio.
1518
1519 In generale pertanto per inviare un messaggio con \func{msgsnd} si usa
1520 ridefinire una struttura simile a quella di \figref{fig:ipc_msbuf}, adattando
1521 alle proprie esigenze il campo \var{mtype}, (o ridefinendo come si vuole il
1522 corpo del messaggio, anche con più campi o con strutture più complesse) avendo
1523 però la cura di mantenere nel primo campo un valore di tipo \ctyp{long} che ne
1524 indica il tipo.
1525
1526 Si tenga presente che la lunghezza che deve essere indicata in questo
1527 argomento è solo quella del messaggio, non quella di tutta la struttura, se
1528 cioè \var{message} è una propria struttura che si passa alla funzione,
1529 \param{msgsz} dovrà essere uguale a \code{sizeof(message)-sizeof(long)}, (se
1530 consideriamo il caso dell'esempio in \figref{fig:ipc_msbuf}, \param{msgsz}
1531 dovrà essere pari a \const{LENGTH}).
1532
1533 \begin{figure}[!htb]
1534   \footnotesize \centering
1535   \begin{minipage}[c]{15cm}
1536     \begin{lstlisting}[labelstep=0]{}
1537     struct msgbuf {
1538          long mtype;          /* message type, must be > 0 */
1539          char mtext[LENGTH];  /* message data */
1540     };
1541     \end{lstlisting}
1542   \end{minipage} 
1543   \normalsize 
1544   \caption{Schema della struttura \structd{msgbuf}, da utilizzare come
1545     argomento per inviare/ricevere messaggi.}
1546   \label{fig:ipc_msbuf}
1547 \end{figure}
1548
1549 Per capire meglio il funzionamento della funzione riprendiamo in
1550 considerazione la struttura della coda illustrata in
1551 \figref{fig:ipc_mq_schema}. Alla chiamata di \func{msgsnd} il nuovo messaggio
1552 sarà aggiunto in fondo alla lista inserendo una nuova struttura \struct{msg},
1553 il puntatore \var{msg\_last} di \struct{msqid\_ds} verrà aggiornato, come pure
1554 il puntatore al messaggio successivo per quello che era il precedente ultimo
1555 messaggio; il valore di \var{mtype} verrà mantenuto in \var{msg\_type} ed il
1556 valore di \param{msgsz} in \var{msg\_ts}; il testo del messaggio sarà copiato
1557 all'indirizzo specificato da \var{msg\_spot}.
1558
1559 Il valore dell'argomento \param{flag} permette di specificare il comportamento
1560 della funzione. Di norma, quando si specifica un valore nullo, la funzione
1561 ritorna immediatamente a meno che si sia ecceduto il valore di
1562 \var{msg\_qbytes}, o il limite di sistema sul numero di messaggi, nel qual
1563 caso si blocca mandando il processo in stato di \textit{sleep}.  Se si
1564 specifica per \param{flag} il valore \const{IPC\_NOWAIT} la funzione opera in
1565 modalità non bloccante, ed in questi casi ritorna immediatamente con un errore
1566 di \errcode{EAGAIN}.
1567
1568 Se non si specifica \const{IPC\_NOWAIT} la funzione resterà bloccata fintanto
1569 che non si liberano risorse sufficienti per poter inserire nella coda il
1570 messaggio, nel qual caso ritornerà normalmente. La funzione può ritornare, con
1571 una condizione di errore anche in due altri casi: quando la coda viene rimossa
1572 (nel qual caso si ha un errore di \errcode{EIDRM}) o quando la funzione viene
1573 interrotta da un segnale (nel qual caso si ha un errore di \errcode{EINTR}).
1574
1575 Una volta completato con successo l'invio del messaggio sulla coda, la
1576 funzione aggiorna i dati mantenuti in \struct{msqid\_ds}, in particolare
1577 vengono modificati:
1578 \begin{itemize*}
1579 \item Il valore di \var{msg\_lspid}, che viene impostato al \acr{pid} del
1580   processo chiamante.
1581 \item Il valore di \var{msg\_qnum}, che viene incrementato di uno.
1582 \item Il valore \var{msg\_stime}, che viene impostato al tempo corrente.
1583 \end{itemize*}
1584
1585 La funzione che viene utilizzata per estrarre un messaggio da una coda è
1586 \funcd{msgrcv}; il suo prototipo è:
1587 \begin{functions}
1588   \headdecl{sys/types.h} 
1589   \headdecl{sys/ipc.h} 
1590   \headdecl{sys/msg.h} 
1591
1592   \funcdecl{ssize\_t msgrcv(int msqid, struct msgbuf *msgp, size\_t msgsz,
1593     long msgtyp, int msgflg)}
1594   
1595   Legge un messaggio dalla coda \param{msqid}.
1596   
1597   \bodydesc{La funzione restituisce il numero di byte letti in caso di
1598     successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà uno
1599     dei valori:
1600   \begin{errlist}
1601   \item[\errcode{EACCES}] Non si hanno i privilegi di accesso sulla coda.
1602   \item[\errcode{EIDRM}] La coda è stata cancellata.
1603   \item[\errcode{E2BIG}] Il testo del messaggio è più lungo di \param{msgsz} e
1604     non si è specificato \const{MSG\_NOERROR} in \param{msgflg}.
1605   \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale mentre
1606     era in attesa di ricevere un messaggio.
1607   \item[\errcode{EINVAL}] Si è specificato un \param{msgid} invalido o un
1608     valore di \param{msgsz} negativo.
1609   \end{errlist}
1610   ed inoltre \errval{EFAULT}.
1611 }
1612 \end{functions}
1613
1614 La funzione legge un messaggio dalla coda specificata, scrivendolo sulla
1615 struttura puntata da \param{msgp}, che dovrà avere un formato analogo a quello
1616 di \figref{fig:ipc_msbuf}.  Una volta estratto, il messaggio sarà rimosso dalla
1617 coda.  L'argomento \param{msgsz} indica la lunghezza massima del testo del
1618 messaggio (equivalente al valore del parametro \const{LENGTH} nell'esempio di
1619 \figref{fig:ipc_msbuf}).
1620
1621 Se il testo del messaggio ha lunghezza inferiore a \param{msgsz} esso viene
1622 rimosso dalla coda; in caso contrario, se \param{msgflg} è impostato a
1623 \const{MSG\_NOERROR}, il messaggio viene troncato e la parte in eccesso viene
1624 perduta, altrimenti il messaggio non viene estratto e la funzione ritorna con
1625 un errore di \errcode{E2BIG}.
1626
1627 L'argomento \param{msgtyp} permette di restringere la ricerca ad un
1628 sottoinsieme dei messaggi presenti sulla coda; la ricerca infatti è fatta con
1629 una scansione della struttura mostrata in \figref{fig:ipc_mq_schema},
1630 restituendo il primo messaggio incontrato che corrisponde ai criteri
1631 specificati (che quindi, visto come i messaggi vengono sempre inseriti dalla
1632 coda, è quello meno recente); in particolare:
1633 \begin{itemize*}
1634 \item se \param{msgtyp} è 0 viene estratto il messaggio in cima alla coda, cioè
1635   quello fra i presenti che è stato inserito inserito per primo. 
1636 \item se \param{msgtyp} è positivo viene estratto il primo messaggio il cui
1637   tipo (il valore del campo \var{mtype}) corrisponde al valore di
1638   \param{msgtyp}.
1639 \item se \param{msgtyp} è negativo viene estratto il primo fra i messaggi con
1640   il valore più basso del tipo, fra tutti quelli il cui tipo ha un valore
1641   inferiore al valore assoluto di \param{msgtyp}.
1642 \end{itemize*}
1643
1644 Il valore di \param{msgflg} permette di controllare il comportamento della
1645 funzione, esso può essere nullo o una maschera binaria composta da uno o più
1646 valori.  Oltre al precedente \const{MSG\_NOERROR}, sono possibili altri due
1647 valori: \const{MSG\_EXCEPT}, che permette, quando \param{msgtyp} è positivo,
1648 di leggere il primo messaggio nella coda con tipo diverso da \param{msgtyp}, e
1649 \const{IPC\_NOWAIT} che causa il ritorno immediato della funzione quando non
1650 ci sono messaggi sulla coda.
1651
1652 Il comportamento usuale della funzione infatti, se non ci sono messaggi
1653 disponibili per la lettura, è di bloccare il processo in stato di
1654 \textit{sleep}. Nel caso però si sia specificato \const{IPC\_NOWAIT} la
1655 funzione ritorna immediatamente con un errore \errcode{ENOMSG}. Altrimenti la
1656 funzione ritorna normalmente non appena viene inserito un messaggio del tipo
1657 desiderato, oppure ritorna con errore qualora la coda sia rimossa (con
1658 \var{errno} impostata a \errcode{EIDRM}) o se il processo viene interrotto da
1659 un segnale (con \var{errno} impostata a \errcode{EINTR}).
1660
1661 Una volta completata con successo l'estrazione del messaggio dalla coda, la
1662 funzione aggiorna i dati mantenuti in \struct{msqid\_ds}, in particolare
1663 vengono modificati:
1664 \begin{itemize*}
1665 \item Il valore di \var{msg\_lrpid}, che viene impostato al \acr{pid} del
1666   processo chiamante.
1667 \item Il valore di \var{msg\_qnum}, che viene decrementato di uno.
1668 \item Il valore \var{msg\_rtime}, che viene impostato al tempo corrente.
1669 \end{itemize*}
1670
1671 Le code di messaggi presentano il solito problema di tutti gli oggetti del
1672 SysV IPC; essendo questi permanenti restano nel sistema occupando risorse
1673 anche quando un processo è terminato, al contrario delle pipe per le quali
1674 tutte le risorse occupate vengono rilasciate quanto l'ultimo processo che le
1675 utilizzava termina. Questo comporta che in caso di errori si può saturare il
1676 sistema, e che devono comunque essere esplicitamente previste delle funzioni
1677 di rimozione in caso di interruzioni o uscite dal programma (come vedremo in
1678 \figref{fig:ipc_mq_fortune_server}).
1679
1680 L'altro problema è non facendo uso di file descriptor le tecniche di
1681 \textit{I/O multiplexing} descritte in \secref{sec:file_multiplexing} non
1682 possono essere utilizzate, e non si ha a disposizione niente di analogo alle
1683 funzioni \func{select} e \func{poll}. Questo rende molto scomodo usare più di
1684 una di queste strutture alla volta; ad esempio non si può scrivere un server
1685 che aspetti un messaggio su più di una coda senza fare ricorso ad una tecnica
1686 di \textit{polling}\index{polling} che esegua un ciclo di attesa su ciascuna
1687 di esse.
1688
1689 Come esempio dell'uso delle code di messaggi possiamo riscrivere il nostro
1690 server di \textit{fortunes} usando queste al posto delle fifo. In questo caso
1691 useremo una sola coda di messaggi, usando il tipo di messaggio per comunicare
1692 in maniera indipendente con client diversi.
1693
1694 \begin{figure}[!bht]
1695   \footnotesize \centering
1696   \begin{minipage}[c]{15cm}
1697     \begin{lstlisting}{}
1698 int msgid;                                       /* Message queue identifier */
1699 int main(int argc, char *argv[])
1700 {
1701 /* Variables definition */
1702     int i, n = 0;
1703     char **fortune;                       /* array of fortune message string */
1704     char *fortunefilename;                              /* fortune file name */
1705     struct msgbuf_read {      /* message struct to read request from clients */
1706         long mtype;                               /* message type, must be 1 */
1707         long pid;             /* message data, must be the pid of the client */
1708     } msg_read;
1709     struct msgbuf_write {       /* message struct to write result to clients */
1710         long mtype;            /* message type, will be the pid of the client*/
1711         char mtext[MSGMAX];             /* message data, will be the fortune */
1712     } msg_write;
1713     key_t key;                                          /* Message queue key */
1714     int size;                                                /* message size */
1715     ...
1716     Signal(SIGTERM, HandSIGTERM);            /* set handlers for termination */
1717     Signal(SIGINT, HandSIGTERM);
1718     Signal(SIGQUIT, HandSIGTERM);
1719     if (n==0) usage();          /* if no pool depth exit printing usage info */
1720     i = FortuneParse(fortunefilename, fortune, n);          /* parse phrases */
1721     /* Create the queue */
1722     key = ftok("./MQFortuneServer.c", 1); 
1723     msgid = msgget(key, IPC_CREAT|0666);
1724     if (msgid < 0) {
1725         perror("Cannot create message queue");
1726         exit(1);
1727     }
1728     /* Main body: loop over requests */
1729     while (1) {
1730         msgrcv(msgid, &msg_read, sizeof(int), 1, MSG_NOERROR);
1731         n = random() % i;                             /* select random value */
1732         strncpy(msg_write.mtext, fortune[n], MSGMAX);
1733         size = min(strlen(fortune[n])+1, MSGMAX);  
1734         msg_write.mtype=msg_read.pid;             /* use request pid as type */
1735         msgsnd(msgid, &msg_write, size, 0);
1736     }
1737 }
1738 /*
1739  * Signal Handler to manage termination
1740  */
1741 void HandSIGTERM(int signo) {
1742     msgctl(msgid, IPC_RMID, NULL);                   /* remove message queue */
1743     exit(0);
1744 }
1745     \end{lstlisting}
1746   \end{minipage} 
1747   \normalsize 
1748   \caption{Sezione principale del codice del server di \textit{fortunes}
1749     basato sulle \textit{message queue}.}
1750   \label{fig:ipc_mq_fortune_server}
1751 \end{figure}
1752
1753 In \figref{fig:ipc_mq_fortune_server} si è riportato un estratto delle parti
1754 principali del codice del nuovo server (il codice completo è nel file
1755 \file{MQFortuneServer.c} nei sorgenti allegati). Il programma è basato su un
1756 uso accorto della caratteristica di poter associate un ``tipo'' ai messaggi
1757 per permettere una comunicazione indipendente fra il server ed i vari client,
1758 usando il \acr{pid} di questi ultimi come identificativo. Questo è possibile
1759 in quanto, al contrario di una fifo, la lettura di una coda di messaggi può
1760 non essere sequenziale, proprio grazie alla classificazione dei messaggi sulla
1761 base del loro tipo.
1762
1763 Il programma, oltre alle solite variabili per il nome del file da cui leggere
1764 le \textit{fortunes} e per il vettore di stringhe che contiene le frasi,
1765 definisce due strutture appositamente per la comunicazione; con
1766 \var{msgbuf\_read} (\texttt{\small 8--11}) vengono passate le richieste mentre
1767 con \var{msgbuf\_write} (\texttt{\small 12--15}) vengono restituite le frasi.
1768
1769 La gestione delle opzioni si è al solito omessa, essa si curerà di impostare
1770 in \var{n} il numero di frasi da leggere specificato a linea di comando ed in
1771 \var{fortunefilename} il file da cui leggerle; dopo aver installato
1772 (\texttt{\small 19--21}) i gestori dei segnali per trattare l'uscita dal
1773 server, viene prima controllato (\texttt{\small 22}) il numero di frasi
1774 richieste abbia senso (cioè sia maggiore di zero), le quali poi
1775 (\texttt{\small 23}) vengono lette nel vettore in memoria con la stessa
1776 funzione \code{FortuneParse()} usata anche per il server basato sulle fifo.
1777
1778 Una volta inizializzato il vettore di stringhe coi messaggi presi dal file
1779 delle \textit{fortune} si procede (\texttt{\small 25}) con la generazione di
1780 una chiave per identificare la coda di messaggi (si usa il nome del file dei
1781 sorgenti del server) con la quale poi si esegue (\texttt{\small 26}) la
1782 creazione della stessa (si noti come si sia chiamata \func{msgget} con un
1783 valore opportuno per l'argomento \param{flag}), avendo cura di abortire il
1784 programma (\texttt{\small 27--29}) in caso di errore.
1785
1786 Finita la fase di inizializzazione il server esegue in permanenza il ciclo
1787 principale (\texttt{\small 32--41}). Questo inizia (\texttt{\small 33}) con il
1788 porsi in attesa di un messaggio di richiesta da parte di un client; si noti
1789 infatti come \func{msgrcv} richieda un messaggio con \var{mtype} uguale a 1:
1790 questo è il valore usato per le richieste dato che corrisponde al \acr{pid} di
1791 \cmd{init}, che non può essere un client. L'uso del flag \const{MSG\_NOERROR}
1792 è solo per sicurezza, dato che i messaggi di richiesta sono di dimensione
1793 fissa (e contengono solo il \acr{pid} del client).
1794
1795 Se non sono presenti messaggi di richiesta \func{msgrcv} si bloccherà,
1796 ritornando soltanto in corrispondenza dell'arrivo sulla coda di un messaggio
1797 di richiesta da parte di un client, in tal caso il ciclo prosegue
1798 (\texttt{\small 34}) selezionando una frase a caso, copiandola (\texttt{\small
1799   35}) nella struttura \var{msgbuf\_write} usata per la risposta e
1800 calcolandone (\texttt{\small 36}) la dimensione.
1801
1802 Per poter permettere a ciascun client di ricevere solo la risposta indirizzata
1803 a lui il tipo del messaggio in uscita viene inizializzato (\texttt{\small 37})
1804 al valore del \acr{pid} del client ricevuto nel messaggio di richiesta.
1805 L'ultimo passo del ciclo (\texttt{\small 38}) è inviare sulla coda il
1806 messaggio di risposta. Si tenga conto che se la coda è piena anche questa
1807 funzione potrà bloccarsi fintanto che non venga liberato dello spazio.
1808
1809 Si noti che il programma può terminare solo grazie ad una interruzione da
1810 parte di un segnale; in tal caso verrà eseguito il gestore
1811 \code{HandSIGTERM}, che semplicemente si limita a cancellare la coda
1812 (\texttt{\small 44}) ed ad uscire (\texttt{\small 45}).
1813
1814 \begin{figure}[!bht]
1815   \footnotesize \centering
1816   \begin{minipage}[c]{15cm}
1817     \begin{lstlisting}{}
1818 int main(int argc, char *argv[])
1819 {
1820     ...
1821     key = ftok("./MQFortuneServer.c", 1); 
1822     msgid = msgget(key, 0); 
1823     if (msgid < 0) {
1824         perror("Cannot find message queue");
1825         exit(1);
1826     }
1827     /* Main body: do request and write result */
1828     msg_read.mtype = 1;                      /* type for request is always 1 */
1829     msg_read.pid = getpid();                   /* use pid for communications */
1830     size = sizeof(msg_read.pid);  
1831     msgsnd(msgid, &msg_read, size, 0);               /* send request message */
1832     msgrcv(msgid, &msg_write, MSGMAX, msg_read.pid, MSG_NOERROR);
1833     printf("%s", msg_write.mtext);
1834 }
1835     \end{lstlisting}
1836   \end{minipage} 
1837   \normalsize 
1838   \caption{Sezione principale del codice del client di \textit{fortunes}
1839     basato sulle \textit{message queue}.}
1840   \label{fig:ipc_mq_fortune_client}
1841 \end{figure}
1842
1843 In \figref{fig:ipc_mq_fortune_client} si è riportato un estratto il codice del
1844 programma client.  Al solito il codice completo è con i sorgenti allegati, nel
1845 file \file{MQFortuneClient.c}.  Come sempre si sono rimosse le parti relative
1846 alla gestione delle opzioni, ed in questo caso, anche la dichiarazione delle
1847 variabili, che, per la parte relative alle strutture usate per la
1848 comunicazione tramite le code, sono le stesse viste in
1849 \figref{fig:ipc_mq_fortune_server}.
1850
1851 Il client in questo caso è molto semplice; la prima parte del programma
1852 (\texttt{\small 4--9}) si occupa di accedere alla coda di messaggi, ed è
1853 identica a quanto visto per il server, solo che in questo caso \func{msgget}
1854 non viene chiamata con il flag di creazione in quanto la coda deve essere
1855 preesistente. In caso di errore (ad esempio se il server non è stato avviato)
1856 il programma termina immediatamente. 
1857
1858 Una volta acquisito l'identificatore della coda il client compone il
1859 messaggio di richiesta (\texttt{\small 12--13}) in \var{msg\_read}, usando 1
1860 per il tipo ed inserendo il proprio \acr{pid} come dato da passare al server.
1861 Calcolata (\texttt{\small 14}) la dimensione, provvede (\texttt{\small 15}) ad
1862 immettere la richiesta sulla coda. 
1863
1864 A questo punto non resta che (\texttt{\small 16}) rileggere dalla coda la
1865 risposta del server richiedendo a \func{msgrcv} di selezionare i messaggi di
1866 tipo corrispondente al valore del \acr{pid} inviato nella richiesta. L'ultimo
1867 passo (\texttt{\small 17}) prima di uscire è quello di stampare a video il
1868 messaggio ricevuto.
1869  
1870 Benché funzionante questa architettura risente dello stesso inconveniente
1871 visto anche nel caso del precedente server basato sulle fifo; se il client
1872 viene interrotto dopo l'invio del messaggio di richiesta e prima della lettura
1873 della risposta, quest'ultima resta nella coda (così come per le fifo si aveva
1874 il problema delle fifo che restavano nel filesystem). In questo caso però il
1875 problemi sono maggiori, sia perché è molto più facile esaurire la memoria
1876 dedicata ad una coda di messaggi che gli inode\index{inode} di un filesystem,
1877 sia perché, con il riutilizzo dei \acr{pid} da parte dei processi, un client
1878 eseguito in un momento successivo potrebbe ricevere un messaggio non
1879 indirizzato a lui.
1880
1881
1882
1883 \subsection{Semafori}
1884 \label{sec:ipc_sysv_sem}
1885
1886 I semafori non sono meccanismi di intercomunicazione diretta come quelli
1887 (pipe, fifo e code di messaggi) visti finora, e non consentono di scambiare
1888 dati fra processi, ma servono piuttosto come meccanismi di sincronizzazione o
1889 di protezione per le \textsl{sezioni critiche}\index{sezioni critiche} del
1890 codice (si ricordi quanto detto in \secref{sec:proc_race_cond}). 
1891
1892 Un semaforo è uno speciale contatore, mantenuto nel kernel, che permette, a
1893 seconda del suo valore, di consentire o meno la prosecuzione dell'esecuzione
1894 di un programma. In questo modo l'accesso ad una risorsa condivisa da più
1895 processi può essere controllato, associando ad essa un semaforo che consente
1896 di assicurare che non più di un processo alla volta possa usarla.
1897
1898 Il concetto di semaforo è uno dei concetti base nella programmazione ed è
1899 assolutamente generico, così come del tutto generali sono modalità con cui lo
1900 si utilizza. Un processo che deve accedere ad una risorsa eseguirà un
1901 controllo del semaforo: se questo è positivo il suo valore sarà decrementato,
1902 indicando che si è consumato una unità della risorsa, ed il processo potrà
1903 proseguire nell'utilizzo di quest'ultima, provvedendo a rilasciarla, una volta
1904 completate le operazioni volute, reincrementando il semaforo.
1905
1906 Se al momento del controllo il valore del semaforo è nullo, siamo invece in
1907 una situazione in cui la risorsa non è disponibile, ed il processo si
1908 bloccherà in stato di \textit{sleep} fin quando chi la sta utilizzando non la
1909 rilascerà, incrementando il valore del semaforo. Non appena il semaforo torna
1910 positivo, indicando che la risorsa è disponibile, il processo sarà svegliato,
1911 e si potrà operare come nel caso precedente (decremento del semaforo, accesso
1912 alla risorsa, incremento del semaforo).
1913
1914 Per poter implementare questo tipo di logica le operazioni di controllo e
1915 decremento del contatore associato al semaforo devono essere atomiche,
1916 pertanto una realizzazione di un oggetto di questo tipo è necessariamente
1917 demandata al kernel. La forma più semplice di semaforo è quella del
1918 \textsl{semaforo binario}, o \textit{mutex}, in cui un valore diverso da zero
1919 (normalmente 1) indica la libertà di accesso, e un valore nullo l'occupazione
1920 della risorsa; in generale però si possono usare semafori con valori interi,
1921 utilizzando il valore del contatore come indicatore del ``numero di risorse''
1922 ancora disponibili.
1923
1924 Il sistema di comunicazione inter-processo di \textit{SysV IPC} prevede anche i
1925 semafori, ma gli oggetti utilizzati non sono semafori singoli, ma gruppi di
1926 semafori detti \textsl{insiemi} (o \textit{semaphore set}); la funzione che
1927 permette di creare o ottenere l'identificatore di un insieme di semafori è
1928 \funcd{semget}, ed il suo prototipo è:
1929 \begin{functions}
1930   \headdecl{sys/types.h} 
1931   \headdecl{sys/ipc.h} 
1932   \headdecl{sys/sem.h} 
1933   
1934   \funcdecl{int semget(key\_t key, int nsems, int flag)}
1935   
1936   Restituisce l'identificatore di un insieme di semafori.
1937   
1938   \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
1939     in caso di errore, nel qual caso \var{errno} assumerà i valori:
1940     \begin{errlist}
1941     \item[\errcode{ENOSPC}] Si è cercato di creare una insieme di semafori
1942       quando è stato superato o il limite per il numero totale di semafori
1943       (\const{SEMMNS}) o quello per il numero totale degli insiemi
1944       (\const{SEMMNI}) nel sistema.
1945     \item[\errcode{EINVAL}] L'argomento \param{nsems} è minore di zero o
1946       maggiore del limite sul numero di semafori per ciascun insieme
1947       (\const{SEMMSL}), o se l'insieme già esiste, maggiore del numero di
1948       semafori che contiene.
1949     \item[\errcode{ENOMEM}] Il sistema non ha abbastanza memoria per poter
1950       contenere le strutture per un nuovo insieme di semafori.
1951     \end{errlist}
1952     ed inoltre \errval{EACCES}, \errval{ENOENT}, \errval{EEXIST},
1953     \errval{EIDRM}, con lo stesso significato che hanno per \func{msgget}.}
1954 \end{functions}
1955
1956 La funzione è del tutto analoga a \func{msgget}, solo che in questo caso
1957 restituisce l'identificatore di un insieme di semafori, in particolare è
1958 identico l'uso degli argomenti \param{key} e \param{flag}, per cui non
1959 ripeteremo quanto detto al proposito in \secref{sec:ipc_sysv_mq}. L'argomento
1960 \param{nsems} permette di specificare quanti semafori deve contenere l'insieme
1961 quando se ne richieda la creazione, e deve essere nullo quando si effettua una
1962 richiesta dell'identificatore di un insieme già esistente.
1963
1964 Purtroppo questa implementazione complica inutilmente lo schema elementare che
1965 abbiamo descritto, dato che non è possibile definire un singolo semaforo, ma
1966 se ne deve creare per forza un insieme.  Ma questa in definitiva è solo una
1967 complicazione inutile, il problema è che i semafori del \textit{SysV IPC}
1968 soffrono di altri due, ben più gravi, difetti.
1969
1970 Il primo difetto è che non esiste una funzione che permetta di creare ed
1971 inizializzare un semaforo in un'unica chiamata; occorre prima creare l'insieme
1972 dei semafori con \func{semget} e poi inizializzarlo con \func{semctl}, si
1973 perde così ogni possibilità di eseguire l'operazione atomicamente.
1974
1975 Il secondo difetto deriva dalla caratteristica generale degli oggetti del
1976 \textit{SysV IPC} di essere risorse globali di sistema, che non vengono
1977 cancellate quando nessuno le usa più; ci si così a trova a dover affrontare
1978 esplicitamente il caso in cui un processo termina per un qualche errore,
1979 lasciando un semaforo occupato, che resterà tale fino al successivo riavvio
1980 del sistema. Come vedremo esistono delle modalità per evitare tutto ciò, ma
1981 diventa necessario indicare esplicitamente che si vuole il ripristino del
1982 semaforo all'uscita del processo.
1983
1984
1985 \begin{figure}[!htb]
1986   \footnotesize \centering
1987   \begin{minipage}[c]{15cm}
1988     \begin{lstlisting}[labelstep=0]{}
1989 struct semid_ds
1990 {
1991     struct ipc_perm sem_perm;           /* operation permission struct */
1992     time_t sem_otime;                   /* last semop() time */
1993     time_t sem_ctime;                   /* last time changed by semctl() */
1994     unsigned long int sem_nsems;        /* number of semaphores in set */
1995 };
1996     \end{lstlisting}
1997   \end{minipage} 
1998   \normalsize 
1999   \caption{La struttura \structd{semid\_ds}, associata a ciascun insieme di
2000     semafori.}
2001   \label{fig:ipc_semid_ds}
2002 \end{figure}
2003
2004 A ciascun insieme di semafori è associata una struttura \struct{semid\_ds},
2005 riportata in \figref{fig:ipc_semid_ds}.\footnote{non si sono riportati i campi
2006   ad uso interno del kernel, che vedremo in \figref{fig:ipc_sem_schema}, che
2007   dipendono dall'implementazione.} Come nel caso delle code di messaggi quando
2008 si crea un nuovo insieme di semafori con \func{semget} questa struttura viene
2009 inizializzata, in particolare il campo \var{sem\_perm} viene inizializzato
2010 come illustrato in \secref{sec:ipc_sysv_access_control} (si ricordi che in
2011 questo caso il permesso di scrittura è in realtà permesso di alterare il
2012 semaforo), per quanto riguarda gli altri campi invece:
2013 \begin{itemize*}
2014 \item il campo \var{sem\_nsems}, che esprime il numero di semafori
2015   nell'insieme, viene inizializzato al valore di \param{nsems}.
2016 \item il campo \var{sem\_ctime}, che esprime il tempo di creazione
2017   dell'insieme, viene inizializzato al tempo corrente.
2018 \item il campo \var{sem\_otime}, che esprime il tempo dell'ultima operazione
2019   effettuata, viene inizializzato a zero.
2020 \end{itemize*}
2021
2022
2023 Ciascun semaforo dell'insieme è realizzato come una struttura di tipo
2024 \struct{sem} che ne contiene i dati essenziali, la sua definizione\footnote{si
2025   è riportata la definizione originaria del kernel 1.0, che contiene la prima
2026   realizzazione del \textit{SysV IPC} in Linux. In realtà questa struttura
2027   ormai è ridotta ai soli due primi membri, e gli altri vengono calcolati
2028   dinamicamente. La si è utilizzata a scopo di esempio, perché indica tutti i
2029   valori associati ad un semaforo, restituiti dalle funzioni di controllo, e
2030   citati dalle pagine di manuale.} è riportata in \figref{fig:ipc_sem}. Questa
2031 struttura, non è accessibile in user space, ma i valori in essa specificati
2032 possono essere letti in maniera indiretta, attraverso l'uso delle funzioni di
2033 controllo.
2034
2035 \begin{figure}[!htb]
2036   \footnotesize \centering
2037   \begin{minipage}[c]{15cm}
2038     \begin{lstlisting}[labelstep=0]{}
2039 struct sem {
2040   short   sempid;         /* pid of last operation */
2041   ushort  semval;         /* current value */
2042   ushort  semncnt;        /* num procs awaiting increase in semval */
2043   ushort  semzcnt;        /* num procs awaiting semval = 0 */
2044 };
2045     \end{lstlisting}
2046   \end{minipage} 
2047   \normalsize 
2048   \caption{La struttura \structd{sem}, che contiene i dati di un singolo
2049     semaforo.} 
2050   \label{fig:ipc_sem}
2051 \end{figure}
2052
2053 I dati mantenuti nella struttura, ed elencati in \figref{fig:ipc_sem},
2054 indicano rispettivamente:
2055 \begin{description*}
2056 \item[\var{semval}] il valore numerico del semaforo.
2057 \item[\var{sempid}] il \acr{pid} dell'ultimo processo che ha eseguito una
2058   operazione sul semaforo.
2059 \item[\var{semncnt}] il numero di processi in attesa che esso venga
2060   incrementato.
2061 \item[\var{semzcnt}] il numero di processi in attesa che esso si annulli.
2062 \end{description*}
2063
2064 \begin{table}[htb]
2065   \footnotesize
2066   \centering
2067   \begin{tabular}[c]{|c|r|p{8cm}|}
2068     \hline
2069     \textbf{Costante} & \textbf{Valore} & \textbf{Significato} \\
2070     \hline
2071     \hline
2072     \const{SEMMNI}&          128 & Numero massimo di insiemi di semafori. \\
2073     \const{SEMMSL}&          250 & Numero massimo di semafori per insieme.\\
2074     \const{SEMMNS}&\const{SEMMNI}*\const{SEMMSL}& Numero massimo di semafori
2075                                    nel sistema .\\
2076     \const{SEMVMX}&        32767 & Massimo valore per un semaforo.\\
2077     \const{SEMOPM}&           32 & Massimo numero di operazioni per chiamata a
2078                                    \func{semop}. \\
2079     \const{SEMMNU}&\const{SEMMNS}& Massimo numero di strutture di ripristino.\\
2080     \const{SEMUME}&\const{SEMOPM}& Massimo numero di voci di ripristino.\\
2081     \const{SEMAEM}&\const{SEMVMX}& valore massimo per l'aggiustamento
2082                                    all'uscita. \\
2083     \hline
2084   \end{tabular}
2085   \caption{Valori delle costanti associate ai limiti degli insiemi di
2086     semafori, definite in \file{linux/sem.h}.} 
2087   \label{tab:ipc_sem_limits}
2088 \end{table}
2089
2090 Come per le code di messaggi anche per gli insiemi di semafori esistono una
2091 serie di limiti, i cui valori sono associati ad altrettante costanti, che si
2092 sono riportate in \tabref{tab:ipc_sem_limits}. Alcuni di questi limiti sono al
2093 solito accessibili e modificabili attraverso \func{sysctl} o scrivendo
2094 direttamente nel file \file{/proc/sys/kernel/sem}.
2095
2096 La funzione che permette di effettuare le varie operazioni di controllo sui
2097 semafori (fra le quali, come accennato, è impropriamente compresa anche la
2098 loro inizializzazione) è \funcd{semctl}; il suo prototipo è:
2099 \begin{functions}
2100   \headdecl{sys/types.h} 
2101   \headdecl{sys/ipc.h} 
2102   \headdecl{sys/sem.h} 
2103   
2104   \funcdecl{int semctl(int semid, int semnum, int cmd)}
2105   \funcdecl{int semctl(int semid, int semnum, int cmd, union semun arg)}
2106   
2107   Esegue le operazioni di controllo su un semaforo o un insieme di semafori.
2108   
2109   \bodydesc{La funzione restituisce in caso di successo un valore positivo
2110     quanto usata con tre argomenti ed un valore nullo quando usata con
2111     quattro. In caso di errore restituisce -1, ed \var{errno} assumerà uno dei
2112     valori:
2113     \begin{errlist}
2114     \item[\errcode{EACCES}] Il processo non ha i privilegi per eseguire
2115       l'operazione richiesta.
2116     \item[\errcode{EIDRM}] L'insieme di semafori è stato cancellato.
2117     \item[\errcode{EPERM}] Si è richiesto \const{IPC\_SET} o \const{IPC\_RMID}
2118       ma il processo non ha privilegi sufficienti ad eseguire l'operazione.
2119     \item[\errcode{ERANGE}] Si è richiesto \const{SETALL} \const{SETVAL} ma il
2120       valore a cui si vuole impostare il semaforo è minore di zero o maggiore
2121       di \const{SEMVMX}.
2122   \end{errlist}
2123   ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
2124 }
2125 \end{functions}
2126
2127 La funzione può avere tre o quattro parametri, a seconda dell'operazione
2128 specificata con \param{cmd}, ed opera o sull'intero insieme specificato da
2129 \param{semid} o sul singolo semaforo di un insieme, specificato da
2130 \param{semnum}. 
2131
2132 \begin{figure}[!htb]
2133   \footnotesize \centering
2134   \begin{minipage}[c]{15cm}
2135     \begin{lstlisting}[labelstep=0]{}
2136 union semun {
2137       int val;                  /* value for SETVAL */
2138       struct semid_ds *buf;     /* buffer for IPC_STAT, IPC_SET */
2139       unsigned short *array;    /* array for GETALL, SETALL */
2140                                 /* Linux specific part: */
2141       struct seminfo *__buf;    /* buffer for IPC_INFO */
2142 };
2143     \end{lstlisting}
2144   \end{minipage} 
2145   \normalsize 
2146   \caption{La definizione dei possibili valori di una \direct{union}
2147     \structd{semun}, usata come quarto argomento della funzione
2148     \func{semctl}.}
2149   \label{fig:ipc_semun}
2150 \end{figure}
2151
2152 Qualora la funzione operi con quattro argomenti \param{arg} è un argomento
2153 generico, che conterrà un dato diverso a seconda dell'azione richiesta; per
2154 unificare l'argomento esso deve essere passato come una \struct{semun}, la cui
2155 definizione, con i possibili valori che può assumere, è riportata in
2156 \figref{fig:ipc_semun}.
2157
2158 Come già accennato sia il comportamento della funzione che il numero di
2159 parametri con cui deve essere invocata, dipendono dal valore dell'argomento
2160 \param{cmd}, che specifica l'azione da intraprendere; i valori validi (che
2161 cioè non causano un errore di \errcode{EINVAL}) per questo argomento sono i
2162 seguenti:
2163 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
2164 \item[\const{IPC\_STAT}] Legge i dati dell'insieme di semafori, copiando il
2165   contenuto della relativa struttura \struct{semid\_ds} all'indirizzo
2166   specificato con \var{arg.buf}. Occorre avere il permesso di lettura.
2167   L'argomento \param{semnum} viene ignorato.
2168 \item[\const{IPC\_RMID}] Rimuove l'insieme di semafori e le relative strutture
2169   dati, con effetto immediato. Tutti i processi che erano stato di
2170   \textit{sleep} vengono svegliati, ritornando con un errore di
2171   \errcode{EIDRM}.  L'userid effettivo del processo deve corrispondere o al
2172   creatore o al proprietario dell'insieme, o all'amministratore. L'argomento
2173   \param{semnum} viene ignorato.
2174 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
2175   dell'insieme. I valori devono essere passati in una struttura
2176   \struct{semid\_ds} puntata da \param{arg.buf} di cui saranno usati soltanto i
2177   campi \var{sem\_perm.uid}, \var{sem\_perm.gid} e i nove bit meno
2178   significativi di \var{sem\_perm.mode}. L'userid effettivo del processo deve
2179   corrispondere o al creatore o al proprietario dell'insieme, o
2180   all'amministratore.  L'argomento \param{semnum} viene ignorato.
2181 \item[\const{GETALL}] Restituisce il valore corrente di ciascun semaforo
2182   dell'insieme (corrispondente al campo \var{semval} di \struct{sem}) nel
2183   vettore indicato da \param{arg.array}. Occorre avere il permesso di lettura.
2184   L'argomento \param{semnum} viene ignorato.
2185 \item[\const{GETNCNT}] Restituisce come valore di ritorno della funzione il
2186   numero di processi in attesa che il semaforo \param{semnum} dell'insieme
2187   \param{semid} venga incrementato (corrispondente al campo \var{semncnt} di
2188   \struct{sem}); va invocata con tre argomenti.  Occorre avere il permesso di
2189   lettura.
2190 \item[\const{GETPID}] Restituisce come valore di ritorno della funzione il
2191   \acr{pid} dell'ultimo processo che ha compiuto una operazione sul semaforo
2192   \param{semnum} dell'insieme \param{semid} (corrispondente al campo
2193   \var{sempid} di \struct{sem}); va invocata con tre argomenti.  Occorre avere
2194   il permesso di lettura.
2195 \item[\const{GETVAL}] Restituisce come valore di ritorno della funzione il il
2196   valore corrente del semaforo \param{semnum} dell'insieme \param{semid}
2197   (corrispondente al campo \var{semval} di \struct{sem}); va invocata con tre
2198   argomenti.  Occorre avere il permesso di lettura.
2199 \item[\const{GETZCNT}] Restituisce come valore di ritorno della funzione il
2200   numero di processi in attesa che il valore del semaforo \param{semnum}
2201   dell'insieme \param{semid} diventi nullo (corrispondente al campo
2202   \var{semncnt} di \struct{sem}); va invocata con tre argomenti.  Occorre avere
2203   il permesso di lettura.
2204 \item[\const{SETALL}] Inizializza il valore di tutti i semafori dell'insieme,
2205   aggiornando il campo \var{sem\_ctime} di \struct{semid\_ds}. I valori devono
2206   essere passati nel vettore indicato da \param{arg.array}.  Si devono avere i
2207   privilegi di scrittura sul semaforo.  L'argomento \param{semnum} viene
2208   ignorato.
2209 \item[\const{SETVAL}] Inizializza il semaforo \param{semnum} al valore passato
2210   dall'argomento \param{arg.val}, aggiornando il campo \var{sem\_ctime} di
2211   \struct{semid\_ds}.  Si devono avere i privilegi di scrittura sul semaforo.
2212 \end{basedescript}
2213
2214 Quando si imposta il valore di un semaforo (sia che lo si faccia per tutto
2215 l'insieme con \const{SETALL}, che per un solo semaforo con \const{SETVAL}), i
2216 processi in attesa su di esso reagiscono di conseguenza al cambiamento di
2217 valore.  Inoltre la coda delle operazioni di ripristino viene cancellata per
2218 tutti i semafori il cui valore viene modificato.
2219
2220 \begin{table}[htb]
2221   \footnotesize
2222   \centering
2223   \begin{tabular}[c]{|c|l|}
2224     \hline
2225     \textbf{Operazione}  & \textbf{Valore restituito} \\
2226     \hline
2227     \hline
2228     \const{GETNCNT}& valore di \var{semncnt}.\\
2229     \const{GETPID} & valore di \var{sempid}.\\
2230     \const{GETVAL} & valore di \var{semval}.\\
2231     \const{GETZCNT}& valore di \var{semzcnt}.\\
2232     \hline
2233   \end{tabular}
2234   \caption{Valori di ritorno della funzione \func{semctl}.} 
2235   \label{tab:ipc_semctl_returns}
2236 \end{table}
2237
2238 Il valore di ritorno della funzione in caso di successo dipende
2239 dall'operazione richiesta; per tutte le operazioni che richiedono quattro
2240 argomenti esso è sempre nullo, per le altre operazioni, elencate in
2241 \tabref{tab:ipc_semctl_returns} viene invece restituito il valore richiesto,
2242 corrispondente al campo della struttura \struct{sem} indicato nella seconda
2243 colonna della tabella.
2244
2245 Le operazioni ordinarie sui semafori, come l'acquisizione o il rilascio degli
2246 stessi (in sostanza tutte quelle non comprese nell'uso di \func{semctl})
2247 vengono effettuate con la funzione \funcd{semop}, il cui prototipo è:
2248 \begin{functions}
2249   \headdecl{sys/types.h} 
2250   \headdecl{sys/ipc.h} 
2251   \headdecl{sys/sem.h} 
2252   
2253   \funcdecl{int semop(int semid, struct sembuf *sops, unsigned nsops)}
2254   
2255   Esegue le operazioni ordinarie su un semaforo o un insieme di semafori.
2256   
2257   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
2258     errore, nel qual caso \var{errno} assumerà uno dei valori:
2259     \begin{errlist}
2260     \item[\errcode{EACCES}] Il processo non ha i privilegi per eseguire
2261       l'operazione richiesta.
2262     \item[\errcode{EIDRM}] L'insieme di semafori è stato cancellato.
2263     \item[\errcode{ENOMEM}] Si è richiesto un \const{SEM\_UNDO} ma il sistema
2264       non ha le risorse per allocare la struttura di ripristino.
2265     \item[\errcode{EAGAIN}] Un'operazione comporterebbe il blocco del processo,
2266       ma si è specificato \const{IPC\_NOWAIT} in \var{sem\_flg}.
2267     \item[\errcode{EINTR}] La funzione, bloccata in attesa dell'esecuzione
2268       dell'operazione, viene interrotta da un segnale.
2269     \item[\errcode{E2BIG}] L'argomento \param{nsops} è maggiore del numero
2270       massimo di operazioni \const{SEMOPM}.
2271     \item[\errcode{ERANGE}] Per alcune operazioni il valore risultante del
2272       semaforo viene a superare il limite massimo \const{SEMVMX}.
2273   \end{errlist}
2274   ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
2275 }
2276 \end{functions}
2277
2278 La funzione permette di eseguire operazioni multiple sui singoli semafori di
2279 un insieme. La funzione richiede come primo argomento l'identificatore
2280 \param{semid} dell'insieme su cui si vuole operare. Il numero di operazioni da
2281 effettuare viene specificato con l'argomento \param{nsop}, mentre il loro
2282 contenuto viene passato con un puntatore ad un vettore di strutture
2283 \struct{sembuf} nell'argomento \param{sops}. Le operazioni richieste vengono
2284 effettivamente eseguite se e soltanto se è possibile effettuarle tutte quante.
2285
2286 \begin{figure}[!htb]
2287   \footnotesize \centering
2288   \begin{minipage}[c]{15cm}
2289     \begin{lstlisting}[labelstep=0]{}
2290 struct sembuf
2291 {
2292   unsigned short int sem_num;   /* semaphore number */
2293   short int sem_op;             /* semaphore operation */
2294   short int sem_flg;            /* operation flag */
2295 };
2296     \end{lstlisting}
2297   \end{minipage} 
2298   \normalsize 
2299   \caption{La struttura \structd{sembuf}, usata per le operazioni sui
2300     semafori.}
2301   \label{fig:ipc_sembuf}
2302 \end{figure}
2303
2304 Il contenuto di ciascuna operazione deve essere specificato attraverso una
2305 opportuna struttura \struct{sembuf} (la cui definizione è riportata in
2306 \figref{fig:ipc_sembuf}) che il programma chiamante deve avere cura di
2307 allocare in un opportuno vettore. La struttura permette di indicare il
2308 semaforo su cui operare, il tipo di operazione, ed un flag di controllo.
2309 Il campo \var{sem\_num} serve per indicare a quale semaforo dell'insieme fa
2310 riferimento l'operazione; si ricordi che i semafori sono numerati come in un
2311 vettore, per cui il primo semaforo corrisponde ad un valore nullo di
2312 \var{sem\_num}.
2313
2314 Il campo \var{sem\_flg} è un flag, mantenuto come maschera binaria, per il
2315 quale possono essere impostati i due valori \const{IPC\_NOWAIT} e
2316 \const{SEM\_UNDO}.  Impostando \const{IPC\_NOWAIT} si fa si che, invece di
2317 bloccarsi (in tutti quei casi in cui l'esecuzione di una operazione richiede
2318 che il processo vada in stato di \textit{sleep}), \func{semop} ritorni
2319 immediatamente con un errore di \errcode{EAGAIN}.  Impostando \const{SEM\_UNDO}
2320 si richiede invece che l'operazione venga registrata in modo che il valore del
2321 semaforo possa essere ripristinato all'uscita del processo.
2322
2323 Infine \var{sem\_op} è il campo che controlla l'operazione che viene eseguita
2324 e determina il comportamento della chiamata a \func{semop}; tre sono i casi
2325 possibili:
2326 \begin{basedescript}{\desclabelwidth{2.0cm}}
2327 \item[\var{sem\_op}$>0$] In questo caso il valore di \var{sem\_op} viene
2328   aggiunto al valore corrente di \var{semval}. La funzione ritorna
2329   immediatamente (con un errore di \errcode{ERANGE} qualora si sia superato il
2330   limite \const{SEMVMX}) ed il processo non viene bloccato in nessun caso.
2331   Specificando \const{SEM\_UNDO} si aggiorna il contatore per il ripristino
2332   del valore del semaforo. Al processo chiamante è richiesto il privilegio di
2333   alterazione (scrittura) sull'insieme di semafori.
2334   
2335 \item[\var{sem\_op}$=0$] Nel caso \var{semval} sia zero l'esecuzione procede
2336   immediatamente. Se \var{semval} è diverso da zero il comportamento è
2337   controllato da \var{sem\_flg}, se è stato impostato \const{IPC\_NOWAIT} la
2338   funzione ritorna con un errore di \errcode{EAGAIN}, altrimenti viene
2339   incrementato \var{semzcnt} di uno ed il processo resta in stato di
2340   \textit{sleep} fintanto che non si ha una delle condizioni seguenti:
2341   \begin{itemize*}
2342   \item \var{semval} diventa zero, nel qual caso \var{semzcnt} viene
2343     decrementato di uno.
2344   \item l'insieme di semafori viene rimosso, nel qual caso \func{semop} ritorna
2345     un errore di \errcode{EIDRM}.
2346   \item il processo chiamante riceve un segnale, nel qual caso \var{semzcnt}
2347     viene decrementato di uno e \func{semop} ritorna un errore di
2348     \errcode{EINTR}.
2349   \end{itemize*}
2350   Al processo chiamante è richiesto il privilegio di lettura dell'insieme dei
2351   semafori.
2352   
2353 \item[\var{sem\_op}$<0$] Nel caso in cui \var{semval} è maggiore o uguale del
2354   valore assoluto di \var{sem\_op} (se cioè la somma dei due valori resta
2355   positiva o nulla) i valori vengono sommati e la funzione ritorna
2356   immediatamente; qualora si sia impostato \const{SEM\_UNDO} viene anche
2357   aggiornato il contatore per il ripristino del valore del semaforo. In caso
2358   contrario (quando cioè la somma darebbe luogo ad un valore di \var{semval}
2359   negativo) se si è impostato \const{IPC\_NOWAIT} la funzione ritorna con un
2360   errore di \errcode{EAGAIN}, altrimenti viene incrementato di uno
2361   \var{semncnt} ed il processo resta in stato di \textit{sleep} fintanto che
2362   non si ha una delle condizioni seguenti:
2363   \begin{itemize*}
2364   \item \var{semval} diventa maggiore o uguale del valore assoluto di
2365     \var{sem\_op}, nel qual caso \var{semncnt} viene decrementato di uno, il
2366     valore di \var{sem\_op} viene sommato a \var{semval}, e se era stato
2367     impostato \const{SEM\_UNDO} viene aggiornato il contatore per il
2368     ripristino del valore del semaforo.
2369   \item l'insieme di semafori viene rimosso, nel qual caso \func{semop}
2370     ritorna un errore di \errcode{EIDRM}.
2371   \item il processo chiamante riceve un segnale, nel qual caso \var{semncnt}
2372     viene decrementato di uno e \func{semop} ritorna un errore di
2373     \errcode{EINTR}.
2374   \end{itemize*}    
2375   Al processo chiamante è richiesto il privilegio di alterazione (scrittura)
2376   sull'insieme di semafori.
2377 \end{basedescript}
2378
2379 In caso di successo della funzione viene aggiornato il campo \var{sempid} per
2380 ogni semaforo modificato al valore del \acr{pid} del processo chiamante;
2381 inoltre vengono pure aggiornati al tempo corrente i campi \var{sem\_otime} e
2382 \var{sem\_ctime}.
2383
2384 Dato che, come già accennato in precedenza, in caso di uscita inaspettata i
2385 semafori possono restare occupati, abbiamo visto come \func{semop} permetta di
2386 attivare un meccanismo di ripristino attraverso l'uso del flag
2387 \const{SEM\_UNDO}. Il meccanismo è implementato tramite una apposita struttura
2388 \struct{sem\_undo}, associata ad ogni processo per ciascun semaforo che esso
2389 ha modificato; all'uscita i semafori modificati vengono ripristinati, e le
2390 strutture disallocate.  Per mantenere coerente il comportamento queste
2391 strutture non vengono ereditate attraverso una \func{fork} (altrimenti si
2392 avrebbe un doppio ripristino), mentre passano inalterate nell'esecuzione di
2393 una \func{exec} (altrimenti non si avrebbe ripristino).
2394
2395 Tutto questo però ha un problema di fondo. Per capire di cosa si tratta
2396 occorre fare riferimento all'implementazione usata in Linux, che è riportata
2397 in maniera semplificata nello schema di \figref{fig:ipc_sem_schema}.  Si è
2398 presa come riferimento l'architettura usata fino al kernel 2.2.x che è più
2399 semplice (ed illustrata in dettaglio in \cite{tlk}); nel kernel 2.4.x la
2400 struttura del \textit{SysV IPC} è stata modificata, ma le definizioni relative
2401 a queste strutture restano per compatibilità.\footnote{in particolare con le
2402   vecchie versioni delle librerie del C, come le libc5.}
2403
2404 \begin{figure}[htb]
2405   \centering \includegraphics[width=15cm]{img/semtruct}
2406   \caption{Schema della struttura di un insieme di semafori.}
2407   \label{fig:ipc_sem_schema}
2408 \end{figure}
2409
2410 Alla creazione di un nuovo insieme viene allocata una nuova strutture
2411 \struct{semid\_ds} ed il relativo vettore di strutture \struct{sem}. Quando si
2412 richiede una operazione viene anzitutto verificato che tutte le operazioni
2413 possono avere successo; se una di esse comporta il blocco del processo il
2414 kernel crea una struttura \struct{sem\_queue} che viene aggiunta in fondo alla
2415 coda di attesa associata a ciascun insieme di semafori\footnote{che viene
2416   referenziata tramite i campi \var{sem\_pending} e \var{sem\_pending\_last}
2417   di \struct{semid\_ds}.}. Nella struttura viene memorizzato il riferimento
2418 alle operazioni richieste (nel campo \var{sops}, che è un puntatore ad una
2419 struttura \struct{sembuf}) e al processo corrente (nel campo \var{sleeper}) poi
2420 quest'ultimo viene messo stato di attesa e viene invocato lo
2421 scheduler\index{scheduler} per passare all'esecuzione di un altro processo.
2422
2423 Se invece tutte le operazioni possono avere successo queste vengono eseguite
2424 immediatamente, dopo di che il kernel esegue una scansione della coda di
2425 attesa (a partire da \var{sem\_pending}) per verificare se qualcuna delle
2426 operazioni sospese in precedenza può essere eseguita, nel qual caso la
2427 struttura \struct{sem\_queue} viene rimossa e lo stato del processo associato
2428 all'operazione (\var{sleeper}) viene riportato a \textit{running}; il tutto
2429 viene ripetuto fin quando non ci sono più operazioni eseguibili o si è
2430 svuotata la coda.
2431
2432 Per gestire il meccanismo del ripristino tutte le volte che per un'operazione
2433 si è specificato il flag \const{SEM\_UNDO} viene mantenuta per ciascun insieme
2434 di semafori una apposita struttura \struct{sem\_undo} che contiene (nel vettore
2435 puntato dal campo \var{semadj}) un valore di aggiustamento per ogni semaforo
2436 cui viene sommato l'opposto del valore usato per l'operazione. 
2437
2438 Queste strutture sono mantenute in due liste,\footnote{rispettivamente
2439   attraverso i due campi \var{id\_next} e \var{proc\_next}.} una associata
2440 all'insieme di cui fa parte il semaforo, che viene usata per invalidare le
2441 strutture se questo viene cancellato o per azzerarle se si è eseguita una
2442 operazione con \func{semctl}; l'altra associata al processo che ha eseguito
2443 l'operazione;\footnote{attraverso il campo \var{semundo} di
2444   \struct{task\_struct}, come mostrato in \ref{fig:ipc_sem_schema}.} quando un
2445 processo termina, la lista ad esso associata viene scandita e le operazioni
2446 applicate al semaforo.
2447
2448 Siccome un processo può accumulare delle richieste di ripristino per semafori
2449 differenti chiamate attraverso diverse chiamate a \func{semop}, si pone il
2450 problema di come eseguire il ripristino dei semafori all'uscita del processo,
2451 ed in particolare se questo può essere fatto atomicamente. Il punto è cosa
2452 succede quando una delle operazioni previste per il ripristino non può essere
2453 eseguita immediatamente perché ad esempio il semaforo è occupato; in tal caso
2454 infatti, se si pone il processo in stato di \textit{sleep} aspettando la
2455 disponibilità del semaforo (come faceva l'implementazione originaria) si perde
2456 l'atomicità dell'operazione. La scelta fatta dal kernel è pertanto quella di
2457 effettuare subito le operazioni che non prevedono un blocco del processo e di
2458 ignorare silenziosamente le altre; questo però comporta il fatto che il
2459 ripristino non è comunque garantito in tutte le occasioni.
2460
2461 Come esempio di uso dell'interfaccia dei semafori vediamo come implementare
2462 con essa dei semplici \textit{mutex} (cioè semafori binari), tutto il codice
2463 in questione, contenuto nel file \file{Mutex.c} allegato ai sorgenti, è
2464 riportato in \figref{fig:ipc_mutex_create}. Utilizzeremo l'interfaccia per
2465 creare un insieme contenente un singolo semaforo, per il quale poi useremo un
2466 valore unitario per segnalare la disponibilità della risorsa, ed un valore
2467 nullo per segnalarne l'indisponibilità. 
2468
2469 \begin{figure}[!bht]
2470   \footnotesize \centering
2471   \begin{minipage}[c]{15cm}
2472     \begin{lstlisting}{} 
2473 /*
2474  * Function MutexCreate: create a mutex/semaphore
2475  */
2476 int MutexCreate(key_t ipc_key) 
2477 {
2478     const union semun semunion={1};             /* semaphore union structure */
2479     int sem_id, ret;
2480     sem_id = semget(ipc_key, 1, IPC_CREAT|0666);         /* get semaphore ID */
2481     if (sem_id == -1) {                              /* if error return code */
2482         return sem_id;
2483     }
2484     ret = semctl(sem_id, 0, SETVAL, semunion);             /* init semaphore */
2485     if (ret == -1) {
2486         return ret;
2487     }
2488     return sem_id;
2489 }
2490 /*
2491  * Function MutexFind: get the semaphore/mutex Id given the IPC key value
2492  */
2493 int MutexFind(key_t ipc_key) 
2494 {
2495     return semget(ipc_key,1,0);
2496 }
2497 /*
2498  * Function MutexRead: read the current value of the mutex/semaphore
2499  */
2500 int MutexRead(int sem_id) 
2501 {
2502     return semctl(sem_id, 0, GETVAL);
2503 }
2504 /*
2505  * Define sembuf structures to lock and unlock the semaphore 
2506  */
2507 struct sembuf sem_lock={                                /* to lock semaphore */
2508     0,                                   /* semaphore number (only one so 0) */
2509     -1,                                    /* operation (-1 to use resource) */
2510     SEM_UNDO};                                /* flag (set for undo at exit) */
2511 struct sembuf sem_ulock={                             /* to unlock semaphore */
2512     0,                                   /* semaphore number (only one so 0) */
2513     1,                                  /* operation (1 to release resource) */
2514     SEM_UNDO};                                      /* flag (in this case 0) */
2515 /*
2516  * Function MutexLock: to lock a mutex/semaphore
2517  */
2518 int MutexLock(int sem_id) 
2519 {
2520     return semop(sem_id, &sem_lock, 1);
2521 }
2522 /*
2523  * Function MutexUnlock: to unlock a mutex/semaphore
2524  */
2525 int MutexUnlock(int sem_id) 
2526 {
2527     return semop(sem_id, &sem_ulock, 1);
2528 }
2529     \end{lstlisting}
2530   \end{minipage} 
2531   \normalsize 
2532   \caption{Il codice delle funzioni che permettono di creare o recuperare
2533     l'identificatore di un semaforo da utilizzare come \textit{mutex}.}
2534   \label{fig:ipc_mutex_create}
2535 \end{figure}
2536
2537 La prima funzione (\texttt{\small 1--17}) è \func{MutexCreate} che data una
2538 chiave crea il semaforo usato per il mutex e lo inizializza, restituendone
2539 l'identificatore. Il primo passo (\texttt{\small 8}) è chiamare \func{semget}
2540 con \const{IPC\_CREATE} per creare il semaforo qualora non esista,
2541 assegnandogli i privilegi di lettura e scrittura per tutti. In caso di errore
2542 (\texttt{\small 9--11}) si ritorna subito il risultato di \func{semget},
2543 altrimenti (\texttt{\small 12}) si inizializza il semaforo chiamando
2544 \func{semctl} con il comando \const{SETVAL}, utilizzando l'unione
2545 \struct{semunion} dichiarata ed avvalorata in precedenza (\texttt{\small 6})
2546 ad 1 per significare che risorsa è libera. In caso di errore (\texttt{\small
2547   13--16}) si restituisce il valore di ritorno di \func{semctl}, altrimenti si
2548 ritorna l'identificatore del semaforo.
2549
2550 La seconda funzione (\texttt{\small 18--24}) è \func{MutexFind}, che data una
2551 chiave, restituisce l'identificatore del semaforo ad essa associato. La
2552 comprensione del suo funzionamento è immediata in quanto è solo un
2553 \textit{wrapper}\footnote{si chiama così una funzione usata per fare da
2554   \textsl{involucro} alla chiamata di un altra, usata in genere per
2555   semplificare un'interfaccia (come in questo caso) o per utilizzare con la
2556   stessa funzione diversi substrati (librerie, ecc.)  che possono fornire le
2557   stesse funzionalità.} di \func{semget} per cercare l'identificatore
2558 associato alla chiave, restituendo direttamente il valore di ritorno della
2559 funzione.
2560
2561 La terza funzione (\texttt{\small 25--31}) è \func{MutexRead} che, dato
2562 l'identificatore, restituisce il valore del mutex. Anche in questo caso la
2563 funzione è un \textit{wrapper} per la chiamata di \func{semctl}, questa volta
2564 con il comando \const{GETVAL}, che permette di restituire il valore del
2565 semaforo.
2566
2567 La quarta e la quinta funzione (\texttt{\small 43--56}) sono \func{MutexLock},
2568 e \func{MutexUnlock}, che permettono rispettivamente di bloccare e sbloccare
2569 il mutex. Entrambe fanno da wrapper per \func{semop}, utilizzando le due
2570 strutture \var{sem\_lock} e \var{sem\_unlock} definite in precedenza
2571 (\texttt{\small 32--42}). Si noti come per queste ultime si sia fatto uso
2572 dell'opzione \const{SEM\_UNDO} per evitare che il semaforo resti bloccato in
2573 caso di terminazione imprevista del processo.
2574
2575 Chiamare \func{MutexLock} decrementa il valore del semaforo: se questo è
2576 libero (ha già valore 1) sarà bloccato (valore nullo), se è bloccato la
2577 chiamata a \func{semop} si bloccherà fintanto che la risorsa non venga
2578 rilasciata. Chiamando \func{MutexUnlock} il valore del semaforo sarà
2579 incrementato di uno, sbloccandolo qualora fosse bloccato.  Si noti che occorre
2580 eseguire sempre prima \func{MutexLock} e poi \func{MutexUnlock}, perché se per
2581 un qualche errore si esegue più volte quest'ultima il valore del semaforo
2582 crescerebbe oltre 1, e \func{MutexLock} non avrebbe più l'effetto aspettato
2583 (bloccare la risorsa quando questa è considerata libera). Si tenga presente
2584 che usare \func{MutexRead} per controllare il valore dei mutex prima di
2585 proseguire non servirebbe comunque, dato che l'operazione non sarebbe atomica.
2586 Vedremo in \secref{sec:ipc_posix_sem} come è possibile ottenere un'interfaccia
2587 analoga senza questo problemi usando il file locking\index{file!locking}.
2588
2589
2590
2591 \subsection{Memoria condivisa}
2592 \label{sec:ipc_sysv_shm}
2593
2594 Il terzo oggetto introdotto dal \textit{SysV IPC} è quello dei segmenti di
2595 memoria condivisa. La funzione che permette di ottenerne uno è \funcd{shmget},
2596 ed il suo prototipo è:
2597 \begin{functions}
2598   \headdecl{sys/types.h} 
2599   \headdecl{sys/ipc.h} 
2600   \headdecl{sys/shm.h}
2601   
2602   \funcdecl{int shmget(key\_t key, int size, int flag)}
2603   
2604   Restituisce l'identificatore di una memoria condivisa.
2605   
2606   \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
2607     in caso di errore, nel qual caso \var{errno} assumerà i valori:
2608     \begin{errlist}
2609     \item[\errcode{ENOSPC}] Si è superato il limite (\const{SHMMNI}) sul numero
2610       di segmenti di memoria nel sistema, o cercato di allocare un segmento le
2611       cui dimensioni fanno superare il limite di sistema (\const{SHMALL}) per
2612       la memoria ad essi riservata.
2613     \item[\errcode{EINVAL}] Si è richiesta una dimensione per un nuovo segmento
2614       maggiore di \const{SHMMAX} o minore di \const{SHMMIN}, o se il segmento
2615       già esiste \param{size} è maggiore delle sue dimensioni.
2616     \item[\errcode{ENOMEM}] Il sistema non ha abbastanza memoria per poter
2617       contenere le strutture per un nuovo segmento di memoria condivisa.
2618     \end{errlist}
2619     ed inoltre \errval{EACCES}, \errval{ENOENT}, \errval{EEXIST},
2620     \errval{EIDRM}, con lo stesso significato che hanno per \func{msgget}.}
2621 \end{functions}
2622
2623 La funzione, come \func{semget}, è del tutto analoga a \func{msgget}, ed
2624 identico è l'uso degli argomenti \param{key} e \param{flag} per cui non
2625 ripeteremo quanto detto al proposito in \secref{sec:ipc_sysv_mq}. L'argomento
2626 \param{size} specifica invece la dimensione, in byte, del segmento, che viene
2627 comunque arrotondata al multiplo superiore di \const{PAGE\_SIZE}.
2628
2629 La memoria condivisa è la forma più veloce di comunicazione fra due processi,
2630 in quanto permette agli stessi di vedere nel loro spazio di indirizzi una
2631 stessa sezione di memoria.  Pertanto non è necessaria nessuna operazione di
2632 copia per trasmettere i dati da un processo all'altro, in quanto ciascuno può
2633 accedervi direttamente con le normali operazioni di lettura e scrittura dei
2634 dati in memoria.
2635
2636 Ovviamente tutto questo ha un prezzo, ed il problema fondamentale della
2637 memoria condivisa è la sincronizzazione degli accessi. È evidente infatti che
2638 se un processo deve scambiare dei dati con un altro, si deve essere sicuri che
2639 quest'ultimo non acceda al segmento di memoria condivisa prima che il primo
2640 non abbia completato le operazioni di scrittura, inoltre nel corso di una
2641 lettura si deve essere sicuri che i dati restano coerenti e non vengono
2642 sovrascritti da un accesso in scrittura sullo stesso segmento da parte di un
2643 altro processo. Per questo in genere la memoria condivisa viene sempre
2644 utilizzata in abbinamento ad un meccanismo di sincronizzazione, il che, di
2645 norma, significa insieme a dei semafori.
2646
2647 \begin{figure}[!htb]
2648   \footnotesize \centering
2649   \begin{minipage}[c]{15cm}
2650     \begin{lstlisting}[labelstep=0]{}
2651 struct shmid_ds {
2652      struct    ipc_perm shm_perm;  /* operation perms */
2653      int  shm_segsz;               /* size of segment (bytes) */
2654      time_t    shm_atime;          /* last attach time */
2655      time_t    shm_dtime;          /* last detach time */
2656      time_t    shm_ctime;          /* last change time */
2657      unsigned short shm_cpid;      /* pid of creator */
2658      unsigned short shm_lpid;      /* pid of last operator */
2659      short     shm_nattch;         /* no. of current attaches */
2660 };
2661     \end{lstlisting}
2662   \end{minipage} 
2663   \normalsize 
2664   \caption{La struttura \structd{shmid\_ds}, associata a ciascun segmento di
2665     memoria condivisa.}
2666   \label{fig:ipc_shmid_ds}
2667 \end{figure}
2668
2669 A ciascun segmento di memoria condivisa è associata una struttura
2670 \struct{shmid\_ds}, riportata in \figref{fig:ipc_shmid_ds}.  Come nel caso
2671 delle code di messaggi quando si crea un nuovo segmento di memoria condivisa
2672 con \func{shmget} questa struttura viene inizializzata, in particolare il
2673 campo \var{shm\_perm} viene inizializzato come illustrato in
2674 \secref{sec:ipc_sysv_access_control}, e valgono le considerazioni ivi fatte
2675 relativamente ai permessi di accesso; per quanto riguarda gli altri campi
2676 invece:
2677 \begin{itemize*}
2678 \item il campo \var{shm\_segsz}, che esprime la dimensione del segmento, viene
2679   inizializzato al valore di \param{size}.
2680 \item il campo \var{shm\_ctime}, che esprime il tempo di creazione del
2681   segmento, viene inizializzato al tempo corrente.
2682 \item i campi \var{shm\_atime} e \var{shm\_dtime}, che esprimono
2683   rispettivamente il tempo dell'ultima volta che il segmento è stato
2684   agganciato o sganciato da un processo, vengono inizializzati a zero.
2685 \item il campo \var{shm\_lpid}, che esprime il \acr{pid} del processo che ha
2686   eseguito l'ultima operazione, viene inizializzato a zero.
2687 \item il campo \var{shm\_cpid}, che esprime il \acr{pid} del processo che ha
2688   creato il segmento, viene inizializzato al \acr{pid} del processo chiamante.
2689 \item il campo \var{shm\_nattac}, che esprime il numero di processi agganciati
2690   al segmento viene inizializzato a zero.
2691 \end{itemize*}
2692
2693 Come per le code di messaggi e gli insiemi di semafori, anche per i segmenti
2694 di memoria condivisa esistono una serie di limiti imposti dal sistema.  Alcuni
2695 di questi limiti sono al solito accessibili e modificabili attraverso
2696 \func{sysctl} o scrivendo direttamente nei rispettivi file di
2697 \file{/proc/sys/kernel/}. In \tabref{tab:ipc_shm_limits} si sono riportate le
2698 costanti simboliche associate a ciascuno di essi, il loro significato, i
2699 valori preimpostati, e, quando presente, il file in \file{/proc/sys/kernel/}
2700 che permettono di cambiarne il valore. 
2701
2702
2703 \begin{table}[htb]
2704   \footnotesize
2705   \centering
2706   \begin{tabular}[c]{|c|r|c|p{7cm}|}
2707     \hline
2708     \textbf{Costante} & \textbf{Valore} & \textbf{File in \texttt{proc}}
2709     & \textbf{Significato} \\
2710     \hline
2711     \hline
2712     \const{SHMALL}& 0x200000&\file{shmall}& Numero massimo di pagine che 
2713                                        possono essere usate per i segmenti di
2714                                        memoria condivisa. \\
2715     \const{SHMMAX}&0x2000000&\file{shmmax}& Dimensione massima di un segmento 
2716                                             di memoria condivisa.\\
2717     \const{SHMMNI}&     4096&\file{msgmni}& Numero massimo di segmenti di 
2718                                             memoria condivisa presenti nel
2719                                             kernel.\\ 
2720     \const{SHMMIN}&        1& ---         & Dimensione minima di un segmento di
2721                                             memoria condivisa. \\
2722     \const{SHMLBA}&\const{PAGE\_SIZE}&--- & Limite inferiore per le dimensioni
2723                                             minime di un segmento (deve essere
2724                                             allineato alle dimensioni di una
2725                                             pagina di memoria). \\
2726     \const{SHMSEG}&   ---   &     ---     & Numero massimo di segmenti di
2727                                             memoria condivisa 
2728                                             per ciascun processo.\\
2729
2730
2731     \hline
2732   \end{tabular}
2733   \caption{Valori delle costanti associate ai limiti dei segmenti di memoria
2734     condivisa, insieme al relativo file in \file{/proc/sys/kernel/} ed al
2735     valore preimpostato presente nel sistema.} 
2736   \label{tab:ipc_shm_limits}
2737 \end{table}
2738
2739 Al solito la funzione che permette di effettuare le operazioni di controllo su
2740 un segmento di memoria condivisa è \funcd{shmctl}; il suo prototipo è:
2741 \begin{functions}
2742   \headdecl{sys/ipc.h} 
2743   \headdecl{sys/shm.h}
2744   
2745   \funcdecl{int shmctl(int shmid, int cmd, struct shmid\_ds *buf)}
2746   
2747   Esegue le operazioni di controllo su un segmento di memoria condivisa.
2748   
2749   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
2750     errore, nel qual caso \var{errno} assumerà i valori:
2751     \begin{errlist}
2752     \item[\errcode{EACCES}] Si è richiesto \const{IPC\_STAT} ma i permessi non
2753       consentono l'accesso in lettura al segmento.
2754     \item[\errcode{EINVAL}] O \param{shmid} o \param{cmd} hanno valori non
2755       validi.
2756     \item[\errcode{EIDRM}] L'argomento \param{shmid} fa riferimento ad un
2757       segmento che è stato cancellato.
2758     \item[\errcode{EPERM}] Si è specificato un comando con \const{IPC\_SET} o
2759       \const{IPC\_RMID} senza i permessi necessari.
2760     \item[\errcode{EOVERFLOW}] L'argomento \param{shmid} fa riferimento ad un
2761       segmento che è stato cancellato.
2762     \end{errlist}
2763   ed inoltre \errval{EFAULT}.}
2764 \end{functions}
2765
2766 Il comportamento della funzione dipende dal valore del comando passato
2767 attraverso l'argomento \param{cmd}, i valori possibili sono i seguenti:
2768 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
2769 \item[\const{IPC\_STAT}] Legge le informazioni riguardo il segmento di memoria
2770   condivisa nella struttura \struct{shmid\_ds} puntata da \param{buf}. Occorre
2771   avere il permesso di lettura sulla coda.
2772 \item[\const{IPC\_RMID}] Marca il segmento di memoria condivisa per la
2773   rimozione, questo verrà cancellato effettivamente solo quando l'ultimo
2774   processo ad esso agganciato si sarà staccato. Questo comando può essere
2775   eseguito solo da un processo con userid effettivo corrispondente o al
2776   creatore della coda, o al proprietario della coda, o all'amministratore.
2777 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
2778   del segmento.  Per modificare i valori di \var{shm\_perm.mode},
2779   \var{shm\_perm.uid} e \var{shm\_perm.gid} occorre essere il proprietario o
2780   il creatore della coda, oppure l'amministratore. Compiuta l'operazione
2781   aggiorna anche il valore del campo \var{shm\_ctime}.
2782 \item[\const{SHM\_LOCK}] Abilita il \textit{memory locking}\index{memory
2783     locking}\footnote{impedisce cioè che la memoria usata per il segmento
2784     venga salvata su disco dal meccanismo della memoria virtuale; si ricordi
2785     quanto trattato in \secref{sec:proc_mem_lock}.} sul segmento di memoria
2786   condivisa. Solo l'amministratore può utilizzare questo comando.
2787 \item[\const{SHM\_UNLOCK}] Disabilita il \textit{memory locking} sul segmento
2788   di memoria condivisa. Solo l'amministratore può utilizzare questo comando.
2789 \end{basedescript}
2790 i primi tre comandi sono gli stessi già visti anche per le code ed i semafori,
2791 gli ultimi due sono delle estensioni previste da Linux. 
2792
2793 Per utilizzare i segmenti di memoria condivisa l'interfaccia prevede due
2794 funzioni, la prima è \funcd{shmat}, che serve ad agganciare un segmento al
2795 processo chiamante, in modo che quest'ultimo possa vederlo nel suo spazio di
2796 indirizzi; il suo prototipo è:
2797 \begin{functions}
2798   \headdecl{sys/types.h} 
2799   \headdecl{sys/shm.h}
2800   
2801   \funcdecl{void *shmat(int shmid, const void *shmaddr, int shmflg)}
2802   Aggancia al processo un segmento di memoria condivisa.
2803   
2804   \bodydesc{La funzione restituisce l'indirizzo del segmento in caso di
2805     successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà i
2806     valori:
2807     \begin{errlist}
2808     \item[\errcode{EACCES}] Il processo non ha i privilegi per accedere al
2809       segmento nella modalità richiesta.
2810     \item[\errcode{EINVAL}] Si è specificato un identificatore invalido per
2811       \param{shmid}, o un indirizzo non allineato sul confine di una pagina
2812       per \param{shmaddr}.
2813     \end{errlist}
2814     ed inoltre \errval{ENOMEM}.}
2815 \end{functions}
2816
2817 La funzione inserisce un segmento di memoria condivisa all'interno dello
2818 spazio di indirizzi del processo, in modo che questo possa accedervi
2819 direttamente, la situazione dopo l'esecuzione di \func{shmat} è illustrata in
2820 \figref{fig:ipc_shmem_layout} (per la comprensione del resto dello schema si
2821 ricordi quanto illustrato al proposito in \secref{sec:proc_mem_layout}). In
2822 particolare l'indirizzo finale del segmento dati (quello impostato da
2823 \func{brk}, vedi \secref{sec:proc_mem_sbrk}) non viene influenzato. Si tenga
2824 presente infine che la funzione ha successo anche se il segmento è stato
2825 marcato per la cancellazione.
2826
2827 \begin{figure}[htb]
2828   \centering
2829   \includegraphics[height=10cm]{img/sh_memory_layout}
2830   \caption{Disposizione dei segmenti di memoria di un processo quando si è
2831     agganciato un segmento di memoria condivisa.}
2832   \label{fig:ipc_shmem_layout}
2833 \end{figure}
2834
2835 L'argomento \param{shmaddr} specifica a quale indirizzo\footnote{Lo standard
2836   SVID prevede che l'argomento \param{shmaddr} sia di tipo \ctyp{char *}, così
2837   come il valore di ritorno della funzione. In Linux è stato così con le
2838   \acr{libc4} e le \acr{libc5}, con il passaggio alle \acr{glibc} il tipo di
2839   \param{shmaddr} è divenuto un \ctyp{const void *} e quello del valore di
2840   ritorno un \ctyp{void *}.} deve essere associato il segmento, se il valore
2841 specificato è \val{NULL} è il sistema a scegliere opportunamente un'area di
2842 memoria libera (questo è il modo più portabile e sicuro di usare la funzione).
2843 Altrimenti il kernel aggancia il segmento all'indirizzo specificato da
2844 \param{shmaddr}; questo però può avvenire solo se l'indirizzo coincide con il
2845 limite di una pagina, cioè se è un multiplo esatto del parametro di sistema
2846 \const{SHMLBA}, che in Linux è sempre uguale \const{PAGE\_SIZE}. 
2847
2848 Si tenga presente però che quando si usa \val{NULL} come valore di
2849 \param{shmaddr}, l'indirizzo restituito da \func{shmat} può cambiare da
2850 processo a processo; pertanto se nell'area di memoria condivisa si salvano
2851 anche degli indirizzi, si deve avere cura di usare valori relativi (in genere
2852 riferiti all'indirizzo di partenza del segmento).
2853
2854 L'argomento \param{shmflg} permette di cambiare il comportamento della
2855 funzione; esso va specificato come maschera binaria, i bit utilizzati sono
2856 solo due e sono identificati dalle costanti \const{SHM\_RND} e
2857 \const{SHM\_RDONLY}, che vanno combinate con un OR aritmetico.  Specificando
2858 \const{SHM\_RND} si evita che \func{shmat} ritorni un errore quando
2859 \param{shmaddr} non è allineato ai confini di una pagina. Si può quindi usare
2860 un valore qualunque per \param{shmaddr}, e il segmento verrà comunque
2861 agganciato, ma al più vicino multiplo di \const{SHMLBA} (il nome della
2862 costante sta infatti per \textit{rounded}, e serve per specificare un
2863 indirizzo come arrotondamento, in Linux è equivalente a \const{PAGE\_SIZE}).
2864
2865 L'uso di \const{SHM\_RDONLY} permette di agganciare il segmento in sola
2866 lettura (si ricordi che anche le pagine di memoria hanno dei permessi), in tal
2867 caso un tentativo di scrivere sul segmento comporterà una violazione di
2868 accesso con l'emissione di un segnale di \const{SIGSEGV}. Il comportamento
2869 usuale di \func{shmat} è quello di agganciare il segmento con l'accesso in
2870 lettura e scrittura (ed il processo deve aver questi permessi in
2871 \var{shm\_perm}), non è prevista la possibilità di agganciare un segmento in
2872 sola scrittura.
2873
2874 In caso di successo la funzione aggiorna anche i seguenti campi di
2875 \struct{shmid\_ds}:
2876 \begin{itemize*}
2877 \item il tempo \var{shm\_atime} dell'ultima operazione di aggancio viene
2878   impostato al tempo corrente.
2879 \item il \acr{pid} \var{shm\_lpid} dell'ultimo processo che ha operato sul
2880   segmento viene impostato a quello del processo corrente.
2881 \item il numero \var{shm\_nattch} di processi agganciati al segmento viene
2882   aumentato di uno.
2883 \end{itemize*} 
2884
2885 Come accennato in \secref{sec:proc_fork} un segmento di memoria condivisa
2886 agganciato ad un processo viene ereditato da un figlio attraverso una
2887 \func{fork}, dato che quest'ultimo riceve una copia dello spazio degli
2888 indirizzi del padre. Invece, dato che attraverso una \func{exec} viene
2889 eseguito un diverso programma con uno spazio di indirizzi completamente
2890 diverso, tutti i segmenti agganciati al processo originario vengono
2891 automaticamente sganciati. Lo stesso avviene all'uscita del processo
2892 attraverso una \func{exit}.
2893
2894 Una volta che un segmento di memoria condivisa non serve più, si può
2895 sganciarlo esplicitamente dal processo usando l'altra funzione
2896 dell'interfaccia, \funcd{shmdt}, il cui prototipo è:
2897 \begin{functions}
2898   \headdecl{sys/types.h} 
2899   \headdecl{sys/shm.h}
2900
2901   \funcdecl{int shmdt(const void *shmaddr)}
2902   Sgancia dal processo un segmento di memoria condivisa.
2903   
2904   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
2905     errore, la funzione fallisce solo quando non c'è un segmento agganciato
2906     all'indirizzo \func{shmaddr}, con \var{errno} che assume il valore
2907     \errval{EINVAL}.}
2908 \end{functions}
2909
2910 La funzione sgancia dallo spazio degli indirizzi del processo un segmento di
2911 memoria condivisa; questo viene identificato con l'indirizzo \param{shmaddr}
2912 restituito dalla precedente chiamata a \func{shmat} con il quale era stato
2913 agganciato al processo.
2914
2915 In caso di successo la funzione aggiorna anche i seguenti campi di
2916 \struct{shmid\_ds}:
2917 \begin{itemize*}
2918 \item il tempo \var{shm\_dtime} dell'ultima operazione di sganciamento viene
2919   impostato al tempo corrente.
2920 \item il \acr{pid} \var{shm\_lpid} dell'ultimo processo che ha operato sul
2921   segmento viene impostato a quello del processo corrente.
2922 \item il numero \var{shm\_nattch} di processi agganciati al segmento viene
2923   decrementato di uno.
2924 \end{itemize*} 
2925 inoltre la regione di indirizzi usata per il segmento di memoria condivisa
2926 viene tolta dallo spazio di indirizzi del processo.
2927
2928 Benché la memoria condivisa costituisca il meccanismo di intercomunicazione
2929 fra processi più veloce, essa non è sempre il più appropriato, dato che, come
2930 abbiamo visto, si avrà comunque la necessità di una sincronizzazione degli
2931 accessi.  Per questo motivo, quando la comunicazione fra processi è
2932 sequenziale, altri meccanismi come le pipe, le fifo o i socket, che non
2933 necessitano di sincronizzazione esplicita, sono da preferire. Essa diventa
2934 l'unico meccanismo possibile quando la comunicazione non è
2935 sequenziale\footnote{come accennato in \secref{sec:ipc_sysv_mq} per la
2936   comunicazione non sequenziale si possono usare le code di messaggi,
2937   attraverso l'uso del campo \var{mtype}, ma solo se quest'ultima può essere
2938   effettuata in forma di messaggio.} o quando non può avvenire secondo una
2939 modalità predefinita.
2940
2941 Un esempio classico di uso della memoria condivisa è quello del
2942 ``\textit{monitor}'', in cui essa viene per scambiare informazioni fra un
2943 processo ``server'' che vi scrive dei dati di interesse generale che ha
2944 ottenuto, e tutti i processi ``client'' interessati agli stessi dati che così
2945 possono leggerli in maniera completamente asincrona.  Con questo schema di
2946 funzionamento da una parte si evita che ciascun processo ``client'' debba
2947 compiere l'operazione, potenzialmente onerosa, di ricavare e trattare i dati,
2948 e dall'altra si evita al processo ``server'' di dover gestire l'invio a tutti
2949 i client di tutti i dati (non potendo il server sapere quali di essi servono
2950 effettivamente al singolo client).
2951
2952 Nel nostro caso implementeremo un ``monitor'' di una directory: un processo si
2953 incaricherà di tenere sotto controllo alcuni parametri relativi ad una
2954 directory (il numero dei file contenuti, la dimensione totale, ecc.) che
2955 saranno salvati in un segmento di memoria condivisa cui altri processi
2956 potranno accedere per ricavare la parte di informazione che interessa.
2957
2958
2959
2960
2961 %% Per capire meglio il funzionamento delle funzioni facciamo ancora una volta
2962 %% riferimento alle strutture con cui il kernel implementa i segmenti di memoria
2963 %% condivisa; uno schema semplificato della struttura è illustrato in
2964 %% \figref{fig:ipc_shm_struct}. 
2965
2966 %% \begin{figure}[htb]
2967 %%   \centering
2968 %%   \includegraphics[width=10cm]{img/shmstruct}
2969 %%    \caption{Schema dell'implementazione dei segmenti di memoria condivisa in
2970 %%     Linux.}
2971 %%   \label{fig:ipc_shm_struct}
2972 %% \end{figure}
2973
2974
2975
2976
2977 \section{Tecniche alternative}
2978 \label{sec:ipc_alternatives}
2979
2980 Come abbiamo detto in \secref{sec:ipc_sysv_generic}, e ripreso nella
2981 descrizione dei singoli oggetti che ne fan parte, il \textit{SysV IPC}
2982 presenta numerosi problemi; in \cite{APUE}\footnote{in particolare nel
2983   capitolo 14.}  Stevens ne effettua una accurata analisi (alcuni dei
2984 concetti sono già stati accennati in precedenza) ed elenca alcune possibili
2985 tecniche alternative, che vogliamo riprendere in questa sezione.
2986
2987
2988 \subsection{Alternative alle code di messaggi}
2989 \label{sec:ipc_mq_alternative}
2990  
2991 Le code di messaggi sono probabilmente il meno usato degli oggetti del
2992 \textit{SysV IPC}; esse infatti nacquero principalmente come meccanismo di
2993 comunicazione bidirezionale quando ancora le pipe erano unidirezionali; con la
2994 disponibilità di \func{socketpair} (vedi \secref{sec:ipc_socketpair}) o
2995 utilizzando una coppia di pipe, si può ottenere questo risultato senza
2996 incorrere nelle complicazioni introdotte dal \textit{SysV IPC}.
2997
2998 In realtà, grazie alla presenza del campo \var{mtype}, le code di messaggi
2999 hanno delle caratteristiche ulteriori, consentendo una classificazione dei
3000 messaggi ed un accesso non rigidamente sequenziale; due caratteristiche che
3001 sono impossibili da ottenere con le pipe e i socket\index{socket} di
3002 \func{socketpair}.  A queste esigenze però si può comunque ovviare in maniera
3003 diversa con un uso combinato della memoria condivisa e dei meccanismi di
3004 sincronizzazione, per cui alla fine l'uso delle code di messaggi classiche è
3005 relativamente poco diffuso.
3006
3007
3008
3009 \subsection{I \textsl{file di lock}}
3010 \label{sec:ipc_file_lock}
3011
3012 \index{file!di lock|(}
3013 Come illustrato in \secref{sec:ipc_sysv_sem} i semafori del \textit{SysV IPC}
3014 presentano una interfaccia inutilmente complessa e con alcuni difetti
3015 strutturali, per questo quando si ha una semplice esigenza di sincronizzazione
3016 per la quale basterebbe un semaforo binario (quello che abbiamo definito come
3017 \textit{mutex}), per indicare la disponibilità o meno di una risorsa, senza la
3018 necessità di un contatore come i semafori, si possono utilizzare metodi
3019 alternativi.
3020
3021 La prima possibilità, utilizzata fin dalle origini di Unix, è quella di usare
3022 dei \textsl{file di lock} (per i quali esiste anche una opportuna directory,
3023 \file{/var/lock}, nel filesystem standard). Per questo si usa la
3024 caratteristica della funzione \func{open} (illustrata in
3025 \secref{sec:file_open}) che prevede\footnote{questo è quanto dettato dallo
3026   standard POSIX.1, ciò non toglie che in alcune implementazioni questa
3027   tecnica possa non funzionare; in particolare per Linux, nel caso di NFS, si
3028   è comunque soggetti alla possibilità di una race condition.} che essa
3029 ritorni un errore quando usata con i flag di \const{O\_CREAT} e
3030 \const{O\_EXCL}. In tal modo la creazione di un \textsl{file di lock} può
3031 essere eseguita atomicamente, il processo che crea il file con successo si può
3032 considerare come titolare del lock (e della risorsa ad esso associata) mentre
3033 il rilascio si può eseguire con una chiamata ad \func{unlink}.
3034
3035 Un esempio dell'uso di questa funzione è mostrato dalle funzioni
3036 \func{LockFile} ed \func{UnlockFile} riportate in \figref{fig:ipc_file_lock}
3037 (sono contenute in \file{LockFile.c}, un'altro dei sorgenti allegati alla
3038 guida) che permettono rispettivamente di creare e rimuovere un \textsl{file di
3039   lock}. Come si può notare entrambe le funzioni sono elementari; la prima
3040 (\texttt{\small 4--10}) si limita ad aprire il file di lock (\texttt{\small
3041   9}) nella modalità descritta, mentre la seconda (\texttt{\small 11--17}) lo
3042 cancella con \func{unlink}.
3043
3044 \begin{figure}[!htb]
3045   \footnotesize \centering
3046   \begin{minipage}[c]{15cm}
3047     \begin{lstlisting}{} 
3048 #include <sys/types.h>
3049 #include <sys/stat.h>
3050 #include <unistd.h>                               /* unix standard functions */
3051 /*
3052  * Function LockFile:
3053  */
3054 int LockFile(const char* path_name)
3055 {
3056     return open(path_name, O_EXCL|O_CREAT);
3057 }
3058 /*
3059  * Function UnlockFile:
3060  */
3061 int UnlockFile(const char* path_name) 
3062 {
3063     return unlink(path_name);
3064 }
3065
3066     \end{lstlisting}
3067   \end{minipage} 
3068   \normalsize 
3069   \caption{Il codice delle funzioni \func{LockFile} e \func{UnlockFile} che
3070     permettono di creare e rimuovere un \textsl{file di lock}.}
3071   \label{fig:ipc_file_lock}
3072 \end{figure}
3073
3074 Uno dei limiti di questa tecnica è che, come abbiamo già accennato in
3075 \secref{sec:file_open}, questo comportamento di \func{open} può non funzionare
3076 (la funzione viene eseguita, ma non è garantita l'atomicità dell'operazione)
3077 se il filesystem su cui si va ad operare è su NFS; in tal caso si può adottare
3078 una tecnica alternativa che prevede l'uso della \func{link} per creare come
3079 \textsl{file di lock} un hard link ad un file esistente; se il link esiste già
3080 e la funzione fallisce, significa che la risorsa è bloccata e potrà essere
3081 sbloccata solo con un \func{unlink}, altrimenti il link è creato ed il lock
3082 acquisito; il controllo e l'eventuale acquisizione sono atomici; la soluzione
3083 funziona anche su NFS, ma ha un'altro difetto è che è quello di poterla usare
3084 solo se si opera all'interno di uno stesso filesystem.
3085
3086 Un generale comunque l'uso di un \textsl{file di lock} presenta parecchi
3087 problemi, che non lo rendono una alternativa praticabile per la
3088 sincronizzazione: anzitutto anche in questo caso, in caso di terminazione
3089 imprevista del processo, si lascia allocata la risorsa (il \textsl{file di
3090   lock}) e questa deve essere sempre cancellata esplicitamente.  Inoltre il
3091 controllo della disponibilità può essere eseguito solo con una tecnica di
3092 \textit{polling}\index{polling}, ed è quindi molto inefficiente.
3093
3094 La tecnica dei file di lock non di meno ha una sua utilità, e può essere usata
3095 con successo quando l'esigenza è solo quella di segnalare l'occupazione di una
3096 risorsa, senza necessità di attendere che questa si liberi; ad esempio la si
3097 usa spesso per evitare interferenze sull'uso delle porte seriali da parte di
3098 più programmi: qualora si trovi un file di lock il programma che cerca di
3099 accedere alla seriale si limita a segnalare che la risorsa non è
3100 disponibile.\index{file!di lock|)}
3101
3102 \subsection{La sincronizzazione con il \textit{file locking}}
3103 \label{sec:ipc_lock_file}
3104
3105 Dato che i file di lock presentano gli inconvenienti illustrati in precedenza,
3106 la tecnica alternativa più comune è quella di fare ricorso al \textit{file
3107   locking}\index{file!locking} (trattato in \secref{sec:file_locking}) usando
3108 \func{fcntl} su un file creato per l'occasione per ottenere un write lock. In
3109 questo modo potremo usare il lock come un \textit{mutex}: per bloccare la
3110 risorsa basterà acquisire il lock, per sbloccarla basterà rilasciare il lock;
3111 una richiesta fatta con un write lock metterà automaticamente il processo in
3112 stato di attesa, senza necessità di ricorrere al
3113 \textit{polling}\index{polling} per determinare la disponibilità della
3114 risorsa, e al rilascio della stessa da parte del processo che la occupava si
3115 otterrà il nuovo lock atomicamente.
3116
3117 Questo approccio presenta il notevole vantaggio che alla terminazione di un
3118 processo tutti i lock acquisiti vengono rilasciati automaticamente (alla
3119 chiusura dei relativi file) e non ci si deve preoccupare di niente, inoltre
3120 non consuma risorse permanentemente allocate nel sistema, lo svantaggio è che
3121 dovendo fare ricorso a delle operazioni sul filesystem esso è in genere
3122 leggermente più lento.
3123
3124 \begin{figure}[!htb]
3125   \footnotesize \centering
3126   \begin{minipage}[c]{15cm}
3127     \begin{lstlisting}{} 
3128 /*
3129  * Function LockMutex: lock a file (creating it if not existent).  
3130  */
3131 int LockMutex(const char *path_name)
3132 {
3133     int fd, res;
3134     struct flock lock;                                /* file lock structure */
3135     /* first open the file (creating it if not existent) */
3136     if ( (fd = open(path_name, O_EXCL|O_CREAT)) < 0) {    /* first open file */
3137         return fd;
3138     }
3139     /* set flock structure */
3140     lock.l_type = F_WRLCK;                        /* set type: read or write */
3141     lock.l_whence = SEEK_SET;        /* start from the beginning of the file */
3142     lock.l_start = 0;                  /* set the start of the locked region */
3143     lock.l_len = 0;                   /* set the length of the locked region */
3144     /* do locking */
3145     if ( (res = fcntl(fd, F_SETLKW, &lock)) < 0 ) {
3146         return res;
3147     }
3148     return 0;
3149 }
3150 /*
3151  * Function UnLockMutex: unlock a file.  
3152  */
3153 int UnlockMutex(const char *path_name)
3154 {
3155     int fd, res;
3156     struct flock lock;                                /* file lock structure */
3157     /* first open the file */
3158     if ( (fd = open(path_name, O_RDWR)) < 0) {            /* first open file */
3159         return fd;
3160     }
3161     /* set flock structure */
3162     lock.l_type = F_UNLCK;                               /* set type: unlock */
3163     lock.l_whence = SEEK_SET;        /* start from the beginning of the file */
3164     lock.l_start = 0;                  /* set the start of the locked region */
3165     lock.l_len = 0;                   /* set the length of the locked region */
3166     /* do locking */
3167     if ( (res = fcntl(fd, F_SETLK, &lock)) < 0 ) {
3168         return res;
3169     }
3170     return 0;
3171 }
3172     \end{lstlisting}
3173   \end{minipage} 
3174   \normalsize 
3175   \caption{Il codice delle funzioni che permettono di creare un
3176     \textit{mutex} utilizzando il file locking\index{file!locking}.}
3177   \label{fig:ipc_flock_mutex}
3178 \end{figure}
3179
3180 Il codice per implementare un mutex utilizzando il file
3181 locking\index{file!locking} è riportato in \figref{fig:ipc_flock_mutex}; a
3182 differenza del precedente caso in cui si sono usati i semafori le funzioni
3183 questa volta sono sufficienti due funzioni, \func{LockMutex} e
3184 \func{UnlockMutex}, usate rispettivamente per acquisire e rilasciare il mutex.
3185
3186 La prima funzione (\texttt{\small 1--22}) serve per acquisire il mutex.
3187 Anzitutto si apre (\texttt{\small 9--11}), creandolo se non esiste, il file
3188 specificato dall'argomento \param{pathname}. In caso di errore si ritorna
3189 immediatamente, altrimenti si prosegue impostando (\texttt{\small 12--16}) la
3190 struttura \var{lock} in modo da poter acquisire un write lock sul file.
3191 Infine si richiede (\texttt{\small 17--20}) il file lock (restituendo il
3192 codice di ritorno di \func{fcntl} caso di errore). Se il file è libero il lock
3193 è acquisito e la funzione ritorna immediatamente; altrimenti \func{fcntl} si
3194 bloccherà (si noti che la si è chiamata con \func{F\_SETLKW}) fino al rilascio
3195 del lock.
3196
3197 La seconda funzione (\texttt{\small 23--44}) serve a rilasciare il mutex. Di
3198 nuovo si apre (\texttt{\small 30--33}) il file specificato dall'argomento
3199 \param{pathname} (che stavolta deve esistere), ritornando immediatamente in
3200 caso di errore. Poi si passa ad inizializzare (\texttt{\small 34--38}) la
3201 struttura \var{lock} per il rilascio del lock, che viene effettuato
3202 (\texttt{\small 39--42}) subito dopo.
3203
3204  \subsection{Il \textit{memory mapping} anonimo}
3205 \label{sec:ipc_mmap_anonymous}
3206
3207 Abbiamo già visto che quando i processi sono \textsl{correlati}\footnote{se
3208   cioè hanno almeno un progenitore comune.} l'uso delle pipe può costituire
3209 una valida alternativa alle code di messaggi; nella stessa situazione si può
3210 evitare l'uso di una memoria condivisa facendo ricorso al cosiddetto
3211 \textit{memory mapping} anonimo.
3212
3213 Abbiamo visto in \secref{sec:file_memory_map} che è possibile mappare il
3214 contenuto di un file nella memoria di un processo, e che, quando viene usato
3215 il flag \const{MAP\_SHARED}, le modifiche effettuate al contenuto del file
3216 vengono viste da tutti i processi che lo hanno mappato. Utilizzare questa
3217 tecnica per creare una memoria condivisa fra processi diversi è estremamente
3218 inefficiente, in quanto occorre passare attraverso il disco. Però abbiamo
3219 visto anche che se si esegue la mappatura con il flag \const{MAP\_ANONYMOUS}
3220 la regione mappata non viene associata a nessun file, anche se quanto scritto
3221 rimane in memoria e può essere riletto; allora, dato che un processo figlio
3222 mantiene nel suo spazio degli indirizzi anche le regioni mappate, esso sarà
3223 anche in grado di accedere a quanto in esse è contenuto.
3224
3225 In questo modo diventa possibile creare una memoria condivisa fra processi
3226 diversi, purché questi abbiano almeno un progenitore comune che ha effettuato
3227 il \textit{memory mapping} anonimo.\footnote{nei sistemi derivati da SysV una
3228   funzionalità simile a questa viene implementata mappando il file speciale
3229   \file{/dev/zero}. In tal caso i valori scritti nella regione mappata non
3230   vengono ignorati (come accade qualora si scriva direttamente sul file), ma
3231   restano in memoria e possono essere riletti secondo le stesse modalità usate
3232   nel \textit{memory mapping} anonimo.} Un esempio di utilizzo di questa
3233 tecnica è mostrato in 
3234
3235
3236
3237 \section{La comunicazione fra processi di POSIX}
3238 \label{sec:ipc_posix}
3239
3240 Per superare i numerosi problemi del \textit{SysV IPC}, evidenziati per i suoi
3241 aspetti generali in coda a \secref{sec:ipc_sysv_generic} e per i singoli
3242 oggetti nei paragrafi successivi, lo standard POSIX.1b ha introdotto dei nuovi
3243 meccanismi di comunicazione, che vanno sotto il nome di POSIX IPC, definendo
3244 una interfaccia completamente nuova, che tratteremo in questa sezione.
3245
3246
3247
3248 \subsection{Considerazioni generali}
3249 \label{sec:ipc_posix_generic}
3250
3251 Il Linux non tutti gli oggetti del POSIX IPC sono supportati nel kernel
3252 ufficiale; solo la memoria condivisa è presente, ma solo a partire dal kernel
3253 2.4.x, per gli altri oggetti esistono patch e librerie non ufficiali.
3254 Nonostante questo è importante esaminare questa interfaccia per la sua netta
3255 superiorità nei confronti di quella del \textit{SysV IPC}.
3256
3257
3258 \subsection{Code di messaggi}
3259 \label{sec:ipc_posix_mq}
3260
3261 Le code di messaggi non sono ancora supportate nel kernel
3262 ufficiale;\footnote{esiste però una proposta di implementazione di Krzysztof
3263   Benedyczak, a partire dal kernel 2.5.50.}  inoltre esse possono essere
3264 implementate, usando la memoria condivisa ed i mutex, con funzioni di
3265 libreria. In generale, come le corrispettive del SysV IPC, sono poco usate,
3266 dato che i socket\index{socket}, nei casi in cui sono sufficienti, sono più
3267 comodi, e negli altri casi la comunicazione può essere gestita direttamente
3268 con mutex e memoria condivisa. Per questo ci limiteremo ad una descrizione
3269 essenziale.
3270
3271
3272
3273 \subsection{Semafori}
3274 \label{sec:ipc_posix_sem}
3275
3276 Dei semafori POSIX esistono sostanzialmente due implementazioni; una è fatta a
3277 livello di libreria ed è fornita dalla libreria dei thread; questa però li
3278 implementa solo a livello di thread e non di processi. Esiste un'altra
3279 versione, realizzata da Konstantin Knizhnik, che reimplementa l'interfaccia
3280 POSIX usando i semafori di SysV IPC. 
3281
3282
3283 \subsection{Memoria condivisa}
3284 \label{sec:ipc_posix_shm}
3285
3286 La memoria condivisa è l'unico degli oggetti di IPC POSIX già presente nel
3287 kernel ufficiale. 
3288
3289
3290 %%% Local Variables: 
3291 %%% mode: latex
3292 %%% TeX-master: "gapil"
3293 %%% End: