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