Questo articolo è la Parte 2 della serie "CORBA per sistemi embedded" all'interno della Rubrica Firmware Reload di Elettronica Open Source.
RT-CORBA
In questo ambito, un utilizzatore ha diverse possibilità per rispondere alle esigenze real-time. In effetti, con RTCORBA è possibile, ad esempio, creare e configurare insiemi di thread (ThreadPool) specificando la loro priorità. Un ThreadPool è costituito da thread statici, assegnati al ThreadPool all’atto della sua creazione, e dinamici, che possono essere creati quando i thread statici risultano tutti impegnati. In questo ambito, è possibile avere differenti linee caratterizzate da diverse priorità e una coda per contenere le richieste in attesa. A questo proposito, il Listato 1 mostra l’interfaccia IDL del ThreadPool nella versione RT-CORBA 1.2.
//IDL
module RTCORBA {
// Threadpool types
typedef unsigned long ThreadpoolId;
struct ThreadpoolLane {
Priority lane_priority;
unsigned long static_threads;
unsigned long dynamic_threads;
};
typedef sequence <ThreadpoolLane> ThreadpoolLanes;
// Threadpool Policy
const CORBA::PolicyType THREADPOOL_POLICY_TYPE = 41;
local interface ThreadpoolPolicy : CORBA::Policy {
readonly attribute ThreadpoolId threadpool;
};
local interface RTORB {
...
ThreadpoolPolicy create_threadpool_policy (
in ThreadpoolId threadpool
);
exception InvalidThreadpool {};
ThreadpoolId create_threadpool (
in unsigned long stacksize,
in unsigned long static_threads,
in unsigned long dynamic_threads,
in Priority default_priority,
in boolean allow_request_buffering,
in unsigned long max_buffered_requests,
in unsigned long max_request_buffer_size );
ThreadpoolId create_threadpool_with_lanes (
in unsigned long stacksize,
in ThreadpoolLanes lanes,
in boolean allow_borrowing
in boolean allow_request_buffering,
in unsigned long max_buffered_requests,
in unsigned long max_request_buffer_size );
void destroy_threadpool ( in ThreadpoolId threadpool )
raises (InvalidThreadpool);
};
};
| Listato 1: Interfaccia IDL per RT-CORBA sui Thread |
Non solo, con RT-CORBA è anche possibile intervenire sulle politiche di schedulazione impostando una differente coordinazione dei processi. Ad ogni operazione si assegna una priorità (tra 0 e 32767); questa priorità viene poi tradotta in una priorità nativa del sistema operativo dove il metodo viene eseguito. I modelli definiti per l’assegnazione delle priorità sono sostanzialmente due: Server Declared e Client Propagated. Con il primo meccanismo è il server che stabilisce la priorità alla quale vengono effettuate le invocazioni sui suoi metodi; nel secondo caso, al contrario, è il client che determina la priorità a cui deve essere eseguito un metodo. La specifica CORBA consente di modificare la priorità attraverso differenti schemi. Con il meccanismo dei ThreadPool è possibile definire un insieme di thread già allocati e disponibili per l’esecuzione dei metodi, nonché di assegnare a loro la priorità. Non solo, a ogni POA, Portable Object Adapter, è associato un solo ThreadPool, che può essere anche condiviso da più POA. I thread sono allocati all’atto della creazione del ThreadPool e quindi consumano risorse di sistema a meno che non si tratti di thread dinamici. Un ThreadPool può essere suddiviso in linee, ognuna con la sua priorità, il suo numero di thread statici e il suo numero di thread dinamici. Le differenti linee possono essere utilizzate per realizzare diverse tipologie di servizio, in questo modo si può garantire una maggiore flessibilità all’intero sistema e al processo di configurazione. Uno degli aspetti più importanti in RTCORBA è lo schedulatore. Infatti, lo scheduling service presente permette di realizzare una politica di scheduling globale oltre alla possibilità di assegnare le opportune policy agli ORB. TAO, con molta probabilità, è la versione RT-CORBA più nota. Infatti, TAO è un’implementazione open-source dello standard RT-CORBA che consente di gestire la qualità del servizio in maniera efficiente, prevedibile e scalabile. Uno degli elementi di maggior interesse di TAO è il suo Real-Time Scheduling Service. TAO offre un requisito importante per queste particolari applicazioni, ovvero la predicibilità. È possibile anche garantire una sua facile portabilità visto che lo stesso è stato scritto in C++, oltre ad essere compatibile con la versione CORBA 3.x che include, tra l’altro, anche la specifica Real-Time. TAO è utilizzabile senza la necessità di acquistare una licenza liberando così l’utente dai costi di sviluppo, anche se, poi, per usi embedded con poche risorse hardware, non è proprio indicato visto che stiamo parlando di un componente software del tutto ragguardevole; infatti, la Tabella 1 mostra il volume di codice. TAO risulta essere estremamente flessibile perché consente, ad esempio, di assegnare a una precisa operazione una QoS più opportuna con attributi ed eventuali priorità.
Tabella 1: Linee di codice
A questo proposito, il suo Run-Time Scheduler per ogni operazione del server richiesta dai client effettua la traduzione delle priorità assegnate nelle priorità comprensibili dal dispatcher del sistema operativo sottostante. L’ACE è un altro componente importante in fatto di RT-CORBA e, nello specifico, di TAO. Infatti, per facilitare la gestione delle diverse problematiche presenti è stato introdotto l’Adaptive Communication Environment, o ACE. Questo modulo assicura una maggiore flessibilità in fatto di comunicazione, oltre a semplificare la gestione dei thread o nella gestione della memoria. Come per TAO, anche ACE è scritto in C++ ed è utilizzabile per un’ampia varietà di sistemi operativi.
