Programma per scrivere su una shared memory.
[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 file, 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 stdout */ 
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
565 ``\textsl{nota}'', per le risposte non si può fare altrettanto, dato che, per
566 la struttura sequenziale delle fifo, i client dovrebbero sapere, prima di
567 leggerli, quando i dati inviati sono destinati a loro.
568
569 Per risolvere questo problema, si può usare un'architettura come quella
570 illustrata in \figref{fig:ipc_fifo_server_arch} in cui i client inviano le
571 richieste al server su una fifo nota mentre le risposte vengono reinviate dal
572 server a ciascuno di essi su una fifo temporanea creata per l'occasione.
573
574 \begin{figure}[htb]
575   \centering
576   \includegraphics[height=9cm]{img/fifoserver}
577   \caption{Schema dell'utilizzo delle fifo nella realizzazione di una
578   architettura di comunicazione client/server.}
579   \label{fig:ipc_fifo_server_arch}
580 \end{figure}
581
582 Come esempio di uso questa architettura e dell'uso delle fifo, abbiamo scritto
583 un server di \textit{fortunes}, che restituisce, alle richieste di un client,
584 un detto a caso estratto da un insieme di frasi; sia il numero delle frasi
585 dell'insieme, che i file da cui esse vengono lette all'avvio, sono importabili
586 da riga di comando. Il corpo principale del server è riportato in
587 \figref{fig:ipc_fifo_server}, dove si è tralasciata la parte che tratta la
588 gestione delle opzioni a riga di comando, che effettua il settaggio delle
589 variabili \var{fortunefilename}, che indica il file da cui leggere le frasi,
590 ed \var{n}, che indica il numero di frasi tenute in memoria, ad un valore
591 diverso da quelli preimpostati. Il codice completo è nel file
592 \file{FortuneServer.c}.
593
594 \begin{figure}[!htb]
595   \footnotesize \centering
596   \begin{minipage}[c]{15cm}
597     \begin{lstlisting}{}
598 char *fifoname = "/tmp/fortune.fifo";
599 int main(int argc, char *argv[])
600 {
601 /* Variables definition */
602     int i, n = 0;
603     char *fortunefilename = "/usr/share/games/fortunes/linux";
604     char **fortune;
605     char line[80];
606     int fifo_server, fifo_client;
607     int nread;
608     ...
609     if (n==0) usage();          /* if no pool depth exit printing usage info */
610     Signal(SIGTERM, HandSIGTERM);            /* set handlers for termination */
611     Signal(SIGINT, HandSIGTERM);
612     Signal(SIGQUIT, HandSIGTERM);
613     i = FortuneParse(fortunefilename, fortune, n);          /* parse phrases */
614     if (mkfifo(fifoname, 0622)) {  /* create well known fifo if does't exist */
615         if (errno!=EEXIST) {
616             perror("Cannot create well known fifo");
617             exit(1);
618         }
619     }
620     daemon(0, 0);
621     /* open fifo two times to avoid EOF */
622     fifo_server = open(fifoname, O_RDONLY);
623     if (fifo_server < 0) {
624         perror("Cannot open read only well known fifo");
625         exit(1);
626     }
627     if (open(fifoname, O_WRONLY) < 0) {                        
628         perror("Cannot open write only well known fifo");
629         exit(1);
630     }
631     /* Main body: loop over requests */
632     while (1) {
633         nread = read(fifo_server, line, 79);                 /* read request */
634         if (nread < 0) {
635             perror("Read Error");
636             exit(1);
637         }
638         line[nread] = 0;                       /* terminate fifo name string */
639         n = random() % i;                             /* select random value */
640         fifo_client = open(line, O_WRONLY);              /* open client fifo */
641         if (fifo_client < 0) {
642             perror("Cannot open");
643             exit(1);
644         }
645         nread = write(fifo_client,                           /* write phrase */
646                       fortune[n], strlen(fortune[n])+1);
647         close(fifo_client);                             /* close client fifo */
648     }
649 }
650     \end{lstlisting}
651   \end{minipage} 
652   \normalsize 
653   \caption{Sezione principale del codice del server di \textit{fortunes}
654     basato sulle fifo.}
655   \label{fig:ipc_fifo_server}
656 \end{figure}
657
658 Il server richiede (\texttt{\small 12}) che sia stata impostata una dimensione
659 dell'insieme delle frasi non nulla, dato che l'inizializzazione del vettore
660 \var{fortune} avviene solo quando questa dimensione viene specificata, la
661 presenza di un valore nullo provoca l'uscita dal programma attraverso la
662 routine (non riportata) che ne stampa le modalità d'uso.  Dopo di che installa
663 (\texttt{\small 13--15}) la funzione che gestisce i segnali di interruzione
664 (anche questa non è riportata in \figref{fig:ipc_fifo_server}) che si limita a
665 rimuovere dal filesystem la fifo usata dal server per comunicare.
666
667 Terminata l'inizializzazione (\texttt{\small 16}) si effettua la chiamata alla
668 funzione \code{FortuneParse} che legge dal file specificato in
669 \var{fortunefilename} le prime \var{n} frasi e le memorizza (allocando
670 dinamicamente la memoria necessaria) nel vettore di puntatori \var{fortune}.
671 Anche il codice della funzione non è riportato, in quanto non direttamente
672 attinente allo scopo dell'esempio.
673
674 Il passo successivo (\texttt{\small 17--22}) è quello di creare con
675 \func{mkfifo} la fifo nota sulla quale il server ascolterà le richieste,
676 qualora si riscontri un errore il server uscirà (escludendo ovviamente il caso
677 in cui la funzione \func{mkfifo} fallisce per la precedente esistenza della
678 fifo).
679
680 Una volta che si è certi che la fifo di ascolto esiste la procedura di
681 inizializzazione è completata. A questo punto si può chiamare (\texttt{\small
682   23}) la funzione \func{daemon} per far proseguire l'esecuzione del programma
683 in background come demone.  Si può quindi procedere (\texttt{\small 24--33})
684 alla apertura della fifo: si noti che questo viene fatto due volte, prima in
685 lettura e poi in scrittura, per evitare di dover gestire all'interno del ciclo
686 principale il caso in cui il server è in ascolto ma non ci sono client che
687 effettuano richieste.  Si ricordi infatti che quando una fifo è aperta solo
688 dal capo in lettura, l'esecuzione di \func{read} ritorna con zero byte (si ha
689 cioè una condizione di end-of-file).
690
691 Nel nostro caso la prima apertura si bloccherà fintanto che un qualunque
692 client non apre a sua volta la fifo nota in scrittura per effettuare la sua
693 richiesta. Pertanto all'inizio non ci sono problemi, il client però, una volta
694 ricevuta la risposta, uscirà, chiudendo tutti i file aperti, compresa la fifo.
695 A questo punto il server resta (se non ci sono altri client che stanno
696 effettuando richieste) con la fifo chiusa sul lato in lettura, ed in questo
697 stato la funzione \func{read} non si bloccherà in attesa di input, ma
698 ritornerà in continuazione, restituendo un end-of-file.\footnote{Si è usata
699   questa tecnica per compatibilità, Linux infatti supporta l'apertura delle
700   fifo in lettura/scrittura, per cui si sarebbe potuto effettuare una singola
701   apertura con \const{O\_RDWR}, la doppia apertura comunque ha il vantaggio
702   che non si può scrivere per errore sul capo aperto in sola lettura.}
703
704 Per questo motivo, dopo aver eseguito l'apertura in lettura (\texttt{\small
705   24--28}),\footnote{di solito si effettua l'apertura del capo in lettura di
706   una fifo in modalità non bloccante, per evitare il rischio di uno stallo: se
707   infatti nessuno apre la fifo in scrittura il processo non ritornerà mai
708   dalla \func{open}. Nel nostro caso questo rischio non esiste, mentre è
709   necessario potersi bloccare in lettura in attesa di una richiesta.} si
710 esegue una seconda apertura in scrittura (\texttt{\small 29--32}), scartando
711 il relativo file descriptor, che non sarà mai usato, in questo modo però la
712 fifo resta comunque aperta anche in scrittura, cosicché le successive chiamate
713 a \func{read} possono bloccarsi.
714
715 A questo punto si può entrare nel ciclo principale del programma che fornisce
716 le risposte ai client (\texttt{\small 34--50}); questo viene eseguito
717 indefinitamente (l'uscita del server viene effettuata inviando un segnale, in
718 modo da passare attraverso la routine di chiusura che cancella la fifo).
719
720 Il server è progettato per accettare come richieste dai client delle stringhe
721 che contengono il nome della fifo sulla quale deve essere inviata la risposta.
722 Per cui prima (\texttt{\small 35--39}) si esegue la lettura dalla stringa di
723 richiesta dalla fifo nota (che a questo punto si bloccherà tutte le volte che
724 non ci sono richieste). Dopo di che, una volta terminata la stringa
725 (\texttt{\small 40}) e selezionato (\texttt{\small 41}) un numero casuale per
726 ricavare la frase da inviare, si procederà (\texttt{\small 42--46})
727 all'apertura della fifo per la risposta, che poi \texttt{\small 47--48}) vi
728 sarà scritta. Infine (\texttt{\small 49}) si chiude la fifo di risposta che
729 non serve più.
730
731 Il codice del client è invece riportato in \figref{fig:ipc_fifo_client}, anche
732 in questo caso si è omessa la gestione delle opzioni e la funzione che stampa
733 a video le informazioni di utilizzo ed esce, riportando solo la sezione
734 principale del programma e le definizioni delle variabili. Il codice completo
735 è nel file \file{FortuneClient.c} dei sorgenti allegati.
736
737 \begin{figure}[!htb]
738   \footnotesize \centering
739   \begin{minipage}[c]{15cm}
740     \begin{lstlisting}{}
741 int main(int argc, char *argv[])
742 {
743 /* Variables definition */
744     int n = 0;
745     char *fortunefilename = "/tmp/fortune.fifo";
746     char line[80];
747     int fifo_server, fifo_client;
748     char fifoname[80];
749     int nread;
750     char buffer[PIPE_BUF];
751     ...
752     snprintf(fifoname, 80, "/tmp/fortune.%d", getpid());     /* compose name */
753     if (mkfifo(fifoname, 0622)) {                        /* open client fifo */
754         if (errno!=EEXIST) {
755             perror("Cannot create well known fifo");
756             exit(-1);
757         }
758     }
759     fifo_server = open(fortunefilename, O_WRONLY);       /* open server fifo */
760     if (fifo_server < 0) {
761         perror("Cannot open well known fifo");
762         exit(-1);
763     }
764     nread = write(fifo_server, fifoname, strlen(fifoname)+1);  /* write name */
765     close(fifo_server);                                 /* close server fifo */
766     fifo_client = open(fifoname, O_RDONLY);              /* open client fifo */
767     if (fifo_client < 0) {
768         perror("Cannot open well known fifo");
769         exit(-1);
770     }
771     nread = read(fifo_client, buffer, sizeof(buffer));        /* read answer */
772     printf("%s", buffer);                                   /* print fortune */
773     close(fifo_client);                                      /* close client */
774     close(fifo_server);                                      /* close server */
775     unlink(fifoname);                                  /* remove client fifo */
776 }
777     \end{lstlisting}
778   \end{minipage} 
779   \normalsize 
780   \caption{Sezione principale del codice del client di \textit{fortunes}
781     basato sulle fifo.}
782   \label{fig:ipc_fifo_client}
783 \end{figure}
784
785 La prima istruzione (\texttt{\small 12}) compone il nome della fifo che dovrà
786 essere utilizzata per ricevere la risposta dal server.  Si usa il \acr{pid}
787 del processo per essere sicuri di avere un nome univoco; dopo di che
788 (\texttt{\small 13-18}) si procede alla creazione del relativo file, uscendo
789 in caso di errore (a meno che il file non sia già presente sul filesystem).
790
791 A questo punto il client può effettuare l'interrogazione del server, per
792 questo prima si apre la fifo nota (\texttt{\small 19--23}), e poi ci si scrive
793 (\texttt{\small 24}) la stringa composta in precedenza, che contiene il nome
794 della fifo da utilizzare per la risposta. Infine si richiude la fifo del
795 server che a questo punto non serve più (\texttt{\small 25}).
796
797 Inoltrata la richiesta si può passare alla lettura della risposta; anzitutto
798 si apre (\texttt{\small 26--30}) la fifo appena creata, da cui si deve
799 riceverla, dopo di che si effettua una lettura (\texttt{\small 31})
800 nell'apposito buffer; si è supposto, come è ragionevole, che le frasi inviate
801 dal server siano sempre di dimensioni inferiori a \const{PIPE\_BUF},
802 tralasciamo la gestione del caso in cui questo non è vero. Infine si stampa
803 (\texttt{\small 32}) a video la risposta, si chiude (\texttt{\small 33}) la
804 fifo e si cancella (\texttt{\small 34}) il relativo file.
805 Si noti come la fifo per la risposta sia stata aperta solo dopo aver inviato
806 la richiesta, se non si fosse fatto così si avrebbe avuto uno stallo, in
807 quanto senza la richiesta, il server non avrebbe potuto aprirne il capo in
808 scrittura e l'apertura si sarebbe bloccata indefinitamente.
809
810 Verifichiamo allora il comportamento dei nostri programmi, in questo, come in
811 altri esempi precedenti, si fa uso delle varie funzioni di servizio, che sono
812 state raccolte nella libreria \file{libgapil.so}, per poter usare quest'ultima
813 occorrerà definire la speciale variabile di ambiente \code{LD\_LIBRARY\_PATH}
814 in modo che il linker dinamico possa accedervi.
815
816 In generale questa variabile indica il pathname della directory contenente la
817 libreria. Nell'ipotesi (che daremo sempre per verificata) che si facciano le
818 prove direttamente nella directory dei sorgenti (dove di norma vengono creati
819 sia i programmi che la libreria), il comando da dare sarà \code{export
820   LD\_LIBRARY\_PATH=./}; a questo punto potremo lanciare il server, facendogli
821 leggere una decina di frasi, con:
822 \begin{verbatim}
823 [piccardi@gont sources]$ ./fortuned -n10
824 \end{verbatim}
825
826 Avendo usato \func{daemon} per eseguire il server in background il comando
827 ritornerà immediatamente, ma potremo verificare con \cmd{ps} che in effetti il
828 programma resta un esecuzione in background, e senza avere associato un
829 terminale di controllo (si ricordi quanto detto in \secref{sec:sess_daemon}):
830 \begin{verbatim}
831 [piccardi@gont sources]$ ps aux
832 ...
833 piccardi 27489  0.0  0.0  1204  356 ?        S    01:06   0:00 ./fortuned -n10
834 piccardi 27492  3.0  0.1  2492  764 pts/2    R    01:08   0:00 ps aux
835 \end{verbatim}%$
836 e si potrà verificare anche che in \file{/tmp} è stata creata la fifo di
837 ascolto \file{fortune.fifo}. A questo punto potremo interrogare il server con
838 il programma client; otterremo così:
839 \begin{verbatim}
840 [piccardi@gont sources]$ ./fortune
841 Linux ext2fs has been stable for a long time, now it's time to break it
842         -- Linuxkongreß '95 in Berlin
843 [piccardi@gont sources]$ ./fortune
844 Let's call it an accidental feature.
845         --Larry Wall
846 [piccardi@gont sources]$ ./fortune
847 .........    Escape the 'Gates' of Hell
848   `:::'                  .......  ......
849    :::  *                  `::.    ::'
850    ::: .::  .:.::.  .:: .::  `::. :'
851    :::  ::   ::  ::  ::  ::    :::.
852    ::: .::. .::  ::.  `::::. .:'  ::.
853 ...:::.....................::'   .::::..
854         -- William E. Roadcap
855 [piccardi@gont sources]$ ./fortune
856 Linux ext2fs has been stable for a long time, now it's time to break it
857         -- Linuxkongreß '95 in Berlin
858 \end{verbatim}%$
859 e ripetendo varie volte il comando otterremo, in ordine casuale, le dieci
860 frasi tenute in memoria dal server.
861
862 Infine per chiudere il server basterà inviare un segnale di terminazione con
863 \code{killall fortuned} e potremo verificare che il gestore del segnale ha
864 anche correttamente cancellato la fifo di ascolto da \file{/tmp}.
865
866 Benché il nostro sistema client-server funzioni, la sua struttura è piuttosto
867 complessa e continua ad avere vari inconvenienti\footnote{lo stesso Stevens,
868   che esamina questa architettura in \cite{APUE}, nota come sia impossibile
869   per il server sapere se un client è andato in crash, con la possibilità di
870   far restare le fifo temporanee sul filesystem, di come sia necessario
871   intercettare \const{SIGPIPE} dato che un client può terminare dopo aver
872   fatto una richiesta, ma prima che la risposta sia inviata (cosa che nel
873   nostro esempio non è stata fatta).}; in generale infatti l'interfaccia delle
874 fifo non è adatta a risolvere questo tipo di problemi, che possono essere
875 affrontati in maniera più semplice ed efficace o usando i
876 \textit{socket}\index{socket} (che tratteremo in dettaglio a partire da
877 \capref{cha:socket_intro}) o ricorrendo a meccanismi di comunicazione diversi,
878 come quelli che esamineremo in seguito.
879
880
881
882 \subsection{La funzione \func{socketpair}}
883 \label{sec:ipc_socketpair}
884
885 Un meccanismo di comunicazione molto simile alle pipe, ma che non presenta il
886 problema della unidirezionalità del flusso dei dati, è quello dei cosiddetti
887 \textsl{socket locali} (o \textit{Unix domain socket}). Tratteremo l'argomento
888 dei \textit{socket}\index{socket} in \capref{cha:socket_intro},\footnote{si
889   tratta comunque di oggetti di comunicazione che, come le pipe, sono
890   utilizzati attraverso dei file descriptor.} nell'ambito dell'interfaccia
891 generale che essi forniscono per la programmazione di rete; e vedremo anche
892 (in~\secref{sec:sock_sa_local}) come si possono definire dei file speciali (di
893 tipo \textit{socket}, analoghi a quello associati alle fifo) cui si accede
894 però attraverso quella medesima interfaccia; vale però la pena esaminare qui
895 una modalità di uso dei socket locali\footnote{la funzione \func{socketpair} è
896   stata introdotta in BSD4.4, ma è supportata in genere da qualunque sistema
897   che fornisca l'interfaccia dei socket.} che li rende sostanzialmente
898 identici ad una pipe bidirezionale.
899
900 La funzione \funcd{socketpair} infatti consente di creare una coppia di file
901 descriptor connessi fra di loro (tramite un socket\index{socket}, appunto),
902 senza dover ricorrere ad un file speciale sul filesystem, i descrittori sono
903 del tutto analoghi a quelli che si avrebbero con una chiamata a \func{pipe},
904 con la sola differenza è che in questo caso il flusso dei dati può essere
905 effettuato in entrambe le direzioni. Il prototipo della funzione è:
906 \begin{functions}
907   \headdecl{sys/types.h} 
908   \headdecl{sys/socket.h} 
909   
910   \funcdecl{int socketpair(int domain, int type, int protocol, int sv[2])}
911   
912   Crea una coppia di socket\index{socket} connessi fra loro.
913   
914   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
915     errore, nel qual caso \var{errno} assumerà uno dei valori:
916   \begin{errlist}
917   \item[\errcode{EAFNOSUPPORT}] I socket\index{socket} locali non sono
918     supportati.
919   \item[\errcode{EPROTONOSUPPORT}] Il protocollo specificato non è supportato.
920   \item[\errcode{EOPNOTSUPP}] Il protocollo specificato non supporta la
921   creazione di coppie di socket\index{socket}.
922   \end{errlist}
923   ed inoltre \errval{EMFILE},  \errval{EFAULT}.
924 }
925 \end{functions}
926
927 La funzione restituisce in \param{sv} la coppia di descrittori connessi fra di
928 loro: quello che si scrive su uno di essi sarà ripresentato in input
929 sull'altro e viceversa. I parametri \param{domain}, \param{type} e
930 \param{protocol} derivano dall'interfaccia dei socket\index{socket} (che è
931 quella che fornisce il substrato per connettere i due descrittori), ma in
932 questo caso i soli valori validi che possono essere specificati sono
933 rispettivamente \const{AF\_UNIX}, \const{SOCK\_STREAM} e \val{0}.
934
935 L'utilità di chiamare questa funzione per evitare due chiamate a \func{pipe}
936 può sembrare limitata; in realtà l'utilizzo di questa funzione (e dei
937 socket\index{socket} locali in generale) permette di trasmettere attraverso le
938 linea non solo dei dati, ma anche dei file descriptor: si può cioè passare da
939 un processo ad un altro un file descriptor, con una sorta di duplicazione
940 dello stesso non all'interno di uno stesso processo, ma fra processi distinti
941 (torneremo su questa funzionalità in \secref{sec:xxx_fd_passing}).
942
943
944 \section{La comunicazione fra processi di System V}
945 \label{sec:ipc_sysv}
946
947 Benché le pipe e le fifo siano ancora ampiamente usate, esse scontano il
948 limite fondamentale che il meccanismo di comunicazione che forniscono è
949 rigidamente sequenziale: una situazione in cui un processo scrive qualcosa che
950 molti altri devono poter leggere non può essere implementata con una pipe.
951
952 Per questo nello sviluppo di System V vennero introdotti una serie di nuovi
953 oggetti per la comunicazione fra processi ed una nuova interfaccia di
954 programmazione, che fossero in grado di garantire una maggiore flessibilità.
955 In questa sezione esamineremo come Linux supporta quello che viene chiamato il
956 \textsl{Sistema di comunicazione inter-processo} di System V, cui da qui in
957 avanti faremo riferimento come \textit{SysV IPC} (dove IPC è la sigla di
958 \textit{Inter-Process Comunication}).
959
960
961
962 \subsection{Considerazioni generali}
963 \label{sec:ipc_sysv_generic}
964
965 La principale caratteristica del \textit{SysV IPC} è quella di essere basato
966 su oggetti permanenti che risiedono nel kernel. Questi, a differenza di quanto
967 avviene per i file descriptor, non mantengono un contatore dei riferimenti, e
968 non vengono cancellati dal sistema una volta che non sono più in uso.
969
970 Questo comporta due problemi: il primo è che, al contrario di quanto avviene
971 per pipe e fifo, la memoria allocata per questi oggetti non viene rilasciata
972 automaticamente quando non c'è più nessuno che li utilizzi, ed essi devono
973 essere cancellati esplicitamente, se non si vuole che restino attivi fino al
974 riavvio del sistema. Il secondo problema è che, dato che non c'è, come per i
975 file, un contatore del numero di riferimenti che ne indichi l'essere in uso,
976 essi possono essere cancellati anche se ci sono dei processi che li stanno
977 utilizzando, con tutte le conseguenze (negative) del caso.
978
979 Un'ulteriore caratteristica negativa è che gli oggetti usati nel \textit{SysV
980   IPC} vengono creati direttamente dal kernel, e sono accessibili solo
981 specificando il relativo \textsl{identificatore}. Questo è un numero
982 progressivo (un po' come il \acr{pid} dei processi) che il kernel assegna a
983 ciascuno di essi quanto vengono creati (sul procedimento di assegnazione
984 torneremo in \secref{sec:ipc_sysv_id_use}). L'identificatore viene restituito
985 dalle funzioni che creano l'oggetto, ed è quindi locale al processo che le ha
986 eseguite. Dato che l'identificatore viene assegnato dinamicamente dal kernel
987 non è possibile prevedere quale sarà, né utilizzare un qualche valore statico,
988 si pone perciò il problema di come processi diversi possono accedere allo
989 stesso oggetto.
990
991 Per risolvere il problema nella struttura \struct{ipc\_perm} che il kernel
992 associa a ciascun oggetto, viene mantenuto anche un campo apposito che
993 contiene anche una \textsl{chiave}, identificata da una variabile del tipo
994 primitivo \type{key\_t}, da specificare in fase di creazione dell'oggetto, e
995 tramite la quale è possibile ricavare l'identificatore.\footnote{in sostanza
996   si sposta il problema dell'accesso dalla classificazione in base
997   all'identificatore alla classificazione in base alla chiave, una delle tante
998   complicazioni inutili presenti nel \textit{SysV IPC}.} Oltre la chiave, la
999 struttura, la cui definizione è riportata in \figref{fig:ipc_ipc_perm},
1000 mantiene varie proprietà ed informazioni associate all'oggetto.
1001
1002 \begin{figure}[!htb]
1003   \footnotesize \centering
1004   \begin{minipage}[c]{15cm}
1005     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm ]{}
1006 struct ipc_perm
1007 {
1008     key_t key;                        /* Key.  */
1009     uid_t uid;                        /* Owner's user ID.  */
1010     gid_t gid;                        /* Owner's group ID.  */
1011     uid_t cuid;                       /* Creator's user ID.  */
1012     gid_t cgid;                       /* Creator's group ID.  */
1013     unsigned short int mode;          /* Read/write permission.  */
1014     unsigned short int seq;           /* Sequence number.  */
1015 };
1016     \end{lstlisting}
1017   \end{minipage} 
1018   \normalsize 
1019   \caption{La struttura \structd{ipc\_perm}, come definita in
1020     \file{sys/ipc.h}.}
1021   \label{fig:ipc_ipc_perm}
1022 \end{figure}
1023
1024 Usando la stessa chiave due processi diversi possono ricavare l'identificatore
1025 associato ad un oggetto ed accedervi. Il problema che sorge a questo punto è
1026 come devono fare per accordarsi sull'uso di una stessa chiave. Se i processi
1027 sono \textsl{parenti} la soluzione è relativamente semplice, in tal caso
1028 infatti si può usare il valore speciale \texttt{IPC\_PRIVATE} per creare un
1029 nuovo oggetto nel processo padre, l'identificatore così ottenuto sarà
1030 disponibile in tutti i figli, e potrà essere passato come parametro attraverso
1031 una \func{exec}.
1032
1033 Però quando i processi non sono \textsl{parenti} (come capita tutte le volte
1034 che si ha a che fare con un sistema client-server) tutto questo non è
1035 possibile; si potrebbe comunque salvare l'identificatore su un file noto, ma
1036 questo ovviamente comporta lo svantaggio di doverselo andare a rileggere.  Una
1037 alternativa più efficace è quella che i programmi usino un valore comune per
1038 la chiave (che ad esempio può essere dichiarato in un header comune), ma c'è
1039 sempre il rischio che questa chiave possa essere stata già utilizzata da
1040 qualcun altro.  Dato che non esiste una convenzione su come assegnare queste
1041 chiavi in maniera univoca l'interfaccia mette a disposizione una funzione
1042 apposita, \funcd{ftok}, che permette di ottenere una chiave specificando il
1043 nome di un file ed un numero di versione; il suo prototipo è:
1044 \begin{functions}
1045   \headdecl{sys/types.h} 
1046   \headdecl{sys/ipc.h} 
1047   
1048   \funcdecl{key\_t ftok(const char *pathname, int proj\_id)}
1049   
1050   Restituisce una chiave per identificare un oggetto del \textit{SysV IPC}.
1051   
1052   \bodydesc{La funzione restituisce la chiave in caso di successo e -1
1053     altrimenti, nel qual caso \var{errno} sarà uno dei possibili codici di
1054     errore di \func{stat}.}
1055 \end{functions}
1056
1057 La funzione determina un valore della chiave sulla base di \param{pathname},
1058 che deve specificare il pathname di un file effettivamente esistente e di un
1059 numero di progetto \param{proj\_id)}, che di norma viene specificato come
1060 carattere, dato che ne vengono utilizzati solo gli 8 bit meno
1061 significativi.\footnote{nelle libc4 e libc5, come avviene in SunOS,
1062   l'argomento \param{proj\_id} è dichiarato tipo \ctyp{char}, le \acr{glibc}
1063   usano il prototipo specificato da XPG4, ma vengono lo stesso utilizzati gli
1064   8 bit meno significativi.}
1065
1066 Il problema è che anche così non c'è la sicurezza che il valore della chiave
1067 sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
1068 con i 16 bit meno significativi dell'inode\index{inode} del file
1069 \param{pathname} (che vengono ottenuti attraverso \func{stat}, da cui derivano
1070 i possibili errori), e gli 8 bit meno significativi del numero del dispositivo
1071 su cui è il file.  Diventa perciò relativamente facile ottenere delle
1072 collisioni, specie se i file sono su dispositivi con lo stesso \textit{minor
1073   number}, come \file{/dev/hda1} e \file{/dev/sda1}.
1074
1075 In genere quello che si fa è utilizzare un file comune usato dai programmi che
1076 devono comunicare (ad esempio un header comune, o uno dei programmi che devono
1077 usare l'oggetto in questione), utilizzando il numero di progetto per ottenere
1078 le chiavi che interessano. In ogni caso occorre sempre controllare, prima di
1079 creare un oggetto, che la chiave non sia già stata utilizzata. Se questo va
1080 bene in fase di creazione, le cose possono complicarsi per i programmi che
1081 devono solo accedere, in quanto, a parte gli eventuali controlli sugli altri
1082 attributi di \struct{ipc\_perm}, non esiste una modalità semplice per essere
1083 sicuri che l'oggetto associato ad una certa chiave sia stato effettivamente
1084 creato da chi ci si aspetta.
1085
1086 Questo è, insieme al fatto che gli oggetti sono permanenti e non mantengono un
1087 contatore di riferimenti per la cancellazione automatica, il principale
1088 problema del \textit{SysV IPC}. Non esiste infatti una modalità chiara per
1089 identificare un oggetto, come sarebbe stato se lo si fosse associato ad in
1090 file, e tutta l'interfaccia è inutilmente complessa.  Per questo ne è stata
1091 effettuata una revisione completa nello standard POSIX.1b, che tratteremo in
1092 \secref{sec:ipc_posix}.
1093
1094
1095 \subsection{Il controllo di accesso}
1096 \label{sec:ipc_sysv_access_control}
1097
1098 Oltre alle chiavi, abbiamo visto che ad ogni oggetto sono associate in
1099 \struct{ipc\_perm} ulteriori informazioni, come gli identificatori del creatore
1100 (nei campi \var{cuid} e \var{cgid}) e del proprietario (nei campi \var{uid} e
1101 \var{gid}) dello stesso, e un insieme di permessi (nel campo \var{mode}). In
1102 questo modo è possibile definire un controllo di accesso sugli oggetti di IPC,
1103 simile a quello che si ha per i file (vedi \secref{sec:file_perm_overview}).
1104
1105 Benché questo controllo di accesso sia molto simile a quello dei file, restano
1106 delle importanti differenze. La prima è che il permesso di esecuzione non
1107 esiste (e se specificato viene ignorato), per cui si può parlare solo di
1108 permessi di lettura e scrittura (nel caso dei semafori poi quest'ultimo è più
1109 propriamente un permesso di modifica). I valori di \var{mode} sono gli stessi
1110 ed hanno lo stesso significato di quelli riportati in
1111 \secref{tab:file_mode_flags}\footnote{se però si vogliono usare le costanti
1112   simboliche ivi definite occorrerà includere il file \file{sys/stat.h},
1113   alcuni sistemi definiscono le costanti \const{MSG\_R} (\texttt{0400}) e
1114   \const{MSG\_W} (\texttt{0200}) per indicare i permessi base di lettura e
1115   scrittura per il proprietario, da utilizzare, con gli opportuni shift, pure
1116   per il gruppo e gli altri, in Linux, visto la loro scarsa utilità, queste
1117   costanti non sono definite.} e come per i file definiscono gli accessi per
1118 il proprietario, il suo gruppo e tutti gli altri.
1119
1120 Quando l'oggetto viene creato i campi \var{cuid} e \var{uid} di
1121 \struct{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono settati
1122 rispettivamente al valore dell'user-ID e del group-ID effettivo del processo che
1123 ha chiamato la funzione, ma, mentre i campi \var{uid} e \var{gid} possono
1124 essere cambiati, i campi \var{cuid} e \var{cgid} restano sempre gli stessi.
1125
1126 Il controllo di accesso è effettuato a due livelli. Il primo livello è nelle
1127 funzioni che richiedono l'identificatore di un oggetto data la chiave. Queste
1128 specificano tutte un argomento \param{flag}, in tal caso quando viene
1129 effettuata la ricerca di una chiave, qualora \param{flag} specifichi dei
1130 permessi, questi vengono controllati e l'identificatore viene restituito solo
1131 se corrispondono a quelli dell'oggetto. Se ci sono dei permessi non presenti
1132 in \var{mode} l'accesso sarà negato. Questo controllo però è di utilità
1133 indicativa, dato che è sempre possibile specificare per \param{flag} un valore
1134 nullo, nel qual caso l'identificatore sarà restituito comunque.
1135
1136 Il secondo livello di controllo è quello delle varie funzioni che accedono
1137 direttamente (in lettura o scrittura) all'oggetto. In tal caso lo schema dei
1138 controlli è simile a quello dei file, ed avviene secondo questa sequenza:
1139 \begin{itemize}
1140 \item se il processo ha i privilegi di amministratore l'accesso è sempre
1141   consentito. 
1142 \item se l'user-ID effettivo del processo corrisponde o al valore del campo
1143   \var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario
1144   in \var{mode} è appropriato\footnote{per appropriato si intende che è
1145     settato il permesso di scrittura per le operazioni di scrittura e quello
1146     di lettura per le operazioni di lettura.} l'accesso è consentito.
1147 \item se il group-ID effettivo del processo corrisponde o al
1148   valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso
1149   per il gruppo in \var{mode} è appropriato l'accesso è consentito.
1150 \item se il permesso per gli altri è appropriato l'accesso è consentito.
1151 \end{itemize}
1152 solo se tutti i controlli elencati falliscono l'accesso è negato. Si noti che
1153 a differenza di quanto avviene per i permessi dei file, fallire in uno dei
1154 passi elencati non comporta il fallimento dell'accesso. Un'ulteriore
1155 differenza rispetto a quanto avviene per i file è che per gli oggetti di IPC
1156 il valore di \var{umask} (si ricordi quanto esposto in
1157 \secref{sec:file_umask}) non ha alcun significato.
1158
1159
1160 \subsection{Gli identificatori ed il loro utilizzo}
1161 \label{sec:ipc_sysv_id_use}
1162
1163 L'unico campo di \struct{ipc\_perm} del quale non abbiamo ancora parlato è
1164 \var{seq}, che in \figref{fig:ipc_ipc_perm} è qualificato con un criptico
1165 ``\textsl{numero di sequenza}'', ne parliamo adesso dato che esso è
1166 strettamente attinente alle modalità con cui il kernel assegna gli
1167 identificatori degli oggetti del sistema di IPC.
1168
1169 Quando il sistema si avvia, alla creazione di ogni nuovo oggetto di IPC viene
1170 assegnato un numero progressivo, pari al numero di oggetti di quel tipo
1171 esistenti. Se il comportamento fosse sempre questo sarebbe identico a quello
1172 usato nell'assegnazione dei file descriptor nei processi, ed i valori degli
1173 identificatori tenderebbero ad essere riutilizzati spesso e restare di piccole
1174 dimensioni (inferiori al numero massimo di oggetti disponibili).
1175
1176 Questo va benissimo nel caso dei file descriptor, che sono locali ad un
1177 processo, ma qui il comportamento varrebbe per tutto il sistema, e per
1178 processi del tutto scorrelati fra loro. Così si potrebbero avere situazioni
1179 come quella in cui un server esce e cancella le sue code di messaggi, ed il
1180 relativo identificatore viene immediatamente assegnato a quelle di un altro
1181 server partito subito dopo, con la possibilità che i client del primo non
1182 facciano in tempo ad accorgersi dell'avvenuto, e finiscano con l'interagire
1183 con gli oggetti del secondo, con conseguenze imprevedibili.
1184
1185 Proprio per evitare questo tipo di situazioni il sistema usa il valore di
1186 \var{seq} per provvedere un meccanismo che porti gli identificatori ad
1187 assumere tutti i valori possibili, rendendo molto più lungo il periodo in cui
1188 un identificatore può venire riutilizzato.
1189
1190 Il sistema dispone sempre di un numero fisso di oggetti di IPC,\footnote{fino
1191   al kernel 2.2.x questi valori, definiti dalle costanti \const{MSGMNI},
1192   \const{SEMMNI} e \const{SHMMNI}, potevano essere cambiati (come tutti gli
1193   altri limiti relativi al \textit{SysV IPC}) solo con una ricompilazione del
1194   kernel, andando a modificarne la definizione nei relativi header file.  A
1195   partire dal kernel 2.4.x è possibile cambiare questi valori a sistema attivo
1196   scrivendo sui file \file{shmmni}, \file{msgmni} e \file{sem} di
1197   \file{/proc/sys/kernel} o con l'uso di \func{sysctl}.} e per ciascuno di
1198 essi viene mantenuto in \var{seq} un numero di sequenza progressivo che viene
1199 incrementato di uno ogni volta che l'oggetto viene cancellato. Quando
1200 l'oggetto viene creato usando uno spazio che era già stato utilizzato in
1201 precedenza per restituire l'identificatore al numero di oggetti presenti viene
1202 sommato il valore di \var{seq} moltiplicato per il numero massimo di oggetti
1203 di quel tipo,\footnote{questo vale fino ai kernel della serie 2.2.x, dalla
1204   serie 2.4.x viene usato lo stesso fattore per tutti gli oggetti, esso è dato
1205   dalla costante \const{IPCMNI}, definita in \file{include/linux/ipc.h}, che
1206   indica il limite massimo per il numero di tutti oggetti di IPC, ed il cui
1207   valore è 32768.}  si evita così il riutilizzo degli stessi numeri, e si fa
1208 sì che l'identificatore assuma tutti i valori possibili.
1209
1210 \begin{figure}[!htb]
1211   \footnotesize \centering
1212   \begin{minipage}[c]{15cm}
1213     \begin{lstlisting}{}
1214 int main(int argc, char *argv[])
1215 {
1216     ...
1217     switch (type) {
1218     case 'q':   /* Message Queue */
1219         debug("Message Queue Try\n");
1220         for (i=0; i<n; i++) {
1221             id = msgget(IPC_PRIVATE, IPC_CREAT|0666);
1222             printf("Identifier Value %d \n", id);
1223             msgctl(id, IPC_RMID, NULL);
1224         }
1225         break;
1226     case 's':   /* Semaphore */
1227         debug("Semaphore\n");
1228         for (i=0; i<n; i++) {
1229             id = semget(IPC_PRIVATE, 1, IPC_CREAT|0666);
1230             printf("Identifier Value %d \n", id);
1231             semctl(id, 0, IPC_RMID);
1232         }
1233         break;
1234     case 'm':   /* Shared Memory */
1235         debug("Shared Memory\n");
1236         for (i=0; i<n; i++) {
1237             id = shmget(IPC_PRIVATE, 1000, IPC_CREAT|0666);
1238             printf("Identifier Value %d \n", id);
1239             shmctl(id, IPC_RMID, NULL);
1240         }
1241         break;
1242     default:    /* should not reached */
1243         return -1;
1244     }
1245     return 0;
1246 }
1247     \end{lstlisting}
1248   \end{minipage} 
1249   \normalsize 
1250   \caption{Sezione principale del programma di test per l'assegnazione degli
1251     identificatori degli oggetti di IPC \file{IPCTestId.c}.}
1252   \label{fig:ipc_sysv_idtest}
1253 \end{figure}
1254
1255 In \figref{fig:ipc_sysv_idtest} è riportato il codice di un semplice programma
1256 di test che si limita a creare un oggetto (specificato a riga di comando),
1257 stamparne il numero di identificatore e cancellarlo per un numero specificato
1258 di volte. Al solito non si è riportato il codice della gestione delle opzioni
1259 a riga di comando, che permette di specificare quante volte effettuare il
1260 ciclo \var{n}, e su quale tipo di oggetto eseguirlo.
1261
1262 La figura non riporta il codice di selezione delle opzioni, che permette di
1263 inizializzare i valori delle variabili \var{type} al tipo di oggetto voluto, e
1264 \var{n} al numero di volte che si vuole effettuare il ciclo di creazione,
1265 stampa, cancellazione. I valori di default sono per l'uso delle code di
1266 messaggi e un ciclo di 5 volte. Se si lancia il comando si otterrà qualcosa
1267 del tipo:
1268 \begin{verbatim}
1269 piccardi@gont sources]$ ./ipctestid
1270 Identifier Value 0 
1271 Identifier Value 32768 
1272 Identifier Value 65536 
1273 Identifier Value 98304 
1274 Identifier Value 131072 
1275 \end{verbatim}%$
1276 il che ci mostra che abbiamo un kernel della serie 2.4.x nel quale non avevamo
1277 ancora usato nessuna coda di messaggi. Se ripetiamo il comando otterremo
1278 ancora:
1279 \begin{verbatim}
1280 [piccardi@gont sources]$ ./ipctestid
1281 Identifier Value 163840 
1282 Identifier Value 196608 
1283 Identifier Value 229376 
1284 Identifier Value 262144 
1285 Identifier Value 294912 
1286 \end{verbatim}%$
1287 che ci mostra come il valore di \var{seq} sia in effetti una quantità
1288 mantenuta staticamente all'interno del sistema.
1289
1290
1291 \subsection{Code di messaggi}
1292 \label{sec:ipc_sysv_mq}
1293
1294 Il primo oggetto introdotto dal \textit{SysV IPC} è quello delle code di
1295 messaggi.  Le code di messaggi sono oggetti analoghi alle pipe o alle fifo,
1296 anche se la loro struttura è diversa, ed il loro scopo principale è appunto
1297 quello di permettere a processi diversi di scambiarsi dei dati.
1298
1299 La funzione che permette di richiedere al sistema l'identificatore di una coda
1300 di messaggi esistente (o di crearne una se questa non esiste) è
1301 \funcd{msgget}; il suo prototipo è:
1302 \begin{functions}
1303   \headdecl{sys/types.h} 
1304   \headdecl{sys/ipc.h} 
1305   \headdecl{sys/msg.h} 
1306   
1307   \funcdecl{int msgget(key\_t key, int flag)}
1308   
1309   Restituisce l'identificatore di una coda di messaggi.
1310   
1311   \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
1312     in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
1313   \begin{errlist}
1314   \item[\errcode{EACCES}] Il processo chiamante non ha i privilegi per accedere
1315   alla coda richiesta.  
1316   \item[\errcode{EEXIST}] Si è richiesta la creazione di una coda che già
1317   esiste, ma erano specificati sia \const{IPC\_CREAT} che \const{IPC\_EXCL}. 
1318   \item[\errcode{EIDRM}] La coda richiesta è marcata per essere cancellata.
1319   \item[\errcode{ENOENT}] Si è cercato di ottenere l'identificatore di una coda
1320     di messaggi specificando una chiave che non esiste e \const{IPC\_CREAT}
1321     non era specificato.
1322   \item[\errcode{ENOSPC}] Si è cercato di creare una coda di messaggi quando è
1323     stato superato il limite massimo di code (\const{MSGMNI}).
1324   \end{errlist}
1325   ed inoltre \errval{ENOMEM}.
1326 }
1327 \end{functions}
1328
1329 Le funzione (come le analoghe che si usano per gli altri oggetti) serve sia a
1330 ottenere l'identificatore di una coda di messaggi esistente, che a crearne una
1331 nuova. L'argomento \param{key} specifica la chiave che è associata
1332 all'oggetto, eccetto il caso in cui si specifichi il valore
1333 \const{IPC\_PRIVATE}, nel qual caso la coda è creata ex-novo e non vi è
1334 associata alcuna chiave, il processo (ed i suoi eventuali figli) potranno
1335 farvi riferimento solo attraverso l'identificatore.
1336
1337 Se invece si specifica un valore diverso da \const{IPC\_PRIVATE}\footnote{in
1338   Linux questo significa un valore diverso da zero.} l'effetto della funzione
1339 dipende dal valore di \param{flag}, se questo è nullo la funzione si limita ad
1340 effettuare una ricerca sugli oggetti esistenti, restituendo l'identificatore
1341 se trova una corrispondenza, o fallendo con un errore di \errcode{ENOENT} se
1342 non esiste o di \errcode{EACCES} se si sono specificati dei permessi non
1343 validi.
1344
1345 Se invece si vuole creare una nuova coda di messaggi \param{flag} non può
1346 essere nullo e deve essere fornito come maschera binaria, impostando il bit
1347 corrispondente al valore \const{IPC\_CREAT}. In questo caso i nove bit meno
1348 significativi di \param{flag} saranno usati come permessi per il nuovo
1349 oggetto, secondo quanto illustrato in \secref{sec:ipc_sysv_access_control}.
1350 Se si imposta anche il bit corrispondente a \const{IPC\_EXCL} la funzione avrà
1351 successo solo se l'oggetto non esiste già, fallendo con un errore di
1352 \errcode{EEXIST} altrimenti.
1353
1354 Si tenga conto che l'uso di \const{IPC\_PRIVATE} non impedisce ad altri
1355 processi di accedere alla coda (se hanno privilegi sufficienti) una volta che
1356 questi possano indovinare o ricavare (ad esempio per tentativi)
1357 l'identificatore ad essa associato. Per come sono implementati gli oggetti di
1358 IPC infatti non esiste una maniera che  garantisca l'accesso esclusivo ad una
1359 coda di messaggi.  Usare \const{IPC\_PRIVATE} o const{IPC\_CREAT} e
1360 \const{IPC\_EXCL} per \param{flag} comporta solo la creazione di una nuova
1361 coda.
1362
1363 \begin{table}[htb]
1364   \footnotesize
1365   \centering
1366   \begin{tabular}[c]{|c|r|l|l|}
1367     \hline
1368     \textbf{Costante} & \textbf{Valore} & \textbf{File in \texttt{proc}}
1369     & \textbf{Significato} \\
1370     \hline
1371     \hline
1372     \const{MSGMNI}&   16& \file{msgmni} & Numero massimo di code di
1373                                           messaggi. \\
1374     \const{MSGMAX}& 8192& \file{msgmax} & Dimensione massima di un singolo
1375                                           messaggio.\\
1376     \const{MSGMNB}&16384& \file{msgmnb} & Dimensione massima del contenuto di 
1377                                           una coda.\\
1378     \hline
1379   \end{tabular}
1380   \caption{Valori delle costanti associate ai limiti delle code di messaggi.}
1381   \label{tab:ipc_msg_limits}
1382 \end{table}
1383
1384 Le code di messaggi sono caratterizzate da tre limiti fondamentali, definiti
1385 negli header e corrispondenti alle prime tre costanti riportate in
1386 \tabref{tab:ipc_msg_limits}, come accennato però in Linux è possibile
1387 modificare questi limiti attraverso l'uso di \func{sysctl} o scrivendo nei
1388 file \file{msgmax}, \file{msgmnb} e \file{msgmni} di \file{/proc/sys/kernel/}.
1389
1390
1391 \begin{figure}[htb]
1392   \centering \includegraphics[width=15cm]{img/mqstruct}
1393   \caption{Schema della struttura di una coda messaggi.}
1394   \label{fig:ipc_mq_schema}
1395 \end{figure}
1396
1397
1398 Una coda di messaggi è costituita da una \textit{linked list};\footnote{una
1399   \textit{linked list} è una tipica struttura di dati, organizzati in una
1400   lista in cui ciascun elemento contiene un puntatore al successivo. In questo
1401   modo la struttura è veloce nell'estrazione ed immissione dei dati dalle
1402   estremità dalla lista (basta aggiungere un elemento in testa o in coda ed
1403   aggiornare un puntatore), e relativamente veloce da attraversare in ordine
1404   sequenziale (seguendo i puntatori), è invece relativamente lenta
1405   nell'accesso casuale e nella ricerca.}  i nuovi messaggi vengono inseriti in
1406 coda alla lista e vengono letti dalla cima, in \figref{fig:ipc_mq_schema} si è
1407 riportato lo schema con cui queste strutture vengono mantenute dal
1408 kernel.\footnote{lo schema illustrato in \figref{fig:ipc_mq_schema} è in
1409   realtà una semplificazione di quello usato effettivamente fino ai kernel
1410   della serie 2.2.x, nei kernel della serie 2.4.x la gestione delle code di
1411   messaggi è stata modificata ed è effettuata in maniera diversa; abbiamo
1412   mantenuto lo schema precedente in quanto illustra comunque in maniera più
1413   che adeguata i principi di funzionamento delle code di messaggi.}
1414
1415 \begin{figure}[!htb]
1416   \footnotesize \centering
1417   \begin{minipage}[c]{15cm}
1418     \begin{lstlisting}[labelstep=0]{}
1419 struct msqid_ds {
1420     struct ipc_perm msg_perm;     /* structure for operation permission */
1421     time_t msg_stime;             /* time of last msgsnd command */
1422     time_t msg_rtime;             /* time of last msgrcv command */
1423     time_t msg_ctime;             /* time of last change */
1424     msgqnum_t msg_qnum;           /* number of messages currently on queue */
1425     msglen_t msg_qbytes;          /* max number of bytes allowed on queue */
1426     pid_t msg_lspid;              /* pid of last msgsnd() */
1427     pid_t msg_lrpid;              /* pid of last msgrcv() */
1428     struct msg *msg_first;        /* first message on queue, unused  */
1429     struct msg *msg_last;         /* last message in queue, unused */
1430     unsigned long int msg_cbytes; /* current number of bytes on queue */
1431 };
1432     \end{lstlisting}
1433   \end{minipage} 
1434   \normalsize 
1435   \caption{La struttura \structd{msqid\_ds}, associata a ciascuna coda di
1436     messaggi.}
1437   \label{fig:ipc_msqid_ds}
1438 \end{figure}
1439
1440 A ciascuna coda è associata una struttura \struct{msgid\_ds}, la cui
1441 definizione, è riportata in \secref{fig:ipc_msqid_ds}. In questa struttura il
1442 kernel mantiene le principali informazioni riguardo lo stato corrente della
1443 coda.\footnote{come accennato questo vale fino ai kernel della serie 2.2.x,
1444   essa viene usata nei kernel della serie 2.4.x solo per compatibilità in
1445   quanto è quella restituita dalle funzioni dell'interfaccia.  Si noti come ci
1446   sia una differenza con i campi mostrati nello schema di
1447   \figref{fig:ipc_mq_schema} che sono presi dalla definizione di
1448   \file{linux/msg.h}, e fanno riferimento alla definizione della omonima
1449   struttura usata nel kernel.} In \figref{fig:ipc_msqid_ds} sono elencati i
1450 campi significativi definiti in \file{sys/msg.h}, a cui si sono aggiunti gli
1451 ultimi tre campi che sono previsti dalla implementazione originale di System
1452 V, ma non dallo standard Unix98.
1453
1454 Quando si crea una nuova coda con \func{msgget} questa struttura viene
1455 inizializzata, in particolare il campo \var{msg\_perm} viene inizializzato
1456 come illustrato in \secref{sec:ipc_sysv_access_control}, per quanto riguarda
1457 gli altri campi invece:
1458 \begin{itemize}
1459 \item il campo \var{msg\_qnum}, che esprime il numero di messaggi presenti
1460   sulla coda, viene inizializzato a 0.
1461 \item i campi \var{msg\_lspid} e \var{msg\_lrpid}, che esprimono
1462   rispettivamente il \acr{pid} dell'ultimo processo che ha inviato o ricevuto
1463   un messaggio sulla coda, sono inizializzati a 0.
1464 \item i campi \var{msg\_stime} e \var{msg\_rtime}, che esprimono
1465   rispettivamente il tempo in cui è stato inviato o ricevuto l'ultimo
1466   messaggio sulla coda, sono inizializzati a 0.
1467 \item il campo \var{msg\_ctime}, che esprime il tempo di creazione della coda,
1468   viene inizializzato al tempo corrente.
1469 \item il campo \var{msg\_qbytes} che esprime la dimensione massima del
1470   contenuto della coda (in byte) viene inizializzato al valore preimpostato
1471   del sistema (\const{MSGMNB}).
1472 \item i campi \var{msg\_first} e \var{msg\_last} che esprimono l'indirizzo del
1473   primo e ultimo messaggio sono inizializzati a \val{NULL} e
1474   \var{msg\_cbytes}, che esprime la dimensione in byte dei messaggi presenti è
1475   inizializzato a zero. Questi campi sono ad uso interno dell'implementazione
1476   e non devono essere utilizzati da programmi in user space).
1477 \end{itemize}
1478
1479 Una volta creata una coda di messaggi le operazioni di controllo vengono
1480 effettuate con la funzione \funcd{msgctl}, che (come le analoghe \func{semctl}
1481 e \func{shmctl}) fa le veci di quello che \func{ioctl} è per i file; il suo
1482 prototipo è:
1483 \begin{functions}
1484   \headdecl{sys/types.h} 
1485   \headdecl{sys/ipc.h} 
1486   \headdecl{sys/msg.h} 
1487   
1488   \funcdecl{int msgctl(int msqid, int cmd, struct msqid\_ds *buf)}
1489   
1490   Esegue l'operazione specificata da \param{cmd} sulla coda \param{msqid}.
1491   
1492   \bodydesc{La funzione restituisce 0 in caso di successo o -1 in caso di
1493     errore, nel qual caso \var{errno} assumerà uno dei valori:
1494   \begin{errlist}
1495   \item[\errcode{EACCES}] Si è richiesto \const{IPC\_STAT} ma processo
1496     chiamante non ha i privilegi di lettura sulla coda.
1497   \item[\errcode{EIDRM}] La coda richiesta è stata cancellata.
1498   \item[\errcode{EPERM}] Si è richiesto \const{IPC\_SET} o \const{IPC\_RMID} ma
1499     il processo non ha i privilegi, o si è richiesto di aumentare il valore di
1500     \var{msg\_qbytes} oltre il limite \const{MSGMNB} senza essere
1501     amministratore.
1502   \end{errlist}
1503   ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
1504 }
1505 \end{functions}
1506
1507 La funzione permette di accedere ai valori della struttura \struct{msqid\_ds},
1508 mantenuta all'indirizzo \param{buf}, per la coda specificata
1509 dall'identificatore \param{msqid}. Il comportamento della funzione dipende dal
1510 valore dell'argomento \param{cmd}, che specifica il tipo di azione da
1511 eseguire; i valori possibili sono:
1512 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
1513 \item[\const{IPC\_STAT}] Legge le informazioni riguardo la coda nella
1514   struttura indicata da \param{buf}. Occorre avere il permesso di lettura
1515   sulla coda.
1516 \item[\const{IPC\_RMID}] Rimuove la coda, cancellando tutti i dati, con
1517   effetto immediato. Tutti i processi che cercheranno di accedere alla coda
1518   riceveranno un errore di \errcode{EIDRM}, e tutti processi in attesa su
1519   funzioni di di lettura o di scrittura sulla coda saranno svegliati ricevendo
1520   il medesimo errore. Questo comando può essere eseguito solo da un processo
1521   con user-ID effettivo corrispondente al creatore o al proprietario della
1522   coda, o all'amministratore.
1523 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
1524   della coda, ed il limite massimo sulle dimensioni del totale dei messaggi in
1525   essa contenuti (\var{msg\_qbytes}). I valori devono essere passati in una
1526   struttura \struct{msqid\_ds} puntata da \param{buf}.  Per modificare i valori
1527   di \var{msg\_perm.mode}, \var{msg\_perm.uid} e \var{msg\_perm.gid} occorre
1528   essere il proprietario o il creatore della coda, oppure l'amministratore; lo
1529   stesso vale per \var{msg\_qbytes}, ma l'amministratore ha la facoltà di
1530   incrementarne il valore a limiti superiori a \const{MSGMNB}.
1531 \end{basedescript}
1532
1533
1534 Una volta che si abbia a disposizione l'identificatore, per inviare un
1535 messaggio su una coda si utilizza la funzione \funcd{msgsnd}; il suo prototipo
1536 è:
1537 \begin{functions}
1538   \headdecl{sys/types.h} 
1539   \headdecl{sys/ipc.h} 
1540   \headdecl{sys/msg.h} 
1541   
1542   \funcdecl{int msgsnd(int msqid, struct msgbuf *msgp, size\_t msgsz, int
1543     msgflg)} 
1544
1545   Invia un messaggio sulla coda \param{msqid}.
1546   
1547   \bodydesc{La funzione restituisce 0, e -1 in caso di errore, nel qual caso
1548     \var{errno} assumerà uno dei valori:
1549   \begin{errlist}
1550   \item[\errcode{EACCES}] Non si hanno i privilegi di accesso sulla coda.
1551   \item[\errcode{EIDRM}] La coda è stata cancellata.
1552   \item[\errcode{EAGAIN}] Il messaggio non può essere inviato perché si è
1553   superato il limite \var{msg\_qbytes} sul numero massimo di byte presenti
1554   sulla coda, e si è richiesto \const{IPC\_NOWAIT} in \param{flag}.
1555   \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
1556   \item[\errcode{EINVAL}] Si è specificato un \param{msgid} invalido, o un
1557     valore non positivo per \param{mtype}, o un valore di \param{msgsz}
1558     maggiore di \const{MSGMAX}.
1559   \end{errlist}
1560   ed inoltre \errval{EFAULT} ed \errval{ENOMEM}.
1561 }
1562 \end{functions}
1563
1564 La funzione inserisce il messaggio sulla coda specificata da \param{msqid}; il
1565 messaggio ha lunghezza specificata da \param{msgsz} ed è passato attraverso il
1566 l'argomento \param{msgp}.  Quest'ultimo deve venire passato sempre come
1567 puntatore ad una struttura \struct{msgbuf} analoga a quella riportata in
1568 \figref{fig:ipc_msbuf} che è quella che deve contenere effettivamente il
1569 messaggio.  La dimensione massima per il testo di un messaggio non può
1570 comunque superare il limite \const{MSGMAX}.
1571
1572 La struttura di \figref{fig:ipc_msbuf} è comunque solo un modello, tanto che
1573 la definizione contenuta in \file{sys/msg.h} usa esplicitamente per il secondo
1574 campo il valore \code{mtext[1]}, che non è di nessuna utilità ai fini pratici.
1575 La sola cosa che conta è che la struttura abbia come primo membro un campo
1576 \var{mtype} come nell'esempio; esso infatti serve ad identificare il tipo di
1577 messaggio e deve essere sempre specificato come intero positivo di tipo
1578 \ctyp{long}.  Il campo \var{mtext} invece può essere di qualsiasi tipo e
1579 dimensione, e serve a contenere il testo del messaggio.
1580
1581 In generale pertanto per inviare un messaggio con \func{msgsnd} si usa
1582 ridefinire una struttura simile a quella di \figref{fig:ipc_msbuf}, adattando
1583 alle proprie esigenze il campo \var{mtype}, (o ridefinendo come si vuole il
1584 corpo del messaggio, anche con più campi o con strutture più complesse) avendo
1585 però la cura di mantenere nel primo campo un valore di tipo \ctyp{long} che ne
1586 indica il tipo.
1587
1588 Si tenga presente che la lunghezza che deve essere indicata in questo
1589 argomento è solo quella del messaggio, non quella di tutta la struttura, se
1590 cioè \var{message} è una propria struttura che si passa alla funzione,
1591 \param{msgsz} dovrà essere uguale a \code{sizeof(message)-sizeof(long)}, (se
1592 consideriamo il caso dell'esempio in \figref{fig:ipc_msbuf}, \param{msgsz}
1593 dovrà essere pari a \const{LENGTH}).
1594
1595 \begin{figure}[!htb]
1596   \footnotesize \centering
1597   \begin{minipage}[c]{15cm}
1598     \begin{lstlisting}[labelstep=0]{}
1599     struct msgbuf {
1600          long mtype;          /* message type, must be > 0 */
1601          char mtext[LENGTH];  /* message data */
1602     };
1603     \end{lstlisting}
1604   \end{minipage} 
1605   \normalsize 
1606   \caption{Schema della struttura \structd{msgbuf}, da utilizzare come
1607     argomento per inviare/ricevere messaggi.}
1608   \label{fig:ipc_msbuf}
1609 \end{figure}
1610
1611 Per capire meglio il funzionamento della funzione riprendiamo in
1612 considerazione la struttura della coda illustrata in
1613 \figref{fig:ipc_mq_schema}. Alla chiamata di \func{msgsnd} il nuovo messaggio
1614 sarà aggiunto in fondo alla lista inserendo una nuova struttura \struct{msg},
1615 il puntatore \var{msg\_last} di \struct{msqid\_ds} verrà aggiornato, come pure
1616 il puntatore al messaggio successivo per quello che era il precedente ultimo
1617 messaggio; il valore di \var{mtype} verrà mantenuto in \var{msg\_type} ed il
1618 valore di \param{msgsz} in \var{msg\_ts}; il testo del messaggio sarà copiato
1619 all'indirizzo specificato da \var{msg\_spot}.
1620
1621 Il valore dell'argomento \param{flag} permette di specificare il comportamento
1622 della funzione. Di norma, quando si specifica un valore nullo, la funzione
1623 ritorna immediatamente a meno che si sia ecceduto il valore di
1624 \var{msg\_qbytes}, o il limite di sistema sul numero di messaggi, nel qual
1625 caso si blocca mandando il processo in stato di \textit{sleep}.  Se si
1626 specifica per \param{flag} il valore \const{IPC\_NOWAIT} la funzione opera in
1627 modalità non bloccante, ed in questi casi ritorna immediatamente con un errore
1628 di \errcode{EAGAIN}.
1629
1630 Se non si specifica \const{IPC\_NOWAIT} la funzione resterà bloccata fintanto
1631 che non si liberano risorse sufficienti per poter inserire nella coda il
1632 messaggio, nel qual caso ritornerà normalmente. La funzione può ritornare, con
1633 una condizione di errore anche in due altri casi: quando la coda viene rimossa
1634 (nel qual caso si ha un errore di \errcode{EIDRM}) o quando la funzione viene
1635 interrotta da un segnale (nel qual caso si ha un errore di \errcode{EINTR}).
1636
1637 Una volta completato con successo l'invio del messaggio sulla coda, la
1638 funzione aggiorna i dati mantenuti in \struct{msqid\_ds}, in particolare
1639 vengono modificati:
1640 \begin{itemize*}
1641 \item Il valore di \var{msg\_lspid}, che viene impostato al \acr{pid} del
1642   processo chiamante.
1643 \item Il valore di \var{msg\_qnum}, che viene incrementato di uno.
1644 \item Il valore \var{msg\_stime}, che viene impostato al tempo corrente.
1645 \end{itemize*}
1646
1647 La funzione che viene utilizzata per estrarre un messaggio da una coda è
1648 \funcd{msgrcv}; il suo prototipo è:
1649 \begin{functions}
1650   \headdecl{sys/types.h} 
1651   \headdecl{sys/ipc.h} 
1652   \headdecl{sys/msg.h} 
1653
1654   \funcdecl{ssize\_t msgrcv(int msqid, struct msgbuf *msgp, size\_t msgsz,
1655     long msgtyp, int msgflg)}
1656   
1657   Legge un messaggio dalla coda \param{msqid}.
1658   
1659   \bodydesc{La funzione restituisce il numero di byte letti in caso di
1660     successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà uno
1661     dei valori:
1662   \begin{errlist}
1663   \item[\errcode{EACCES}] Non si hanno i privilegi di accesso sulla coda.
1664   \item[\errcode{EIDRM}] La coda è stata cancellata.
1665   \item[\errcode{E2BIG}] Il testo del messaggio è più lungo di \param{msgsz} e
1666     non si è specificato \const{MSG\_NOERROR} in \param{msgflg}.
1667   \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale mentre
1668     era in attesa di ricevere un messaggio.
1669   \item[\errcode{EINVAL}] Si è specificato un \param{msgid} invalido o un
1670     valore di \param{msgsz} negativo.
1671   \end{errlist}
1672   ed inoltre \errval{EFAULT}.
1673 }
1674 \end{functions}
1675
1676 La funzione legge un messaggio dalla coda specificata, scrivendolo sulla
1677 struttura puntata da \param{msgp}, che dovrà avere un formato analogo a quello
1678 di \figref{fig:ipc_msbuf}.  Una volta estratto, il messaggio sarà rimosso dalla
1679 coda.  L'argomento \param{msgsz} indica la lunghezza massima del testo del
1680 messaggio (equivalente al valore del parametro \const{LENGTH} nell'esempio di
1681 \figref{fig:ipc_msbuf}).
1682
1683 Se il testo del messaggio ha lunghezza inferiore a \param{msgsz} esso viene
1684 rimosso dalla coda; in caso contrario, se \param{msgflg} è impostato a
1685 \const{MSG\_NOERROR}, il messaggio viene troncato e la parte in eccesso viene
1686 perduta, altrimenti il messaggio non viene estratto e la funzione ritorna con
1687 un errore di \errcode{E2BIG}.
1688
1689 L'argomento \param{msgtyp} permette di restringere la ricerca ad un
1690 sottoinsieme dei messaggi presenti sulla coda; la ricerca infatti è fatta con
1691 una scansione della struttura mostrata in \figref{fig:ipc_mq_schema},
1692 restituendo il primo messaggio incontrato che corrisponde ai criteri
1693 specificati (che quindi, visto come i messaggi vengono sempre inseriti dalla
1694 coda, è quello meno recente); in particolare:
1695 \begin{itemize}
1696 \item se \param{msgtyp} è 0 viene estratto il messaggio in cima alla coda, cioè
1697   quello fra i presenti che è stato inserito inserito per primo. 
1698 \item se \param{msgtyp} è positivo viene estratto il primo messaggio il cui
1699   tipo (il valore del campo \var{mtype}) corrisponde al valore di
1700   \param{msgtyp}.
1701 \item se \param{msgtyp} è negativo viene estratto il primo fra i messaggi con
1702   il valore più basso del tipo, fra tutti quelli il cui tipo ha un valore
1703   inferiore al valore assoluto di \param{msgtyp}.
1704 \end{itemize}
1705
1706 Il valore di \param{msgflg} permette di controllare il comportamento della
1707 funzione, esso può essere nullo o una maschera binaria composta da uno o più
1708 valori.  Oltre al precedente \const{MSG\_NOERROR}, sono possibili altri due
1709 valori: \const{MSG\_EXCEPT}, che permette, quando \param{msgtyp} è positivo,
1710 di leggere il primo messaggio nella coda con tipo diverso da \param{msgtyp}, e
1711 \const{IPC\_NOWAIT} che causa il ritorno immediato della funzione quando non
1712 ci sono messaggi sulla coda.
1713
1714 Il comportamento usuale della funzione infatti, se non ci sono messaggi
1715 disponibili per la lettura, è di bloccare il processo in stato di
1716 \textit{sleep}. Nel caso però si sia specificato \const{IPC\_NOWAIT} la
1717 funzione ritorna immediatamente con un errore \errcode{ENOMSG}. Altrimenti la
1718 funzione ritorna normalmente non appena viene inserito un messaggio del tipo
1719 desiderato, oppure ritorna con errore qualora la coda sia rimossa (con
1720 \var{errno} impostata a \errcode{EIDRM}) o se il processo viene interrotto da
1721 un segnale (con \var{errno} impostata a \errcode{EINTR}).
1722
1723 Una volta completata con successo l'estrazione del messaggio dalla coda, la
1724 funzione aggiorna i dati mantenuti in \struct{msqid\_ds}, in particolare
1725 vengono modificati:
1726 \begin{itemize*}
1727 \item Il valore di \var{msg\_lrpid}, che viene impostato al \acr{pid} del
1728   processo chiamante.
1729 \item Il valore di \var{msg\_qnum}, che viene decrementato di uno.
1730 \item Il valore \var{msg\_rtime}, che viene impostato al tempo corrente.
1731 \end{itemize*}
1732
1733 Le code di messaggi presentano il solito problema di tutti gli oggetti del
1734 SysV IPC; essendo questi permanenti restano nel sistema occupando risorse
1735 anche quando un processo è terminato, al contrario delle pipe per le quali
1736 tutte le risorse occupate vengono rilasciate quanto l'ultimo processo che le
1737 utilizzava termina. Questo comporta che in caso di errori si può saturare il
1738 sistema, e che devono comunque essere esplicitamente previste delle funzioni
1739 di rimozione in caso di interruzioni o uscite dal programma (come vedremo in
1740 \figref{fig:ipc_mq_fortune_server}).
1741
1742 L'altro problema è non facendo uso di file descriptor le tecniche di
1743 \textit{I/O multiplexing} descritte in \secref{sec:file_multiplexing} non
1744 possono essere utilizzate, e non si ha a disposizione niente di analogo alle
1745 funzioni \func{select} e \func{poll}. Questo rende molto scomodo usare più di
1746 una di queste strutture alla volta; ad esempio non si può scrivere un server
1747 che aspetti un messaggio su più di una coda senza fare ricorso ad una tecnica
1748 di \textit{polling}\index{polling} che esegua un ciclo di attesa su ciascuna
1749 di esse.
1750
1751 Come esempio dell'uso delle code di messaggi possiamo riscrivere il nostro
1752 server di \textit{fortunes} usando queste al posto delle fifo. In questo caso
1753 useremo una sola coda di messaggi, usando il tipo di messaggio per comunicare
1754 in maniera indipendente con client diversi.
1755
1756 \begin{figure}[!bht]
1757   \footnotesize \centering
1758   \begin{minipage}[c]{15cm}
1759     \begin{lstlisting}{}
1760 int msgid;                                       /* Message queue identifier */
1761 int main(int argc, char *argv[])
1762 {
1763 /* Variables definition */
1764     int i, n = 0;
1765     char **fortune;                       /* array of fortune message string */
1766     char *fortunefilename = "/usr/share/games/fortunes/linux";  /* file name */
1767     struct msgbuf_read {      /* message struct to read request from clients */
1768         long mtype;                               /* message type, must be 1 */
1769         long pid;             /* message data, must be the pid of the client */
1770     } msg_read;
1771     struct msgbuf_write {       /* message struct to write result to clients */
1772         long mtype;            /* message type, will be the pid of the client*/
1773         char mtext[MSGMAX];             /* message data, will be the fortune */
1774     } msg_write;
1775     key_t key;                                          /* Message queue key */
1776     int size;                                                /* message size */
1777     ...
1778     Signal(SIGTERM, HandSIGTERM);            /* set handlers for termination */
1779     Signal(SIGINT, HandSIGTERM);
1780     Signal(SIGQUIT, HandSIGTERM);
1781     if (n==0) usage();          /* if no pool depth exit printing usage info */
1782     i = FortuneParse(fortunefilename, fortune, n);          /* parse phrases */
1783     /* Create the queue */
1784     key = ftok("./MQFortuneServer.c", 1); 
1785     msgid = msgget(key, IPC_CREAT|0666);
1786     if (msgid < 0) {
1787         perror("Cannot create message queue");
1788         exit(1);
1789     }
1790     /* Main body: loop over requests */
1791     daemon(0, 0);
1792     while (1) {
1793         msgrcv(msgid, &msg_read, sizeof(int), 1, MSG_NOERROR);
1794         n = random() % i;                             /* select random value */
1795         strncpy(msg_write.mtext, fortune[n], MSGMAX);
1796         size = min(strlen(fortune[n])+1, MSGMAX);  
1797         msg_write.mtype=msg_read.pid;             /* use request pid as type */
1798         msgsnd(msgid, &msg_write, size, 0);
1799     }
1800 }
1801 /*
1802  * Signal Handler to manage termination
1803  */
1804 void HandSIGTERM(int signo) {
1805     msgctl(msgid, IPC_RMID, NULL);                   /* remove message queue */
1806     exit(0);
1807 }
1808     \end{lstlisting}
1809   \end{minipage} 
1810   \normalsize 
1811   \caption{Sezione principale del codice del server di \textit{fortunes}
1812     basato sulle \textit{message queue}.}
1813   \label{fig:ipc_mq_fortune_server}
1814 \end{figure}
1815
1816 In \figref{fig:ipc_mq_fortune_server} si è riportato un estratto delle parti
1817 principali del codice del nuovo server (il codice completo è nel file
1818 \file{MQFortuneServer.c} nei sorgenti allegati). Il programma è basato su un
1819 uso accorto della caratteristica di poter associate un ``tipo'' ai messaggi
1820 per permettere una comunicazione indipendente fra il server ed i vari client,
1821 usando il \acr{pid} di questi ultimi come identificativo. Questo è possibile
1822 in quanto, al contrario di una fifo, la lettura di una coda di messaggi può
1823 non essere sequenziale, proprio grazie alla classificazione dei messaggi sulla
1824 base del loro tipo.
1825
1826 Il programma, oltre alle solite variabili per il nome del file da cui leggere
1827 le \textit{fortunes} e per il vettore di stringhe che contiene le frasi,
1828 definisce due strutture appositamente per la comunicazione; con
1829 \var{msgbuf\_read} (\texttt{\small 8--11}) vengono passate le richieste mentre
1830 con \var{msgbuf\_write} (\texttt{\small 12--15}) vengono restituite le frasi.
1831
1832 La gestione delle opzioni si è al solito omessa, essa si curerà di impostare
1833 in \var{n} il numero di frasi da leggere specificato a linea di comando ed in
1834 \var{fortunefilename} il file da cui leggerle; dopo aver installato
1835 (\texttt{\small 19--21}) i gestori dei segnali per trattare l'uscita dal
1836 server, viene prima controllato (\texttt{\small 22}) il numero di frasi
1837 richieste abbia senso (cioè sia maggiore di zero), le quali poi
1838 (\texttt{\small 23}) vengono lette nel vettore in memoria con la stessa
1839 funzione \code{FortuneParse} usata anche per il server basato sulle fifo.
1840
1841 Una volta inizializzato il vettore di stringhe coi messaggi presi dal file
1842 delle \textit{fortune} si procede (\texttt{\small 25}) con la generazione di
1843 una chiave per identificare la coda di messaggi (si usa il nome del file dei
1844 sorgenti del server) con la quale poi si esegue (\texttt{\small 26}) la
1845 creazione della stessa (si noti come si sia chiamata \func{msgget} con un
1846 valore opportuno per l'argomento \param{flag}), avendo cura di abortire il
1847 programma (\texttt{\small 27--29}) in caso di errore.
1848
1849 Finita la fase di inizializzazione il server prima (\texttt{\small 32}) chiama
1850 la funzione \func{daemon} per andare in background e poi esegue in permanenza
1851 il ciclo principale (\texttt{\small 33--40}). Questo inizia (\texttt{\small
1852   34}) con il porsi in attesa di un messaggio di richiesta da parte di un
1853 client; si noti infatti come \func{msgrcv} richieda un messaggio con
1854 \var{mtype} uguale a 1: questo è il valore usato per le richieste dato che
1855 corrisponde al \acr{pid} di \cmd{init}, che non può essere un client. L'uso
1856 del flag \const{MSG\_NOERROR} è solo per sicurezza, dato che i messaggi di
1857 richiesta sono di dimensione fissa (e contengono solo il \acr{pid} del
1858 client).
1859
1860 Se non sono presenti messaggi di richiesta \func{msgrcv} si bloccherà,
1861 ritornando soltanto in corrispondenza dell'arrivo sulla coda di un messaggio
1862 di richiesta da parte di un client, in tal caso il ciclo prosegue
1863 (\texttt{\small 35}) selezionando una frase a caso, copiandola (\texttt{\small
1864   36}) nella struttura \var{msgbuf\_write} usata per la risposta e
1865 calcolandone (\texttt{\small 37}) la dimensione.
1866
1867 Per poter permettere a ciascun client di ricevere solo la risposta indirizzata
1868 a lui il tipo del messaggio in uscita viene inizializzato (\texttt{\small 38})
1869 al valore del \acr{pid} del client ricevuto nel messaggio di richiesta.
1870 L'ultimo passo del ciclo (\texttt{\small 39}) è inviare sulla coda il
1871 messaggio di risposta. Si tenga conto che se la coda è piena anche questa
1872 funzione potrà bloccarsi fintanto che non venga liberato dello spazio.
1873
1874 Si noti che il programma può terminare solo grazie ad una interruzione da
1875 parte di un segnale; in tal caso verrà eseguito (\texttt{\small 45--48}) il
1876 gestore \code{HandSIGTERM}, che semplicemente si limita a cancellare la coda
1877 (\texttt{\small 46}) ed ad uscire (\texttt{\small 47}).
1878
1879 \begin{figure}[!bht]
1880   \footnotesize \centering
1881   \begin{minipage}[c]{15cm}
1882     \begin{lstlisting}{}
1883 int main(int argc, char *argv[])
1884 {
1885     ...
1886     key = ftok("./MQFortuneServer.c", 1); 
1887     msgid = msgget(key, 0); 
1888     if (msgid < 0) {
1889         perror("Cannot find message queue");
1890         exit(1);
1891     }
1892     /* Main body: do request and write result */
1893     msg_read.mtype = 1;                      /* type for request is always 1 */
1894     msg_read.pid = getpid();                   /* use pid for communications */
1895     size = sizeof(msg_read.pid);  
1896     msgsnd(msgid, &msg_read, size, 0);               /* send request message */
1897     msgrcv(msgid, &msg_write, MSGMAX, msg_read.pid, MSG_NOERROR);
1898     printf("%s", msg_write.mtext);
1899 }
1900     \end{lstlisting}
1901   \end{minipage} 
1902   \normalsize 
1903   \caption{Sezione principale del codice del client di \textit{fortunes}
1904     basato sulle \textit{message queue}.}
1905   \label{fig:ipc_mq_fortune_client}
1906 \end{figure}
1907
1908 In \figref{fig:ipc_mq_fortune_client} si è riportato un estratto il codice del
1909 programma client.  Al solito il codice completo è con i sorgenti allegati, nel
1910 file \file{MQFortuneClient.c}.  Come sempre si sono rimosse le parti relative
1911 alla gestione delle opzioni, ed in questo caso, anche la dichiarazione delle
1912 variabili, che, per la parte relative alle strutture usate per la
1913 comunicazione tramite le code, sono le stesse viste in
1914 \figref{fig:ipc_mq_fortune_server}.
1915
1916 Il client in questo caso è molto semplice; la prima parte del programma
1917 (\texttt{\small 4--9}) si occupa di accedere alla coda di messaggi, ed è
1918 identica a quanto visto per il server, solo che in questo caso \func{msgget}
1919 non viene chiamata con il flag di creazione in quanto la coda deve essere
1920 preesistente. In caso di errore (ad esempio se il server non è stato avviato)
1921 il programma termina immediatamente. 
1922
1923 Una volta acquisito l'identificatore della coda il client compone il
1924 messaggio di richiesta (\texttt{\small 12--13}) in \var{msg\_read}, usando 1
1925 per il tipo ed inserendo il proprio \acr{pid} come dato da passare al server.
1926 Calcolata (\texttt{\small 14}) la dimensione, provvede (\texttt{\small 15}) ad
1927 immettere la richiesta sulla coda. 
1928
1929 A questo punto non resta che (\texttt{\small 16}) rileggere dalla coda la
1930 risposta del server richiedendo a \func{msgrcv} di selezionare i messaggi di
1931 tipo corrispondente al valore del \acr{pid} inviato nella richiesta. L'ultimo
1932 passo (\texttt{\small 17}) prima di uscire è quello di stampare a video il
1933 messaggio ricevuto.
1934  
1935 Proviamo allora il nostro nuovo sistema, al solito occorre definire
1936 \code{LD\_LIBRAY\_PATH} per accedere alla libreria \file{libgapil.so}, dopo di
1937 che, in maniera del tutto analoga a quanto fatto con il programma che usa le
1938 fifo, potremo far partire il server con:
1939 \begin{verbatim}
1940 [piccardi@gont sources]$ ./mqfortuned -n10
1941 \end{verbatim}%$
1942 come nel caso precedente, avendo eseguito il server in background, il comando
1943 ritornerà immediatamente; potremo però verificare con \cmd{ps} che il
1944 programma è effettivamente in esecuzione, e che ha creato una coda di
1945 messaggi:
1946 \begin{verbatim}
1947 [piccardi@gont sources]$ ipcs
1948
1949 ------ Shared Memory Segments --------
1950 key        shmid      owner      perms      bytes      nattch     status      
1951
1952 ------ Semaphore Arrays --------
1953 key        semid      owner      perms      nsems     
1954
1955 ------ Message Queues --------
1956 key        msqid      owner      perms      used-bytes   messages    
1957 0x0102dc6a 0          piccardi   666        0            0           
1958 \end{verbatim}
1959 a questo punto potremo usare il client per ottenere le nostre frasi:
1960 \begin{verbatim}
1961 [piccardi@gont sources]$ ./mqfortune
1962 Linux ext2fs has been stable for a long time, now it's time to break it
1963         -- Linuxkongreß '95 in Berlin
1964 [piccardi@gont sources]$ ./mqfortune
1965 Let's call it an accidental feature.
1966         --Larry Wall
1967 \end{verbatim}
1968 con un risultato del tutto equivalente al precedente. Infine potremo chiudere
1969 il server inviando il segnale di terminazione con il comando \code{killall
1970   mqfortuned} verificando che effettivamente la coda di messaggi viene rimossa.
1971
1972 Benché funzionante questa architettura risente dello stesso inconveniente
1973 visto anche nel caso del precedente server basato sulle fifo; se il client
1974 viene interrotto dopo l'invio del messaggio di richiesta e prima della lettura
1975 della risposta, quest'ultima resta nella coda (così come per le fifo si aveva
1976 il problema delle fifo che restavano nel filesystem). In questo caso però il
1977 problemi sono maggiori, sia perché è molto più facile esaurire la memoria
1978 dedicata ad una coda di messaggi che gli inode\index{inode} di un filesystem,
1979 sia perché, con il riutilizzo dei \acr{pid} da parte dei processi, un client
1980 eseguito in un momento successivo potrebbe ricevere un messaggio non
1981 indirizzato a lui.
1982
1983
1984
1985 \subsection{Semafori}
1986 \label{sec:ipc_sysv_sem}
1987
1988 I semafori non sono meccanismi di intercomunicazione diretta come quelli
1989 (pipe, fifo e code di messaggi) visti finora, e non consentono di scambiare
1990 dati fra processi, ma servono piuttosto come meccanismi di sincronizzazione o
1991 di protezione per le \textsl{sezioni critiche}\index{sezioni critiche} del
1992 codice (si ricordi quanto detto in \secref{sec:proc_race_cond}). 
1993
1994 Un semaforo è uno speciale contatore, mantenuto nel kernel, che permette, a
1995 seconda del suo valore, di consentire o meno la prosecuzione dell'esecuzione
1996 di un programma. In questo modo l'accesso ad una risorsa condivisa da più
1997 processi può essere controllato, associando ad essa un semaforo che consente
1998 di assicurare che non più di un processo alla volta possa usarla.
1999
2000 Il concetto di semaforo è uno dei concetti base nella programmazione ed è
2001 assolutamente generico, così come del tutto generali sono modalità con cui lo
2002 si utilizza. Un processo che deve accedere ad una risorsa eseguirà un
2003 controllo del semaforo: se questo è positivo il suo valore sarà decrementato,
2004 indicando che si è consumato una unità della risorsa, ed il processo potrà
2005 proseguire nell'utilizzo di quest'ultima, provvedendo a rilasciarla, una volta
2006 completate le operazioni volute, reincrementando il semaforo.
2007
2008 Se al momento del controllo il valore del semaforo è nullo, siamo invece in
2009 una situazione in cui la risorsa non è disponibile, ed il processo si
2010 bloccherà in stato di \textit{sleep} fin quando chi la sta utilizzando non la
2011 rilascerà, incrementando il valore del semaforo. Non appena il semaforo torna
2012 positivo, indicando che la risorsa è disponibile, il processo sarà svegliato,
2013 e si potrà operare come nel caso precedente (decremento del semaforo, accesso
2014 alla risorsa, incremento del semaforo).
2015
2016 Per poter implementare questo tipo di logica le operazioni di controllo e
2017 decremento del contatore associato al semaforo devono essere atomiche,
2018 pertanto una realizzazione di un oggetto di questo tipo è necessariamente
2019 demandata al kernel. La forma più semplice di semaforo è quella del
2020 \textsl{semaforo binario}, o \textit{mutex}, in cui un valore diverso da zero
2021 (normalmente 1) indica la libertà di accesso, e un valore nullo l'occupazione
2022 della risorsa; in generale però si possono usare semafori con valori interi,
2023 utilizzando il valore del contatore come indicatore del ``numero di risorse''
2024 ancora disponibili.
2025
2026 Il sistema di comunicazione inter-processo di \textit{SysV IPC} prevede anche i
2027 semafori, ma gli oggetti utilizzati non sono semafori singoli, ma gruppi di
2028 semafori detti \textsl{insiemi} (o \textit{semaphore set}); la funzione che
2029 permette di creare o ottenere l'identificatore di un insieme di semafori è
2030 \funcd{semget}, ed il suo prototipo è:
2031 \begin{functions}
2032   \headdecl{sys/types.h} 
2033   \headdecl{sys/ipc.h} 
2034   \headdecl{sys/sem.h} 
2035   
2036   \funcdecl{int semget(key\_t key, int nsems, int flag)}
2037   
2038   Restituisce l'identificatore di un insieme di semafori.
2039   
2040   \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
2041     in caso di errore, nel qual caso \var{errno} assumerà i valori:
2042     \begin{errlist}
2043     \item[\errcode{ENOSPC}] Si è cercato di creare una insieme di semafori
2044       quando è stato superato o il limite per il numero totale di semafori
2045       (\const{SEMMNS}) o quello per il numero totale degli insiemi
2046       (\const{SEMMNI}) nel sistema.
2047     \item[\errcode{EINVAL}] L'argomento \param{nsems} è minore di zero o
2048       maggiore del limite sul numero di semafori per ciascun insieme
2049       (\const{SEMMSL}), o se l'insieme già esiste, maggiore del numero di
2050       semafori che contiene.
2051     \item[\errcode{ENOMEM}] Il sistema non ha abbastanza memoria per poter
2052       contenere le strutture per un nuovo insieme di semafori.
2053     \end{errlist}
2054     ed inoltre \errval{EACCES}, \errval{ENOENT}, \errval{EEXIST},
2055     \errval{EIDRM}, con lo stesso significato che hanno per \func{msgget}.}
2056 \end{functions}
2057
2058 La funzione è del tutto analoga a \func{msgget}, solo che in questo caso
2059 restituisce l'identificatore di un insieme di semafori, in particolare è
2060 identico l'uso degli argomenti \param{key} e \param{flag}, per cui non
2061 ripeteremo quanto detto al proposito in \secref{sec:ipc_sysv_mq}. L'argomento
2062 \param{nsems} permette di specificare quanti semafori deve contenere l'insieme
2063 quando se ne richieda la creazione, e deve essere nullo quando si effettua una
2064 richiesta dell'identificatore di un insieme già esistente.
2065
2066 Purtroppo questa implementazione complica inutilmente lo schema elementare che
2067 abbiamo descritto, dato che non è possibile definire un singolo semaforo, ma
2068 se ne deve creare per forza un insieme.  Ma questa in definitiva è solo una
2069 complicazione inutile, il problema è che i semafori del \textit{SysV IPC}
2070 soffrono di altri due, ben più gravi, difetti.
2071
2072 Il primo difetto è che non esiste una funzione che permetta di creare ed
2073 inizializzare un semaforo in un'unica chiamata; occorre prima creare l'insieme
2074 dei semafori con \func{semget} e poi inizializzarlo con \func{semctl}, si
2075 perde così ogni possibilità di eseguire l'operazione atomicamente.
2076
2077 Il secondo difetto deriva dalla caratteristica generale degli oggetti del
2078 \textit{SysV IPC} di essere risorse globali di sistema, che non vengono
2079 cancellate quando nessuno le usa più; ci si così a trova a dover affrontare
2080 esplicitamente il caso in cui un processo termina per un qualche errore,
2081 lasciando un semaforo occupato, che resterà tale fino al successivo riavvio
2082 del sistema. Come vedremo esistono delle modalità per evitare tutto ciò, ma
2083 diventa necessario indicare esplicitamente che si vuole il ripristino del
2084 semaforo all'uscita del processo.
2085
2086
2087 \begin{figure}[!htb]
2088   \footnotesize \centering
2089   \begin{minipage}[c]{15cm}
2090     \begin{lstlisting}[labelstep=0]{}
2091 struct semid_ds
2092 {
2093     struct ipc_perm sem_perm;           /* operation permission struct */
2094     time_t sem_otime;                   /* last semop() time */
2095     time_t sem_ctime;                   /* last time changed by semctl() */
2096     unsigned long int sem_nsems;        /* number of semaphores in set */
2097 };
2098     \end{lstlisting}
2099   \end{minipage} 
2100   \normalsize 
2101   \caption{La struttura \structd{semid\_ds}, associata a ciascun insieme di
2102     semafori.}
2103   \label{fig:ipc_semid_ds}
2104 \end{figure}
2105
2106 A ciascun insieme di semafori è associata una struttura \struct{semid\_ds},
2107 riportata in \figref{fig:ipc_semid_ds}.\footnote{non si sono riportati i campi
2108   ad uso interno del kernel, che vedremo in \figref{fig:ipc_sem_schema}, che
2109   dipendono dall'implementazione.} Come nel caso delle code di messaggi quando
2110 si crea un nuovo insieme di semafori con \func{semget} questa struttura viene
2111 inizializzata, in particolare il campo \var{sem\_perm} viene inizializzato
2112 come illustrato in \secref{sec:ipc_sysv_access_control} (si ricordi che in
2113 questo caso il permesso di scrittura è in realtà permesso di alterare il
2114 semaforo), per quanto riguarda gli altri campi invece:
2115 \begin{itemize*}
2116 \item il campo \var{sem\_nsems}, che esprime il numero di semafori
2117   nell'insieme, viene inizializzato al valore di \param{nsems}.
2118 \item il campo \var{sem\_ctime}, che esprime il tempo di creazione
2119   dell'insieme, viene inizializzato al tempo corrente.
2120 \item il campo \var{sem\_otime}, che esprime il tempo dell'ultima operazione
2121   effettuata, viene inizializzato a zero.
2122 \end{itemize*}
2123
2124
2125 Ciascun semaforo dell'insieme è realizzato come una struttura di tipo
2126 \struct{sem} che ne contiene i dati essenziali, la sua definizione\footnote{si
2127   è riportata la definizione originaria del kernel 1.0, che contiene la prima
2128   realizzazione del \textit{SysV IPC} in Linux. In realtà questa struttura
2129   ormai è ridotta ai soli due primi membri, e gli altri vengono calcolati
2130   dinamicamente. La si è utilizzata a scopo di esempio, perché indica tutti i
2131   valori associati ad un semaforo, restituiti dalle funzioni di controllo, e
2132   citati dalle pagine di manuale.} è riportata in \figref{fig:ipc_sem}. Questa
2133 struttura, non è accessibile in user space, ma i valori in essa specificati
2134 possono essere letti in maniera indiretta, attraverso l'uso delle funzioni di
2135 controllo.
2136
2137 \begin{figure}[!htb]
2138   \footnotesize \centering
2139   \begin{minipage}[c]{15cm}
2140     \begin{lstlisting}[labelstep=0]{}
2141 struct sem {
2142   short   sempid;         /* pid of last operation */
2143   ushort  semval;         /* current value */
2144   ushort  semncnt;        /* num procs awaiting increase in semval */
2145   ushort  semzcnt;        /* num procs awaiting semval = 0 */
2146 };
2147     \end{lstlisting}
2148   \end{minipage} 
2149   \normalsize 
2150   \caption{La struttura \structd{sem}, che contiene i dati di un singolo
2151     semaforo.} 
2152   \label{fig:ipc_sem}
2153 \end{figure}
2154
2155 I dati mantenuti nella struttura, ed elencati in \figref{fig:ipc_sem},
2156 indicano rispettivamente:
2157 \begin{description*}
2158 \item[\var{semval}] il valore numerico del semaforo.
2159 \item[\var{sempid}] il \acr{pid} dell'ultimo processo che ha eseguito una
2160   operazione sul semaforo.
2161 \item[\var{semncnt}] il numero di processi in attesa che esso venga
2162   incrementato.
2163 \item[\var{semzcnt}] il numero di processi in attesa che esso si annulli.
2164 \end{description*}
2165
2166 \begin{table}[htb]
2167   \footnotesize
2168   \centering
2169   \begin{tabular}[c]{|c|r|p{8cm}|}
2170     \hline
2171     \textbf{Costante} & \textbf{Valore} & \textbf{Significato} \\
2172     \hline
2173     \hline
2174     \const{SEMMNI}&          128 & Numero massimo di insiemi di semafori. \\
2175     \const{SEMMSL}&          250 & Numero massimo di semafori per insieme.\\
2176     \const{SEMMNS}&\const{SEMMNI}*\const{SEMMSL}& Numero massimo di semafori
2177                                    nel sistema .\\
2178     \const{SEMVMX}&        32767 & Massimo valore per un semaforo.\\
2179     \const{SEMOPM}&           32 & Massimo numero di operazioni per chiamata a
2180                                    \func{semop}. \\
2181     \const{SEMMNU}&\const{SEMMNS}& Massimo numero di strutture di ripristino.\\
2182     \const{SEMUME}&\const{SEMOPM}& Massimo numero di voci di ripristino.\\
2183     \const{SEMAEM}&\const{SEMVMX}& valore massimo per l'aggiustamento
2184                                    all'uscita. \\
2185     \hline
2186   \end{tabular}
2187   \caption{Valori delle costanti associate ai limiti degli insiemi di
2188     semafori, definite in \file{linux/sem.h}.} 
2189   \label{tab:ipc_sem_limits}
2190 \end{table}
2191
2192 Come per le code di messaggi anche per gli insiemi di semafori esistono una
2193 serie di limiti, i cui valori sono associati ad altrettante costanti, che si
2194 sono riportate in \tabref{tab:ipc_sem_limits}. Alcuni di questi limiti sono al
2195 solito accessibili e modificabili attraverso \func{sysctl} o scrivendo
2196 direttamente nel file \file{/proc/sys/kernel/sem}.
2197
2198 La funzione che permette di effettuare le varie operazioni di controllo sui
2199 semafori (fra le quali, come accennato, è impropriamente compresa anche la
2200 loro inizializzazione) è \funcd{semctl}; il suo prototipo è:
2201 \begin{functions}
2202   \headdecl{sys/types.h} 
2203   \headdecl{sys/ipc.h} 
2204   \headdecl{sys/sem.h} 
2205   
2206   \funcdecl{int semctl(int semid, int semnum, int cmd)}
2207   \funcdecl{int semctl(int semid, int semnum, int cmd, union semun arg)}
2208   
2209   Esegue le operazioni di controllo su un semaforo o un insieme di semafori.
2210   
2211   \bodydesc{La funzione restituisce in caso di successo un valore positivo
2212     quanto usata con tre argomenti ed un valore nullo quando usata con
2213     quattro. In caso di errore restituisce -1, ed \var{errno} assumerà uno dei
2214     valori:
2215     \begin{errlist}
2216     \item[\errcode{EACCES}] Il processo non ha i privilegi per eseguire
2217       l'operazione richiesta.
2218     \item[\errcode{EIDRM}] L'insieme di semafori è stato cancellato.
2219     \item[\errcode{EPERM}] Si è richiesto \const{IPC\_SET} o \const{IPC\_RMID}
2220       ma il processo non ha privilegi sufficienti ad eseguire l'operazione.
2221     \item[\errcode{ERANGE}] Si è richiesto \const{SETALL} \const{SETVAL} ma il
2222       valore a cui si vuole impostare il semaforo è minore di zero o maggiore
2223       di \const{SEMVMX}.
2224   \end{errlist}
2225   ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
2226 }
2227 \end{functions}
2228
2229 La funzione può avere tre o quattro parametri, a seconda dell'operazione
2230 specificata con \param{cmd}, ed opera o sull'intero insieme specificato da
2231 \param{semid} o sul singolo semaforo di un insieme, specificato da
2232 \param{semnum}. 
2233
2234 \begin{figure}[!htb]
2235   \footnotesize \centering
2236   \begin{minipage}[c]{15cm}
2237     \begin{lstlisting}[labelstep=0]{}
2238 union semun {
2239       int val;                  /* value for SETVAL */
2240       struct semid_ds *buf;     /* buffer for IPC_STAT, IPC_SET */
2241       unsigned short *array;    /* array for GETALL, SETALL */
2242                                 /* Linux specific part: */
2243       struct seminfo *__buf;    /* buffer for IPC_INFO */
2244 };
2245     \end{lstlisting}
2246   \end{minipage} 
2247   \normalsize 
2248   \caption{La definizione dei possibili valori di una \direct{union}
2249     \structd{semun}, usata come quarto argomento della funzione
2250     \func{semctl}.}
2251   \label{fig:ipc_semun}
2252 \end{figure}
2253
2254 Qualora la funzione operi con quattro argomenti \param{arg} è un argomento
2255 generico, che conterrà un dato diverso a seconda dell'azione richiesta; per
2256 unificare l'argomento esso deve essere passato come una \struct{semun}, la cui
2257 definizione, con i possibili valori che può assumere, è riportata in
2258 \figref{fig:ipc_semun}.
2259
2260 Come già accennato sia il comportamento della funzione che il numero di
2261 parametri con cui deve essere invocata, dipendono dal valore dell'argomento
2262 \param{cmd}, che specifica l'azione da intraprendere; i valori validi (che
2263 cioè non causano un errore di \errcode{EINVAL}) per questo argomento sono i
2264 seguenti:
2265 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
2266 \item[\const{IPC\_STAT}] Legge i dati dell'insieme di semafori, copiando il
2267   contenuto della relativa struttura \struct{semid\_ds} all'indirizzo
2268   specificato con \var{arg.buf}. Occorre avere il permesso di lettura.
2269   L'argomento \param{semnum} viene ignorato.
2270 \item[\const{IPC\_RMID}] Rimuove l'insieme di semafori e le relative strutture
2271   dati, con effetto immediato. Tutti i processi che erano stato di
2272   \textit{sleep} vengono svegliati, ritornando con un errore di
2273   \errcode{EIDRM}.  L'user-ID effettivo del processo deve corrispondere o al
2274   creatore o al proprietario dell'insieme, o all'amministratore. L'argomento
2275   \param{semnum} viene ignorato.
2276 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
2277   dell'insieme. I valori devono essere passati in una struttura
2278   \struct{semid\_ds} puntata da \param{arg.buf} di cui saranno usati soltanto i
2279   campi \var{sem\_perm.uid}, \var{sem\_perm.gid} e i nove bit meno
2280   significativi di \var{sem\_perm.mode}. L'user-ID effettivo del processo deve
2281   corrispondere o al creatore o al proprietario dell'insieme, o
2282   all'amministratore.  L'argomento \param{semnum} viene ignorato.
2283 \item[\const{GETALL}] Restituisce il valore corrente di ciascun semaforo
2284   dell'insieme (corrispondente al campo \var{semval} di \struct{sem}) nel
2285   vettore indicato da \param{arg.array}. Occorre avere il permesso di lettura.
2286   L'argomento \param{semnum} viene ignorato.
2287 \item[\const{GETNCNT}] Restituisce come valore di ritorno della funzione il
2288   numero di processi in attesa che il semaforo \param{semnum} dell'insieme
2289   \param{semid} venga incrementato (corrispondente al campo \var{semncnt} di
2290   \struct{sem}); va invocata con tre argomenti.  Occorre avere il permesso di
2291   lettura.
2292 \item[\const{GETPID}] Restituisce come valore di ritorno della funzione il
2293   \acr{pid} dell'ultimo processo che ha compiuto una operazione sul semaforo
2294   \param{semnum} dell'insieme \param{semid} (corrispondente al campo
2295   \var{sempid} di \struct{sem}); va invocata con tre argomenti.  Occorre avere
2296   il permesso di lettura.
2297 \item[\const{GETVAL}] Restituisce come valore di ritorno della funzione il il
2298   valore corrente del semaforo \param{semnum} dell'insieme \param{semid}
2299   (corrispondente al campo \var{semval} di \struct{sem}); va invocata con tre
2300   argomenti.  Occorre avere il permesso di lettura.
2301 \item[\const{GETZCNT}] Restituisce come valore di ritorno della funzione il
2302   numero di processi in attesa che il valore del semaforo \param{semnum}
2303   dell'insieme \param{semid} diventi nullo (corrispondente al campo
2304   \var{semncnt} di \struct{sem}); va invocata con tre argomenti.  Occorre avere
2305   il permesso di lettura.
2306 \item[\const{SETALL}] Inizializza il valore di tutti i semafori dell'insieme,
2307   aggiornando il campo \var{sem\_ctime} di \struct{semid\_ds}. I valori devono
2308   essere passati nel vettore indicato da \param{arg.array}.  Si devono avere i
2309   privilegi di scrittura sul semaforo.  L'argomento \param{semnum} viene
2310   ignorato.
2311 \item[\const{SETVAL}] Inizializza il semaforo \param{semnum} al valore passato
2312   dall'argomento \param{arg.val}, aggiornando il campo \var{sem\_ctime} di
2313   \struct{semid\_ds}.  Si devono avere i privilegi di scrittura sul semaforo.
2314 \end{basedescript}
2315
2316 Quando si imposta il valore di un semaforo (sia che lo si faccia per tutto
2317 l'insieme con \const{SETALL}, che per un solo semaforo con \const{SETVAL}), i
2318 processi in attesa su di esso reagiscono di conseguenza al cambiamento di
2319 valore.  Inoltre la coda delle operazioni di ripristino viene cancellata per
2320 tutti i semafori il cui valore viene modificato.
2321
2322 \begin{table}[htb]
2323   \footnotesize
2324   \centering
2325   \begin{tabular}[c]{|c|l|}
2326     \hline
2327     \textbf{Operazione}  & \textbf{Valore restituito} \\
2328     \hline
2329     \hline
2330     \const{GETNCNT}& valore di \var{semncnt}.\\
2331     \const{GETPID} & valore di \var{sempid}.\\
2332     \const{GETVAL} & valore di \var{semval}.\\
2333     \const{GETZCNT}& valore di \var{semzcnt}.\\
2334     \hline
2335   \end{tabular}
2336   \caption{Valori di ritorno della funzione \func{semctl}.} 
2337   \label{tab:ipc_semctl_returns}
2338 \end{table}
2339
2340 Il valore di ritorno della funzione in caso di successo dipende
2341 dall'operazione richiesta; per tutte le operazioni che richiedono quattro
2342 argomenti esso è sempre nullo, per le altre operazioni, elencate in
2343 \tabref{tab:ipc_semctl_returns} viene invece restituito il valore richiesto,
2344 corrispondente al campo della struttura \struct{sem} indicato nella seconda
2345 colonna della tabella.
2346
2347 Le operazioni ordinarie sui semafori, come l'acquisizione o il rilascio degli
2348 stessi (in sostanza tutte quelle non comprese nell'uso di \func{semctl})
2349 vengono effettuate con la funzione \funcd{semop}, il cui prototipo è:
2350 \begin{functions}
2351   \headdecl{sys/types.h} 
2352   \headdecl{sys/ipc.h} 
2353   \headdecl{sys/sem.h} 
2354   
2355   \funcdecl{int semop(int semid, struct sembuf *sops, unsigned nsops)}
2356   
2357   Esegue le operazioni ordinarie su un semaforo o un insieme di semafori.
2358   
2359   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
2360     errore, nel qual caso \var{errno} assumerà uno dei valori:
2361     \begin{errlist}
2362     \item[\errcode{EACCES}] Il processo non ha i privilegi per eseguire
2363       l'operazione richiesta.
2364     \item[\errcode{EIDRM}] L'insieme di semafori è stato cancellato.
2365     \item[\errcode{ENOMEM}] Si è richiesto un \const{SEM\_UNDO} ma il sistema
2366       non ha le risorse per allocare la struttura di ripristino.
2367     \item[\errcode{EAGAIN}] Un'operazione comporterebbe il blocco del processo,
2368       ma si è specificato \const{IPC\_NOWAIT} in \var{sem\_flg}.
2369     \item[\errcode{EINTR}] La funzione, bloccata in attesa dell'esecuzione
2370       dell'operazione, viene interrotta da un segnale.
2371     \item[\errcode{E2BIG}] L'argomento \param{nsops} è maggiore del numero
2372       massimo di operazioni \const{SEMOPM}.
2373     \item[\errcode{ERANGE}] Per alcune operazioni il valore risultante del
2374       semaforo viene a superare il limite massimo \const{SEMVMX}.
2375   \end{errlist}
2376   ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
2377 }
2378 \end{functions}
2379
2380 La funzione permette di eseguire operazioni multiple sui singoli semafori di
2381 un insieme. La funzione richiede come primo argomento l'identificatore
2382 \param{semid} dell'insieme su cui si vuole operare. Il numero di operazioni da
2383 effettuare viene specificato con l'argomento \param{nsop}, mentre il loro
2384 contenuto viene passato con un puntatore ad un vettore di strutture
2385 \struct{sembuf} nell'argomento \param{sops}. Le operazioni richieste vengono
2386 effettivamente eseguite se e soltanto se è possibile effettuarle tutte quante.
2387
2388 \begin{figure}[!htb]
2389   \footnotesize \centering
2390   \begin{minipage}[c]{15cm}
2391     \begin{lstlisting}[labelstep=0]{}
2392 struct sembuf
2393 {
2394   unsigned short int sem_num;   /* semaphore number */
2395   short int sem_op;             /* semaphore operation */
2396   short int sem_flg;            /* operation flag */
2397 };
2398     \end{lstlisting}
2399   \end{minipage} 
2400   \normalsize 
2401   \caption{La struttura \structd{sembuf}, usata per le operazioni sui
2402     semafori.}
2403   \label{fig:ipc_sembuf}
2404 \end{figure}
2405
2406 Il contenuto di ciascuna operazione deve essere specificato attraverso una
2407 opportuna struttura \struct{sembuf} (la cui definizione è riportata in
2408 \figref{fig:ipc_sembuf}) che il programma chiamante deve avere cura di
2409 allocare in un opportuno vettore. La struttura permette di indicare il
2410 semaforo su cui operare, il tipo di operazione, ed un flag di controllo.
2411 Il campo \var{sem\_num} serve per indicare a quale semaforo dell'insieme fa
2412 riferimento l'operazione; si ricordi che i semafori sono numerati come in un
2413 vettore, per cui il primo semaforo corrisponde ad un valore nullo di
2414 \var{sem\_num}.
2415
2416 Il campo \var{sem\_flg} è un flag, mantenuto come maschera binaria, per il
2417 quale possono essere impostati i due valori \const{IPC\_NOWAIT} e
2418 \const{SEM\_UNDO}.  Impostando \const{IPC\_NOWAIT} si fa si che, invece di
2419 bloccarsi (in tutti quei casi in cui l'esecuzione di una operazione richiede
2420 che il processo vada in stato di \textit{sleep}), \func{semop} ritorni
2421 immediatamente con un errore di \errcode{EAGAIN}.  Impostando \const{SEM\_UNDO}
2422 si richiede invece che l'operazione venga registrata in modo che il valore del
2423 semaforo possa essere ripristinato all'uscita del processo.
2424
2425 Infine \var{sem\_op} è il campo che controlla l'operazione che viene eseguita
2426 e determina il comportamento della chiamata a \func{semop}; tre sono i casi
2427 possibili:
2428 \begin{basedescript}{\desclabelwidth{2.0cm}}
2429 \item[\var{sem\_op}$>0$] In questo caso il valore di \var{sem\_op} viene
2430   aggiunto al valore corrente di \var{semval}. La funzione ritorna
2431   immediatamente (con un errore di \errcode{ERANGE} qualora si sia superato il
2432   limite \const{SEMVMX}) ed il processo non viene bloccato in nessun caso.
2433   Specificando \const{SEM\_UNDO} si aggiorna il contatore per il ripristino
2434   del valore del semaforo. Al processo chiamante è richiesto il privilegio di
2435   alterazione (scrittura) sull'insieme di semafori.
2436   
2437 \item[\var{sem\_op}$=0$] Nel caso \var{semval} sia zero l'esecuzione procede
2438   immediatamente. Se \var{semval} è diverso da zero il comportamento è
2439   controllato da \var{sem\_flg}, se è stato impostato \const{IPC\_NOWAIT} la
2440   funzione ritorna con un errore di \errcode{EAGAIN}, altrimenti viene
2441   incrementato \var{semzcnt} di uno ed il processo resta in stato di
2442   \textit{sleep} fintanto che non si ha una delle condizioni seguenti:
2443   \begin{itemize*}
2444   \item \var{semval} diventa zero, nel qual caso \var{semzcnt} viene
2445     decrementato di uno.
2446   \item l'insieme di semafori viene rimosso, nel qual caso \func{semop} ritorna
2447     un errore di \errcode{EIDRM}.
2448   \item il processo chiamante riceve un segnale, nel qual caso \var{semzcnt}
2449     viene decrementato di uno e \func{semop} ritorna un errore di
2450     \errcode{EINTR}.
2451   \end{itemize*}
2452   Al processo chiamante è richiesto il privilegio di lettura dell'insieme dei
2453   semafori.
2454   
2455 \item[\var{sem\_op}$<0$] Nel caso in cui \var{semval} è maggiore o uguale del
2456   valore assoluto di \var{sem\_op} (se cioè la somma dei due valori resta
2457   positiva o nulla) i valori vengono sommati e la funzione ritorna
2458   immediatamente; qualora si sia impostato \const{SEM\_UNDO} viene anche
2459   aggiornato il contatore per il ripristino del valore del semaforo. In caso
2460   contrario (quando cioè la somma darebbe luogo ad un valore di \var{semval}
2461   negativo) se si è impostato \const{IPC\_NOWAIT} la funzione ritorna con un
2462   errore di \errcode{EAGAIN}, altrimenti viene incrementato di uno
2463   \var{semncnt} ed il processo resta in stato di \textit{sleep} fintanto che
2464   non si ha una delle condizioni seguenti:
2465   \begin{itemize*}
2466   \item \var{semval} diventa maggiore o uguale del valore assoluto di
2467     \var{sem\_op}, nel qual caso \var{semncnt} viene decrementato di uno, il
2468     valore di \var{sem\_op} viene sommato a \var{semval}, e se era stato
2469     impostato \const{SEM\_UNDO} viene aggiornato il contatore per il
2470     ripristino del valore del semaforo.
2471   \item l'insieme di semafori viene rimosso, nel qual caso \func{semop}
2472     ritorna un errore di \errcode{EIDRM}.
2473   \item il processo chiamante riceve un segnale, nel qual caso \var{semncnt}
2474     viene decrementato di uno e \func{semop} ritorna un errore di
2475     \errcode{EINTR}.
2476   \end{itemize*}    
2477   Al processo chiamante è richiesto il privilegio di alterazione (scrittura)
2478   sull'insieme di semafori.
2479 \end{basedescript}
2480
2481 In caso di successo della funzione viene aggiornato il campo \var{sempid} per
2482 ogni semaforo modificato al valore del \acr{pid} del processo chiamante;
2483 inoltre vengono pure aggiornati al tempo corrente i campi \var{sem\_otime} e
2484 \var{sem\_ctime}.
2485
2486 Dato che, come già accennato in precedenza, in caso di uscita inaspettata i
2487 semafori possono restare occupati, abbiamo visto come \func{semop} permetta di
2488 attivare un meccanismo di ripristino attraverso l'uso del flag
2489 \const{SEM\_UNDO}. Il meccanismo è implementato tramite una apposita struttura
2490 \struct{sem\_undo}, associata ad ogni processo per ciascun semaforo che esso
2491 ha modificato; all'uscita i semafori modificati vengono ripristinati, e le
2492 strutture disallocate.  Per mantenere coerente il comportamento queste
2493 strutture non vengono ereditate attraverso una \func{fork} (altrimenti si
2494 avrebbe un doppio ripristino), mentre passano inalterate nell'esecuzione di
2495 una \func{exec} (altrimenti non si avrebbe ripristino).
2496
2497 Tutto questo però ha un problema di fondo. Per capire di cosa si tratta
2498 occorre fare riferimento all'implementazione usata in Linux, che è riportata
2499 in maniera semplificata nello schema di \figref{fig:ipc_sem_schema}.  Si è
2500 presa come riferimento l'architettura usata fino al kernel 2.2.x che è più
2501 semplice (ed illustrata in dettaglio in \cite{tlk}); nel kernel 2.4.x la
2502 struttura del \textit{SysV IPC} è stata modificata, ma le definizioni relative
2503 a queste strutture restano per compatibilità.\footnote{in particolare con le
2504   vecchie versioni delle librerie del C, come le libc5.}
2505
2506 \begin{figure}[htb]
2507   \centering \includegraphics[width=15cm]{img/semtruct}
2508   \caption{Schema della struttura di un insieme di semafori.}
2509   \label{fig:ipc_sem_schema}
2510 \end{figure}
2511
2512 Alla creazione di un nuovo insieme viene allocata una nuova strutture
2513 \struct{semid\_ds} ed il relativo vettore di strutture \struct{sem}. Quando si
2514 richiede una operazione viene anzitutto verificato che tutte le operazioni
2515 possono avere successo; se una di esse comporta il blocco del processo il
2516 kernel crea una struttura \struct{sem\_queue} che viene aggiunta in fondo alla
2517 coda di attesa associata a ciascun insieme di semafori\footnote{che viene
2518   referenziata tramite i campi \var{sem\_pending} e \var{sem\_pending\_last}
2519   di \struct{semid\_ds}.}. Nella struttura viene memorizzato il riferimento
2520 alle operazioni richieste (nel campo \var{sops}, che è un puntatore ad una
2521 struttura \struct{sembuf}) e al processo corrente (nel campo \var{sleeper}) poi
2522 quest'ultimo viene messo stato di attesa e viene invocato lo
2523 scheduler\index{scheduler} per passare all'esecuzione di un altro processo.
2524
2525 Se invece tutte le operazioni possono avere successo queste vengono eseguite
2526 immediatamente, dopo di che il kernel esegue una scansione della coda di
2527 attesa (a partire da \var{sem\_pending}) per verificare se qualcuna delle
2528 operazioni sospese in precedenza può essere eseguita, nel qual caso la
2529 struttura \struct{sem\_queue} viene rimossa e lo stato del processo associato
2530 all'operazione (\var{sleeper}) viene riportato a \textit{running}; il tutto
2531 viene ripetuto fin quando non ci sono più operazioni eseguibili o si è
2532 svuotata la coda.
2533
2534 Per gestire il meccanismo del ripristino tutte le volte che per un'operazione
2535 si è specificato il flag \const{SEM\_UNDO} viene mantenuta per ciascun insieme
2536 di semafori una apposita struttura \struct{sem\_undo} che contiene (nel vettore
2537 puntato dal campo \var{semadj}) un valore di aggiustamento per ogni semaforo
2538 cui viene sommato l'opposto del valore usato per l'operazione. 
2539
2540 Queste strutture sono mantenute in due liste,\footnote{rispettivamente
2541   attraverso i due campi \var{id\_next} e \var{proc\_next}.} una associata
2542 all'insieme di cui fa parte il semaforo, che viene usata per invalidare le
2543 strutture se questo viene cancellato o per azzerarle se si è eseguita una
2544 operazione con \func{semctl}; l'altra associata al processo che ha eseguito
2545 l'operazione;\footnote{attraverso il campo \var{semundo} di
2546   \struct{task\_struct}, come mostrato in \ref{fig:ipc_sem_schema}.} quando un
2547 processo termina, la lista ad esso associata viene scandita e le operazioni
2548 applicate al semaforo.
2549
2550 Siccome un processo può accumulare delle richieste di ripristino per semafori
2551 differenti chiamate attraverso diverse chiamate a \func{semop}, si pone il
2552 problema di come eseguire il ripristino dei semafori all'uscita del processo,
2553 ed in particolare se questo può essere fatto atomicamente. Il punto è cosa
2554 succede quando una delle operazioni previste per il ripristino non può essere
2555 eseguita immediatamente perché ad esempio il semaforo è occupato; in tal caso
2556 infatti, se si pone il processo in stato di \textit{sleep} aspettando la
2557 disponibilità del semaforo (come faceva l'implementazione originaria) si perde
2558 l'atomicità dell'operazione. La scelta fatta dal kernel è pertanto quella di
2559 effettuare subito le operazioni che non prevedono un blocco del processo e di
2560 ignorare silenziosamente le altre; questo però comporta il fatto che il
2561 ripristino non è comunque garantito in tutte le occasioni.
2562
2563 Come esempio di uso dell'interfaccia dei semafori vediamo come implementare
2564 con essa dei semplici \textit{mutex} (cioè semafori binari), tutto il codice
2565 in questione, contenuto nel file \file{Mutex.c} allegato ai sorgenti, è
2566 riportato in \figref{fig:ipc_mutex_create}. Utilizzeremo l'interfaccia per
2567 creare un insieme contenente un singolo semaforo, per il quale poi useremo un
2568 valore unitario per segnalare la disponibilità della risorsa, ed un valore
2569 nullo per segnalarne l'indisponibilità. 
2570
2571 \begin{figure}[!bht]
2572   \footnotesize \centering
2573   \begin{minipage}[c]{15cm}
2574     \begin{lstlisting}{} 
2575 /* Function MutexCreate: create a mutex/semaphore */
2576 int MutexCreate(key_t ipc_key) 
2577 {
2578     const union semun semunion={1};             /* semaphore union structure */
2579     int sem_id, ret;
2580     sem_id = semget(ipc_key, 1, IPC_CREAT|0666);         /* get semaphore ID */
2581     if (sem_id == -1) {                              /* if error return code */
2582         return sem_id;
2583     }
2584     ret = semctl(sem_id, 0, SETVAL, semunion);             /* init semaphore */
2585     if (ret == -1) {
2586         return ret;
2587     }
2588     return sem_id;
2589 }
2590 /* Function MutexFind: get the semaphore/mutex Id given the IPC key value */
2591 int MutexFind(key_t ipc_key) 
2592 {
2593     return semget(ipc_key,1,0);
2594 }
2595 /* Function MutexRead: read the current value of the mutex/semaphore */
2596 int MutexRead(int sem_id) 
2597 {
2598     return semctl(sem_id, 0, GETVAL);
2599 }
2600 /* Define sembuf structures to lock and unlock the semaphore  */
2601 struct sembuf sem_lock={                                /* to lock semaphore */
2602     0,                                   /* semaphore number (only one so 0) */
2603     -1,                                    /* operation (-1 to use resource) */
2604     SEM_UNDO};                                /* flag (set for undo at exit) */
2605 struct sembuf sem_ulock={                             /* to unlock semaphore */
2606     0,                                   /* semaphore number (only one so 0) */
2607     1,                                  /* operation (1 to release resource) */
2608     SEM_UNDO};                                      /* flag (in this case 0) */
2609 /* Function MutexLock: to lock a mutex/semaphore */
2610 int MutexLock(int sem_id) 
2611 {
2612     return semop(sem_id, &sem_lock, 1);
2613 }
2614 /* Function MutexUnlock: to unlock a mutex/semaphore */
2615 int MutexUnlock(int sem_id) 
2616 {
2617     return semop(sem_id, &sem_ulock, 1);
2618 }
2619 /* Function MutexRemove: remove a mutex/semaphore */
2620 int MutexRemove(int sem_id) 
2621 {
2622     return semctl(sem_id, 0, IPC_RMID);
2623 }
2624     \end{lstlisting}
2625   \end{minipage} 
2626   \normalsize 
2627   \caption{Il codice delle funzioni che permettono di creare o recuperare
2628     l'identificatore di un semaforo da utilizzare come \textit{mutex}.}
2629   \label{fig:ipc_mutex_create}
2630 \end{figure}
2631
2632 La prima funzione (\texttt{\small 2--15}) è \func{MutexCreate} che data una
2633 chiave crea il semaforo usato per il mutex e lo inizializza, restituendone
2634 l'identificatore. Il primo passo (\texttt{\small 6}) è chiamare \func{semget}
2635 con \const{IPC\_CREATE} per creare il semaforo qualora non esista,
2636 assegnandogli i privilegi di lettura e scrittura per tutti. In caso di errore
2637 (\texttt{\small 7--9}) si ritorna subito il risultato di \func{semget},
2638 altrimenti (\texttt{\small 10}) si inizializza il semaforo chiamando
2639 \func{semctl} con il comando \const{SETVAL}, utilizzando l'unione
2640 \struct{semunion} dichiarata ed avvalorata in precedenza (\texttt{\small 4})
2641 ad 1 per significare che risorsa è libera. In caso di errore (\texttt{\small
2642   11--13}) si restituisce il valore di ritorno di \func{semctl}, altrimenti
2643 (\texttt{\small 14}) si ritorna l'identificatore del semaforo.
2644
2645 La seconda funzione (\texttt{\small 17--20}) è \func{MutexFind}, che, data una
2646 chiave, restituisce l'identificatore del semaforo ad essa associato. La
2647 comprensione del suo funzionamento è immediata in quanto essa è soltanto un
2648 \textit{wrapper}\footnote{si chiama così una funzione usata per fare da
2649   \textsl{involucro} alla chiamata di un altra, usata in genere per
2650   semplificare un'interfaccia (come in questo caso) o per utilizzare con la
2651   stessa funzione diversi substrati (librerie, ecc.)  che possono fornire le
2652   stesse funzionalità.} di una chiamata a \func{semget} per cercare
2653 l'identificatore associato alla chiave, il valore di ritorno di quest'ultima
2654 viene passato all'indietro al chiamante.
2655
2656 La terza funzione (\texttt{\small 22--25}) è \func{MutexRead} che, dato un
2657 identificatore, restituisce il valore del semaforo associato al mutex. Anche
2658 in questo caso la funzione è un \textit{wrapper} per una chiamata a
2659 \func{semctl} con il comando \const{GETVAL}, che permette di restituire il
2660 valore del semaforo.
2661
2662 La quarta e la quinta funzione (\texttt{\small 36--44}) sono \func{MutexLock},
2663 e \func{MutexUnlock}, che permettono rispettivamente di bloccare e sbloccare
2664 il mutex. Entrambe fanno da wrapper per \func{semop}, utilizzando le due
2665 strutture \var{sem\_lock} e \var{sem\_unlock} definite in precedenza
2666 (\texttt{\small 27--34}). Si noti come per queste ultime si sia fatto uso
2667 dell'opzione \const{SEM\_UNDO} per evitare che il semaforo resti bloccato in
2668 caso di terminazione imprevista del processo.
2669
2670 L'ultima funzione (\texttt{\small 46--49}) della serie, è \func{MutexRemove},
2671 che rimuove il mutex. Anche in questo caso si ha un wrapper per una chiamata a
2672 \func{semctl} con il comando \const{IPC\_RMID}, che permette di cancellare il
2673 semaforo; il valore di ritorno di quest'ultima viene passato all'indietro.
2674
2675 Chiamare \func{MutexLock} decrementa il valore del semaforo: se questo è
2676 libero (ha già valore 1) sarà bloccato (valore nullo), se è bloccato la
2677 chiamata a \func{semop} si bloccherà fintanto che la risorsa non venga
2678 rilasciata. Chiamando \func{MutexUnlock} il valore del semaforo sarà
2679 incrementato di uno, sbloccandolo qualora fosse bloccato.  
2680
2681 Si noti che occorre eseguire sempre prima \func{MutexLock} e poi
2682 \func{MutexUnlock}, perché se per un qualche errore si esegue più volte
2683 quest'ultima il valore del semaforo crescerebbe oltre 1, e \func{MutexLock}
2684 non avrebbe più l'effetto aspettato (bloccare la risorsa quando questa è
2685 considerata libera).  Infine si tenga presente che usare \func{MutexRead} per
2686 controllare il valore dei mutex prima di proseguire in una operazione di
2687 sblocco non servirebbe comunque, dato che l'operazione non sarebbe atomica.
2688 Vedremo in \secref{sec:ipc_lock_file} come sia possibile ottenere
2689 un'interfaccia analoga a quella appena illustrata, senza incorrere in questi
2690 problemi, usando il file locking\index{file!locking}.
2691
2692
2693 \subsection{Memoria condivisa}
2694 \label{sec:ipc_sysv_shm}
2695
2696 Il terzo oggetto introdotto dal \textit{SysV IPC} è quello dei segmenti di
2697 memoria condivisa. La funzione che permette di ottenerne uno è \funcd{shmget},
2698 ed il suo prototipo è:
2699 \begin{functions}
2700   \headdecl{sys/types.h} 
2701   \headdecl{sys/ipc.h} 
2702   \headdecl{sys/shm.h}
2703   
2704   \funcdecl{int shmget(key\_t key, int size, int flag)}
2705   
2706   Restituisce l'identificatore di una memoria condivisa.
2707   
2708   \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
2709     in caso di errore, nel qual caso \var{errno} assumerà i valori:
2710     \begin{errlist}
2711     \item[\errcode{ENOSPC}] Si è superato il limite (\const{SHMMNI}) sul numero
2712       di segmenti di memoria nel sistema, o cercato di allocare un segmento le
2713       cui dimensioni fanno superare il limite di sistema (\const{SHMALL}) per
2714       la memoria ad essi riservata.
2715     \item[\errcode{EINVAL}] Si è richiesta una dimensione per un nuovo segmento
2716       maggiore di \const{SHMMAX} o minore di \const{SHMMIN}, o se il segmento
2717       già esiste \param{size} è maggiore delle sue dimensioni.
2718     \item[\errcode{ENOMEM}] Il sistema non ha abbastanza memoria per poter
2719       contenere le strutture per un nuovo segmento di memoria condivisa.
2720     \end{errlist}
2721     ed inoltre \errval{EACCES}, \errval{ENOENT}, \errval{EEXIST},
2722     \errval{EIDRM}, con lo stesso significato che hanno per \func{msgget}.}
2723 \end{functions}
2724
2725 La funzione, come \func{semget}, è del tutto analoga a \func{msgget}, ed
2726 identico è l'uso degli argomenti \param{key} e \param{flag} per cui non
2727 ripeteremo quanto detto al proposito in \secref{sec:ipc_sysv_mq}. L'argomento
2728 \param{size} specifica invece la dimensione, in byte, del segmento, che viene
2729 comunque arrotondata al multiplo superiore di \const{PAGE\_SIZE}.
2730
2731 La memoria condivisa è la forma più veloce di comunicazione fra due processi,
2732 in quanto permette agli stessi di vedere nel loro spazio di indirizzi una
2733 stessa sezione di memoria.  Pertanto non è necessaria nessuna operazione di
2734 copia per trasmettere i dati da un processo all'altro, in quanto ciascuno può
2735 accedervi direttamente con le normali operazioni di lettura e scrittura dei
2736 dati in memoria.
2737
2738 Ovviamente tutto questo ha un prezzo, ed il problema fondamentale della
2739 memoria condivisa è la sincronizzazione degli accessi. È evidente infatti che
2740 se un processo deve scambiare dei dati con un altro, si deve essere sicuri che
2741 quest'ultimo non acceda al segmento di memoria condivisa prima che il primo
2742 non abbia completato le operazioni di scrittura, inoltre nel corso di una
2743 lettura si deve essere sicuri che i dati restano coerenti e non vengono
2744 sovrascritti da un accesso in scrittura sullo stesso segmento da parte di un
2745 altro processo. Per questo in genere la memoria condivisa viene sempre
2746 utilizzata in abbinamento ad un meccanismo di sincronizzazione, il che, di
2747 norma, significa insieme a dei semafori.
2748
2749 \begin{figure}[!htb]
2750   \footnotesize \centering
2751   \begin{minipage}[c]{15cm}
2752     \begin{lstlisting}[labelstep=0]{}
2753 struct shmid_ds {
2754      struct    ipc_perm shm_perm;  /* operation perms */
2755      int  shm_segsz;               /* size of segment (bytes) */
2756      time_t    shm_atime;          /* last attach time */
2757      time_t    shm_dtime;          /* last detach time */
2758      time_t    shm_ctime;          /* last change time */
2759      unsigned short shm_cpid;      /* pid of creator */
2760      unsigned short shm_lpid;      /* pid of last operator */
2761      short     shm_nattch;         /* no. of current attaches */
2762 };
2763     \end{lstlisting}
2764   \end{minipage} 
2765   \normalsize 
2766   \caption{La struttura \structd{shmid\_ds}, associata a ciascun segmento di
2767     memoria condivisa.}
2768   \label{fig:ipc_shmid_ds}
2769 \end{figure}
2770
2771 A ciascun segmento di memoria condivisa è associata una struttura
2772 \struct{shmid\_ds}, riportata in \figref{fig:ipc_shmid_ds}.  Come nel caso
2773 delle code di messaggi quando si crea un nuovo segmento di memoria condivisa
2774 con \func{shmget} questa struttura viene inizializzata, in particolare il
2775 campo \var{shm\_perm} viene inizializzato come illustrato in
2776 \secref{sec:ipc_sysv_access_control}, e valgono le considerazioni ivi fatte
2777 relativamente ai permessi di accesso; per quanto riguarda gli altri campi
2778 invece:
2779 \begin{itemize*}
2780 \item il campo \var{shm\_segsz}, che esprime la dimensione del segmento, viene
2781   inizializzato al valore di \param{size}.
2782 \item il campo \var{shm\_ctime}, che esprime il tempo di creazione del
2783   segmento, viene inizializzato al tempo corrente.
2784 \item i campi \var{shm\_atime} e \var{shm\_dtime}, che esprimono
2785   rispettivamente il tempo dell'ultima volta che il segmento è stato
2786   agganciato o sganciato da un processo, vengono inizializzati a zero.
2787 \item il campo \var{shm\_lpid}, che esprime il \acr{pid} del processo che ha
2788   eseguito l'ultima operazione, viene inizializzato a zero.
2789 \item il campo \var{shm\_cpid}, che esprime il \acr{pid} del processo che ha
2790   creato il segmento, viene inizializzato al \acr{pid} del processo chiamante.
2791 \item il campo \var{shm\_nattac}, che esprime il numero di processi agganciati
2792   al segmento viene inizializzato a zero.
2793 \end{itemize*}
2794
2795 Come per le code di messaggi e gli insiemi di semafori, anche per i segmenti
2796 di memoria condivisa esistono una serie di limiti imposti dal sistema.  Alcuni
2797 di questi limiti sono al solito accessibili e modificabili attraverso
2798 \func{sysctl} o scrivendo direttamente nei rispettivi file di
2799 \file{/proc/sys/kernel/}. 
2800
2801 In \tabref{tab:ipc_shm_limits} si sono riportate le
2802 costanti simboliche associate a ciascuno di essi, il loro significato, i
2803 valori preimpostati, e, quando presente, il file in \file{/proc/sys/kernel/}
2804 che permettono di cambiarne il valore. 
2805
2806
2807 \begin{table}[htb]
2808   \footnotesize
2809   \centering
2810   \begin{tabular}[c]{|c|r|c|p{7cm}|}
2811     \hline
2812     \textbf{Costante} & \textbf{Valore} & \textbf{File in \texttt{proc}}
2813     & \textbf{Significato} \\
2814     \hline
2815     \hline
2816     \const{SHMALL}& 0x200000&\file{shmall}& Numero massimo di pagine che 
2817                                        possono essere usate per i segmenti di
2818                                        memoria condivisa. \\
2819     \const{SHMMAX}&0x2000000&\file{shmmax}& Dimensione massima di un segmento 
2820                                             di memoria condivisa.\\
2821     \const{SHMMNI}&     4096&\file{msgmni}& Numero massimo di segmenti di 
2822                                             memoria condivisa presenti nel
2823                                             kernel.\\ 
2824     \const{SHMMIN}&        1& ---         & Dimensione minima di un segmento di
2825                                             memoria condivisa. \\
2826     \const{SHMLBA}&\const{PAGE\_SIZE}&--- & Limite inferiore per le dimensioni
2827                                             minime di un segmento (deve essere
2828                                             allineato alle dimensioni di una
2829                                             pagina di memoria). \\
2830     \const{SHMSEG}&   ---   &     ---     & Numero massimo di segmenti di
2831                                             memoria condivisa 
2832                                             per ciascun processo.\\
2833
2834
2835     \hline
2836   \end{tabular}
2837   \caption{Valori delle costanti associate ai limiti dei segmenti di memoria
2838     condivisa, insieme al relativo file in \file{/proc/sys/kernel/} ed al
2839     valore preimpostato presente nel sistema.} 
2840   \label{tab:ipc_shm_limits}
2841 \end{table}
2842
2843 Al solito la funzione che permette di effettuare le operazioni di controllo su
2844 un segmento di memoria condivisa è \funcd{shmctl}; il suo prototipo è:
2845 \begin{functions}
2846   \headdecl{sys/ipc.h} 
2847   \headdecl{sys/shm.h}
2848   
2849   \funcdecl{int shmctl(int shmid, int cmd, struct shmid\_ds *buf)}
2850   
2851   Esegue le operazioni di controllo su un segmento di memoria condivisa.
2852   
2853   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
2854     errore, nel qual caso \var{errno} assumerà i valori:
2855     \begin{errlist}
2856     \item[\errcode{EACCES}] Si è richiesto \const{IPC\_STAT} ma i permessi non
2857       consentono l'accesso in lettura al segmento.
2858     \item[\errcode{EINVAL}] O \param{shmid} non è un identificatore valido o
2859       \param{cmd} non è un comando valido.
2860     \item[\errcode{EIDRM}] L'argomento \param{shmid} fa riferimento ad un
2861       segmento che è stato cancellato.
2862     \item[\errcode{EPERM}] Si è specificato un comando con \const{IPC\_SET} o
2863       \const{IPC\_RMID} senza i permessi necessari.
2864     \item[\errcode{EOVERFLOW}] Si è tentato il comando \const{IPC\_STAT} ma il
2865       valore del group-ID o dell'user-ID è troppo grande per essere
2866       memorizzato nella struttura puntata dal \param{buf}.  
2867     \item[\errcode{EFAULT}] L'indirizzo specificato con \param{buf} non è
2868       valido.
2869     \end{errlist}
2870 }
2871 \end{functions}
2872
2873 Il comando specificato attraverso l'argomento \param{cmd} determina i diversi
2874 effetti della funzione; i possibili valori che esso può assumere, ed il
2875 corrispondente comportamento della funzione, sono i seguenti:
2876
2877 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
2878 \item[\const{IPC\_STAT}] Legge le informazioni riguardo il segmento di memoria
2879   condivisa nella struttura \struct{shmid\_ds} puntata da \param{buf}. Occorre
2880   che il processo chiamante abbia il permesso di lettura sulla segmento.
2881 \item[\const{IPC\_RMID}] Marca il segmento di memoria condivisa per la
2882   rimozione, questo verrà cancellato effettivamente solo quando l'ultimo
2883   processo ad esso agganciato si sarà staccato. Questo comando può essere
2884   eseguito solo da un processo con user-ID effettivo corrispondente o al
2885   creatore del segmento, o al proprietario del segmento, o all'amministratore.
2886 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
2887   del segmento.  Per modificare i valori di \var{shm\_perm.mode},
2888   \var{shm\_perm.uid} e \var{shm\_perm.gid} occorre essere il proprietario o
2889   il creatore del segmento, oppure l'amministratore. Compiuta l'operazione
2890   aggiorna anche il valore del campo \var{shm\_ctime}.
2891 \item[\const{SHM\_LOCK}] Abilita il  
2892   \textit{memory locking}\index{memory locking}\footnote{impedisce cioè che la
2893     memoria usata per il segmento venga salvata su disco dal meccanismo della
2894     memoria virtuale\index{memoria virtuale}; si ricordi quanto trattato in
2895     \secref{sec:proc_mem_lock}.} sul segmento di memoria condivisa. Solo
2896   l'amministratore può utilizzare questo comando.
2897 \item[\const{SHM\_UNLOCK}] Disabilita il \textit{memory locking} sul segmento
2898   di memoria condivisa. Solo l'amministratore può utilizzare questo comando.
2899 \end{basedescript}
2900 i primi tre comandi sono gli stessi già visti anche per le code di messaggi e
2901 gli insiemi di semafori, gli ultimi due sono delle estensioni specifiche
2902 previste da Linux, che permettono di abilitare e disabilitare il meccanismo
2903 della memoria virtuale\index{memoria virtuale} per il segmento.
2904
2905 L'argomento \param{buf} viene utilizzato solo con i comandi \const{IPC\_STAT}
2906 e \const{IPC\_SET} nel qual caso esso dovrà puntare ad una struttura
2907 \struct{shmid\_ds} precedentemente allocata, in cui nel primo caso saranno
2908 scritti i dati del segmento di memoria restituiti dalla funzione e da cui, nel
2909 secondo caso, verranno letti i dati da impostare sul segmento.
2910
2911 Una volta che lo si è creato, per utilizzare un segmento di memoria condivisa
2912 l'interfaccia prevede due funzioni, \funcd{shmat} e \func{shmdt}. La prima di
2913 queste serve ad agganciare un segmento al processo chiamante, in modo che
2914 quest'ultimo possa inserirlo nel suo spazio di indirizzi per potervi accedere;
2915 il suo prototipo è:
2916 \begin{functions}
2917   \headdecl{sys/types.h} 
2918   \headdecl{sys/shm.h}
2919   
2920   \funcdecl{void *shmat(int shmid, const void *shmaddr, int shmflg)}
2921   Aggancia al processo un segmento di memoria condivisa.
2922   
2923   \bodydesc{La funzione restituisce l'indirizzo del segmento in caso di
2924     successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà i
2925     valori:
2926     \begin{errlist}
2927     \item[\errcode{EACCES}] Il processo non ha i privilegi per accedere al
2928       segmento nella modalità richiesta.
2929     \item[\errcode{EINVAL}] Si è specificato un identificatore invalido per
2930       \param{shmid}, o un indirizzo non allineato sul confine di una pagina
2931       per \param{shmaddr}.
2932     \end{errlist}
2933     ed inoltre \errval{ENOMEM}.}
2934 \end{functions}
2935
2936 La funzione inserisce un segmento di memoria condivisa all'interno dello
2937 spazio di indirizzi del processo, in modo che questo possa accedervi
2938 direttamente, la situazione dopo l'esecuzione di \func{shmat} è illustrata in
2939 \figref{fig:ipc_shmem_layout} (per la comprensione del resto dello schema si
2940 ricordi quanto illustrato al proposito in \secref{sec:proc_mem_layout}). In
2941 particolare l'indirizzo finale del segmento dati (quello impostato da
2942 \func{brk}, vedi \secref{sec:proc_mem_sbrk}) non viene influenzato. Si tenga
2943 presente infine che la funzione ha successo anche se il segmento è stato
2944 marcato per la cancellazione.
2945
2946 \begin{figure}[htb]
2947   \centering
2948   \includegraphics[height=10cm]{img/sh_memory_layout}
2949   \caption{Disposizione dei segmenti di memoria di un processo quando si è
2950     agganciato un segmento di memoria condivisa.}
2951   \label{fig:ipc_shmem_layout}
2952 \end{figure}
2953
2954 L'argomento \param{shmaddr} specifica a quale indirizzo\footnote{Lo standard
2955   SVID prevede che l'argomento \param{shmaddr} sia di tipo \ctyp{char *}, così
2956   come il valore di ritorno della funzione. In Linux è stato così con le
2957   \acr{libc4} e le \acr{libc5}, con il passaggio alle \acr{glibc} il tipo di
2958   \param{shmaddr} è divenuto un \ctyp{const void *} e quello del valore di
2959   ritorno un \ctyp{void *}.} deve essere associato il segmento, se il valore
2960 specificato è \val{NULL} è il sistema a scegliere opportunamente un'area di
2961 memoria libera (questo è il modo più portabile e sicuro di usare la funzione).
2962 Altrimenti il kernel aggancia il segmento all'indirizzo specificato da
2963 \param{shmaddr}; questo però può avvenire solo se l'indirizzo coincide con il
2964 limite di una pagina, cioè se è un multiplo esatto del parametro di sistema
2965 \const{SHMLBA}, che in Linux è sempre uguale \const{PAGE\_SIZE}. 
2966
2967 Si tenga presente però che quando si usa \val{NULL} come valore di
2968 \param{shmaddr}, l'indirizzo restituito da \func{shmat} può cambiare da
2969 processo a processo; pertanto se nell'area di memoria condivisa si salvano
2970 anche degli indirizzi, si deve avere cura di usare valori relativi (in genere
2971 riferiti all'indirizzo di partenza del segmento).
2972
2973 L'argomento \param{shmflg} permette di cambiare il comportamento della
2974 funzione; esso va specificato come maschera binaria, i bit utilizzati sono
2975 solo due e sono identificati dalle costanti \const{SHM\_RND} e
2976 \const{SHM\_RDONLY}, che vanno combinate con un OR aritmetico.  Specificando
2977 \const{SHM\_RND} si evita che \func{shmat} ritorni un errore quando
2978 \param{shmaddr} non è allineato ai confini di una pagina. Si può quindi usare
2979 un valore qualunque per \param{shmaddr}, e il segmento verrà comunque
2980 agganciato, ma al più vicino multiplo di \const{SHMLBA} (il nome della
2981 costante sta infatti per \textit{rounded}, e serve per specificare un
2982 indirizzo come arrotondamento, in Linux è equivalente a \const{PAGE\_SIZE}).
2983
2984 L'uso di \const{SHM\_RDONLY} permette di agganciare il segmento in sola
2985 lettura (si ricordi che anche le pagine di memoria hanno dei permessi), in tal
2986 caso un tentativo di scrivere sul segmento comporterà una violazione di
2987 accesso con l'emissione di un segnale di \const{SIGSEGV}. Il comportamento
2988 usuale di \func{shmat} è quello di agganciare il segmento con l'accesso in
2989 lettura e scrittura (ed il processo deve aver questi permessi in
2990 \var{shm\_perm}), non è prevista la possibilità di agganciare un segmento in
2991 sola scrittura.
2992
2993 In caso di successo la funzione aggiorna anche i seguenti campi di
2994 \struct{shmid\_ds}:
2995 \begin{itemize*}
2996 \item il tempo \var{shm\_atime} dell'ultima operazione di aggancio viene
2997   impostato al tempo corrente.
2998 \item il \acr{pid} \var{shm\_lpid} dell'ultimo processo che ha operato sul
2999   segmento viene impostato a quello del processo corrente.
3000 \item il numero \var{shm\_nattch} di processi agganciati al segmento viene
3001   aumentato di uno.
3002 \end{itemize*} 
3003
3004 Come accennato in \secref{sec:proc_fork} un segmento di memoria condivisa
3005 agganciato ad un processo viene ereditato da un figlio attraverso una
3006 \func{fork}, dato che quest'ultimo riceve una copia dello spazio degli
3007 indirizzi del padre. Invece, dato che attraverso una \func{exec} viene
3008 eseguito un diverso programma con uno spazio di indirizzi completamente
3009 diverso, tutti i segmenti agganciati al processo originario vengono
3010 automaticamente sganciati. Lo stesso avviene all'uscita del processo
3011 attraverso una \func{exit}.
3012
3013 Una volta che un segmento di memoria condivisa non serve più, si può
3014 sganciarlo esplicitamente dal processo usando l'altra funzione
3015 dell'interfaccia, \funcd{shmdt}, il cui prototipo è:
3016 \begin{functions}
3017   \headdecl{sys/types.h} 
3018   \headdecl{sys/shm.h}
3019
3020   \funcdecl{int shmdt(const void *shmaddr)}
3021   Sgancia dal processo un segmento di memoria condivisa.
3022   
3023   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
3024     errore, la funzione fallisce solo quando non c'è un segmento agganciato
3025     all'indirizzo \func{shmaddr}, con \var{errno} che assume il valore
3026     \errval{EINVAL}.}
3027 \end{functions}
3028
3029 La funzione sgancia dallo spazio degli indirizzi del processo un segmento di
3030 memoria condivisa; questo viene identificato con l'indirizzo \param{shmaddr}
3031 restituito dalla precedente chiamata a \func{shmat} con il quale era stato
3032 agganciato al processo.
3033
3034 In caso di successo la funzione aggiorna anche i seguenti campi di
3035 \struct{shmid\_ds}:
3036 \begin{itemize*}
3037 \item il tempo \var{shm\_dtime} dell'ultima operazione di sganciamento viene
3038   impostato al tempo corrente.
3039 \item il \acr{pid} \var{shm\_lpid} dell'ultimo processo che ha operato sul
3040   segmento viene impostato a quello del processo corrente.
3041 \item il numero \var{shm\_nattch} di processi agganciati al segmento viene
3042   decrementato di uno.
3043 \end{itemize*} 
3044 inoltre la regione di indirizzi usata per il segmento di memoria condivisa
3045 viene tolta dallo spazio di indirizzi del processo.
3046
3047 Benché la memoria condivisa costituisca il meccanismo di intercomunicazione
3048 fra processi più veloce, essa non è sempre il più appropriato, dato che, come
3049 abbiamo visto, si avrà comunque la necessità di una sincronizzazione degli
3050 accessi.  Per questo motivo, quando la comunicazione fra processi è
3051 sequenziale, altri meccanismi come le pipe, le fifo o i socket, che non
3052 necessitano di sincronizzazione esplicita, sono da preferire. Essa diventa
3053 l'unico meccanismo possibile quando la comunicazione non è
3054 sequenziale\footnote{come accennato in \secref{sec:ipc_sysv_mq} per la
3055   comunicazione non sequenziale si possono usare le code di messaggi,
3056   attraverso l'uso del campo \var{mtype}, ma solo se quest'ultima può essere
3057   effettuata in forma di messaggio.} o quando non può avvenire secondo una
3058 modalità predefinita.
3059
3060 Un esempio classico di uso della memoria condivisa è quello del
3061 ``\textit{monitor}'', in cui viene per scambiare informazioni fra un processo
3062 server, che vi scrive dei dati di interesse generale che ha ottenuto, e i
3063 processi client interessati agli stessi dati che così possono leggerli in
3064 maniera completamente asincrona.  Con questo schema di funzionamento da una
3065 parte si evita che ciascun processo client debba compiere l'operazione,
3066 potenzialmente onerosa, di ricavare e trattare i dati, e dall'altra si evita
3067 al processo server di dover gestire l'invio a tutti i client di tutti i dati
3068 (non potendo il server sapere quali di essi servono effettivamente al singolo
3069 client).
3070
3071 Nel nostro caso implementeremo un ``\textsl{monitor}'' di una directory: un
3072 processo si incaricherà di tenere sotto controllo alcuni parametri relativi ad
3073 una directory (il numero dei file contenuti, la dimensione totale, quante
3074 directory, link simbolici, file normali, ecc.) che saranno salvati in un
3075 segmento di memoria condivisa cui altri processi potranno accedere per
3076 ricavare la parte di informazione che interessa.
3077
3078 In \figref{fig:ipc_dirmonitor_main} si è riportata la sezione principale del
3079 corpo del programma server, insieme alle definizioni delle altre funzioni
3080 usate nel programma e delle variabili globali, omettendo tutto quello che
3081 riguarda la gestione delle opzioni e la stampa delle istruzioni di uso a
3082 video; al solito il codice completo si trova con i sorgenti allegati nel file
3083 \file{DirMonitor.c}.
3084
3085 \begin{figure}[!htb]
3086   \footnotesize \centering
3087   \begin{minipage}[c]{15cm}
3088     \begin{lstlisting}{} 
3089 /* global variables for shared memory segment */
3090 struct DirProp {
3091     int tot_size;    
3092     int tot_files;   
3093     int tot_regular; 
3094     int tot_fifo;    
3095     int tot_link;    
3096     int tot_dir;     
3097     int tot_block;   
3098     int tot_char;    
3099     int tot_sock;
3100 } *shmptr;
3101 int shmid; 
3102 int mutex;
3103 /* main body */
3104 int main(int argc, char *argv[]) 
3105 {
3106     int i;
3107     key_t key;
3108     ...
3109     if ((argc - optind) != 1) {          /* There must be remaing parameters */
3110         printf("Wrong number of arguments %d\n", argc - optind);
3111         usage();
3112     }
3113     if (chdir(argv[1])) {                      /* chdir to be sure dir exist */
3114         perror("Cannot find directory to monitor");
3115     }
3116     Signal(SIGTERM, HandSIGTERM);            /* set handlers for termination */
3117     Signal(SIGINT, HandSIGTERM);
3118     Signal(SIGQUIT, HandSIGTERM);
3119     key = ftok("~/gapil/sources/DirMonitor.c", 1);           /* define a key */
3120     shmid = shmget(key, 4096, IPC_CREAT|0666);        /* get a shared memory */
3121     if (shmid < 0) {
3122         perror("Cannot create shared memory");
3123         exit(1);
3124     }
3125     if ( (shmptr = shmat(shmid, NULL, 0)) == NULL ) {   /* attach to process */
3126         perror("Cannot attach segment");
3127         exit(1);
3128     }
3129     if ((mutex = MutexCreate(key)) == -1) {                   /* get a Mutex */
3130         perror("Cannot create mutex");
3131         exit(1);
3132     }
3133     /* main loop, monitor directory properties each 10 sec */
3134     daemon(1, 0);              /* demonize process, staying in monitored dir */
3135     while (1) {
3136         MutexLock(mutex);                              /* lock shared memory */
3137         memset(shmptr, 0, sizeof(struct DirProp));    /* erase previous data */
3138         DirScan(argv[1], ComputeValues);                     /* execute scan */
3139         MutexUnlock(mutex);                          /* unlock shared memory */
3140         sleep(pause);                              /* sleep until next watch */
3141     }
3142 }
3143     \end{lstlisting}
3144   \end{minipage} 
3145   \normalsize 
3146   \caption{Codice della funzione principale del programma \file{DirMonitor.c}.}
3147   \label{fig:ipc_dirmonitor_main}
3148 \end{figure}
3149
3150 Il programma usa delle variabili globali (\texttt{\small 2--14}) per mantenere
3151 i valori relativi agli oggetti usati per la comunicazione inter-processo; si è
3152 definita inoltre una apposita struttura \struct{DirProp} che contiene i dati
3153 relativi alle proprietà che si vogliono mantenere nella memoria condivisa, per
3154 l'accesso da parte dei client.
3155
3156 Il programma, dopo la sezione, omessa, relativa alla gestione delle opzioni da
3157 riga di comando (che si limitano alla eventuale stampa di un messaggio di
3158 aiuto a video ed all'impostazione della durata dell'intervallo con cui viene
3159 ripetuto il calcolo delle proprietà della directory) controlla (\texttt{\small
3160   21--24}) che sia stato specificato il parametro necessario contenente il
3161 nome della directory da tenere sotto controllo, senza il quale esce
3162 immediatamente con un messaggio di errore.
3163
3164 Poi, per verificare che il parametro specifichi effettivamente una directory,
3165 si esegue (\texttt{\small 25--27}) su di esso una \func{chdir}, uscendo
3166 immediatamente in caso di errore.  Questa funzione serve anche per impostare
3167 la directory di lavoro del programma nella directory da tenere sotto
3168 controllo, in vista del successivo uso della funzione
3169 \func{daemon}.\footnote{Si noti come si è potuta fare questa scelta,
3170   nonostante le indicazioni illustrate in \secref{sec:sess_daemon}, per il
3171   particolare scopo del programma, che necessita comunque di restare
3172   all'interno di una directory.} Infine (\texttt{\small 28--30}) si installano
3173 i gestori per i vari segnali di terminazione che, avendo a che fare con un
3174 programma che deve essere eseguito come server, sono il solo strumento
3175 disponibile per concluderne l'esecuzione.
3176
3177 Il passo successivo (\texttt{\small 31--44}) è quello di creare gli oggetti di
3178 intercomunicazione necessari. Si inizia costruendo (\texttt{\small 31}) la
3179 chiave da usare come riferimento con il nome del programma,\footnote{si è
3180   usato un riferimento relativo alla home dell'utente, supposto che i sorgenti
3181   di GaPiL siano stati installati direttamente in essa. Qualora si effettui
3182   una installazione diversa si dovrà correggere il programma.} dopo di che si
3183 richiede (\texttt{\small 32}) la creazione di un segmento di memoria condivisa
3184 con \func{shmget} (una pagina di memoria è sufficiente per i dati che
3185 useremo), uscendo (\texttt{\small 33--36}) qualora la creazione non abbia
3186 successo.
3187
3188 Una volta ottenutone l'identificatore in \var{shmid}, si può agganciare
3189 (\texttt{\small 37--40}) il segmento al processo con \func{shmat} anche in
3190 questo caso si esce qualora la funzione non abbia successo. Con l'indirizzo
3191 \var{shmptr} così ottenuto potremo poi accedere alla memoria condivisa, che,
3192 per come abbiamo lo abbiamo definito, sarà vista nella forma data da
3193 \struct{DirProp}. Infine (\texttt{\small 41--44}) utilizzando sempre la stessa
3194 chiave, si crea, tramite le funzioni di interfaccia già descritte in
3195 \secref{sec:ipc_sysv_sem}, anche un mutex, che utilizzeremo per regolare
3196 l'accesso alla memoria condivisa.
3197
3198 Una volta completata l'inizializzazione e la creazione degli oggetti di
3199 intercomunicazione il programma entra nel ciclo principale (\texttt{\small
3200   45--54}) dove vengono eseguite indefinitamente le attività di monitoraggio.
3201 Il primo passo (\texttt{\small 46}) è eseguire \func{daemon} per proseguire con
3202 l'esecuzione in background come si conviene ad un programma demone; si noti
3203 che si è mantenuta, usando un valore non nullo del primo argomento, la
3204 directory di lavoro corrente.
3205
3206 Una volta che il programma è andato in background l'esecuzione prosegue
3207 (\texttt{\small 47--53}) all'interno di un ciclo infinito: si inizia
3208 (\texttt{\small 48}) bloccando il mutex con \func{MutexLock} per poter
3209 accedere alla memoria condivisa (la funzione si bloccherà automaticamente se
3210 qualche client sta leggendo), poi (\texttt{\small 49}) si cancellano i valori
3211 precedentemente immagazzinati nella memoria condivisa con \func{memset}, e si
3212 esegue (\texttt{\small 50}) un nuovo calcolo degli stessi utilizzando la
3213 funzione \func{DirScan}; infine (\texttt{\small 51}) si sblocca il mutex con
3214 \func{MutexUnlock}, e si attende (\texttt{\small 52}) per il periodo di tempo
3215 specificato a riga di comando con l'opzione \code{-p} con una \func{sleep}.
3216
3217 \begin{figure}[!htb]
3218   \footnotesize \centering
3219   \begin{minipage}[c]{15cm}
3220     \begin{lstlisting}{} 
3221 /* Routine  to compute directory properties inside DirScan */
3222 int ComputeValues(struct dirent * direntry) 
3223 {
3224     struct stat data;
3225     stat(direntry->d_name, &data);                          /* get stat data */
3226     shmptr->tot_size += data.st_size;
3227     shmptr->tot_files++;
3228     if (S_ISREG(data.st_mode)) shmptr->tot_regular++;
3229     if (S_ISFIFO(data.st_mode)) shmptr->tot_fifo++;
3230     if (S_ISLNK(data.st_mode)) shmptr->tot_link++;
3231     if (S_ISDIR(data.st_mode)) shmptr->tot_dir++;
3232     if (S_ISBLK(data.st_mode)) shmptr->tot_block++;
3233     if (S_ISCHR(data.st_mode)) shmptr->tot_char++;
3234     if (S_ISSOCK(data.st_mode)) shmptr->tot_sock++;
3235     return 0;
3236 }
3237 /* Signal Handler to manage termination */
3238 void HandSIGTERM(int signo) {
3239     MutexLock(mutex);
3240     if (shmdt(shmptr)) {
3241         perror("Error detaching shared memory");
3242         exit(1);
3243     }
3244     if (shmctl(shmid, IPC_RMID, NULL)) {
3245         perror("Cannot remove shared memory segment");
3246         exit(1);
3247     }
3248     MutexRemove(mutex);
3249     exit(0);
3250 }
3251     \end{lstlisting}
3252   \end{minipage} 
3253   \normalsize 
3254   \caption{Codice delle funzione ausiliarie usate da \file{DirMonitor.c}.}
3255   \label{fig:ipc_dirmonitor_sub}
3256 \end{figure}
3257
3258 Si noti come per il calcolo dei valori da mantenere nella memoria condivisa si
3259 sia usata ancora una volta la funzione \func{DirScan}, già utilizzata (e
3260 descritta in dettaglio) in \secref{sec:file_dir_read}, che ci permette di
3261 effettuare la scansione delle voci della directory, chiamando per ciascuna di
3262 esse la funzione \func{ComputeValues}, che esegue tutti i calcoli necessari.
3263
3264 Il codice di quest'ultima è riportato in \figref{fig:ipc_dirmonitor_sub}. Come
3265 si vede la funzione (\texttt{\small 2--16}) è molto semplice e si limita a
3266 chiamare (\texttt{\small 5}) la funzione \func{stat} sul file indicato da
3267 ciascuna voce, per ottenerne i dati, che poi utilizza per incrementare i vari
3268 contatori nella memoria condivisa, cui accede grazie alla variabile globale
3269 \var{shmptr}.
3270
3271 Dato che la funzione è chiamata da \func{DirScan}, si è all'interno del ciclo
3272 principale del programma, con un mutex acquisito, perciò non è necessario
3273 effettuare nessun controllo e si può accedere direttamente alla memoria
3274 condivisa usando \var{shmptr} per riempire i campi della struttura
3275 \struct{DirProp}; così prima (\texttt{\small 6--7}) si sommano le dimensioni
3276 dei file ed il loro numero, poi, utilizzando le macro di
3277 \tabref{tab:file_type_macro}, si contano (\texttt{\small 8--14}) quanti ce ne
3278 sono per ciascun tipo.
3279
3280 In \figref{fig:ipc_dirmonitor_sub} è riportato anche (\texttt{\small 17--30})
3281 il codice del gestore dei segnali di terminazione, usato per chiudere il
3282 programma. Esso, oltre a provocare l'uscita del programma, si incarica anche
3283 di cancellare tutti gli oggetti di intercomunicazione non più necessari.  Per
3284 questo anzitutto (\texttt{\small 19}) acquisisce il mutex con
3285 \func{MutexLock}, per evitare di operare mentre un client sta ancora leggendo
3286 i dati, dopo di che (\texttt{\small 20--23}) prima distacca il segmento di
3287 memoria condivisa con \func{shmad} e poi (\texttt{\small 24--27}) lo cancella
3288 con \func{shctl}.  Infine (\texttt{\small 28}) rimuove il mutex con
3289 \func{MutexRemove} ed esce.
3290
3291 \begin{figure}[!htb]
3292   \footnotesize \centering
3293   \begin{minipage}[c]{15cm}
3294     \begin{lstlisting}{} 
3295 int main(int argc, char *argv[]) 
3296 {
3297     int i;
3298     key_t key;
3299     ...
3300     /* create needed IPC objects */
3301     key = ftok("~/gapil/sources/DirMonitor.c", 1);           /* define a key */
3302     shmid = shmget(key, 4096, 0);                /* get the shared memory ID */
3303     if (shmid < 0) {
3304         perror("Cannot find shared memory");
3305         exit(1);
3306     }
3307     if ( (shmptr = shmat(shmid, NULL, 0)) == NULL ) {   /* attach to process */
3308         perror("Cannot attach segment");
3309         exit(1);
3310     }
3311     if ((mutex = MutexFind(key)) == -1) {                   /* get the Mutex */
3312         perror("Cannot find mutex");
3313         exit(1);
3314     }
3315     /* main loop */
3316     MutexLock(mutex);                                  /* lock shared memory */
3317     printf("Ci sono %d file dati\n", shmptr->tot_regular);
3318     printf("Ci sono %d directory\n", shmptr->tot_dir);
3319     printf("Ci sono %d link\n", shmptr->tot_link);
3320     printf("Ci sono %d fifo\n", shmptr->tot_fifo);
3321     printf("Ci sono %d socket\n", shmptr->tot_sock);
3322     printf("Ci sono %d device a caratteri\n", shmptr->tot_char);
3323     printf("Ci sono %d device a blocchi\n", shmptr->tot_block);
3324     printf("Totale  %d file, per %d byte\n",
3325            shmptr->tot_files, shmptr->tot_size);
3326     MutexUnlock(mutex);                              /* unlock shared memory */
3327 }
3328     \end{lstlisting}
3329   \end{minipage} 
3330   \normalsize 
3331   \caption{Codice del programma client del monitor delle proprietà di una
3332     directory, \file{ReadMonitor.c}.}
3333   \label{fig:ipc_dirmonitor_client}
3334 \end{figure}
3335
3336 Il codice del client, che permette di leggere le informazioni mantenute nella
3337 memoria condivisa, è riportato in \figref{fig:ipc_dirmonitor_client}. Al
3338 solito si è omessa la sezione di gestione delle opzioni e la funzione che
3339 stampa a video le istruzioni; il codice completo è nei sorgenti allegati, nel
3340 file \file{ReadMonitor.c}.
3341
3342 Una volta completata la gestione delle opzioni a riga di comando il programma
3343 rigenera (\texttt{\small 7}) con \func{ftok} la stessa chiave usata dal server
3344 per identificare il segmento di memoria condivisa ed il mutex, poi
3345 (\texttt{\small 8}) si richiede con \func{semget} l'identificatore della
3346 memoria condivisa, ma in questo caso si vuole che esso esista di già; al
3347 solito (\texttt{\small 9--12}) si esce in caso di errore. Una volta ottenuto
3348 l'identificatore in \var{shmid} si può (\texttt{\small 13--16}) agganciare il
3349 segmento al processo all'indirizzo \func{shmptr}; anche in questo caso si
3350 chiude immediatamente il programma se qualcosa non funziona.  Infine
3351 (\texttt{\small 17--20}) con \func{MutexFind} si richiede l'identificatore del
3352 mutex.
3353
3354 Una volta completata l'inizializzazione ed ottenuti i riferimenti agli oggetti
3355 di intercomunicazione necessari viene eseguito il corpo principale del
3356 programma (\texttt{\small 21--33}); si comincia (\texttt{\small 22})
3357 acquisendo il mutex con \func{MutexLock}; qui avviene il blocco del processo
3358 se la memoria condivisa non è disponibile.  Poi (\texttt{\small 23--31}) si
3359 stampano i vari valori mantenuti nella memoria condivisa attraverso l'uso di
3360 \var{shmptr}. Infine (\texttt{\small 41}) con \func{MutexUnlock} si rilascia
3361 il mutex, prima di uscire.
3362
3363 Verifichiamo allora il funzionamento dei nostri programmi; al solito, usando
3364 le funzioni di libreria occorre definire opportunamente
3365 \code{LD\_LIBRARY\_PATH}; poi si potrà lanciare il server con:
3366 \begin{verbatim}
3367 [piccardi@gont sources]$ ./dirmonitor ./
3368 \end{verbatim}%$
3369 ed avendo usato \func{daemon} il comando ritornerà immediatamente. Una volta
3370 che il server è in esecuzione, possiamo passare ad invocare il client per
3371 verificarne i risultati, in tal caso otterremo:
3372 \begin{verbatim}
3373 [piccardi@gont sources]$ ./readmon 
3374 Ci sono 68 file dati
3375 Ci sono 3 directory
3376 Ci sono 0 link
3377 Ci sono 0 fifo
3378 Ci sono 0 socket
3379 Ci sono 0 device a caratteri
3380 Ci sono 0 device a blocchi
3381 Totale  71 file, per 489831 byte
3382 \end{verbatim}%$
3383 ed un rapido calcolo (ad esempio con \code{ls -a | wc} per contare i file) ci
3384 permette di verificare che il totale dei file è giusto. Un controllo con
3385 \cmd{ipcs} ci permette inoltre di verificare la presenza di un segmento di
3386 memoria condivisa e di un semaforo:
3387 \begin{verbatim}
3388 [piccardi@gont sources]$ ipcs
3389 ------ Shared Memory Segments --------
3390 key        shmid      owner      perms      bytes      nattch     status      
3391 0xffffffff 54067205   piccardi  666        4096       1                       
3392
3393 ------ Semaphore Arrays --------
3394 key        semid      owner      perms      nsems     
3395 0xffffffff 229376     piccardi  666        1         
3396
3397 ------ Message Queues --------
3398 key        msqid      owner      perms      used-bytes   messages    
3399 \end{verbatim}%$
3400
3401 Se a questo punto aggiungiamo un file, ad esempio con \code{touch prova},
3402 potremo verificare (passati nel peggiore dei casi almeno 10 secondi, cioè
3403 l'intervallo scelto per la rilettura dei dati), che:
3404 \begin{verbatim}
3405 [piccardi@gont sources]$ ./readmon 
3406 Ci sono 69 file dati
3407 Ci sono 3 directory
3408 Ci sono 0 link
3409 Ci sono 0 fifo
3410 Ci sono 0 socket
3411 Ci sono 0 device a caratteri
3412 Ci sono 0 device a blocchi
3413 Totale  72 file, per 489887 byte
3414 \end{verbatim}%$
3415
3416 Infine potremo terminare il server con il comando \code{killall dirmonitor},
3417 nel qual caso, ripetendo la lettura otterremo che:
3418 \begin{verbatim}
3419 [piccardi@gont sources]$ ./readmon 
3420 Cannot find shared memory: No such file or directory
3421 \end{verbatim}%$
3422 e potremo verificare che anche gli oggetti di intercomunicazione sono stati
3423 cancellati:
3424 \begin{verbatim}
3425 [piccardi@gont sources]$ ipcs
3426 ------ Shared Memory Segments --------
3427 key        shmid      owner      perms      bytes      nattch     status      
3428
3429 ------ Semaphore Arrays --------
3430 key        semid      owner      perms      nsems     
3431
3432 ------ Message Queues --------
3433 key        msqid      owner      perms      used-bytes   messages    
3434 \end{verbatim}%$
3435
3436
3437
3438 %% Per capire meglio il funzionamento delle funzioni facciamo ancora una volta
3439 %% riferimento alle strutture con cui il kernel implementa i segmenti di memoria
3440 %% condivisa; uno schema semplificato della struttura è illustrato in
3441 %% \figref{fig:ipc_shm_struct}. 
3442
3443 %% \begin{figure}[htb]
3444 %%   \centering
3445 %%   \includegraphics[width=10cm]{img/shmstruct}
3446 %%    \caption{Schema dell'implementazione dei segmenti di memoria condivisa in
3447 %%     Linux.}
3448 %%   \label{fig:ipc_shm_struct}
3449 %% \end{figure}
3450
3451
3452
3453
3454 \section{Tecniche alternative}
3455 \label{sec:ipc_alternatives}
3456
3457 Come abbiamo detto in \secref{sec:ipc_sysv_generic}, e ripreso nella
3458 descrizione dei singoli oggetti che ne fan parte, il \textit{SysV IPC}
3459 presenta numerosi problemi; in \cite{APUE}\footnote{in particolare nel
3460   capitolo 14.}  Stevens ne effettua una accurata analisi (alcuni dei concetti
3461 sono già stati accennati in precedenza) ed elenca alcune possibili tecniche
3462 alternative, che vogliamo riprendere in questa sezione.
3463
3464
3465 \subsection{Alternative alle code di messaggi}
3466 \label{sec:ipc_mq_alternative}
3467  
3468 Le code di messaggi sono probabilmente il meno usato degli oggetti del
3469 \textit{SysV IPC}; esse infatti nacquero principalmente come meccanismo di
3470 comunicazione bidirezionale quando ancora le pipe erano unidirezionali; con la
3471 disponibilità di \func{socketpair} (vedi \secref{sec:ipc_socketpair}) o
3472 utilizzando una coppia di pipe, si può ottenere questo risultato senza
3473 incorrere nelle complicazioni introdotte dal \textit{SysV IPC}.
3474
3475 In realtà, grazie alla presenza del campo \var{mtype}, le code di messaggi
3476 hanno delle caratteristiche ulteriori, consentendo una classificazione dei
3477 messaggi ed un accesso non rigidamente sequenziale; due caratteristiche che
3478 sono impossibili da ottenere con le pipe e i socket\index{socket} di
3479 \func{socketpair}.  A queste esigenze però si può comunque ovviare in maniera
3480 diversa con un uso combinato della memoria condivisa e dei meccanismi di
3481 sincronizzazione, per cui alla fine l'uso delle code di messaggi classiche è
3482 relativamente poco diffuso.
3483
3484 \subsection{I \textsl{file di lock}}
3485 \label{sec:ipc_file_lock}
3486
3487 \index{file!di lock|(}
3488 Come illustrato in \secref{sec:ipc_sysv_sem} i semafori del \textit{SysV IPC}
3489 presentano una interfaccia inutilmente complessa e con alcuni difetti
3490 strutturali, per questo quando si ha una semplice esigenza di sincronizzazione
3491 per la quale basterebbe un semaforo binario (quello che abbiamo definito come
3492 \textit{mutex}), per indicare la disponibilità o meno di una risorsa, senza la
3493 necessità di un contatore come i semafori, si possono utilizzare metodi
3494 alternativi.
3495
3496 La prima possibilità, utilizzata fin dalle origini di Unix, è quella di usare
3497 dei \textsl{file di lock} (per i quali esiste anche una opportuna directory,
3498 \file{/var/lock}, nel filesystem standard). Per questo si usa la
3499 caratteristica della funzione \func{open} (illustrata in
3500 \secref{sec:file_open}) che prevede\footnote{questo è quanto dettato dallo
3501   standard POSIX.1, ciò non toglie che in alcune implementazioni questa
3502   tecnica possa non funzionare; in particolare per Linux, nel caso di NFS, si
3503   è comunque soggetti alla possibilità di una race   
3504   condition\index{race condition}.} che essa ritorni un errore quando usata
3505 con i flag di \const{O\_CREAT} e \const{O\_EXCL}. In tal modo la creazione di
3506 un \textsl{file di lock} può essere eseguita atomicamente, il processo che
3507 crea il file con successo si può considerare come titolare del lock (e della
3508 risorsa ad esso associata) mentre il rilascio si può eseguire con una chiamata
3509 ad \func{unlink}.
3510
3511 Un esempio dell'uso di questa funzione è mostrato dalle funzioni
3512 \func{LockFile} ed \func{UnlockFile} riportate in \figref{fig:ipc_file_lock}
3513 (sono contenute in \file{LockFile.c}, un'altro dei sorgenti allegati alla
3514 guida) che permettono rispettivamente di creare e rimuovere un \textsl{file di
3515   lock}. Come si può notare entrambe le funzioni sono elementari; la prima
3516 (\texttt{\small 4--10}) si limita ad aprire il file di lock (\texttt{\small
3517   9}) nella modalità descritta, mentre la seconda (\texttt{\small 11--17}) lo
3518 cancella con \func{unlink}.
3519
3520 \begin{figure}[!htb]
3521   \footnotesize \centering
3522   \begin{minipage}[c]{15cm}
3523     \begin{lstlisting}{} 
3524 #include <sys/types.h>
3525 #include <sys/stat.h>
3526 #include <unistd.h>                               /* unix standard functions */
3527 /*
3528  * Function LockFile:
3529  */
3530 int LockFile(const char* path_name)
3531 {
3532     return open(path_name, O_EXCL|O_CREAT);
3533 }
3534 /*
3535  * Function UnlockFile:
3536  */
3537 int UnlockFile(const char* path_name) 
3538 {
3539     return unlink(path_name);
3540 }
3541     \end{lstlisting}
3542   \end{minipage} 
3543   \normalsize 
3544   \caption{Il codice delle funzioni \func{LockFile} e \func{UnlockFile} che
3545     permettono di creare e rimuovere un \textsl{file di lock}.}
3546   \label{fig:ipc_file_lock}
3547 \end{figure}
3548
3549 Uno dei limiti di questa tecnica è che, come abbiamo già accennato in
3550 \secref{sec:file_open}, questo comportamento di \func{open} può non funzionare
3551 (la funzione viene eseguita, ma non è garantita l'atomicità dell'operazione)
3552 se il filesystem su cui si va ad operare è su NFS; in tal caso si può adottare
3553 una tecnica alternativa che prevede l'uso della \func{link} per creare come
3554 \textsl{file di lock} un hard link ad un file esistente; se il link esiste già
3555 e la funzione fallisce, significa che la risorsa è bloccata e potrà essere
3556 sbloccata solo con un \func{unlink}, altrimenti il link è creato ed il lock
3557 acquisito; il controllo e l'eventuale acquisizione sono atomici; la soluzione
3558 funziona anche su NFS, ma ha un'altro difetto è che è quello di poterla usare
3559 solo se si opera all'interno di uno stesso filesystem.
3560
3561 Un generale comunque l'uso di un \textsl{file di lock} presenta parecchi
3562 problemi, che non lo rendono una alternativa praticabile per la
3563 sincronizzazione: anzitutto in caso di terminazione imprevista del processo,
3564 si lascia allocata la risorsa (il \textsl{file di lock}) e questa deve essere
3565 sempre cancellata esplicitamente.  Inoltre il controllo della disponibilità
3566 può essere eseguito solo con una tecnica di \textit{polling}\index{polling},
3567 ed è quindi molto inefficiente.
3568
3569 La tecnica dei file di lock ha comunque una sua utilità, e può essere usata
3570 con successo quando l'esigenza è solo quella di segnalare l'occupazione di una
3571 risorsa, senza necessità di attendere che questa si liberi; ad esempio la si
3572 usa spesso per evitare interferenze sull'uso delle porte seriali da parte di
3573 più programmi: qualora si trovi un file di lock il programma che cerca di
3574 accedere alla seriale si limita a segnalare che la risorsa non è
3575 disponibile.\index{file!di lock|)}
3576
3577
3578 \subsection{La sincronizzazione con il \textit{file locking}}
3579 \label{sec:ipc_lock_file}
3580
3581 Dato che i file di lock\index{file!di lock} presentano gli inconvenienti
3582 illustrati in precedenza, la tecnica alternativa di sincronizzazione più
3583 comune è quella di fare ricorso al \textit{file locking}\index{file!locking}
3584 (trattato in \secref{sec:file_locking}) usando \func{fcntl} su un file creato
3585 per l'occasione per ottenere un write lock. In questo modo potremo usare il
3586 lock come un \textit{mutex}: per bloccare la risorsa basterà acquisire il
3587 lock, per sbloccarla basterà rilasciare il lock. Una richiesta fatta con un
3588 write lock metterà automaticamente il processo in stato di attesa, senza
3589 necessità di ricorrere al \textit{polling}\index{polling} per determinare la
3590 disponibilità della risorsa, e al rilascio della stessa da parte del processo
3591 che la occupava si otterrà il nuovo lock atomicamente.
3592
3593 Questo approccio presenta il notevole vantaggio che alla terminazione di un
3594 processo tutti i lock acquisiti vengono rilasciati automaticamente (alla
3595 chiusura dei relativi file) e non ci si deve preoccupare di niente; inoltre
3596 non consuma risorse permanentemente allocate nel sistema. Lo svantaggio è che,
3597 dovendo fare ricorso a delle operazioni sul filesystem, esso è in genere
3598 leggermente più lento.
3599