Il meccanismo dei checkpoint è largamente utilizzato nel fault tolerance. Di solito è un’estensione delle chiamate di sistema operativo che viene invocata dall’utente. In caso di sistema real time, la questione più importante riguarda la temporizzazione e la memorizzazione dell’esatto istante temporale del checkpoint. Le normali applicazioni real time sono composte di vari processi real time che devono condividere i dati utilizzando le comunicazioni tra processi che vengono fornite dal sistema operativo; il SO deve tenere conto di tutto questo per garantire la consistenza del checkpoint (il che viene fatto tracciando tutte le comunicazioni dall’ultimo checkpoint in poi, il che da un idea della complessità di tutto questo).

Un ambiente real time aggiunge dei requisiti da soddisfare rispetto ad un sistema normale, e questi sono dati in massima parte dalle deadlines che vengono aggiunte ad ogni singolo task, la correttezza della computazione viene così ad essere sia il risultato logico, che il rispetto delle deadlines.

1. Architettura

Il protocollo che vogliamo analizzare, deve soddisfare queste caratteristiche [19]:

2. Analisi del protocollo

Un applicazione real time è strettamente correlata con l’ambiente di funzionamento, inoltre il sistema è di solito composto da task che vengono eseguiti in intervalli specifici (tasks periodici), questi task "leggono" dati dall’esterno mediante sensori e "scrivono" mediante gli attuatori esistono inoltre alcuni tasks aperiodici che vengono attivati quando accade una certa situazione.

Poiché il sistema è costruito secondo le estensioni dello standard Posix.1b, le "acquisizioni" e le "scritture" vengono fatte semplicemente invocando le chiamate di sistema READ e WRITE.

Inoltre è stato aggiunto del codice per risolvere alcune chiamate di sistema per il salvataggio dello stato di un processo (il tutto all’interno del sistema operativo stesso).

Normalmente il checkpoint andrebbe eseguito dopo ogni chiamata di sistema (EXEC, FORK, EXIT, ecc.), ma se questo avviene, allora la performance può diminuire notevolmente a causa della grande mole di dati (soprattutto di carattere temporale) che devono essere memorizzati.

Questa perdita viene ovviata in due modi:

La cancellazione dei checkpoint viene effettuata quando un processo finisce la propria esecuzione oppure quando cambia l’immagine di esecuzione.

Così, quando un processo invoca una EXIT di sistema, il processo stesso viene rimosso dalla tabella di sistema dei processi, le risorse a lui assegnate sono rese disponibili e le informazioni di recupero sono rimosse dall’unità stabile dove erano state memorizzate.

La EXEC invece cambia l’immagine di esecuzione, così il processo non viene rimosso dalla tabella di sistema, ma le informazioni di recupero sono comunque cancellate, perché il segmento di testo viene comunque cambiato e il segmento dati reinizializzato con nuovi dati, il segmento di stack contiene l’attivazione della subroutine con un nuovo entry point: gli indirizzi virtuali dopo l’esecuzione della EXEC, non hanno più alcuna relazione con quelli precedenti, cosicché è inutile mantenere i dati di recupero vecchi.

L’altra chiamata di sistema correlata alla creazione di processi è la FORK che crea un nuovo processo, il punto di recupero viene quindi salvato sia per il processo creatore, che per il nuovo.

Come detto, il sistema salverà un checkpoint quando vengono modificate alcune variabili nel sistema controllato.

In un sistema Unix, questo viene fatto eseguendo le chiamate write, aio_write, lio_listio.

Altre chiamate associate all’ I/O come open, creat, link, ecc. posso modificare il file system, e quando succede, viene fatto il checkpoint.

Le chiamate invece associate alle code dei messaggi non portano ad un checkpoint, ad eccezione delle mq_open e mq_unlink.

Lo stesso per le equivalenti chiamate relative ai semafori (sem_open, sem_unlink) e ai segmenti di memoria condivisi (shm_open, shm_unlink).

Inoltre le close, mq_close, sem_close, shm_close portano ad un checkpoint, perché liberano una risorsa che è usata per tenere traccia delle dipendenze (v. Paragrafo 4).

3. Informazioni contenute nel checkpoint

Il checkpoint deve contenere le informazioni tali che il sistema operativo possa ricostruire il corretto stato di esecuzione.

4. Tracciamento delle dipendenze

Una soluzione al problema della consistenza, è quello di fare un checkpoint globale, cosicché il sistema operativo non tiene conto delle dipendenze tra processi. In questo caso viene forzato un checkpoint a tutti i processi, anche se essi non hanno alcuna comunicazione tra loro. Questo approccio è semplice, ma introduce ritardi addizionali che posso portare alla perdita di deadlines.

Un altra soluzione per evitare di tenere traccia delle dipendenze è quello di stabilire un checkpoint ogni volta che un processo comunica con un altro. Anche in questo caso si introduce un alto overhead, a causa della grande quantità di risultati intermedi memorizzati.

Si vede quindi che è meglio tenere traccia delle comunicazioni tra processi appartenenti ad una stessa applicazione. Queste dipendenze sono generate quando un processo usa uno dei seguenti modi per comunicare dello standard Posix.1b: code di messaggi, semafori Posix.1b, oggetti di memoria condivisa, pipes, segnali. Le chiamate di sistema correlate hanno bisogno di alcune azioni per tener traccia delle dipendenze.

Il protocollo analizzato comparato al modello che prevede un checkpoint globale, porta i seguenti miglioramenti.