Issues in RealTime CORBA Requirements for RealTime CORBA
Issues in Real-Time CORBA • Requirements for Real-Time CORBA: A. Inselberg and P. Krupp “Requirements for Real-Time CORBA”. Milcom’ 97 • A System: D. Schmidt et al. “TAO: a Middleware Framework for Real-Time ORB Endsystems”, IEEE Workshop on Middleware for Distributed Real-Time Systems and Services, 1997.
Requirements for Real-Time CORBA • Applications domains with realtime needs: – DOD/Aerospace – Manufacturing – Electronic Commerce – Process Control – Finance – Telecommunications • Characteristics of distributed real-time systems: – Response Time – Reliability – Correctness and Completenes – Concurrency – Distribution
Real-Time Requirements for CORBA • Functional Requirements: – – – – Ability to track events (object startup, completion, creation, invocation, …) Availability of global clock. Support for variety of scheduling policies. Priority based queueing and priority inheritance Support for multithreaded clients and servers. Support for multiple communication protocols. Support for failure notification (timing failures, “operational” failures) • Operational Requirements: – – Make available performance times of CORBA functions. Shared memory Predictable garbage collection Support large number of concurrent connections to remote objects. • Implementation Requirements: – Small memory footprint – Thread-safe and reentrant
Impact on CORBA • Modification of ORB and its Services – Dynamic Invocation Interface? – Thread abstraction layer. – Priority based queueing for components and services – Priority inheritance, priority ceiling, etc. – Time awareness (e. g. in Event Service) – Publish worst-case execution time for all functions. – TCP/IP? – Object mobility, distributed transparency? • Addition of New Services for Real-Time – New Real-Time Services, e. g. Scheduling Service – Timing exceptions, both at client and at server • Extensions to IDL – Timing constraints in invocation vs. as part of IDL.
TAO (D. Schmidt et al) • Trends in Distributed, Real-Time System Development – programming applications vs. integrating reusable components – remote method invocation to integrate distributet application components – efforts to define standard software infrastructure in heterogeneous environments. – demand for Qo. S guarantees in and systems [what about network? rb] • => CORBA/DCOM/Java RMI • Problems: – lack of Qo. S specification interfaces – lack of Qo. S enforcement – lack of real-time programming features – lack of performance optimizations
TAO: Overview • Real-time IDL stubs and Skeletons – specify and enforce timing requirements end-to-end. • Real-time object adapter (ROA) – in addition to demultiplexing requests, ROA dispatches requests in accordance with scheduling strategies. • ORB Qo. S Interface • Real-time I/O subsystem – admission control and priority assignment • High-speed network adapters – ATM on steroids • Originally: static priority (communication 20 Hz, 10 Hz, 5 Hz, 1 Hz)
A Real-Time CORBA Scheduling Service in TAO • Example: Avionics mission computing – deterministic real-time requirements: e. g. weapon release, navigation – statistical real-time requirements: e. g. built-in tests, lowpriority display queues. • Typical application characteristics: – bounded executions – bounded rates – known operations
Limitations of Static Scheduling • Traditionally: RMS • Inefficient handling of non-periodic processing: – Needs to treat aperiodic requests as if periodic, i. e. , as if occuring at maximum rate (e. g. sporadic server, etc. ) • Utilization phasing penalty for non-harmonic periods: – High utilization possible only for harmonic workloads – Otherwise schedulability bound slightly larger than 69% • Inflexible handling of invocation-to-invocation variation in resource requirements – Mode changes are very expensive.
Overcoming Limitations: Dynamic Scheduling • For example EDF(Earliest Deadline First), MLF (Minimum Laxity First), MUF (Maximum Urgency First) • Problems: – Many dynamic scheduling strategies do not offer a priori guarantees – Purely dynamic scheduled systems can behave non-deterministically under heavy loads. • EDF: – Operations dispatched based on time-to-deadline. – Limitation: Operation with earliest deadline is dispatched whether or not there is sufficient time to complete its execution. Fact that operation cannot meet its deadline only detected after the deadline has expired. • MLF: – Operations dispatched in laxity order. – Can detect deadline violation prior to deadline itself.
Priority Mapping in TAO • Priority fields in RT_Info of task: – static priority – dynamic subpriority – static subpriority • Real-time information about task: – criticality – execution time – period – dependencies – importance • Various mapping of info to priority fields allow for variety of scheduling algorithms.
- Slides: 10