TODS: ANALISI ED ESTENSIONE DI UN FRAMEWORK ORIENTATO AGLI OGGETTI PER APPLICAZIONI REAL-TIME

1
TODS ANALISI ED ESTENSIONE DI UN FRAMEWORK
ORIENTATO AGLI OGGETTI PER APPLICAZIONI REAL-TIME

• Docente
• Prof. Stefano Caselli

2
Sommario

• Introduzione a TODS
• Estensioni a TODS implementazione di Rate
  Monotonic
• Valutazione delle prestazioni
• Conclusioni

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
Struttura di TODS

• 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
Livello utente (1)

• Esempio di applicazione in tempo reale usando gli
  RTObject di TODS
• include lttods.Hgt
• using namespace tods
• class myRTobj public RTObject
• protected
• // the body of the RT method
• void body( / void /)
• ... // the code that performs task
• public
• RTMethodlt myRTobj, void, void gt method
• // ctor
• myRTobj( shared_ptrlt RequestManager gt rm )
  
• RTObject( rm ),
• method( this, ( myRTobjbody ) )

6
Livello utente (2)

• try
• const string algo "Edf_OnOff_Conf"
• vectorlt string gt par( 1 )
• par0 string( "1.0" )
• auto_ptrlt RequestManager gt tmprm
• RTFactorycreate( algo, par )
• shared_ptrlt RequestManager gt rm( tmprm )
• myRTobj rtObj( rm )
• ...
• const TimeInterval t( 0, 100000000 )
• // one-shot request
• rtObj.method( t )
• // periodic request
• PeriodicReqHandlelt void gt h1

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
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
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
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
Class Diagram
notify
usa
usa
ltltinterfacegtgt RequestManager
ltltinterfacegtgt Request
RTObject
eredita
Executive
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
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 ltJobgt
• è 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
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
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
Overhead complessivo

• Test un task t0 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

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

EDF RM
Accepter 24.1 µs 307.1 µs
Scheduler 13.6 µs 27.8 µs
18
Misure di latenza
myRTObj.method()

• Output del test di latenza
• latency test n. 0 measure 3.1585latency
  test n. 1 measure 0.222632latency test n. 2
  measure 0.172539latency test n. 3 measure
  0.178615latency test n. 4 measure
  0.171721latency test n. 5 measure
  0.179257latency test n. 6 measure
  0.179567latency test n. 7 measure
  0.17923latency test n. 8 measure
  0.172881latency test n. 9 measure 0.179821
• Il primo valore è normalmente di 3 ms, gli altri
  variano fra 170-180 µs.

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
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
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