Variable Lifting in Lambda Expressions

In my previous blog about event driven programming pattern, there was a code block that I want to make sure is well explained. 

private Task<string> CallLongRunningServiceWithCallback()

{

  var tcs = new TaskCompletionSource<string>();

  var client = new ServiceReference1.Service1Client();

  client.LongFunctionCallback += (o, args) =>

    {

      if (args.Error != null)

      {

        tcs.TrySetException(args.Error);

        return;

      }

      if (args.Cancelled)

      {

        tcs.TrySetCanceled();

        return;

      }

      tcs.TrySetResult(args.Result);

    };

     client.RunLongFunctionAsync();

     // Do some other work…

     return tcs.Task;

}

How come a variable declared outside the callback function is accessed inside the function? Isn’t this against the variable scoping rules? Why won’t compiler throw error? Many programmers may have these questions (at least my few of my team meets asked this) and that is why I wanted cover it in a separate blog post.

If you are not keeping close look on what is introduced in each .NET version upgrade, you may have missed this addition to the .NET in 3.0. If you use lambda expression, you can refer to the local variables in the method your lambda is declared. In above example, tcs is defined as local variable to the CallLongRunningServiceWithCallback method but it’s also available to use inside the lambda method for LongFunctionCallback delegate. This behaviour is called variable lifting and it was derived from lambda calculus. Lambda (λ) has been used in mathematics for a long time. The formal systems that are nowadays called λ-calculus and combinatory logic were both invented in the 1920s, and their aim was to describe the most basic properties of function-abstraction, application and substitution in a very general setting. In 1985 Thomas Johnsson introduced lambda lifting. After that it was added to few computer programming languages, but Microsoft formally introduced it in .NET 3.0 I believe somewhere around 2007.

How does variable lifting works behind the scene? Lambda function may contain some it’s own local variables and some variables from the calling function. The local variables inside the lambda are called bound variables and calling function’s variables are called free variables. Free variables are “lifted” into the lambda. Compiler does a lot of leg work for you to capture the state of variables and preserve them outside of their normal lifetimes. More formally, when the compiler encounters a lambda expression that has free variables, it will lift the free variables into a class called a closure. The closure's lifetime exists beyond the lifetime of the free variables hoisted in it. The compiler rewrites the variable access in the method to access the one within the closure instance. It will create a closure class similar to the following. Please note that actual name of the class is auto-generated and so it could be different.

public class _closure$_1

{

  public TaskCompletionSource<string> tcs = new TaskCompletionSource<string>();

  public Task<string> LongFunctionCallback(CallbackArgs args)

  {

    var tcs = new TaskCompletionSource<string>();

    var client = new ServiceReference1.Service1Client();

     client.LongFunctionCallback += (o, args) =>

    {

      if (args.Error != null)

      {

        tcs.TrySetException(args.Error);

        return;

      }

      if (args.Cancelled)

      {

        tcs.TrySetCanceled();

        return;

      }

      tcs.TrySetResult(args.Result);

    };

     client.RunLongFunctionAsync();

     // Do some other work…

     return tcs.Task;

  }

}

As you can see the tcs variable is lifted inside the closure class. Compiler will then also modify the main method where lambda is called to instantiate the closure class, assign calling function’s local variable to the .tcs property of closure class and then call the closure class’s LongFuncationCallback method.

I hope this helps understanding my earlier blog post about event driven programming. You will see similar code of TaskCompletionSource in many places on MSDN and other blog sites, but I could not find anywhere anyone explaining variable lifting in the same post. There could be many interesting scenarios that you can try out to dig more deep into how variable lifting works. What will happen if I change the lifted variable after the lambda expression? You can see such scenarios are explained very well by Timothy Ng in MSDN magazine article. 

Responsibility Matrix for Architecture / Design Creation Activity

In a large project, there may be many people who have some role in the creation and approval of project deliverables. Sometimes this is pretty straightforward, such as one person writing a document and one person approving it. In other cases, there may be many people who have a hand in the creation, and others that need to have varying levels of approval. The Responsibility Matrix is a tool used to define the general responsibilities for each role on a project. The matrix can then be used to communicate the roles and responsibilities to the appropriate people associated with the team. This helps set expectations and ensures people know what is expected from them.

C - Create
I - Provide Input
R - Review
A - Approve
N - Notify
M - Manage

Let’s say Product Owner wants to add a new functionality to the product. Typically business team or product owner provides requirements. Requirement document should also have its own responsibility matrix defined. However since this is architect's blog I would highlight the responsibility matrix for architecture or design activity for creating design artifacts.

In a large project typically you have one or more enterprise architects and one or more application architects. However it’s important to define the primary ownership of new feature design to one enterprise architect who looks at the overall product and one application architect of the area where the new feature is being added. In this case, I would define the responsibilities as follows:

C - Creator of the design is one application architect whose application is largely affected by the new feature. This architect is primarily responsible for creating a design document.

R - All other architects review the design document for design-flaw, best practices or company standards compliance, integration issues with their applications etc. In other words, all other architects have review responsibility.

