When I started to design synchronization contracts, I wanted to play a little with my ideas before trying to implement the whole mechanism directly into the compiler and runtime monitor. I started to wonder how contracts could be introduced in the .NET platform, and at which level.
The answer is similar to the one given for AOP on .NET (more on this in a future post!): you can act at compiler level (static-weaving in AOP parlor), at the execution engine level, and finally at class library level.

Focusing on the last two, how can you insert code for checking and enforcing constracts? According to the various studies on interception and AOP on the .NET platform(1) there are three ways to intercept calls to methods on an object, and do some preprocessing and postprocessing:

• Using Context Attributes and a Transparent Proxy;
• Synthesize a proxy that forward calls to the original object;
• Injecting directly MSIL code with the Unmanaged .NET profiling APIs.

We will see how each of these methods work, and which is better for the current purpose. In this post, from now on, we will focus on the first method: using Context Attributes and a Transparent Proxy.

(1) NOTE: like Ted Neward points out in this its Interception != AOP post, the term AOP is used incorrectly in many articles. I share his ideas on the subject, but for the purposes of this discussion the term interception will suffice.

Context Attributes and a Transparent Proxy

To cook a solution based on this technology, we need three ingredients:

• Custom Attributes to mark methods with a formula
  
• Reflection (based on .NET metadata) to explore fileds and methods
• .NET Interceptors to hijack execution and check the validity of a formula upon method invocation.
  

The BCL provides a complete set of managed classes (the Reflection API) that can be used to emit metadata and MSIL instructions in a rather simple way, from a managed application. In the managed world, the structure of libraries and classes is available through the metadata; this reflection mechanism makes possible to write applications that programatically read the structure of existing types in an easy way, and also that add code and fields to those types.

For the second ingredient, the .NET Framework provide also a mechanism called Attributes. According to the MSDN developers guide, Attributes designed by your own are called custom attributes. Custom attributes are essentially traditional classes that derive directly or indirectly from System.Attribute. Just like traditional classes, custom attributes contain methods that store and retrieve data; arguments for the attribute must match a constructor or a set of public fields in the class implementing the custom attribute.
Properties of the custom attribute class (like the element that they are intended for, if they are inherited and so on) are specified through a class-wide attribute: the AttributeUsageAttribute.
Here is an example, applied at our problem: an attribute to attach a formula to a method:

[AttributeUsage(AttributeTargets.Constructor |
   AttributeTargets.Method | AttributeTargets.Property,
   Inherited = true,
   AllowMultiple = true)]
public class GuardAttribute : Attribute
{
   public GuardAttribute() {
      Console.WriteLine("Eval Formula: " + Formula);
   }
   public GuardAttribute(string ltlFormula) {
      Formula = ltlFormula;
      Console.WriteLine("Eval Formula: " + Formula);
   }
   public string Formula;
}

And here is an example of application of our new custom attribute:

public class Test
{
   bool g;
   bool f = true;
   [Guard("H (g or f)")] //using constructor
   public string m(int i, out int j)
   {
      j = i;
      return (i + 2).ToString();
   }
   [Guard(Formula = "H (g or f)")] //using public field
   public string m(int i, out int j)
   {
      j = i;
      return (i + 2).ToString();
   }
}

Attributes, like other metadata elements, can be accessed programmatically. Here is an example of a function that, given a type, scans its members to see if some is marked with our GuardAttribute:

public class AttributeConsumer
{
   Type type;
   
   public AttributeConsumer(Type type)   
   {
      this.type = type;
   }
   
   public void findAttributes()
   {
      Type attType = typeof(GuardAttribute);
      
      foreach (MethodInfo m in type.GetMethods()) 
      {
         if (m.IsDefined(attType, true))
         {
            object[] atts = m.GetCustomAttributes(attType, true);
            GuardAttribute att = (GuardAttribute)atts[0];
            parseAttribute(att.Formula);
         }
      }
   }
   
   public void walkMembers(string s)
   {
      BindingFlags bf = BindingFlags.Static
                  | BindingFlags.Instance
                  | BindingFlags.Public
                  | BindingFlags.NonPublic
                  | BindingFlags.FlattenHierarchy ;
      
      Console.WriteLine("Members for {0}", s);
      MemberInfo[] members = type.GetMember(s, bf);
      for (int i = 0; i < members.Length; ++i)
      {
         Console.WriteLine("{0} {1}", 
            members[i].MemberType,
            members[i].Name);
            
         //inject additional Metadata for formulas
            
         //generate code for updating the formulas
            
         //inject it      
      }
   }
   
   void injectMetadata() {
      //...          
   }
}

If such an attribute is found, its formula is scanned, and appropriate fields to hold the previous status of sub-formulae (needed for recording temporal behaviour) are injected into the actual type.

But what about the code? We need to be notified when a method we are interested in (a method with an attached formula) is called. Here comes the third ingredient: .NET interceptors.

