Stavolta vorrei ragionare su di un argomento un pò più tecnico, una problematica spesso affrontata da chi si occupa di firmware o software RT in genere: i timer virtuali.
Il problema è questo: si dispone di una singola fonte d'interrupt periodico (ad esempio un tick ogni decimo di secondo) e tramite questa si vuole implementare un sistema di timer virtuali.
Vediamo le API di questo ipotetico sistema di timers:
// // Questa funzione viene invocata ogni decimo di secondo sotto interrupt. void Tick(void) { // Qua dentro gestisco la temporizzazione dei timer. }
// // Funzione per attivare un timer virtuale. // Imposta un timer con tempo "Time", allo scadere del tempo // verrà invocata la funzione CallBack() e il timer si disattiva. void SetTimer(DWORD Time, void (*CallBack)(void)) { // Qua dentro creo un nuovo timer virtuale. }
Il problema è che si vorrebbe ottenere di poter avere un numero ampio di timer virtuali "running" e si dovrebbe operare su N timer virtuali senza perdita d'efficienza mano a mano che si attivano molti timer.
Vediamo chi riesce a concepire la migliore struttura dati per gestire efficientemente una situazione di questo tipo Non è indispensabile scrivere tanto codice, basta spiegare anche a parole.
Vuoi sapere a che serve un meccanismo di timer virtuali ? Beh, immagina di dover schedulare eventi in una tua applicazione in tempi diversi, il numero/ordine degli eventi non lo puoi limitare a priori. Ad esempio un video game, devi gestire una serie di animazioni e/o eventi in tempi precisi: - 100msec omino uno comincia a saltare. - 500msec omino due spara un proiettile - 800msec omino uno riatterra - ogni 200 msec aggiornamento stato degli oggetti e della rete (è un gioco multiplayer ) ecc ecc
Il meccanismo di timer virtuali ti permette di schedulare un numero illimitato di eventi ed avere timing precisi per le animazioni. I tempi come te li calcoli ? con i loop ? chiaro che no, serve un meccanismo preciso, asincrono e indipendente dal clock del sistema. Ho un pò banalizzato ma spero sia chiara l'importanza di un meccanismo di questo tipo per chi progetta software destinati a funzionare in real time.
Dai che siamo ancora sul facile la prossima volta cominciamo a parlare di codice multithreaded e sicronizzazione fra processi.
Se sei programmatore jedi oscuro: lo sai già Se programmi: ti serve. Se t'interessi vagamente di programmazione: impari qualcosa. Se non t'interessi di programmazione: che ci fai qua ?
Comunque questa cosa non ha avuto seguito pare, la chiudiamo qua.
