Showing posts with label C#. Show all posts
Showing posts with label C#. Show all posts

Saturday, May 3, 2014

How Mongo DB can solve Event Sourcing versionning (Part 1 of 2)

First of all I invite you to read my previous post on How to support changes in your software. It will give you a good heads up on where I’m going with this post.

imageHaving a strategy to support change is a good practice but sometimes it fails on the first change because, well you know, it’s not that easy. I’m a big fan of document database and NoSQL. Mongo DB is a good match for me because it’s easy to install on Windows and use from C# application. I won’t go in to detail on how to create a .NET Application that connect to Mongo. The are plenty of site out there (here, here, here and here) that can help you with that. Document databases are often referred to as schema less database but it’s not completely true. There is a schema, it’s just not as rigid and well defined as traditional databases. The schema used Mongo is based on Json format. For example look at the following Json document. (Only the event payload is shown here and in all other sample)

{
    "Name" : "Logitech wireless mouse",
    "Price" : "29.99$"
}

This document can be the definition of a event in an Event Store. The C# class to handle this event should be:

public class ProductAddedEvent : DomainEvent
{
    public string Name { get; set; }
    public string Price { get; set; }
}

The missing fields are manage by the DomainEventbase class. This is a really simple object to illustrate the concept.

imageNow we realize that we made an error in the definition of the Price field. We want to convert it into a double type to be able to make some calculation with it. In an event sourcing system the events are immutable, they must never be changed. The past is written in stone. So we need to work pretty much like functional programming to evolve our event to a new format. The first thing we need to do is to tag each evolution with a version number. Because all our event derived from the DomainEvent class that is easy. First add a base type to DomainEvent to hold the versioning concerns :

[Serializable]
public abstract class DomainEvent : Versionable
{
  // ...
}

Now take alook at the Versionable class :

[Serializable]
public abstract class Versionable
{
  private int? _version;

  public int Version
  {
    get { return _version.GetValueOrDefault(CurrentVersion); }
    set { _version = value; }
  }

  protected internal virtual int CurrentVersion
  {
    get { return 1; }
  }
}

This will set any new DomainEvent to version 1 by default and provide the ability to change it in the future. The Version field will be serialized and save in Mongo DB. Here is the C# class that define the event payload :

public class FooEvent : DomainEvent
{
    public string Name { get; set; }
    public string Value { get; set; }
}

The serialized version of that class will look like this :

{
    "Version" : 1,
    "Name" : "Foo",
    "Value" : "3.00$"
}

imageNow that we can know which version of the document we are processing we can start thinking about changing the C# class. The goal is to preserve all needed data from one version to the other. Depending on the type of modification different technique can be used. Our first change will be to change the Value field type from string to double. The only good way to do that is to use Mongo BSonSerializer attribute.

public class FooEvent : DomainEvent
{
  public string Name { get; set; }
  [BSonSerializer(typeof(AmountToDoubleSerializer)]
  public double Value { get; set; }
}

public class AmountToDoubleSerializer : BsonBaseSerializer
{
  public override object Deserialize(
    BsonReader bsonReader,
    Type nominalType,
    Type actualType,
    IBsonSerializationOptions options)
  {
    VerifyTypes(nominalType, actualType, typeof(Double));

    BsonType bsonType = bsonReader.GetCurrentBsonType();
    switch (bsonType)
    {
    case BsonType.String:
      string readString = bsonReader.ReadString();
      double value = Double.Parse(readString.Replace("$", ""), CultureInfo.InvariantCulture);
      return value;
    case BsonType.Double:
      return bsonReader.ReadDouble();
    default:
      string message = string.Format("Cannot deserialize BsonString from BsonType {0}.", bsonType);
      throw new FileFormatException(message);
    }
  }

  public override void Serialize(
    BsonWriter bsonWriter,
    Type nominalType,
    object value,
    IBsonSerializationOptions options)
  {
    if (value == null)
    {
      throw new ArgumentNullException("value");
    }

    bsonWriter.WriteDouble((Double)value);
  }
}

The AmountToDoubleSerializer will be able to convert string type to double but also to read and save properties that are already in double format. This will allow for our system to read past events as well as new ones.

In the next post I will show how can we do other transformation such as adding, removing and renaming a property.

Tuesday, April 29, 2014

How to support changes in your Software

Event Sourcing is a very powerful architectural concept. Pretty much like a bank account statement everything you write on it is considered immutable. There is no way you can change anything in the past. The only option is to add a new entry to fix a previously made error.

imageThe goal of such concept is to never loose any information not even mistakes. In real life we make mistake all the time. In any good entry form the will be a lot of validation in place to limit those mistakes. But even then mistake can happen.

If the only mistake would be data it won’t be too much of a problem. Any bad data entry can be corrected by a compensating entry that does the exact opposite. But what happens when mistakes are structural.

In software development we always have to choose amongst many differents options. Every time we decide between one structure over another we have to live with the consequences of that choice for the rest of the life of our software. The ability to change the structure of our software decrease exponentially as the features are added. For every new feature we multiply the number of ways we can combine it with other existing features.

How can we build a software that will last longer than its competitor? How cae we embrace changes in our software? In a CQRS and Event Sourcing developed software it’s easy. There is only two main parts that are subject to big change: The Read Model and the Domain.

imageChanges in the Read Model are not so bad. Because all Read Models are built by replaying all historical events, it’s easy to flush them and rebuild them from scratch. The real challenge is to maintain domain events integrity across the life time of your application.

As I wrote before, event store is meant to be immutable therefore it shouldn’t change in any way. But what if you realize that you forgot an important information that you need to track in your domain? Worse, what if you need to remove some properties of your event or an event property need to change its type. Of course those changes should not be the norm but, you know, sh*t happens. In a CQRS and Event Sourcing application supported by Domain Driven Design (DDD) it should be possible to allow such changes. The domain itself may evolve over time. Some business rule may be changed or added and they may need more information to be applied.

The domain objects are good for hiding the internal process of business rules but, in order to be able to do their job, they need some external information. Those information will be persisted in the event store so they will be available later to rebuild the entire object state and be ready to accept any new state change.

imageConceptually the domain only need to know the latest structure of each event in the event store. It should be able to apply them as is to its internal state. In fact the event store will contain earlier version of those events. The goal is to threat them as if they are like their latest counterparts. The best way to do this is exactly like how source control system work such as Git or Mercurial. In those SCM each change set is recorded as a delta from the previous state. They records any new or removed lines of code. So to make that work all we need to do is to have a piece of code that manage transition from any version to the next. Then we need to apply those transitions from the last saved version to the latest version.

How can we do that in our events? See my next post to know more about how to do just like that with a Mongo DB event store.

Saturday, April 26, 2014

Imagine a world where the past is all and only truth

Palais_de_la_Decouverte_Tyrannosaurus_rex_p1050042 Your computer system must be full of structured and relational databases. You might take regular backup of them if you don’t want to loose any information. Despite all those precautions you loose all in-between state of your information.
If all you care about is the final state it’s not a big deal but there are good chances that you have to answer some questions like:
  • How much time passed between the first item was put in the shopping cart and the completion of the transaction
  • How many times an item was removed from a shopping cart
  • What was the state the purchase order before the crash
If you didn’t implement some ways to trace those events you won’t have any answer to give. Even if you find a way to do it, you will only get information from the moment you put it in place.
I suggest you a new approach to never have to answer “it’s imposible” to your boss when he asks you that kind of question: CQRS and Event Sourcing. The power of this duo comes manly from Event Sourcing. You remember everything that you learned about side effects and why you should do everything possible to avoid them. Here those effects are the only important things. In that kind of system we do not keep data for say, we keep the effect of an action that we call passed events. For example, if we execute the following command:
var command = new AddItemToCart(cartId, itemId);
command.Execute();
The system will produce the following event:
var @event = new ItemAdded(cartId, itemId);
ApplyEvent(@event);
The strength of the system comes when we delete items. We are able to trace those delete as events too:
var command = new RemoveItemFromCart(cartId, cartItemIndex);
command.Execute();
Will produce:
var @event = new ItemRemoved(cartId, cartItemIndex);
ApplyEvent(@event);
In this system, all event derived from a base event:
public class EventBase
{
 public Guid Id { get; set; }
 public int Sequence { get; set; }
 public DateTime TimeStamp { get; set; }
}
A framework class ensure that every events get its date and sequence properties set.
In such system, only events are valuable. They reflect what really happened in the past. Those event will be used to build specific read models for each surrounding system the are interested. Each one will have its own small database to answer to its needs and any changes to that database will only affect this system.
Those read models are only transient representation of the system’s past.

Tuesday, April 16, 2013

Are you “fluent” in C#?

I’m starting a new codeplex project to build a fluent library for design patterns. For example let’s take those examples.
Here is how to build a chain of responsibility is a standard manner:
var command1 = new Command1();
var command2 = new Command2("Test");
command1.NextInChain = command2;
command1.Execute(null);
Here is the same construct in a fluent manner:
var chain = new ChainBuilder<ChainCommand>()
  .Add<Command1>()
  .Add<Command2>(() => new Command2("Test"))
  .Build();
chain.Execute(null);
Which one do you like the most? In my case I prefer the fluent way. Building a chain of responsibility in not that difficult if you have only a handful of element to chain, but if you have more it become boring to remember to link the previous element to the next. My builder take car of that for you. Because of “fluent” concept you always now what comes next. For exmaple the ChainBuilder class only expose some overload of Add and a Build method.
So if you like this way of thinking, join my codeplex project and give me your feedback about it.
See : http://fluentpatterns.codeplex.com/

Monday, March 28, 2011

How to Databind to ListBox’s SelectedItems property (Silverlight)

 

It’s been a while since the last time I published some useful code sample. I apologize!

Today I found what I qualify as a bug in Silverlight 4.0. Those who know me are aware that I’m working on a big Silverlight project for about a year now. As you also know I’m a big fan of patterns and for Silverlight, the obvious one is MVVM.

Every pattern has its own standard and often its own framework. With MVVM the omnipresent framework feature is Databinding. In XAML, Databinding is really powerful. Of course Silverlight doesn’t have all the power WPF has but almost. I’m already used to deal with the limitation of Silverlight binding and the lack of Markup extension for example. But today I it a wall with something I didn’t expect, data binding to the SelectedItems property of a ListBox.

If you look closely at ListBox’s properties you will find that almost all of them are DependencyProperty except for SelectedItems (don’t miss the “s”). SelectedItem (without an “s”) is a ok but not SelectedItems. Why? I suppose its was forgotten.

How to fix that? I found many complex implementation of solution to solve this issue but I didn’t found one I was satisfied with. When trying to debug this “bug” I realized that if I inspect the content of the SelectedItems property in the debug view then the binding was working. So I came up with a solution around that strange side effect.

First let’s try to reproduce the problem. The first thing you need to do is to create a new Silverlight application. Accept all the default, it doesn’t matter. Next put this code in the MainPage.xaml

<UserControl x:Class="ListBoxSelecteItemsBug.MainPage"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
             xmlns:fix="clr-namespace:ListBoxSelecteItemsBug"
             mc:Ignorable="d"
             d:DesignHeight="300"
             d:DesignWidth="400">