.NET interceptors are associated with the target component via metadata; the CLR uses the metadata to compose in a stack a set of objects (called message sinks) that get notified of every method call. The composition usually happens when an object instance of the target component is created. When the client calls a method on the target object, the call is intercepted by the framework, the message sinks get the chance of processing the call and performing their service; finally the object's method is called.
On the return from the call each sink in the chain is again invoked, giving it the possibility to post-process the call. This set of message sinks work together to provide a context for the component's method to execute.

Thanks to attributes, metadata of the target component can be enriched with all the information necessaries to bind the message sinks we want to the component itself. However, custom attiributes are often not sufficient: if you need access to the call stack before and after each method to read the environment (like parameters of a method call), this requires an interceptor and the context in which the object lives: .NET interceptors can act only if we provide for a context for the component.
Let's see how objects can live in a context, and how contexts and interceptors work togheter. In the .NET Framework, an application domain is a logical boundary that the common language runtime (CLR) creates within a single process. Components loaded by the .NET runtime are isolated form each other: they run independently of one another and cannot directly impact one another; they don't directly share memory and they can communicate only using .NET remoting (although this service is provided transparently by the framework). Components living in separate appdomains have separate contexts. For objects living in the same application domain, a context is provided for any class that derives from System.ContextBoundObject; when we create an instance of a subclass of ContextBoundObject the .NET runtime will automatically create a separate context for the newly created object.

 

This diagram shows the flow of a call between the a client class and an object in a different context or application domain.
In such a situation, the .NET framework performs the following steps:

1. A transparent proxy is created. This proxy contains an interface identical to the recipient, so that the caller is kept in the dark about the ultimate location of the callee.
2. The transparent proxy calls the real proxy, whose job it is to marshal the parameters of the method across the application domain. Before the target object receives the call there are zero or more message sink classes that get called. The first message sink pre-processes the message, sends it along to the next message sink in the stack of message sinks between client and object, and then post-processes the message. The next message sink does the same, and so on until the last sink is reached. Then the control is passed to the stack builder sink.
3. The last sink in the chain is the stack builder sink. This sink takes the parameters and places them onto the stack before invoking the method in the receiving object.
4. By doing this, the recipient remains as oblivious to the mechanism used to make the call as the initiator is.
5. After calling the object, the stack builder sink serializes the outbound parameters and the return value, and returns to the previous message sink.
   

So, the object implementing our pre- and post-processing logic have to participate in this chain of message sinks.

For a class implementing a sink to be hooked to our target object, we first need to update our attribute to work with context-bound objects. This is done by deriving it from ContextAttribute instead of Attribute and implementing a method for returning a context property for that attribute:

[AttributeUsage(AttributeTargets.Class, Inherited = true)]
public class InterceptAttribute : ContextAttribute
{
    
   public InterceptAttribute() : base("Intercept")
   {
   }

   public override void Freeze(Context newContext)
   {            
   }

   public override void 
      GetPropertiesForNewContext(IConstructionCallMessage ctorMsg)
   {
      ctorMsg.ContextProperties.Add( new InterceptProperty() );
   }

   public override bool IsContextOK(Context ctx, 
      IConstructionCallMessage ctorMsg)
   {
      InterceptProperty p = ctx.GetProperty("Intercept") 
         as InterceptProperty;
      if(p == null)
         return false;
      return true;
   }

   public override bool IsNewContextOK(Context newCtx)
   {
      InterceptProperty p = newCtx.GetProperty("Intercept") 
         as InterceptProperty;
      if(p == null)
         return false;
      return true;
   }

}

[AttributeUsage(AttributeTargets.Constructor | 
    AttributeTargets.Method | AttributeTargets.Property, 
    Inherited = true,
    AllowMultiple = true)]
public class GuardAttribute : Attribute
{ 
   public GuardAttribute() {}
   public GuardAttribute(string ltlFormula)
   {
      Formula = ltlFormula;

      AttributeConsumer ac = new AttributeConsumer();

      //parse formula...
      LTLcomp parser = new LTLcomp(ac);
      parser.openGrammar(...);
      parser.parseSource(ltlFormula);
   }

   private string Formula;

   public void Process()
   {
      //evalute Formula
   }

   public void PostProcess()
   {
      //update formula
   }
}

At object creation time GetPropertiesForNewContext is called for each context attribute associated with the object.
This allows us to add our own \emph{context property} to the list of properties of the context bound with our target object; the property in turn allows us to add a message sink to the chain of message sinks:

The intercepting mechanism is really powerful. However, for our purposes it is not enough. It has three major diadvantages:

• performance: the overhead of crossing the boundary of a context, or of an appdomain, isn't always acceptable (the cost of a function call is 20-fold, from some simple measures I did). If you already need to do this (your component must live in another appdomain, or in another process, or even in another machine) there is no problem and almost no overhead, since the framework need already to establish a proxy and marshal all method calls;
• we have to modify the class(es) in the target component. They must inherith from ContextBoundObject. And since .NET doesn't support multiple inhritance, this is a rather serious issue;
• only parameter of the method call are accessible. The state of the target object, its fields and properties, are hidden. Since to find out if an object is accessible from a client we need to inspect its state, this issue makes it very difficult to use the interception mechanism for our purposes.

Next time we'll see the first completely working solution: synthesized proxies.