Subtext 1.9.5 -> 2.1.2

I’ve just upgraded my blog from Subtext 1.9.5 to Subtext 2.1.2. The upgrade has been smooth and I haven’t had to make any manual changes. I’m really impressed. Keep up good work guys! I can’t wait for Subtext 3.0 which is meant to based on ASP.NET MVC. Now I need to find a better skin for my blog but taking into account my UI skills that might take some time ;).

5 days SOA and DDD training by Udi Dahan in Melbourne

If there are enough people then this actually might happen. If you are interested and I’m telling you, you should :) then express that as soon as possible by  contacting Simon. You can find an overview of the training here.

Quick look at STM.NET performance

STM as an idea looks interesting and definitely has a lot of advantages over regular locking. It helps prevent deadlocks, makes easier to compose components that implement some kind of synchronization, helps eliminate nested locks, supports retries and so on. You can find the full list of goodness here.
When I found out that STM.NET(based on .NET 4.0) is out my first question was related to its performance. I put together a simple test and I have to say that in most scenarios STM.NET is an overkill. Sure, it’s a research project and it hasn’t been productized which means it’s not optimized and it’s not ready for prime time. But still, on average it’s 20x slower than the regular lock statement. That’s a lot taking into account that in most cases developers use very simple locking strategies and try to avoid nested locks. If Microsoft can bring it down to 2x then it is a completely different story.
The results:

The code of the benchmark:

using System;
using System.Threading;
using System.Collections;
using System.TransactionalMemory;
using System.Collections.Generic;
using System.Diagnostics;
class Program
{
    public delegate void CustomAction();
    [AtomicNotSupported]
    static void Main(string[] args)
    {
        var iterations = 1000000;
        Console.WriteLine("Number of Threads  | STM.NET [ms] |" + 
                          "Regular locking [ms] | Times slower");
        for (var i =1 ; i < 15; i++)
        {
            Test(i, iterations);  
        }
        
        Console.ReadLine();
    }
    private static void Test(int numberOfThreads, int iterations)
    {
        var storage = new Storage();
        CustomAction action = () =>
        {
            Atomic.Do(() =>
            {
                storage.UpdateByOne();
            });
        };
        var stm = Execute(numberOfThreads, iterations, action, storage);
        storage = new Storage();
        CustomAction action1 = () =>
        {
            lock (storage)
            {
                storage.UpdateByOne();
            }
        };
        var locking = Execute(numberOfThreads, iterations, action1, storage);
        int slower = (int)(stm.ElapsedMilliseconds / locking.ElapsedMilliseconds);
        var message = String.Format("{0}\t\t\t{1}\t\t\t{2}\t\t\t{3}", numberOfThreads, 
                                    stm.ElapsedMilliseconds, 
                                    locking.ElapsedMilliseconds, slower);
        Console.WriteLine(message);
    }
    private static Stopwatch Execute(int numberOfThreads, int iterations, 
                                     CustomAction action, Storage storage)
    {
        var stopwatch = Stopwatch.StartNew();
        var threads = new List<Thread>();
        for (var i = 0; i < numberOfThreads; i++)
        {
            var thread = new Thread(() =>
            {
                for (var j = 0; j < iterations; j++)
                {
                    action();
                }
            });
            threads.Add(thread);
        }
        foreach (var thread in threads)
        {
            thread.Start();
        }
        foreach (var thread in threads)
        {
            thread.Join();
        }
        stopwatch.Stop();
        if (numberOfThreads * iterations != storage.Result)
        { 
            var message = String.Format("Incorrect value. Expected: {0} Actual: {1}", 
                                         numberOfThreads*iterations, storage.Result);
            throw new ApplicationException(message);
        }
        return stopwatch;
    }
}
public class Storage
{
    private long value;
    public void UpdateByOne()
    {
        value = value + 1;
    }
    public long Result
    {
        get { return value; }
    }
}