    <Grid x:Name="LayoutRoot"
          Background="White">
        <StackPanel Orientation="Vertical">
            <ListBox x:Name="myListBox"
                     Height="200"
               SelectionMode="Extended"
                     ItemsSource="{Binding MyItems}" />

            <Button Content="Click me"
                    Command="{Binding DoItCommand}"
                    CommandParameter="{Binding SelectedItems, ElementName=myListBox}" />
      <Button Content="Make it work"
              Click="ButtonBase_OnClick" />
        </StackPanel>
    </Grid>
</UserControl>

Notice the “CommandParameter” binding at line 22 binding to “SelectedItems” on “myListBox”. Then Put the following code in the MainPage.xaml.cs (code behind).

using System;
using System.Collections;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Linq;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Controls.Primitives;
using System.Windows.Data;
using System.Windows.Input;

namespace ListBoxSelecteItemsBug
{
  public partial class MainPage : UserControl
  {
    private readonly ICommand _doItCommand = new MyCommand();
    private readonly ObservableCollection<string> _myItems = new ObservableCollection<string>();

    public MainPage()
    {
      _myItems.Add("test1");
      _myItems.Add("test2");
      _myItems.Add("test3");
      _myItems.Add("test4");
      _myItems.Add("test5");
      _myItems.Add("test6");
      _myItems.Add("test7");

      InitializeComponent();

      DataContext = this;
    }

    public ICommand DoItCommand
    {
      get { return _doItCommand; }
    }

    public ObservableCollection<string> MyItems
    {
      get { return _myItems; }
    }

    private void ButtonBase_OnClick(object sender, RoutedEventArgs e)
    {
      MessageBox.Show(string.Format("{0} actual selected items", myListBox.SelectedItems.Count));
    }
  }

  public class MyCommand : ICommand
  {
    #region ICommand Members

    public bool CanExecute(object parameter)
    {
      return true;
    }

    public void Execute(object parameter)
    {
      var list = (ICollection<object>) parameter;
      MessageBox.Show(string.Format("{0} items selected", list.Count()));
    }

    public event EventHandler CanExecuteChanged;

    #endregion
  }
}

For simplicity purpose I put everything in the same file but wouldn’t do that normally.

The concept here is simple. If you run this application you will see a ListBox with 7 items in it. You can select one or more of these items and click on “Click me” button. If you do that you should see a popup with “0 items selected” displayed. This proves that the “SelectedItems” is not working. Now if you click on “Make it work” button you should see the actual number of item you have selected previously. Now click again on “Click me” and the number should also be right.

What happened in this sequence of event is simple. The first time you click on “Click me” button you see the initial binding value of number of “SelectedItems” which is 0. The next time you click on it will display the right number because accessing “SelectedItems” outside of data binding seems to refresh its value.

How can we trigger that refresh automatically? With an attached property.

Now add a new file to the Silverlight project call it ListBoxFix and paste it this content:

using System.Windows;

namespace ListBoxSelecteItemsBug
{
  public static class ListBoxFix
  {
    public static bool GetSelectedItemsBinding(System.Windows.Controls.ListBox element)
    {
      return (bool)element.GetValue(SelectedItemsBindingProperty);
    }
      
    public static void SetSelectedItemsBinding(System.Windows.Controls.ListBox element, bool value)
    {
      element.SetValue(SelectedItemsBindingProperty, value);
      if (value)
      {
        element.SelectionChanged += (sender, args) =>
        {
          // Dummy code to refresh SelectedItems value
          var x = element.SelectedItems;
        };
      }
    }

    public static readonly DependencyProperty SelectedItemsBindingProperty =
        DependencyProperty.RegisterAttached("FixSlecetedItemsBinding",
        typeof(bool), typeof(FrameworkElement), new PropertyMetadata(false));
  }
}

The key here is the line 20. The only thing it does is accessing the “SelectedItems”. The last thing to do is to use that AttachedProperty in our ListBox:

            <ListBox x:Name="myListBox"
                     Height="200"
               fix:ListBox.SelectedItemsBinding="True"
               SelectionMode="Extended"
                     ItemsSource="{Binding MyItems}" />

Doing that, triggers the binding to be refreshed and everything should work.

Thursday, March 18, 2010

How to use strongly-typed name with INotifyPropertyChanged

You may already have read my posts about how to use INotifyPropertyChanged in a type-safe way (here and here), but sometime you don’t want to modify all your classes to use this method. All you want is avoid the use of a magic string to define the property. Your code will be refactoring proof.

For example let say you have this property:

public string FirstName
{
    get { return _firstName; }
    set 
    {
        if (_firstName == value)
            return;
        _firstName = value;
        RaisePropertyChanged("FirstName");
    }
}

Some refactoring tool, like Resharper, will be able to change the “FirstName” string but not Visual Studio itself. The solution? Replace this string with a strong type value. How? Let’s assume we can do this:

public string FirstName
{
    get { return _firstName; }
    set 
    {
        if (_firstName == value)
            return;
        _firstName = value;
        RaisePropertyChanged(this.NameOf(p => p.FirstName));
    }
}

Notice that you must specify the “this” keyword to make it work. That is exactly What this extension method let you do:

public static class ObjectExtensions
{
    public static string NameOf<T>(this T target, Expression<Func<T, object>> propertyExpression)
    {
        MemberExpression body = null;
        if (propertyExpression.Body is UnaryExpression)
        {
            var unary = propertyExpression.Body as UnaryExpression;
            if (unary.Operand is MemberExpression)
                body = unary.Operand as MemberExpression;
        }
        else if (propertyExpression.Body is MemberExpression)
        {
            body = propertyExpression.Body as MemberExpression;
        }
        if (body == null)
            throw new ArgumentException("'propertyExpression' should be a member expression");

        // Extract the right part (after "=>")
        var vmExpression = body.Expression as ConstantExpression;

        // Extract the name of the property to raise a change on
        return body.Member.Name;
    }
}

You can even use it in your property changed handler:

private void OnPropertyChanged(object sender, PropertyChangedEventArgs args)
{
    if (args.PropertyName == this.NameOf(p => p.FirstName))
    {
        // ...
    }
}

Enjoy!

Wednesday, September 30, 2009

Using Decorator (or Wrapper) Design Patterns to add Validation to an object

Context

In most cases when someone write about the Decorator pattern it is usually related to UI stuff. The most common example is adding “decoration” to a control, for example a scroll bar. But in my humble opinion, this is not the most useful usage of Decorator. The purpose this pattern is:

“Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub classing for extending functionality”

Gang of Four

If you think about it, Validation is a responsibility and so it can be added by this pattern. Of course we can add the validation to the class itself or in its base class, but how would you reuse this validation across many unrelated objects and what if you object must derive from another base class?

Solution

Decorator The solution is the Decorator pattern. With this pattern we can add new responsibility to an object without changing its internals.

For simplicity purpose we will take a simple sample that anyone can understand but the concept shown here can apply to much more complex object.

Four our sample we will take a bank account. On this account we should be able to to money deposit and withdraw. The class diagram on the right illustrate this design.

Let’s start by defining our IAccount interface

namespace Model
{
   public interface IAccount {
       string AccountNumber { get; }
       decimal Balance { get; }
       bool Active { get; }
       void Deposit(decimal amount);
       void Withdraw(decimal amount);
       void Close();
   }
}

This simple interface will be the central abstraction of the system. The goal is to never depends on concrete class and this interface in enough to add a lot of functionality around an account.

Now here the interface implementation as an Account:

using System.Diagnostics;

namespace Model
{
   [DebuggerDisplay("Account = {_accountNumber}, Balance = {_balance}")]
   public class Account : IAccount
   {
       public string AccountNumber { get; private set; }
       public decimal Balance { get; private set; }
       public bool Active { get; set; }

       internal Account(string accountNumber, decimal balance)
       {
           AccountNumber = accountNumber;
           Balance = balance;
           Active = true;
       }

       public void Deposit(decimal amount)
       {
           if (OnBeforeDeposit())
               Balance += amount;
           OnAfterDeposit();
       }

       protected virtual bool OnBeforeDeposit()
       {
           return true;
       }

       protected virtual void OnAfterDeposit() { }

       public void Withdraw(decimal amount)
       {
           if (OnBeforeWithdraw())
               Balance -= amount;
           OnAfterWithdraw();
       }

       protected virtual bool OnBeforeWithdraw()
       {
           return true;
       }

       protected virtual void OnAfterWithdraw() { }

       public void Close()
       {
           if (OnBeforeClose())
               Active = false;
           OnAfterClose();
       }

       protected virtual bool OnBeforeClose()
       {
           return true;
       }

       protected virtual void OnAfterClose() { }
   }
}

If you expand the previous block of code you will see that the implementation of IAccount is only doing business stuff. There is no other responsibility in this class than the one that is meant for. We can clearly see “Template Method” design pattern here. All “OnSomething()” method are protected and any derided class can add implementation around the process. All “Before” method can cancel the process if the return value is false. This allow extension classes to add some specific behaviour.

But one of the main thing missing in this class is “validation”. We will use the decorator pattern to do that. A decorator class is a class thst implement all the member of an abstraction and forward all the calls to an internal instance of a real implementation that abstraction. In our case the abstraction is “IAccount” so we have to make a decorator that implement that interface.

namespace Model.Decorator
{
   public abstract class AccountDecorator : IAccount
   {
       private readonly IAccount _account;

       protected IAccount Account
       {
           get { return _account; }
       }

       protected AccountDecorator(IAccount account)
       {
           _account = account;
       }

       public string AccountNumber
       {
           get { return Account.AccountNumber; }
       }

       public decimal Balance
       {
           get { return Account.Balance; }
       }

       public bool Active
       {
           get { return Account.Active; }
       }

       public virtual void Deposit(decimal amount)
       {
           Account.Deposit(amount);
       }

       public virtual void Withdraw(decimal amount)
       {
           Account.Withdraw(amount);
       }

       public virtual void Close()
       {
           Account.Close();
       }
   }
}

As you can see the constructor of the decorator takes an instance of “IAccount”. All method forward their call to that instance. This base class simplifies the process of creating concrete decorator by allowing other decorator to implement some but not all members of the interface.

Now is the time to start implementing our validation class structure. For that purpose we will create a base validation class that will be responsible of applying the validation the IAccount instance.

using System.Collections.Generic;
using Model.Decorator;

namespace Model.Validator
{
   public abstract class AccountValidatorBase : AccountDecorator
   {
       protected abstract IEnumerable<IValidation> GetValidations(decimal amount);

       protected AccountValidatorBase(IAccount account) : base(account) {}

       protected void Validate(decimal amount)
       {
           foreach (var validation in GetValidations(amount))
               if (!validation.IsValid)
                   throw validation.Exception;
       }
   }
}

This simple base class define a “GetValidations” method that all derived class must override to add a list of validation to perform on method call.

Now to implement the “Deposit” validation we have to create this class:

using System.Collections.Generic;
using Model.Validation;

namespace Model.Validator
{
   public class AccountDepositValidator : AccountValidatorBase
   {
       public AccountDepositValidator(IAccount account) : base(account) {}

       protected override IEnumerable<IValidation> GetValidations(decimal amount)
       {
           return new List<IValidation>
           {
               new AmountGreaterThanZeroValidation(amount),
               new AmountShouldHaveOnlyTwoDecimals(amount),
               new AccountMustBeActiveValidation(Account),
               new DepositAmountNotExceedMaxValidation(Account, amount)
           };
       }

       public override void Deposit(decimal amount)
       {
           Validate(amount);
           Account.Deposit(amount);
       }
   }
}

This class is responsible for creating all validation instances. The “Deposit” method is overridden to call the base “Validate” method before doing the actual deposit.

To implement those validation we need to define the “IValidation” interface.

using System;

namespace Model.Validator
{
   public interface IValidation
   {
       bool IsValid { get; }
       Exception Exception { get; }
   }
}

Here is a sample implementation:

using System;
using Model.Validator;

namespace Model.Validation
{
   public class AmountGreaterThanZeroValidation : IValidation
   {
       public AmountGreaterThanZeroValidation(decimal amount)
       {
           Amount = amount;
       }

       public decimal Amount { get; set; }

       public bool IsValid
       {
           get { return Amount > 0; }
       }

       public Exception Exception
       {
           get { return new ArgumentOutOfRangeException("amount", Amount, "Deposit amount should be greater than 0."); }
       }
   }
}

All other validations used in “AccountDepositValidator” can be described the same way.

The last step is to create an actual “IAccount” that will implement all this stuff. To do that we will need a Bank class. A bank is responsible of creating account. It will also be responsible of decorating it with all necessary decorators.

using System;
using System.Collections.Generic;
using Model.Logging;
using Model.Validator;

namespace Model
{
   public static class Bank
   {
       static readonly SortedDictionary<string, IAccount> _accounts = new SortedDictionary<string, IAccount>();
       private static int _accountSequence = 1;

       public static IAccount CreateAccount(decimal balance)
       {
           string accountNumber = String.Format("A{0:0000}", _accountSequence++);
           IAccount account = new Account(accountNumber, balance);
           account = new AccountDepositValidator(account);
           _accounts[account.AccountNumber] = account;
           return account;
       }
   }
}

To illustrate this process in action here is a sequence diagram:

Validation with Decorator

