Torna alla pagina di Sistemi Operativi
:: Appunti caotici ::
Lezione 5 Comunicazione con Mailbox
Con questa tecnica il processo mittente genera il messaggio senza sapere chi sarà il ricevente; si tratta quindi di comunicazione indiretta.
Il messaggio viene depositato in una mailbox (detta anche porta), una struttura dati presente nel sistema operativo, caratterizzata da un nome cui si farà riferimento per accedere ai messaggi da lei contenuta. Il processo ricevente prelevererà il messaggio accedendo ad essa.
Il messaggio può contenere diverse informazioni, come:
I messaggi possono avere dimesione Fissa o ''Variabile.
Va anzitutto ricordato che non stiamo assegnando i messaggi ad una coppia di processi, ma li stiamo inserendo in una struttura accessibile (teoricamente) da tutti. Certo, esisteranno comunque delle politiche di accesso: solo e tutti quei processi che avranno ottenuto dal sistema operativo i diritti di lettura potranno leggere i messaggi.
La mailbox può avere capacità:
La mailbox prima di essere utilizzata deve essere creata, e se in un secondo momento non serve più la si può cancellare. Vengono quindi messe a disposizione delle funzioni che permettono tali operazioni:
Vengono fornite anche delle funzioni apposite per l'invio e la ricezioni di messaggi.
Invio: send(M, messaggio)
Questa funzione deposita i messaggi nella mailbox e risulta bloccante in base alla capacità della mailbox:
Ricezione: ''receive(M, messaggio).
Tale funzione consente di ricevere il messaggio dalla mailbox. Risulta bloccante se non c'è almeno un messaggio da ricevere.
E' solo in fase di ricezione che si completa l'identificazione delle identità da parte dei processi.
Ci sono anche delle funzioni di invio e di ricezione condizionale.
Invio Condizionale: cond_send(M, messaggio): error_status
Questa funzione deposita il messaggio nella mailbox solo se trova spazio al suo interno. Tale funzione quindi non è bloccante, se non trova spazio non costringe il processo a rimanere in attesa che si liberi spazio sufficiente nella mailbox per poter depositare il messaggio. Viene quindi introdotto una condizione, che mi ritorna errore nel caso il processo non riesca a depositare il messaggio.
Ricezione Condizionale: cond_receive(M, messaggio): error_status
Tale funzione riceve un messaggio solo se ce ne è almeno uno nella mailbox. In caso contrario ritorna la condizione di errore, non bloccando di conseguenza il processo ricevente.
Le politiche di sincronizzazione sono stabilite sempre in base alla capacità della mailbox:
Una caratteristica di questa tecnica è che non ho un'indentificazione dei processi che comunicano, quindi ho una comunicazione indiretta. La sincronizzazione è gestita in maniera automatica da parte del sistema operativo.
Ci sono varie tecniche di ordinamento dei messaggi all'interno della mailbox, tali tecniche si riferiscono anche ai processi che sono in attesa. Tali tecniche sono:
Dato che la mailbox non è proprietà del processo ma bensì del sistema operativo (ricordiamo che è nel suo spazio di indirizzamento!), posso stabilire delle proprietà su di essa. Posso attribuire la mailbox ad un processo proprietario, l'unico a poter ricevere messaggi, mentre tutti gli altri processi possono solo inviarli. Se il processo proprietario scompare, la mailbox scompare con esso.
Ci possono essere comunicazioni con molti possibili mittenti o riceventi. Ogni comunicazione coinvolgerà sempre minimo due processi, ma la struttura della mailbox consente che ci siano più processi mittenti e più processi riceventi che possono partecipare nella comunicazione. La struttura della mailbox non mi consente però di sapere a priori chi siano tali processi.
Notare anche come la struttura dati mailbox disgiunga naturalmente il processo mittente dal ricevente.
Una differenza sostanziale nella comunicazione molti a uno rispetto a quella precedente è che ho un solo processo di servizio (S, nello schema). Nel caso un cui il processo di servizio schiatti, il sistema operativo può farlo ripartire eseguendone una copia (a cui cambierà l'id). I richiedenti non si accorgono di nulla, tranne quello che S stava servendo nel momento in cui è esploso (il nuovo servizio non sa che c'era una richiesta pendente).
Una struttura uno a molti mi consente di avere più processi di servizio ed un unico processo richiedente, che verrà sempre servito per quanto possa rompere con le sue richieste.
I processi che si occuperanno del servizio saranno delle copie dello stesso processo, pronte a servire ognuna una richiesta di entrata spacifica. Ciò è reso possibile dal fatto che si da per assunto che tali processi serventi compino operazioni di I/O, così che abbiano tempi morti nello sfruttamento del processore, durante i quali possa avvenire la turnazione.
Questa tecnica è auspicabile quando ho un singolo processo che ha più richieste e che vuole vengano soddisfatte contemporaneamente.
In questa tecnica ho più processi di servizio e più processi che effettuano richieste. Nel metodo uno a molti potevo soddisfare in parallelo più richieste effetuate da un singolo processo, potevo però avere momenti in cui alcuni processi di servizio rimanevano in stato di attesa. Con questo metodo ottimizzo quei tempi morti soddisfacendo richieste effettuate da altri processi.