Università degli Studi di Parma Corso di laurea in Ingegneria Informatica A.A. 2004 - 2005 Dario Lodi Rizzini Sistemi in tempo reale 1 TODS: ANALISI ED.

Presentazione sul tema: "Università degli Studi di Parma Corso di laurea in Ingegneria Informatica A.A. 2004 - 2005 Dario Lodi Rizzini Sistemi in tempo reale 1 TODS: ANALISI ED."— Transcript della presentazione:

1 Università degli Studi di Parma Corso di laurea in Ingegneria Informatica A.A. 2004 - 2005 Dario Lodi Rizzini Sistemi in tempo reale 1 TODS: ANALISI ED ESTENSIONE DI UN FRAMEWORK ORIENTATO AGLI OGGETTI PER APPLICAZIONI REAL-TIME Docente: Prof. Stefano Caselli

2 Dario Lodi Rizzini 2 Sommario Introduzione a TODS Estensioni a TODS: implementazione di Rate Monotonic Valutazione delle prestazioni Conclusioni

3 Dario Lodi Rizzini 3 Introduzione TODS (Timed Object for Distributed Systems) è un framework orientato agli oggetti per le applicazioni real time. Consente la creazione di oggetti in tempo reale demandando le funzionalità di scheduling e della verifica dei vincoli temporali al framework. Semplifica lintroduzione di nuovi algoritmi di scheduling.

4 Dario Lodi Rizzini 4 Struttura di TODS TODS Layer DisC++ Thread Layer POSIX Thread Glibc Linux TODS Framework OS Linux Thread TODS è organizzato in due strati: TODS layer: implementa le funzionalità real time in senso stretto Thread layer: libreria ad oggetti per la programmazione concorrente basata su DisC++ Il Thread layer di TODS dovrebbe impiegare soltanto POSIX Thread. In verità sfrutta direttamente funzionalità della libreria Linux Thread che gradualmente verrà sostituita dalla NPTL.

5 Dario Lodi Rizzini 5 Esempio di applicazione in tempo reale usando gli RTObject di TODS #include using namespace tods; class myRTobj : public RTObject { protected: // the body of the RT method void body( /* void */){... // the code that performs task } public: RTMethod method; // ctor myRTobj( shared_ptr rm ) : RTObject( rm ), method( this, &( myRTobj::body ) ) {} }; Livello utente (1) RTMethod usa i template Riferimento a body()

