A Generative Programming Approach for Adaptive Middleware

1
A Generative Programming Approach for Adaptive
Middleware

• Venkita Subramonian Chris Gill
• Distributed Object Computing Group
• Washington University, St. Louis

2
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

3
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

4
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

5
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

Para-functional properties captured as aspects
A
B
Replywait strategy
Replywait strategy
ORB1
ORB2
A.foo1
B.bar1
A.foo2
Functional properties captured using invocation
graph
6
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
7
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

8
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

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

11
Wait-on-reactor is it perfect?

• Wait-on-Reactor comes with its own baggage
• Wait-on-Reactor strategy could cause interleaved
  request/reply processing

12
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

13
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

14
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

15
Problem representation in terms of call graph

• 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 gt Kc segments of color C
• Kc is number of threads in node with color C
• E.g., f3-f2-f4-f5-f2

f1
f2
f3
f4
f5
16
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
f5
f4
f2
f4
f5
f2
Permutable
17
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

18
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

19
Using logic in our example

• Predicates in the logic
• Deadlock(CallChain)
• HostedIn(function,Process)
• ReplyWaitStrategy(Process,strategy)
• 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

20
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

21
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()
• templateltWaitPolicyT WaitPolicy, BFBoundT
  BFBoundgt
• struct PolicyValidator
• typedef IF ltWaitPolicyWaitOnReactor,
• IF ltBFBoundBFBounded,
• InvalidCombination,
• ValidCombinationgtRET,
• ValidCombinationgtRET RET

• //This one is a valid combination.
• PolicyValidatorltWaitOnReactor,
• BFUnBoundedgtRET validator1
• //This one is an invalid combination.
• //Gives compile error
• PolicyValidatorltWaitOnReactor,
• BFBoundedgtRET validator2

22
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

23
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