A Look on the Code: 2011

Saturday, December 31, 2011

Serializing Primitive Types to Byte Array–Analysis

Hi All,

Today I am going to consider the following case: You want to transmit a class over some sort of a protocol and of course you want to minimize the serialization size and maximize the serialization speed of your class. Since every class is essentially a set of primitive types we can simply consider the cost of serializing these primitive types to simple byte arrays (buffers) which can be sent over some medium.

My wife did an extensive research on this case at work and eventually came down with two possible methods (I am summarizing her work as there were many possible solutions to this case)

Method 1 – Using List<byte>

 public static byte[] GetBytes()  
{                                        
  List<byte> result = new List<byte>(400000);  
  for (int i = 0; i < 100000; i++)  
    result.AddRange(BitConverter.GetBytes(i));  
  
  return result.ToArray();  
} 

Method 2 – Using MemoryStream

 public static byte[] GetBytes()  
{  
  using (MemoryStream ms = new MemoryStream(400000))  
  {  
    using (BinaryWriter writer = new BinaryWriter(ms))  
    {  
    for (int i = 0; i < 100000; i++)  
      writer.Write(i);  
    }  
    return ms.GetBuffer();  
  }  
  
} 

At first glance these two methods should not differ by much. Perhaps Method 1 should be a bit slower but here are the results of this run:

 Stopwatch sw = new Stopwatch();  
sw.Start();  
byte[] result = ArrayFormatter.GetBytes();  
sw.Stop();  
Console.WriteLine(string.Format("ArrayFormatter time = {0} value = {1} length = {2}",sw.ElapsedMilliseconds,result[12],result.Length));  
            
sw.Reset();  
  
sw.Start();  
result = MemoryStreamFormatter.GetBytes();  
sw.Stop();  
Console.WriteLine(string.Format("MemoryStreamFormatter time = {0} value = {1} length = {2}",sw.ElapsedMilliseconds,result[12],result.Length)); 

ArrayFormatter time = 3439 value = 3 length = 400000
MemoryStreamFormatter time = 343 value = 3 length = 400000

Method 1 is ten times slower than Method 2. When my wife told me about this result I said she probably measured something wrong. I simply couldn’t believe it so I ran the analysis myself and got the following results:

First, we look at the results of Method 2. We can see that the MemoryStream was initialized with a single allocation of 400000 bytes just as we would expect. But there is something nice happening here. The result of the method GetBytes is taken directly from the memory stream buffer by using the GetBuffer method (the memory stream is disposed when we leave the method) so no additional allocations are required.

Now we look at Method 2. Oh the horror… The constructor of the List allocates 400000 bytes just as we expected. We did it so that AddRange would not need to allocate additional bytes and therefore relocate the entire collection in memory. Next we see that BitConverter.GetBytes allocated 100,000 arrays of 4 bytes each, the result of converting a single int into byte array but since an Array is a class we paid a great penalty here. For every class allocated in 32bit architecture we pay 8 bytes of system managed space (two pointers, one for the syncblock and one for the MT of that class) and probably each instance of Array contains a single int variable that contains its size (I am not sure about this if you know otherwise please leave a comment). All and all each such intermediate array takes 16 bytes and therefore there are 1600000 bytes allocated by this method. The big surprise comes with the AddRange method. You would expect that no allocations would be done in this method since we pre-allocated all the needed space in the List constructor but it seems that for each call to AddRange a temporary array is allocated (the number of byte allocated is the same as in the BitConverter.GetBytes calls). Lets look at the code using ILSpy -

 public void InsertRange(int index, IEnumerable<T> collection)  
{  
  if (collection == null)  
  {  
    ThrowHelper.ThrowArgumentNullException(ExceptionArgument.collection);  
  }  
  if (index > this._size)  
  {  
    ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument.index, ExceptionResource.ArgumentOutOfRange_Index);  
  }  
  ICollection<T> collection2 = collection as ICollection<T>;  
  if (collection2 != null)  
  {  
    int count = collection2.Count;  
    if (count > 0)  
    {  
      this.EnsureCapacity(this._size + count);  
      if (index < this._size)  
      {  
        Array.Copy(this._items, index, this._items, index + count, this._size - index);  
      }  
      if (this == collection2)  
      {  
        Array.Copy(this._items, 0, this._items, index, index);  
        Array.Copy(this._items, index + count, this._items, index * 2, this._size - index);  
      }  
      else  
      {  
        T[] array = new T[count];  
        collection2.CopyTo(array, 0);  
        array.CopyTo(this._items, index);  
      }  
      this._size += count;  
    }  
  }  
  else  
  {  
    using (IEnumerator<T> enumerator = collection.GetEnumerator())  
    {  
      while (enumerator.MoveNext())  
      {  
        this.Insert(index++, enumerator.Current);  
      }  
    }  
  }  
  this._version++;  
} 

