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