How many times can you load an assembly into the same AppDomain?

Actually, as many as you want, just call

Assembly.Load(File.ReadAllBytes(@"SomeFolder\MyLib.dll"));

in a loop. All copies will have their code base set to the currently executing assembly. Code base specifies the physical location of an assembly. By executing the following line

Assembly.LoadFrom(@"SomeOtherFolder\MyLib.dll");

we load another copy but this time from completely different location. Let’s add one more:

Assembly.Load("MyLib");

In this way we end up with several copies and 3 different code bases inside of the same AppDomain. This happens because each assembly is loaded into different load context. You can read about that here. Why is it like that? To be honest I’ve found no clear explanation. Some Microsoft bloggers mention that this makes order independent loading possible. But that’s it. From my perspective that’s not much to justify the fact that multiple copies of the same assembly can be loaded into the same AppDomain which is very often dangerous.
The main problem is that the runtime treats types in all copies as completely different types. This means that if you create an object of type MyClass using the type definition from the assembly loaded by Load method you won’t be able to pass it to a method that takes MyClass as a parameter but is defined in the assembly loaded by LoadFrom method. If something like that happens you get InvalidCastException which is hard to believe in because VS debugger clearly shows that the type of the parameter is correct :). It’s only when you dig deeper and check the assembly where the type comes from when you find out that they are from 2 different assemblies. This can be very confusing and hard to debug. Even if there is a valid reason behind this feature it would be great if I could run loader/runtime in some kind of strict mode where duplicates are not allowed and a meaningful exception is thrown when an assembly is requested to be loaded more than once. I can see more and more code that is loaded dynamically at runtime and this feature would be very useful.

This blog is NOT dead

It’s been a very busy and exciting half a year for me and that’s the main reason why my blog WAS temporarily abandoned.

Before Christmas 2008 I left Ireland for good. I’ve spent over 3 years of my life there and I don’ regret anything. I’ve met many amazing people and I’ve learnt a lot from both professional and personal perspectives. But my Irish time was up and it was time to move on. I’ve decided to move to Sydney in Australia and become one of the Readifarians. I started my new job at the beginning of April 2009. After leaving Ireland but before arriving in Australia I went travelling(Mexico, Guatemala, NYC) for several weeks to prepare myself for new challenges. That’s the story.

I work as a Consultant which means that I either work from home or work on the client side. It’s definitely completely different way of working than the one you experience as a permanent employee. It’s too early to make some definitive statements but so far I can say that is focused very much on solving problems which makes it very intense. And that’s exactly what I was looking for.

The bottom line is that I’m back to blogging which means I’m more or less settled on the other side of the planet :).

Dublin - it's not a city it's a new Microsoft codename :)

It looks like Windows Server 2008 needs to be extended to be able to host WCF 4.0 and WF 4.0 type of applications. The codename of this set of extensions is called Dublin. Dublin is the capital of Ireland and I'm curious if the author of the codename knew about that. Anyway, you can find more details about the new platform here. At the first glance it looks interesting but still there is no mention of publish/subscribe type of messaging. I hope I've missed something as this a huge gap in the communication framework that Microsoft provides.

Tags: .NET, WCF, WF

27 stack frames on 32 bit OS and 22 stack frames on 64 bit OS

64 bit JIT and 32 bit JIT are 2 very different beasts which is what one would suspect. But still I was rather surprised that 64 bit JIT was able to reduce the call stack of a call by 20% in comparison with 32 bit JIT. A piece of my code crawls the call stack to gather some runtime characteristics and it broke on a 64 bit machine. That's how I started a small investigation and found this difference. In most cases it's not a good idea to rely on the way JIT works as this is subject to change but from time to time there is simply no other way. If you look for more information about 32/64 JIT you can check this blog post of Scott Hanselman which is an overview with links to other Microsoft bloggers that dive much deeper into details.

Tags: JIT, .NET