In questo capitolo analizzeremo il FT nel software, nei sistemi distribuiti attraverso l’approccio di gruppo di conversazione [7].

Esistono in letteratura due paradigmi di programmazione per i gruppi: conversazione e comunicazione.

Noi assumiamo che il sistema in questione consista di una serie di processi che possono essere eseguiti in modo concorrente e possono comunicare nel frattempo. Esistono tre categorie di questi processi: indipendenti, competitivi e cooperazionali.

Una occorrenza di tipo competitivo esiste quando due o più processi che sono separati, usano le stesse risorse di sistema, le quali non conoscono di solito nulla del processo che le utilizza. Esempi sono l’uso delle risorse di sistema operativo, server di dati, DBMS, e oggetti.

Una occorrenza di tipo cooperativo esiste quando più processi cooperano tra di loro per un lavoro comune, e loro sono a conoscenza di questo fatto. Essi possono perfino comunicare attraverso risorse condivise, ma il punto principale è che essi sono stati creati assieme per uno scopo comune e devono aiutarsi a vicenda. Essi sincronizzano le loro esecuzioni e ognuno di essi può aspettare l’informazione computata da altri. Esempi sono la computazione parallela, i sistemi di controllo.

La scelta se costruire un sistema cooperante o concorrente dipende dal designer e da come egli prevede di utilizzare il sistema.

Poiché ogni operazione di conversazione deve essere atomica, il problema dell’isolamento ha un ruolo primario. Infatti il designer di un processo non conosce niente circa gli altri processi che competono per le risorse. Questo tipo di competizione è nascosta e non deve influenzare il design di un processo. Deve essere garantito che se più transazioni sono eseguite simultaneamente, esse non si disturbino a vicenda e che il recupero eventuale di una di esse, non danneggi le altre. (per un dettaglio sulle transazioni v. Cap. FT nelle Basi di Dati)

2. Conversazioni

Il concetto di conversazione è stato introdotto da Randell nel 1975.

I processi entrano nella conversazione in modo asincrono; un punto di recovery è stabilito per ognuno di essi. Essi sono liberi di scambiarsi informazioni entro la conversazione, ma non possono comunicare con alcun processo esterno alla comunicazione. Quando tutti i processi che partecipano alla conversazione hanno finito, si passa ad un test di accettazione. Se è soddisfatto, i processi lasciano il gruppo di conversazione, altrimenti essi recuperano lo stato che avevano al punto di recovery. Se qualche processo cade durante la conversazione, tutti i processi fanno un roll back allo stato di recovery. Una conversazione può essere di tipo nested, quando un sottogruppo di processi da vita ad una conversazione tra loro.

Lo schema di conversazione offre un chiaro approccio all’implementazione di sistemi concorrenti FT, strutturando il sistema in unità di conversazione ed applicando il FT a queste unità, in modo da facilitare il design di sistemi complessi (la struttura del sistema è un gerarchia di azioni con chiara FT semantica).

Nei sistemi distribuiti, il FT è messo in opera, a volte, attraverso i gruppi di comunicazione.

Un gruppo di comunicazione consiste di uno o più processi, chiamati membri, che cooperano per eseguire alcuni servizi o per portare avanti l’esecuzione di un’applicazione. Un processo può partecipare a più gruppi. Messaggi multicast possono essere mandati a tutti i membri del gruppo. Un processo può creare, cancellare, associarsi o lasciare un gruppo. Si suppone che i messaggi arrivino sempre e comunque a destinazione.

Un gruppo di comunicazione è altamente tollerante ai guasti hardware, ma poco per quanto riguarda i guasti software, soprattutto per la sua non atomicità dei messaggi.

Un altro approccio è quello dei protocolli che arrivano ad un accordo tra le varie esecuzioni parallele della stessa applicazione.

Anche questo approccio non è vincente, perché lo scopo dei processi cooperanti è quello di lavorare in accordo, non di cercare un accordo sul risultato.

Le conversazioni, invece, hanno una chiara semantica FT (ricerca di errore, confinamento del danno, recupero dall’errore), ad esempio tutti i partecipanti prendono parte al recovery, se uno di essi fallisce. Inoltre le conversazioni sono "invisibili" al mondo esterno ed ai processi circostanti.

3. In pratica

Possiamo far coesistere gruppi di comunicazione e conversazione in un sistema distribuito, ad un diverso livello: l’uno hardware, l’altro software.

Supponiamo che esista un livello sottostante con gruppi di comunicazione, che si occupano di tutta la parte di FT hardware e di consegna sicura dei messaggi.

Ad un livello superiore, instauriamo dei gruppi di conversazione, con le seguenti proprietà:

Lo scambio di informazione è permesso solo all’interno di un gruppo

Sono possibili conversazioni innestate una nell’altra

Gli errori sono rilevabili sia in fase di test di accettazione, che durante la conversazione stessa

Se non esistono errori, tutti i processi lasciano la conversazione allo stesso tempo

Ogni processo conosce il risultato del test di accettazione

Tutti i partecipanti prendono parte all’esecuzione del recovery, in caso di errore

L’esistenza allo stesso tempo di gruppi di conversazione e comunicazione è garantita dalle seguenti regole:

Un conversazione è un’entità atomica, non può ricevere o inviare informazioni al mondo esterno

Nessuno può mandare messaggi multicast ai membri di una conversazione

Quando una conversazione è terminata, i partecipanti possono rimanere nello stesso gruppo