A Generative Programming Approach for Adaptive Middleware Venkita Subramonian & Chris Gill Distributed Object Computing Group Washington University, St. Louis

Need for Adaptive Middleware  Mission-critical systems need a high degree of coordination among end- systems  E.g., Military Command and Control, Distributed Manufacturing systems, Coordinated disaster response  End-systems undergo Mode changes based on internal changes as well as interaction with other end-systems  Dealing with all possible combinations of middleware settings in all modes apriori is not feasible Joint Forces Global Info Grid Joint Forces Global Info Grid

Component based middleware development  Increasing effort to use reusable components  How do we develop correct distributed real-time embedded systems using reusable components?  Correctness defined in two dimensions  Functional  Algorithmic correctness, type safety  Para-functional  End-to-end timeliness, recovery from faults, memory footprint, concurrency, security  Component middleware to the rescue  Process of developing, packaging and deployment made easier  Main focus on functional properties  E.g., CORBA Component Model, J2EE, COM  But DRE systems need more…

Component Models with QoS  Para-functional constraints still need to be addressed  Component models enhanced to address para-functional constraints  E.g., RTCCM implementation – Component Integrated ACE ORB (CIAO)  Combining functional and para-functional properties still tedious and error prone  Fundamental problem is Interference between the above two sets of properties

Interference  Para-functional properties could interfere with each other and with functional properties  Choice of number of threads in one ORB could affect the timeliness of invocation from another ORB  Need to analyze and capture this interference in a formal way AB A.foo1B.bar1A.foo2 Functional properties captured using invocation graph ORB1ORB2 Replywait strategy Replywait strategy Para-functional properties captured as aspects

Problem Statement Given functional and para-functional properties of a system, is the system deadlock-free and does it meet its deadlines? Points of variation: Deployment strategy Wait on Reply Strategy Invocation graph

Motivating example – Endsystem ORB configuration  Many possible configurations for ORB infrastructure in end- systems  E.g., Number of threads, Reply wait strategy  Some combination of configurations are not safe  Using (The ACE ORB) TAO as an example

Patterns in TAO – an interlude  Reactor  Synchronous Demultlplexing of events from multiple event sources – e.g. sockets, message queues, etc  Event Handlers registered with reactor for actual event handling  Reactor notification acts an interrupt  Leader-Followers  Used for managing threads in a thread pool  Threads take turn waiting on reactor for events  Leader waits on reactor and followers wait on condition variables  Leader promotes follower before processing event

Wait-on-Connection strategy  Replyhandler waits on connection for the reply  Blocking call to recv()  One less thread listening on the Reactor for new requests  No interference from other requests that arrive when reply is pending  Could cause deadlocks on nested upcalls. Nested Upcall scenario

Wait-on-Reactor strategy  Replyhandler waits on reactor for the reply  As opposed to waiting on connection  Reactor gets a chance to process other requests while replies are pending  Interleaving of request reply processing  Very ideal for single threaded processing  With multiple threads, Leader- Follower model is used

Wait-on-reactor – is it perfect?  Wait-on-Reactor comes with its own baggage  Wait-on-Reactor strategy could cause interleaved request/reply processing

Blocking factors  Blocking factors need to be considered for real-time analysis  Blocking factor could be bounded or unbounded  Based on the upcall duration  Blocking factors affects real-time properties of other end-systems  Call-chains will have a cascade effect

What did we learn?  Ensuring safety and feasibility of operations in individual systems requires  Modeling a graph of method invocations  Decorating the graph with QoS attributes  Execution time, Period, etc  Performing analysis over the graph  Interaction with other end-systems need to be taken into account  Static configuration whenever possible  Reduces runtime overhead for adaptation  Runtime reconfiguration to deal with runtime adaptation  Certain combination of configurations may not be valid or safe  Goal is to build systems which are “correct by composition”

