Pubblichiamo un guest post di Emanuele Rampichini
Troppo spesso nel mondo dell’informatica c’è confusione riguardo al concetto di “tempo reale”. Siamo abituati ad utilizzare sistemi operativi che rispondono in maniera immediata ai nostri comandi, siano essi impartiti da una tastiera da un mouse o da altre periferiche. Questa abitudine porta a pensare che un sistema possa essere considerato in “tempo reale” semplicemente in relazione a quanto più rapidamente le risposte ai nostri stimoli vengano interpretate, processate e le risposte restituite.
Nei sistemi operativi interattivi tradizionali il tempo medio di risposta di un processo è il parametro su cui si gioca la partita. Nei sistemi realtime i concetti centrali sono invece quelli della garanzia e della prevedibilità. Non ci importa che un certo numero di processi vengano eseguiti complessivamente velocemente ma vogliamo delle garanzie temporali sui singoli processi (tecnicamente parliamo di deadline).
Per rendere chiaro questo concetto possiamo fare un esempio molto semplice:
Supponiamo che alle 8:00 di mattina vi vengano assegnati i seguenti compiti:
– Pagare la bolletta
– Comprare il Pane
Supponiamo che per qualche motivo vi troviate di fronte a queste due possibilità:
– Passare immediatamente alle poste riuscendo a concludere il pagamento per le 10:00, poi al supermercato completando i compiti assegnati alle 11:50
– Passare prima al supermercato riuscendo a comprare il pane per le 9:30 e solo in seguito alle poste completando i compiti assegnati alle 11:00
Ovviamente nessuna persona (sana di mente) conoscendo le due alternative sceglierebbe la prima possibilità rispetto alla seconda. Ma se cambiassimo le carte in tavola e inserissimo ulteriori vincoli nel problema?
– La bolletta va pagata entro le 10:30 pena il pagamento di una sovratassa
– Il pane va acquistato entro le 12:00 pena il salto del secondo pasto più importante della giornata :D
Ecco che quella che fino a un secondo fa ci sembrava una scelta illogica adesso diventa non solo comprensibile ma addirittura la scelta preferibile. Arrivare alle 11:50 e non alle 11:00 a casa non compromette in alcun modo il pranzo e non implicherà l’esborso di una sovratassa.
Ecco come il concetto di tempo reale esula da quello di velocità assoluta di risposta ed entra nel contesto dell’ambiente in cui si opera (nell’esempio l’ambiente sono i vincoli inseriti in un secondo momento).
Il passo successivo è quello di individuare le conseguenze del mancato rispetto dei vincoli temporali. Solitamente i processi che si presentano in un sistema in tempo reale vengono suddivisi in due categorie:
PROCESSI HARD REALTIME:
Processi in cui il mancato rispetto dei vincoli temporali (sforamento delle deadline) comporta un effetto catastrofico sul sistema.
In generale tra gli esempi di processi hard realtime possiamo annoverare tutti quelli che hanno a che fare strettamente con l’ambiente reale circostante(sensoristica, sistemi di attuazione, controllo di dispositivi automatici)
PROCESSI SOFT REALTIME:
Processi in cui lo sforamento dei vincoli temporali comporta un degrado delle prestazioni, ma non viene compromesso il comportamento complessivo del sistema. Pensiamo per esempio al motore di rendering di un videgame, che in alcune situazioni potrebbe rallentare per via di carichi più alti del previsto con l’effetto di vedere il flusso di immagini scattare.
Nei sistemi complessi molto spesso le due categorie di processi convivono e vanno gestite contemporaneamente.
Per dare una idea generale di quello che deve essere un sistema operativo in tempo reale possiamo elencarne le caratteristiche attese:
– Gestione esplicita dei vincoli temporali:
La correttezza dei risultati è valutata non solo riguardo ai valori ma anche rispetto al parametro tempo. Un risultato che arriva in ritardo in alcuni ambiti può significare la vita o la morte di una persona.
– Prevedibilità
Il sistema deve essere sempre in grado di prevedere le conseguenze delle decisioni che si troverà a prendere.
– Tolleranza ai sovraccarichi
Bisogna prevedere l’eventualità di sovraccarichi e prendere decisioni a riguardo senza compromettere il corretto funzionamento del sistema.
– Monitorabilità
Deve conoscere se qualcosa sta andando storto al suo interno e essere in grado di segnalarlo.
– Flessibilità
Deve essere modulare per adattarsi il più possibile alle esigenze delle applicazioni che ci gireranno sopra.
Svincolandosi dall’esempio particolarmente ridicolo descritto sopra e dalla panoramica generale, problemi che vanno affrontati nell’ottica del “tempo reale” sono ovviamente ampiamente presenti nella società moderna. Basti pensare ai sistemi ABS delle automobili, o ai sistemi di controllo e stabilizzazione degli aeroplani.
Nell’ articolo che seguirà analizzeremo come la scena open source proponga una offerta estremamente variegata di sistemi operativi adatti alla progettazione di applicativi in tempo reale.
Riferimenti:
Appunti delle lezioni sistemi operativi in tempo reale – Prof Aldo Franco Dragoni
Sistemi in Tempo Reale – Giorgio C. Buttazzo
Wikipedia en