Look at lines 136 – 138! Our assumption was correct. There is an allocation of a temporary array in the middle of AddRange but why? I found a cryptic answer in StackOverflow. In simple words the answer is this: Since the input collection is cast to ICollection<T> we have to use it's CopyTo method to copy the elements because it may have a custom implementation. The CopyTo method expects we send it the full array and not only the area to which it should copy the elements. If we would send the internal array of the List<T> (this._items) we would expose it to an external method of unknown implementation, this is very dangerous because it can change other elements in this array. As a rule of thumb it’s a good practice to not send reference type (mutable) private members to methods of unknown implementation. The solution here is to create a temporary array with the exactly needed size and make the input collection copy all the members there and then use the standard implementation of CopyTo to copy the elements to the internal array.

All things combined we get ten times more bytes allocated in Method 1 over Method 2 which accounts for the difference in performance. Mystery solved.

Thanks for reading,
Boris.

Friday, December 16, 2011

Writing an Extensible Application – Part 4: MEF

Hi All,

This is the 4th and final part of the extensibility series and this time I will talk about MEF (Managed Extensibility Framework). MEF was an open source project on codeplex but in .Net framework 4 (and SL 4) it was included within the framework itself. MEF is a very simple way to allow extensibility in your application.

A short reminder: We have an application consisting of two projects, the main application and the interfaces Dll which we ship to our clients. The client references the interfaces Dll and implements the required interfaces. This time the extensibility project is called Extensibility and it uses MEF to extend our application. To use MEF in .Net 4 project you simply have to reference System.ComponentModel.Composition (from the framework). Now things couldn’t be simpler. All you need to do is to mark your implemented classes with the Export attribute which will allow the MEF mechanism to identify these implementations as your extensibility implementations. You can pass a type to this attribute stating under which type the implemented class will be imported.

So the code didn’t change too much except these things:

 [InheritedExport(typeof(ICollider))]  
public class BasicCollider : ICollider 

 [InheritedExport(typeof(IDrawer))]  
public class BasicDrawer : IDrawer 

 [InheritedExport(typeof(IMover))]  
public class BasicMover : IMover 

and in the main application the loading is much simpler now:

 private void LoadExtensibility()  
{  
  Assembly applicationAssembly =  Assembly.GetAssembly(GetType());  
  string extensibilityPath = System.IO.Path.Combine(System.IO.Path.GetDirectoryName(applicationAssembly.Location), ConfigurationManager.AppSettings["Extensibility"]);  
  
  AggregateCatalog catalog = new AggregateCatalog();  
  catalog.Catalogs.Add(new DirectoryCatalog(extensibilityPath));  
  _container = new CompositionContainer(catalog);  
  
  try  
  {  
    this._container.ComposeParts(this);  
  }  
  catch (CompositionException compositionException)  
  {  
    Console.WriteLine(compositionException.ToString());  
  }  
  
  IEnumerable<Lazy<ICollider>> tempColliders = _container.GetExports<ICollider>();  
  foreach (Lazy<ICollider> collider in tempColliders)  
    Colliders.Add(new StrategyAdapter(collider.Value));  
  
  IEnumerable<Lazy<IMover>> tempMovers = _container.GetExports<IMover>();  
  foreach (Lazy<IMover> mover in tempMovers)  
    Movers.Add(new StrategyAdapter(mover.Value));  
  
  IEnumerable<Lazy<IDrawer>> tempDrawers = _container.GetExports<IDrawer>();  
  foreach (Lazy<IDrawer> drawer in tempDrawers)  
    Drawers.Add(new StrategyAdapter(drawer.Value));  
  
} 

I won’t go into details about the use of MEF but basically I linked the extensibility folder “Extensibility” with the composition container which magically read the dlls from that folder and added the exported classes so that I can later read them using the GetExports method.

Summary

