3 %% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
12 \chapter{L'intercomunicazione fra processi}
16 Uno degli aspetti fondamentali della programmazione in un sistema unix-like è
17 la comunicazione fra processi. In questo capitolo affronteremo solo i
18 meccanismi più elementari che permettono di mettere in comunicazione processi
19 diversi, come quelli tradizionali che coinvolgono \textit{pipe} e
20 \textit{fifo} e i meccanismi di intercomunicazione di System V e quelli POSIX.
22 Tralasceremo invece tutte le problematiche relative alla comunicazione
23 attraverso la rete (e le relative interfacce) che saranno affrontate in
24 dettaglio in un secondo tempo. Non affronteremo neanche meccanismi più
25 complessi ed evoluti come le RPC (\textit{Remote Procedure Calls}) e CORBA
26 (\textit{Common Object Request Brocker Architecture}) che in genere sono
27 implementati con un ulteriore livello sopra i meccanismi elementari.
30 \section{L'intercomunicazione fra processi tradizionale}
33 Il primo meccanismo di comunicazione fra processi introdotto nei sistemi Unix,
34 è quello delle cosiddette \textit{pipe}; esse costituiscono una delle
35 caratteristiche peculiari del sistema, in particolar modo dell'interfaccia a
36 linea di comando. In questa sezione descriveremo le sue basi, le funzioni che
37 ne gestiscono l'uso e le varie forme in cui si è evoluto.
40 \subsection{Le \textit{pipe} standard}
43 Le \textit{pipe} nascono sostanzialmente con Unix, e sono il primo, e tuttora
44 uno dei più usati, meccanismi di comunicazione fra processi. Si tratta in
45 sostanza di una coppia di file descriptor\footnote{si tenga presente che
46 le pipe sono oggetti creati dal kernel e non risiedono su disco.} connessi
47 fra di loro in modo che se quanto scrive su di uno si può rileggere
48 dall'altro. Si viene così a costituire un canale di comunicazione tramite i
49 due file descriptor, nella forma di un \textsl{tubo} (da cui il nome)
50 attraverso cui fluiscono i dati.
52 La funzione che permette di creare questa speciale coppia di file descriptor
53 associati ad una \textit{pipe} è appunto \funcd{pipe}, ed il suo prototipo è:
54 \begin{prototype}{unistd.h}
55 {int pipe(int filedes[2])}
57 Crea una coppia di file descriptor associati ad una \textit{pipe}.
59 \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
60 errore, nel qual caso \var{errno} potrà assumere i valori \errval{EMFILE},
61 \errval{ENFILE} e \errval{EFAULT}.}
64 La funzione restituisce la coppia di file descriptor nel vettore
65 \param{filedes}; il primo è aperto in lettura ed il secondo in scrittura. Come
66 accennato concetto di funzionamento di una pipe è semplice: quello che si
67 scrive nel file descriptor aperto in scrittura viene ripresentato tale e quale
68 nel file descriptor aperto in lettura. I file descriptor infatti non sono
69 connessi a nessun file reale, ma, come accennato in
70 sez.~\ref{sec:file_sendfile_splice}, ad un buffer nel kernel, la cui
71 dimensione è specificata dal parametro di sistema \const{PIPE\_BUF}, (vedi
72 sez.~\ref{sec:sys_file_limits}). Lo schema di funzionamento di una pipe è
73 illustrato in fig.~\ref{fig:ipc_pipe_singular}, in cui sono illustrati i due
74 capi della pipe, associati a ciascun file descriptor, con le frecce che
75 indicano la direzione del flusso dei dati.
77 % TODO: la dimensione è cambiata a 64k (vedi man 7 pipe) e può essere
78 % modificata con F_SETPIPE_SZ dal 2.6.35 (vedi fcntl)
82 \includegraphics[height=5cm]{img/pipe}
83 \caption{Schema della struttura di una pipe.}
84 \label{fig:ipc_pipe_singular}
87 Chiaramente creare una pipe all'interno di un singolo processo non serve a
88 niente; se però ricordiamo quanto esposto in sez.~\ref{sec:file_shared_access}
89 riguardo al comportamento dei file descriptor nei processi figli, è immediato
90 capire come una pipe possa diventare un meccanismo di intercomunicazione. Un
91 processo figlio infatti condivide gli stessi file descriptor del padre,
92 compresi quelli associati ad una pipe (secondo la situazione illustrata in
93 fig.~\ref{fig:ipc_pipe_fork}). In questo modo se uno dei processi scrive su un
94 capo della pipe, l'altro può leggere.
98 \includegraphics[height=5cm]{img/pipefork}
99 \caption{Schema dei collegamenti ad una pipe, condivisi fra processo padre e
100 figlio dopo l'esecuzione \func{fork}.}
101 \label{fig:ipc_pipe_fork}
104 Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
105 comunicazione fra processi attraverso una pipe, utilizzando le proprietà
106 ordinarie dei file, ma ci mostra anche qual è il principale\footnote{Stevens
107 in \cite{APUE} riporta come limite anche il fatto che la comunicazione è
108 unidirezionale, ma in realtà questo è un limite facilmente superabile usando
109 una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i
110 processi possano condividere i file descriptor della pipe, e per questo essi
111 devono comunque essere \textsl{parenti} (dall'inglese \textit{siblings}), cioè
112 o derivare da uno stesso processo padre in cui è avvenuta la creazione della
113 pipe, o, più comunemente, essere nella relazione padre/figlio.
115 A differenza di quanto avviene con i file normali, la lettura da una pipe può
116 essere bloccante (qualora non siano presenti dati), inoltre se si legge da una
117 pipe il cui capo in scrittura è stato chiuso, si avrà la ricezione di un EOF
118 (vale a dire che la funzione \func{read} ritornerà restituendo 0). Se invece
119 si esegue una scrittura su una pipe il cui capo in lettura non è aperto il
120 processo riceverà il segnale \signal{SIGPIPE}, e la funzione di scrittura
121 restituirà un errore di \errcode{EPIPE} (al ritorno del gestore, o qualora il
122 segnale sia ignorato o bloccato).
124 La dimensione del buffer della pipe (\const{PIPE\_BUF}) ci dà inoltre un'altra
125 importante informazione riguardo il comportamento delle operazioni di lettura
126 e scrittura su di una pipe; esse infatti sono atomiche fintanto che la
127 quantità di dati da scrivere non supera questa dimensione. Qualora ad esempio
128 si effettui una scrittura di una quantità di dati superiore l'operazione verrà
129 effettuata in più riprese, consentendo l'intromissione di scritture effettuate
133 \subsection{Un esempio dell'uso delle pipe}
134 \label{sec:ipc_pipe_use}
136 Per capire meglio il funzionamento delle pipe faremo un esempio di quello che
137 è il loro uso più comune, analogo a quello effettuato della shell, e che
138 consiste nell'inviare l'output di un processo (lo standard output) sull'input
139 di un altro. Realizzeremo il programma di esempio nella forma di un
140 \textit{CGI}\footnote{un CGI (\textit{Common Gateway Interface}) è un
141 programma che permette la creazione dinamica di un oggetto da inserire
142 all'interno di una pagina HTML.} per Apache, che genera una immagine JPEG
143 di un codice a barre, specificato come argomento in ingresso.
145 Un programma che deve essere eseguito come \textit{CGI} deve rispondere a
146 delle caratteristiche specifiche, esso infatti non viene lanciato da una
147 shell, ma dallo stesso web server, alla richiesta di una specifica URL, che di
150 http://www.sito.it/cgi-bin/programma?argomento
152 ed il risultato dell'elaborazione deve essere presentato (con una intestazione
153 che ne descrive il mime-type) sullo standard output, in modo che il web-server
154 possa reinviarlo al browser che ha effettuato la richiesta, che in questo modo
155 è in grado di visualizzarlo opportunamente.
157 Per realizzare quanto voluto useremo in sequenza i programmi \cmd{barcode} e
158 \cmd{gs}, il primo infatti è in grado di generare immagini PostScript di
159 codici a barre corrispondenti ad una qualunque stringa, mentre il secondo
160 serve per poter effettuare la conversione della stessa immagine in formato
161 JPEG. Usando una pipe potremo inviare l'output del primo sull'input del
162 secondo, secondo lo schema mostrato in fig.~\ref{fig:ipc_pipe_use}, in cui la
163 direzione del flusso dei dati è data dalle frecce continue.
167 \includegraphics[height=5cm]{img/pipeuse}
168 \caption{Schema dell'uso di una pipe come mezzo di comunicazione fra
169 due processi attraverso l'esecuzione una \func{fork} e la chiusura dei
170 capi non utilizzati.}
171 \label{fig:ipc_pipe_use}
174 Si potrebbe obiettare che sarebbe molto più semplice salvare il risultato
175 intermedio su un file temporaneo. Questo però non tiene conto del fatto che un
176 \textit{CGI} deve poter gestire più richieste in concorrenza, e si avrebbe una
177 evidente \itindex{race~condition} \textit{race condition} in caso di accesso
178 simultaneo a detto file.\footnote{il problema potrebbe essere superato
179 determinando in anticipo un nome appropriato per il file temporaneo, che
180 verrebbe utilizzato dai vari sotto-processi, e cancellato alla fine della
181 loro esecuzione; ma a questo punto le cose non sarebbero più tanto
182 semplici.} L'uso di una pipe invece permette di risolvere il problema in
183 maniera semplice ed elegante, oltre ad essere molto più efficiente, dato che
184 non si deve scrivere su disco.
186 Il programma ci servirà anche come esempio dell'uso delle funzioni di
187 duplicazione dei file descriptor che abbiamo trattato in
188 sez.~\ref{sec:file_dup}, in particolare di \func{dup2}. È attraverso queste
189 funzioni infatti che è possibile dirottare gli stream standard dei processi
190 (che abbiamo visto in tab.~\ref{tab:file_std_files} e
191 sez.~\ref{sec:file_stream}) sulla pipe. In fig.~\ref{fig:ipc_barcodepage_code}
192 abbiamo riportato il corpo del programma, il cui codice completo è disponibile
193 nel file \file{BarCodePage.c} che si trova nella directory dei sorgenti.
195 \begin{figure}[!htbp]
196 \footnotesize \centering
197 \begin{minipage}[c]{\codesamplewidth}
198 \includecodesample{listati/BarCodePage.c}
201 \caption{Sezione principale del codice del \textit{CGI}
202 \file{BarCodePage.c}.}
203 \label{fig:ipc_barcodepage_code}
206 La prima operazione del programma (\texttt{\small 4--12}) è quella di creare
207 le due pipe che serviranno per la comunicazione fra i due comandi utilizzati
208 per produrre il codice a barre; si ha cura di controllare la riuscita della
209 chiamata, inviando in caso di errore un messaggio invece dell'immagine
210 richiesta.\footnote{la funzione \func{WriteMess} non è riportata in
211 fig.~\ref{fig:ipc_barcodepage_code}; essa si incarica semplicemente di
212 formattare l'uscita alla maniera dei CGI, aggiungendo l'opportuno
213 \textit{mime type}, e formattando il messaggio in HTML, in modo che
214 quest'ultimo possa essere visualizzato correttamente da un browser.}
216 Una volta create le pipe, il programma può creare (\texttt{\small 13-17}) il
217 primo processo figlio, che si incaricherà (\texttt{\small 19--25}) di eseguire
218 \cmd{barcode}. Quest'ultimo legge dallo standard input una stringa di
219 caratteri, la converte nell'immagine PostScript del codice a barre ad essa
220 corrispondente, e poi scrive il risultato direttamente sullo standard output.
222 Per poter utilizzare queste caratteristiche prima di eseguire \cmd{barcode} si
223 chiude (\texttt{\small 20}) il capo aperto in scrittura della prima pipe, e se
224 ne collega (\texttt{\small 21}) il capo in lettura allo standard input, usando
225 \func{dup2}. Si ricordi che invocando \func{dup2} il secondo file, qualora
226 risulti aperto, viene, come nel caso corrente, chiuso prima di effettuare la
227 duplicazione. Allo stesso modo, dato che \cmd{barcode} scrive l'immagine
228 PostScript del codice a barre sullo standard output, per poter effettuare una
229 ulteriore redirezione il capo in lettura della seconda pipe viene chiuso
230 (\texttt{\small 22}) mentre il capo in scrittura viene collegato allo standard
231 output (\texttt{\small 23}).
233 In questo modo all'esecuzione (\texttt{\small 25}) di \cmd{barcode} (cui si
234 passa in \var{size} la dimensione della pagina per l'immagine) quest'ultimo
235 leggerà dalla prima pipe la stringa da codificare che gli sarà inviata dal
236 padre, e scriverà l'immagine PostScript del codice a barre sulla seconda.
238 Al contempo una volta lanciato il primo figlio, il processo padre prima chiude
239 (\texttt{\small 26}) il capo inutilizzato della prima pipe (quello in input) e
240 poi scrive (\texttt{\small 27}) la stringa da convertire sul capo in output,
241 così che \cmd{barcode} possa riceverla dallo standard input. A questo punto
242 l'uso della prima pipe da parte del padre è finito ed essa può essere
243 definitivamente chiusa (\texttt{\small 28}), si attende poi (\texttt{\small
244 29}) che l'esecuzione di \cmd{barcode} sia completata.
246 Alla conclusione della sua esecuzione \cmd{barcode} avrà inviato l'immagine
247 PostScript del codice a barre sul capo in scrittura della seconda pipe; a
248 questo punto si può eseguire la seconda conversione, da PS a JPEG, usando il
249 programma \cmd{gs}. Per questo si crea (\texttt{\small 30--34}) un secondo
250 processo figlio, che poi (\texttt{\small 35--42}) eseguirà questo programma
251 leggendo l'immagine PostScript creata da \cmd{barcode} dallo standard input,
252 per convertirla in JPEG.
254 Per fare tutto ciò anzitutto si chiude (\texttt{\small 37}) il capo in
255 scrittura della seconda pipe, e se ne collega (\texttt{\small 38}) il capo in
256 lettura allo standard input. Per poter formattare l'output del programma in
257 maniera utilizzabile da un browser, si provvede anche \texttt{\small 40}) alla
258 scrittura dell'apposita stringa di identificazione del mime-type in testa allo
259 standard output. A questo punto si può invocare \texttt{\small 41}) \cmd{gs},
260 provvedendo gli appositi switch che consentono di leggere il file da
261 convertire dallo standard input e di inviare la conversione sullo standard
264 Per completare le operazioni il processo padre chiude (\texttt{\small 44}) il
265 capo in scrittura della seconda pipe, e attende la conclusione del figlio
266 (\texttt{\small 45}); a questo punto può (\texttt{\small 46}) uscire. Si tenga
267 conto che l'operazione di chiudere il capo in scrittura della seconda pipe è
268 necessaria, infatti, se non venisse chiusa, \cmd{gs}, che legge il suo
269 standard input da detta pipe, resterebbe bloccato in attesa di ulteriori dati
270 in ingresso (l'unico modo che un programma ha per sapere che l'input è
271 terminato è rilevare che lo standard input è stato chiuso), e la \func{wait}
275 \subsection{Le funzioni \func{popen} e \func{pclose}}
276 \label{sec:ipc_popen}
278 Come si è visto la modalità più comune di utilizzo di una pipe è quella di
279 utilizzarla per fare da tramite fra output ed input di due programmi invocati
280 in sequenza; per questo motivo lo standard POSIX.2 ha introdotto due funzioni
281 che permettono di sintetizzare queste operazioni. La prima di esse si chiama
282 \funcd{popen} ed il suo prototipo è:
283 \begin{prototype}{stdio.h}
284 {FILE *popen(const char *command, const char *type)}
286 Esegue il programma \param{command}, di cui, a seconda di \param{type},
287 restituisce, lo standard input o lo standard output nella pipe collegata allo
288 stream restituito come valore di ritorno.
290 \bodydesc{La funzione restituisce l'indirizzo dello stream associato alla pipe
291 in caso di successo e \val{NULL} per un errore, nel qual caso \var{errno}
292 potrà assumere i valori relativi alle sottostanti invocazioni di \func{pipe}
293 e \func{fork} o \errcode{EINVAL} se \param{type} non è valido.}
296 La funzione crea una pipe, esegue una \func{fork}, ed invoca il programma
297 \param{command} attraverso la shell (in sostanza esegue \file{/bin/sh} con il
298 flag \code{-c}); l'argomento \param{type} deve essere una delle due stringhe
299 \verb|"w"| o \verb|"r"|, per indicare se la pipe sarà collegata allo standard
300 input o allo standard output del comando invocato.
302 La funzione restituisce il puntatore allo stream associato alla pipe creata,
303 che sarà aperto in sola lettura (e quindi associato allo standard output del
304 programma indicato) in caso si sia indicato \code{"r"}, o in sola scrittura (e
305 quindi associato allo standard input) in caso di \code{"w"}.
307 Lo \textit{stream} restituito da \func{popen} è identico a tutti gli effetti
308 ai \textit{file stream} visti in sez.~\ref{sec:files_std_interface}, anche se
309 è collegato ad una pipe e non ad un file, e viene sempre aperto in modalità
310 \textit{fully-buffered} (vedi sez.~\ref{sec:file_buffering}); l'unica
311 differenza con gli usuali stream è che dovrà essere chiuso dalla seconda delle
312 due nuove funzioni, \funcd{pclose}, il cui prototipo è:
313 \begin{prototype}{stdio.h}
314 {int pclose(FILE *stream)}
316 Chiude il file \param{stream}, restituito da una precedente \func{popen}
317 attendendo la terminazione del processo ad essa associato.
319 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
320 errore; nel quel caso il valore di \var{errno} deriva dalle sottostanti
323 \noindent che oltre alla chiusura dello stream si incarica anche di attendere
324 (tramite \func{wait4}) la conclusione del processo creato dalla precedente
327 Per illustrare l'uso di queste due funzioni riprendiamo il problema
328 precedente: il programma mostrato in fig.~\ref{fig:ipc_barcodepage_code} per
329 quanto funzionante, è (volutamente) codificato in maniera piuttosto complessa,
330 inoltre nella pratica sconta un problema di \cmd{gs} che non è in
331 grado\footnote{nella versione GNU Ghostscript 6.53 (2002-02-13).} di
332 riconoscere correttamente l'Encapsulated PostScript, per cui deve essere usato
333 il PostScript e tutte le volte viene generata una pagina intera, invece che
334 una immagine delle dimensioni corrispondenti al codice a barre.
336 Se si vuole generare una immagine di dimensioni appropriate si deve usare un
337 approccio diverso. Una possibilità sarebbe quella di ricorrere ad ulteriore
338 programma, \cmd{epstopsf}, per convertire in PDF un file EPS (che può essere
339 generato da \cmd{barcode} utilizzando lo switch \cmd{-E}). Utilizzando un PDF
340 al posto di un EPS \cmd{gs} esegue la conversione rispettando le dimensioni
341 originarie del codice a barre e produce un JPEG di dimensioni corrette.
343 Questo approccio però non funziona, per via di una delle caratteristiche
344 principali delle pipe. Per poter effettuare la conversione di un PDF infatti è
345 necessario, per la struttura del formato, potersi spostare (con \func{lseek})
346 all'interno del file da convertire; se si esegue la conversione con \cmd{gs}
347 su un file regolare non ci sono problemi, una pipe però è rigidamente
348 sequenziale, e l'uso di \func{lseek} su di essa fallisce sempre con un errore
349 di \errcode{ESPIPE}, rendendo impossibile la conversione. Questo ci dice che
350 in generale la concatenazione di vari programmi funzionerà soltanto quando
351 tutti prevedono una lettura sequenziale del loro input.
353 Per questo motivo si è dovuto utilizzare un procedimento diverso, eseguendo
354 prima la conversione (sempre con \cmd{gs}) del PS in un altro formato
355 intermedio, il PPM,\footnote{il \textit{Portable PixMap file format} è un
356 formato usato spesso come formato intermedio per effettuare conversioni, è
357 infatti molto facile da manipolare, dato che usa caratteri ASCII per
358 memorizzare le immagini, anche se per questo è estremamente inefficiente.}
359 dal quale poi si può ottenere un'immagine di dimensioni corrette attraverso
360 vari programmi di manipolazione (\cmd{pnmcrop}, \cmd{pnmmargin}) che può
361 essere infine trasformata in PNG (con \cmd{pnm2png}).
363 In questo caso però occorre eseguire in sequenza ben quattro comandi diversi,
364 inviando l'output di ciascuno all'input del successivo, per poi ottenere il
365 risultato finale sullo standard output: un caso classico di utilizzazione
366 delle pipe, in cui l'uso di \func{popen} e \func{pclose} permette di
367 semplificare notevolmente la stesura del codice.
369 Nel nostro caso, dato che ciascun processo deve scrivere il suo output sullo
370 standard input del successivo, occorrerà usare \func{popen} aprendo la pipe in
371 scrittura. Il codice del nuovo programma è riportato in
372 fig.~\ref{fig:ipc_barcode_code}. Come si può notare l'ordine di invocazione
373 dei programmi è l'inverso di quello in cui ci si aspetta che vengano
374 effettivamente eseguiti. Questo non comporta nessun problema dato che la
375 lettura su una pipe è bloccante, per cui ciascun processo, per quanto lanciato
376 per primo, si bloccherà in attesa di ricevere sullo standard input il
377 risultato dell'elaborazione del precedente, benché quest'ultimo venga invocato
380 \begin{figure}[!htbp]
381 \footnotesize \centering
382 \begin{minipage}[c]{\codesamplewidth}
383 \includecodesample{listati/BarCode.c}
386 \caption{Codice completo del \textit{CGI} \file{BarCode.c}.}
387 \label{fig:ipc_barcode_code}
390 Nel nostro caso il primo passo (\texttt{\small 14}) è scrivere il mime-type
391 sullo standard output; a questo punto il processo padre non necessita più di
392 eseguire ulteriori operazioni sullo standard output e può tranquillamente
393 provvedere alla redirezione.
395 Dato che i vari programmi devono essere lanciati in successione, si è
396 approntato un ciclo (\texttt{\small 15--19}) che esegue le operazioni in
397 sequenza: prima crea una pipe (\texttt{\small 17}) per la scrittura eseguendo
398 il programma con \func{popen}, in modo che essa sia collegata allo standard
399 input, e poi redirige (\texttt{\small 18}) lo standard output su detta pipe.
401 In questo modo il primo processo ad essere invocato (che è l'ultimo della
402 catena) scriverà ancora sullo standard output del processo padre, ma i
403 successivi, a causa di questa redirezione, scriveranno sulla pipe associata
404 allo standard input del processo invocato nel ciclo precedente.
406 Alla fine tutto quello che resta da fare è lanciare (\texttt{\small 21}) il
407 primo processo della catena, che nel caso è \cmd{barcode}, e scrivere
408 (\texttt{\small 23}) la stringa del codice a barre sulla pipe, che è collegata
409 al suo standard input, infine si può eseguire (\texttt{\small 24--27}) un
410 ciclo che chiuda, nell'ordine inverso rispetto a quello in cui le si sono
411 create, tutte le pipe create con \func{pclose}.
414 \subsection{Le \textit{pipe} con nome, o \textit{fifo}}
415 \label{sec:ipc_named_pipe}
417 Come accennato in sez.~\ref{sec:ipc_pipes} il problema delle \textit{pipe} è
418 che esse possono essere utilizzate solo da processi con un progenitore comune
419 o nella relazione padre/figlio; per superare questo problema lo standard
420 POSIX.1 ha definito dei nuovi oggetti, le \textit{fifo}, che hanno le stesse
421 caratteristiche delle pipe, ma che invece di essere strutture interne del
422 kernel, visibili solo attraverso un file descriptor, sono accessibili
423 attraverso un \itindex{inode} inode che risiede sul filesystem, così che i
424 processi le possono usare senza dovere per forza essere in una relazione di
427 Utilizzando una \textit{fifo} tutti i dati passeranno, come per le pipe,
428 attraverso un apposito buffer nel kernel, senza transitare dal filesystem;
429 \itindex{inode} l'inode allocato sul filesystem serve infatti solo a fornire un
430 punto di riferimento per i processi, che permetta loro di accedere alla stessa
431 fifo; il comportamento delle funzioni di lettura e scrittura è identico a
432 quello illustrato per le pipe in sez.~\ref{sec:ipc_pipes}.
434 Abbiamo già visto in sez.~\ref{sec:file_mknod} le funzioni \func{mknod} e
435 \func{mkfifo} che permettono di creare una fifo; per utilizzarne una un
436 processo non avrà che da aprire il relativo \index{file!speciali} file
437 speciale o in lettura o scrittura; nel primo caso sarà collegato al capo di
438 uscita della fifo, e dovrà leggere, nel secondo al capo di ingresso, e dovrà
441 Il kernel crea una singola pipe per ciascuna fifo che sia stata aperta, che può
442 essere acceduta contemporaneamente da più processi, sia in lettura che in
443 scrittura. Dato che per funzionare deve essere aperta in entrambe le
444 direzioni, per una fifo di norma la funzione \func{open} si blocca se viene
445 eseguita quando l'altro capo non è aperto.
447 Le fifo però possono essere anche aperte in modalità \textsl{non-bloccante},
448 nel qual caso l'apertura del capo in lettura avrà successo solo quando anche
449 l'altro capo è aperto, mentre l'apertura del capo in scrittura restituirà
450 l'errore di \errcode{ENXIO} fintanto che non verrà aperto il capo in lettura.
452 In Linux è possibile aprire le fifo anche in lettura/scrittura,\footnote{lo
453 standard POSIX lascia indefinito il comportamento in questo caso.}
454 operazione che avrà sempre successo immediato qualunque sia la modalità di
455 apertura (bloccante e non bloccante); questo può essere utilizzato per aprire
456 comunque una fifo in scrittura anche se non ci sono ancora processi il
457 lettura; è possibile anche usare la fifo all'interno di un solo processo, nel
458 qual caso però occorre stare molto attenti alla possibili situazioni di
459 stallo.\footnote{se si cerca di leggere da una fifo che non contiene dati si
460 avrà un \itindex{deadlock} deadlock immediato, dato che il processo si
461 blocca e non potrà quindi mai eseguire le funzioni di scrittura.}
463 Per la loro caratteristica di essere accessibili attraverso il filesystem, è
464 piuttosto frequente l'utilizzo di una fifo come canale di comunicazione nelle
465 situazioni un processo deve ricevere informazioni da altri. In questo caso è
466 fondamentale che le operazioni di scrittura siano atomiche; per questo si deve
467 sempre tenere presente che questo è vero soltanto fintanto che non si supera
468 il limite delle dimensioni di \const{PIPE\_BUF} (si ricordi quanto detto in
469 sez.~\ref{sec:ipc_pipes}).
471 A parte il caso precedente, che resta probabilmente il più comune, Stevens
472 riporta in \cite{APUE} altre due casistiche principali per l'uso delle fifo:
474 \item Da parte dei comandi di shell, per evitare la creazione di file
475 temporanei quando si devono inviare i dati di uscita di un processo
476 sull'input di parecchi altri (attraverso l'uso del comando \cmd{tee}).
478 \item Come canale di comunicazione fra client ed server (il modello
479 \textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}).
482 Nel primo caso quello che si fa è creare tante fifo, da usare come standard
483 input, quanti sono i processi a cui i vogliono inviare i dati, questi ultimi
484 saranno stati posti in esecuzione ridirigendo lo standard input dalle fifo, si
485 potrà poi eseguire il processo che fornisce l'output replicando quest'ultimo,
486 con il comando \cmd{tee}, sulle varie fifo.
488 Il secondo caso è relativamente semplice qualora si debba comunicare con un
489 processo alla volta (nel qual caso basta usare due fifo, una per leggere ed
490 una per scrivere), le cose diventano invece molto più complesse quando si
491 vuole effettuare una comunicazione fra il server ed un numero imprecisato di
492 client; se il primo infatti può ricevere le richieste attraverso una fifo
493 ``\textsl{nota}'', per le risposte non si può fare altrettanto, dato che, per
494 la struttura sequenziale delle fifo, i client dovrebbero sapere, prima di
495 leggerli, quando i dati inviati sono destinati a loro.
497 Per risolvere questo problema, si può usare un'architettura come quella
498 illustrata in fig.~\ref{fig:ipc_fifo_server_arch} in cui i client inviano le
499 richieste al server su una fifo nota mentre le risposte vengono reinviate dal
500 server a ciascuno di essi su una fifo temporanea creata per l'occasione.
504 \includegraphics[height=9cm]{img/fifoserver}
505 \caption{Schema dell'utilizzo delle fifo nella realizzazione di una
506 architettura di comunicazione client/server.}
507 \label{fig:ipc_fifo_server_arch}
510 Come esempio di uso questa architettura e dell'uso delle fifo, abbiamo scritto
511 un server di \textit{fortunes}, che restituisce, alle richieste di un client,
512 un detto a caso estratto da un insieme di frasi; sia il numero delle frasi
513 dell'insieme, che i file da cui esse vengono lette all'avvio, sono importabili
514 da riga di comando. Il corpo principale del server è riportato in
515 fig.~\ref{fig:ipc_fifo_server}, dove si è tralasciata la parte che tratta la
516 gestione delle opzioni a riga di comando, che effettua il settaggio delle
517 variabili \var{fortunefilename}, che indica il file da cui leggere le frasi,
518 ed \var{n}, che indica il numero di frasi tenute in memoria, ad un valore
519 diverso da quelli preimpostati. Il codice completo è nel file
520 \file{FortuneServer.c}.
522 \begin{figure}[!htbp]
523 \footnotesize \centering
524 \begin{minipage}[c]{\codesamplewidth}
525 \includecodesample{listati/FortuneServer.c}
528 \caption{Sezione principale del codice del server di \textit{fortunes}
530 \label{fig:ipc_fifo_server}
533 Il server richiede (\texttt{\small 12}) che sia stata impostata una dimensione
534 dell'insieme delle frasi non nulla, dato che l'inizializzazione del vettore
535 \var{fortune} avviene solo quando questa dimensione viene specificata, la
536 presenza di un valore nullo provoca l'uscita dal programma attraverso la
537 funzione (non riportata) che ne stampa le modalità d'uso. Dopo di che
538 installa (\texttt{\small 13--15}) la funzione che gestisce i segnali di
539 interruzione (anche questa non è riportata in fig.~\ref{fig:ipc_fifo_server})
540 che si limita a rimuovere dal filesystem la fifo usata dal server per
543 Terminata l'inizializzazione (\texttt{\small 16}) si effettua la chiamata alla
544 funzione \code{FortuneParse} che legge dal file specificato in
545 \var{fortunefilename} le prime \var{n} frasi e le memorizza (allocando
546 dinamicamente la memoria necessaria) nel vettore di puntatori \var{fortune}.
547 Anche il codice della funzione non è riportato, in quanto non direttamente
548 attinente allo scopo dell'esempio.
550 Il passo successivo (\texttt{\small 17--22}) è quello di creare con
551 \func{mkfifo} la fifo nota sulla quale il server ascolterà le richieste,
552 qualora si riscontri un errore il server uscirà (escludendo ovviamente il caso
553 in cui la funzione \func{mkfifo} fallisce per la precedente esistenza della
556 Una volta che si è certi che la fifo di ascolto esiste la procedura di
557 inizializzazione è completata. A questo punto si può chiamare (\texttt{\small
558 23}) la funzione \func{daemon} per far proseguire l'esecuzione del programma
559 in background come demone. Si può quindi procedere (\texttt{\small 24--33})
560 alla apertura della fifo: si noti che questo viene fatto due volte, prima in
561 lettura e poi in scrittura, per evitare di dover gestire all'interno del ciclo
562 principale il caso in cui il server è in ascolto ma non ci sono client che
563 effettuano richieste. Si ricordi infatti che quando una fifo è aperta solo
564 dal capo in lettura, l'esecuzione di \func{read} ritorna con zero byte (si ha
565 cioè una condizione di end-of-file).
567 Nel nostro caso la prima apertura si bloccherà fintanto che un qualunque
568 client non apre a sua volta la fifo nota in scrittura per effettuare la sua
569 richiesta. Pertanto all'inizio non ci sono problemi, il client però, una volta
570 ricevuta la risposta, uscirà, chiudendo tutti i file aperti, compresa la fifo.
571 A questo punto il server resta (se non ci sono altri client che stanno
572 effettuando richieste) con la fifo chiusa sul lato in lettura, ed in questo
573 stato la funzione \func{read} non si bloccherà in attesa di input, ma
574 ritornerà in continuazione, restituendo un end-of-file.\footnote{si è usata
575 questa tecnica per compatibilità, Linux infatti supporta l'apertura delle
576 fifo in lettura/scrittura, per cui si sarebbe potuto effettuare una singola
577 apertura con \const{O\_RDWR}, la doppia apertura comunque ha il vantaggio
578 che non si può scrivere per errore sul capo aperto in sola lettura.}
580 Per questo motivo, dopo aver eseguito l'apertura in lettura (\texttt{\small
581 24--28}),\footnote{di solito si effettua l'apertura del capo in lettura di
582 una fifo in modalità non bloccante, per evitare il rischio di uno stallo: se
583 infatti nessuno apre la fifo in scrittura il processo non ritornerà mai
584 dalla \func{open}. Nel nostro caso questo rischio non esiste, mentre è
585 necessario potersi bloccare in lettura in attesa di una richiesta.} si
586 esegue una seconda apertura in scrittura (\texttt{\small 29--32}), scartando
587 il relativo file descriptor, che non sarà mai usato, in questo modo però la
588 fifo resta comunque aperta anche in scrittura, cosicché le successive chiamate
589 a \func{read} possono bloccarsi.
591 A questo punto si può entrare nel ciclo principale del programma che fornisce
592 le risposte ai client (\texttt{\small 34--50}); questo viene eseguito
593 indefinitamente (l'uscita del server viene effettuata inviando un segnale, in
594 modo da passare attraverso la funzione di chiusura che cancella la fifo).
596 Il server è progettato per accettare come richieste dai client delle stringhe
597 che contengono il nome della fifo sulla quale deve essere inviata la risposta.
598 Per cui prima (\texttt{\small 35--39}) si esegue la lettura dalla stringa di
599 richiesta dalla fifo nota (che a questo punto si bloccherà tutte le volte che
600 non ci sono richieste). Dopo di che, una volta terminata la stringa
601 (\texttt{\small 40}) e selezionato (\texttt{\small 41}) un numero casuale per
602 ricavare la frase da inviare, si procederà (\texttt{\small 42--46})
603 all'apertura della fifo per la risposta, che poi \texttt{\small 47--48}) vi
604 sarà scritta. Infine (\texttt{\small 49}) si chiude la fifo di risposta che
607 Il codice del client è invece riportato in fig.~\ref{fig:ipc_fifo_client},
608 anche in questo caso si è omessa la gestione delle opzioni e la funzione che
609 stampa a video le informazioni di utilizzo ed esce, riportando solo la sezione
610 principale del programma e le definizioni delle variabili. Il codice completo
611 è nel file \file{FortuneClient.c} dei sorgenti allegati.
613 \begin{figure}[!htbp]
614 \footnotesize \centering
615 \begin{minipage}[c]{\codesamplewidth}
616 \includecodesample{listati/FortuneClient.c}
619 \caption{Sezione principale del codice del client di \textit{fortunes}
621 \label{fig:ipc_fifo_client}
624 La prima istruzione (\texttt{\small 12}) compone il nome della fifo che dovrà
625 essere utilizzata per ricevere la risposta dal server. Si usa il \ids{PID}
626 del processo per essere sicuri di avere un nome univoco; dopo di che
627 (\texttt{\small 13-18}) si procede alla creazione del relativo file, uscendo
628 in caso di errore (a meno che il file non sia già presente sul filesystem).
630 A questo punto il client può effettuare l'interrogazione del server, per
631 questo prima si apre la fifo nota (\texttt{\small 19--23}), e poi ci si scrive
632 (\texttt{\small 24}) la stringa composta in precedenza, che contiene il nome
633 della fifo da utilizzare per la risposta. Infine si richiude la fifo del
634 server che a questo punto non serve più (\texttt{\small 25}).
636 Inoltrata la richiesta si può passare alla lettura della risposta; anzitutto
637 si apre (\texttt{\small 26--30}) la fifo appena creata, da cui si deve
638 riceverla, dopo di che si effettua una lettura (\texttt{\small 31})
639 nell'apposito buffer; si è supposto, come è ragionevole, che le frasi inviate
640 dal server siano sempre di dimensioni inferiori a \const{PIPE\_BUF},
641 tralasciamo la gestione del caso in cui questo non è vero. Infine si stampa
642 (\texttt{\small 32}) a video la risposta, si chiude (\texttt{\small 33}) la
643 fifo e si cancella (\texttt{\small 34}) il relativo file.
644 Si noti come la fifo per la risposta sia stata aperta solo dopo aver inviato
645 la richiesta, se non si fosse fatto così si avrebbe avuto uno stallo, in
646 quanto senza la richiesta, il server non avrebbe potuto aprirne il capo in
647 scrittura e l'apertura si sarebbe bloccata indefinitamente.
649 Verifichiamo allora il comportamento dei nostri programmi, in questo, come in
650 altri esempi precedenti, si fa uso delle varie funzioni di servizio, che sono
651 state raccolte nella libreria \file{libgapil.so}, per poter usare quest'ultima
652 occorrerà definire la variabile di ambiente \envvar{LD\_LIBRARY\_PATH} in modo
653 che il linker dinamico possa accedervi.
655 In generale questa variabile indica il \textit{pathname} della directory
656 contenente la libreria. Nell'ipotesi (che daremo sempre per verificata) che si
657 facciano le prove direttamente nella directory dei sorgenti (dove di norma
658 vengono creati sia i programmi che la libreria), il comando da dare sarà
659 \code{export LD\_LIBRARY\_PATH=./}; a questo punto potremo lanciare il server,
660 facendogli leggere una decina di frasi, con:
662 [piccardi@gont sources]$ ./fortuned -n10
666 Avendo usato \func{daemon} per eseguire il server in background il comando
667 ritornerà immediatamente, ma potremo verificare con \cmd{ps} che in effetti il
668 programma resta un esecuzione in background, e senza avere associato un
669 terminale di controllo (si ricordi quanto detto in sez.~\ref{sec:sess_daemon}):
671 [piccardi@gont sources]$ ps aux
673 piccardi 27489 0.0 0.0 1204 356 ? S 01:06 0:00 ./fortuned -n10
674 piccardi 27492 3.0 0.1 2492 764 pts/2 R 01:08 0:00 ps aux
677 e si potrà verificare anche che in \file{/tmp} è stata creata la fifo di
678 ascolto \file{fortune.fifo}. A questo punto potremo interrogare il server con
679 il programma client; otterremo così:
681 [piccardi@gont sources]$ ./fortune
682 Linux ext2fs has been stable for a long time, now it's time to break it
683 -- Linuxkongreß '95 in Berlin
684 [piccardi@gont sources]$ ./fortune
685 Let's call it an accidental feature.
687 [piccardi@gont sources]$ ./fortune
688 ......... Escape the 'Gates' of Hell
691 ::: .:: .:.::. .:: .:: `::. :'
692 ::: :: :: :: :: :: :::.
693 ::: .::. .:: ::. `::::. .:' ::.
694 ...:::.....................::' .::::..
695 -- William E. Roadcap
696 [piccardi@gont sources]$ ./fortune
697 Linux ext2fs has been stable for a long time, now it's time to break it
698 -- Linuxkongreß '95 in Berlin
701 e ripetendo varie volte il comando otterremo, in ordine casuale, le dieci
702 frasi tenute in memoria dal server.
704 Infine per chiudere il server basterà inviare un segnale di terminazione con
705 \code{killall fortuned} e potremo verificare che il gestore del segnale ha
706 anche correttamente cancellato la fifo di ascolto da \file{/tmp}.
708 Benché il nostro sistema client-server funzioni, la sua struttura è piuttosto
709 complessa e continua ad avere vari inconvenienti\footnote{lo stesso Stevens,
710 che esamina questa architettura in \cite{APUE}, nota come sia impossibile
711 per il server sapere se un client è andato in crash, con la possibilità di
712 far restare le fifo temporanee sul filesystem, di come sia necessario
713 intercettare \signal{SIGPIPE} dato che un client può terminare dopo aver
714 fatto una richiesta, ma prima che la risposta sia inviata (cosa che nel
715 nostro esempio non è stata fatta).}; in generale infatti l'interfaccia delle
716 fifo non è adatta a risolvere questo tipo di problemi, che possono essere
717 affrontati in maniera più semplice ed efficace o usando i socket (che
718 tratteremo in dettaglio a partire da cap.~\ref{cha:socket_intro}) o ricorrendo
719 a meccanismi di comunicazione diversi, come quelli che esamineremo in seguito.
723 \subsection{La funzione \func{socketpair}}
724 \label{sec:ipc_socketpair}
726 Un meccanismo di comunicazione molto simile alle pipe, ma che non presenta il
727 problema della unidirezionalità del flusso dei dati, è quello dei cosiddetti
728 \textsl{socket locali} (o \textit{Unix domain socket}). Tratteremo l'argomento
729 dei socket in cap.~\ref{cha:socket_intro},\footnote{si tratta comunque di
730 oggetti di comunicazione che, come le pipe, sono utilizzati attraverso dei
731 file descriptor.} nell'ambito dell'interfaccia generale che essi forniscono
732 per la programmazione di rete; e vedremo anche
733 (in~sez.~\ref{sec:sock_sa_local}) come si possono definire dei
734 \index{file!speciali} file speciali (di tipo socket, analoghi a quello
735 associati alle fifo) cui si accede però attraverso quella medesima
736 interfaccia; vale però la pena esaminare qui una modalità di uso dei socket
737 locali\footnote{la funzione \func{socketpair} è stata introdotta in BSD4.4, ma
738 è supportata in genere da qualunque sistema che fornisca l'interfaccia dei
739 socket.} che li rende sostanzialmente identici ad una pipe bidirezionale.
741 La funzione \funcd{socketpair} infatti consente di creare una coppia di file
742 descriptor connessi fra di loro (tramite un socket, appunto), senza dover
743 ricorrere ad un \index{file!speciali} file speciale sul filesystem, i
744 descrittori sono del tutto analoghi a quelli che si avrebbero con una chiamata
745 a \func{pipe}, con la sola differenza è che in questo caso il flusso dei dati
746 può essere effettuato in entrambe le direzioni. Il prototipo della funzione è:
748 \headdecl{sys/types.h}
749 \headdecl{sys/socket.h}
751 \funcdecl{int socketpair(int domain, int type, int protocol, int sv[2])}
753 Crea una coppia di socket connessi fra loro.
755 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
756 errore, nel qual caso \var{errno} assumerà uno dei valori:
758 \item[\errcode{EAFNOSUPPORT}] i socket locali non sono supportati.
759 \item[\errcode{EPROTONOSUPPORT}] il protocollo specificato non è supportato.
760 \item[\errcode{EOPNOTSUPP}] il protocollo specificato non supporta la
761 creazione di coppie di socket.
763 ed inoltre \errval{EMFILE}, \errval{EFAULT}.
767 La funzione restituisce in \param{sv} la coppia di descrittori connessi fra di
768 loro: quello che si scrive su uno di essi sarà ripresentato in input
769 sull'altro e viceversa. Gli argomenti \param{domain}, \param{type} e
770 \param{protocol} derivano dall'interfaccia dei socket (vedi
771 sez.~\ref{sec:sock_creation}) che è quella che fornisce il substrato per
772 connettere i due descrittori, ma in questo caso i soli valori validi che
773 possono essere specificati sono rispettivamente \const{AF\_UNIX},
774 \const{SOCK\_STREAM} e \val{0}.
776 L'utilità di chiamare questa funzione per evitare due chiamate a \func{pipe}
777 può sembrare limitata; in realtà l'utilizzo di questa funzione (e dei socket
778 locali in generale) permette di trasmettere attraverso le linea non solo dei
779 dati, ma anche dei file descriptor: si può cioè passare da un processo ad un
780 altro un file descriptor, con una sorta di duplicazione dello stesso non
781 all'interno di uno stesso processo, ma fra processi distinti (torneremo su
782 questa funzionalità in sez.~\ref{sec:sock_fd_passing}).
785 \section{L'intercomunicazione fra processi di System V}
788 Benché le pipe e le fifo siano ancora ampiamente usate, esse scontano il
789 limite fondamentale che il meccanismo di comunicazione che forniscono è
790 rigidamente sequenziale: una situazione in cui un processo scrive qualcosa che
791 molti altri devono poter leggere non può essere implementata con una pipe.
793 Per questo nello sviluppo di System V vennero introdotti una serie di nuovi
794 oggetti per la comunicazione fra processi ed una nuova interfaccia di
795 programmazione, che fossero in grado di garantire una maggiore flessibilità.
796 In questa sezione esamineremo come Linux supporta quello che viene chiamato il
797 \textsl{Sistema di comunicazione fra processi} di System V, cui da qui in
798 avanti faremo riferimento come \textit{SysV IPC} (dove IPC è la sigla di
799 \textit{Inter-Process Comunication}).
803 \subsection{Considerazioni generali}
804 \label{sec:ipc_sysv_generic}
806 La principale caratteristica del \textit{SysV IPC} è quella di essere basato
807 su oggetti permanenti che risiedono nel kernel. Questi, a differenza di quanto
808 avviene per i file descriptor, non mantengono un contatore dei riferimenti, e
809 non vengono cancellati dal sistema una volta che non sono più in uso.
811 Questo comporta due problemi: il primo è che, al contrario di quanto avviene
812 per pipe e fifo, la memoria allocata per questi oggetti non viene rilasciata
813 automaticamente quando non c'è più nessuno che li utilizzi, ed essi devono
814 essere cancellati esplicitamente, se non si vuole che restino attivi fino al
815 riavvio del sistema. Il secondo problema è che, dato che non c'è, come per i
816 file, un contatore del numero di riferimenti che ne indichi l'essere in uso,
817 essi possono essere cancellati anche se ci sono dei processi che li stanno
818 utilizzando, con tutte le conseguenze (negative) del caso.
820 Un'ulteriore caratteristica negativa è che gli oggetti usati nel \textit{SysV
821 IPC} vengono creati direttamente dal kernel, e sono accessibili solo
822 specificando il relativo \textsl{identificatore}. Questo è un numero
823 progressivo (un po' come il \ids{PID} dei processi) che il kernel assegna a
824 ciascuno di essi quanto vengono creati (sul procedimento di assegnazione
825 torneremo in sez.~\ref{sec:ipc_sysv_id_use}). L'identificatore viene restituito
826 dalle funzioni che creano l'oggetto, ed è quindi locale al processo che le ha
827 eseguite. Dato che l'identificatore viene assegnato dinamicamente dal kernel
828 non è possibile prevedere quale sarà, né utilizzare un qualche valore statico,
829 si pone perciò il problema di come processi diversi possono accedere allo
832 Per risolvere il problema nella struttura \struct{ipc\_perm} che il kernel
833 associa a ciascun oggetto, viene mantenuto anche un campo apposito che
834 contiene anche una \textsl{chiave}, identificata da una variabile del tipo
835 primitivo \type{key\_t}, da specificare in fase di creazione dell'oggetto, e
836 tramite la quale è possibile ricavare l'identificatore.\footnote{in sostanza
837 si sposta il problema dell'accesso dalla classificazione in base
838 all'identificatore alla classificazione in base alla chiave, una delle tante
839 complicazioni inutili presenti nel \textit{SysV IPC}.} Oltre la chiave, la
840 struttura, la cui definizione è riportata in fig.~\ref{fig:ipc_ipc_perm},
841 mantiene varie proprietà ed informazioni associate all'oggetto.
844 \footnotesize \centering
845 \begin{minipage}[c]{\textwidth}
846 \includestruct{listati/ipc_perm.h}
849 \caption{La struttura \structd{ipc\_perm}, come definita in
850 \headfile{sys/ipc.h}.}
851 \label{fig:ipc_ipc_perm}
854 Usando la stessa chiave due processi diversi possono ricavare l'identificatore
855 associato ad un oggetto ed accedervi. Il problema che sorge a questo punto è
856 come devono fare per accordarsi sull'uso di una stessa chiave. Se i processi
857 sono \textsl{imparentati} la soluzione è relativamente semplice, in tal caso
858 infatti si può usare il valore speciale \texttt{IPC\_PRIVATE} per creare un
859 nuovo oggetto nel processo padre, l'identificatore così ottenuto sarà
860 disponibile in tutti i figli, e potrà essere passato come argomento attraverso
863 Però quando i processi non sono \textsl{imparentati} (come capita tutte le
864 volte che si ha a che fare con un sistema client-server) tutto questo non è
865 possibile; si potrebbe comunque salvare l'identificatore su un file noto, ma
866 questo ovviamente comporta lo svantaggio di doverselo andare a rileggere. Una
867 alternativa più efficace è quella che i programmi usino un valore comune per
868 la chiave (che ad esempio può essere dichiarato in un header comune), ma c'è
869 sempre il rischio che questa chiave possa essere stata già utilizzata da
870 qualcun altro. Dato che non esiste una convenzione su come assegnare queste
871 chiavi in maniera univoca l'interfaccia mette a disposizione una funzione
872 apposita, \funcd{ftok}, che permette di ottenere una chiave specificando il
873 nome di un file ed un numero di versione; il suo prototipo è:
875 \headdecl{sys/types.h}
878 \funcdecl{key\_t ftok(const char *pathname, int proj\_id)}
880 Restituisce una chiave per identificare un oggetto del \textit{SysV IPC}.
882 \bodydesc{La funzione restituisce la chiave in caso di successo e -1
883 altrimenti, nel qual caso \var{errno} sarà uno dei possibili codici di
884 errore di \func{stat}.}
887 La funzione determina un valore della chiave sulla base di \param{pathname},
888 che deve specificare il \textit{pathname} di un file effettivamente esistente
889 e di un numero di progetto \param{proj\_id)}, che di norma viene specificato
890 come carattere, dato che ne vengono utilizzati solo gli 8 bit meno
891 significativi.\footnote{nelle libc4 e libc5, come avviene in SunOS,
892 l'argomento \param{proj\_id} è dichiarato tipo \ctyp{char}, la \acr{glibc}
893 usa il prototipo specificato da XPG4, ma vengono lo stesso utilizzati gli 8
894 bit meno significativi.}
896 Il problema è che anche così non c'è la sicurezza che il valore della chiave
897 sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
898 con i 16 bit meno significativi \itindex{inode} dell'inode del file
899 \param{pathname} (che vengono ottenuti attraverso \func{stat}, da cui derivano
900 i possibili errori), e gli 8 bit meno significativi del numero del dispositivo
901 su cui è il file. Diventa perciò relativamente facile ottenere delle
902 collisioni, specie se i file sono su dispositivi con lo stesso
903 \itindex{minor~number} \textit{minor number}, come \file{/dev/hda1} e
906 In genere quello che si fa è utilizzare un file comune usato dai programmi che
907 devono comunicare (ad esempio un header comune, o uno dei programmi che devono
908 usare l'oggetto in questione), utilizzando il numero di progetto per ottenere
909 le chiavi che interessano. In ogni caso occorre sempre controllare, prima di
910 creare un oggetto, che la chiave non sia già stata utilizzata. Se questo va
911 bene in fase di creazione, le cose possono complicarsi per i programmi che
912 devono solo accedere, in quanto, a parte gli eventuali controlli sugli altri
913 attributi di \struct{ipc\_perm}, non esiste una modalità semplice per essere
914 sicuri che l'oggetto associato ad una certa chiave sia stato effettivamente
915 creato da chi ci si aspetta.
917 Questo è, insieme al fatto che gli oggetti sono permanenti e non mantengono un
918 contatore di riferimenti per la cancellazione automatica, il principale
919 problema del \textit{SysV IPC}. Non esiste infatti una modalità chiara per
920 identificare un oggetto, come sarebbe stato se lo si fosse associato ad in
921 file, e tutta l'interfaccia è inutilmente complessa. Per questo ne è stata
922 effettuata una revisione completa nello standard POSIX.1b, che tratteremo in
923 sez.~\ref{sec:ipc_posix}.
926 \subsection{Il controllo di accesso}
927 \label{sec:ipc_sysv_access_control}
929 Oltre alle chiavi, abbiamo visto che ad ogni oggetto sono associate in
930 \struct{ipc\_perm} ulteriori informazioni, come gli identificatori del creatore
931 (nei campi \var{cuid} e \var{cgid}) e del proprietario (nei campi \var{uid} e
932 \var{gid}) dello stesso, e un insieme di permessi (nel campo \var{mode}). In
933 questo modo è possibile definire un controllo di accesso sugli oggetti di IPC,
934 simile a quello che si ha per i file (vedi sez.~\ref{sec:file_perm_overview}).
936 Benché questo controllo di accesso sia molto simile a quello dei file, restano
937 delle importanti differenze. La prima è che il permesso di esecuzione non
938 esiste (e se specificato viene ignorato), per cui si può parlare solo di
939 permessi di lettura e scrittura (nel caso dei semafori poi quest'ultimo è più
940 propriamente un permesso di modifica). I valori di \var{mode} sono gli stessi
941 ed hanno lo stesso significato di quelli riportati in
942 tab.~\ref{tab:file_mode_flags}\footnote{se però si vogliono usare le costanti
943 simboliche ivi definite occorrerà includere il file \headfile{sys/stat.h},
944 alcuni sistemi definiscono le costanti \const{MSG\_R} (\texttt{0400}) e
945 \const{MSG\_W} (\texttt{0200}) per indicare i permessi base di lettura e
946 scrittura per il proprietario, da utilizzare, con gli opportuni shift, pure
947 per il gruppo e gli altri, in Linux, visto la loro scarsa utilità, queste
948 costanti non sono definite.} e come per i file definiscono gli accessi per
949 il proprietario, il suo gruppo e tutti gli altri.
951 Quando l'oggetto viene creato i campi \var{cuid} e \var{uid} di
952 \struct{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono impostati
953 rispettivamente al valore dell'\ids{UID} e del \ids{GID} effettivo del processo
954 che ha chiamato la funzione, ma, mentre i campi \var{uid} e \var{gid} possono
955 essere cambiati, i campi \var{cuid} e \var{cgid} restano sempre gli stessi.
957 Il controllo di accesso è effettuato a due livelli. Il primo livello è nelle
958 funzioni che richiedono l'identificatore di un oggetto data la chiave. Queste
959 specificano tutte un argomento \param{flag}, in tal caso quando viene
960 effettuata la ricerca di una chiave, qualora \param{flag} specifichi dei
961 permessi, questi vengono controllati e l'identificatore viene restituito solo
962 se corrispondono a quelli dell'oggetto. Se ci sono dei permessi non presenti
963 in \var{mode} l'accesso sarà negato. Questo controllo però è di utilità
964 indicativa, dato che è sempre possibile specificare per \param{flag} un valore
965 nullo, nel qual caso l'identificatore sarà restituito comunque.
967 Il secondo livello di controllo è quello delle varie funzioni che accedono
968 direttamente (in lettura o scrittura) all'oggetto. In tal caso lo schema dei
969 controlli è simile a quello dei file, ed avviene secondo questa sequenza:
971 \item se il processo ha i privilegi di amministratore l'accesso è sempre
973 \item se l'\ids{UID} effettivo del processo corrisponde o al valore del campo
974 \var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario
975 in \var{mode} è appropriato\footnote{per appropriato si intende che è
976 impostato il permesso di scrittura per le operazioni di scrittura e quello
977 di lettura per le operazioni di lettura.} l'accesso è consentito.
978 \item se il \ids{GID} effettivo del processo corrisponde o al
979 valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso
980 per il gruppo in \var{mode} è appropriato l'accesso è consentito.
981 \item se il permesso per gli altri è appropriato l'accesso è consentito.
983 solo se tutti i controlli elencati falliscono l'accesso è negato. Si noti che
984 a differenza di quanto avviene per i permessi dei file, fallire in uno dei
985 passi elencati non comporta il fallimento dell'accesso. Un'ulteriore
986 differenza rispetto a quanto avviene per i file è che per gli oggetti di IPC
987 il valore di \itindex{umask} \textit{umask} (si ricordi quanto esposto in
988 sez.~\ref{sec:file_perm_management}) non ha alcun significato.
991 \subsection{Gli identificatori ed il loro utilizzo}
992 \label{sec:ipc_sysv_id_use}
994 L'unico campo di \struct{ipc\_perm} del quale non abbiamo ancora parlato è
995 \var{seq}, che in fig.~\ref{fig:ipc_ipc_perm} è qualificato con un criptico
996 ``\textsl{numero di sequenza}'', ne parliamo adesso dato che esso è
997 strettamente attinente alle modalità con cui il kernel assegna gli
998 identificatori degli oggetti del sistema di IPC.
1000 Quando il sistema si avvia, alla creazione di ogni nuovo oggetto di IPC viene
1001 assegnato un numero progressivo, pari al numero di oggetti di quel tipo
1002 esistenti. Se il comportamento fosse sempre questo sarebbe identico a quello
1003 usato nell'assegnazione dei file descriptor nei processi, ed i valori degli
1004 identificatori tenderebbero ad essere riutilizzati spesso e restare di piccole
1005 dimensioni (inferiori al numero massimo di oggetti disponibili).
1007 Questo va benissimo nel caso dei file descriptor, che sono locali ad un
1008 processo, ma qui il comportamento varrebbe per tutto il sistema, e per
1009 processi del tutto scorrelati fra loro. Così si potrebbero avere situazioni
1010 come quella in cui un server esce e cancella le sue code di messaggi, ed il
1011 relativo identificatore viene immediatamente assegnato a quelle di un altro
1012 server partito subito dopo, con la possibilità che i client del primo non
1013 facciano in tempo ad accorgersi dell'avvenuto, e finiscano con l'interagire
1014 con gli oggetti del secondo, con conseguenze imprevedibili.
1016 Proprio per evitare questo tipo di situazioni il sistema usa il valore di
1017 \var{seq} per provvedere un meccanismo che porti gli identificatori ad
1018 assumere tutti i valori possibili, rendendo molto più lungo il periodo in cui
1019 un identificatore può venire riutilizzato.
1021 Il sistema dispone sempre di un numero fisso di oggetti di IPC,\footnote{fino
1022 al kernel 2.2.x questi valori, definiti dalle costanti \const{MSGMNI},
1023 \const{SEMMNI} e \const{SHMMNI}, potevano essere cambiati (come tutti gli
1024 altri limiti relativi al \textit{SysV IPC}) solo con una ricompilazione del
1025 kernel, andando a modificarne la definizione nei relativi header file. A
1026 partire dal kernel 2.4.x è possibile cambiare questi valori a sistema attivo
1027 scrivendo sui file \sysctlrelfile{kernel}{shmmni},
1028 \sysctlrelfile{kernel}{msgmni} e \sysctlrelfile{kernel}{sem}
1029 di \file{/proc/sys/kernel} o con l'uso di \func{sysctl}.} e per ciascuno di
1030 essi viene mantenuto in \var{seq} un numero di sequenza progressivo che viene
1031 incrementato di uno ogni volta che l'oggetto viene cancellato. Quando
1032 l'oggetto viene creato usando uno spazio che era già stato utilizzato in
1033 precedenza per restituire l'identificatore al numero di oggetti presenti viene
1034 sommato il valore di \var{seq} moltiplicato per il numero massimo di oggetti
1035 di quel tipo,\footnote{questo vale fino ai kernel della serie 2.2.x, dalla
1036 serie 2.4.x viene usato lo stesso fattore per tutti gli oggetti, esso è dato
1037 dalla costante \const{IPCMNI}, definita in \file{include/linux/ipc.h}, che
1038 indica il limite massimo per il numero di tutti oggetti di IPC, ed il cui
1039 valore è 32768.} si evita così il riutilizzo degli stessi numeri, e si fa
1040 sì che l'identificatore assuma tutti i valori possibili.
1042 \begin{figure}[!htbp]
1043 \footnotesize \centering
1044 \begin{minipage}[c]{\codesamplewidth}
1045 \includecodesample{listati/IPCTestId.c}
1048 \caption{Sezione principale del programma di test per l'assegnazione degli
1049 identificatori degli oggetti di IPC \file{IPCTestId.c}.}
1050 \label{fig:ipc_sysv_idtest}
1053 In fig.~\ref{fig:ipc_sysv_idtest} è riportato il codice di un semplice
1054 programma di test che si limita a creare un oggetto (specificato a riga di
1055 comando), stamparne il numero di identificatore e cancellarlo per un numero
1056 specificato di volte. Al solito non si è riportato il codice della gestione
1057 delle opzioni a riga di comando, che permette di specificare quante volte
1058 effettuare il ciclo \var{n}, e su quale tipo di oggetto eseguirlo.
1060 La figura non riporta il codice di selezione delle opzioni, che permette di
1061 inizializzare i valori delle variabili \var{type} al tipo di oggetto voluto, e
1062 \var{n} al numero di volte che si vuole effettuare il ciclo di creazione,
1063 stampa, cancellazione. I valori di default sono per l'uso delle code di
1064 messaggi e un ciclo di 5 volte. Se si lancia il comando si otterrà qualcosa
1067 piccardi@gont sources]$ ./ipctestid
1069 Identifier Value 32768
1070 Identifier Value 65536
1071 Identifier Value 98304
1072 Identifier Value 131072
1075 il che ci mostra che abbiamo un kernel della serie 2.4.x nel quale non avevamo
1076 ancora usato nessuna coda di messaggi. Se ripetiamo il comando otterremo
1079 [piccardi@gont sources]$ ./ipctestid
1080 Identifier Value 163840
1081 Identifier Value 196608
1082 Identifier Value 229376
1083 Identifier Value 262144
1084 Identifier Value 294912
1087 che ci mostra come il valore di \var{seq} sia in effetti una quantità
1088 mantenuta staticamente all'interno del sistema.
1091 \subsection{Code di messaggi}
1092 \label{sec:ipc_sysv_mq}
1094 Il primo oggetto introdotto dal \textit{SysV IPC} è quello delle code di
1095 messaggi. Le code di messaggi sono oggetti analoghi alle pipe o alle fifo,
1096 anche se la loro struttura è diversa, ed il loro scopo principale è appunto
1097 quello di permettere a processi diversi di scambiarsi dei dati.
1099 La funzione che permette di richiedere al sistema l'identificatore di una coda
1100 di messaggi esistente (o di crearne una se questa non esiste) è
1101 \funcd{msgget}; il suo prototipo è:
1103 \headdecl{sys/types.h}
1104 \headdecl{sys/ipc.h}
1105 \headdecl{sys/msg.h}
1107 \funcdecl{int msgget(key\_t key, int flag)}
1109 Restituisce l'identificatore di una coda di messaggi.
1111 \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
1112 in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
1114 \item[\errcode{EACCES}] il processo chiamante non ha i privilegi per accedere
1115 alla coda richiesta.
1116 \item[\errcode{EEXIST}] si è richiesta la creazione di una coda che già
1117 esiste, ma erano specificati sia \const{IPC\_CREAT} che \const{IPC\_EXCL}.
1118 \item[\errcode{EIDRM}] la coda richiesta è marcata per essere cancellata.
1119 \item[\errcode{ENOENT}] si è cercato di ottenere l'identificatore di una coda
1120 di messaggi specificando una chiave che non esiste e \const{IPC\_CREAT}
1121 non era specificato.
1122 \item[\errcode{ENOSPC}] si è cercato di creare una coda di messaggi quando è
1123 stato superato il limite massimo di code (\const{MSGMNI}).
1125 ed inoltre \errval{ENOMEM}.
1129 Le funzione (come le analoghe che si usano per gli altri oggetti) serve sia a
1130 ottenere l'identificatore di una coda di messaggi esistente, che a crearne una
1131 nuova. L'argomento \param{key} specifica la chiave che è associata
1132 all'oggetto, eccetto il caso in cui si specifichi il valore
1133 \const{IPC\_PRIVATE}, nel qual caso la coda è creata ex-novo e non vi è
1134 associata alcuna chiave, il processo (ed i suoi eventuali figli) potranno
1135 farvi riferimento solo attraverso l'identificatore.
1137 Se invece si specifica un valore diverso da \const{IPC\_PRIVATE}\footnote{in
1138 Linux questo significa un valore diverso da zero.} l'effetto della funzione
1139 dipende dal valore di \param{flag}, se questo è nullo la funzione si limita ad
1140 effettuare una ricerca sugli oggetti esistenti, restituendo l'identificatore
1141 se trova una corrispondenza, o fallendo con un errore di \errcode{ENOENT} se
1142 non esiste o di \errcode{EACCES} se si sono specificati dei permessi non
1145 Se invece si vuole creare una nuova coda di messaggi \param{flag} non può
1146 essere nullo e deve essere fornito come maschera binaria, impostando il bit
1147 corrispondente al valore \const{IPC\_CREAT}. In questo caso i nove bit meno
1148 significativi di \param{flag} saranno usati come permessi per il nuovo
1149 oggetto, secondo quanto illustrato in sez.~\ref{sec:ipc_sysv_access_control}.
1150 Se si imposta anche il bit corrispondente a \const{IPC\_EXCL} la funzione avrà
1151 successo solo se l'oggetto non esiste già, fallendo con un errore di
1152 \errcode{EEXIST} altrimenti.
1154 Si tenga conto che l'uso di \const{IPC\_PRIVATE} non impedisce ad altri
1155 processi di accedere alla coda (se hanno privilegi sufficienti) una volta che
1156 questi possano indovinare o ricavare (ad esempio per tentativi)
1157 l'identificatore ad essa associato. Per come sono implementati gli oggetti di
1158 IPC infatti non esiste una maniera che garantisca l'accesso esclusivo ad una
1159 coda di messaggi. Usare \const{IPC\_PRIVATE} o const{IPC\_CREAT} e
1160 \const{IPC\_EXCL} per \param{flag} comporta solo la creazione di una nuova
1166 \begin{tabular}[c]{|c|r|l|l|}
1168 \textbf{Costante} & \textbf{Valore} & \textbf{File in \texttt{proc}}
1169 & \textbf{Significato} \\
1172 \const{MSGMNI}& 16& \file{msgmni} & Numero massimo di code di
1174 \const{MSGMAX}& 8192& \file{msgmax} & Dimensione massima di un singolo
1176 \const{MSGMNB}&16384& \file{msgmnb} & Dimensione massima del contenuto di
1180 \caption{Valori delle costanti associate ai limiti delle code di messaggi.}
1181 \label{tab:ipc_msg_limits}
1184 Le code di messaggi sono caratterizzate da tre limiti fondamentali, definiti
1185 negli header e corrispondenti alle prime tre costanti riportate in
1186 tab.~\ref{tab:ipc_msg_limits}, come accennato però in Linux è possibile
1187 modificare questi limiti attraverso l'uso di \func{sysctl} o scrivendo nei
1188 file \sysctlrelfile{kernel}{msgmax},
1189 \sysctlrelfile{kernel}{msgmnb} e
1190 \sysctlrelfile{kernel}{msgmni} di \file{/proc/sys/kernel/}.
1192 \begin{figure}[!htb]
1193 \centering \includegraphics[width=13cm]{img/mqstruct}
1194 \caption{Schema della struttura di una coda messaggi.}
1195 \label{fig:ipc_mq_schema}
1199 Una coda di messaggi è costituita da una \itindex{linked~list} \textit{linked
1200 list};\footnote{una \itindex{linked~list} \textit{linked list} è una tipica
1201 struttura di dati, organizzati in una lista in cui ciascun elemento contiene
1202 un puntatore al successivo. In questo modo la struttura è veloce
1203 nell'estrazione ed immissione dei dati dalle estremità dalla lista (basta
1204 aggiungere un elemento in testa o in coda ed aggiornare un puntatore), e
1205 relativamente veloce da attraversare in ordine sequenziale (seguendo i
1206 puntatori), è invece relativamente lenta nell'accesso casuale e nella
1207 ricerca.} i nuovi messaggi vengono inseriti in coda alla lista e vengono
1208 letti dalla cima, in fig.~\ref{fig:ipc_mq_schema} si è riportato lo schema con
1209 cui queste strutture vengono mantenute dal kernel.\footnote{lo schema
1210 illustrato in fig.~\ref{fig:ipc_mq_schema} è in realtà una semplificazione
1211 di quello usato effettivamente fino ai kernel della serie 2.2.x, nei kernel
1212 della serie 2.4.x la gestione delle code di messaggi è stata modificata ed è
1213 effettuata in maniera diversa; abbiamo mantenuto lo schema precedente in
1214 quanto illustra comunque in maniera più che adeguata i principi di
1215 funzionamento delle code di messaggi.}
1217 \begin{figure}[!htb]
1218 \footnotesize \centering
1219 \begin{minipage}[c]{\textwidth}
1220 \includestruct{listati/msqid_ds.h}
1223 \caption{La struttura \structd{msqid\_ds}, associata a ciascuna coda di
1225 \label{fig:ipc_msqid_ds}
1228 A ciascuna coda è associata una struttura \struct{msqid\_ds}, la cui
1229 definizione, è riportata in fig.~\ref{fig:ipc_msqid_ds}. In questa struttura
1230 il kernel mantiene le principali informazioni riguardo lo stato corrente della
1231 coda.\footnote{come accennato questo vale fino ai kernel della serie 2.2.x,
1232 essa viene usata nei kernel della serie 2.4.x solo per compatibilità in
1233 quanto è quella restituita dalle funzioni dell'interfaccia. Si noti come ci
1234 sia una differenza con i campi mostrati nello schema di
1235 fig.~\ref{fig:ipc_mq_schema} che sono presi dalla definizione di
1236 \file{include/linux/msg.h}, e fanno riferimento alla definizione della
1237 omonima struttura usata nel kernel.} In fig.~\ref{fig:ipc_msqid_ds} sono
1238 elencati i campi significativi definiti in \headfile{sys/msg.h}, a cui si sono
1239 aggiunti gli ultimi tre campi che sono previsti dalla implementazione
1240 originale di System V, ma non dallo standard Unix98.
1242 Quando si crea una nuova coda con \func{msgget} questa struttura viene
1243 inizializzata, in particolare il campo \var{msg\_perm} viene inizializzato
1244 come illustrato in sez.~\ref{sec:ipc_sysv_access_control}, per quanto riguarda
1245 gli altri campi invece:
1247 \item il campo \var{msg\_qnum}, che esprime il numero di messaggi presenti
1248 sulla coda, viene inizializzato a 0.
1249 \item i campi \var{msg\_lspid} e \var{msg\_lrpid}, che esprimono
1250 rispettivamente il \ids{PID} dell'ultimo processo che ha inviato o ricevuto
1251 un messaggio sulla coda, sono inizializzati a 0.
1252 \item i campi \var{msg\_stime} e \var{msg\_rtime}, che esprimono
1253 rispettivamente il tempo in cui è stato inviato o ricevuto l'ultimo
1254 messaggio sulla coda, sono inizializzati a 0.
1255 \item il campo \var{msg\_ctime}, che esprime il tempo di creazione della coda,
1256 viene inizializzato al tempo corrente.
1257 \item il campo \var{msg\_qbytes} che esprime la dimensione massima del
1258 contenuto della coda (in byte) viene inizializzato al valore preimpostato
1259 del sistema (\const{MSGMNB}).
1260 \item i campi \var{msg\_first} e \var{msg\_last} che esprimono l'indirizzo del
1261 primo e ultimo messaggio sono inizializzati a \val{NULL} e
1262 \var{msg\_cbytes}, che esprime la dimensione in byte dei messaggi presenti è
1263 inizializzato a zero. Questi campi sono ad uso interno dell'implementazione
1264 e non devono essere utilizzati da programmi in user space).
1267 Una volta creata una coda di messaggi le operazioni di controllo vengono
1268 effettuate con la funzione \funcd{msgctl}, che (come le analoghe \func{semctl}
1269 e \func{shmctl}) fa le veci di quello che \func{ioctl} è per i file; il suo
1272 \headdecl{sys/types.h}
1273 \headdecl{sys/ipc.h}
1274 \headdecl{sys/msg.h}
1276 \funcdecl{int msgctl(int msqid, int cmd, struct msqid\_ds *buf)}
1278 Esegue l'operazione specificata da \param{cmd} sulla coda \param{msqid}.
1280 \bodydesc{La funzione restituisce 0 in caso di successo o $-1$ in caso di
1281 errore, nel qual caso \var{errno} assumerà uno dei valori:
1283 \item[\errcode{EACCES}] si è richiesto \const{IPC\_STAT} ma processo
1284 chiamante non ha i privilegi di lettura sulla coda.
1285 \item[\errcode{EIDRM}] la coda richiesta è stata cancellata.
1286 \item[\errcode{EPERM}] si è richiesto \const{IPC\_SET} o \const{IPC\_RMID} ma
1287 il processo non ha i privilegi, o si è richiesto di aumentare il valore di
1288 \var{msg\_qbytes} oltre il limite \const{MSGMNB} senza essere
1291 ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
1295 La funzione permette di accedere ai valori della struttura \struct{msqid\_ds},
1296 mantenuta all'indirizzo \param{buf}, per la coda specificata
1297 dall'identificatore \param{msqid}. Il comportamento della funzione dipende dal
1298 valore dell'argomento \param{cmd}, che specifica il tipo di azione da
1299 eseguire; i valori possibili sono:
1300 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
1301 \item[\const{IPC\_STAT}] Legge le informazioni riguardo la coda nella
1302 struttura indicata da \param{buf}. Occorre avere il permesso di lettura
1304 \item[\const{IPC\_RMID}] Rimuove la coda, cancellando tutti i dati, con
1305 effetto immediato. Tutti i processi che cercheranno di accedere alla coda
1306 riceveranno un errore di \errcode{EIDRM}, e tutti processi in attesa su
1307 funzioni di lettura o di scrittura sulla coda saranno svegliati ricevendo
1308 il medesimo errore. Questo comando può essere eseguito solo da un processo
1309 con \ids{UID} effettivo corrispondente al creatore o al proprietario della
1310 coda, o all'amministratore.
1311 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
1312 della coda, ed il limite massimo sulle dimensioni del totale dei messaggi in
1313 essa contenuti (\var{msg\_qbytes}). I valori devono essere passati in una
1314 struttura \struct{msqid\_ds} puntata da \param{buf}. Per modificare i valori
1315 di \var{msg\_perm.mode}, \var{msg\_perm.uid} e \var{msg\_perm.gid} occorre
1316 essere il proprietario o il creatore della coda, oppure l'amministratore; lo
1317 stesso vale per \var{msg\_qbytes}, ma l'amministratore ha la facoltà di
1318 incrementarne il valore a limiti superiori a \const{MSGMNB}.
1322 Una volta che si abbia a disposizione l'identificatore, per inviare un
1323 messaggio su una coda si utilizza la funzione \funcd{msgsnd}; il suo prototipo
1326 \headdecl{sys/types.h}
1327 \headdecl{sys/ipc.h}
1328 \headdecl{sys/msg.h}
1330 \funcdecl{int msgsnd(int msqid, struct msgbuf *msgp, size\_t msgsz, int
1333 Invia un messaggio sulla coda \param{msqid}.
1335 \bodydesc{La funzione restituisce 0, e $-1$ in caso di errore, nel qual caso
1336 \var{errno} assumerà uno dei valori:
1338 \item[\errcode{EACCES}] non si hanno i privilegi di accesso sulla coda.
1339 \item[\errcode{EIDRM}] la coda è stata cancellata.
1340 \item[\errcode{EAGAIN}] il messaggio non può essere inviato perché si è
1341 superato il limite \var{msg\_qbytes} sul numero massimo di byte presenti
1342 sulla coda, e si è richiesto \const{IPC\_NOWAIT} in \param{flag}.
1343 \item[\errcode{EINVAL}] si è specificato un \param{msgid} invalido, o un
1344 valore non positivo per \param{mtype}, o un valore di \param{msgsz}
1345 maggiore di \const{MSGMAX}.
1347 ed inoltre \errval{EFAULT}, \errval{EINTR} ed \errval{ENOMEM}. }
1350 La funzione inserisce il messaggio sulla coda specificata da \param{msqid}; il
1351 messaggio ha lunghezza specificata da \param{msgsz} ed è passato attraverso il
1352 l'argomento \param{msgp}. Quest'ultimo deve venire passato sempre come
1353 puntatore ad una struttura \struct{msgbuf} analoga a quella riportata in
1354 fig.~\ref{fig:ipc_msbuf} che è quella che deve contenere effettivamente il
1355 messaggio. La dimensione massima per il testo di un messaggio non può
1356 comunque superare il limite \const{MSGMAX}.
1358 La struttura di fig.~\ref{fig:ipc_msbuf} è comunque solo un modello, tanto che
1359 la definizione contenuta in \headfile{sys/msg.h} usa esplicitamente per il
1360 secondo campo il valore \code{mtext[1]}, che non è di nessuna utilità ai fini
1361 pratici. La sola cosa che conta è che la struttura abbia come primo membro un
1362 campo \var{mtype} come nell'esempio; esso infatti serve ad identificare il
1363 tipo di messaggio e deve essere sempre specificato come intero positivo di
1364 tipo \ctyp{long}. Il campo \var{mtext} invece può essere di qualsiasi tipo e
1365 dimensione, e serve a contenere il testo del messaggio.
1367 In generale pertanto per inviare un messaggio con \func{msgsnd} si usa
1368 ridefinire una struttura simile a quella di fig.~\ref{fig:ipc_msbuf}, adattando
1369 alle proprie esigenze il campo \var{mtype}, (o ridefinendo come si vuole il
1370 corpo del messaggio, anche con più campi o con strutture più complesse) avendo
1371 però la cura di mantenere nel primo campo un valore di tipo \ctyp{long} che ne
1374 Si tenga presente che la lunghezza che deve essere indicata in questo
1375 argomento è solo quella del messaggio, non quella di tutta la struttura, se
1376 cioè \var{message} è una propria struttura che si passa alla funzione,
1377 \param{msgsz} dovrà essere uguale a \code{sizeof(message)-sizeof(long)}, (se
1378 consideriamo il caso dell'esempio in fig.~\ref{fig:ipc_msbuf}, \param{msgsz}
1379 dovrà essere pari a \const{LENGTH}).
1381 \begin{figure}[!htb]
1382 \footnotesize \centering
1383 \begin{minipage}[c]{\textwidth}
1384 \includestruct{listati/msgbuf.h}
1387 \caption{Schema della struttura \structd{msgbuf}, da utilizzare come
1388 argomento per inviare/ricevere messaggi.}
1389 \label{fig:ipc_msbuf}
1392 Per capire meglio il funzionamento della funzione riprendiamo in
1393 considerazione la struttura della coda illustrata in
1394 fig.~\ref{fig:ipc_mq_schema}. Alla chiamata di \func{msgsnd} il nuovo messaggio
1395 sarà aggiunto in fondo alla lista inserendo una nuova struttura \struct{msg},
1396 il puntatore \var{msg\_last} di \struct{msqid\_ds} verrà aggiornato, come pure
1397 il puntatore al messaggio successivo per quello che era il precedente ultimo
1398 messaggio; il valore di \var{mtype} verrà mantenuto in \var{msg\_type} ed il
1399 valore di \param{msgsz} in \var{msg\_ts}; il testo del messaggio sarà copiato
1400 all'indirizzo specificato da \var{msg\_spot}.
1402 Il valore dell'argomento \param{flag} permette di specificare il comportamento
1403 della funzione. Di norma, quando si specifica un valore nullo, la funzione
1404 ritorna immediatamente a meno che si sia ecceduto il valore di
1405 \var{msg\_qbytes}, o il limite di sistema sul numero di messaggi, nel qual
1406 caso si blocca mandando il processo in stato di \textit{sleep}. Se si
1407 specifica per \param{flag} il valore \const{IPC\_NOWAIT} la funzione opera in
1408 modalità non bloccante, ed in questi casi ritorna immediatamente con un errore
1409 di \errcode{EAGAIN}.
1411 Se non si specifica \const{IPC\_NOWAIT} la funzione resterà bloccata fintanto
1412 che non si liberano risorse sufficienti per poter inserire nella coda il
1413 messaggio, nel qual caso ritornerà normalmente. La funzione può ritornare, con
1414 una condizione di errore anche in due altri casi: quando la coda viene rimossa
1415 (nel qual caso si ha un errore di \errcode{EIDRM}) o quando la funzione viene
1416 interrotta da un segnale (nel qual caso si ha un errore di \errcode{EINTR}).
1418 Una volta completato con successo l'invio del messaggio sulla coda, la
1419 funzione aggiorna i dati mantenuti in \struct{msqid\_ds}, in particolare
1422 \item Il valore di \var{msg\_lspid}, che viene impostato al \ids{PID} del
1424 \item Il valore di \var{msg\_qnum}, che viene incrementato di uno.
1425 \item Il valore \var{msg\_stime}, che viene impostato al tempo corrente.
1428 La funzione che viene utilizzata per estrarre un messaggio da una coda è
1429 \funcd{msgrcv}; il suo prototipo è:
1431 \headdecl{sys/types.h}
1432 \headdecl{sys/ipc.h}
1433 \headdecl{sys/msg.h}
1435 \funcdecl{ssize\_t msgrcv(int msqid, struct msgbuf *msgp, size\_t msgsz,
1436 long msgtyp, int msgflg)}
1438 Legge un messaggio dalla coda \param{msqid}.
1440 \bodydesc{La funzione restituisce il numero di byte letti in caso di
1441 successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà uno
1444 \item[\errcode{EACCES}] non si hanno i privilegi di accesso sulla coda.
1445 \item[\errcode{EIDRM}] la coda è stata cancellata.
1446 \item[\errcode{E2BIG}] il testo del messaggio è più lungo di \param{msgsz} e
1447 non si è specificato \const{MSG\_NOERROR} in \param{msgflg}.
1448 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale mentre
1449 era in attesa di ricevere un messaggio.
1450 \item[\errcode{EINVAL}] si è specificato un \param{msgid} invalido o un
1451 valore di \param{msgsz} negativo.
1453 ed inoltre \errval{EFAULT}.
1457 La funzione legge un messaggio dalla coda specificata, scrivendolo sulla
1458 struttura puntata da \param{msgp}, che dovrà avere un formato analogo a quello
1459 di fig.~\ref{fig:ipc_msbuf}. Una volta estratto, il messaggio sarà rimosso
1460 dalla coda. L'argomento \param{msgsz} indica la lunghezza massima del testo
1461 del messaggio (equivalente al valore del parametro \const{LENGTH} nell'esempio
1462 di fig.~\ref{fig:ipc_msbuf}).
1464 Se il testo del messaggio ha lunghezza inferiore a \param{msgsz} esso viene
1465 rimosso dalla coda; in caso contrario, se \param{msgflg} è impostato a
1466 \const{MSG\_NOERROR}, il messaggio viene troncato e la parte in eccesso viene
1467 perduta, altrimenti il messaggio non viene estratto e la funzione ritorna con
1468 un errore di \errcode{E2BIG}.
1470 L'argomento \param{msgtyp} permette di restringere la ricerca ad un
1471 sottoinsieme dei messaggi presenti sulla coda; la ricerca infatti è fatta con
1472 una scansione della struttura mostrata in fig.~\ref{fig:ipc_mq_schema},
1473 restituendo il primo messaggio incontrato che corrisponde ai criteri
1474 specificati (che quindi, visto come i messaggi vengono sempre inseriti dalla
1475 coda, è quello meno recente); in particolare:
1477 \item se \param{msgtyp} è 0 viene estratto il messaggio in cima alla coda, cioè
1478 quello fra i presenti che è stato inserito per primo.
1479 \item se \param{msgtyp} è positivo viene estratto il primo messaggio il cui
1480 tipo (il valore del campo \var{mtype}) corrisponde al valore di
1482 \item se \param{msgtyp} è negativo viene estratto il primo fra i messaggi con
1483 il valore più basso del tipo, fra tutti quelli il cui tipo ha un valore
1484 inferiore al valore assoluto di \param{msgtyp}.
1487 Il valore di \param{msgflg} permette di controllare il comportamento della
1488 funzione, esso può essere nullo o una maschera binaria composta da uno o più
1489 valori. Oltre al precedente \const{MSG\_NOERROR}, sono possibili altri due
1490 valori: \const{MSG\_EXCEPT}, che permette, quando \param{msgtyp} è positivo,
1491 di leggere il primo messaggio nella coda con tipo diverso da \param{msgtyp}, e
1492 \const{IPC\_NOWAIT} che causa il ritorno immediato della funzione quando non
1493 ci sono messaggi sulla coda.
1495 Il comportamento usuale della funzione infatti, se non ci sono messaggi
1496 disponibili per la lettura, è di bloccare il processo in stato di
1497 \textit{sleep}. Nel caso però si sia specificato \const{IPC\_NOWAIT} la
1498 funzione ritorna immediatamente con un errore \errcode{ENOMSG}. Altrimenti la
1499 funzione ritorna normalmente non appena viene inserito un messaggio del tipo
1500 desiderato, oppure ritorna con errore qualora la coda sia rimossa (con
1501 \var{errno} impostata a \errcode{EIDRM}) o se il processo viene interrotto da
1502 un segnale (con \var{errno} impostata a \errcode{EINTR}).
1504 Una volta completata con successo l'estrazione del messaggio dalla coda, la
1505 funzione aggiorna i dati mantenuti in \struct{msqid\_ds}, in particolare
1508 \item Il valore di \var{msg\_lrpid}, che viene impostato al \ids{PID} del
1510 \item Il valore di \var{msg\_qnum}, che viene decrementato di uno.
1511 \item Il valore \var{msg\_rtime}, che viene impostato al tempo corrente.
1514 Le code di messaggi presentano il solito problema di tutti gli oggetti del
1515 SysV IPC; essendo questi permanenti restano nel sistema occupando risorse
1516 anche quando un processo è terminato, al contrario delle pipe per le quali
1517 tutte le risorse occupate vengono rilasciate quanto l'ultimo processo che le
1518 utilizzava termina. Questo comporta che in caso di errori si può saturare il
1519 sistema, e che devono comunque essere esplicitamente previste delle funzioni
1520 di rimozione in caso di interruzioni o uscite dal programma (come vedremo in
1521 fig.~\ref{fig:ipc_mq_fortune_server}).
1523 L'altro problema è non facendo uso di file descriptor le tecniche di
1524 \textit{I/O multiplexing} descritte in sez.~\ref{sec:file_multiplexing} non
1525 possono essere utilizzate, e non si ha a disposizione niente di analogo alle
1526 funzioni \func{select} e \func{poll}. Questo rende molto scomodo usare più di
1527 una di queste strutture alla volta; ad esempio non si può scrivere un server
1528 che aspetti un messaggio su più di una coda senza fare ricorso ad una tecnica
1529 di \itindex{polling} \textit{polling} che esegua un ciclo di attesa su
1532 Come esempio dell'uso delle code di messaggi possiamo riscrivere il nostro
1533 server di \textit{fortunes} usando queste al posto delle fifo. In questo caso
1534 useremo una sola coda di messaggi, usando il tipo di messaggio per comunicare
1535 in maniera indipendente con client diversi.
1537 \begin{figure}[!htbp]
1538 \footnotesize \centering
1539 \begin{minipage}[c]{\codesamplewidth}
1540 \includecodesample{listati/MQFortuneServer.c}
1543 \caption{Sezione principale del codice del server di \textit{fortunes}
1544 basato sulle \textit{message queue}.}
1545 \label{fig:ipc_mq_fortune_server}
1548 In fig.~\ref{fig:ipc_mq_fortune_server} si è riportato un estratto delle parti
1549 principali del codice del nuovo server (il codice completo è nel file
1550 \file{MQFortuneServer.c} nei sorgenti allegati). Il programma è basato su un
1551 uso accorto della caratteristica di poter associate un ``tipo'' ai messaggi
1552 per permettere una comunicazione indipendente fra il server ed i vari client,
1553 usando il \ids{PID} di questi ultimi come identificativo. Questo è possibile
1554 in quanto, al contrario di una fifo, la lettura di una coda di messaggi può
1555 non essere sequenziale, proprio grazie alla classificazione dei messaggi sulla
1558 Il programma, oltre alle solite variabili per il nome del file da cui leggere
1559 le \textit{fortunes} e per il vettore di stringhe che contiene le frasi,
1560 definisce due strutture appositamente per la comunicazione; con
1561 \var{msgbuf\_read} (\texttt{\small 8--11}) vengono passate le richieste mentre
1562 con \var{msgbuf\_write} (\texttt{\small 12--15}) vengono restituite le frasi.
1564 La gestione delle opzioni si è al solito omessa, essa si curerà di impostare
1565 in \var{n} il numero di frasi da leggere specificato a linea di comando ed in
1566 \var{fortunefilename} il file da cui leggerle; dopo aver installato
1567 (\texttt{\small 19--21}) i gestori dei segnali per trattare l'uscita dal
1568 server, viene prima controllato (\texttt{\small 22}) il numero di frasi
1569 richieste abbia senso (cioè sia maggiore di zero), le quali poi
1570 (\texttt{\small 23}) vengono lette nel vettore in memoria con la stessa
1571 funzione \code{FortuneParse} usata anche per il server basato sulle fifo.
1573 Una volta inizializzato il vettore di stringhe coi messaggi presi dal file
1574 delle \textit{fortune} si procede (\texttt{\small 25}) con la generazione di
1575 una chiave per identificare la coda di messaggi (si usa il nome del file dei
1576 sorgenti del server) con la quale poi si esegue (\texttt{\small 26}) la
1577 creazione della stessa (si noti come si sia chiamata \func{msgget} con un
1578 valore opportuno per l'argomento \param{flag}), avendo cura di abortire il
1579 programma (\texttt{\small 27--29}) in caso di errore.
1581 Finita la fase di inizializzazione il server prima (\texttt{\small 32}) chiama
1582 la funzione \func{daemon} per andare in background e poi esegue in permanenza
1583 il ciclo principale (\texttt{\small 33--40}). Questo inizia (\texttt{\small
1584 34}) con il porsi in attesa di un messaggio di richiesta da parte di un
1585 client; si noti infatti come \func{msgrcv} richieda un messaggio con
1586 \var{mtype} uguale a 1: questo è il valore usato per le richieste dato che
1587 corrisponde al \ids{PID} di \cmd{init}, che non può essere un client. L'uso
1588 del flag \const{MSG\_NOERROR} è solo per sicurezza, dato che i messaggi di
1589 richiesta sono di dimensione fissa (e contengono solo il \ids{PID} del
1592 Se non sono presenti messaggi di richiesta \func{msgrcv} si bloccherà,
1593 ritornando soltanto in corrispondenza dell'arrivo sulla coda di un messaggio
1594 di richiesta da parte di un client, in tal caso il ciclo prosegue
1595 (\texttt{\small 35}) selezionando una frase a caso, copiandola (\texttt{\small
1596 36}) nella struttura \var{msgbuf\_write} usata per la risposta e
1597 calcolandone (\texttt{\small 37}) la dimensione.
1599 Per poter permettere a ciascun client di ricevere solo la risposta indirizzata
1600 a lui il tipo del messaggio in uscita viene inizializzato (\texttt{\small 38})
1601 al valore del \ids{PID} del client ricevuto nel messaggio di richiesta.
1602 L'ultimo passo del ciclo (\texttt{\small 39}) è inviare sulla coda il
1603 messaggio di risposta. Si tenga conto che se la coda è piena anche questa
1604 funzione potrà bloccarsi fintanto che non venga liberato dello spazio.
1606 Si noti che il programma può terminare solo grazie ad una interruzione da
1607 parte di un segnale; in tal caso verrà eseguito (\texttt{\small 45--48}) il
1608 gestore \code{HandSIGTERM}, che semplicemente si limita a cancellare la coda
1609 (\texttt{\small 46}) ed ad uscire (\texttt{\small 47}).
1611 \begin{figure}[!htbp]
1612 \footnotesize \centering
1613 \begin{minipage}[c]{\codesamplewidth}
1614 \includecodesample{listati/MQFortuneClient.c}
1617 \caption{Sezione principale del codice del client di \textit{fortunes}
1618 basato sulle \textit{message queue}.}
1619 \label{fig:ipc_mq_fortune_client}
1622 In fig.~\ref{fig:ipc_mq_fortune_client} si è riportato un estratto il codice
1623 del programma client. Al solito il codice completo è con i sorgenti allegati,
1624 nel file \file{MQFortuneClient.c}. Come sempre si sono rimosse le parti
1625 relative alla gestione delle opzioni, ed in questo caso, anche la
1626 dichiarazione delle variabili, che, per la parte relative alle strutture usate
1627 per la comunicazione tramite le code, sono le stesse viste in
1628 fig.~\ref{fig:ipc_mq_fortune_server}.
1630 Il client in questo caso è molto semplice; la prima parte del programma
1631 (\texttt{\small 4--9}) si occupa di accedere alla coda di messaggi, ed è
1632 identica a quanto visto per il server, solo che in questo caso \func{msgget}
1633 non viene chiamata con il flag di creazione in quanto la coda deve essere
1634 preesistente. In caso di errore (ad esempio se il server non è stato avviato)
1635 il programma termina immediatamente.
1637 Una volta acquisito l'identificatore della coda il client compone il
1638 messaggio di richiesta (\texttt{\small 12--13}) in \var{msg\_read}, usando 1
1639 per il tipo ed inserendo il proprio \ids{PID} come dato da passare al server.
1640 Calcolata (\texttt{\small 14}) la dimensione, provvede (\texttt{\small 15}) ad
1641 immettere la richiesta sulla coda.
1643 A questo punto non resta che (\texttt{\small 16}) rileggere dalla coda la
1644 risposta del server richiedendo a \func{msgrcv} di selezionare i messaggi di
1645 tipo corrispondente al valore del \ids{PID} inviato nella richiesta. L'ultimo
1646 passo (\texttt{\small 17}) prima di uscire è quello di stampare a video il
1649 Proviamo allora il nostro nuovo sistema, al solito occorre definire
1650 \code{LD\_LIBRARY\_PATH} per accedere alla libreria \file{libgapil.so}, dopo di
1651 che, in maniera del tutto analoga a quanto fatto con il programma che usa le
1652 fifo, potremo far partire il server con:
1654 [piccardi@gont sources]$ ./mqfortuned -n10
1656 come nel caso precedente, avendo eseguito il server in background, il comando
1657 ritornerà immediatamente; potremo però verificare con \cmd{ps} che il
1658 programma è effettivamente in esecuzione, e che ha creato una coda di
1661 [piccardi@gont sources]$ ipcs
1663 ------ Shared Memory Segments --------
1664 key shmid owner perms bytes nattch status
1666 ------ Semaphore Arrays --------
1667 key semid owner perms nsems
1669 ------ Message Queues --------
1670 key msqid owner perms used-bytes messages
1671 0x0102dc6a 0 piccardi 666 0 0
1673 a questo punto potremo usare il client per ottenere le nostre frasi:
1675 [piccardi@gont sources]$ ./mqfortune
1676 Linux ext2fs has been stable for a long time, now it's time to break it
1677 -- Linuxkongreß '95 in Berlin
1678 [piccardi@gont sources]$ ./mqfortune
1679 Let's call it an accidental feature.
1682 con un risultato del tutto equivalente al precedente. Infine potremo chiudere
1683 il server inviando il segnale di terminazione con il comando \code{killall
1684 mqfortuned} verificando che effettivamente la coda di messaggi viene rimossa.
1686 Benché funzionante questa architettura risente dello stesso inconveniente
1687 visto anche nel caso del precedente server basato sulle fifo; se il client
1688 viene interrotto dopo l'invio del messaggio di richiesta e prima della lettura
1689 della risposta, quest'ultima resta nella coda (così come per le fifo si aveva
1690 il problema delle fifo che restavano nel filesystem). In questo caso però il
1691 problemi sono maggiori, sia perché è molto più facile esaurire la memoria
1692 dedicata ad una coda di messaggi che gli \itindex{inode} inode di un filesystem,
1693 sia perché, con il riutilizzo dei \ids{PID} da parte dei processi, un client
1694 eseguito in un momento successivo potrebbe ricevere un messaggio non
1699 \subsection{Semafori}
1700 \label{sec:ipc_sysv_sem}
1702 I semafori non sono meccanismi di intercomunicazione diretta come quelli
1703 (pipe, fifo e code di messaggi) visti finora, e non consentono di scambiare
1704 dati fra processi, ma servono piuttosto come meccanismi di sincronizzazione o
1705 di protezione per le \index{sezione~critica} \textsl{sezioni critiche} del
1706 codice (si ricordi quanto detto in sez.~\ref{sec:proc_race_cond}).
1708 Un semaforo è uno speciale contatore, mantenuto nel kernel, che permette, a
1709 seconda del suo valore, di consentire o meno la prosecuzione dell'esecuzione
1710 di un programma. In questo modo l'accesso ad una risorsa condivisa da più
1711 processi può essere controllato, associando ad essa un semaforo che consente
1712 di assicurare che non più di un processo alla volta possa usarla.
1714 Il concetto di semaforo è uno dei concetti base nella programmazione ed è
1715 assolutamente generico, così come del tutto generali sono modalità con cui lo
1716 si utilizza. Un processo che deve accedere ad una risorsa eseguirà un
1717 controllo del semaforo: se questo è positivo il suo valore sarà decrementato,
1718 indicando che si è consumato una unità della risorsa, ed il processo potrà
1719 proseguire nell'utilizzo di quest'ultima, provvedendo a rilasciarla, una volta
1720 completate le operazioni volute, reincrementando il semaforo.
1722 Se al momento del controllo il valore del semaforo è nullo, siamo invece in
1723 una situazione in cui la risorsa non è disponibile, ed il processo si
1724 bloccherà in stato di \textit{sleep} fin quando chi la sta utilizzando non la
1725 rilascerà, incrementando il valore del semaforo. Non appena il semaforo torna
1726 positivo, indicando che la risorsa è disponibile, il processo sarà svegliato,
1727 e si potrà operare come nel caso precedente (decremento del semaforo, accesso
1728 alla risorsa, incremento del semaforo).
1730 Per poter implementare questo tipo di logica le operazioni di controllo e
1731 decremento del contatore associato al semaforo devono essere atomiche,
1732 pertanto una realizzazione di un oggetto di questo tipo è necessariamente
1733 demandata al kernel. La forma più semplice di semaforo è quella del
1734 \textsl{semaforo binario}, o \textit{mutex}, in cui un valore diverso da zero
1735 (normalmente 1) indica la libertà di accesso, e un valore nullo l'occupazione
1736 della risorsa. In generale però si possono usare semafori con valori interi,
1737 utilizzando il valore del contatore come indicatore del ``numero di risorse''
1740 Il sistema di comunicazione inter-processo di \textit{SysV IPC} prevede anche i
1741 semafori, ma gli oggetti utilizzati non sono semafori singoli, ma gruppi di
1742 semafori detti \textsl{insiemi} (o \textit{semaphore set}); la funzione che
1743 permette di creare o ottenere l'identificatore di un insieme di semafori è
1744 \funcd{semget}, ed il suo prototipo è:
1746 \headdecl{sys/types.h}
1747 \headdecl{sys/ipc.h}
1748 \headdecl{sys/sem.h}
1750 \funcdecl{int semget(key\_t key, int nsems, int flag)}
1752 Restituisce l'identificatore di un insieme di semafori.
1754 \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
1755 in caso di errore, nel qual caso \var{errno} assumerà i valori:
1757 \item[\errcode{ENOSPC}] si è cercato di creare una insieme di semafori
1758 quando è stato superato o il limite per il numero totale di semafori
1759 (\const{SEMMNS}) o quello per il numero totale degli insiemi
1760 (\const{SEMMNI}) nel sistema.
1761 \item[\errcode{EINVAL}] l'argomento \param{nsems} è minore di zero o
1762 maggiore del limite sul numero di semafori per ciascun insieme
1763 (\const{SEMMSL}), o se l'insieme già esiste, maggiore del numero di
1764 semafori che contiene.
1765 \item[\errcode{ENOMEM}] il sistema non ha abbastanza memoria per poter
1766 contenere le strutture per un nuovo insieme di semafori.
1768 ed inoltre \errval{EACCES}, \errval{ENOENT}, \errval{EEXIST},
1769 \errval{EIDRM}, con lo stesso significato che hanno per \func{msgget}.}
1772 La funzione è del tutto analoga a \func{msgget}, solo che in questo caso
1773 restituisce l'identificatore di un insieme di semafori, in particolare è
1774 identico l'uso degli argomenti \param{key} e \param{flag}, per cui non
1775 ripeteremo quanto detto al proposito in sez.~\ref{sec:ipc_sysv_mq}. L'argomento
1776 \param{nsems} permette di specificare quanti semafori deve contenere l'insieme
1777 quando se ne richieda la creazione, e deve essere nullo quando si effettua una
1778 richiesta dell'identificatore di un insieme già esistente.
1780 Purtroppo questa implementazione complica inutilmente lo schema elementare che
1781 abbiamo descritto, dato che non è possibile definire un singolo semaforo, ma
1782 se ne deve creare per forza un insieme. Ma questa in definitiva è solo una
1783 complicazione inutile, il problema è che i semafori del \textit{SysV IPC}
1784 soffrono di altri due, ben più gravi, difetti.
1786 Il primo difetto è che non esiste una funzione che permetta di creare ed
1787 inizializzare un semaforo in un'unica chiamata; occorre prima creare l'insieme
1788 dei semafori con \func{semget} e poi inizializzarlo con \func{semctl}, si
1789 perde così ogni possibilità di eseguire l'operazione atomicamente.
1791 Il secondo difetto deriva dalla caratteristica generale degli oggetti del
1792 \textit{SysV IPC} di essere risorse globali di sistema, che non vengono
1793 cancellate quando nessuno le usa più; ci si così a trova a dover affrontare
1794 esplicitamente il caso in cui un processo termina per un qualche errore,
1795 lasciando un semaforo occupato, che resterà tale fino al successivo riavvio
1796 del sistema. Come vedremo esistono delle modalità per evitare tutto ciò, ma
1797 diventa necessario indicare esplicitamente che si vuole il ripristino del
1798 semaforo all'uscita del processo.
1800 \begin{figure}[!htb]
1801 \footnotesize \centering
1802 \begin{minipage}[c]{\textwidth}
1803 \includestruct{listati/semid_ds.h}
1806 \caption{La struttura \structd{semid\_ds}, associata a ciascun insieme di
1808 \label{fig:ipc_semid_ds}
1811 A ciascun insieme di semafori è associata una struttura \struct{semid\_ds},
1812 riportata in fig.~\ref{fig:ipc_semid_ds}.\footnote{non si sono riportati i
1813 campi ad uso interno del kernel, che vedremo in
1814 fig.~\ref{fig:ipc_sem_schema}, che dipendono dall'implementazione.} Come nel
1815 caso delle code di messaggi quando si crea un nuovo insieme di semafori con
1816 \func{semget} questa struttura viene inizializzata, in particolare il campo
1817 \var{sem\_perm} viene inizializzato come illustrato in
1818 sez.~\ref{sec:ipc_sysv_access_control} (si ricordi che in questo caso il
1819 permesso di scrittura è in realtà permesso di alterare il semaforo), per
1820 quanto riguarda gli altri campi invece:
1822 \item il campo \var{sem\_nsems}, che esprime il numero di semafori
1823 nell'insieme, viene inizializzato al valore di \param{nsems}.
1824 \item il campo \var{sem\_ctime}, che esprime il tempo di creazione
1825 dell'insieme, viene inizializzato al tempo corrente.
1826 \item il campo \var{sem\_otime}, che esprime il tempo dell'ultima operazione
1827 effettuata, viene inizializzato a zero.
1830 Ciascun semaforo dell'insieme è realizzato come una struttura di tipo
1831 \struct{sem} che ne contiene i dati essenziali, la sua definizione\footnote{si
1832 è riportata la definizione originaria del kernel 1.0, che contiene la prima
1833 realizzazione del \textit{SysV IPC} in Linux. In realtà questa struttura
1834 ormai è ridotta ai soli due primi membri, e gli altri vengono calcolati
1835 dinamicamente. La si è utilizzata a scopo di esempio, perché indica tutti i
1836 valori associati ad un semaforo, restituiti dalle funzioni di controllo, e
1837 citati dalle pagine di manuale.} è riportata in fig.~\ref{fig:ipc_sem}.
1838 Questa struttura, non è accessibile in user space, ma i valori in essa
1839 specificati possono essere letti in maniera indiretta, attraverso l'uso delle
1840 funzioni di controllo.
1842 \begin{figure}[!htb]
1843 \footnotesize \centering
1844 \begin{minipage}[c]{\textwidth}
1845 \includestruct{listati/sem.h}
1848 \caption{La struttura \structd{sem}, che contiene i dati di un singolo
1853 I dati mantenuti nella struttura, ed elencati in fig.~\ref{fig:ipc_sem},
1854 indicano rispettivamente:
1855 \begin{description*}
1856 \item[\var{semval}] il valore numerico del semaforo.
1857 \item[\var{sempid}] il \ids{PID} dell'ultimo processo che ha eseguito una
1858 operazione sul semaforo.
1859 \item[\var{semncnt}] il numero di processi in attesa che esso venga
1861 \item[\var{semzcnt}] il numero di processi in attesa che esso si annulli.
1867 \begin{tabular}[c]{|c|r|p{8cm}|}
1869 \textbf{Costante} & \textbf{Valore} & \textbf{Significato} \\
1872 \const{SEMMNI}& 128 & Numero massimo di insiemi di semafori.\\
1873 \const{SEMMSL}& 250 & Numero massimo di semafori per insieme.\\
1874 \const{SEMMNS}&\const{SEMMNI}*\const{SEMMSL}& Numero massimo di semafori
1876 \const{SEMVMX}& 32767 & Massimo valore per un semaforo.\\
1877 \const{SEMOPM}& 32 & Massimo numero di operazioni per chiamata a
1879 \const{SEMMNU}&\const{SEMMNS}& Massimo numero di strutture di ripristino.\\
1880 \const{SEMUME}&\const{SEMOPM}& Massimo numero di voci di ripristino.\\
1881 \const{SEMAEM}&\const{SEMVMX}& Valore massimo per l'aggiustamento
1885 \caption{Valori delle costanti associate ai limiti degli insiemi di
1886 semafori, definite in \file{linux/sem.h}.}
1887 \label{tab:ipc_sem_limits}
1890 Come per le code di messaggi anche per gli insiemi di semafori esistono una
1891 serie di limiti, i cui valori sono associati ad altrettante costanti, che si
1892 sono riportate in tab.~\ref{tab:ipc_sem_limits}. Alcuni di questi limiti sono
1893 al solito accessibili e modificabili attraverso \func{sysctl} o scrivendo
1894 direttamente nel file \sysctlfile{kernel/sem}.
1896 La funzione che permette di effettuare le varie operazioni di controllo sui
1897 semafori (fra le quali, come accennato, è impropriamente compresa anche la
1898 loro inizializzazione) è \funcd{semctl}; il suo prototipo è:
1900 \headdecl{sys/types.h}
1901 \headdecl{sys/ipc.h}
1902 \headdecl{sys/sem.h}
1904 \funcdecl{int semctl(int semid, int semnum, int cmd)}
1905 \funcdecl{int semctl(int semid, int semnum, int cmd, union semun arg)}
1907 Esegue le operazioni di controllo su un semaforo o un insieme di semafori.
1909 \bodydesc{La funzione restituisce in caso di successo un valore positivo
1910 quanto usata con tre argomenti ed un valore nullo quando usata con
1911 quattro. In caso di errore restituisce -1, ed \var{errno} assumerà uno dei
1914 \item[\errcode{EACCES}] il processo non ha i privilegi per eseguire
1915 l'operazione richiesta.
1916 \item[\errcode{EIDRM}] l'insieme di semafori è stato cancellato.
1917 \item[\errcode{EPERM}] si è richiesto \const{IPC\_SET} o \const{IPC\_RMID}
1918 ma il processo non ha privilegi sufficienti ad eseguire l'operazione.
1919 \item[\errcode{ERANGE}] si è richiesto \const{SETALL} \const{SETVAL} ma il
1920 valore a cui si vuole impostare il semaforo è minore di zero o maggiore
1923 ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
1927 La funzione può avere tre o quattro argomenti, a seconda dell'operazione
1928 specificata con \param{cmd}, ed opera o sull'intero insieme specificato da
1929 \param{semid} o sul singolo semaforo di un insieme, specificato da
1932 \begin{figure}[!htb]
1933 \footnotesize \centering
1934 \begin{minipage}[c]{\textwidth}
1935 \includestruct{listati/semun.h}
1938 \caption{La definizione dei possibili valori di una \direct{union}
1939 \structd{semun}, usata come quarto argomento della funzione
1941 \label{fig:ipc_semun}
1944 Qualora la funzione operi con quattro argomenti \param{arg} è un argomento
1945 generico, che conterrà un dato diverso a seconda dell'azione richiesta; per
1946 unificare l'argomento esso deve essere passato come una \struct{semun}, la cui
1947 definizione, con i possibili valori che può assumere, è riportata in
1948 fig.~\ref{fig:ipc_semun}.
1950 Come già accennato sia il comportamento della funzione che il numero di
1951 argomenti con cui deve essere invocata dipendono dal valore dell'argomento
1952 \param{cmd}, che specifica l'azione da intraprendere; i valori validi (che
1953 cioè non causano un errore di \errcode{EINVAL}) per questo argomento sono i
1955 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
1956 \item[\const{IPC\_STAT}] Legge i dati dell'insieme di semafori, copiando il
1957 contenuto della relativa struttura \struct{semid\_ds} all'indirizzo
1958 specificato con \var{arg.buf}. Occorre avere il permesso di lettura.
1959 L'argomento \param{semnum} viene ignorato.
1960 \item[\const{IPC\_RMID}] Rimuove l'insieme di semafori e le relative strutture
1961 dati, con effetto immediato. Tutti i processi che erano stato di
1962 \textit{sleep} vengono svegliati, ritornando con un errore di
1963 \errcode{EIDRM}. L'\ids{UID} effettivo del processo deve corrispondere o al
1964 creatore o al proprietario dell'insieme, o all'amministratore. L'argomento
1965 \param{semnum} viene ignorato.
1966 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
1967 dell'insieme. I valori devono essere passati in una struttura
1968 \struct{semid\_ds} puntata da \param{arg.buf} di cui saranno usati soltanto i
1969 campi \var{sem\_perm.uid}, \var{sem\_perm.gid} e i nove bit meno
1970 significativi di \var{sem\_perm.mode}. L'\ids{UID} effettivo del processo deve
1971 corrispondere o al creatore o al proprietario dell'insieme, o
1972 all'amministratore. L'argomento \param{semnum} viene ignorato.
1973 \item[\const{GETALL}] Restituisce il valore corrente di ciascun semaforo
1974 dell'insieme (corrispondente al campo \var{semval} di \struct{sem}) nel
1975 vettore indicato da \param{arg.array}. Occorre avere il permesso di lettura.
1976 L'argomento \param{semnum} viene ignorato.
1977 \item[\const{GETNCNT}] Restituisce come valore di ritorno della funzione il
1978 numero di processi in attesa che il semaforo \param{semnum} dell'insieme
1979 \param{semid} venga incrementato (corrispondente al campo \var{semncnt} di
1980 \struct{sem}); va invocata con tre argomenti. Occorre avere il permesso di
1982 \item[\const{GETPID}] Restituisce come valore di ritorno della funzione il
1983 \ids{PID} dell'ultimo processo che ha compiuto una operazione sul semaforo
1984 \param{semnum} dell'insieme \param{semid} (corrispondente al campo
1985 \var{sempid} di \struct{sem}); va invocata con tre argomenti. Occorre avere
1986 il permesso di lettura.
1987 \item[\const{GETVAL}] Restituisce come valore di ritorno della funzione il il
1988 valore corrente del semaforo \param{semnum} dell'insieme \param{semid}
1989 (corrispondente al campo \var{semval} di \struct{sem}); va invocata con tre
1990 argomenti. Occorre avere il permesso di lettura.
1991 \item[\const{GETZCNT}] Restituisce come valore di ritorno della funzione il
1992 numero di processi in attesa che il valore del semaforo \param{semnum}
1993 dell'insieme \param{semid} diventi nullo (corrispondente al campo
1994 \var{semncnt} di \struct{sem}); va invocata con tre argomenti. Occorre avere
1995 il permesso di lettura.
1996 \item[\const{SETALL}] Inizializza il valore di tutti i semafori dell'insieme,
1997 aggiornando il campo \var{sem\_ctime} di \struct{semid\_ds}. I valori devono
1998 essere passati nel vettore indicato da \param{arg.array}. Si devono avere i
1999 privilegi di scrittura sul semaforo. L'argomento \param{semnum} viene
2001 \item[\const{SETVAL}] Inizializza il semaforo \param{semnum} al valore passato
2002 dall'argomento \param{arg.val}, aggiornando il campo \var{sem\_ctime} di
2003 \struct{semid\_ds}. Si devono avere i privilegi di scrittura sul semaforo.
2006 Quando si imposta il valore di un semaforo (sia che lo si faccia per tutto
2007 l'insieme con \const{SETALL}, che per un solo semaforo con \const{SETVAL}), i
2008 processi in attesa su di esso reagiscono di conseguenza al cambiamento di
2009 valore. Inoltre la coda delle operazioni di ripristino viene cancellata per
2010 tutti i semafori il cui valore viene modificato.
2015 \begin{tabular}[c]{|c|l|}
2017 \textbf{Operazione} & \textbf{Valore restituito} \\
2020 \const{GETNCNT}& Valore di \var{semncnt}.\\
2021 \const{GETPID} & Valore di \var{sempid}.\\
2022 \const{GETVAL} & Valore di \var{semval}.\\
2023 \const{GETZCNT}& Valore di \var{semzcnt}.\\
2026 \caption{Valori di ritorno della funzione \func{semctl}.}
2027 \label{tab:ipc_semctl_returns}
2030 Il valore di ritorno della funzione in caso di successo dipende
2031 dall'operazione richiesta; per tutte le operazioni che richiedono quattro
2032 argomenti esso è sempre nullo, per le altre operazioni, elencate in
2033 tab.~\ref{tab:ipc_semctl_returns} viene invece restituito il valore richiesto,
2034 corrispondente al campo della struttura \struct{sem} indicato nella seconda
2035 colonna della tabella.
2037 Le operazioni ordinarie sui semafori, come l'acquisizione o il rilascio degli
2038 stessi (in sostanza tutte quelle non comprese nell'uso di \func{semctl})
2039 vengono effettuate con la funzione \funcd{semop}, il cui prototipo è:
2041 \headdecl{sys/types.h}
2042 \headdecl{sys/ipc.h}
2043 \headdecl{sys/sem.h}
2045 \funcdecl{int semop(int semid, struct sembuf *sops, unsigned nsops)}
2047 Esegue le operazioni ordinarie su un semaforo o un insieme di semafori.
2049 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
2050 errore, nel qual caso \var{errno} assumerà uno dei valori:
2052 \item[\errcode{EACCES}] il processo non ha i privilegi per eseguire
2053 l'operazione richiesta.
2054 \item[\errcode{EIDRM}] l'insieme di semafori è stato cancellato.
2055 \item[\errcode{ENOMEM}] si è richiesto un \const{SEM\_UNDO} ma il sistema
2056 non ha le risorse per allocare la struttura di ripristino.
2057 \item[\errcode{EAGAIN}] un'operazione comporterebbe il blocco del processo,
2058 ma si è specificato \const{IPC\_NOWAIT} in \var{sem\_flg}.
2059 \item[\errcode{EINTR}] la funzione, bloccata in attesa dell'esecuzione
2060 dell'operazione, viene interrotta da un segnale.
2061 \item[\errcode{E2BIG}] l'argomento \param{nsops} è maggiore del numero
2062 massimo di operazioni \const{SEMOPM}.
2063 \item[\errcode{ERANGE}] per alcune operazioni il valore risultante del
2064 semaforo viene a superare il limite massimo \const{SEMVMX}.
2066 ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
2071 %TODO manca semtimedop, trattare qui, referenziata in
2072 %sez.~\ref{sec:sig_gen_beha}.
2074 La funzione permette di eseguire operazioni multiple sui singoli semafori di
2075 un insieme. La funzione richiede come primo argomento l'identificatore
2076 \param{semid} dell'insieme su cui si vuole operare. Il numero di operazioni da
2077 effettuare viene specificato con l'argomento \param{nsop}, mentre il loro
2078 contenuto viene passato con un puntatore ad un vettore di strutture
2079 \struct{sembuf} nell'argomento \param{sops}. Le operazioni richieste vengono
2080 effettivamente eseguite se e soltanto se è possibile effettuarle tutte quante.
2082 \begin{figure}[!htb]
2083 \footnotesize \centering
2084 \begin{minipage}[c]{\textwidth}
2085 \includestruct{listati/sembuf.h}
2088 \caption{La struttura \structd{sembuf}, usata per le operazioni sui
2090 \label{fig:ipc_sembuf}
2093 Il contenuto di ciascuna operazione deve essere specificato attraverso una
2094 opportuna struttura \struct{sembuf} (la cui definizione è riportata in
2095 fig.~\ref{fig:ipc_sembuf}) che il programma chiamante deve avere cura di
2096 allocare in un opportuno vettore. La struttura permette di indicare il
2097 semaforo su cui operare, il tipo di operazione, ed un flag di controllo.
2098 Il campo \var{sem\_num} serve per indicare a quale semaforo dell'insieme fa
2099 riferimento l'operazione; si ricordi che i semafori sono numerati come in un
2100 vettore, per cui il primo semaforo corrisponde ad un valore nullo di
2103 Il campo \var{sem\_flg} è un flag, mantenuto come maschera binaria, per il
2104 quale possono essere impostati i due valori \const{IPC\_NOWAIT} e
2105 \const{SEM\_UNDO}. Impostando \const{IPC\_NOWAIT} si fa si che, invece di
2106 bloccarsi (in tutti quei casi in cui l'esecuzione di una operazione richiede
2107 che il processo vada in stato di \textit{sleep}), \func{semop} ritorni
2108 immediatamente con un errore di \errcode{EAGAIN}. Impostando \const{SEM\_UNDO}
2109 si richiede invece che l'operazione venga registrata in modo che il valore del
2110 semaforo possa essere ripristinato all'uscita del processo.
2112 Infine \var{sem\_op} è il campo che controlla l'operazione che viene eseguita
2113 e determina il comportamento della chiamata a \func{semop}; tre sono i casi
2115 \begin{basedescript}{\desclabelwidth{2.0cm}}
2116 \item[\var{sem\_op}$>0$] In questo caso il valore di \var{sem\_op} viene
2117 aggiunto al valore corrente di \var{semval}. La funzione ritorna
2118 immediatamente (con un errore di \errcode{ERANGE} qualora si sia superato il
2119 limite \const{SEMVMX}) ed il processo non viene bloccato in nessun caso.
2120 Specificando \const{SEM\_UNDO} si aggiorna il contatore per il ripristino
2121 del valore del semaforo. Al processo chiamante è richiesto il privilegio di
2122 alterazione (scrittura) sull'insieme di semafori.
2124 \item[\var{sem\_op}$=0$] Nel caso \var{semval} sia zero l'esecuzione procede
2125 immediatamente. Se \var{semval} è diverso da zero il comportamento è
2126 controllato da \var{sem\_flg}, se è stato impostato \const{IPC\_NOWAIT} la
2127 funzione ritorna con un errore di \errcode{EAGAIN}, altrimenti viene
2128 incrementato \var{semzcnt} di uno ed il processo resta in stato di
2129 \textit{sleep} fintanto che non si ha una delle condizioni seguenti:
2131 \item \var{semval} diventa zero, nel qual caso \var{semzcnt} viene
2132 decrementato di uno.
2133 \item l'insieme di semafori viene rimosso, nel qual caso \func{semop} ritorna
2134 un errore di \errcode{EIDRM}.
2135 \item il processo chiamante riceve un segnale, nel qual caso \var{semzcnt}
2136 viene decrementato di uno e \func{semop} ritorna un errore di
2139 Al processo chiamante è richiesto il privilegio di lettura dell'insieme dei
2142 \item[\var{sem\_op}$<0$] Nel caso in cui \var{semval} è maggiore o uguale del
2143 valore assoluto di \var{sem\_op} (se cioè la somma dei due valori resta
2144 positiva o nulla) i valori vengono sommati e la funzione ritorna
2145 immediatamente; qualora si sia impostato \const{SEM\_UNDO} viene anche
2146 aggiornato il contatore per il ripristino del valore del semaforo. In caso
2147 contrario (quando cioè la somma darebbe luogo ad un valore di \var{semval}
2148 negativo) se si è impostato \const{IPC\_NOWAIT} la funzione ritorna con un
2149 errore di \errcode{EAGAIN}, altrimenti viene incrementato di uno
2150 \var{semncnt} ed il processo resta in stato di \textit{sleep} fintanto che
2151 non si ha una delle condizioni seguenti:
2153 \item \var{semval} diventa maggiore o uguale del valore assoluto di
2154 \var{sem\_op}, nel qual caso \var{semncnt} viene decrementato di uno, il
2155 valore di \var{sem\_op} viene sommato a \var{semval}, e se era stato
2156 impostato \const{SEM\_UNDO} viene aggiornato il contatore per il
2157 ripristino del valore del semaforo.
2158 \item l'insieme di semafori viene rimosso, nel qual caso \func{semop}
2159 ritorna un errore di \errcode{EIDRM}.
2160 \item il processo chiamante riceve un segnale, nel qual caso \var{semncnt}
2161 viene decrementato di uno e \func{semop} ritorna un errore di
2164 Al processo chiamante è richiesto il privilegio di alterazione (scrittura)
2165 sull'insieme di semafori.
2168 In caso di successo della funzione viene aggiornato il campo \var{sempid} per
2169 ogni semaforo modificato al valore del \ids{PID} del processo chiamante;
2170 inoltre vengono pure aggiornati al tempo corrente i campi \var{sem\_otime} e
2173 Dato che, come già accennato in precedenza, in caso di uscita inaspettata i
2174 semafori possono restare occupati, abbiamo visto come \func{semop} permetta di
2175 attivare un meccanismo di ripristino attraverso l'uso del flag
2176 \const{SEM\_UNDO}. Il meccanismo è implementato tramite una apposita struttura
2177 \kstruct{sem\_undo}, associata ad ogni processo per ciascun semaforo che esso
2178 ha modificato; all'uscita i semafori modificati vengono ripristinati, e le
2179 strutture disallocate. Per mantenere coerente il comportamento queste
2180 strutture non vengono ereditate attraverso una \func{fork} (altrimenti si
2181 avrebbe un doppio ripristino), mentre passano inalterate nell'esecuzione di
2182 una \func{exec} (altrimenti non si avrebbe ripristino).
2184 Tutto questo però ha un problema di fondo. Per capire di cosa si tratta
2185 occorre fare riferimento all'implementazione usata in Linux, che è riportata
2186 in maniera semplificata nello schema di fig.~\ref{fig:ipc_sem_schema}. Si è
2187 presa come riferimento l'architettura usata fino al kernel 2.2.x che è più
2188 semplice (ed illustrata in dettaglio in \cite{tlk}); nel kernel 2.4.x la
2189 struttura del \textit{SysV IPC} è stata modificata, ma le definizioni relative
2190 a queste strutture restano per compatibilità.\footnote{in particolare con le
2191 vecchie versioni delle librerie del C, come le libc5.}
2193 \begin{figure}[!htb]
2194 \centering \includegraphics[width=13cm]{img/semtruct}
2195 \caption{Schema della struttura di un insieme di semafori.}
2196 \label{fig:ipc_sem_schema}
2199 Alla creazione di un nuovo insieme viene allocata una nuova strutture
2200 \struct{semid\_ds} ed il relativo vettore di strutture \struct{sem}. Quando si
2201 richiede una operazione viene anzitutto verificato che tutte le operazioni
2202 possono avere successo; se una di esse comporta il blocco del processo il
2203 kernel crea una struttura \kstruct{sem\_queue} che viene aggiunta in fondo alla
2204 coda di attesa associata a ciascun insieme di semafori\footnote{che viene
2205 referenziata tramite i campi \var{sem\_pending} e \var{sem\_pending\_last}
2206 di \struct{semid\_ds}.}.
2208 Nella struttura viene memorizzato il riferimento alle operazioni richieste
2209 (nel campo \var{sops}, che è un puntatore ad una struttura \struct{sembuf}) e
2210 al processo corrente (nel campo \var{sleeper}) poi quest'ultimo viene messo
2211 stato di attesa e viene invocato lo \itindex{scheduler} scheduler per passare
2212 all'esecuzione di un altro processo.
2214 Se invece tutte le operazioni possono avere successo queste vengono eseguite
2215 immediatamente, dopo di che il kernel esegue una scansione della coda di
2216 attesa (a partire da \var{sem\_pending}) per verificare se qualcuna delle
2217 operazioni sospese in precedenza può essere eseguita, nel qual caso la
2218 struttura \kstruct{sem\_queue} viene rimossa e lo stato del processo associato
2219 all'operazione (\var{sleeper}) viene riportato a \textit{running}; il tutto
2220 viene ripetuto fin quando non ci sono più operazioni eseguibili o si è
2221 svuotata la coda. Per gestire il meccanismo del ripristino tutte le volte che
2222 per un'operazione si è specificato il flag \const{SEM\_UNDO} viene mantenuta
2223 per ciascun insieme di semafori una apposita struttura \kstruct{sem\_undo} che
2224 contiene (nel vettore puntato dal campo \var{semadj}) un valore di
2225 aggiustamento per ogni semaforo cui viene sommato l'opposto del valore usato
2228 %TODO verificare queste strutture \kstruct{sem\_queue} e \kstruct{sem\_undo}
2230 Queste strutture sono mantenute in due liste,\footnote{rispettivamente
2231 attraverso i due campi \var{id\_next} e \var{proc\_next}.} una associata
2232 all'insieme di cui fa parte il semaforo, che viene usata per invalidare le
2233 strutture se questo viene cancellato o per azzerarle se si è eseguita una
2234 operazione con \func{semctl}; l'altra associata al processo che ha eseguito
2235 l'operazione;\footnote{attraverso il campo \var{semundo} di
2236 \kstruct{task\_struct}, come mostrato in \ref{fig:ipc_sem_schema}.} quando un
2237 processo termina, la lista ad esso associata viene scandita e le operazioni
2238 applicate al semaforo. Siccome un processo può accumulare delle richieste di
2239 ripristino per semafori differenti chiamate attraverso diverse chiamate a
2240 \func{semop}, si pone il problema di come eseguire il ripristino dei semafori
2241 all'uscita del processo, ed in particolare se questo può essere fatto
2244 Il punto è cosa succede quando una delle operazioni previste per il ripristino
2245 non può essere eseguita immediatamente perché ad esempio il semaforo è
2246 occupato; in tal caso infatti, se si pone il processo in stato di
2247 \textit{sleep} aspettando la disponibilità del semaforo (come faceva
2248 l'implementazione originaria) si perde l'atomicità dell'operazione. La scelta
2249 fatta dal kernel è pertanto quella di effettuare subito le operazioni che non
2250 prevedono un blocco del processo e di ignorare silenziosamente le altre;
2251 questo però comporta il fatto che il ripristino non è comunque garantito in
2254 Come esempio di uso dell'interfaccia dei semafori vediamo come implementare
2255 con essa dei semplici \textit{mutex} (cioè semafori binari), tutto il codice
2256 in questione, contenuto nel file \file{Mutex.c} allegato ai sorgenti, è
2257 riportato in fig.~\ref{fig:ipc_mutex_create}. Utilizzeremo l'interfaccia per
2258 creare un insieme contenente un singolo semaforo, per il quale poi useremo un
2259 valore unitario per segnalare la disponibilità della risorsa, ed un valore
2260 nullo per segnalarne l'indisponibilità.
2262 \begin{figure}[!htbp]
2263 \footnotesize \centering
2264 \begin{minipage}[c]{\codesamplewidth}
2265 \includecodesample{listati/Mutex.c}
2268 \caption{Il codice delle funzioni che permettono di creare o recuperare
2269 l'identificatore di un semaforo da utilizzare come \textit{mutex}.}
2270 \label{fig:ipc_mutex_create}
2273 La prima funzione (\texttt{\small 2--15}) è \func{MutexCreate} che data una
2274 chiave crea il semaforo usato per il mutex e lo inizializza, restituendone
2275 l'identificatore. Il primo passo (\texttt{\small 6}) è chiamare \func{semget}
2276 con \const{IPC\_CREATE} per creare il semaforo qualora non esista,
2277 assegnandogli i privilegi di lettura e scrittura per tutti. In caso di errore
2278 (\texttt{\small 7--9}) si ritorna subito il risultato di \func{semget},
2279 altrimenti (\texttt{\small 10}) si inizializza il semaforo chiamando
2280 \func{semctl} con il comando \const{SETVAL}, utilizzando l'unione
2281 \struct{semunion} dichiarata ed avvalorata in precedenza (\texttt{\small 4})
2282 ad 1 per significare che risorsa è libera. In caso di errore (\texttt{\small
2283 11--13}) si restituisce il valore di ritorno di \func{semctl}, altrimenti
2284 (\texttt{\small 14}) si ritorna l'identificatore del semaforo.
2286 La seconda funzione (\texttt{\small 17--20}) è \func{MutexFind}, che, data una
2287 chiave, restituisce l'identificatore del semaforo ad essa associato. La
2288 comprensione del suo funzionamento è immediata in quanto essa è soltanto un
2289 \textit{wrapper}\footnote{si chiama così una funzione usata per fare da
2290 \textsl{involucro} alla chiamata di un altra, usata in genere per
2291 semplificare un'interfaccia (come in questo caso) o per utilizzare con la
2292 stessa funzione diversi substrati (librerie, ecc.) che possono fornire le
2293 stesse funzionalità.} di una chiamata a \func{semget} per cercare
2294 l'identificatore associato alla chiave, il valore di ritorno di quest'ultima
2295 viene passato all'indietro al chiamante.
2297 La terza funzione (\texttt{\small 22--25}) è \func{MutexRead} che, dato un
2298 identificatore, restituisce il valore del semaforo associato al mutex. Anche
2299 in questo caso la funzione è un \textit{wrapper} per una chiamata a
2300 \func{semctl} con il comando \const{GETVAL}, che permette di restituire il
2301 valore del semaforo.
2303 La quarta e la quinta funzione (\texttt{\small 36--44}) sono \func{MutexLock},
2304 e \func{MutexUnlock}, che permettono rispettivamente di bloccare e sbloccare
2305 il mutex. Entrambe fanno da wrapper per \func{semop}, utilizzando le due
2306 strutture \var{sem\_lock} e \var{sem\_unlock} definite in precedenza
2307 (\texttt{\small 27--34}). Si noti come per queste ultime si sia fatto uso
2308 dell'opzione \const{SEM\_UNDO} per evitare che il semaforo resti bloccato in
2309 caso di terminazione imprevista del processo.
2311 L'ultima funzione (\texttt{\small 46--49}) della serie, è \func{MutexRemove},
2312 che rimuove il mutex. Anche in questo caso si ha un wrapper per una chiamata a
2313 \func{semctl} con il comando \const{IPC\_RMID}, che permette di cancellare il
2314 semaforo; il valore di ritorno di quest'ultima viene passato all'indietro.
2316 Chiamare \func{MutexLock} decrementa il valore del semaforo: se questo è
2317 libero (ha già valore 1) sarà bloccato (valore nullo), se è bloccato la
2318 chiamata a \func{semop} si bloccherà fintanto che la risorsa non venga
2319 rilasciata. Chiamando \func{MutexUnlock} il valore del semaforo sarà
2320 incrementato di uno, sbloccandolo qualora fosse bloccato.
2322 Si noti che occorre eseguire sempre prima \func{MutexLock} e poi
2323 \func{MutexUnlock}, perché se per un qualche errore si esegue più volte
2324 quest'ultima il valore del semaforo crescerebbe oltre 1, e \func{MutexLock}
2325 non avrebbe più l'effetto aspettato (bloccare la risorsa quando questa è
2326 considerata libera). Infine si tenga presente che usare \func{MutexRead} per
2327 controllare il valore dei mutex prima di proseguire in una operazione di
2328 sblocco non servirebbe comunque, dato che l'operazione non sarebbe atomica.
2329 Vedremo in sez.~\ref{sec:ipc_lock_file} come sia possibile ottenere
2330 un'interfaccia analoga a quella appena illustrata, senza incorrere in questi
2331 problemi, usando il \itindex{file~locking} \textit{file locking}.
2334 \subsection{Memoria condivisa}
2335 \label{sec:ipc_sysv_shm}
2337 Il terzo oggetto introdotto dal \textit{SysV IPC} è quello dei segmenti di
2338 memoria condivisa. La funzione che permette di ottenerne uno è \funcd{shmget},
2339 ed il suo prototipo è:
2341 \headdecl{sys/types.h}
2342 \headdecl{sys/ipc.h}
2343 \headdecl{sys/shm.h}
2345 \funcdecl{int shmget(key\_t key, int size, int flag)}
2347 Restituisce l'identificatore di una memoria condivisa.
2349 \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
2350 in caso di errore, nel qual caso \var{errno} assumerà i valori:
2352 \item[\errcode{ENOSPC}] si è superato il limite (\const{SHMMNI}) sul numero
2353 di segmenti di memoria nel sistema, o cercato di allocare un segmento le
2354 cui dimensioni fanno superare il limite di sistema (\const{SHMALL}) per
2355 la memoria ad essi riservata.
2356 \item[\errcode{EINVAL}] si è richiesta una dimensione per un nuovo segmento
2357 maggiore di \const{SHMMAX} o minore di \const{SHMMIN}, o se il segmento
2358 già esiste \param{size} è maggiore delle sue dimensioni.
2359 \item[\errcode{ENOMEM}] il sistema non ha abbastanza memoria per poter
2360 contenere le strutture per un nuovo segmento di memoria condivisa.
2362 ed inoltre \errval{EACCES}, \errval{ENOENT}, \errval{EEXIST},
2363 \errval{EIDRM}, con lo stesso significato che hanno per \func{msgget}.}
2366 La funzione, come \func{semget}, è del tutto analoga a \func{msgget}, ed
2367 identico è l'uso degli argomenti \param{key} e \param{flag} per cui non
2368 ripeteremo quanto detto al proposito in sez.~\ref{sec:ipc_sysv_mq}. L'argomento
2369 \param{size} specifica invece la dimensione, in byte, del segmento, che viene
2370 comunque arrotondata al multiplo superiore di \const{PAGE\_SIZE}.
2372 La memoria condivisa è la forma più veloce di comunicazione fra due processi,
2373 in quanto permette agli stessi di vedere nel loro spazio di indirizzi una
2374 stessa sezione di memoria. Pertanto non è necessaria nessuna operazione di
2375 copia per trasmettere i dati da un processo all'altro, in quanto ciascuno può
2376 accedervi direttamente con le normali operazioni di lettura e scrittura dei
2379 Ovviamente tutto questo ha un prezzo, ed il problema fondamentale della
2380 memoria condivisa è la sincronizzazione degli accessi. È evidente infatti che
2381 se un processo deve scambiare dei dati con un altro, si deve essere sicuri che
2382 quest'ultimo non acceda al segmento di memoria condivisa prima che il primo
2383 non abbia completato le operazioni di scrittura, inoltre nel corso di una
2384 lettura si deve essere sicuri che i dati restano coerenti e non vengono
2385 sovrascritti da un accesso in scrittura sullo stesso segmento da parte di un
2386 altro processo. Per questo in genere la memoria condivisa viene sempre
2387 utilizzata in abbinamento ad un meccanismo di sincronizzazione, il che, di
2388 norma, significa insieme a dei semafori.
2390 \begin{figure}[!htb]
2391 \footnotesize \centering
2392 \begin{minipage}[c]{\textwidth}
2393 \includestruct{listati/shmid_ds.h}
2396 \caption{La struttura \structd{shmid\_ds}, associata a ciascun segmento di
2398 \label{fig:ipc_shmid_ds}
2401 A ciascun segmento di memoria condivisa è associata una struttura
2402 \struct{shmid\_ds}, riportata in fig.~\ref{fig:ipc_shmid_ds}. Come nel caso
2403 delle code di messaggi quando si crea un nuovo segmento di memoria condivisa
2404 con \func{shmget} questa struttura viene inizializzata, in particolare il
2405 campo \var{shm\_perm} viene inizializzato come illustrato in
2406 sez.~\ref{sec:ipc_sysv_access_control}, e valgono le considerazioni ivi fatte
2407 relativamente ai permessi di accesso; per quanto riguarda gli altri campi
2410 \item il campo \var{shm\_segsz}, che esprime la dimensione del segmento, viene
2411 inizializzato al valore di \param{size}.
2412 \item il campo \var{shm\_ctime}, che esprime il tempo di creazione del
2413 segmento, viene inizializzato al tempo corrente.
2414 \item i campi \var{shm\_atime} e \var{shm\_dtime}, che esprimono
2415 rispettivamente il tempo dell'ultima volta che il segmento è stato
2416 agganciato o sganciato da un processo, vengono inizializzati a zero.
2417 \item il campo \var{shm\_lpid}, che esprime il \ids{PID} del processo che ha
2418 eseguito l'ultima operazione, viene inizializzato a zero.
2419 \item il campo \var{shm\_cpid}, che esprime il \ids{PID} del processo che ha
2420 creato il segmento, viene inizializzato al \ids{PID} del processo chiamante.
2421 \item il campo \var{shm\_nattac}, che esprime il numero di processi agganciati
2422 al segmento viene inizializzato a zero.
2425 Come per le code di messaggi e gli insiemi di semafori, anche per i segmenti
2426 di memoria condivisa esistono una serie di limiti imposti dal sistema. Alcuni
2427 di questi limiti sono al solito accessibili e modificabili attraverso
2428 \func{sysctl} o scrivendo direttamente nei rispettivi file di
2429 \file{/proc/sys/kernel/}.
2431 In tab.~\ref{tab:ipc_shm_limits} si sono riportate le
2432 costanti simboliche associate a ciascuno di essi, il loro significato, i
2433 valori preimpostati, e, quando presente, il file in \file{/proc/sys/kernel/}
2434 che permettono di cambiarne il valore.
2440 \begin{tabular}[c]{|c|r|c|p{7cm}|}
2442 \textbf{Costante} & \textbf{Valore} & \textbf{File in \texttt{proc}}
2443 & \textbf{Significato} \\
2446 \const{SHMALL}& 0x200000&\sysctlrelfile{kernel}{shmall}
2447 & Numero massimo di pagine che
2448 possono essere usate per i segmenti di
2449 memoria condivisa.\\
2450 \const{SHMMAX}&0x2000000&\sysctlrelfile{kernel}{shmmax}
2451 & Dimensione massima di un segmento di memoria
2453 \const{SHMMNI}& 4096&\sysctlrelfile{kernel}{msgmni}
2454 & Numero massimo di segmenti di memoria condivisa
2455 presenti nel kernel.\\
2456 \const{SHMMIN}& 1& --- & Dimensione minima di un segmento di
2457 memoria condivisa.\\
2458 \const{SHMLBA}&\const{PAGE\_SIZE}&--- & Limite inferiore per le dimensioni
2459 minime di un segmento (deve essere
2460 allineato alle dimensioni di una
2461 pagina di memoria).\\
2462 \const{SHMSEG}& --- & --- & Numero massimo di segmenti di
2463 memoria condivisa per ciascun
2469 \caption{Valori delle costanti associate ai limiti dei segmenti di memoria
2470 condivisa, insieme al relativo file in \file{/proc/sys/kernel/} ed al
2471 valore preimpostato presente nel sistema.}
2472 \label{tab:ipc_shm_limits}
2475 Al solito la funzione che permette di effettuare le operazioni di controllo su
2476 un segmento di memoria condivisa è \funcd{shmctl}; il suo prototipo è:
2478 \headdecl{sys/ipc.h}
2479 \headdecl{sys/shm.h}
2481 \funcdecl{int shmctl(int shmid, int cmd, struct shmid\_ds *buf)}
2483 Esegue le operazioni di controllo su un segmento di memoria condivisa.
2485 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
2486 errore, nel qual caso \var{errno} assumerà i valori:
2488 \item[\errcode{EACCES}] si è richiesto \const{IPC\_STAT} ma i permessi non
2489 consentono l'accesso in lettura al segmento.
2490 \item[\errcode{EINVAL}] o \param{shmid} non è un identificatore valido o
2491 \param{cmd} non è un comando valido.
2492 \item[\errcode{EIDRM}] l'argomento \param{shmid} fa riferimento ad un
2493 segmento che è stato cancellato.
2494 \item[\errcode{EPERM}] si è specificato un comando con \const{IPC\_SET} o
2495 \const{IPC\_RMID} senza i permessi necessari.
2496 \item[\errcode{EOVERFLOW}] si è tentato il comando \const{IPC\_STAT} ma il
2497 valore del \ids{GID} o dell'\ids{UID} è troppo grande per essere
2498 memorizzato nella struttura puntata da \param{buf}.
2499 \item[\errcode{EFAULT}] l'indirizzo specificato con \param{buf} non è
2505 Il comando specificato attraverso l'argomento \param{cmd} determina i diversi
2506 effetti della funzione; i possibili valori che esso può assumere, ed il
2507 corrispondente comportamento della funzione, sono i seguenti:
2509 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
2510 \item[\const{IPC\_STAT}] Legge le informazioni riguardo il segmento di memoria
2511 condivisa nella struttura \struct{shmid\_ds} puntata da \param{buf}. Occorre
2512 che il processo chiamante abbia il permesso di lettura sulla segmento.
2513 \item[\const{IPC\_RMID}] Marca il segmento di memoria condivisa per la
2514 rimozione, questo verrà cancellato effettivamente solo quando l'ultimo
2515 processo ad esso agganciato si sarà staccato. Questo comando può essere
2516 eseguito solo da un processo con \ids{UID} effettivo corrispondente o al
2517 creatore del segmento, o al proprietario del segmento, o all'amministratore.
2518 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
2519 del segmento. Per modificare i valori di \var{shm\_perm.mode},
2520 \var{shm\_perm.uid} e \var{shm\_perm.gid} occorre essere il proprietario o
2521 il creatore del segmento, oppure l'amministratore. Compiuta l'operazione
2522 aggiorna anche il valore del campo \var{shm\_ctime}.
2523 \item[\const{SHM\_LOCK}] Abilita il \itindex{memory~locking} \textit{memory
2524 locking}\footnote{impedisce cioè che la memoria usata per il segmento
2525 venga salvata su disco dal meccanismo della \index{memoria~virtuale}
2526 memoria virtuale; si ricordi quanto trattato in
2527 sez.~\ref{sec:proc_mem_lock}.} sul segmento di memoria condivisa. Solo
2528 l'amministratore può utilizzare questo comando.
2529 \item[\const{SHM\_UNLOCK}] Disabilita il \itindex{memory~locking}
2530 \textit{memory locking} sul segmento di memoria condivisa. Solo
2531 l'amministratore può utilizzare questo comando.
2533 i primi tre comandi sono gli stessi già visti anche per le code di messaggi e
2534 gli insiemi di semafori, gli ultimi due sono delle estensioni specifiche
2535 previste da Linux, che permettono di abilitare e disabilitare il meccanismo
2536 della \index{memoria~virtuale} memoria virtuale per il segmento.
2538 L'argomento \param{buf} viene utilizzato solo con i comandi \const{IPC\_STAT}
2539 e \const{IPC\_SET} nel qual caso esso dovrà puntare ad una struttura
2540 \struct{shmid\_ds} precedentemente allocata, in cui nel primo caso saranno
2541 scritti i dati del segmento di memoria restituiti dalla funzione e da cui, nel
2542 secondo caso, verranno letti i dati da impostare sul segmento.
2544 Una volta che lo si è creato, per utilizzare un segmento di memoria condivisa
2545 l'interfaccia prevede due funzioni, \funcd{shmat} e \func{shmdt}. La prima di
2546 queste serve ad agganciare un segmento al processo chiamante, in modo che
2547 quest'ultimo possa inserirlo nel suo spazio di indirizzi per potervi accedere;
2550 \headdecl{sys/types.h}
2551 \headdecl{sys/shm.h}
2553 \funcdecl{void *shmat(int shmid, const void *shmaddr, int shmflg)}
2554 Aggancia al processo un segmento di memoria condivisa.
2556 \bodydesc{La funzione restituisce l'indirizzo del segmento in caso di
2557 successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà i
2560 \item[\errcode{EACCES}] il processo non ha i privilegi per accedere al
2561 segmento nella modalità richiesta.
2562 \item[\errcode{EINVAL}] si è specificato un identificatore invalido per
2563 \param{shmid}, o un indirizzo non allineato sul confine di una pagina
2564 per \param{shmaddr}.
2566 ed inoltre \errval{ENOMEM}.}
2569 La funzione inserisce un segmento di memoria condivisa all'interno dello
2570 spazio di indirizzi del processo, in modo che questo possa accedervi
2571 direttamente, la situazione dopo l'esecuzione di \func{shmat} è illustrata in
2572 fig.~\ref{fig:ipc_shmem_layout} (per la comprensione del resto dello schema si
2573 ricordi quanto illustrato al proposito in sez.~\ref{sec:proc_mem_layout}). In
2574 particolare l'indirizzo finale del segmento dati (quello impostato da
2575 \func{brk}, vedi sez.~\ref{sec:proc_mem_alloc}) non viene influenzato.
2576 Si tenga presente infine che la funzione ha successo anche se il segmento è
2577 stato marcato per la cancellazione.
2579 \begin{figure}[!htb]
2580 \centering \includegraphics[height=10cm]{img/sh_memory_layout}
2581 \caption{Disposizione dei segmenti di memoria di un processo quando si è
2582 agganciato un segmento di memoria condivisa.}
2583 \label{fig:ipc_shmem_layout}
2586 L'argomento \param{shmaddr} specifica a quale indirizzo\footnote{lo standard
2587 SVID prevede che l'argomento \param{shmaddr} sia di tipo \ctyp{char *}, così
2588 come il valore di ritorno della funzione; in Linux è stato così con le
2589 \acr{libc4} e le \acr{libc5}, con il passaggio alla \acr{glibc} il tipo di
2590 \param{shmaddr} è divenuto un \ctyp{const void *} e quello del valore di
2591 ritorno un \ctyp{void *}.} deve essere associato il segmento, se il valore
2592 specificato è \val{NULL} è il sistema a scegliere opportunamente un'area di
2593 memoria libera (questo è il modo più portabile e sicuro di usare la funzione).
2594 Altrimenti il kernel aggancia il segmento all'indirizzo specificato da
2595 \param{shmaddr}; questo però può avvenire solo se l'indirizzo coincide con il
2596 limite di una pagina, cioè se è un multiplo esatto del parametro di sistema
2597 \const{SHMLBA}, che in Linux è sempre uguale \const{PAGE\_SIZE}.
2599 Si tenga presente però che quando si usa \val{NULL} come valore di
2600 \param{shmaddr}, l'indirizzo restituito da \func{shmat} può cambiare da
2601 processo a processo; pertanto se nell'area di memoria condivisa si salvano
2602 anche degli indirizzi, si deve avere cura di usare valori relativi (in genere
2603 riferiti all'indirizzo di partenza del segmento).
2605 L'argomento \param{shmflg} permette di cambiare il comportamento della
2606 funzione; esso va specificato come maschera binaria, i bit utilizzati sono
2607 solo due e sono identificati dalle costanti \const{SHM\_RND} e
2608 \const{SHM\_RDONLY}, che vanno combinate con un OR aritmetico. Specificando
2609 \const{SHM\_RND} si evita che \func{shmat} ritorni un errore quando
2610 \param{shmaddr} non è allineato ai confini di una pagina. Si può quindi usare
2611 un valore qualunque per \param{shmaddr}, e il segmento verrà comunque
2612 agganciato, ma al più vicino multiplo di \const{SHMLBA} (il nome della
2613 costante sta infatti per \textit{rounded}, e serve per specificare un
2614 indirizzo come arrotondamento, in Linux è equivalente a \const{PAGE\_SIZE}).
2616 L'uso di \const{SHM\_RDONLY} permette di agganciare il segmento in sola
2617 lettura (si ricordi che anche le pagine di memoria hanno dei permessi), in tal
2618 caso un tentativo di scrivere sul segmento comporterà una
2619 \itindex{segment~violation} violazione di accesso con l'emissione di un
2620 segnale di \signal{SIGSEGV}. Il comportamento usuale di \func{shmat} è quello
2621 di agganciare il segmento con l'accesso in lettura e scrittura (ed il processo
2622 deve aver questi permessi in \var{shm\_perm}), non è prevista la possibilità
2623 di agganciare un segmento in sola scrittura.
2625 In caso di successo la funzione aggiorna anche i seguenti campi di
2628 \item il tempo \var{shm\_atime} dell'ultima operazione di aggancio viene
2629 impostato al tempo corrente.
2630 \item il \ids{PID} \var{shm\_lpid} dell'ultimo processo che ha operato sul
2631 segmento viene impostato a quello del processo corrente.
2632 \item il numero \var{shm\_nattch} di processi agganciati al segmento viene
2636 Come accennato in sez.~\ref{sec:proc_fork} un segmento di memoria condivisa
2637 agganciato ad un processo viene ereditato da un figlio attraverso una
2638 \func{fork}, dato che quest'ultimo riceve una copia dello spazio degli
2639 indirizzi del padre. Invece, dato che attraverso una \func{exec} viene
2640 eseguito un diverso programma con uno spazio di indirizzi completamente
2641 diverso, tutti i segmenti agganciati al processo originario vengono
2642 automaticamente sganciati. Lo stesso avviene all'uscita del processo
2643 attraverso una \func{exit}.
2645 Una volta che un segmento di memoria condivisa non serve più, si può
2646 sganciarlo esplicitamente dal processo usando l'altra funzione
2647 dell'interfaccia, \funcd{shmdt}, il cui prototipo è:
2649 \headdecl{sys/types.h}
2650 \headdecl{sys/shm.h}
2652 \funcdecl{int shmdt(const void *shmaddr)}
2653 Sgancia dal processo un segmento di memoria condivisa.
2655 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
2656 errore, la funzione fallisce solo quando non c'è un segmento agganciato
2657 all'indirizzo \param{shmaddr}, con \var{errno} che assume il valore
2661 La funzione sgancia dallo spazio degli indirizzi del processo un segmento di
2662 memoria condivisa; questo viene identificato con l'indirizzo \param{shmaddr}
2663 restituito dalla precedente chiamata a \func{shmat} con il quale era stato
2664 agganciato al processo.
2666 In caso di successo la funzione aggiorna anche i seguenti campi di
2669 \item il tempo \var{shm\_dtime} dell'ultima operazione di sganciamento viene
2670 impostato al tempo corrente.
2671 \item il \ids{PID} \var{shm\_lpid} dell'ultimo processo che ha operato sul
2672 segmento viene impostato a quello del processo corrente.
2673 \item il numero \var{shm\_nattch} di processi agganciati al segmento viene
2674 decrementato di uno.
2676 inoltre la regione di indirizzi usata per il segmento di memoria condivisa
2677 viene tolta dallo spazio di indirizzi del processo.
2679 \begin{figure}[!htbp]
2680 \footnotesize \centering
2681 \begin{minipage}[c]{\codesamplewidth}
2682 \includecodesample{listati/SharedMem.c}
2685 \caption{Il codice delle funzioni che permettono di creare, trovare e
2686 rimuovere un segmento di memoria condivisa.}
2687 \label{fig:ipc_sysv_shm_func}
2690 Come esempio di uso di queste funzioni vediamo come implementare una serie di
2691 funzioni di libreria che ne semplifichino l'uso, automatizzando le operazioni
2692 più comuni; il codice, contenuto nel file \file{SharedMem.c}, è riportato in
2693 fig.~\ref{fig:ipc_sysv_shm_func}.
2695 La prima funzione (\texttt{\small 3--16}) è \func{ShmCreate} che, data una
2696 chiave, crea il segmento di memoria condivisa restituendo il puntatore allo
2697 stesso. La funzione comincia (\texttt{\small 6}) con il chiamare
2698 \func{shmget}, usando il flag \const{IPC\_CREATE} per creare il segmento
2699 qualora non esista, ed assegnandogli i privilegi specificati dall'argomento
2700 \var{perm} e la dimensione specificata dall'argomento \var{shm\_size}. In
2701 caso di errore (\texttt{\small 7--9}) si ritorna immediatamente un puntatore
2702 nullo, altrimenti (\texttt{\small 10}) si prosegue agganciando il segmento di
2703 memoria condivisa al processo con \func{shmat}. In caso di errore
2704 (\texttt{\small 11--13}) si restituisce di nuovo un puntatore nullo, infine
2705 (\texttt{\small 14}) si inizializza con \func{memset} il contenuto del
2706 segmento al valore costante specificato dall'argomento \var{fill}, e poi si
2707 ritorna il puntatore al segmento stesso.
2709 La seconda funzione (\texttt{\small 17--31}) è \func{ShmFind}, che, data una
2710 chiave, restituisce l'indirizzo del segmento ad essa associato. Anzitutto
2711 (\texttt{\small 22}) si richiede l'identificatore del segmento con
2712 \func{shmget}, ritornando (\texttt{\small 23--25}) un puntatore nullo in caso
2713 di errore. Poi si prosegue (\texttt{\small 26}) agganciando il segmento al
2714 processo con \func{shmat}, restituendo (\texttt{\small 27--29}) di nuovo un
2715 puntatore nullo in caso di errore, se invece non ci sono errori si restituisce
2716 il puntatore ottenuto da \func{shmat}.
2718 La terza funzione (\texttt{\small 32--51}) è \func{ShmRemove} che, data la
2719 chiave ed il puntatore associati al segmento di memoria condivisa, prima lo
2720 sgancia dal processo e poi lo rimuove. Il primo passo (\texttt{\small 37}) è
2721 la chiamata a \func{shmdt} per sganciare il segmento, restituendo
2722 (\texttt{\small 38--39}) un valore -1 in caso di errore. Il passo successivo
2723 (\texttt{\small 41}) è utilizzare \func{shmget} per ottenere l'identificatore
2724 associato al segmento data la chiave \var{key}. Al solito si restituisce un
2725 valore di -1 (\texttt{\small 42--45}) in caso di errore, mentre se tutto va
2726 bene si conclude restituendo un valore nullo.
2728 Benché la memoria condivisa costituisca il meccanismo di intercomunicazione
2729 fra processi più veloce, essa non è sempre il più appropriato, dato che, come
2730 abbiamo visto, si avrà comunque la necessità di una sincronizzazione degli
2731 accessi. Per questo motivo, quando la comunicazione fra processi è
2732 sequenziale, altri meccanismi come le pipe, le fifo o i socket, che non
2733 necessitano di sincronizzazione esplicita, sono da preferire. Essa diventa
2734 l'unico meccanismo possibile quando la comunicazione non è
2735 sequenziale\footnote{come accennato in sez.~\ref{sec:ipc_sysv_mq} per la
2736 comunicazione non sequenziale si possono usare le code di messaggi,
2737 attraverso l'uso del campo \var{mtype}, ma solo se quest'ultima può essere
2738 effettuata in forma di messaggio.} o quando non può avvenire secondo una
2739 modalità predefinita.
2741 Un esempio classico di uso della memoria condivisa è quello del
2742 ``\textit{monitor}'', in cui viene per scambiare informazioni fra un processo
2743 server, che vi scrive dei dati di interesse generale che ha ottenuto, e i
2744 processi client interessati agli stessi dati che così possono leggerli in
2745 maniera completamente asincrona. Con questo schema di funzionamento da una
2746 parte si evita che ciascun processo client debba compiere l'operazione,
2747 potenzialmente onerosa, di ricavare e trattare i dati, e dall'altra si evita
2748 al processo server di dover gestire l'invio a tutti i client di tutti i dati
2749 (non potendo il server sapere quali di essi servono effettivamente al singolo
2752 Nel nostro caso implementeremo un ``\textsl{monitor}'' di una directory: un
2753 processo si incaricherà di tenere sotto controllo alcuni parametri relativi ad
2754 una directory (il numero dei file contenuti, la dimensione totale, quante
2755 directory, link simbolici, file normali, ecc.) che saranno salvati in un
2756 segmento di memoria condivisa cui altri processi potranno accedere per
2757 ricavare la parte di informazione che interessa.
2759 In fig.~\ref{fig:ipc_dirmonitor_main} si è riportata la sezione principale del
2760 corpo del programma server, insieme alle definizioni delle altre funzioni
2761 usate nel programma e delle \index{variabili!globali} variabili globali,
2762 omettendo tutto quello che riguarda la gestione delle opzioni e la stampa
2763 delle istruzioni di uso a video; al solito il codice completo si trova con i
2764 sorgenti allegati nel file \file{DirMonitor.c}.
2766 \begin{figure}[!htbp]
2767 \footnotesize \centering
2768 \begin{minipage}[c]{\codesamplewidth}
2769 \includecodesample{listati/DirMonitor.c}
2772 \caption{Codice della funzione principale del programma \file{DirMonitor.c}.}
2773 \label{fig:ipc_dirmonitor_main}
2776 Il programma usa delle \index{variabili!globali} variabili globali
2777 (\texttt{\small 2--14}) per mantenere i valori relativi agli oggetti usati per
2778 la comunicazione inter-processo; si è definita inoltre una apposita struttura
2779 \struct{DirProp} che contiene i dati relativi alle proprietà che si vogliono
2780 mantenere nella memoria condivisa, per l'accesso da parte dei client.
2782 Il programma, dopo la sezione, omessa, relativa alla gestione delle opzioni da
2783 riga di comando (che si limitano alla eventuale stampa di un messaggio di
2784 aiuto a video ed all'impostazione della durata dell'intervallo con cui viene
2785 ripetuto il calcolo delle proprietà della directory) controlla (\texttt{\small
2786 20--23}) che sia stato specificato l'argomento necessario contenente il nome
2787 della directory da tenere sotto controllo, senza il quale esce immediatamente
2788 con un messaggio di errore.
2790 Poi, per verificare che l'argomento specifichi effettivamente una directory,
2791 si esegue (\texttt{\small 24--26}) su di esso una \func{chdir}, uscendo
2792 immediatamente in caso di errore. Questa funzione serve anche per impostare
2793 la \index{directory~di~lavoro} directory di lavoro del programma nella
2794 directory da tenere sotto controllo, in vista del successivo uso della
2795 funzione \func{daemon}.\footnote{si noti come si è potuta fare questa scelta,
2796 nonostante le indicazioni illustrate in sez.~\ref{sec:sess_daemon}, per il
2797 particolare scopo del programma, che necessita comunque di restare
2798 all'interno di una directory.} Infine (\texttt{\small 27--29}) si installano
2799 i gestori per i vari segnali di terminazione che, avendo a che fare con un
2800 programma che deve essere eseguito come server, sono il solo strumento
2801 disponibile per concluderne l'esecuzione.
2803 Il passo successivo (\texttt{\small 30--39}) è quello di creare gli oggetti di
2804 intercomunicazione necessari. Si inizia costruendo (\texttt{\small 30}) la
2805 chiave da usare come riferimento con il nome del programma,\footnote{si è
2806 usato un riferimento relativo alla home dell'utente, supposto che i sorgenti
2807 di GaPiL siano stati installati direttamente in essa. Qualora si effettui
2808 una installazione diversa si dovrà correggere il programma.} dopo di che si
2809 richiede (\texttt{\small 31}) la creazione di un segmento di memoria condivisa
2810 con usando la funzione \func{ShmCreate} illustrata in precedenza (una pagina
2811 di memoria è sufficiente per i dati che useremo), uscendo (\texttt{\small
2812 32--35}) qualora la creazione ed il successivo agganciamento al processo non
2813 abbia successo. Con l'indirizzo \var{shmptr} così ottenuto potremo poi
2814 accedere alla memoria condivisa, che, per come abbiamo lo abbiamo definito,
2815 sarà vista nella forma data da \struct{DirProp}. Infine (\texttt{\small
2816 36--39}) utilizzando sempre la stessa chiave, si crea, tramite le funzioni
2817 di interfaccia già descritte in sez.~\ref{sec:ipc_sysv_sem}, anche un mutex,
2818 che utilizzeremo per regolare l'accesso alla memoria condivisa.
2820 \begin{figure}[!htbp]
2821 \footnotesize \centering
2822 \begin{minipage}[c]{\codesamplewidth}
2823 \includecodesample{listati/ComputeValues.c}
2826 \caption{Codice delle funzioni ausiliarie usate da \file{DirMonitor.c}.}
2827 \label{fig:ipc_dirmonitor_sub}
2830 Completata l'inizializzazione e la creazione degli oggetti di
2831 intercomunicazione il programma entra nel ciclo principale (\texttt{\small
2832 40--49}) dove vengono eseguite indefinitamente le attività di monitoraggio.
2833 Il primo passo (\texttt{\small 41}) è eseguire \func{daemon} per proseguire
2834 con l'esecuzione in background come si conviene ad un programma demone; si
2835 noti che si è mantenuta, usando un valore non nullo del primo argomento, la
2836 \index{directory~di~lavoro} directory di lavoro corrente. Una volta che il
2837 programma è andato in background l'esecuzione prosegue (\texttt{\small
2838 42--48}) all'interno di un ciclo infinito: si inizia (\texttt{\small 43})
2839 bloccando il mutex con \func{MutexLock} per poter accedere alla memoria
2840 condivisa (la funzione si bloccherà automaticamente se qualche client sta
2841 leggendo), poi (\texttt{\small 44}) si cancellano i valori precedentemente
2842 immagazzinati nella memoria condivisa con \func{memset}, e si esegue
2843 (\texttt{\small 45}) un nuovo calcolo degli stessi utilizzando la funzione
2844 \myfunc{dir\_scan}; infine (\texttt{\small 46}) si sblocca il mutex con
2845 \func{MutexUnlock}, e si attende (\texttt{\small 47}) per il periodo di tempo
2846 specificato a riga di comando con l'opzione \code{-p} con una \func{sleep}.
2848 Si noti come per il calcolo dei valori da mantenere nella memoria condivisa si
2849 sia usata ancora una volta la funzione \myfunc{dir\_scan}, già utilizzata (e
2850 descritta in dettaglio) in sez.~\ref{sec:file_dir_read}, che ci permette di
2851 effettuare la scansione delle voci della directory, chiamando per ciascuna di
2852 esse la funzione \func{ComputeValues}, che esegue tutti i calcoli necessari.
2854 Il codice di quest'ultima è riportato in fig.~\ref{fig:ipc_dirmonitor_sub}.
2855 Come si vede la funzione (\texttt{\small 2--16}) è molto semplice e si limita
2856 a chiamare (\texttt{\small 5}) la funzione \func{stat} sul file indicato da
2857 ciascuna voce, per ottenerne i dati, che poi utilizza per incrementare i vari
2858 contatori nella memoria condivisa, cui accede grazie alla
2859 \index{variabili!globali} variabile globale \var{shmptr}.
2861 Dato che la funzione è chiamata da \myfunc{dir\_scan}, si è all'interno del
2862 ciclo principale del programma, con un mutex acquisito, perciò non è
2863 necessario effettuare nessun controllo e si può accedere direttamente alla
2864 memoria condivisa usando \var{shmptr} per riempire i campi della struttura
2865 \struct{DirProp}; così prima (\texttt{\small 6--7}) si sommano le dimensioni
2866 dei file ed il loro numero, poi, utilizzando le macro di
2867 tab.~\ref{tab:file_type_macro}, si contano (\texttt{\small 8--14}) quanti ce
2868 ne sono per ciascun tipo.
2870 In fig.~\ref{fig:ipc_dirmonitor_sub} è riportato anche il codice
2871 (\texttt{\small 17--23}) del gestore dei segnali di terminazione, usato per
2872 chiudere il programma. Esso, oltre a provocare l'uscita del programma, si
2873 incarica anche di cancellare tutti gli oggetti di intercomunicazione non più
2874 necessari. Per questo anzitutto (\texttt{\small 19}) acquisisce il mutex con
2875 \func{MutexLock}, per evitare di operare mentre un client sta ancora leggendo
2876 i dati, dopo di che (\texttt{\small 20}) distacca e rimuove il segmento di
2877 memoria condivisa usando \func{ShmRemove}. Infine (\texttt{\small 21})
2878 rimuove il mutex con \func{MutexRemove} ed esce (\texttt{\small 22}).
2880 \begin{figure}[!htbp]
2881 \footnotesize \centering
2882 \begin{minipage}[c]{\codesamplewidth}
2883 \includecodesample{listati/ReadMonitor.c}
2886 \caption{Codice del programma client del monitor delle proprietà di una
2887 directory, \file{ReadMonitor.c}.}
2888 \label{fig:ipc_dirmonitor_client}
2891 Il codice del client usato per leggere le informazioni mantenute nella memoria
2892 condivisa è riportato in fig.~\ref{fig:ipc_dirmonitor_client}. Al solito si è
2893 omessa la sezione di gestione delle opzioni e la funzione che stampa a video
2894 le istruzioni; il codice completo è nei sorgenti allegati, nel file
2895 \file{ReadMonitor.c}.
2897 Una volta conclusa la gestione delle opzioni a riga di comando il programma
2898 rigenera (\texttt{\small 7}) con \func{ftok} la stessa chiave usata dal server
2899 per identificare il segmento di memoria condivisa ed il mutex, poi
2900 (\texttt{\small 8}) richiede con \func{ShmFind} l'indirizzo della memoria
2901 condivisa agganciando al contempo il segmento al processo, Infine
2902 (\texttt{\small 17--20}) con \func{MutexFind} si richiede l'identificatore del
2903 mutex. Completata l'inizializzazione ed ottenuti i riferimenti agli oggetti
2904 di intercomunicazione necessari viene eseguito il corpo principale del
2905 programma (\texttt{\small 21--33}); si comincia (\texttt{\small 22})
2906 acquisendo il mutex con \func{MutexLock}; qui avviene il blocco del processo
2907 se la memoria condivisa non è disponibile. Poi (\texttt{\small 23--31}) si
2908 stampano i vari valori mantenuti nella memoria condivisa attraverso l'uso di
2909 \var{shmptr}. Infine (\texttt{\small 41}) con \func{MutexUnlock} si rilascia
2910 il mutex, prima di uscire.
2912 Verifichiamo allora il funzionamento dei nostri programmi; al solito, usando
2913 le funzioni di libreria occorre definire opportunamente
2914 \code{LD\_LIBRARY\_PATH}; poi si potrà lanciare il server con:
2916 [piccardi@gont sources]$ ./dirmonitor ./
2919 ed avendo usato \func{daemon} il comando ritornerà immediatamente. Una volta
2920 che il server è in esecuzione, possiamo passare ad invocare il client per
2921 verificarne i risultati, in tal caso otterremo:
2923 [piccardi@gont sources]$ ./readmon
2924 Ci sono 68 file dati
2929 Ci sono 0 device a caratteri
2930 Ci sono 0 device a blocchi
2931 Totale 71 file, per 489831 byte
2934 ed un rapido calcolo (ad esempio con \code{ls -a | wc} per contare i file) ci
2935 permette di verificare che il totale dei file è giusto. Un controllo con
2936 \cmd{ipcs} ci permette inoltre di verificare la presenza di un segmento di
2937 memoria condivisa e di un semaforo:
2939 [piccardi@gont sources]$ ipcs
2940 ------ Shared Memory Segments --------
2941 key shmid owner perms bytes nattch status
2942 0xffffffff 54067205 piccardi 666 4096 1
2944 ------ Semaphore Arrays --------
2945 key semid owner perms nsems
2946 0xffffffff 229376 piccardi 666 1
2948 ------ Message Queues --------
2949 key msqid owner perms used-bytes messages
2953 Se a questo punto aggiungiamo un file, ad esempio con \code{touch prova},
2954 potremo verificare che, passati nel peggiore dei casi almeno 10 secondi (o
2955 l'eventuale altro intervallo impostato per la rilettura dei dati) avremo:
2957 [piccardi@gont sources]$ ./readmon
2958 Ci sono 69 file dati
2963 Ci sono 0 device a caratteri
2964 Ci sono 0 device a blocchi
2965 Totale 72 file, per 489887 byte
2969 A questo punto possiamo far uscire il server inviandogli un segnale di
2970 \signal{SIGTERM} con il comando \code{killall dirmonitor}, a questo punto
2971 ripetendo la lettura, otterremo un errore:
2973 [piccardi@gont sources]$ ./readmon
2974 Cannot find shared memory: No such file or directory
2977 e inoltre potremo anche verificare che anche gli oggetti di intercomunicazione
2978 visti in precedenza sono stati regolarmente cancellati:
2980 [piccardi@gont sources]$ ipcs
2981 ------ Shared Memory Segments --------
2982 key shmid owner perms bytes nattch status
2984 ------ Semaphore Arrays --------
2985 key semid owner perms nsems
2987 ------ Message Queues --------
2988 key msqid owner perms used-bytes messages
2993 %% Per capire meglio il funzionamento delle funzioni facciamo ancora una volta
2994 %% riferimento alle strutture con cui il kernel implementa i segmenti di memoria
2995 %% condivisa; uno schema semplificato della struttura è illustrato in
2996 %% fig.~\ref{fig:ipc_shm_struct}.
2998 %% \begin{figure}[!htb]
3000 %% \includegraphics[width=10cm]{img/shmstruct}
3001 %% \caption{Schema dell'implementazione dei segmenti di memoria condivisa in
3003 %% \label{fig:ipc_shm_struct}
3009 \section{Tecniche alternative}
3010 \label{sec:ipc_alternatives}
3012 Come abbiamo detto in sez.~\ref{sec:ipc_sysv_generic}, e ripreso nella
3013 descrizione dei singoli oggetti che ne fan parte, il \textit{SysV IPC}
3014 presenta numerosi problemi; in \cite{APUE}\footnote{in particolare nel
3015 capitolo 14.} Stevens ne effettua una accurata analisi (alcuni dei concetti
3016 sono già stati accennati in precedenza) ed elenca alcune possibili tecniche
3017 alternative, che vogliamo riprendere in questa sezione.
3020 \subsection{Alternative alle code di messaggi}
3021 \label{sec:ipc_mq_alternative}
3023 Le code di messaggi sono probabilmente il meno usato degli oggetti del
3024 \textit{SysV IPC}; esse infatti nacquero principalmente come meccanismo di
3025 comunicazione bidirezionale quando ancora le pipe erano unidirezionali; con la
3026 disponibilità di \func{socketpair} (vedi sez.~\ref{sec:ipc_socketpair}) o
3027 utilizzando una coppia di pipe, si può ottenere questo risultato senza
3028 incorrere nelle complicazioni introdotte dal \textit{SysV IPC}.
3030 In realtà, grazie alla presenza del campo \var{mtype}, le code di messaggi
3031 hanno delle caratteristiche ulteriori, consentendo una classificazione dei
3032 messaggi ed un accesso non rigidamente sequenziale; due caratteristiche che
3033 sono impossibili da ottenere con le pipe e i socket di \func{socketpair}. A
3034 queste esigenze però si può comunque ovviare in maniera diversa con un uso
3035 combinato della memoria condivisa e dei meccanismi di sincronizzazione, per
3036 cui alla fine l'uso delle code di messaggi classiche è relativamente poco
3039 % TODO: trattare qui, se non ssis trova posto migliore, copy_from_process e
3040 % copy_to_process, introdotte con il kernel 3.2. Vedi
3041 % http://lwn.net/Articles/405346/ e
3042 % http://ozlabs.org/~cyeoh/cma/process_vm_readv.txt
3045 \subsection{I \textsl{file di lock}}
3046 \label{sec:ipc_file_lock}
3048 \index{file!di lock|(}
3050 Come illustrato in sez.~\ref{sec:ipc_sysv_sem} i semafori del \textit{SysV IPC}
3051 presentano una interfaccia inutilmente complessa e con alcuni difetti
3052 strutturali, per questo quando si ha una semplice esigenza di sincronizzazione
3053 per la quale basterebbe un semaforo binario (quello che abbiamo definito come
3054 \textit{mutex}), per indicare la disponibilità o meno di una risorsa, senza la
3055 necessità di un contatore come i semafori, si possono utilizzare metodi
3058 La prima possibilità, utilizzata fin dalle origini di Unix, è quella di usare
3059 dei \textsl{file di lock} (per i quali esiste anche una opportuna directory,
3060 \file{/var/lock}, nel filesystem standard). Per questo si usa la
3061 caratteristica della funzione \func{open} (illustrata in
3062 sez.~\ref{sec:file_open_close}) che prevede\footnote{questo è quanto dettato dallo
3063 standard POSIX.1, ciò non toglie che in alcune implementazioni questa
3064 tecnica possa non funzionare; in particolare per Linux, nel caso di NFS, si
3065 è comunque soggetti alla possibilità di una \itindex{race~condition}
3066 \textit{race condition}.} che essa ritorni un errore quando usata con i
3067 flag di \const{O\_CREAT} e \const{O\_EXCL}. In tal modo la creazione di un
3068 \textsl{file di lock} può essere eseguita atomicamente, il processo che crea
3069 il file con successo si può considerare come titolare del lock (e della
3070 risorsa ad esso associata) mentre il rilascio si può eseguire con una chiamata
3073 Un esempio dell'uso di questa funzione è mostrato dalle funzioni
3074 \func{LockFile} ed \func{UnlockFile} riportate in fig.~\ref{fig:ipc_file_lock}
3075 (sono contenute in \file{LockFile.c}, un altro dei sorgenti allegati alla
3076 guida) che permettono rispettivamente di creare e rimuovere un \textsl{file di
3077 lock}. Come si può notare entrambe le funzioni sono elementari; la prima
3078 (\texttt{\small 4--10}) si limita ad aprire il file di lock (\texttt{\small
3079 9}) nella modalità descritta, mentre la seconda (\texttt{\small 11--17}) lo
3080 cancella con \func{unlink}.
3082 \begin{figure}[!htbp]
3083 \footnotesize \centering
3084 \begin{minipage}[c]{\codesamplewidth}
3085 \includecodesample{listati/LockFile.c}
3088 \caption{Il codice delle funzioni \func{LockFile} e \func{UnlockFile} che
3089 permettono di creare e rimuovere un \textsl{file di lock}.}
3090 \label{fig:ipc_file_lock}
3093 Uno dei limiti di questa tecnica è che, come abbiamo già accennato in
3094 sez.~\ref{sec:file_open_close}, questo comportamento di \func{open} può non
3095 funzionare (la funzione viene eseguita, ma non è garantita l'atomicità
3096 dell'operazione) se il filesystem su cui si va ad operare è su NFS; in tal
3097 caso si può adottare una tecnica alternativa che prevede l'uso della
3098 \func{link} per creare come \textsl{file di lock} un hard link ad un file
3099 esistente; se il link esiste già e la funzione fallisce, significa che la
3100 risorsa è bloccata e potrà essere sbloccata solo con un \func{unlink},
3101 altrimenti il link è creato ed il lock acquisito; il controllo e l'eventuale
3102 acquisizione sono atomici; la soluzione funziona anche su NFS, ma ha un altro
3103 difetto è che è quello di poterla usare solo se si opera all'interno di uno
3106 In generale comunque l'uso di un \textsl{file di lock} presenta parecchi
3107 problemi che non lo rendono una alternativa praticabile per la
3108 sincronizzazione: anzitutto in caso di terminazione imprevista del processo,
3109 si lascia allocata la risorsa (il \textsl{file di lock}) e questa deve essere
3110 sempre cancellata esplicitamente. Inoltre il controllo della disponibilità
3111 può essere eseguito solo con una tecnica di \itindex{polling}
3112 \textit{polling}, ed è quindi molto inefficiente.
3114 La tecnica dei file di lock ha comunque una sua utilità, e può essere usata
3115 con successo quando l'esigenza è solo quella di segnalare l'occupazione di una
3116 risorsa, senza necessità di attendere che questa si liberi; ad esempio la si
3117 usa spesso per evitare interferenze sull'uso delle porte seriali da parte di
3118 più programmi: qualora si trovi un file di lock il programma che cerca di
3119 accedere alla seriale si limita a segnalare che la risorsa non è disponibile.
3121 \index{file!di lock|)}
3124 \subsection{La sincronizzazione con il \textit{file locking}}
3125 \label{sec:ipc_lock_file}
3127 Dato che i \index{file!di lock} file di lock presentano gli inconvenienti
3128 illustrati in precedenza, la tecnica alternativa di sincronizzazione più
3129 comune è quella di fare ricorso al \itindex{file~locking} \textit{file
3130 locking} (trattato in sez.~\ref{sec:file_locking}) usando \func{fcntl} su un
3131 file creato per l'occasione per ottenere un write lock. In questo modo potremo
3132 usare il lock come un \textit{mutex}: per bloccare la risorsa basterà
3133 acquisire il lock, per sbloccarla basterà rilasciare il lock. Una richiesta
3134 fatta con un write lock metterà automaticamente il processo in stato di
3135 attesa, senza necessità di ricorrere al \itindex{polling} \textit{polling} per
3136 determinare la disponibilità della risorsa, e al rilascio della stessa da
3137 parte del processo che la occupava si otterrà il nuovo lock atomicamente.
3139 Questo approccio presenta il notevole vantaggio che alla terminazione di un
3140 processo tutti i lock acquisiti vengono rilasciati automaticamente (alla
3141 chiusura dei relativi file) e non ci si deve preoccupare di niente; inoltre
3142 non consuma risorse permanentemente allocate nel sistema. Lo svantaggio è che,
3143 dovendo fare ricorso a delle operazioni sul filesystem, esso è in genere
3144 leggermente più lento.
3146 \begin{figure}[!htbp]
3147 \footnotesize \centering
3148 \begin{minipage}[c]{\codesamplewidth}
3149 \includecodesample{listati/MutexLocking.c}
3152 \caption{Il codice delle funzioni che permettono per la gestione dei
3153 \textit{mutex} con il \itindex{file~locking} \textit{file locking}.}
3154 \label{fig:ipc_flock_mutex}
3157 Il codice delle varie funzioni usate per implementare un mutex utilizzando il
3158 \textit{file locking} \itindex{file~locking} è riportato in
3159 fig.~\ref{fig:ipc_flock_mutex}; si è mantenuta volutamente una struttura
3160 analoga alle precedenti funzioni che usano i semafori, anche se le due
3161 interfacce non possono essere completamente equivalenti, specie per quanto
3162 riguarda la rimozione del mutex.
3164 La prima funzione (\texttt{\small 1--5}) è \func{CreateMutex}, e serve a
3165 creare il mutex; la funzione è estremamente semplice, e si limita
3166 (\texttt{\small 4}) a creare, con una opportuna chiamata ad \func{open}, il
3167 file che sarà usato per il successivo \textit{file locking}, assicurandosi che
3168 non esista già (nel qual caso segnala un errore); poi restituisce il file
3169 descriptor che sarà usato dalle altre funzioni per acquisire e rilasciare il
3172 La seconda funzione (\texttt{\small 6--10}) è \func{FindMutex}, che, come la
3173 precedente, è stata definita per mantenere una analogia con la corrispondente
3174 funzione basata sui semafori. Anch'essa si limita (\texttt{\small 9}) ad
3175 aprire il file da usare per il \itindex{file~locking} \textit{file locking},
3176 solo che in questo caso le opzioni di \func{open} sono tali che il file in
3177 questione deve esistere di già.
3179 La terza funzione (\texttt{\small 11--22}) è \func{LockMutex} e serve per
3180 acquisire il mutex. La funzione definisce (\texttt{\small 14}) e inizializza
3181 (\texttt{\small 16--19}) la struttura \var{lock} da usare per acquisire un
3182 write lock sul file, che poi (\texttt{\small 21}) viene richiesto con
3183 \func{fcntl}, restituendo il valore di ritorno di quest'ultima. Se il file è
3184 libero il lock viene acquisito e la funzione ritorna immediatamente;
3185 altrimenti \func{fcntl} si bloccherà (si noti che la si è chiamata con
3186 \const{F\_SETLKW}) fino al rilascio del lock.
3188 La quarta funzione (\texttt{\small 24--34}) è \func{UnlockMutex} e serve a
3189 rilasciare il mutex. La funzione è analoga alla precedente, solo che in questo
3190 caso si inizializza (\texttt{\small 28--31}) la struttura \var{lock} per il
3191 rilascio del lock, che viene effettuato (\texttt{\small 33}) con la opportuna
3192 chiamata a \func{fcntl}. Avendo usato il \itindex{file~locking} \textit{file
3193 locking} in semantica POSIX (si riveda quanto detto
3194 sez.~\ref{sec:file_posix_lock}) solo il processo che ha precedentemente
3195 eseguito il lock può sbloccare il mutex.
3197 La quinta funzione (\texttt{\small 36--39}) è \func{RemoveMutex} e serve a
3198 cancellare il mutex. Anche questa funzione è stata definita per mantenere una
3199 analogia con le funzioni basate sui semafori, e si limita a cancellare
3200 (\texttt{\small 38}) il file con una chiamata ad \func{unlink}. Si noti che in
3201 questo caso la funzione non ha effetto sui mutex già ottenuti con precedenti
3202 chiamate a \func{FindMutex} o \func{CreateMutex}, che continueranno ad essere
3203 disponibili fintanto che i relativi file descriptor restano aperti. Pertanto
3204 per rilasciare un mutex occorrerà prima chiamare \func{UnlockMutex} oppure
3205 chiudere il file usato per il lock.
3207 La sesta funzione (\texttt{\small 41--55}) è \func{ReadMutex} e serve a
3208 leggere lo stato del mutex. In questo caso si prepara (\texttt{\small 46--49})
3209 la solita struttura \var{lock} come l'acquisizione del lock, ma si effettua
3210 (\texttt{\small 51}) la chiamata a \func{fcntl} usando il comando
3211 \const{F\_GETLK} per ottenere lo stato del lock, e si restituisce
3212 (\texttt{\small 52}) il valore di ritorno in caso di errore, ed il valore del
3213 campo \var{l\_type} (che descrive lo stato del lock) altrimenti
3214 (\texttt{\small 54}). Per questo motivo la funzione restituirà -1 in caso di
3215 errore e uno dei due valori \const{F\_UNLCK} o \const{F\_WRLCK}\footnote{non
3216 si dovrebbe mai avere il terzo valore possibile, \const{F\_RDLCK}, dato che
3217 la nostra interfaccia usa solo i write lock. Però è sempre possibile che
3218 siano richiesti altri lock sul file al di fuori dell'interfaccia, nel qual
3219 caso si potranno avere, ovviamente, interferenze indesiderate.} in caso di
3220 successo, ad indicare che il mutex è, rispettivamente, libero o occupato.
3222 Basandosi sulla semantica dei file lock POSIX valgono tutte le considerazioni
3223 relative al comportamento di questi ultimi fatte in
3224 sez.~\ref{sec:file_posix_lock}; questo significa ad esempio che, al contrario
3225 di quanto avveniva con l'interfaccia basata sui semafori, chiamate multiple a
3226 \func{UnlockMutex} o \func{LockMutex} non si cumulano e non danno perciò
3227 nessun inconveniente.
3230 \subsection{Il \textit{memory mapping} anonimo}
3231 \label{sec:ipc_mmap_anonymous}
3233 \itindbeg{memory~mapping}
3234 Abbiamo già visto che quando i processi sono \textsl{correlati}\footnote{se
3235 cioè hanno almeno un progenitore comune.} l'uso delle pipe può costituire
3236 una valida alternativa alle code di messaggi; nella stessa situazione si può
3237 evitare l'uso di una memoria condivisa facendo ricorso al cosiddetto
3238 \textit{memory mapping} anonimo.
3240 In sez.~\ref{sec:file_memory_map} abbiamo visto come sia possibile mappare il
3241 contenuto di un file nella memoria di un processo, e che, quando viene usato
3242 il flag \const{MAP\_SHARED}, le modifiche effettuate al contenuto del file
3243 vengono viste da tutti i processi che lo hanno mappato. Utilizzare questa
3244 tecnica per creare una memoria condivisa fra processi diversi è estremamente
3245 inefficiente, in quanto occorre passare attraverso il disco. Però abbiamo
3246 visto anche che se si esegue la mappatura con il flag \const{MAP\_ANONYMOUS}
3247 la regione mappata non viene associata a nessun file, anche se quanto scritto
3248 rimane in memoria e può essere riletto; allora, dato che un processo figlio
3249 mantiene nel suo spazio degli indirizzi anche le regioni mappate, esso sarà
3250 anche in grado di accedere a quanto in esse è contenuto.
3252 In questo modo diventa possibile creare una memoria condivisa fra processi
3253 diversi, purché questi abbiano almeno un progenitore comune che ha effettuato
3254 il \textit{memory mapping} anonimo.\footnote{nei sistemi derivati da SysV una
3255 funzionalità simile a questa viene implementata mappando il file speciale
3256 \file{/dev/zero}. In tal caso i valori scritti nella regione mappata non
3257 vengono ignorati (come accade qualora si scriva direttamente sul file), ma
3258 restano in memoria e possono essere riletti secondo le stesse modalità usate
3259 nel \textit{memory mapping} anonimo.} Vedremo come utilizzare questa tecnica
3260 più avanti, quando realizzeremo una nuova versione del monitor visto in
3261 sez.~\ref{sec:ipc_sysv_shm} che possa restituisca i risultati via rete.
3262 \itindend{memory~mapping}
3264 % TODO: fare esempio di mmap anonima
3266 % TODO: con il kernel 3.2 è stata introdotta un nuovo meccanismo di
3267 % intercomunicazione veloce chiamato Cross Memory Attach, da capire se e come
3268 % trattarlo qui, vedi http://lwn.net/Articles/405346/
3269 % https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fcf634098c00dd9cd247447368495f0b79be12d1
3271 \section{L'intercomunicazione fra processi di POSIX}
3272 \label{sec:ipc_posix}
3274 Per superare i numerosi problemi del \textit{SysV IPC}, evidenziati per i suoi
3275 aspetti generali in coda a sez.~\ref{sec:ipc_sysv_generic} e per i singoli
3276 oggetti nei paragrafi successivi, lo standard POSIX.1b ha introdotto dei nuovi
3277 meccanismi di comunicazione, che vanno sotto il nome di POSIX IPC, definendo
3278 una interfaccia completamente nuova, che tratteremo in questa sezione.
3281 \subsection{Considerazioni generali}
3282 \label{sec:ipc_posix_generic}
3284 Oggi Linux supporta tutti gli oggetti definito nello standard POSIX per l'IPC,
3285 ma a lungo non è stato così; la memoria condivisa è presente a partire dal
3286 kernel 2.4.x, i semafori sono forniti dalla \acr{glibc} nella sezione che
3287 implementa i \itindex{thread} \textit{thread} POSIX di nuova generazione che
3288 richiedono il kernel 2.6, le code di messaggi sono supportate a partire dal
3291 La caratteristica fondamentale dell'interfaccia POSIX è l'abbandono dell'uso
3292 degli identificatori e delle chiavi visti nel SysV IPC, per passare ai
3293 \itindex{POSIX~IPC~names} \textit{POSIX IPC names}, che sono sostanzialmente
3294 equivalenti ai nomi dei file. Tutte le funzioni che creano un oggetto di IPC
3295 POSIX prendono come primo argomento una stringa che indica uno di questi nomi;
3296 lo standard è molto generico riguardo l'implementazione, ed i nomi stessi
3297 possono avere o meno una corrispondenza sul filesystem; tutto quello che è
3300 \item i nomi devono essere conformi alle regole che caratterizzano i
3301 \textit{pathname}, in particolare non essere più lunghi di \const{PATH\_MAX}
3302 byte e terminati da un carattere nullo.
3303 \item se il nome inizia per una \texttt{/} chiamate differenti allo stesso
3304 nome fanno riferimento allo stesso oggetto, altrimenti l'interpretazione del
3305 nome dipende dall'implementazione.
3306 \item l'interpretazione di ulteriori \texttt{/} presenti nel nome dipende
3307 dall'implementazione.
3310 Data la assoluta genericità delle specifiche, il comportamento delle funzioni
3311 è subordinato in maniera quasi completa alla relativa
3312 implementazione.\footnote{tanto che Stevens in \cite{UNP2} cita questo caso
3313 come un esempio della maniera standard usata dallo standard POSIX per
3314 consentire implementazioni non standardizzabili.} Nel caso di Linux, sia per
3315 quanto riguarda la memoria condivisa ed i semafori, che per quanto riguarda le
3316 code di messaggi, tutto viene creato usando come radici delle opportune
3317 directory (rispettivamente \file{/dev/shm} e \file{/dev/mqueue}, per i
3318 dettagli si faccia riferimento a sez.~\ref{sec:ipc_posix_shm},
3319 sez.~\ref{sec:ipc_posix_sem} e sez.~\ref{sec:ipc_posix_mq}) ed i nomi
3320 specificati nelle relative funzioni sono considerati come un
3321 \itindsub{pathname}{assoluto} \textit{pathname} assoluto (comprendente
3322 eventuali sottodirectory) rispetto a queste radici.
3324 Il vantaggio degli oggetti di IPC POSIX è comunque che essi vengono inseriti
3325 nell'albero dei file, e possono essere maneggiati con le usuali funzioni e
3326 comandi di accesso ai file,\footnote{questo è vero nel caso di Linux, che usa
3327 una implementazione che lo consente, non è detto che altrettanto valga per
3328 altri kernel; in particolare, come si può facilmente verificare con uno
3329 \cmd{strace}, sia per la memoria condivisa che per le code di messaggi le
3330 system call utilizzate da Linux sono le stesse di quelle dei file, essendo
3331 detti oggetti realizzati come tali in appositi filesystem.} che funzionano
3332 come su dei file normali.
3334 In particolare i permessi associati agli oggetti di IPC POSIX sono identici ai
3335 permessi dei file, ed il controllo di accesso segue esattamente la stessa
3336 semantica (quella illustrata in sez.~\ref{sec:file_access_control}), e non
3337 quella particolare (si ricordi quanto visto in
3338 sez.~\ref{sec:ipc_sysv_access_control}) che viene usata per gli oggetti del
3339 SysV IPC. Per quanto riguarda l'attribuzione dell'utente e del gruppo
3340 proprietari dell'oggetto alla creazione di quest'ultimo essa viene effettuata
3341 secondo la semantica SysV: corrispondono cioè a \ids{UID} e \ids{GID} effettivi
3342 del processo che esegue la creazione.
3345 \subsection{Code di messaggi}
3346 \label{sec:ipc_posix_mq}
3348 Le code di messaggi POSIX sono supportate da Linux a partire dalla versione
3349 2.6.6-rc1 del kernel,\footnote{l'implementazione è dovuta a Michal Wronski e
3350 Krzysztof Benedyczak, e le relative informazioni si possono trovare su
3351 \url{http://www.geocities.com/wronski12/posix_ipc/index.html}.} In
3352 generale, come le corrispettive del SysV IPC, le code di messaggi sono poco
3353 usate, dato che i socket, nei casi in cui sono sufficienti, sono più comodi, e
3354 che in casi più complessi la comunicazione può essere gestita direttamente con
3355 mutex (o semafori) e memoria condivisa con tutta la flessibilità che occorre.
3357 Per poter utilizzare le code di messaggi, oltre ad utilizzare un kernel
3358 superiore al 2.6.6 (o precedente, se sono stati opportunamente applicati i
3359 relativi patch) occorre utilizzare la libreria \file{libmqueue}\footnote{i
3360 programmi che usano le code di messaggi cioè devono essere compilati
3361 aggiungendo l'opzione \code{-lmqueue} al comando \cmd{gcc}; in
3362 corrispondenza all'inclusione del supporto nel kernel ufficiale anche
3363 \file{libmqueue} è stata inserita nella \acr{glibc}, a partire dalla
3364 versione 2.3.4 delle medesime.} che contiene le funzioni dell'interfaccia
3365 POSIX.\footnote{in realtà l'implementazione è realizzata tramite delle
3366 opportune chiamate ad \func{ioctl} sui file del filesystem speciale su cui
3367 vengono mantenuti questi oggetti di IPC.}
3369 La libreria inoltre richiede la presenza dell'apposito filesystem di tipo
3370 \texttt{mqueue} montato su \file{/dev/mqueue}; questo può essere fatto
3371 aggiungendo ad \conffile{/etc/fstab} una riga come:
3373 mqueue /dev/mqueue mqueue defaults 0 0
3375 ed esso sarà utilizzato come radice sulla quale vengono risolti i nomi delle
3376 code di messaggi che iniziano con una ``\texttt{/}''. Le opzioni di mount
3377 accettate sono \texttt{uid}, \texttt{gid} e \texttt{mode} che permettono
3378 rispettivamente di impostare l'utente, il gruppo ed i permessi associati al
3382 La funzione che permette di aprire (e crearla se non esiste ancora) una coda
3383 di messaggi POSIX è \funcd{mq\_open}, ed il suo prototipo è:
3387 \funcdecl{mqd\_t mq\_open(const char *name, int oflag)}
3389 \funcdecl{mqd\_t mq\_open(const char *name, int oflag, unsigned long mode,
3390 struct mq\_attr *attr)}
3392 Apre una coda di messaggi POSIX impostandone le caratteristiche.
3394 \bodydesc{La funzione restituisce il descrittore associato alla coda in caso
3395 di successo e -1 per un errore; nel quel caso \var{errno} assumerà i
3398 \item[\errcode{EACCES}] il processo non ha i privilegi per accedere al
3399 alla memoria secondo quanto specificato da \param{oflag}.
3400 \item[\errcode{EEXIST}] si è specificato \const{O\_CREAT} e
3401 \const{O\_EXCL} ma la coda già esiste.
3402 \item[\errcode{EINVAL}] il file non supporta la funzione, o si è
3403 specificato \const{O\_CREAT} con una valore non nullo di \param{attr} e
3404 valori non validi di \var{mq\_maxmsg} e \var{mq\_msgsize}.
3405 \item[\errcode{ENOENT}] non si è specificato \const{O\_CREAT} ma la coda
3408 ed inoltre \errval{ENOMEM}, \errval{ENOSPC}, \errval{EFAULT},
3409 \errval{EMFILE}, \errval{EINTR} ed \errval{ENFILE}.
3413 La funzione apre la coda di messaggi identificata dall'argomento \param{name}
3414 restituendo il descrittore ad essa associato, del tutto analogo ad un file
3415 descriptor, con l'unica differenza che lo standard prevede un apposito tipo
3416 \type{mqd\_t}.\footnote{nel caso di Linux si tratta in effetti proprio di un
3417 normale file descriptor; pertanto, anche se questo comportamento non è
3418 portabile, lo si può tenere sotto osservazione con le funzioni dell'I/O
3419 multiplexing (vedi sez.~\ref{sec:file_multiplexing}) come possibile
3420 alternativa all'uso dell'interfaccia di notifica di \func{mq\_notify} (che
3421 vedremo a breve).} Se la coda esiste già il descrittore farà riferimento
3422 allo stesso oggetto, consentendo così la comunicazione fra due processi
3425 La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
3426 possono essere specificati per \param{oflag}, che deve essere specificato come
3427 maschera binaria; i valori possibili per i vari bit sono quelli visti in
3428 sez.~\ref{sec:file_open_close} dei quali però \func{mq\_open} riconosce solo i
3430 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
3431 \item[\const{O\_RDONLY}] Apre la coda solo per la ricezione di messaggi. Il
3432 processo potrà usare il descrittore con \func{mq\_receive} ma non con
3434 \item[\const{O\_WRONLY}] Apre la coda solo per la trasmissione di messaggi. Il
3435 processo potrà usare il descrittore con \func{mq\_send} ma non con
3437 \item[\const{O\_RDWR}] Apre la coda solo sia per la trasmissione che per la
3439 \item[\const{O\_CREAT}] Necessario qualora si debba creare la coda; la
3440 presenza di questo bit richiede la presenza degli ulteriori argomenti
3441 \param{mode} e \param{attr}.
3442 \item[\const{O\_EXCL}] Se usato insieme a \const{O\_CREAT} fa fallire la
3443 chiamata se la coda esiste già, altrimenti esegue la creazione atomicamente.
3444 \item[\const{O\_NONBLOCK}] Imposta la coda in modalità non bloccante, le
3445 funzioni di ricezione e trasmissione non si bloccano quando non ci sono le
3446 risorse richieste, ma ritornano immediatamente con un errore di
3450 I primi tre bit specificano la modalità di apertura della coda, e sono fra
3451 loro esclusivi. Ma qualunque sia la modalità in cui si è aperta una coda,
3452 questa potrà essere riaperta più volte in una modalità diversa, e vi si potrà
3453 sempre accedere attraverso descrittori diversi, esattamente come si può fare
3456 Se la coda non esiste e la si vuole creare si deve specificare
3457 \const{O\_CREAT}, in tal caso occorre anche specificare i permessi di
3458 creazione con l'argomento \param{mode};\footnote{fino al 2.6.14 per un bug i
3459 valori della \textit{umask} del processo non venivano applicati a questi
3460 permessi.} i valori di quest'ultimo sono identici a quelli usati per
3461 \func{open}, anche se per le code di messaggi han senso solo i permessi di
3462 lettura e scrittura. Oltre ai permessi di creazione possono essere specificati
3463 anche gli attributi specifici della coda tramite l'argomento \param{attr};
3464 quest'ultimo è un puntatore ad una apposita struttura \struct{mq\_attr}, la
3465 cui definizione è riportata in fig.~\ref{fig:ipc_mq_attr}.
3467 \begin{figure}[!htb]
3468 \footnotesize \centering
3469 \begin{minipage}[c]{\textwidth}
3470 \includestruct{listati/mq_attr.h}
3473 \caption{La struttura \structd{mq\_attr}, contenente gli attributi di una
3474 coda di messaggi POSIX.}
3475 \label{fig:ipc_mq_attr}
3478 Per la creazione della coda i campi della struttura che devono essere
3479 specificati sono \var{mq\_maxmsg} e \var{mq\_msgsize}, che indicano
3480 rispettivamente il numero massimo di messaggi che può contenere e la
3481 dimensione massima di un messaggio. Il valore dovrà essere positivo e minore
3482 dei rispettivi limiti di sistema \const{MQ\_MAXMSG} e \const{MQ\_MSGSIZE},
3483 altrimenti la funzione fallirà con un errore di \errcode{EINVAL}.
3484 Se \param{attr} è un puntatore nullo gli attributi della coda saranno
3485 impostati ai valori predefiniti.
3487 Quando l'accesso alla coda non è più necessario si può chiudere il relativo
3488 descrittore con la funzione \funcd{mq\_close}, il cui prototipo è:
3489 \begin{prototype}{mqueue.h}
3490 {int mq\_close(mqd\_t mqdes)}
3492 Chiude la coda \param{mqdes}.
3494 \bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore;
3495 nel quel caso \var{errno} assumerà i valori \errval{EBADF} o
3499 La funzione è analoga a \func{close},\footnote{in Linux, dove le code sono
3500 implementate come file su un filesystem dedicato, è esattamente la stessa
3501 funzione.} dopo la sua esecuzione il processo non sarà più in grado di usare
3502 il descrittore della coda, ma quest'ultima continuerà ad esistere nel sistema
3503 e potrà essere acceduta con un'altra chiamata a \func{mq\_open}. All'uscita di
3504 un processo tutte le code aperte, così come i file, vengono chiuse
3505 automaticamente. Inoltre se il processo aveva agganciato una richiesta di
3506 notifica sul descrittore che viene chiuso, questa sarà rilasciata e potrà
3507 essere richiesta da qualche altro processo.
3510 Quando si vuole effettivamente rimuovere una coda dal sistema occorre usare la
3511 funzione \funcd{mq\_unlink}, il cui prototipo è:
3512 \begin{prototype}{mqueue.h}
3513 {int mq\_unlink(const char *name)}
3515 Rimuove una coda di messaggi.
3517 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
3518 errore; nel quel caso \var{errno} assumerà gli stessi valori riportati da
3522 Anche in questo caso il comportamento della funzione è analogo a quello di
3523 \func{unlink} per i file,\footnote{di nuovo l'implementazione di Linux usa
3524 direttamente \func{unlink}.} la funzione rimuove la coda \param{name}, così
3525 che una successiva chiamata a \func{mq\_open} fallisce o crea una coda
3528 Come per i file ogni coda di messaggi ha un contatore di riferimenti, per cui
3529 la coda non viene effettivamente rimossa dal sistema fin quando questo non si
3530 annulla. Pertanto anche dopo aver eseguito con successo \func{mq\_unlink} la
3531 coda resterà accessibile a tutti i processi che hanno un descrittore aperto su
3532 di essa. Allo stesso modo una coda ed i suoi contenuti resteranno disponibili
3533 all'interno del sistema anche quando quest'ultima non è aperta da nessun
3534 processo (questa è una delle differenze più rilevanti nei confronti di pipe e
3535 fifo). La sola differenza fra code di messaggi POSIX e file normali è che,
3536 essendo il filesystem delle code di messaggi virtuale e basato su oggetti
3537 interni al kernel, il suo contenuto viene perduto con il riavvio del sistema.
3539 Come accennato ad ogni coda di messaggi è associata una struttura
3540 \struct{mq\_attr}, che può essere letta e modificata attraverso le due
3541 funzioni \funcd{mq\_getattr} e \funcd{mq\_setattr}, i cui prototipi sono:
3545 \funcdecl{int mq\_getattr(mqd\_t mqdes, struct mq\_attr *mqstat)}
3546 Legge gli attributi di una coda di messaggi POSIX.
3548 \funcdecl{int mq\_setattr(mqd\_t mqdes, const struct mq\_attr *mqstat,
3549 struct mq\_attr *omqstat)}
3550 Modifica gli attributi di una coda di messaggi POSIX.
3552 \bodydesc{Entrambe le funzioni restituiscono 0 in caso di successo e -1 in
3553 caso di errore; nel quel caso \var{errno} assumerà i valori \errval{EBADF}
3557 La funzione \func{mq\_getattr} legge i valori correnti degli attributi della
3558 coda nella struttura puntata da \param{mqstat}; di questi l'unico relativo
3559 allo stato corrente della coda è \var{mq\_curmsgs} che indica il numero di
3560 messaggi da essa contenuti, gli altri indicano le caratteristiche generali
3563 La funzione \func{mq\_setattr} permette di modificare gli attributi di una
3564 coda tramite i valori contenuti nella struttura puntata da \param{mqstat}, ma
3565 può essere modificato solo il campo \var{mq\_flags}, gli altri campi vengono
3566 ignorati. In particolare i valori di \var{mq\_maxmsg} e \var{mq\_msgsize}
3567 possono essere specificati solo in fase ci creazione della coda. Inoltre i
3568 soli valori possibili per \var{mq\_flags} sono 0 e \const{O\_NONBLOCK}, per
3569 cui alla fine la funzione può essere utilizzata solo per abilitare o
3570 disabilitare la modalità non bloccante. L'argomento \param{omqstat} viene
3571 usato, quando diverso da \val{NULL}, per specificare l'indirizzo di una
3572 struttura su cui salvare i valori degli attributi precedenti alla chiamata
3575 Per inserire messaggi su di una coda sono previste due funzioni,
3576 \funcd{mq\_send} e \funcd{mq\_timedsend}, i cui prototipi sono:
3580 \funcdecl{int mq\_send(mqd\_t mqdes, const char *msg\_ptr, size\_t msg\_len,
3581 unsigned int msg\_prio)}
3582 Esegue l'inserimento di un messaggio su una coda.
3584 \funcdecl{int mq\_timedsend(mqd\_t mqdes, const char *msg\_ptr, size\_t
3585 msg\_len, unsigned msg\_prio, const struct timespec *abs\_timeout)}
3586 Esegue l'inserimento di un messaggio su una coda entro il tempo
3587 \param{abs\_timeout}.
3590 \bodydesc{Le funzioni restituiscono 0 in caso di successo e $-1$ per un
3591 errore; nel quel caso \var{errno} assumerà i valori:
3593 \item[\errcode{EAGAIN}] si è aperta la coda con \const{O\_NONBLOCK}, e la
3595 \item[\errcode{EMSGSIZE}] la lunghezza del messaggio \param{msg\_len}
3596 eccede il limite impostato per la coda.
3597 \item[\errcode{EINVAL}] si è specificato un valore nullo per
3598 \param{msg\_len}, o un valore di \param{msg\_prio} fuori dai limiti, o
3599 un valore non valido per \param{abs\_timeout}.
3600 \item[\errcode{ETIMEDOUT}] l'inserimento del messaggio non è stato
3601 effettuato entro il tempo stabilito.
3603 ed inoltre \errval{EBADF}, \errval{ENOMEM} ed \errval{EINTR}.}
3606 Entrambe le funzioni richiedono un puntatore al testo del messaggio
3607 nell'argomento \param{msg\_ptr} e la relativa lunghezza in \param{msg\_len}.
3608 Se quest'ultima eccede la dimensione massima specificata da \var{mq\_msgsize}
3609 le funzioni ritornano immediatamente con un errore di \errcode{EMSGSIZE}.
3611 L'argomento \param{msg\_prio} indica la priorità dell'argomento; i messaggi di
3612 priorità maggiore vengono inseriti davanti a quelli di priorità inferiore (e
3613 quindi saranno riletti per primi). A parità del valore della priorità il
3614 messaggio sarà inserito in coda a tutti quelli con la stessa priorità. Il
3615 valore della priorità non può eccedere il limite di sistema
3616 \const{MQ\_PRIO\_MAX}, che nel caso è pari a 32768.
3618 Qualora la coda sia piena, entrambe le funzioni si bloccano, a meno che non
3619 sia stata selezionata in fase di apertura la modalità non
3620 bloccante,\footnote{o si sia impostato il flag \const{O\_NONBLOCK} sul file
3621 descriptor della coda.} nel qual caso entrambe ritornano \errcode{EAGAIN}.
3622 La sola differenza fra le due funzioni è che la seconda, passato il tempo
3623 massimo impostato con l'argomento \param{abs\_timeout},\footnote{deve essere
3624 specificato un tempo assoluto tramite una struttura \struct{timespec} (vedi
3625 fig.~\ref{fig:sys_timespec_struct}) indicato in numero di secondi e
3626 nanosecondi a partire dal 1 gennaio 1970.} ritorna comunque con un errore di
3627 \errcode{ETIMEDOUT}, se invece il tempo è già scaduto al momento della
3628 chiamata e la coda è vuota la funzione ritorna immediatamente.
3630 Come per l'inserimento, anche per l'estrazione dei messaggi da una coda sono
3631 previste due funzioni, \funcd{mq\_receive} e \funcd{mq\_timedreceive}, i cui
3636 \funcdecl{ssize\_t mq\_receive(mqd\_t mqdes, char *msg\_ptr, size\_t
3637 msg\_len, unsigned int *msg\_prio)}
3638 Effettua la ricezione di un messaggio da una coda.
3640 \funcdecl{ssize\_t mq\_timedreceive(mqd\_t mqdes, char *msg\_ptr, size\_t
3641 msg\_len, unsigned int *msg\_prio, const struct timespec *abs\_timeout)}
3642 Effettua la ricezione di un messaggio da una coda entro il tempo
3643 \param{abs\_timeout}.
3645 \bodydesc{Le funzioni restituiscono il numero di byte del messaggio in caso
3646 di successo e -1 in caso di errore; nel quel caso \var{errno} assumerà i
3649 \item[\errcode{EAGAIN}] si è aperta la coda con \const{O\_NONBLOCK}, e la
3651 \item[\errcode{EMSGSIZE}] la lunghezza del messaggio sulla coda eccede il
3652 valore \param{msg\_len} specificato per la ricezione.
3653 \item[\errcode{EINVAL}] si è specificato un valore nullo per
3654 \param{msg\_ptr}, o un valore non valido per \param{abs\_timeout}.
3655 \item[\errcode{ETIMEDOUT}] la ricezione del messaggio non è stata
3656 effettuata entro il tempo stabilito.
3658 ed inoltre \errval{EBADF}, \errval{EINTR}, \errval{ENOMEM}, o
3662 La funzione estrae dalla coda il messaggio a priorità più alta, o il più
3663 vecchio fra quelli della stessa priorità. Una volta ricevuto il messaggio
3664 viene tolto dalla coda e la sua dimensione viene restituita come valore di
3665 ritorno.\footnote{si tenga presente che 0 è una dimensione valida e che la
3666 condizione di errore è restituita dal valore -1; Stevens in \cite{UNP2} fa
3667 notare che questo è uno dei casi in cui vale ciò che lo standard
3668 \textsl{non} dice, una dimensione nulla infatti, pur non essendo citata, non
3671 Se la dimensione specificata da \param{msg\_len} non è sufficiente a contenere
3672 il messaggio, entrambe le funzioni, al contrario di quanto avveniva nelle code
3673 di messaggi di SysV, ritornano un errore di \errcode{EMSGSIZE} senza estrarre
3674 il messaggio. È pertanto opportuno eseguire sempre una chiamata a
3675 \func{mq\_getattr} prima di eseguire una ricezione, in modo da ottenere la
3676 dimensione massima dei messaggi sulla coda, per poter essere in grado di
3677 allocare dei buffer sufficientemente ampi per la lettura.
3679 Se si specifica un puntatore per l'argomento \param{msg\_prio} il valore della
3680 priorità del messaggio viene memorizzato all'indirizzo da esso indicato.
3681 Qualora non interessi usare la priorità dei messaggi si può specificare
3682 \var{NULL}, ed usare un valore nullo della priorità nelle chiamate a
3685 Si noti che con le code di messaggi POSIX non si ha la possibilità di
3686 selezionare quale messaggio estrarre con delle condizioni sulla priorità, a
3687 differenza di quanto avveniva con le code di messaggi di SysV che permettono
3688 invece la selezione in base al valore del campo \var{mtype}.
3690 % TODO inserire i dati di /proc/sys/fs/mqueue
3692 Qualora la coda sia vuota entrambe le funzioni si bloccano, a meno che non si
3693 sia selezionata la modalità non bloccante; in tal caso entrambe ritornano
3694 immediatamente con l'errore \errcode{EAGAIN}. Anche in questo caso la sola
3695 differenza fra le due funzioni è che la seconda non attende indefinitamente e
3696 passato il tempo massimo \param{abs\_timeout} ritorna comunque con un errore
3697 di \errcode{ETIMEDOUT}.
3699 Uno dei problemi sottolineati da Stevens in \cite{UNP2}, comuni ad entrambe le
3700 tipologie di code messaggi, è che non è possibile per chi riceve identificare
3701 chi è che ha inviato il messaggio, in particolare non è possibile sapere da
3702 quale utente esso provenga. Infatti, in mancanza di un meccanismo interno al
3703 kernel, anche se si possono inserire delle informazioni nel messaggio, queste
3704 non possono essere credute, essendo completamente dipendenti da chi lo invia.
3705 Vedremo però come, attraverso l'uso del meccanismo di notifica, sia possibile
3706 superare in parte questo problema.
3708 Una caratteristica specifica delle code di messaggi POSIX è la possibilità di
3709 usufruire di un meccanismo di notifica asincrono; questo può essere attivato
3710 usando la funzione \funcd{mq\_notify}, il cui prototipo è:
3711 \begin{prototype}{mqueue.h}
3712 {int mq\_notify(mqd\_t mqdes, const struct sigevent *notification)}
3714 Attiva il meccanismo di notifica per la coda \param{mqdes}.
3716 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
3717 errore; nel quel caso \var{errno} assumerà i valori:
3719 \item[\errcode{EBUSY}] c'è già un processo registrato per la notifica.
3720 \item[\errcode{EBADF}] il descrittore non fa riferimento ad una coda di
3725 Il meccanismo di notifica permette di segnalare in maniera asincrona ad un
3726 processo la presenza di dati sulla coda, in modo da evitare la necessità di
3727 bloccarsi nell'attesa. Per far questo un processo deve registrarsi con la
3728 funzione \func{mq\_notify}, ed il meccanismo è disponibile per un solo
3729 processo alla volta per ciascuna coda.
3731 Il comportamento di \func{mq\_notify} dipende dal valore dell'argomento
3732 \param{notification}, che è un puntatore ad una apposita struttura
3733 \struct{sigevent}, (definita in fig.~\ref{fig:struct_sigevent}) introdotta
3734 dallo standard POSIX.1b per gestire la notifica di eventi; per altri dettagli
3735 si può vedere quanto detto in sez.~\ref{sec:sig_timer_adv} a proposito
3736 dell'uso della stessa struttura per la notifica delle scadenze dei
3739 Attraverso questa struttura si possono impostare le modalità con cui viene
3740 effettuata la notifica nel campo \var{sigev\_notify}, che può assumere i
3741 valori di tab.~\ref{tab:sigevent_sigev_notify}.\footnote{la pagina di manuale
3742 riporta soltanto i primi tre (inizialmente era possibile solo
3743 \const{SIGEV\_SIGNAL}).} Il metodo consigliato è quello di usare
3744 \const{SIGEV\_SIGNAL} usando il campo \var{sigev\_signo} per indicare il quale
3745 segnale deve essere inviato al processo. Inoltre il campo \var{sigev\_value} è
3746 un puntatore ad una struttura \struct{sigval} (definita in
3747 fig.~\ref{fig:sig_sigval}) che permette di restituire al gestore del segnale
3748 un valore numerico o un indirizzo,\footnote{per il suo uso si riveda la
3749 trattazione fatta in sez.~\ref{sec:sig_real_time} a proposito dei segnali
3750 \textit{real-time}.} posto che questo sia installato nella forma estesa
3751 vista in sez.~\ref{sec:sig_sigaction}.
3753 La funzione registra il processo chiamante per la notifica se
3754 \param{notification} punta ad una struttura \struct{sigevent} opportunamente
3755 inizializzata, o cancella una precedente registrazione se è \val{NULL}. Dato
3756 che un solo processo alla volta può essere registrato, la funzione fallisce
3757 con \errcode{EBUSY} se c'è un altro processo già registrato.\footnote{questo
3758 significa anche che se si registra una notifica con \const{SIGEV\_NONE} il
3759 processo non la riceverà, ma impedirà anche che altri possano registrarsi
3760 per poterlo fare.} Si tenga presente inoltre che alla chiusura del
3761 descrittore associato alla coda (e quindi anche all'uscita del processo) ogni
3762 eventuale registrazione di notifica presente viene cancellata.
3764 La notifica del segnale avviene all'arrivo di un messaggio in una coda vuota
3765 (cioè solo se sulla coda non ci sono messaggi) e se non c'è nessun processo
3766 bloccato in una chiamata a \func{mq\_receive}, in questo caso infatti il
3767 processo bloccato ha la precedenza ed il messaggio gli viene immediatamente
3768 inviato, mentre per il meccanismo di notifica tutto funziona come se la coda
3769 fosse rimasta vuota.
3771 Quando un messaggio arriva su una coda vuota al processo che si era registrato
3772 viene inviato il segnale specificato da \code{notification->sigev\_signo}, e
3773 la coda diventa disponibile per una ulteriore registrazione. Questo comporta
3774 che se si vuole mantenere il meccanismo di notifica occorre ripetere la
3775 registrazione chiamando nuovamente \func{mq\_notify} all'interno del gestore
3776 del segnale di notifica. A differenza della situazione simile che si aveva con
3777 i segnali non affidabili,\footnote{l'argomento è stato affrontato in
3778 \ref{sec:sig_semantics}.} questa caratteristica non configura una
3779 \itindex{race~condition} \textit{race condition} perché l'invio di un segnale
3780 avviene solo se la coda è vuota; pertanto se si vuole evitare di correre il
3781 rischio di perdere eventuali ulteriori segnali inviati nel lasso di tempo che
3782 occorre per ripetere la richiesta di notifica basta avere cura di eseguire
3783 questa operazione prima di estrarre i messaggi presenti dalla coda.
3785 L'invio del segnale di notifica avvalora alcuni campi di informazione
3786 restituiti al gestore attraverso la struttura \struct{siginfo\_t} (definita in
3787 fig.~\ref{fig:sig_siginfo_t}). In particolare \var{si\_pid} viene impostato al
3788 valore del \ids{PID} del processo che ha emesso il segnale, \var{si\_uid}
3789 all'userid effettivo, \var{si\_code} a \const{SI\_MESGQ}, e \var{si\_errno} a
3790 0. Questo ci dice che, se si effettua la ricezione dei messaggi usando
3791 esclusivamente il meccanismo di notifica, è possibile ottenere le informazioni
3792 sul processo che ha inserito un messaggio usando un gestore per il segnale in
3793 forma estesa.\footnote{di nuovo si faccia riferimento a quanto detto al
3794 proposito in sez.~\ref{sec:sig_sigaction} e sez.~\ref{sec:sig_real_time}.}
3798 \subsection{Memoria condivisa}
3799 \label{sec:ipc_posix_shm}
3801 La memoria condivisa è stato il primo degli oggetti di IPC POSIX inserito nel
3802 kernel ufficiale; il supporto a questo tipo di oggetti è realizzato attraverso
3803 il filesystem \texttt{tmpfs}, uno speciale filesystem che mantiene tutti i
3804 suoi contenuti in memoria, che viene attivato abilitando l'opzione
3805 \texttt{CONFIG\_TMPFS} in fase di compilazione del kernel.
3807 Per potere utilizzare l'interfaccia POSIX per la memoria condivisa la
3808 \acr{glibc}\footnote{le funzioni sono state introdotte con la versione 2.2.}
3809 richiede di compilare i programmi con l'opzione \code{-lrt}; inoltre è
3810 necessario che in \file{/dev/shm} sia montato un filesystem \texttt{tmpfs};
3811 questo di norma viene fatto aggiungendo una riga del tipo di:
3813 tmpfs /dev/shm tmpfs defaults 0 0
3815 ad \conffile{/etc/fstab}. In realtà si può montare un filesystem \texttt{tmpfs}
3816 dove si vuole, per usarlo come RAM disk, con un comando del tipo:
3818 mount -t tmpfs -o size=128M,nr_inodes=10k,mode=700 tmpfs /mytmpfs
3821 Il filesystem riconosce, oltre quelle mostrate, le opzioni \texttt{uid} e
3822 \texttt{gid} che identificano rispettivamente utente e gruppo cui assegnarne
3823 la titolarità, e \texttt{nr\_blocks} che permette di specificarne la
3824 dimensione in blocchi, cioè in multipli di \const{PAGECACHE\_SIZE} che in
3825 questo caso è l'unità di allocazione elementare.
3827 La funzione che permette di aprire un segmento di memoria condivisa POSIX, ed
3828 eventualmente di crearlo se non esiste ancora, è \funcd{shm\_open}; il suo
3831 \headdecl{sys/mman.h}
3832 \headdecl{sys/stat.h}
3835 \funcdecl{int shm\_open(const char *name, int oflag, mode\_t mode)}
3837 Apre un segmento di memoria condivisa.
3839 \bodydesc{La funzione restituisce un file descriptor positivo in caso di
3840 successo e -1 in caso di errore; nel quel caso \var{errno} assumerà gli
3841 stessi valori riportati da \func{open}.}
3844 La funzione apre un segmento di memoria condivisa identificato dal nome
3845 \param{name}. Come già spiegato in sez.~\ref{sec:ipc_posix_generic} questo
3846 nome può essere specificato in forma standard solo facendolo iniziare per
3847 ``\file{/}'' e senza ulteriori ``\file{/}''. Linux supporta comunque nomi
3848 generici, che verranno interpretati prendendo come radice
3849 \file{/dev/shm}.\footnote{occorre pertanto evitare di specificare qualcosa del
3850 tipo \file{/dev/shm/nome} all'interno di \param{name}, perché questo
3851 comporta, da parte delle funzioni di libreria, il tentativo di accedere a
3852 \file{/dev/shm/dev/shm/nome}.}
3854 La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
3855 possono essere specificati per \param{oflag}, che deve essere specificato come
3856 maschera binaria comprendente almeno uno dei due valori \const{O\_RDONLY} e
3857 \const{O\_RDWR}; i valori possibili per i vari bit sono quelli visti in
3858 sez.~\ref{sec:file_open_close} dei quali però \func{shm\_open} riconosce solo
3860 \begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
3861 \item[\const{O\_RDONLY}] Apre il file descriptor associato al segmento di
3862 memoria condivisa per l'accesso in sola lettura.
3863 \item[\const{O\_RDWR}] Apre il file descriptor associato al segmento di
3864 memoria condivisa per l'accesso in lettura e scrittura.
3865 \item[\const{O\_CREAT}] Necessario qualora si debba creare il segmento di
3866 memoria condivisa se esso non esiste; in questo caso viene usato il valore
3867 di \param{mode} per impostare i permessi, che devono essere compatibili con
3868 le modalità con cui si è aperto il file.
3869 \item[\const{O\_EXCL}] Se usato insieme a \const{O\_CREAT} fa fallire la
3870 chiamata a \func{shm\_open} se il segmento esiste già, altrimenti esegue la
3871 creazione atomicamente.
3872 \item[\const{O\_TRUNC}] Se il segmento di memoria condivisa esiste già, ne
3873 tronca le dimensioni a 0 byte.
3876 In caso di successo la funzione restituisce un file descriptor associato al
3877 segmento di memoria condiviso con le stesse modalità di
3878 \func{open}\footnote{in realtà, come accennato, \func{shm\_open} è un semplice
3879 wrapper per \func{open}, usare direttamente quest'ultima avrebbe lo stesso
3880 effetto.} viste in sez.~\ref{sec:file_open_close}; in particolare viene impostato
3881 il flag \const{FD\_CLOEXEC}. Chiamate effettuate da diversi processi usando
3882 lo stesso nome, restituiranno file descriptor associati allo stesso segmento
3883 (così come, nel caso di file di dati, essi sono associati allo stesso
3884 \itindex{inode} inode). In questo modo è possibile effettuare una chiamata ad
3885 \func{mmap} sul file descriptor restituito da \func{shm\_open} ed i processi
3886 vedranno lo stesso segmento di memoria condivisa.
3888 Quando il nome non esiste il segmento può essere creato specificando
3889 \const{O\_CREAT}; in tal caso il segmento avrà (così come i nuovi file)
3890 lunghezza nulla. Dato che un segmento di lunghezza nulla è di scarsa utilità,
3891 per impostarne la dimensione si deve usare \func{ftruncate} (vedi
3892 sez.~\ref{sec:file_file_size}), prima di mapparlo in memoria con \func{mmap}.
3893 Si tenga presente che una volta chiamata \func{mmap} si può chiudere il file
3894 descriptor (con \func{close}), senza che la mappatura ne risenta.
3896 Come per i file, quando si vuole effettivamente rimuovere segmento di memoria
3897 condivisa, occorre usare la funzione \funcd{shm\_unlink}, il cui prototipo è:
3898 \begin{prototype}{sys/mman.h}
3899 {int shm\_unlink(const char *name)}
3901 Rimuove un segmento di memoria condivisa.
3903 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
3904 errore; nel quel caso \var{errno} assumerà gli stessi valori riportati da
3908 La funzione è del tutto analoga ad \func{unlink}, e si limita a cancellare il
3909 nome del segmento da \file{/dev/shm}, senza nessun effetto né sui file
3910 descriptor precedentemente aperti con \func{shm\_open}, né sui segmenti già
3911 mappati in memoria; questi verranno cancellati automaticamente dal sistema
3912 solo con le rispettive chiamate a \func{close} e \func{munmap}. Una volta
3913 eseguita questa funzione però, qualora si richieda l'apertura di un segmento
3914 con lo stesso nome, la chiamata a \func{shm\_open} fallirà, a meno di non aver
3915 usato \const{O\_CREAT}, in quest'ultimo caso comunque si otterrà un file
3916 descriptor che fa riferimento ad un segmento distinto da eventuali precedenti.
3918 \begin{figure}[!htbp]
3919 \footnotesize \centering
3920 \begin{minipage}[c]{\codesamplewidth}
3921 \includecodesample{listati/MemShared.c}
3924 \caption{Il codice delle funzioni di gestione dei segmenti di memoria
3926 \label{fig:ipc_posix_shmmem}
3929 Come esempio per l'uso di queste funzioni vediamo come è possibile riscrivere
3930 una interfaccia semplificata analoga a quella vista in
3931 fig.~\ref{fig:ipc_sysv_shm_func} per la memoria condivisa in stile SysV. Il
3932 codice, riportato in fig.~\ref{fig:ipc_posix_shmmem}, è sempre contenuto nel
3933 file \file{SharedMem.c} dei sorgenti allegati.
3935 La prima funzione (\texttt{\small 1--24}) è \func{CreateShm} che, dato un nome
3936 nell'argomento \var{name} crea un nuovo segmento di memoria condivisa,
3937 accessibile in lettura e scrittura, e ne restituisce l'indirizzo. Anzitutto si
3938 definiscono (\texttt{\small 8}) i flag per la successiva (\texttt{\small 9})
3939 chiamata a \func{shm\_open}, che apre il segmento in lettura e scrittura
3940 (creandolo se non esiste, ed uscendo in caso contrario) assegnandogli sul
3941 filesystem i permessi specificati dall'argomento \var{perm}. In caso di errore
3942 (\texttt{\small 10--12}) si restituisce un puntatore nullo, altrimenti si
3943 prosegue impostando (\texttt{\small 14}) la dimensione del segmento con
3944 \func{ftruncate}. Di nuovo (\texttt{\small 15--16}) si esce immediatamente
3945 restituendo un puntatore nullo in caso di errore. Poi si passa (\texttt{\small
3946 18}) a mappare in memoria il segmento con \func{mmap} specificando dei
3947 diritti di accesso corrispondenti alla modalità di apertura. Di nuovo si
3948 restituisce (\texttt{\small 19--21}) un puntatore nullo in caso di errore,
3949 altrimenti si inizializza (\texttt{\small 22}) il contenuto del segmento al
3950 valore specificato dall'argomento \var{fill} con \func{memset}, e se ne
3951 restituisce (\texttt{\small 23}) l'indirizzo.
3953 La seconda funzione (\texttt{\small 25--40}) è \func{FindShm} che trova un
3954 segmento di memoria condiviso già esistente, restituendone l'indirizzo. In
3955 questo caso si apre (\texttt{\small 31}) il segmento con \func{shm\_open}
3956 richiedendo che il segmento sia già esistente, in caso di errore
3957 (\texttt{\small 31--33}) si ritorna immediatamente un puntatore nullo.
3958 Ottenuto il file descriptor del segmento lo si mappa (\texttt{\small 35}) in
3959 memoria con \func{mmap}, restituendo (\texttt{\small 36--38}) un puntatore
3960 nullo in caso di errore, o l'indirizzo (\texttt{\small 39}) dello stesso in
3963 La terza funzione (\texttt{\small 40--45}) è \func{RemoveShm}, e serve a
3964 cancellare un segmento di memoria condivisa. Dato che al contrario di quanto
3965 avveniva con i segmenti del SysV IPC gli oggetti allocati nel kernel vengono
3966 rilasciati automaticamente quando nessuna li usa più, tutto quello che c'è da
3967 fare (\texttt{\small 44}) in questo caso è chiamare \func{shm\_unlink},
3968 restituendo al chiamante il valore di ritorno.
3973 \subsection{Semafori}
3974 \label{sec:ipc_posix_sem}
3976 Fino alla serie 2.4.x del kernel esisteva solo una implementazione parziale
3977 dei semafori POSIX che li realizzava solo a livello di \itindex{thread}
3978 \textit{thread} e non di processi,\footnote{questo significava che i semafori
3979 erano visibili solo all'interno dei \itindex{thread} \textit{thread} creati
3980 da un singolo processo, e non potevano essere usati come meccanismo di
3981 sincronizzazione fra processi diversi.} fornita attraverso la sezione delle
3982 estensioni \textit{real-time} della \acr{glibc}.\footnote{quelle che si
3983 accedono collegandosi alla libreria \texttt{librt}.} Esisteva inoltre una
3984 libreria che realizzava (parzialmente) l'interfaccia POSIX usando le funzioni
3985 dei semafori di SysV IPC (mantenendo così tutti i problemi sottolineati in
3986 sez.~\ref{sec:ipc_sysv_sem}).
3988 A partire dal kernel 2.5.7 è stato introdotto un meccanismo di
3989 sincronizzazione completamente nuovo, basato sui cosiddetti
3990 \textit{futex},\footnote{la sigla sta per \textit{fast user mode mutex}.} con
3991 il quale è stato possibile implementare una versione nativa dei semafori
3992 POSIX. Grazie a questo con i kernel della serie 2.6 e le nuove versioni della
3993 \acr{glibc} che usano questa nuova infrastruttura per quella che viene quella
3994 che viene chiamata \textit{New Posix Thread Library}, sono state implementate
3995 anche tutte le funzioni dell'interfaccia dei semafori POSIX.
3997 Anche in questo caso è necessario appoggiarsi alla libreria per le estensioni
3998 \textit{real-time} \texttt{librt}, questo significa che se si vuole utilizzare
3999 questa interfaccia, oltre ad utilizzare gli opportuni file di definizione,
4000 occorrerà compilare i programmi con l'opzione \texttt{-lrt}.
4002 La funzione che permette di creare un nuovo semaforo POSIX, creando il
4003 relativo file, o di accedere ad uno esistente, è \funcd{sem\_open}, questa
4004 prevede due forme diverse a seconda che sia utilizzata per aprire un semaforo
4005 esistente o per crearne uno nuovi, i relativi prototipi sono:
4007 \headdecl{semaphore.h}
4009 \funcdecl{sem\_t *sem\_open(const char *name, int oflag)}
4011 \funcdecl{sem\_t *sem\_open(const char *name, int oflag, mode\_t mode,
4012 unsigned int value)}
4014 Crea un semaforo o ne apre uno esistente.
4016 \bodydesc{La funzione restituisce l'indirizzo del semaforo in caso di
4017 successo e \const{SEM\_FAILED} in caso di errore; nel quel caso
4018 \var{errno} assumerà i valori:
4020 \item[\errcode{EACCES}] il semaforo esiste ma non si hanno permessi
4021 sufficienti per accedervi.
4022 \item[\errcode{EEXIST}] si sono specificati \const{O\_CREAT} e
4023 \const{O\_EXCL} ma il semaforo esiste.
4024 \item[\errcode{EINVAL}] il valore di \param{value} eccede
4025 \const{SEM\_VALUE\_MAX}.
4026 \item[\errcode{ENAMETOOLONG}] si è utilizzato un nome troppo lungo.
4027 \item[\errcode{ENOENT}] non si è usato \const{O\_CREAT} ed il nome
4028 specificato non esiste.
4030 ed inoltre \errval{ENFILE} ed \errval{ENOMEM}.}
4033 L'argomento \param{name} definisce il nome del semaforo che si vuole
4034 utilizzare, ed è quello che permette a processi diversi di accedere allo
4035 stesso semaforo. Questo deve essere specificato con un \textit{pathname} nella
4036 forma \texttt{/qualchenome}, che non ha una corrispondenza diretta con un
4037 \textit{pathname} reale; con Linux infatti i file associati ai semafori sono
4038 mantenuti nel filesystem virtuale \texttt{/dev/shm}, e gli viene assegnato
4039 automaticamente un nome nella forma \texttt{sem.qualchenome}.\footnote{si ha
4040 cioè una corrispondenza per cui \texttt{/qualchenome} viene rimappato, nella
4041 creazione tramite \func{sem\_open}, su \texttt{/dev/shm/sem.qualchenome}.}
4043 L'argomento \param{oflag} è quello che controlla le modalità con cui opera la
4044 funzione, ed è passato come maschera binaria; i bit corrispondono a quelli
4045 utilizzati per l'analogo argomento di \func{open}, anche se dei possibili
4046 valori visti in sez.~\ref{sec:file_open_close} sono utilizzati soltanto
4047 \const{O\_CREAT} e \const{O\_EXCL}.
4049 Se si usa \const{O\_CREAT} si richiede la creazione del semaforo qualora
4050 questo non esista, ed in tal caso occorre utilizzare la seconda forma della
4051 funzione, in cui si devono specificare sia un valore iniziale con l'argomento
4052 \param{value},\footnote{e si noti come così diventa possibile, differenza di
4053 quanto avviene per i semafori del \textit{SysV IPC}, effettuare in maniera
4054 atomica creazione ed inizializzazione di un semaforo usando una unica
4055 funzione.} che una maschera dei permessi con l'argomento
4056 \param{mode};\footnote{anche questo argomento prende gli stessi valori
4057 utilizzati per l'analogo di \func{open}, che si sono illustrati in dettaglio
4058 sez.~\ref{sec:file_perm_overview}.} questi verranno assegnati al semaforo
4059 appena creato. Se il semaforo esiste già i suddetti valori saranno invece
4060 ignorati. Usando il flag \const{O\_EXCL} si richiede invece la verifica che il
4061 semaforo non esiste, usandolo insieme ad \const{O\_CREAT} la funzione fallisce
4062 qualora un semaforo con lo stesso nome sia già presente.
4064 La funzione restituisce in caso di successo un puntatore all'indirizzo del
4065 semaforo con un valore di tipo \ctyp{sem\_t *}, è questo valore che dovrà
4066 essere passato alle altre funzioni per operare sul semaforo stesso. Si tenga
4067 presente che, come accennato in sez.~\ref{sec:ipc_posix_generic}, i semafori
4068 usano la semantica standard dei file per quanto riguarda i controlli di
4071 Questo significa che un nuovo semaforo viene sempre creato con l'\ids{UID} ed
4072 il \ids{GID} effettivo del processo chiamante, e che i permessi indicati con
4073 \param{mode} vengono filtrati dal valore della \itindex{umask} \textit{umask}
4074 del processo. Inoltre per poter aprire un semaforo è necessario avere su di
4075 esso sia il permesso di lettura che quello di scrittura.
4077 Una volta che si sia ottenuto l'indirizzo di un semaforo, sarà possibile
4078 utilizzarlo; se si ricorda quanto detto all'inizio di
4079 sez.~\ref{sec:ipc_sysv_sem}, dove si sono introdotti i concetti generali
4080 relativi ai semafori, le operazioni principali sono due, quella che richiede
4081 l'uso di una risorsa bloccando il semaforo e quella che rilascia la risorsa
4082 liberando il semaforo. La prima operazione è effettuata dalla funzione
4083 \funcd{sem\_wait}, il cui prototipo è:
4085 \headdecl{semaphore.h}
4087 \funcdecl{int sem\_wait(sem\_t *sem)}
4089 Blocca il semaforo \param{sem}.
4091 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
4092 errore; nel quel caso \var{errno} assumerà i valori:
4094 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
4095 \item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
4100 La funzione cerca di decrementare il valore del semaforo indicato dal
4101 puntatore \param{sem}, se questo ha un valore positivo, cosa che significa che
4102 la risorsa è disponibile, la funzione ha successo, il valore del semaforo
4103 viene diminuito di 1 ed essa ritorna immediatamente; se il valore è nullo la
4104 funzione si blocca fintanto che il valore del semaforo non torni
4105 positivo\footnote{ovviamente per opera di altro processo che lo rilascia
4106 chiamando \func{sem\_post}.} così che poi essa possa decrementarlo con
4107 successo e proseguire.
4109 Si tenga presente che la funzione può sempre essere interrotta da un segnale
4110 (nel qual caso si avrà un errore di \const{EINTR}) e che questo avverrà
4111 comunque, anche se si è richiesta la semantica BSD installando il relativo
4112 gestore con \const{SA\_RESTART} (vedi sez.~\ref{sec:sig_sigaction}) per
4113 riavviare le system call interrotte.
4115 Della funzione \func{sem\_wait} esistono due varianti che consentono di
4116 gestire diversamente le modalità di attesa in caso di risorsa occupata, la
4117 prima di queste è \funcd{sem\_trywait}, che serve ad effettuare un tentativo
4118 di acquisizione senza bloccarsi; il suo prototipo è:
4120 \headdecl{semaphore.h}
4122 \funcdecl{int sem\_trywait(sem\_t *sem)}
4124 Tenta di bloccare il semaforo \param{sem}.
4126 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
4127 errore; nel quel caso \var{errno} assumerà gli stessi valori:
4129 \item[\errcode{EAGAIN}] il semaforo non può essere acquisito senza
4131 \item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
4136 La funzione è identica a \func{sem\_wait} ed se la risorsa è libera ha lo
4137 stesso effetto, vale a dire che in caso di semaforo diverso da zero la
4138 funzione lo decrementa e ritorna immediatamente; la differenza è che nel caso
4139 in cui il semaforo è occupato essa non si blocca e di nuovo ritorna
4140 immediatamente, restituendo però un errore di \errval{EAGAIN}, così che il
4141 programma possa proseguire.
4143 La seconda variante di \func{sem\_wait} è una estensione specifica che può
4144 essere utilizzata soltanto se viene definita la macro \macro{\_XOPEN\_SOURCE}
4145 ad un valore di 600 prima di includere \headfile{semaphore.h}, la funzione è
4146 \funcd{sem\_timedwait}, ed il suo prototipo è:
4148 \headdecl{semaphore.h}
4150 \funcdecl{int sem\_timedwait(sem\_t *sem, const struct timespec
4153 Blocca il semaforo \param{sem}.
4155 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
4156 errore; nel quel caso \var{errno} assumerà gli stessi valori:
4158 \item[\errcode{ETIMEDOUT}] è scaduto il tempo massimo di attesa.
4159 \item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
4160 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
4165 Anche in questo caso il comportamento della funzione è identico a quello di
4166 \func{sem\_wait}, la sola differenza consiste nel fatto che con questa
4167 funzione è possibile impostare tramite l'argomento \param{abs\_timeout} un
4168 tempo limite per l'attesa, scaduto il quale la funzione ritorna comunque,
4169 anche se non è possibile acquisire il semaforo. In tal caso la funzione
4170 fallirà, riportando un errore di \errval{ETIMEDOUT}.
4172 La seconda funzione principale utilizzata per l'uso dei semafori è
4173 \funcd{sem\_post}, che viene usata per rilasciare un semaforo occupato o, in
4174 generale, per aumentare di una unità il valore dello stesso anche qualora non
4175 fosse occupato;\footnote{si ricordi che in generale un semaforo viene usato
4176 come indicatore di un numero di risorse disponibili.} il suo prototipo è:
4178 \headdecl{semaphore.h}
4180 \funcdecl{int sem\_post(sem\_t *sem)}
4182 Rilascia il semaforo \param{sem}.
4184 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
4185 errore; nel quel caso \var{errno} assumerà i valori:
4187 \item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
4192 La funzione incrementa di uno il valore corrente del semaforo indicato
4193 dall'argomento \param{sem}, se questo era nullo la relativa risorsa risulterà
4194 sbloccata, cosicché un altro processo (o \itindex{thread} \textit{thread})
4195 eventualmente bloccato in una \func{sem\_wait} sul semaforo potrà essere
4196 svegliato e rimesso in esecuzione. Si tenga presente che la funzione è sicura
4197 \index{funzioni!sicure} per l'uso all'interno di un gestore di segnali (si
4198 ricordi quanto detto in sez.~\ref{sec:sig_signal_handler}).
4200 Se invece di operare su un semaforo se ne vuole solamente leggere il valore,
4201 si può usare la funzione \funcd{sem\_getvalue}, il cui prototipo è:
4203 \headdecl{semaphore.h}
4205 \funcdecl{int sem\_getvalue(sem\_t *sem, int *sval)}
4207 Richiede il valore del semaforo \param{sem}.
4209 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
4210 errore; nel quel caso \var{errno} assumerà i valori:
4212 \item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
4217 La funzione legge il valore del semaforo indicato dall'argomento \param{sem} e
4218 lo restituisce nella variabile intera puntata dall'argomento
4219 \param{sval}. Qualora ci siano uno o più processi bloccati in attesa sul
4220 semaforo lo standard prevede che la funzione possa restituire un valore nullo
4221 oppure il numero di processi bloccati in una \func{sem\_wait} sul suddetto
4222 semaforo; nel caso di Linux vale la prima opzione.
4224 Questa funzione può essere utilizzata per avere un suggerimento sullo stato di
4225 un semaforo, ovviamente non si può prendere il risultato riportato in
4226 \param{sval} che come indicazione, il valore del semaforo infatti potrebbe
4227 essere già stato modificato al ritorno della funzione.
4229 % TODO verificare comportamento sem_getvalue
4231 Una volta che non ci sia più la necessità di operare su un semaforo se ne può
4232 terminare l'uso con la funzione \funcd{sem\_close}, il cui prototipo è:
4234 \headdecl{semaphore.h}
4236 \funcdecl{int sem\_close(sem\_t *sem)}
4238 Chiude il semaforo \param{sem}.
4240 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
4241 errore; nel quel caso \var{errno} assumerà i valori:
4243 \item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
4248 La funzione chiude il semaforo indicato dall'argomento \param{sem}; questo
4249 comporta che tutte le risorse che il sistema può avere assegnato al processo
4250 nell'uso dello stesso vengono rilasciate. Questo significa che un altro
4251 processo bloccato sul semaforo a causa della acquisizione da parte del
4252 processo che chiama \func{sem\_close} potrà essere riavviato.
4254 Si tenga presente poi che come per i file all'uscita di un processo tutti i
4255 semafori che questo aveva aperto vengono automaticamente chiusi; questo
4256 comportamento risolve il problema che si aveva con i semafori del \textit{SysV
4257 IPC} (di cui si è parlato in sez.~\ref{sec:ipc_sysv_sem}) per i quali le
4258 risorse possono restare bloccate. Si tenga poi presente che, a differenza di
4259 quanto avviene per i file, in caso di una chiamata ad \func{execve} tutti i
4260 semafori vengono chiusi automaticamente.
4262 Come per i semafori del \textit{SysV IPC} anche quelli POSIX hanno una
4263 persistenza di sistema; questo significa che una volta che si è creato un
4264 semaforo con \func{sem\_open} questo continuerà ad esistere fintanto che il
4265 kernel resta attivo (vale a dire fino ad un successivo riavvio) a meno che non
4266 lo si cancelli esplicitamente. Per far questo si può utilizzare la funzione
4267 \funcd{sem\_unlink}, il cui prototipo è:
4269 \headdecl{semaphore.h}
4271 \funcdecl{int sem\_unlink(const char *name)}
4273 Rimuove il semaforo \param{name}.
4275 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
4276 errore; nel quel caso \var{errno} assumerà i valori:
4278 \item[\errcode{EACCES}] non si hanno i permessi necessari a cancellare il
4280 \item[\errcode{ENAMETOOLONG}] il nome indicato è troppo lungo.
4281 \item[\errcode{ENOENT}] il semaforo \param{name} non esiste.
4286 La funzione rimuove il semaforo indicato dall'argomento \param{name}, che
4287 prende un valore identico a quello usato per creare il semaforo stesso con
4288 \func{sem\_open}. Il semaforo viene rimosso dal filesystem immediatamente; ma
4289 il semaforo viene effettivamente cancellato dal sistema soltanto quando tutti
4290 i processi che lo avevano aperto lo chiudono. Si segue cioè la stessa
4291 semantica usata con \func{unlink} per i file, trattata in dettaglio in
4292 sez.~\ref{sec:link_symlink_rename}.
4294 Una delle caratteristiche peculiari dei semafori POSIX è che questi possono
4295 anche essere utilizzati anche in forma anonima, senza necessità di fare
4296 ricorso ad un nome sul filesystem o ad altri indicativi. In questo caso si
4297 dovrà porre la variabile che contiene l'indirizzo del semaforo in un tratto di
4298 memoria che sia accessibile a tutti i processi in gioco. La funzione che
4299 consente di inizializzare un semaforo anonimo è \funcd{sem\_init}, il cui
4302 \headdecl{semaphore.h}
4304 \funcdecl{int sem\_init(sem\_t *sem, int pshared, unsigned int value)}
4306 Inizializza il semaforo anonimo \param{sem}.
4308 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
4309 errore; nel quel caso \var{errno} assumerà i valori:
4311 \item[\errcode{EINVAL}] il valore di \param{value} eccede
4312 \const{SEM\_VALUE\_MAX}.
4313 \item[\errcode{ENOSYS}] il valore di \param{pshared} non è nullo ed il
4314 sistema non supporta i semafori per i processi.
4319 La funzione inizializza un semaforo all'indirizzo puntato dall'argomento
4320 \param{sem}, e come per \func{sem\_open} consente di impostare un valore
4321 iniziale con \param{value}. L'argomento \param{pshared} serve ad indicare se
4322 il semaforo deve essere utilizzato dai \itindex{thread} \textit{thread} di uno
4323 stesso processo (con un valore nullo) o condiviso fra processi diversi (con un
4326 Qualora il semaforo debba essere condiviso dai \itindex{thread}
4327 \textit{thread} di uno stesso processo (nel qual caso si parla di
4328 \textit{thread-shared semaphore}), occorrerà che \param{sem} sia l'indirizzo
4329 di una variabile visibile da tutti i \itindex{thread} \textit{thread}, si
4330 dovrà usare cioè una \index{variabili!globali} variabile globale o una
4331 variabile allocata dinamicamente nello \itindex{heap} \textit{heap}.
4333 Qualora il semaforo debba essere condiviso fra più processi (nel qual caso si
4334 parla di \textit{process-shared semaphore}) la sola scelta possibile per
4335 renderlo visibile a tutti è di porlo in un tratto di memoria condivisa. Questo
4336 potrà essere ottenuto direttamente sia con \func{shmget} (vedi
4337 sez.~\ref{sec:ipc_sysv_shm}) che con \func{shm\_open} (vedi
4338 sez.~\ref{sec:ipc_posix_shm}), oppure, nel caso che tutti i processi in gioco
4339 abbiano un genitore comune, con una mappatura anonima con \func{mmap} (vedi
4340 sez.~\ref{sec:file_memory_map}),\footnote{si ricordi che i tratti di memoria
4341 condivisa vengono mantenuti nei processi figli attraverso la funzione
4342 \func{fork}.} a cui essi poi potranno accedere.
4344 Una volta inizializzato il semaforo anonimo con \func{sem\_init} lo si potrà
4345 utilizzare nello stesso modo dei semafori normali con \func{sem\_wait} e
4346 \func{sem\_post}. Si tenga presente però che inizializzare due volte lo stesso
4347 semaforo può dar luogo ad un comportamento indefinito.
4349 Una volta che non si intenda più utilizzare un semaforo anonimo questo può
4350 essere eliminato dal sistema; per far questo di deve utilizzare una apposita
4351 funzione, \funcd{sem\_destroy}, il cui prototipo è:
4353 \headdecl{semaphore.h}
4355 \funcdecl{int sem\_destroy(sem\_t *sem)}
4357 Elimina il semaforo anonimo \param{sem}.
4359 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
4360 errore; nel quel caso \var{errno} assumerà i valori:
4362 \item[\errcode{EINVAL}] il valore di \param{value} eccede
4363 \const{SEM\_VALUE\_MAX}.
4368 La funzione prende come unico argomento l'indirizzo di un semaforo che deve
4369 essere stato inizializzato con \func{sem\_init}; non deve quindi essere
4370 applicata a semafori creati con \func{sem\_open}. Inoltre si deve essere
4371 sicuri che il semaforo sia effettivamente inutilizzato, la distruzione di un
4372 semaforo su cui sono presenti processi (o \itindex{thread} \textit{thread}) in
4373 attesa (cioè bloccati in una \func{sem\_wait}) provoca un comportamento
4376 Si tenga presente infine che utilizzare un semaforo che è stato distrutto con
4377 \func{sem\_destroy} di nuovo può dare esito a comportamenti indefiniti. Nel
4378 caso ci si trovi in una tale evenienza occorre reinizializzare il semaforo una
4379 seconda volta con \func{sem\_init}.
4381 Come esempio di uso sia della memoria condivisa che dei semafori POSIX si sono
4382 scritti due semplici programmi con i quali è possibile rispettivamente
4383 monitorare il contenuto di un segmento di memoria condivisa e modificarne il
4386 \begin{figure}[!htbp]
4387 \footnotesize \centering
4388 \begin{minipage}[c]{\codesamplewidth}
4389 \includecodesample{listati/message_getter.c}
4392 \caption{Sezione principale del codice del programma
4393 \file{message\_getter.c}.}
4394 \label{fig:ipc_posix_sem_shm_message_server}
4397 Il corpo principale del primo dei due, il cui codice completo è nel file
4398 \file{message\_getter.c} dei sorgenti allegati, è riportato in
4399 fig.~\ref{fig:ipc_posix_sem_shm_message_server}; si è tralasciata la parte che
4400 tratta la gestione delle opzioni a riga di comando (che consentono di
4401 impostare un nome diverso per il semaforo e il segmento di memoria condivisa)
4402 ed il controllo che al programma venga fornito almeno un argomento, contenente
4403 la stringa iniziale da inserire nel segmento di memoria condivisa.
4405 Lo scopo del programma è quello di creare un segmento di memoria condivisa su
4406 cui registrare una stringa, e tenerlo sotto osservazione stampando la stessa
4407 una volta al secondo. Si utilizzerà un semaforo per proteggere l'accesso in
4408 lettura alla stringa, in modo che questa non possa essere modificata
4409 dall'altro programma prima di averla finita di stampare.
4411 La parte iniziale del programma contiene le definizioni (\texttt{\small 1--8})
4412 del gestore del segnale usato per liberare le risorse utilizzate, delle
4413 \index{variabili!globali} variabili globali contenenti i nomi di default del
4414 segmento di memoria condivisa e del semaforo (il default scelto è
4415 \texttt{messages}), e delle altre variabili utilizzate dal programma.
4417 Come prima istruzione (\texttt{\small 10}) si è provveduto ad installare un
4418 gestore di segnale che consentirà di effettuare le operazioni di pulizia
4419 (usando la funzione \func{Signal} illustrata in
4420 fig.~\ref{fig:sig_Signal_code}), dopo di che (\texttt{\small 10--16}) si è
4421 creato il segmento di memoria condivisa con la funzione \func{CreateShm} che
4422 abbiamo appena trattato in sez.~\ref{sec:ipc_posix_shm}, uscendo con un
4423 messaggio in caso di errore.
4425 Si tenga presente che la funzione \func{CreateShm} richiede che il segmento
4426 non sia già presente e fallirà qualora un'altra istanza, o un altro programma
4427 abbia già allocato un segmento con quello stesso nome. Per semplicità di
4428 gestione si è usata una dimensione fissa pari a 256 byte, definita tramite la
4429 costante \texttt{MSGMAXSIZE}.
4431 Il passo successivo (\texttt{\small 17--21}) è quello della creazione del
4432 semaforo che regola l'accesso al segmento di memoria condivisa con
4433 \func{sem\_open}; anche in questo caso si gestisce l'uscita con stampa di un
4434 messaggio in caso di errore. Anche per il semaforo, avendo specificato la
4435 combinazione di flag \code{O\_CREAT|O\_EXCL} come secondo argomento, si esce
4436 qualora fosse già esistente; altrimenti esso verrà creato con gli opportuni
4437 permessi specificati dal terzo argomento, (indicante lettura e scrittura in
4438 notazione ottale). Infine il semaforo verrà inizializzato ad un valore nullo
4439 (il quarto argomento), corrispondete allo stato in cui risulta bloccato.
4441 A questo punto (\texttt{\small 23}) si potrà inizializzare il messaggio posto
4442 nel segmento di memoria condivisa usando la stringa passata come argomento al
4443 programma. Essendo il semaforo stato creato già bloccato non ci si dovrà
4444 preoccupare di eventuali \itindex{race~condition} \textit{race condition}
4445 qualora il programma di modifica del messaggio venisse lanciato proprio in
4446 questo momento. Una volta inizializzato il messaggio occorrerà però
4447 rilasciare il semaforo (\texttt{\small 25--28}) per consentirne l'uso; in
4448 tutte queste operazioni si provvederà ad uscire dal programma con un opportuno
4449 messaggio in caso di errore.
4451 Una volta completate le inizializzazioni il ciclo principale del programma
4452 (\texttt{\small 29--47}) viene ripetuto indefinitamente (\texttt{\small 29})
4453 per stampare sia il contenuto del messaggio che una serie di informazioni di
4454 controllo. Il primo passo (\texttt{\small 30--34}) è quello di acquisire (con
4455 \func{sem\_getvalue}, con uscita in caso di errore) e stampare il valore del
4456 semaforo ad inizio del ciclo; seguito (\texttt{\small 35--36}) dal tempo
4459 \begin{figure}[!htbp]
4460 \footnotesize \centering
4461 \begin{minipage}[c]{\codesamplewidth}
4462 \includecodesample{listati/HandSigInt.c}
4465 \caption{Codice del gestore di segnale del programma
4466 \file{message\_getter.c}.}
4467 \label{fig:ipc_posix_sem_shm_message_server_handler}
4470 Prima della stampa del messaggio invece si deve acquisire il semaforo
4471 (\texttt{\small 31--34}) per evitare accessi concorrenti alla stringa da parte
4472 del programma di modifica. Una volta eseguita la stampa (\texttt{\small 41})
4473 il semaforo dovrà essere rilasciato (\texttt{\small 42--45}). Il passo finale
4474 (\texttt{\small 46}) è attendere per un secondo prima di eseguire da capo il
4477 Per uscire in maniera corretta dal programma sarà necessario interromperlo con
4478 il break da tastiera (\texttt{C-c}), che corrisponde all'invio del segnale
4479 \signal{SIGINT}, per il quale si è installato (\texttt{\small 10}) una
4480 opportuna funzione di gestione, riportata in
4481 fig.~\ref{fig:ipc_posix_sem_shm_message_server_handler}. La funzione è molto
4482 semplice e richiama le funzioni di rimozione sia per il segmento di memoria
4483 condivisa che per il semaforo, garantendo così che possa essere riaperto
4484 ex-novo senza errori in un futuro riutilizzo del comando.
4486 \begin{figure}[!htbp]
4487 \footnotesize \centering
4488 \begin{minipage}[c]{\codesamplewidth}
4489 \includecodesample{listati/message_setter.c}
4492 \caption{Sezione principale del codice del programma
4493 \file{message\_setter.c}.}
4494 \label{fig:ipc_posix_sem_shm_message_setter}
4497 Il secondo programma di esempio è \file{message\_setter.c}, di cui si è
4498 riportato il corpo principale in
4499 fig.~\ref{fig:ipc_posix_sem_shm_message_setter},\footnote{al solito il codice
4500 completo è nel file dei sorgenti allegati.} dove si è tralasciata, non
4501 essendo significativa per quanto si sta trattando, la parte relativa alla
4502 gestione delle opzioni a riga di comando e degli argomenti, che sono identici
4503 a quelli usati da \file{message\_getter}, con l'unica aggiunta di un'opzione
4504 ``\texttt{-t}'' che consente di indicare un tempo di attesa (in secondi) in
4505 cui il programma si ferma tenendo bloccato il semaforo.
4507 Una volta completata la gestione delle opzioni e degli argomenti (ne deve
4508 essere presente uno solo, contenente la nuova stringa da usare come
4509 messaggio), il programma procede (\texttt{\small 10--14}) con l'acquisizione
4510 del segmento di memoria condivisa usando la funzione \func{FindShm} (trattata
4511 in sez.~\ref{sec:ipc_posix_shm}) che stavolta deve già esistere. Il passo
4512 successivo (\texttt{\small 16--19}) è quello di aprire il semaforo, e a
4513 differenza di \file{message\_getter}, in questo caso si richiede a
4514 \func{sem\_open} che questo esista, passando uno zero come secondo ed unico
4517 Una volta completate con successo le precedenti inizializzazioni, il passo
4518 seguente (\texttt{\small 21--24}) è quello di acquisire il semaforo, dopo di
4519 che sarà possibile eseguire la sostituzione del messaggio (\texttt{\small 25})
4520 senza incorrere in possibili \itindex{race~condition} \textit{race condition}
4521 con la stampa dello stesso da parte di \file{message\_getter}.
4523 Una volta effettuata la modifica viene stampato (\texttt{\small 26}) il tempo
4524 di attesa impostato con l'opzione ``\texttt{-t}'' dopo di che (\texttt{\small
4525 27}) viene eseguita la stessa, senza rilasciare il semaforo che resterà
4526 quindi bloccato (causando a questo punto una interruzione delle stampe
4527 eseguite da \file{message\_getter}). Terminato il tempo di attesa si rilascerà
4528 (\texttt{\small 29--32}) il semaforo per poi uscire.
4530 Per verificare il funzionamento dei programmi occorrerà lanciare per primo
4531 \file{message\_getter}\footnote{lanciare per primo \file{message\_setter} darà
4532 luogo ad un errore, non essendo stati creati il semaforo ed il segmento di
4533 memoria condivisa.} che inizierà a stampare una volta al secondo il
4534 contenuto del messaggio ed i suoi dati, con qualcosa del tipo:
4536 piccardi@hain:~/gapil/sources$ ./message_getter messaggio
4537 sem=1, Fri Dec 31 14:12:41 2010
4539 sem=1, Fri Dec 31 14:12:42 2010
4544 proseguendo indefinitamente fintanto che non si prema \texttt{C-c} per farlo
4545 uscire. Si noti come il valore del semaforo risulti sempre pari ad 1 (in
4546 quanto al momento esso sarà sempre libero).
4548 A questo punto si potrà lanciare \file{message\_setter} per cambiare il
4549 messaggio, nel nostro caso per rendere evidente il funzionamento del blocco
4550 richiederemo anche una attesa di 3 secondi, ed otterremo qualcosa del tipo:
4552 piccardi@hain:~/gapil/sources$ ./message_setter -t 3 ciao
4553 Sleeping for 3 seconds
4556 dove il programma si fermerà per 3 secondi prima di rilasciare il semaforo e
4559 L'effetto di questo programma si potrà però apprezzare meglio nell'uscita di
4560 \file{message\_getter}, che verrà interrotta per questo stesso tempo, prima di
4561 ricominciare con il nuovo testo:
4564 sem=1, Fri Dec 31 14:16:27 2010
4566 sem=1, Fri Dec 31 14:16:28 2010
4568 sem=0, Fri Dec 31 14:16:29 2010
4570 sem=1, Fri Dec 31 14:16:32 2010
4572 sem=1, Fri Dec 31 14:16:33 2010
4578 E si noterà come nel momento in cui si è lanciato \file{message\_setter} le
4579 stampe di \file{message\_getter} si bloccheranno, come corretto, dopo aver
4580 registrato un valore nullo per il semaforo. Il programma infatti resterà
4581 bloccato nella \func{sem\_wait} (quella di riga (\texttt{\small 37}) in
4582 fig.~\ref{fig:ipc_posix_sem_shm_message_server}) fino alla scadenza
4583 dell'attesa di \file{message\_setter} (con l'esecuzione della \func{sem\_post}
4584 della riga (\texttt{\small 29}) di
4585 fig.~\ref{fig:ipc_posix_sem_shm_message_setter}), e riprenderanno con il nuovo
4586 testo alla terminazione di quest'ultimo.
4589 % LocalWords: like fifo System POSIX RPC Calls Common Object Request Brocker
4590 % LocalWords: Architecture descriptor kernel unistd int filedes errno EMFILE
4591 % LocalWords: ENFILE EFAULT BUF sez fig fork Stevens siblings EOF read SIGPIPE
4592 % LocalWords: EPIPE shell CGI Gateway Interface HTML JPEG URL mime type gs dup
4593 % LocalWords: barcode PostScript race condition stream BarCodePage WriteMess
4594 % LocalWords: size PS switch wait popen pclose stdio const char command NULL
4595 % LocalWords: EINVAL cap fully buffered Ghostscript l'Encapsulated epstopsf of
4596 % LocalWords: PDF EPS lseek ESPIPE PPM Portable PixMap format pnmcrop PNG pnm
4597 % LocalWords: pnmmargin png BarCode inode filesystem l'inode mknod mkfifo RDWR
4598 % LocalWords: ENXIO deadlock client reinviate fortunes fortunefilename daemon
4599 % LocalWords: FortuneServer FortuneParse FortuneClient pid libgapil LD librt
4600 % LocalWords: PATH linker pathname ps tmp killall fortuned crash socket domain
4601 % LocalWords: socketpair BSD sys protocol sv EAFNOSUPPORT EPROTONOSUPPORT AF
4602 % LocalWords: EOPNOTSUPP SOCK SysV IPC Process Comunication ipc perm key exec
4603 % LocalWords: header ftok proj stat libc SunOS glibc XPG dell'inode number uid
4604 % LocalWords: cuid cgid gid tab MSG shift group umask seq MSGMNI SEMMNI SHMMNI
4605 % LocalWords: shmmni msgmni sem sysctl IPCMNI IPCTestId msgget EACCES EEXIST
4606 % LocalWords: CREAT EXCL EIDRM ENOENT ENOSPC ENOMEM novo proc MSGMAX msgmax ds
4607 % LocalWords: MSGMNB msgmnb linked list msqid msgid linux msg qnum lspid lrpid
4608 % LocalWords: rtime ctime qbytes first last cbytes msgctl semctl shmctl ioctl
4609 % LocalWords: cmd struct buf EPERM RMID msgsnd msgbuf msgp msgsz msgflg EAGAIN
4610 % LocalWords: NOWAIT EINTR mtype mtext long message sizeof LENGTH ts sleep BIG
4611 % LocalWords: msgrcv ssize msgtyp NOERROR EXCEPT ENOMSG multiplexing select ls
4612 % LocalWords: poll polling queue MQFortuneServer write init HandSIGTERM l'IPC
4613 % LocalWords: MQFortuneClient mqfortuned mutex risorse' inter semaphore semget
4614 % LocalWords: nsems SEMMNS SEMMSL semid otime semval sempid semncnt semzcnt nr
4615 % LocalWords: SEMVMX SEMOPM semop SEMMNU SEMUME SEMAEM semnum union semun arg
4616 % LocalWords: ERANGE SETALL SETVAL GETALL array GETNCNT GETPID GETVAL GETZCNT
4617 % LocalWords: sembuf sops unsigned nsops UNDO flg nsop num undo pending semadj
4618 % LocalWords: sleeper scheduler running next semundo MutexCreate semunion lock
4619 % LocalWords: MutexFind wrapper MutexRead MutexLock MutexUnlock unlock locking
4620 % LocalWords: MutexRemove shmget SHMALL SHMMAX SHMMIN shmid shm segsz atime FD
4621 % LocalWords: dtime lpid cpid nattac shmall shmmax SHMLBA SHMSEG EOVERFLOW brk
4622 % LocalWords: memory shmat shmdt void shmaddr shmflg SVID RND RDONLY rounded
4623 % LocalWords: SIGSEGV nattch exit SharedMem ShmCreate memset fill ShmFind home
4624 % LocalWords: ShmRemove DirMonitor DirProp chdir GaPiL shmptr ipcs NFS
4625 % LocalWords: ComputeValues ReadMonitor touch SIGTERM dirmonitor unlink fcntl
4626 % LocalWords: LockFile UnlockFile CreateMutex FindMutex LockMutex SETLKW GETLK
4627 % LocalWords: UnlockMutex RemoveMutex ReadMutex UNLCK WRLCK RDLCK mapping MAP
4628 % LocalWords: SHARED ANONYMOUS thread patch names strace system call userid Di
4629 % LocalWords: groupid Michal Wronski Krzysztof Benedyczak wrona posix mqueue
4630 % LocalWords: lmqueue gcc mount mqd name oflag attr maxmsg msgsize receive ptr
4631 % LocalWords: send WRONLY NONBLOCK close mqdes EBADF getattr setattr mqstat to
4632 % LocalWords: omqstat curmsgs flags timedsend len prio timespec abs EMSGSIZE
4633 % LocalWords: ETIMEDOUT timedreceive getaddr notify sigevent notification l'I
4634 % LocalWords: EBUSY sigev SIGNAL signo value sigval siginfo all'userid MESGQ
4635 % LocalWords: Konstantin Knizhnik futex tmpfs ramfs cache shared swap CONFIG
4636 % LocalWords: lrt blocks PAGECACHE TRUNC CLOEXEC mmap ftruncate munmap FindShm
4637 % LocalWords: CreateShm RemoveShm LIBRARY Library libmqueue FAILED has
4638 % LocalWords: ENAMETOOLONG qualchenome RESTART trywait XOPEN SOURCE timedwait
4639 % LocalWords: process getvalue sval execve pshared ENOSYS heap PAGE destroy it
4640 % LocalWords: xffffffff Arrays owner perms Queues used bytes messages device
4641 % LocalWords: Cannot find such Segments getter Signal MSGMAXSIZE been stable
4642 % LocalWords: for now it's break Berlin sources Let's an accidental feature
4643 % LocalWords: Larry Wall Escape the Hell William ipctestid Identifier segment
4644 % LocalWords: violation dell'I SIGINT setter Fri Dec Sleeping seconds
4647 %%% Local Variables:
4649 %%% TeX-master: "gapil"