On managed something and graphical nonsense

Friday, February 24, 2006

Fun with Singletons in C# 2.0 (Part 2)



And here we go again :)

Last entry we talked about the "Generic Singleton" and how to achieve such an artifact without partial specialization templating (aka full blown C++ templating engine). In this entry we will focus on allocators, what they do, what is their responsability, what we can do with them, and maybe some little history about their existence.

Allocators in one shape or another can be tracked to the very beginning of the programming endervour. There had always been a necesity to allocate resources, the most basic resource to allocate was memory; so in procedural language we relied either on the compiler to do stack allocation of memory or on specific constructions or library calls (as in C) to do the work. Using those approaches the specific allocation strategy was hidden from the programmer by those calls.

Sometimes things didnt worked as expected and those default allocation strategies fall short, mostly when a lot of space has to be allocated to be used in special ways; for example in mathematical code (memory must be aligned and consecutive to better use the cache of the processor) or in code with high performance requirements. At that moment most programmers relied in custom strategies to handle those situations doing just a single call to get all memory required in one step.

When object orientation got mainstream and languages like Smalltalk and C++, some objects were a little too big and costly to initialize, we again relied on allocators to recicle the memory we used or objects :) .

Then someone thought, what if we let the programmer specify the memory/object allocation strategy giving a binding to the underlaying allocation system. Then the allocators where given a name and an existence in its own. And light filled the sky and allocators where born :D

Ok, enough history. Now we are going to the nitty gritty details (I love this part). IMHO the best way to accomplish something is knowing where we want to go. Now lets suppose we have our "Static Allocation Singleton" from Part 1, now what if we write something like this:

/// <summary>
/// An StaticSingleton using an StaticAllocator used just
/// to simplify the inheritance syntax.
/// </summary>
public class StaticSingleton<T> : Singleton<T, StaticAllocator<T>> where T : class
{ }
So our static singleton is just a Singleton of type T with an StaticAllocator of type T. Cooool! Isnt it?? Now lets get our hands dirty. So by now we know that our allocators will be the ones that will be in charge of specifying our allocation strategy. Now our singleton not only depends on T but on our Allocator too. In C# code it should be something like this:


public class Singleton< T, Allocator >
where T : class
where Allocator : Allocator< T >
{
private static readonly Allocator<T> allocator;
/// <summary>
/// The Singleton implementation of the Instance method defer the creation policy to
/// its allocator, so this method just delegate the Instance retrieval to the
/// Instance method of the allocator.
/// </summary>
public static T Instance
{
get { return allocator.Instance; }
}
}

Even if you dont know already we have solved the Allocator Based Singleton problem. Where is the trick you might think? Well someone said (if anyone knows the source would be cool): "There are only a few problems in Computer Science that cannot be solved by an extra level of indirection." I applied that concept so now the Instance method just delegates the real allocation to the Allocator Instance :)

We have a big problem to solve yet, but we have solved it in the last singleton implementation. Guess who had been the lucky winner that will ensure that the allocator get created :D, yes our friend Reflection.


static Singleton()
{
ConstructorInfo constructor = typeof(Allocator).GetConstructor(
BindingFlags.Instance |
BindingFlags.NonPublic, null,
new Type[0], new ParameterModifier[0]
);

if (constructor == null)
throw new Exception("The allocator doesnt have a private/protected constructor.");

try
{
allocator = constructor.Invoke(new object[0]) as Allocator<T>;
}
catch (Exception e)
{
throw new Exception("The Singleton Allocator couldnt be constructed", e);
}
}

What if I create multiple allocators then can I create multiple instances of T? The answer is yes and no. Yes, you can create multiple instances of the allocator, and No they wont allow you to have multiple instances of T :) using the same trick that we used before.

Our allocator looks like this:

public abstract class Allocator<T>
where T : class
{
/// <summary>
/// The parameterless protected Constructor.
/// </summary>
protected Allocator()
{ }

/// <summary>
/// The property returns the only instance of the Singleton Object in question.
/// </summary>
/// <remarks>This property implementation must enforce the Single Object property
/// of Singletons throwing an exception.</remarks>
public abstract T Instance { get; }
}

So how do our StaticAllocator look? Well, almost the same as our original singleton :O

public class StaticAllocator<T> : Allocator<T> where T : class
{
static StaticAllocator()
{
ConstructorInfo constructor = typeof(T).GetConstructor(
BindingFlags.Instance |
BindingFlags.NonPublic, null,
new Type[0], new ParameterModifier[0]);

if (constructor == null)
throw new Exception("The object doesnt have a private/protected constructor.");

try
{
instance = constructor.Invoke(new object[0]) as T;
}
catch (Exception e)
{
throw new Exception("The StaticSingleton couldnt be constructed", e);
}
}

private StaticAllocator()
{ }

private static readonly T instance;

/// <summary>
/// The static allocator Instance property returns the instance created on class loading.
/// </summary>
/// <remarks>This means that the singleton is instantiated at the moment in which
/// a class has a reference to that type even if it never calls the Instance
/// method.</remarks>
public override T Instance
{
get { return instance; }
}
}