  1. Call Bank.CreateAccount.
  2. The Bank instantiate an Account class.
  3. The Bank create an AccountDepositValidator and wrap Account with it
  4. The Bank return an instance of IAccount.
  5. Deposit is called on IAccount which is an instance of AccountDepositValidator
  6. AccountDepositValidator call Validate
  7. AccountDepositValidator call GetValidations to retrieve the list of validation to evaluate
  8. An AmountGreaterThaZeroValidation is created
  9. IsValid returns true
  10. AccountDepositValidator call base Deposit method
  11. Balance value is updated

Next

With all this in place the only thing left to do is to implement all the other validators for all method of “IAccount”.

Thursday, July 23, 2009

Type-safe INotifyPropertyChanged and derived classes

Some of you who read my previous blog post notice that this technique doesn't allow to raise “PropertyChanged” event from a derived class. This is because you can only call method of “PropertyChangedEventHandler” from the class where it is defined. Anywhere else you can only assign (+=) and unassign (-=) event handler.

One way to work around this is to add a method in your base model class that will forward the call to “PropertyChangedEventHandler”.

Here is a modified copy of the class from my previous post:

public class Model : INotifyPropertyChanged
{
    private string _data;

    public string Data
    {
        get { return _data; }
        set
        {
            if (_data == value)
                return;

            _data = value;

            // Type safe raise from base method
            RaisePropertyChanged(() => Data);
        }
    }

    protected void RaisePropertyChanged(Expression<Func<object>> expression)
    {
        PropertyChanged.Raise(expression);   
    }

    #region Implementation of INotifyPropertyChanged

    public event PropertyChangedEventHandler PropertyChanged = null;

    #endregion
}

Now you can define a derived class and use the same method to raise a PropertyChanged event.

public class DerivedModel : Model
{
    private string _moreData;

    public string MoreData
    {
        get { return _moreData; }
        set
        {
            if (_moreData == value)
                return;

            _moreData = value;
            RaisePropertyChanged(() => MoreData);
        }
    }
}

Now with very little effort you can build a type-safe and bindable data model.

It is also useful to be able to raise many property at once. For example if have calculated properties that depends on others like in this sample class:

public class User : INotifyPropertyChanged
{
    private string _lastName;

    public string LastName
    {
        get { return _lastName; }
        set
        {
            if (_lastName == value)
                return;

            _lastName = value;
            RaisePropertyChanged(()=>LastName, ()=>FullName);
        }
    }

    private string _firstName;

    public string FirstName
    {
        get { return _firstName; }
        set
        {
            if (_firstName == value)
                return;

            _firstName = value;
            RaisePropertyChanged(() => FirstName, () => FullName);
        }
    }

    public string FullName
    {
        get { return String.Format("{0} {1}", _firstName, _lastName); }
    }

    public void RaisePropertyChanged(params Expression<Func<object>>[] expression)
    {
        PropertyChanged.Raise(expression);
    }

    #region Implementation of INotifyPropertyChanged

    public event PropertyChangedEventHandler PropertyChanged = null;

    #endregion
}

Because a change to either “FirstName” or “LastName” should trigger a change to “FullName” you have to raise both changes from both properties. Of course you can call “RaisePropertyChanged” many times but with a simple overload you can do this. All you have to do is add this to your extensions class.

public static void Raise(this PropertyChangedEventHandler handler, params Expression<Func<object>>[] proppertyExpressions)
{
    foreach (var expression in proppertyExpressions)
        Raise(handler, expression);
}

Aside from beeing type safe, this method will give you intellisense support while you type your “RaiePropertyChanged” calls. You still have to type the right property though.

Wednesday, July 22, 2009

How to use INotifyPropertyChanged, the type-safe way (no magic string)

Implementation of the INotifyPropertyChanged interface is quite simple. There is only one event to implement. Take for example the following simple model class:

public class Model : INotifyPropertyChanged
{
    private string _data;

    public string Data
    {
        get { return _data; }
        set
        {
            if (_data == value)
                return;

            _data = value;

            // Type un-safe PropertyChanged raise 
            PropertyChanged(this, new PropertyChangedEventArgs("Data"));
        }
    }

    #region Implementation of INotifyPropertyChanged

    public event PropertyChangedEventHandler PropertyChanged = null;

    #endregion
}

This is a pretty standard way to implement a bindable property. The problem here is the “Data” string to specify which property changed. If someone change the name of the property without changing the content of the string, the code will compile fine but won’t work. In a big application with may properties it can be hard to detect and find the problem.

The best solution is to rely on the compiler to warn us. But because the property name is a string it can’t. So let’s change that line with a type-safe one.

public class Model : INotifyPropertyChanged
{
    private string _data;

    public string Data
    {
        get { return _data; }
        set
        {
            if (_data == value)
                return;

            _data = value;

            // Type safe PropertyChanged raise
            PropertyChanged.Raise(() => Data);
        }
    }

    #region Implementation of INotifyPropertyChanged

    public event PropertyChangedEventHandler PropertyChanged = null;

    #endregion
}

What is the trick? Raise is an extension method that takes a lambda expression to specify the name of the property in a type safe way. The Raise method resolve this expression to extract the name of the property and pass it to the PropertyChanged event.

public static class PropertyChangedExtensions
{
    public static void Raise(this PropertyChangedEventHandler handler, Expression<Func<object>> propertyExpression)
    {
        if (handler != null)
        {
            // Retreive lambda body
            var body = propertyExpression.Body as MemberExpression;
            if (body == null)
                throw new ArgumentException("'propertyExpression' should be a member expression");

            // Extract the right part (after "=>")
            var vmExpression = body.Expression as ConstantExpression;
            if (vmExpression == null)
                throw new ArgumentException("'propertyExpression' body should be a constant expression");

            // Create a reference to the calling object to pass it as the sender
            LambdaExpression vmlambda = Expression.Lambda(vmExpression);
            Delegate vmFunc = vmlambda.Compile();
            object vm = vmFunc.DynamicInvoke();

            // Extract the name of the property to raise a change on
            string propertyName = body.Member.Name;
            var e = new PropertyChangedEventArgs(propertyName);
            handler(vm, e);
        }
    }
}

All you have to do is to put this extension method in your code and the jib is done. Of course at the end a string will be used to raise the PropertyChanged event but because you don’t have to type it, you don’t have to maintain it.

Tuesday, June 2, 2009

How to implement “lock” with timeout?

Anybody who did any multithreaded application probably used the “lock” keyword. This is actually a good thing.

“lock” is the most optimized way to lock a resource. First let’s take a look at what lock really do. Here is the simple Account class we will use for this post.

using System.Threading;

namespace Banking
{
    public class Account
    {
        private readonly string _accountNumber;
        private double _balance;

        private Account(string accountNumber, double amount)
        {
            _accountNumber = accountNumber;
            Balance = amount;
        }

        public string AccountNumber
        {
            get { return _accountNumber; }
        }

        public double Balance
        {
            get { return _balance; }
            set { _balance = value; }
        }

        public static Account OpenNew(string accountNumber, double amount)
        {
            return new Account(accountNumber, amount);
        }

        public void Deposit(double amount)
        {
            Interlocked.Exchange(ref _balance, _balance + amount);
        }

        public void Withdraw(double amount)
        {
            Interlocked.Exchange(ref _balance, _balance - amount);
        }

        public static void Transfer(double amount, Account fromAccount, Account toAccount)
        {
            // Bad code here. Potential deadlock.
            lock (fromAccount)
            lock (toAccount)
            {
                fromAccount.Withdraw(amount);
                toAccount.Deposit(amount);
            }
        }

        public override string ToString()
        {
            return string.Format("{0} (Balance = {1})", _accountNumber, _balance);
        }
    }
}

Here are some important things to point out about this class:

  • The constructor is private to limit the creators of this class.
  • The public OpenNew method is the only way to create an instance. This ensure that every Account starts with a name and a balance.
  • Deposit and Withdraw methods are thread safe. They both uses Interlocked class which is has low level methods to modify values.
  • Transfer is not thread safe even though it uses locks. There is a potential deadlock if two thread transfer funds using the same accounts at the same time.

Most of the time the transfer method will work without any problem but the is a slight chance of deadlock. Of course this is a fairly simple method and in fact we can use another private object field to lock on like in this sample.

private static object _syncLock = new object();

public static void Transfer(double amount, Account fromAccount, Account toAccount)
{
    // Bad code here. Potential deadlock.
    lock (_syncLock)
    {
        fromAccount.Withdraw(amount);
        toAccount.Deposit(amount);
    }
}

That mean you will need to use that _syncLock object all the time to be consistent, even if you need to lock only one of the two accounts. And because Transfer is a static method we need to make the _syncLock object static too. That mean that any other call to Transfer will have to wait until this call finish. That is a huge performance issue.

What we really need is to be able to lock actual Account objects and recover from any deadlock. The best way to do this is to use timeouts on the locking process. The caller can catch timeouts and handle it properly instead of waiting forever. Here is a better Transfer method.

public static void Transfer(double amount, Account fromAccount, Account toAccount)
{
    bool fromLock = Monitor.TryEnter(fromAccount, 1000);
    bool toLock = Monitor.TryEnter(toAccount, 1000);
    try
    {
        if (fromLock && toLock)
        {
            fromAccount.Withdraw(amount);
            toAccount.Deposit(amount);
        }
    }
    finally
    {
        if (fromLock)
            Monitor.Exit(fromLock);

        if (toLock)
            Monitor.Exit(toLock);
    }
}

This is a lot more code to write. Actually this is not far from what the lock keyword would do. Because if you look at your code with Reflector you will see that lock does translate to Monitor.Enter and Monitor.Exit (your have to look in IL not in C#). So a simple lock statement like this.

lock(obj)
{
    // do somtehing
    Console.WriteLine("Locked");
}

Would be translated to.

Monitor.Enter(obj);
try
{
    // do somtehing
    Console.WriteLine("Locked");
}
finally
{
    Monitor.Exit(obj);
}

You won’t see it in C# (with Reflector) but if you look at IL code you will see exactly the same sequence twice.

So to solve our problem, would it be nice to have something like this?

public static void Transfer(double amount, Account fromAccount, Account toAccount)
{
    Safe.Lock(new [] {fromAccount, toAccount}, 1000, () =>
    {
        fromAccount.Withdraw(amount);
        toAccount.Deposit(amount);
    });
}

This look pretty much like the well known lock keyword, isn’t it? Now how can we do this? That’s better. The Safe static call has a Lock static method that take care of everything. The fist argument can be a single object or an array of objects. This allow locking multiple object at once. The Lock method use the Monitor.TryEnter to acquire lock on objects. If this can be done before the timeout occur the Action argument is executed.

Of course this code can and should be surrounded with a try-catch block. here is how to do so.

public static void Transfer(double amount, Account fromAccount, Account toAccount)
{
    var retries = 10;

    while (retries-- > 0)
    {
        try
        {
            Safe.Lock(new[] { fromAccount, toAccount }, 1000, () =>
            {
                fromAccount.Withdraw(amount);
                toAccount.Deposit(amount);
            });
            break;
        }
        catch (TimeoutException e)
        {
            if (retries == 0)
                throw;
            Thread.Sleep(100);
        }
    }
}

In this code snippet it will retry at most 10 time to lock toAccount and fromAccount before giving up. Notice that only the TimeoutException is handled, so any other exception will be thrown immediately and stop the process. The break at the end of the try block let us out as soon as it works.

This is a good timeout pattern and easy to implement in your own code. Give it a try and let me know if it works.

Here is the full code for the Safe class.

using System;
using System.Linq;
using System.Threading;

namespace MultithreadHelper
{
    public class Safe : IDisposable
    {
        private readonly object[] _padlocks;
        private readonly bool[] _securedFlags;

        private Safe(object padlock, int milliSecondTimeout)
        {
            _padlocks = new[] {padlock};
            _securedFlags = new[] {Monitor.TryEnter(padlock, milliSecondTimeout)};
        }

        private Safe(object[] padlocks, int milliSecondTimeout)
        {
            _padlocks = padlocks;
            _securedFlags = new bool[_padlocks.Length];
            for (int i = 0; i < _padlocks.Length; i++)
                _securedFlags[i] = Monitor.TryEnter(padlocks[i], milliSecondTimeout);
        }

        public bool Secured
        {
            get { return _securedFlags.All(s => s); }
        }

        public static void Lock(object[] padlocks, int millisecondTimeout, Action codeToRun)
        {
            using (var bolt = new Safe(padlocks, millisecondTimeout))
                if (bolt.Secured)
                    codeToRun();
                else
                    throw new TimeoutException(string.Format("Safe.Lock wasn't able to acquire a lock in {0}ms",
                                                             millisecondTimeout));
        }

        public static void Lock(object padlock, int millisecondTimeout, Action codeToRun)
        {
            using (var bolt = new Safe(padlock, millisecondTimeout))
                if (bolt.Secured)
                    codeToRun();
                else
                    throw new TimeoutException(string.Format("Safe.Lock wasn't able to acquire a lock in {0}ms",
                                                             millisecondTimeout));
        }

        #region Implementation of IDisposable

        public void Dispose()
        {
            for (int i = 0; i < _securedFlags.Length; i++)
                if (_securedFlags[i])
                {
                    Monitor.Exit(_padlocks[i]);
                    _securedFlags[i] = false;
                }
        }

        #endregion
    }
}

Wednesday, May 13, 2009

How to test your multi-threaded code (part 3 of 3)?

In the last post we learned how to find and fix a simple multi-thread problem. Now we will see a more complex scenario and see how CHESS wil find the solution.

To do that we will add a ne method to our Account type.

public static void Transfer(double amount, Account fromAccount, Account toAccount)
{
    lock (fromAccount)
    {
        lock(toAccount)
        {
            fromAccount.Withdraw(amount);
            toAccount.Deposit(amount);
        }
    }
}

Because we want to be sure that the transfer works we lock both the “from” and the “to” account.

Now we can easily wrtie this test to see that this is working fine in signle threaded scenario.

[TestMethod]
public void TransferTest()
{
    Account a1 = Account.OpenNew(10000);
    Account a2 = Account.OpenNew(10000);

    Account.Transfer(100, a1, a2);
    Account.Transfer(100, a2, a1);

    Assert.AreEqual(10000, a1.Balance);
    Assert.AreEqual(10000, a2.Balance);
}

As we did before we will convert this single-thread method to a multi-thread one.

[TestMethod]
[HostType("Chess")]
public void TransferMultiThreadTest()
{
    Account a1 = Account.OpenNew(10000);
    Account a2 = Account.OpenNew(10000);

    Thread thread = 
new Thread(o => Account.Transfer(100, ((Account[]) o)[0], ((Account[]) o)[1])); thread.Start(new[] {a1, a2}); Account.Transfer(100, a2, a1); thread.Join(); Assert.AreEqual(10000, a1.Balance); Assert.AreEqual(10000, a2.Balance); }

Now if we run this CHESS will detect a deadlock scenario. If you’ve done some SQL queries you know you should always try to lock all your resources always in the same order. But why doesn’t it working here. We have only one method that lock resources they should be locked in the same order every time, and that’s true. The deadlock occurs because in some cases a thread start to lock the fromAccount (or maybe the toAccount too) and get interrupt by another thread trying to do the same. Then both thread are waiting for each other to complete. Databases engine use timeouts to get out of these situation, but the lock keyword doesn’t support timeout, eventough it uses Monitor.Enter which support it. In another post I will show you how to build your own lock implementation that support timeout, but now we need to find a way to make our code thread safe.

We have to go back to our account class and do some changes.

public static object _locObject = new object();

public static void Transfer(double amount, Account fromAccount, Account toAccount)
{
    lock (_locObject)
    {
        fromAccount.Withdraw(amount);
        toAccount.Deposit(amount);
    }
}

We have to create a static lock object we can use to lock on. Because we are doing the lock in one signle operation our test will now run without any problem.

This is only a small overview of what CHESS can do.

Monday, May 11, 2009

How to test your multi-threaded code (part 2 of 3)?

Previously we saw how to build a test to find a multi-thread bug our your code. Now we will look at how to reproduce debug and fix it.

Remember our bank account class:

public class Account
{
   public double Balance { get; set; }

   private Account(double amount)
   {
       Balance = amount;
   }

   public static Account OpenNew(double amount)
   {
       return new Account(amount);
   }

   public void Deposit(double amount)
   {
       double tempAmount = Balance;
       // potential problem
       lock (this)
       {
           Balance = tempAmount + amount;
       }
   }

   public void Withdraw(double amount)
   {
       double tempAmount = Balance;
       // potential problem
       lock (this)
       {
           Balance = tempAmount - amount;
       }
   }
}

And our test:

[TestMethod()]
[HostType("Chess")]
public void BalanceMutiThreadTest()
{
   Account account = Account.OpenNew(10000);

   Thread thread = new Thread(a => ((Account) a).Withdraw(100));
   thread.Start(account);
   account.Deposit(100);
   thread.Join();

   Assert.AreEqual(10000, account.Balance);
}

Now if we look carefully at the test result detail, there is an explanation on how to reproduce this particular schedule. All you have to do is to copy/paste the code provided just before your test method call.

[TestMethod()]
[HostType("Chess")]
[TestProperty("ChessMode", "Repro")]
[TestProperty("ChessBreak", "BeforePreemption")]
#region ChessScheduleString (not human readable)
[TestProperty("ChessScheduleString", @"bpilaiaaaaaaaaaaaeaaonlnahgabmejjgcfcgcpgnmkhlhpekpfeknhoahekbaiiagabdcenijaeabaommbiimnogjcombngjehcdcjklckibmkgffggffnggbgeammonjnlmphnohloplnphnohloplnphlkdljneochphnpppdpfmgggeabgmpgmoeknkmjjocbiakkmibpdphohmbpdpcchomnfpodnhpidfpappfpfhhpponplpkgpmdelpppbgpkplkpoflfmbopdpkgdppbppfpephpocllfpedhppkopjkppjlohpppohpaaldcaoojfhfaaaaaa")]
#endregion
public void BalanceMutiThreadTest()
{
   Account account = Account.OpenNew(10000);

   Thread thread = new Thread(a => ((Account) a).Withdraw(100));
   thread.Start(account);
   account.Deposit(100);
   thread.Join();

   Assert.AreEqual(10000, account.Balance);
}

(your code may be different)

With that code in place if you run your test again (without the debugger) you will see that only one schedule was evaluated and you got the same result as the previous test. From there, as a tester, you job is done. You check in the code and hand it to the development team. If you are a member of a small team, as I usually am, you may be the tester and the developer so you’ll have to debug the code yourself.

Now run this test again but this time with the debugger. The execution should stop just before one of the lock statement. If you step once you will be able to inspect tempAmount and Balance values and see the problem. Between the line where the debugger stop and the previous line another thread changed the Balance value. Now you can see the don’t match.

Of course in this case the solution is easy, we just have to put the tempAmount assignation inside of the lock block but in the next post you will see a case where the solution is not so obvious.

Tuesday, May 5, 2009

How to test your multi-threaded code (part 1 of 3)?

CHESS is the answer. At least this is what we have best right now.

In multi-threaded application, bug are hard to almost impossible to find. For the last years the only true way to detect threading problems was to run load test until the system crash. Once it does, every once in thousands of iterations, the tools to reproduce and debug the problem were inexistent.

The RiSE (Research in Software Engineering) team at Microsoft have been working for a long time on a product called CHESS. When run with CHESS, you unit tests will try every possible combination of thread interleave to find a case where you application crash or worst doesn’t give you the result you expect.

Here is a simple demo to show you the power of CHESS. Let’s start with a banking account management system.

public class Account
{
    public double Balance { get; set; }

    private Account(double amount)
    {
        Balance = amount;
    }

    public static Account OpenNew(double amount)
    {
        return new Account(amount);
    }

    public void Deposit(double amount)
    {
        double tempAmount = Balance;
        // potential problem
        lock (this)
        {
            Balance = tempAmount + amount;
        }
    }

    public void Withdraw(double amount)
    {
        double tempAmount = Balance;
        // potential problem
        lock(this)
        {
            Balance = tempAmount - amount;
        }
    }
}

Of course I voluntarily introduce “potential problems” to show how CHESS will get them. With that class you can write this test:

[TestMethod()]
public void BalanceTest()
{
    Account account = Account.OpenNew(10000);

    account.Withdraw(100);
    account.Deposit(100);

    Assert.AreEqual(10000, account.Balance);
}

This will always run fine as it is single threaded. Now what if we change it a little to make it multi-threaded:

[TestMethod()]
public void BalanceMutiThreadTest()
{
    Account account = Account.OpenNew(10000);

    Thread thread = new Thread(a => ((Account) a).Withdraw(100));
    thread.Start(account);
    account.Deposit(100);
    thread.Join();

    Assert.AreEqual(10000, account.Balance);
}

As you can see here we put the withdraw part in a new thread. But even then we can run this test again and again without any problem. You can put it in a loop if you want and never being able to make it return an invalid balance.

Once you have CHESS installed on your system the only thing you have to do is to add a HostType attribute to your method.

[TestMethod()]
[HostType("Chess")]
public void BalanceMutiThreadTest()
{
    Account account = Account.OpenNew(10000);

    Thread thread = new Thread(a => ((Account) a).Withdraw(100));
    thread.Start(account);
    account.Deposit(100);
    thread.Join();

    Assert.AreEqual(10000, account.Balance);
}

Now when you run this test you should get something like:

Assert.AreEqual failed. Expected:<10000>. Actual:<10100>.

You should also have noticed that it took a little longer to run the test. This is because the CHESS host scans your code to build an execution schedule for every possible thread interleave that CHESS can detect. If you double click on the test result you will see how many schedules that were tried before finding the bug, in my case it is 3.

Next time we will see how to reproduce and debug that code.

Wednesday, March 25, 2009

Good practice to use Dispatcher in WPF background thread

Here is a good way to use extension method in a multi threaded context. Everybody knows that when you try to update UI from any other thread than the UI you get an “InvalidOperationException” with message “The calling thread cannot access this object because a different thread owns it.”. Look at the following sample:

Let say somewhere in your code you have this

private void Button_Click(object sender, RoutedEventArgs e)
{
    // ...
    ThreadPool.QueueUserWorkItem(DoWork, this);
    // ...
}

If you implement DoWork Like this…

private static void DoWork(object state)
{
    Window1 win = (Window1) state;
    for (int i = 0; i < 100; i++)
    {
        // do some work
        win.progress1.Value = i;
    }
    win.progress1.Value = 100;
}

…you will be in trouble.

Because you can’t update UI from a thread other than the UI one you will get the InvalidOperationException as stated before.

The solution is to use the Dispatcher object. As from microsoft documentation:

Only the thread that the Dispatcher was created on may access the DispatcherObject directly. To access a DispatcherObject from a thread other than the thread theDispatcherObject was created on, call Invoke or BeginInvoke on the Dispatcher the DispatcherObject is associated with.

Subclasses of DispatcherObject that need to enforce thread safety can do so by calling VerifyAccess on all public methods. This guarantees the calling thread is the thread that theDispatcherObject was created on.

So our previous sample should look like this:

private static void DoWork(object state)
{
    Window1 win = (Window1) state;
    for (int i = 0; i < 100; i++)
    {
        // do some work
        win.Dispatcher.Invoke(new Action<ProgressBar, int>((p, v) => p.Value = v), win.progress1, i);
    }
    win.Dispatcher.Invoke(new Action<ProgressBar>(p => p.Value = 100), win.progress1);
}

This is a little more work but not it works. Because we don’t want to call the Dispatcher object when it’s not needed we sould do this:

private static void DoWork(object state)
{
    Window1 win = (Window1) state;
    for (int i = 0; i < 100; i++)
    {
        // do some work
        if (win.Dispatcher.CheckAccess())
            // We can call on the current thread
            win.progress1.Value = i;
        else
            // we need to call Invoke
            win.Dispatcher.Invoke(new Action<ProgressBar, int>((p, v) => p.Value = v), win.progress1, i);
    }

    if (win.Dispatcher.CheckAccess())
        // We can call on the current thread
        win.progress1.Value = 100;
    else
        // we need to call Invoke
        win.Dispatcher.Invoke(new Action<ProgressBar>(p => p.Value = 100), win.progress1);
}

Ouch! This is a lot more work. We cannot do that every time. That’s when extensions method comes handy. We can replace this whole process of choosing the right implementation with a single extension method. It will make our code more readable and more managable.

He is the whole extension class with all possible overload for a method called Dispatch. This method will dispatch the process only if needed:

public static class DispatcherExtensions
{
    public static TResult Dispatch<TResult>(this DispatcherObject source, Func<TResult> func)
    {
        if (source.Dispatcher.CheckAccess())
            return func();

        return (TResult) source.Dispatcher.Invoke(func);
    }

    public static TResult Dispatch<T, TResult>(this T source, Func<T, TResult> func) where T : DispatcherObject
    {
        if (source.Dispatcher.CheckAccess())
            return func(source);

        return (TResult)source.Dispatcher.Invoke(func, source);
    }

    public static TResult Dispatch<TSource, T, TResult>(this TSource source, Func<TSource, T, TResult> func, T param1) where TSource : DispatcherObject
    {
        if (source.Dispatcher.CheckAccess())
            return func(source, param1);

        return (TResult)source.Dispatcher.Invoke(func, source, param1);
    }

    public static TResult Dispatch<TSource, T1, T2, TResult>(this TSource source, Func<TSource, T1, T2, TResult> func, T1 param1, T2 param2) where TSource : DispatcherObject
    {
        if (source.Dispatcher.CheckAccess())
            return func(source, param1, param2);

        return (TResult)source.Dispatcher.Invoke(func, source, param1, param2);
    }

    public static TResult Dispatch<TSource, T1, T2, T3, TResult>(this TSource source, Func<TSource, T1, T2, T3, TResult> func, T1 param1, T2 param2, T3 param3) where TSource : DispatcherObject
    {
        if (source.Dispatcher.CheckAccess())
            return func(source, param1, param2, param3);

        return (TResult)source.Dispatcher.Invoke(func, source, param1, param2, param3);
    }

    public static void Dispatch(this DispatcherObject source, Action func)
    {
        if (source.Dispatcher.CheckAccess())
            func();
        else
            source.Dispatcher.Invoke(func);
    }

    public static void Dispatch<TSource>(this TSource source, Action<TSource> func) where TSource : DispatcherObject
    {
        if (source.Dispatcher.CheckAccess())
            func(source);
        else
            source.Dispatcher.Invoke(func, source);
    }

    public static void Dispatch<TSource, T1>(this TSource source, Action<TSource, T1> func, T1 param1) where TSource : DispatcherObject
    {
        if (source.Dispatcher.CheckAccess())
            func(source, param1);
        else
            source.Dispatcher.Invoke(func, source, param1);
    }

    public static void Dispatch<TSource, T1, T2>(this TSource source, Action<TSource, T1, T2> func, T1 param1, T2 param2) where TSource : DispatcherObject
    {
        if (source.Dispatcher.CheckAccess())
            func(source, param1, param2);
        else
            source.Dispatcher.Invoke(func, source, param1, param2);
    }

    public static void Dispatch<TSource, T1, T2, T3>(this TSource source, Action<TSource, T1, T2, T3> func,
                                                     T1 param1, T2 param2, T3 param3) where TSource : DispatcherObject
    {
        if (source.Dispatcher.CheckAccess())
            func(source, param1, param2, param3);
        else
            source.Dispatcher.Invoke(func, source, param1, param2, param3);
    }
}

That seems a lot of code to write but see how it simplifies the code when you use it:

private static void DoWork(object state)
{
    Window1 win = (Window1) state;
    for (int i = 0; i < 100; i++)
    {
        // do some work
        win.progress1.Dispatch((p, v) => p.Value = v, i);
    }

    win.progress1.Dispatch(p => p.Value = 100);
}

This is almost as simple as our first implementation of DoWork. The only difference is in this version we call “Dispatch” with a lambda expression that will always be run on the UI thread.

Let me know if you find this helpful or if you think of something better.

Monday, February 23, 2009

Extension methods series: Extension points

As mentioned earlier (the basics, managing the scope, use interfaces) it is important to manage the scope of your extension methods. One other way to do that is to use extension point concept. An extension point is itself an extension method which is only purpose is to transform your object into another type on which you have define plenty of extensions.

The following sample comes from an open source project called Umbrella.

Let’s first try to wrap this concept into an interface:

public interface IExtensionPoint
{
  object ExtendedValue { get; }
  Type ExtendedType { get; }
}

This interface define the basis of an extension point. “ExtendedValue” will hold the source object reference and “ExtendedType” the type of the extended object. Now here is it generic base implementation:

public class ExtensionPoint<T> : IExtensionPoint<T>
{
  private readonly Type type;
  private readonly T value;

  public ExtensionPoint(T value)
  {
      this.value = value;
  }

  public ExtensionPoint(Type type)
  {
      this.type = type;
  }

  #region IExtensionPoint<T> Members

  public T ExtendedValue
  {
      get { return value; }
  }

  object IExtensionPoint.ExtendedValue
  {
      get { return value; }
  }

  public Type ExtendedType
  {
      get { return type ?? (value == null ? typeof (T) : value.GetType()); }
  }

  #endregion
}

This generic class will be used as a base class for all extension points. It contains all the logic to store the value and some read-only properties to get information about it.

Let’s say we want to build some xml serialization extensions, we can start by creating our xml serialization extension point:

public class SerializationExtensionPoint<T> : ExtensionPoint<T>
{
  public SerializationExtensionPoint(T value)
      : base(value)
  {
  }

  public SerializationExtensionPoint(Type type)
      : base(type)
  {
  }
}

Like I said earlier, this class doesn’t do a lot. It’s purpose is only to convert an extension point of T into a serialization extension point of T. To use this we must have a converter extension method in scope:

public static class SerializationExtensions
{
  public static SerializationExtensionPoint<T> Serialize<T>(this T value)
  {
      return new SerializationExtensionPoint<T>(value);
  }
}

The “Serialization” extension method is called to get access to all other serialization extension methods.

Somewhere in you code you will have this method. This method can be applied to any type because it takes T as a source. The last step is to define an extension method on SerializationExtensionPoint:

public static string ToXml<T>(this SerializationExtensionPoint<T> extensionPoint)
{
  using (var stream = new MemoryStream())
  {
      Xml(extensionPoint, stream, extensionPoint.ExtendedValue);

      stream.Position = 0;
      StreamReader reader = new StreamReader(stream);

      return reader.ReadToEnd();
  }
}

This method will convert any object into XML. Look how easy it is to read this: “source serialize to xml”.

var source = new List<string>();
source.Add("Test1");
source.Add("Test2");
source.Add("Test3");
var xml = source.Serialize().ToXml();

You will get:

<?xml version="1.0" ?>
<ArrayOfString xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<string>Test1</string>
<string>Test2</string>
<string>Test3</string>
</ArrayOfString>

Like any API development, one good practice to follow is to start by writing how you will use it. For example, in the last sample we could have started by writing “source.Serialize().ToXml();” and then start implementing the whole thing to make it work. The result of this is improved readability and reusability. Two things that helps a lot when someone else (or even you) have to modify your code later.

Tuesday, February 17, 2009

Extension methods series: the basics

One the new thing in C# is extension methods. Extension methods are static method that works pretty much like an helper function but instead of passing the instance to act on as an argument the instance is a prefix to the method. It looks exactly like if the method is part of the type itself.

Of course because C# is a statically typed language we are not really adding new method to a type. Here is the trick. The following example is a classic case of helper function:

if (String.IsNullOrEmpty(instance))
{
	// ...
}

The method “IsNullOrEmpty” is static a member of type “String”. To use it we must call it by its type and then pass it an instance of that type. Here is an easy way transform this helper function into an extension method.

public static class StringExtensions
{
	public static bool IsNullOrEmpty(this string instance)
	{
	    return String.IsNullOrEmpty(instance);
	}	
}

One of the requirement to make extension methods is the class must be static. Notice the “this” keyword used on the first argument of the method. This tell the compiler which type this method is extending and what type it should be.

Now if we use this code it will look like this:

if (instance.IsNullOrEmpty())
{
	// ...
}

At compile time the condition will be replaced by “StringExtension.IsNullOrEmpty(instance)”. So extension method is just a compiler trick to facilitate the uses of helper function. Beside the fact that it is easier to use it is also more readable. That is the starting point to fluent interfaces.

Wednesday, February 11, 2009

Why ++ operator is not thread safe

Here is a quick hint on how to make your software thread safe. If you want to increment a member of your class you would probably do something like this:

public void NotSafe()
{
    val++;
}

Where val is a member of your class.But this is not thread safe. Doing this involve 4 operations:

  1. Loading the field and put it on the stack
  2. Putting 1 on the stack to increment by 1
  3. Calling add on the stack
  4. Storing the result in the field

Here is the corresponding IL:

.method public hidebysig instance void NotSafe() cil managed
{
    .maxstack 8
    L_0000: nop
    L_0001: ldarg.0
    L_0002: dup
    L_0003: ldfld int32 ClassLibrary1.Class1::val
    L_0008: ldc.i4.1
    L_0009: add
    L_000a: stfld int32 ClassLibrary1.Class1::val
    L_000f: ret
}

The problem is that anywhere between any of the 4 steps another thread can try to do the same thing. For example if a second thread pup in just after the first one is between step 1 and 2 they will both try to increment the same value and store it on the stack. To resolve this problem you can use a lock like this:

public void SafeLock()
{
    lock (valLock)
    {
        val++;
    }
}

But this will generate the following IL:

.method public hidebysig instance void SafeLock() cil managed
{
    .maxstack 3
    .locals init (
        [0] object CS$2$0000)
    L_0000: nop
    L_0001: ldarg.0
    L_0002: ldfld object ClassLibrary1.Class1::valLock
    L_0007: dup
    L_0008: stloc.0
    L_0009: call void [mscorlib]System.Threading.Monitor::Enter(object)
    L_000e: nop
    L_000f: nop
    L_0010: ldarg.0
    L_0011: dup
    L_0012: ldfld int32 ClassLibrary1.Class1::val
    L_0017: ldc.i4.1
    L_0018: add
    L_0019: stfld int32 ClassLibrary1.Class1::val
    L_001e: nop
    L_001f: leave.s L_0029
    L_0021: ldloc.0
    L_0022: call void [mscorlib]System.Threading.Monitor::Exit(object)
    L_0027: nop
    L_0028: endfinally
    L_0029: nop
    L_002a: ret
    .try L_000f to L_0021 finally handler L_0021 to L_0029
}

As you can see there is a lot more code involve to ensure thread safety, A quicker, faster an easier way to do this s to use Interlocked class. This class will use low level OS call to modify the member. Here’s how to use it:

public void Safe()
{
    Interlocked.Increment(ref val);
}

This will be render as two major IL steps:

  1. Load value from the field and put it on the stack
  2. Call Increment

Here is the IL representation of this:

.method public hidebysig instance void Safe() cil managed
{
    .maxstack 8
    L_0000: nop
    L_0001: ldarg.0
    L_0002: ldflda int32 ClassLibrary1.Class1::val
    L_0007: call int32 [mscorlib]System.Threading.Interlocked::Increment(int32&)
    L_000c: pop
    L_000d: ret
}

Now every time you will see something++ you will know that this is not thread safe and how to fix it.

Saturday, February 7, 2009

XML Serialization Tip: Hiding default constructor

Here is a quick tip. You all know that to serialize and deserialize an object in XML you need a default (parameter less) constructor. But sometimes you don’t want anybody to use it other than the serializer itself.

By making the default constructor obsolete you can make sure no code will directly call it.

public class MyClass
{
	[Obsolete("For XML Serialization Only", true)]
	public MyClass()
	{
		// Needed for XML serailisation
	}

	public MyClass(string initialValue)
	{
		// ...
	}

	// ...
}

Don’t forget to specify true as the second argument to the Obsolete attribute. This will raise a compilation error if this constructor is called directly. I insist on “directly” because nothing will prevent someone to use reflection to call it. XML Serialisation can occur because it uses reflection to do it.

Thursday, January 15, 2009

Managed Parallel Computing with Parallel Extensions

Full Listing

In my last post I told you about how I like to do talks about my passion. One of the subject I,m interested in at the moment is managed parallel computing, especially with what is coming from Microsoft Research: Parallel Extensions.

Parallel Extension is a new framework that will help us build software that can harvest all the power of a multi-core system without all the complexity of managing thread ourselves. I’m also presenting a lot on this subject, so if you are a member of a local user group I will be pleased to get invited.

What exactly is parallel extension. Like it says, it’s an extension. Actually it’s a replacement of the System.Threading library that add a lot of new types to deal with parallelism. By now, you should be aware of the existence of the thread pool class in the framework. But building multi-threaded application with that requires you to handle all the threads you create yourself. Of course the thread pool will make it easy to create threads, but the first question you have to ask is: how many threads do I need? The answer depend on many things. First, what are you trying to do? Are you just trying to use your idle CPU to some background processing or are your trying to complete an intensive process as fast as possible? How many available core do you have? Is it the only application that need processor power at the moment? The beauty of the Parallel Extensions framework is that it turn those those questions to be almost obsolete.

The power of that framework lives in it task scheduler. Wait! We are talking about Task now! What about thread? Yes, Parallel Extensions adds another layer of abstraction to resolve the problem. Isn’t that always what we do. That Task layer is very convenient. Now we don’t have to bother anymore about thread we just have to break our process into tasks. To put it simply, a task should be the smallest unit of work that can run independent of others.

I know how must you like to see code so here is a little sample for you.

internal class Program
{
    private static void Main(string[] args)
    {
        Tree tree = Tree.Create();
        int sum = tree.Sum();
		Console.WriteLine("Sum is {0}", sum);
    }
}

This is the main code to calculate the sum of a binary tree. Of course we have to implement the Sum method.

    public int Sum()
    {
        int left = SumLeft();
        int right = SumRight();

        return Value + left + right;
    }

The Sum method call two internal function to do the job. It gets the sum of the left part and add it to the sum of the right part. In this sample, we have to wait for the whole calculation of the left part before starting to calculate the right one. This tree can be deep, so SumLeft may take time to process. On a single core system you will have to do it sequentially. But if you have a multi core system you can do at least to calculation at the same time. What if later you move your program to a 16 cores system. With thread you would have to know how may cores are available and then start creating just enough thread to do the processing. Too little, you will waste valuable CPU time, too many you will take too much memory because every managed thread takes 1 Meg of memory. Parallel Extension framework will automatically use all available cores to do the job without interfering with the rest of the system. By default two thread per core will be created with an average priority. Of course you have full control those over those defaults by creating your own TaskManagerPolicy, but we will see that in another post.

Take a look at how to parallelize this task.

public int ParallelSum1()
{
    int left = 0;
    int right = 0;

    Task[] tasks = new Task[]
    {
        Task.Create(x => left = Left.Sum()),
        Task.Create(x => right = Right.Sum())
    };

    Task.WaitAll(tasks);
    return Value + left + right;
}

This is how you could do it with a simple task structure, but this code smells. The problem is that left and right variables are define outside of the scope of the task structure. Let see how to do it better and why.

public int ParallelSum2()
{
    Future<int> futureLeft = Future<int>.Create(() => Left == null ? 0 : Left.Sum());
    Future<int> futureRight = Future<int>.Create(() => Right == null ? 0 : Right.Sum());
    return Value + futureLeft.Value + futureRight.Value;
}

In this snippet futureLeft and futureRight are tasks that will be potentially evaluated on another thread if there is some resource available. If not they will be executed on the current thread when we ask for their Value property. With this method we will use only two cores even though we may have more in the future. But if we try to replace Sum() by ParalaleSum2() on line 3 and 4, it will not work properly. We will end up creating way too many task and it will run slower that the sequential version. Here is a solution to get the scalability we need.

public int ParallelSum3()
{
    Future<int> futureLeft = Future<int>.Create(() => Left == null ? 0 : Left.ParallelSum3());
    int futureRight = Right == null ? 0 : Right.Sum();
    return Value + futureLeft.Value + futureRight;
}

This time we only compute one path of the tree in parallel the other one will be calculated sequentially.

In conclusion even if we have more tools to build our software to do work in parallel, it is not always easy to get it right.

Inspiration comes from Daniel Moth.
http://www.danielmoth.com/Blog/2008/12/introducing-new-task-type.html
http://channel9.msdn.com/pdc2008/TL26/

Friday, September 12, 2008

Presenting @ DevTeach

If you needed one more reason to register for DevTeach here it is. I'm giving a talk about parallel extensions. Here is the teaser:
A glimpse into the parallel universe
There is no more free lunch! The Moore's law is over. If we want more power we need to cross the processor barrier and do work in parallel. In June 2008, Microsoft released its second CTP of Parallel Extensions library. Come with me to see how easy it will be to make that leap of faith into the world of parallel processing. We will see how Task, concurrent collections, lazy initialization, parallel Linq and other tools can help us in this endeavour.