Choice of configuration  Choose strategy based on system characteristics  Dimensions of freedom  Reply-wait strategy  Thread count  Deployment of components  Call graph nodes carry configuration parameters  System Modes represented by call graph and a tuple of configuration attributes

 Analysis of para-functional properties done by analyzing the call graph  Each method is assigned a color corresponding to the host on which the servant hosting the method is deployed  Deadlock exists  If there exists > K c segments of color C  K c is number of threads in node with color C  E.g., f3-f2-f4-f5-f2 Problem representation in terms of call graph f1 f2 f3 f4 f5

Temporal nature of call graphs  Possibly different call sequences in different modes of systems operation  A partial order could be established statically based on call sequence constraints  Leverage graphical tools capable of call graph manipulation f3 f2 f4 f5 f2 f5 f2f4 Permutable

WUGLE  WUGLE – Washington University Guided Logic Exercises  Dr. Robert Pless and Jacob Perkins, Media and Machines Lab, WUSTL  Tool for manipulating logical expressions and visualize other abstract concepts  WUGLE currently being enhanced to transform graphs  Three dimensions of freedom as attributes of graph nodes  Different configurations realized by assigning different attributes to the graph nodes

Towards a Theory of Infrastructure Configuration  “Correct by composition” needs “design for composition”  Use first-order logic to formally capture interference between system aspects  Use Generative programming to do the actual configuration  Configuration generators use configuration logic as the basis for generating appropriate configurations  Weaving of multiple QoS aspects

Using logic in our example  Predicates in the logic  Deadlock(CallChain)  HostedIn(function,Process)  ReplyWaitStrategy(Process,strate gy)  Question: Is there a possibility of deadlock because of wrong configuration?  Calculation of execution time typically done outside the logic framework  As part of schedulability analysis tool

C++ Template Meta-Programming  One form of Generative Programming  Mechanism to embed generators in C++  Completely within the purview of C++ language  Metainformation represented using  Member traits, Traits classes, Traits templates  Compile-time control-flow constructs  Template metafunctions E.g. IF, THEN, ELSE, CASE  Conditional compilation based on evaluation of type-expressions  Issues  Advanced usage of C++ templates  Compiler support an issue

Configuration Validator – a glimpse enum WaitPolicyT {WaitOnReactor, WaitOnConnection}; //Do we need bounded Blocking factor? enum BFBoundT {BFBounded, BFUnBounded}; class InvalidCombination { //Instantiation of this class gives compile error private: ~InvalidCombination(); }; class ValidCombination { public: ~ValidCombination(){} }; template struct PolicyValidator { typedef IF <WaitPolicy==WaitOnReactor, IF <BFBound==BFBounded, InvalidCombination, ValidCombination>::RET, ValidCombination>::RET RET; }; //This one is a valid combination. PolicyValidator<WaitOnReactor, BFUnBounded>::RET validator1; //This one is an invalid combination. //Gives compile error PolicyValidator<WaitOnReactor, BFBounded>::RET validator2;

Related Work  Extending/Exploiting type systems  RMA using template meta programming  RMA schedulability analysis at compile-time within the C++ type system  Compile error when utilization bound exceeds the RM utilization bound  “Rate-Monotonic Analysis in the C++ Typesystem”, Deters, Gill and Cytron, presented at RTAS 2003 Workshop on Model-Driven Embedded Systems  Composition Logics  Work by John Regehr and Alastair Reid at U. Utah  Reasoning about Concurrency in Component-Based Systems Software  First order logic for representing system knowledge  Automated Tools  WUGLE project at WUSTL

Conclusions and Future work  Conclusion  Apply “Correctness by Composition” philosophy for building adaptive middleware  Formalize the composition design using logic  Use a Generative Programming approach to customize a family of systems  Runtime reconfiguration for runtime adaptation  Future work  First-order logic may not be powerful enough.  Need to investigate into other types of logic for sufficient representation of the infrastructure behavior  Using transformation/visualization tools like WUGLE to experiment with different configurations statically