What if we want to do a LazyAllocator, well as in most textbooks we will leave that for the reader to implement by themselves (just dont tell anyone, you can get the source from here ;) ) So we did all this just to implement a LazyAllocator?? Hell no, what if I say you that you can have an abstract singleton to instance a concrete provider by itself just reading the concrete instance from a config file? Whould it be useful? Well I know of an specific scenario where it wont be only cool, but useful. When you are creating a Rendering Engine and the rendering provider could be Managed DirectX or OpenGL (and that cant be changed on the fly ;) ) then you just read the Renderer concrete class from a configuration file, and the user wont ever know what it is using as he is using an abstract class. :)

I must say that this entry was fun to write it, so I hope you enjoy reading it as much as I did writting it.

Greetings
Federico

Monday, February 20, 2006

Fun with Singletons in C# 2.0 (Part 1)

Introduction
Coming from a hardcore C++ development background, I had amazed myself several times reading such excelent books like Modern C++ Design: Generic Programming and Design Patterns Applied from Andrei Alexandrescu or the source code of Boost. They are extremely hard to understand (took me several weeks and a big headache to get a glipse of what he was talking about) but I would recommend them anytime to C# developers that would really want to uncover the real potential of C# generics.

With the new generics support given by C# 2.0 some common design patterns can be generalized to work with any type. Exploiting the capabilities given by the type system, reflection and generics we can accomplish typesafe modular code customization and automation. Fun with Singletons is just a demostration among the array of posibilities that C# 2.0 features introduce.

The audience for this article is anyone with a decent knowledge on generics, however to really appreciate it, an exposure to C++ templates engine would be desired.

Background

The singleton is by far the most common design pattern in literature, it has been implemented countless of times in several languages. In C# the typical implementation requires us to implement the Instance method and be aware of locking depending if we are creating it lazily or statically.

One night (like 8 months ago) I asked to myself: Wouldnt it be nice to inherit from a class and automatically have the singleton implementation done? And what about all security controls required to make sure I am not making a mistake in the implementation of my class?

The response didnt took much time to come: yes, I can do that in C++; however, the aim was to do it to investigate one of those interesting features back then with the Beta 2 of Visual Studio 2005, C# generics. The solution was heavily inspired by Alexandrescu's Generic Singleton Pattern also known as "Allocator Based Singleton". And here we go :) .

Generic Singletons

At the time I had been looking to code the singletons in a way that they could be used like this:

public class MySingleton : Singleton<MySingleton>
{}

Luckily up to that point C# generics suffice to handle a situation like that one, so after some time trying to get a grasp of how generics worked in C# 2.0 I came up with the following Singleton class.

public class Singleton<T> where T : new ()
{
private static T instance;

public static T Instance { get { return instance; } }

static Singleton ()
{
instance = new T();
}

protected Singleton ()
{}
}

public class MySingleton : Singleton<MySingleton>
{
public MySingleton ()
{}
}

At the time I was thrilled, I was able to create a singleton using the famous recursive pattern that made C++ templates so weird to understand; all that in C# 2.0. However, I wasnt entirely satisfied with the implementation. So where's the catch? Read the code again :).

One of the tenets for the Singleton pattern existence is that the instance must be unique; that was the property that I wasnt honoring. The requirement that T must implement a public default constructor was killing the design of such a reusable pattern component. Took me like 6 hours of trying this and that to realize that the design wasnt flawed, it was my usual C++ style of thinking what was hindering me from discovering the solution to this problem.

The solution can be described with just one word: Reflection. Yes, reflection is one of those features that can be extremely powerful when used correctly or a "Golden Hammer" if used obsesibly. In this case, reflection was the feature that would allow me to honor the most important property of Singletons and at the same time do some runtime checking on behalf of the user of a generic library.

ConstructorInfo constructor = typeof(T).GetConstructor(
BindingFlags.Instance | BindingFlags.NonPublic,
null, new Type[0],
new ParameterModifier[0] );
if (constructor == null)
throw new Exception(
"The singleton doesnt have a private
/protected constructor."
);

try
{
allocator = constructor.Invoke(new object[0]) as T;
}
catch (Exception e)
{
throw new Exception(
"The Singleton couldnt be constructed", e
);
}
Now instead of relaying on the new() constrain in the generic type, by reflection we would only look for private or protected constructions. That means that, if the user mistakenly try to create a singleton and add a default constructor that isnt private or protected, then the singleton base would not allow it to continue raising an exception ( this implementation do not check if the user adds public constructors with parameters, but that is easily achived ).

Up to that point I was pretty satisfied with the solution, but having different styles of singletons behaviors like Lazy allocation, configuration based, etc; would require me to recode the singletons. I know what you think, I dont like it either :D

Next part of this post will show how to accomplish the highly desired (by me at least) "Allocator Based Singleton" and the complete source of its implementation. So, see ya arround.

Greetings
Federico Lois