I - Business Analysts, Project Managers and Product Owners holds responsibility of providing inputs here. It is critical to get inputs from them as far as explaining the business problem. In many cases I have experienced that whenever responsibility matrix is not clearly defined, PMs, business analysts or product owners start providing design suggestions or sometimes forces a specific design. This is usually as case when these roles have some technical background in their career. They remember how they have done it in the past and start dictating how it should be done or starts questioning the architects. This is why responsibility matrix plays such a crucial role in large projects and conflicts can be avoided.

A - Finally enterprise architect has to make a call on the design and approve it. It’s important to have this played by single person to manage accountability.

N - Once the design is approved, Project Manager should be notified. The important contribution of project manager here is to do scope management, prioritization and risk management. All project managers know what this means.

M - Delivery team including technical managers, team leads and developers then manages it to take it to the further level of creating low level design, provide estimates to PMs and fit it into release plan. Finally implement the feature based on the agreed upon release plan.

Again one can ask whose responsibility is to create responsibility matrix? IMO it’s a team’s job but primary owner is project manager. If you have reached this line, thanks for reading this blog post. Please provide your comments.

Evolution of Asynchronous Programming (EAP) in .NET

Asynchronous programming model in .NET makes it very easy for developers to write event based asynchronous pattern (EAP) code starting .NET version 4.5. We have been trained for long enough by .NET programming practices to use event based pattern for any asynchronous work. For example, you want to perform a long running operation. When calling this long running function, you don’t want your client code to make a blocking call; instead a very famous pattern that many architects suggests here is to ask you client to pass a callback function or delegate and that callback function will be called as soon as this long running operation is over. This is nothing but the EAP pattern.

As shown in following example, function “client” makes a call to “longfunction” and waits for the long function to complete. This is a blocking call.

private Task<string> CallLongRunningService()

{

  var client = new ServiceReference1.Service1Client();

  // blocking call where main thread is blocked

  client.CallLongRunningService();

}

Now instead of just waiting for “longfunction” to complete, “client” function wants to do some other stuff. Here many architects would suggest to use EAP pattern and call the long function asynchronously.

So we refactor “CallLongRunningService” to “CallLongRunningServiceWithCallback” and ask a callback function to be called when long function is complete.

private void CallLongRunningServiceWithCallback()

{

  var client = new ServiceReference1.Service1Client();

  client.LongFunctionCallback += LongFunctionCallback;

  client.RunLongFunctionAsync();

}

private void LongFunctionCallback(CallbackArgs args)

{

  // set the result in some local variable. Basically store the result so that others

  // can access it

  m_result = args.Result;

}

As you can guess “client” function also need to be refactored to consume the refactored “CallLongRunningServiceWithCallback” and reconcile its logic with the callback function. Now we have split the logic into two functions, main function and callback function.

Now this is where TaskCompletionSource and Task Parallel Library TPL comes to rescue. Using TaskCompletionSource you can refactor the above code as follows:

private Task<string> CallLongRunningServiceWithCallback()

{

  var tcs = new TaskCompletionSource<string>();

  var client = new ServiceReference1.Service1Client();

  client.LongFunctionCallback += (o, args) =>

    {

      if (args.Error != null)

      {

        tcs.TrySetException(args.Error);

        return;

      }

      if (args.Cancelled)

      {

        tcs.TrySetCanceled();

        return;

      }

      tcs.TrySetResult(args.Result);

    };

    client.RunLongFunctionAsync();

    // Do some other work…

    return tcs.Task;

}

Client application will get the task as return parameter and will have to call task.Result to get the result from long running function. In the above see the comment line “Do some other work…”. This is where you can do something else while the long function is doing its job. Following is the code you will write to consume the long running function with callback.

Task<string> t = CallLongRunningFunctionWithCallback();

Console.WriteLine(t.Result);

Where is the blocking call here? In above lines of code when you call t.Result it’s a blocking call on current thread. You need this anyway because we don’t know how long the long function will take to complete. But the best thing about this pattern that I allows us to not just wait but we can carry other activities during the function is running. Also see TPL code is much simpler than our earlier when callback was a separate function.  TPL provides TaskCompletionSource to help us track the result of the async task in a consistent way across the projects.

All IT professionals are business professionals (also)

There is a funny distinction people make about I am an IT professional versus business professional. This is good as far we are talking about what type of skills I have. However it is essential in a successful organization to have a realization that we all working towards solving business problems. I cannot be a purely IT professional and just focus on IT problems. The way I would look at it is I am helping solve a business problem using my IT skills. This takes be back the fundamental reason of existence in any organization. The moment we focus on the reason of our existence in an organization that we are here to solve a business problem or achieve a business goal, our perspective changes. We all become business professionals. Of course we will use different skills to contribute towards solving a problem or achieving a goal, but it is very important to start from a business reason.

As an architect, when I am asked to design a software system I start from what are the organizations goals, what are they trying to accomplish, what business problem are we solving and then understand the solution architecture. In some projects I have seen that an architect is given a bunch of requirement documents and functional specifications and asked to create software architecture. I believe architect should be involved during the requirement gathering discussions and functional specification formation process as well along with business users and business analysts. Architect may not play active role there, but it is important for that role to be part of the process, interact with business users and business analysts to hear the information first hand and not from some document. Architecture is built using collaboration with various parties and a document has limitations of how much you can capture in it. 

Hello World

I have started using this blog instead of my earlier blog on live.com. I am finding it much useful and easy to post to this blog from my iPhone. Lets see how it goes.