I have presented 3 ways of making your application extensible. The first involved reflection only and wasn’t a real extensibility framework but merely a poor man’s solution (which sometimes may be enough). The second solution involved an open source framework (IC#Core) which is a bit obsolete and gives only the infrastructure into which you need to add content. The third solution is the MEF framework which gives you some nice options (such as hot swapping) but if you use it without the source code there is too much “automagical” stuff going on there (at least for me). I think the main take-away here is the design of the application. If you followed the example throughout the four parts you have noticed that due to the design of the application the changes I had to make to move from one extensibility framework to the other were quite minor.

Thank you for reading,

Boris

Saturday, December 3, 2011

String Interning or why you shouldn’t use string in a lock statement.

Hi All,

Today I want to talk about a nice and relatively unmentioned feature of the .Net framework – string interning. I will start with a small riddle. What do you think is the output of the following application?

 class Program  
{  
  static void Main(string[] args)  
  {  
    Task t0 = new Task(() => { PrintNumber(0); });  
    Task t1 = new Task(() => { PrintNumber(1); });  
    t0.Start();  
    t1.Start();  
    Task.WaitAll(t0, t1);  
  }  
  
  public static void PrintNumber(int number)  
  {  
    lock ("Monkey")  
    {  
      for (int i = 0; i < 10; i++)  
      {  
        Console.Out.Write(number);  
        Thread.Sleep(200);  
      }  
    }  
  }  
} 

If you said a series of 0s and then a series of 1s (or vise versa) then you are right. But why? When we lock the string “Monkey” shouldn’t the compiler create two instances of the this string (one per call)? This string is a local variable of the method.

As you probably know the String class in .Net is immutable which means that once an instance of this class is created it cannot be edited in any way. Any operation that changes the content of the string will always create a new instance of the string, this instance reflects the changes done on the original string. This behavior is not cemented using some sort of a language directive and is more of a “word of mouth”, an agreements if you wish, between the framework and the coders. Nevertheless, this immutability allows the .Net framework to treat the string in a special way. If the compiler can infer the string content at compile time it will not be allocated on the local heap. It will be allocated on the System Appdomain and added to an interning hash table on the System Domain (called the intern pool). Every time a string is created the framework will search the intern pool to check if an instance of this string already exists and if so it will return a reference to that instance. Note that this would happen automatically only to strings which the compiler can infer during compilation but you can force a string to enter the intern pool by using the String.Intern method.

Here is a simple program to list some interesting cases of string interning:

 static void Main(string[] args)  
    {  
      string s1 = "Hello World";  
      string s2 = "Hello World";  
      string s3 = s2;  
      StringBuilder sb1 = new StringBuilder(s1);  
      string s4 = sb1.ToString();  
      string s5 = string.Intern(s4);  
      string s6 = s1.Clone() as string;  
       
  
      Console.Out.WriteLine(String.Format("s1 == s2 - {0}", s1 == s2));  
      Console.Out.WriteLine(String.Format("Object.ReferenceEquals(s1,s2) - {0}", Object.ReferenceEquals(s1, s2)));  
      Console.Out.WriteLine(String.Format("Object.ReferenceEquals(s1,s3) - {0}", Object.ReferenceEquals(s1, s3)));  
      Console.Out.WriteLine(String.Format("Object.ReferenceEquals(s1,s4) - {0}", Object.ReferenceEquals(s1, s4)));  
      Console.Out.WriteLine(String.Format("Object.ReferenceEquals(s1,s5) - {0}", Object.ReferenceEquals(s1, s5)));  
      Console.Out.WriteLine(String.Format("Object.ReferenceEquals(s1,s6) - {0}", Object.ReferenceEquals(s1, s6)));  
  
      StringBuilder sb2 = new StringBuilder();  
      for (int i = 0; i < 20000; i++)  
        sb1.Append("a");  
  
      string[] strings = new string[2];  
      for (int i = 0; i < 2; i++)  
      {  
        strings[i] = String.Intern(sb1.ToString());  
      }  
  
       
      Console.Out.WriteLine(String.Format("(s1,s6) - {0}", Object.ReferenceEquals(strings[0],strings[1])));  
  
    } 

And the output is:

s1 == s2 - True
Object.ReferenceEquals(s1,s2) - True
Object.ReferenceEquals(s1,s3) - True
Object.ReferenceEquals(s1,s4) - False
Object.ReferenceEquals(s1,s5) - True
Object.ReferenceEquals(s1,s6) - True
(s1,s6) – True

Couple of thigs to notice:

String operations that do not change the string (such as Clone or ToString) will return the same instance.
If an interend string is allocated on the System Appdomain it will never be released (Only when the CLR is terminated)
StringBuilder will always generate a new instance of a string (the compiler can’t infer what the StringBuilder contains).

I am not sure where interning can actually help (although I heard that there are some use cases in ASP.NET where this behavior is benefitial) but you should be aware that it exist and never use a string in a lock statement. Who knows where this string comes from Smile

This is what MSDN has to say about the lock statement :

lock("myLock") is a problem because any other code in the process using the same string, will share the same lock.

I hope now you understand why.

I want to thank Ilya Kosaev for helping me with this blog post.

Thanks for reading,

Boris.

Friday, November 18, 2011

Memory leaks when implementing GetHashCode()

Hi All,

If you have been following my blog then you know I am trying to list as many possible memory leaks in managed code as possible. Most developers, when told about the garbage collection mechanism in .Net, think that memory leaks cannot happen (at least in pure managed code) but as we seen this is not true. The most common case for such memory leaks are static (or singleton events) but as I shown before, using lambda expressions incorrectly may also cause objects not to be disposed in a timely manner.

We consider a case where a simple object overrides the GetHashCode method to be used in a dictionary later. In our case the object (named Person) will be used as a key for a much larger data chunk (named LargeDataObject). Being a seasoned .Net developer I know that if I override the GetHashCode method I also have to override the Equals method and so I do:

 public class Person  
{  
  public int Age { get; set; }  
  
  public override int GetHashCode()  
  {  
    return Age.GetHashCode();  
  }  
  
  public override bool Equals(object obj)  
  {  
    if (!(obj is Person))  
      return false;  
  
    return (obj as Person).Age == this.Age;  
  }  
} 

In my implementation lies the key to the memory leak (pun intended). We examine the following use of the person class:

 Dictionary<Person, LargeDataObject> table = new Dictionary<Person, LargeDataObject>();  
Person p1 = new Person() { Age = 10 };  
table.Add(p1, new LargeDataObject());  
  
Console.Out.WriteLine("Contains P1(10) = {0}", table.ContainsKey(p1)); 

So far so good, this application would print : Contains P1(10) = True

But now I add the following code:

 p1.Age = 20;  
Console.Out.WriteLine("Contains P1(20) = {0}", table.ContainsKey(p1)); 

I changed the age of the person thus changing the hash code of person instance. The GetHashCode and the Equal methods are still in sync but now p1 sits in the wrong bucket within the dictionary! For this case the application would print out : Contains P1(20) = False

In fact you can get to the original p1 instance only by iterating over the keys of this dictionary (but lets face it, you didn’t use dictionary in the first place to iterate over all the keys). What you probably have is something like this in your code:

 Person p2 = new Person(){Age=10};  
      LargeDataObject dataObject = new LargeDataObject();  
      if (table.ContainsKey(p2))  
        table[p2] = dataObject;  
      else  
        table.Add(p2, dataObject); 

If we run this code after the previous code then another person (and most importantly LargeDataObject) will be added to the dictionary. This would happen if I try to add a new Person with Age = 20 because of what MSDN tells us (quite correctly) to do:

“If two objects compare as equal, the GetHashCode method for each object must return the same value. However, if two objects do not compare as equal, the GetHashCode methods for the two object do not have to return different values.”

What happens when you look for a Person with Age = 10: The dictionary goes to the bucket where the hash code is 10 and looks there. It finds p1 and checks if it equals to the current person. The age of p1 is 20 so the current person is not equal p1. Nothing found.

What happens when you look for a Person with Age = 20: The dictionary goes to the bucket where the hash code is 20 and looks there. It finds no items. Nothing found.

Conclusion: If you are implementing GetHashCode and Eqauls make sure they do not depend on mutable properties of an object or this object (if used in a hash based collection) may never be disposed or reached through your code.

Thanks for reading,

Boris.

Friday, November 4, 2011

Writing an Extensible Application – Part 3: IC#Code Addin Tree

Hi All,

This is the third part of my extensibility series and this time I would like to describe an open source extensibility mechanism which is part of SharpDevelop called the Addin Tree. To use the Addin Tree all you have to do is to download the latest version of SharpDevelop and reference the file ICSharpCode.Core.dll in your project. For my example I will be using the dll from version 4.1 which can be downloaded from the site.

The Addin Tree (AT for short) is a very simple mechanism based on XML files called Addins. Each Addin file may contain one or more Path elements which maps all child elements of the Path element to a specific node within the AT. The AT is a tree data structure where each node may contain one or more Codons that describe any user data. Each node in the tree can be reached using a path statement of the form “A/B/…/C/D” where A,B,C are the ids of the nodes to pass on the way to node D which is represented by this statement. When the application loads it can read any number of Addins and build the tree. Later, you may access any node of the tree and Build the codons within this node. Each codon is built by a Doozer which is mapped to that specific codon (the core mechanism provides some basic doozers to build elementary program elements).

The addins are defined using XML files that contain the following elements:

Root Addin Element which contains some general data on the addin.
The Manifest Element which describes the addin file.
The Runtime Element which defines the Doozers and the assemblies needed in the addin.
The Paths Elements which contain the codons of the addin.

Here is an example of such an Addin file (from SharpDevelop):

         <AddIn name= "AddInScout"  
             author= "Satguru P Srivastava"  
          copyright= "prj:///doc/copyright.txt"  
                url= "http://home.mchsi.com/~ssatguru"  
       description = "Display AddIn Information"  
       addInManagerHidden = "preinstalled">  
  
  <Manifest>  
    <Identity name = "ICSharpCode.AddInScout"/>  
  </Manifest>  
  
  <Runtime>  
    <Import assembly="AddInScout.dll"/>  
  </Runtime>  
  
  <Path name = "/Workspace/Tools">  
    <MenuItem id = "ShowAddInScout"  
                  label = "AddIn Scout"  
                  class = "AddInScout.AddInScoutCommand"/>  
  </Path>  
</AddIn> 

The Balls Game

Back to our example… To use the Addin tree extensibility I made some small changes. First, the build process now builds the entire game into a single root Bin folder and all the Addins into an Addins folder. This structure is needed for the Runtime mechanism of the AT. I created a main addin file for the application called Main.addin which contains the definition of the three Doozers I will use to support the extensibility of my application. The doozers are defined in the Interfaces project as internal classes and they contain some logic to build the required class from the codon definition. The main addin file looks like this:

 <AddIn name="Balls Main Addin"  
       author="Boris Kozorovitzky"  
       description="The main addin of the game"  
       addInManagerHidden="preinstalled">  
  
  <Manifest>  
    <Identity name="MainAddin"/>  
  </Manifest>  
  
  <Runtime>  
    <Import assembly=":BallsInterfaces">  
      <Doozer name="Collider" class="BallsInterfaces.Doozers.ColliderDoozer"/>  
      <Doozer name="Mover" class="BallsInterfaces.Doozers.MoverDoozer"/>  
      <Doozer name="Drawer" class="BallsInterfaces.Doozers.DrawerDoozer"/>  
    </Import>  
  </Runtime>  
</AddIn> 

One important thing to notice here is that the Import element tells the extensibility mechanism where to find the doozers. In this case I use the “:” syntax to tell it that the required assembly is in the Bin folder. You will understand why this is important next.

The extensibility Addin may sit anywhere in the Addin folder (any directory structure) and it looks like this:

 <AddIn name="Balls Addin"  
       author="Boris Kozorovitzky"  
       description="Adds some balls to the game"  
       addInManagerHidden="preinstalled">  
  
  <Manifest>  
    <Identity name="AddinExtensibility"/>  
  </Manifest>  
  
  <Runtime>  
    <Import assembly=":BallsInterfaces"></Import>  
    <Import assembly="AddinExtensibility.dll"></Import>  
  </Runtime>  
  
  <Path name="/Balls/Colliders">  
    <Collider type="AddinExtensibility.BasicCollider"></Collider>  
    <Collider type="AddinExtensibility.StopperCollider"></Collider>  
  </Path>  
  
  <Path name="/Balls/Movers">  
    <Mover type="AddinExtensibility.BasicMover"></Mover>  
    <Mover type="AddinExtensibility.ParabolicMover"></Mover>  
  
  </Path>  
  
  <Path name="/Balls/Drawers">  
    <Drawer type="AddinExtensibility.BasicDrawer" fill="Yellow"></Drawer>  
      <Drawer type="AddinExtensibility.BlinkerDrawer"></Drawer>  
  
  </Path>  
  
</AddIn> 

Note that the import section references the Dll where all the classes are defined – AddinExtensibility.dll and the BallsInterfaces assembly. The main section of the addin contains three Path elements (I chose the path randomly to something logical) and each path contains Codon which can be built by a specific doozer (see doozer mapping in the main addin file). The collider doozer code will reveal the nice trick which the import does for us:

 internal class ColliderDoozer:IDoozer  
{  
  public object BuildItem(BuildItemArgs args)  
  {  
    string stringType = args.Codon.Properties["type"];  
    object result = args.AddIn.CreateObject(stringType);  
    return result;  
  }  
  
  public bool HandleConditions  
  {  
    get { return false; }  
  }  
} 

The AT mechanism will call the BuildItem method on any codon which is mapped to that doozer. In this case I expect the element to have a “type” attribute where the type of the object is written. Now that the type is resolved I can call the CreateObject method which will do the magic for us and find the correct type from the assemblies referenced in the Runtime section and thus returning the correct item each time. To show you how the extensibility mechanism can work for us I added two editable properties to the BasicDrawer type. The Drawer doozer calls a new method – Configure which takes the codon and extracts the needed arguments from it. Now we can control the color and the diameter of the basic drawer directly from the addin file!

 public class BasicDrawer : IDrawer  
  {  
    private static double _initialDiameter;  
    private static Brush _initialBrush;  
  
    public void Initialize(IBall ball)  
    {  
      ball.Diameter = _initialDiameter;  
      ball.Fill = _initialBrush??Brushes.Blue;  
    }  
  
    public void Tick(IBall ball)  
    {  
  
    }  
  
    public object Clone()  
    {  
      return new BasicDrawer();  
    }  
  
  
    public void Configure(ICSharpCode.Core.Codon codon)  
    {  
      _initialDiameter = 15;  
      if (codon.Properties.Contains("diameter"))  
      {  
        string diameterString = codon.Properties["diameter"];  
        double diameter = 15d;  
        Double.TryParse(diameterString, out diameter);  
        _initialDiameter = diameter;  
      }  
  
      _initialBrush = null;  
      if (codon.Properties.Contains("fill"))  
      {  
        string fillString = codon.Properties["fill"];  
        _initialBrush = (SolidColorBrush)new BrushConverter().ConvertFromString(fillString);  
      }  
  
    }  
  } 

In the example I set the color of all the balls created with the BasicDrawer to Yellow but the user may chose to edit this value as he wishes.

The extensibility initialization code changed slightly and now it loads all the addin files from the Addins path:

 private void LoadExtensibility()  
{  
  Assembly applicationAssembly =  Assembly.GetAssembly(GetType());  
  string extensibilityPath = System.IO.Path.Combine(System.IO.Path.GetDirectoryName(applicationAssembly.Location), ConfigurationManager.AppSettings["AddinsPath"]);  
  string[] addinFiles = System.IO.Directory.GetFiles(extensibilityPath, "*.addin",System.IO.SearchOption.AllDirectories);  
  AddInTree.Load(new List<string>(addinFiles), new List<string>());  
  foreach (ICollider collider in AddInTree.BuildItems<ICollider>("/Balls/Colliders", null))  
    Colliders.Add(new StrategyAdapter(collider));  
  
  foreach (IMover mover in AddInTree.BuildItems<IMover>("/Balls/Movers", null))  
    Movers.Add(new StrategyAdapter(mover));  
  
  foreach (IDrawer drawer in AddInTree.BuildItems<IDrawer>("/Balls/Drawers", null))  
    Drawers.Add(new StrategyAdapter(drawer));  
} 

This extensibility mechanism allows great flexibility and it is simple enough to cover many useful scenarios. In the worst case you can always take a look at the source code to see how things work under the hood. If you are looking for something simple yet powerful to extend your application you should definitely consider the Addin Tree.

Thank you for reading. You can get the new sources from my SkyDrive here:

Boris

Sunday, October 16, 2011

Task Parallel Library (TPL)–The lambda strikes back

Hi All,

I would like to share an interesting insight I got when solving some problems at Project Euler. I was trying to make my program run a little faster (because it was using only one CPU core) so I decided to use the TPL. I will spare you the details of the actual problem and instead present a simple piece of code which demonstrates the problem:

 public static void Run()  
    {  
      Task[] tasks = new Task[10];  
      for (int i = 0; i < 10; i++)  
      {  
        tasks[i] = Task.Factory.StartNew(() => { PrintNumber(i); });  
      }  
  
      Task.WaitAll(tasks);  
    }  
  
    private static void PrintNumber(int i)  
    {  
      Thread.Sleep(100);  
      Console.Write(i);  
      Console.Write(",");  
    } 

What do you think will be printed when I call Run?

If you think that this is not deterministic because the TPL may choose to run the tasks at any order you would be half right. Indeed, the TPL can run the tasks in any order but in this case we have a different problem. The evaluation of the lambda expression will be done only when the task is run and in the general case it would be after the loop is finished so the value of “i" would be 10 for all the tasks.

The correct answer is therefore that the program will print 10 times “10,” (in the general case because in some cases the task may start in the middle of the loop).

I remind you from a previous post on my blog that when you use a local variable in a lambda expression the compiler generates a “secret” class for you which holds a reference (for reference types) or a copy (for value types) of this variable until the lambda expression is run. Therefore to get the desired result we need a unique variable to be copied in each iteration. This can be achieved by adding a temp variable within the scope of the loop and use it in the lambda.

 public static void Run()  
{  
  Task[] tasks = new Task[10];  
  for (int i = 0; i < 10; i++)  
  {  
    int x = i;  
    tasks[i] = Task.Factory.StartNew(() => { PrintNumber(x); });  
  }  
  
  Task.WaitAll(tasks);  
}  
  
private static void PrintNumber(int i)  
{  
  Thread.Sleep(100);  
  Console.Write(i);  
  Console.Write(",");  
} 

Now we get the correct results, the numbers 0 though 9 are printed (in some order).

My conclusion is (again): One should be extra careful when using local variables in lambda expressions.

Thanks for reading,

Boris.

Thursday, October 13, 2011

Persisting a GridSplitter

Hi All,

If you are using WPF then you probably use the Grid container and if you are using that then at times you surely need the assistance of the GridSplitter. The GridSplitter is a sub element of the Grid and it allows the user to conveniently resize the grid columns or rows. Those of you who worked with the GridSplitter know that it is quite challenging to work with correctly.

I will start with a small example. In my application I need a vertical splitter between two buttons (conveniently named Left and Right). The initial size of the Left button should be twice the size of the Right button. Here is the XAML:

 <Grid>  
    <Grid.ColumnDefinitions>  
        <ColumnDefinition Width="2*"></ColumnDefinition>  
        <ColumnDefinition Width="Auto"></ColumnDefinition>  
        <ColumnDefinition Width="*"></ColumnDefinition>  
    </Grid.ColumnDefinitions>  
    <GridSplitter Width="5" Background="Red" VerticalAlignment="Stretch" HorizontalAlignment="Center" Grid.Column="1"></GridSplitter>  
    <Button Grid.Column="0">Left</Button>  
    <Button Grid.Column="2">Right</Button>  
</Grid> 

And this is the result:

I am using a technique where the GridSplitter sits in its own column. I find this approach better since then you don’t need to think how it should be position within the column or within the XAML file.

The problem with the GridSplitter becomes apparent when you try to use fixed sizes in the grid column width (the same applies for grid row height but I will continue the discussion with the grid columns). What if we want the left column to start with a fixed size of 5cm on the screen. The logical thing to do would be to set the width of the first column to 5cm. If you do that and run the application everything would seem normal until you start dragging the GridSplitter. Try dragging it to the right… way right… past the window border right… now let go and try to drag it back. That’s right. The GridSplitter is gone! I read somewhere on the Internet that the grid splitter does exactly what I told it to do. If you believe that then try to do the same with the right column and dragging the GridSplitter left. The phenomenon here is even stranger.

 <Grid>  
     <Grid>  
         <Grid.ColumnDefinitions>  
             <ColumnDefinition Width="*" ></ColumnDefinition>  
             <ColumnDefinition Width="Auto"></ColumnDefinition>  
             <ColumnDefinition Width="5cm" ></ColumnDefinition>  
         </Grid.ColumnDefinitions>  
  
         <GridSplitter Width="5" Background="Red" VerticalAlignment="Stretch"  
     HorizontalAlignment="Center" Grid.Column="1"></GridSplitter>  
         <Button Grid.Column="0">Left</Button>  
         <Button Grid.Column="2" >Right</Button>  
     </Grid>  
 </Grid> 

Don’t do that… Its crazy!

The point I am trying to make here is that the GridSplitter is best used when the widths of the column are star based. You can have some control using the MinWidth and MaxWidth properties applied on the columns, but sometimes this behavior is not the desired one.

Now for the main challenge. I want my application to restore the state of the GridSplitter position next time it is run. For example if I move the GridSplitter such that only the Right button is visible and close the application. When I start the application I expect only the Right button to be visible. Actually doing this is quite simple. I add x:Name attributes to the grid columns and handle the DragCompleted event of the GridSplitter. In the handler I serialize the width properties of both columns into a file. The problem here is that the Width is not a simple double value but a struct (GridLength). Fortunately, the framework provides us with a small helper class to serialize and deserialize this struct called GridLengthConverter. The serialization code looks like this:

 Assembly assembly = Assembly.GetExecutingAssembly();  
String directory = System.IO.Path.GetDirectoryName(assembly.Location);  
using (StreamWriter writer = new StreamWriter(Path.Combine(directory, "width.txt")))  
{  
  GridLengthConverter converter = new GridLengthConverter();  
  writer.WriteLine(converter.ConvertToString(LeftColumn.Width));  
  writer.WriteLine(converter.ConvertToString(RightColumn.Width));  
} 

and the deserialization code is therefore like this:

 Assembly assembly = Assembly.GetExecutingAssembly();  
String directory = System.IO.Path.GetDirectoryName(assembly.Location);  
if (File.Exists(Path.Combine(directory, "width.txt")))  
{  
  using (StreamReader reader = new StreamReader(Path.Combine(directory, "width.txt")))  
  {  
    GridLengthConverter converter = new GridLengthConverter();  
    LeftColumn.Width = (GridLength)converter.ConvertFromString(reader.ReadLine());  
    RightColumn.Width = (GridLength)converter.ConvertFromString(reader.ReadLine());  
  }  
} 

(it is run after InitializeComponents).

The important thing to notice here is that you must serialize both column width because they are relative to each other.

That’s it for today. Thank you for reading.

Boris.

Tuesday, September 27, 2011

Writing an Extensible Application – Part 2: Extensibility by Reflection

Hi,

This time I will present a very primitive (yet somehow effective) extensibility method: Extensibility by Reflection. This method is good when you don’t want to over complicate things and all you need is a simple way to extend some specific types. This method is based on the Reflection mechanism of .Net (as the name suggests).

Let’s make a short recap of the previous post. I have made a small application that simulates balls within an enclosed rectangular area. Each ball has three “properties”: The Collider, the Mover, and the Drawer. The UI allows the user to select each of the aforementioned properties from a list and create a ball using these properties. The most important thing I did was to design the application in an extensible way. The main application uses all the data through interfaces which are defined in an external DLL (BallsInterfaces.dll).

I have created an additional project which represents the extensibility client (a dll your user would write). For coherence, I have moved all the basic types to that dll and now all of our colliders, drawers, and movers will be loaded through extensibility. I changed the build target path of the new project to be inside <Main project dir>/Extensibility. In the main project I have added the following key to the application settings:

 <appSettings>  
  <add key="ExtensibilityPath" value="Extensibility"/>  
</appSettings> 

From this point things are quite simple. All we have to do is to load all the DLLs from the defined path and in each such DLL find and instanciate any class that inherits from ICollider, IMover, or IDrawer interfaces. The following code does just that:

 private void LoadExtensibility()  
{  
  Assembly applicationAssembly =  Assembly.GetAssembly(GetType());  
  string extensibilityPath = System.IO.Path.Combine(System.IO.Path.GetDirectoryName(applicationAssembly.Location), ConfigurationManager.AppSettings["ExtensibilityPath"]);  
  string[] dllFiles = System.IO.Directory.GetFiles(extensibilityPath, "*.dll");  
  foreach (string fileName in dllFiles)  
  {  
    Assembly currentAssembly =  Assembly.LoadFile(fileName);  
    Type[] innerTypes = currentAssembly.GetTypes();  
    foreach (Type t in innerTypes)  
    {  
      if (t.IsClass && t.IsPublic)  
      {  
        if (t.GetInterfaces().Contains(typeof(ICollider)))  
        {  
          Colliders.Add(new StrategyAdapter(t));  
        }  
  
        if (t.GetInterfaces().Contains(typeof(IMover)))  
        {  
          Movers.Add(new StrategyAdapter(t));  
        }  
  
  
        if (t.GetInterfaces().Contains(typeof(IDrawer)))  
        {  
          Drawers.Add(new StrategyAdapter(t));  
        }  
  
      }  
    }  
  }  
} 

A few things worth mentioning:

I have added three ObservableCollections named – Colliders, Movers, and Drawers and hooked them up with the ComboBoxes in the application.
Each observable collection contains an adapter class (StrategyAdapter) which mitigates the extensible type with the instance creation. It also provides the Name property for display within the ComboBoxes. The StrategyAdapter code is as follows:

 public class StrategyAdapter  
  {  
     
    protected Type _innerItemType;  
    public string Name  
    {  
      get  
      {  
        if (_innerItemType != null)  
        {  
          return _innerItemType.Name;  
        }  
        return "Null";  
  
      }  
       
    }  
    public StrategyAdapter(Type itemType)  
    {  
      _innerItemType = itemType;  
    }  
  
    public T CreateInstance<T>() where T:class  
    {  
      return Activator.CreateInstance(_innerItemType) as T;  
    }  
  } 

And from this code you may infer that the ball creation code becomes:

 Ball ball = new Ball(SelectedMover.CreateInstance<IMover>(), SelectedCollider.CreateInstance<ICollider>(), SelectedDrawer.CreateInstance<IDrawer>(), _environment); 

To extend this example I have added three new implementations of the extensibility interfaces:

The Parabolic Mover – It moves the ball as if there was gravity (i.e. with acceleration).
The Blinker Drawer – It creates a slightly bigger red ball that slowly disappears and then instantly reappears.
The Stopper Collider – It stops the other ball on the spot after collision.

As usual, you can download the sources from my SkyDrive -

I want to take this opportunity to say שנה טובה וחג שמח to all my Jewish friends. Nice and fun 国庆节 to all my Chinese friends, rest and spend time with your families. Happy Friday to all my Pastafarian friends (since every Friday is a holyday!).

Thanks for reading,

Boris.

Saturday, December 31, 2011

Friday, December 16, 2011

Saturday, December 3, 2011

Friday, November 18, 2011

Friday, November 4, 2011

Sunday, October 16, 2011

Thursday, October 13, 2011

Tuesday, September 27, 2011

Followers