6 Dario Lodi Rizzini 6 … try { const string algo = "Edf_OnOff_Conf"; vector par( 1 ); par[0] = string( "1.0" ); auto_ptr tmprm = RTFactory::create( algo, par ); shared_ptr rm( tmprm ); myRTobj rtObj( rm );... const TimeInterval t( 0, 100000000 ); // one-shot request rtObj.method( t ); // periodic request: PeriodicReqHandle h1 = rtObj.method( t, callType::periodic ); … h1.terminate(); } catch ( /* evcezione*/ ) { … } Livello utente (2) Algoritmo e parametri Creazione dellexecutive dealine Rilascio di task one shot e periodici (method è un oggetto funzione) Terminazione task periodici

7 Dario Lodi Rizzini 7 Livello utente (3) Gli oggetti in tempo reale sono istanze di classi che ereditano dalla classe RTObject e hanno un RTMethod, ossia un oggetto funzione che gestisce il rilascio, come membro pubblico. Gli algoritmi di scheduling supportati da TODS sono di tipo priority driven (solo EDF è stato implementato). La classe RTFactory ha in compito di caricare lalgoritmo da uno shared object e di fornire allExecutive i riferimenti di Accepter e Scheduler.

8 Dario Lodi Rizzini 8 Livello utente (4) LExecutive eredita linterfaccia RequestManager. Il rilascio di un task può essere di tipo periodic o one shot. Nel caso di task one shot si possono specificare deadline assolute con la classe TimeInstant o relative con la classe TimeInterval. Lutente non si occupa di parametri come il worst case execution time (WCET) o del test di acceptance: in caso di fallimento viene infatti lanciata una eccezione not_feasible_task.

9 Dario Lodi Rizzini 9 Implementazione di RM (1) Lo sviluppo di TODS è orientato alladozione di Earliest Deadline First (EDF) come algoritmo di scheduling. Limplementazione di Rate Monotonic (RM) evidenzia la semplicità con cui è possibile introdurre nuovi algoritmi di scheduling. Le modiche richieste sono state relativamente poche –estensione di alcune interfaccce (classi Job e derivate) –alcune classi sono state reimplementate per supportare policies (es: JobQueue che gestisce la coda dei job)

10 Dario Lodi Rizzini 10 Implementazione di RM (2) Sono state fatte alcune scelte di progetto che limitano luso di RM –Si è deciso di gestire solo task periodici; sono possibili estensioni per gestire anche task one shot come il polling server o il deferrable server. –Non è stato consentito il partizionamento dellutilizazzione della CPU supportato dalla implementazione di EDF. il bound di Liu-Layland restringe molto lammissibilità di un nuovo task

11 Dario Lodi Rizzini 11 Class Diagram > Scheduler > Accepter > ReqObserver RMAccepter eredita RMScheduler eredita > Servant > JobQueue > Job notify > RequestManager Executive eredita RTObject usa > Request

12 Dario Lodi Rizzini 12 Le classi di RM (1) Rm_OnOff_Conf : classe di configurazione dellalgoritmo RM con il compito di fornire al RequestManager laccepter e lo scheduler di RM –implementa linterfaccia RTConfiguration RMAccepter : implementa le interfacce Accepter e ReqObserver –implementa una variazione del normale pattern Observer per consentire allo Scheduler di notificare allAccepter il rilascio o la terminazione di task –verifica lammissibilità dei task rilasciati metodo isFeasible() –isFeasible() per i task one shot restituisce sempre il valore false

13 Dario Lodi Rizzini 13 Le classi di RM (2) RMScheduler : implementa linterfaccia Scheduler –presenta differenze rispetto a EDFSceduler che adotta soluzioni per gestire il partizionamento dellutilizzazione della CPU –accoglie le richieste (precedentemente validate) attraverso il metodo addReq() –usa istanze di JobQueue e Servant, le classi che di fatto realizzano lalgoritmo RM, specificando la policy RMCompareJob che ordina i job rispetto al periodo JobQueue : eredita dalla classe STL list –è una classe template per consentire di definire la politica di ordinamento della coda –riordina anche le priorità del thread pool sulla base dellordinamento dei Job

14 Dario Lodi Rizzini 14 Le classi RM (3) Servant : è una classe di collegamento con il Thread Layer di TODS –possiede un thread a priorità massima che viene risvegliato quando un nuovo job entra nella coda oppure è scaduta una deadline; per il tempo restante rimane in attesa su di una condition variable –possiede un thread pool che vengono assgnati ai job della coda –è una classe template per poter contenere un riferimento a JobQueue che è a sua volta template

15 Dario Lodi Rizzini 15 Valutazione delle prestazioni Uno dei principali obiettivi del progetto è valutare le prestazioni del framework ed in particolare loverhead introdotto da TODS I test effettuati prevedono tre tipi di stime: –valutazione delloverhead complessivo al momento del rilascio di un task –valutazione dei contributi specifici di Executive e Accepter –valutazione della latenza I test principalmente hanno interessato il consolidato algortimo EDF

16 Dario Lodi Rizzini 16 Overhead complessivo Test: un task τ 0 rilascia altri task con deadline successiva per ritardare la loro esecuzione. Risultati: –nei primi 20 rilasci il valore delloverhead assume valori di 2-3 ms, particolarmente elevati rispetto alle dimensioni dei task –le successive misure si assestano intorno ai 200-300 μs … τ0τ0 overhead

17 Dario Lodi Rizzini 17 Overhead di Accepter e Scheduler Nel codice dellexecutive sono state inseriti dei timer per rilevare loverhead di Accepter e Scheduler. I valori ottenuti sono significativamente molto ridotti, dellordine di delle decine di microsecondi EDFRM Accepter24.1 μs307.1 μs * Scheduler13.6 μs27.8 μs *

18 Dario Lodi Rizzini 18 Misure di latenza Output del test di latenza latency test n. 0 : measure 3.1585 latency test n. 1 : measure 0.222632 latency test n. 2 : measure 0.172539 latency test n. 3 : measure 0.178615 latency test n. 4 : measure 0.171721 latency test n. 5 : measure 0.179257 latency test n. 6 : measure 0.179567 latency test n. 7 : measure 0.17923 latency test n. 8 : measure 0.172881 latency test n. 9 : measure 0.179821 … Il primo valore è normalmente di 3 ms, gli altri variano fra 170-180 μs. Ck start() Ck.stop() myRTObj.method()

19 Dario Lodi Rizzini 19 Osservazioni I test mettono in evidenza la presenza di valori di overhead abbastanza elevati in relazione alle primi rilasci di job. Lipotesi più ragionevole è che loverhead iniziale dipenda dallinizalizzazione del thread pool –il thread pool ha dimensione di default di 20 thread –nel test di latenza viene creato un unico thread ed il valore elevato si presenta solo in un caso

20 Dario Lodi Rizzini 20 Conclusioni È stata implementata una prima versione dellalgoritmo RM. –Sviluppi futuri possono prevedere lintroduzione di un server periodico per la gestione di task one shot Lanalisi delle prestazioni ha messo in evidenza ulteriori limiti del Thread layer di TODS –È incompatibile con la Native POSIX Threading Libary (NPTL) –Bug nelle implementazioni di oggetti thread sono la probabile causa degli overhead segnalati

21 Dario Lodi Rizzini 21 Bibliografia Pallastrelli D., Studio e realizzazione di un framework orientato agli oggetti per applicazioni Real-Time, tesi di laurea. Gamma, Helm et al., Design Pattern, Addison-Wesley Alexandrescu A., Modern C++ Design Per futuri sviluppi di RM: Strosnider, Lehoczky, Sha, The Deferrable Server Algorithm for Enhanced Aperiodic Responsiveness in Hard Real-Time Envirinments, IEEE Trans. on Computers, Jan. 1995