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