Joyce L. Tokar, PhD Vice President of Technology DDC-I jlt@ddci.com
SCORE � Programming Domains • Numerics • Information Systems • Systems Programming • Real-Time Systems • Distributed Systems • Safety and Security � Profiles • Implementer Defined • User Defined • Ravenscar • Extensible Protected Types • Dynamic Ceiling Priorities • Others � ISO Standard and Addendums
SCORE ISO/IEC 8652:1995 – Ada Reference Manual � Core • Basic Features • Real-Time Features • Object-Oriented Enhancements • Megaprogramming Support • Interfaces � Annexes • Numerics • Information Systems • Systems Programming • Real-Time • Safety and Security • Distribution
SCORE Systems Programming � Access to the underlying hardware (machine instructions, hardware devices, etc.); � Access to the underlying operating or runtime system; � Low-level, direct interrupt handling; � Unchecked access to parts of the run-time model of the implementation; � Specifying the representation and allocation of program data structures; � Access to shared variables in a multitasking program; � Access to the identity of tasks and the allocation of data on a per- task basis.
SCORE Real-Time Systems � Priority Model � Dispatch scheduling model entry queue discipline � Specification of the effect of the abort statement � Restrictions on the tasking model � Resolution of a number of timing issues � A distinct monotonic clock � Synchronous and asynchronous task control protocols.
SCORE Safety and Security � Understanding program execution � Reviewing object code � Restricting language constructs whose usage might complicate the demonstration of program correctness
SCORE Distributed Systems � Partitions � Communication Between Partitions • Remote Call Interface (RCI) • Remote Procedure Calls (RPCs) � Partition Communication Subsystem � Consistency of A Distributed System
SCORE � Programming Domains • Numerics • Information Systems • Systems Programming • Real-Time Systems • Distributed Systems • Safety and Security � Profiles • Implementer Defined • User Defined • Ravenscar • Extensible Protected Types • Dynamic Ceiling Priorities • Others � ISO Standard and Addendums
SCORE Implementer Defined � A definition of an execution profile by an Ada vendor that uses the pragma Restrictions and other characteristics of the Special Needs Annexes to refine the behavior of the Ada Execution Environment to meet the needs of a specific domain. Such a system, generally results in an Ada Run-Time System (RTS) which is optimized to meet the requirements specified. � DDC-I • Tasking with FIFO Queuing, Heap Management and Exception Handling • Tasking with Priority Queuing, Heap Management and Exception Handling • No Tasking, No Heap Management and Exception Handling • No Tasking, No Heap Management and No Exception Handling
SCORE Domain Defined � A definition that uses the pragma Restrictions and other characteristics of the Special Needs Annexes to refine the behavior of the Ada Execution Environment to meet the needs of a specific domain. The user expects that a vendor suppling such a system will provide an Ada Run-Time System (RTS) which is optimized to meet the requirements specified. The user community expects common implementations from all suppliers. � Aonix – Raven � University of Madrid (GNAT) – GNAT/ORK
SCORE Ravenscar Profile � The Ravenscar Profile was defined at the International Real-Time Ada Working Group (IRTAWG-8) meeting to meet the needs of the hard real-time, safety-critical, high-integrity community. � This profile was reviewed and refined at IRTAWG-9. � The Ravenscar Profile defines an execution environment that supports the use of a simple subset of Ada tasking and protected types which may be analyzed for their timing properties and which demonstrate deterministic execution. � The suggested profile was reviewed and refined at IRTAWG-10 in September 2000.
SCORE � During the IRTAWG-10 meeting, a number of extensions were considered for Ravenscar. � The following are the recommendations from this session: • Potentially Blocking Operations – While executing within a protected object, a Ravenscar compliant implementation shall raise Program_Error for all potentially blocking operations except those which occur in a foreign language domain.
SCORE � More recommendations from IRTAWG-10: • Heap – A Ravenscar compliant implementation shall make no explicit use of the heap in the RTS. The implementation shall not use the storage pool other than for the execution of allocations ==> No_Implicit_Heap_Allocations is added to the Ravenscar Restrictions. • Dynamic Interrupt Handlers – When using the No_Dynamic_Interrupt_Handlers restriction, the user does not use any of the subprograms defined in the package Ada.Interrupts. Therefore, an implementation may provide a package that does not include the procedures or that only provides null bodies for these routines or raises Program_Error.
SCORE Silence � The Ravenscar Profile shall stay silent on the following items at this time: • Standard Storage Pools – the Ravenscar Profile will say nothing on the issue of the use of standard storage pools at this time. • Priority Range – the Ravenscar Profile does not suggest any change to the definition of the range of values for type priority. • Floating Point Types – there are no recommendations in the profile on floating point types.
SCORE � A number of items were considered for further investigation as candidates for inclusion in the Ravenscar profile. � None of these items are in the recommended profile at this time: • Exceptions – what should be done about exceptions? • Shared Variables – it would be nice to require an implementation to specify how long an atomic operation will be non-preemptible. • Controlled Types – should the No_Nested_Finalization restriction be required by Ravenscar? Currently viewed as being implicit by some members of IRTAWG.
SCORE � More research is needed in the following areas: • Dynamic Priorities – needed for earliest deadline first scheduling. • Dynamic Task Creation & Destruction – library level access types and dynamic arrays of tasks are interesting features for the profile. • Protected Object Entries – multiple entries and multiple elements in the entry queue are desirable extensions. • Task entries – the addition of task entries and the select statement should be evaluated. • Conditional entry calls – maybe in the future. • Dynamic Protected Objects – maybe in the future at the library level. • Timed entry calls – maybe in the future.
SCORE Extensible Protected Types � The objective here is to provide better integration between the concurrent features of Ada and the object-oriented features. � The basic model is to supply the syntax and semantics needed to extend protected types in much the same manner as is done for tagged types: protected type T is tagged protected type T1 is new T with procedure W(...); procedure W(...); – overrides T.W procedure X(...); procedure Z(...); – a new method entry Y(...); private private .... .... end T1; end T; type PT is access protected type T’Class; P : PT := new ...; – some type in the hierarchy ..... P.X(...); – all external calls dispatch
SCORE � A key component is the extension of barrier conditions. � As a protected object is extended, the barrier condition on an entry that overrides a parent entry must strengthen the parent's entry barrier condition. � A child can call a parent entry as a "procedure" and therefore the call is not potentially suspending.
SCORE Outstanding Issues � Whether a call to the parent entry should check the barrier and raise Program_Error when there is a failure; presently, the EPT model does not check the parent barrier; � Post processing of a requeue to a parent's entry call should or should not be done; presently, the EPT forbids post- processing; � Should abstract entries have a guard, an optional guard, or should the guard be forbidden; presently, the EPT model forbids guards on abstract entries; � Are the mix-in inheritance characteristics sufficient; � Integration with the features in the Real-Time, Systems Programming, and Safety and Security Annexes; � EPTs and interrupt handlers needs to be studied further as does the entire priority model.
SCORE Dynamic Ceiling Priorities � Changing the Ceiling Priority of a Protected Object dynamically is one effective way to implement mode change. � Several issues arise when considering this model in light of the entire Ada language as well as within the domain defined by the Ravenscar Profile.
SCORE Issues to be Considered � How do changes of the ceiling priority occur? � What are the effects of changing the ceiling priority of a protected object during the execution of a protected action? � What is the behavior for the interactions between the change in the ceiling priority of a protected object and the requeue operation?
Recommend
More recommend
