7) Cosa si intende per primitive dirette/indirette? E per primitive simmetriche/asimmetriche?
Indirette/dirette: l’uso o meno di entità intermedie cui inviare i messaggi (link, porte o qualsiasi altra entità diversa dal processo partner)
Simmetriche/asimmetriche: la presenza di uno (simmetriche) o più (asimmetriche) canali bidirezionali attraverso cui i processi si scambiano messaggi
Primitive dirette:
Caratteristiche e problemi del modo diretto:
il modo diretto lascia libertà ai processi.
difficile leggibilità e scarsa modularità.
capacità espressiva limitata, non è utilizzabile per il modello client/server.
possibilità di deadlock in caso di operazioni sincrone e limiti di memoria: se P manda a Q e Q manda a P, se i due nodi non hanno più memoria, sono obbligati a sospendere ogni attività. Naturalmente il deadlock può derivare non solo da un ciclo tra due vicini diretti, ma anche da una catena di vicini.
Primitive indirette:
Link: canale di comunicazione unidirezionale per un processo. E' un meccanismo asimmetrico: il cliente conosce il servitore ma non viceversa.
può essere anche definito come l’astrazione di una connessione tra due processi
un link è visto come un oggetto protetto gestito da un name server centralizzato (kernel), che viene utilizzato mediante primitive del tipo:
send(link, messaggio) receive(link, messaggio) Ogni processo può generare un link a sè stesso e può passarne la conoscenza ad altri. Il kernel mantiene la tabella dei link per ogni processo.
nel modello client/server completo:
- il cliente deve avere un link per il servitore
- il cliente invia un link a sè stesso nel messaggio al servitore, che lo usa per la risposta
vantaggi:
facilità alla migrazione (dinamicità).
possibilità di trasmissione anche di aree di dimensioni elevate con ottimizzazioni dell’area usata.
svantaggi
overhead di gestione.
link dangling (viene inviato un link ma il destinatario non può rispondere, allora il link viene continuamente spedito).
Bilink: canale di comunicazione bidirezionale, con bufferizzazione o meno e con blocco o meno tra due processi, con azioni di invio/ricezioni consentite ad entrambi i processi.
Buffer: sono gestiti a livello utente.
Non Blocking: un processo può avere più richieste pendenti (send o receive), realizzando così un modello cliente/servitore multiplo
Un bilink può essere anche trasferito da un processo all’altro, cambiandone il processo agganciato, per esempio tramite una primitiva: send(link, buffer, link da agganciare)
svantaggio: overhead
Porte: mailbox è un nome globale per la comunicazione indiretta tra qualunque processo.
Ma implica overhead nell’implementazione:
Una porta (oggetto protetto di kernel) consente operazioni di invio, ricezione, proprietà: un solo processo può fare le operazioni di ricezione in un certo istante, in base ai diritti.
le porte possono essere bidirezionali.
il processo owner può distribuire i diritti, passare la porta e cedere la ownership. L’owner è legato alla porta; se termina, termina anche la porta, provocando eccezioni negli altri processi che trasmettono o ricevono.
Implementazione: per il processo ricevente la porta è associata ad una coda FIFO.
caso particolare: ACCENT.
Ogni comunicazione (sia per i processi di utente, di sistema che di Kernel vero e proprio) avviene attraverso le porte. Il grado di bufferizzazione di ogni porta è limitato e definito alla creazione. In caso di buffer pieno:
- il processo sospeso fino a che non si trova spazio (tipico in comunicazione per processi utente con un server)
- il processo riceve una eccezione (dopo un time-out) (tipico di comunicazione non cliente/servitore)
- il processo non riceve indicazioni, ma il messaggio è accodato dal kernel fino a quando l'invio non è possibile (tipico di comunicazione per processi servitori)
Passaggio dei parametri
il passaggio dei parametri avviene per valore o per riferimento. In quest’ultimo caso c’è necessità di spazio comune o di trasmissione (con interazione con la gestione della memoria)
la dimensione dei messaggi può essere fissa (facile supporto, ma programmazione più complessa) o variabile (supporto più complesso, ma programmazione più facile)
Eccezzioni:
esiste la necessità di fornire una buona gestione delle eccezioni in caso di messaggio pendente:
Terminazione del receiver\sender : il messaggio non può essere ricevuto. Senza buffering si ha il blocco del sender\receiver. Rimedio: time-out o terminare a sua volta
terminazione attuata dal sistema operativo
Linee guida per altre azioni di eccezione:
- application dependent
- ignorare eccezioni non critiche
- ritentare un’operazione
- nel caso che un’operazione possa essere stata fatta parzialmente, approccio alle transazioni