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