Archive

Posts Tagged ‘.NET’

Distributed Lock with AppFabric Caching

July 30, 2013 2 comments

When building distributed applications you often need to synchronize access to shared resources. For example you might have multiple instances of a web service running on a web farm and you need to only have one of those services perform a given task. Steve Marx proposed a solution for Windows Azure which relies on leases but unfortunately that will not work on premise. Other caching products, such as Redis, offer this functionality out of the box so I thought it would be useful to have this for AppFabric.

I’ve developed a DataCache extension method that works the same way as ServiceStack’s Redis Client. Here’s how to use it:

DataCache cache = factory.GetCache("MyCache");
using (cache.AcquireLock("MyLock"))
{
    // Lock acquired, perform synchronized work here
}

The AcquireLock method will block until it can acquire an exclusive lock or until the optional timeout value is reached. Here is the implementation:

public static IDisposable AcquireLock(this DataCache cache, string key, TimeSpan? timeout = null)
{
    if (cache == null)
    {
        throw new ArgumentNullException("cache");
    }
    if (key == null)
    {
        throw new ArgumentNullException("key");
    }

    return new DataCacheLock(cache, key, timeout);
}

Very simple so far, the core of the logic is in the private DataCacheLock class:

private class DataCacheLock : IDisposable
{
    private DataCache _cache;            
    private DataCacheLockHandle _lockHandle;
    private string _key;

    public DataCacheLock(DataCache cache, string key, TimeSpan? timeout)
    {
        _cache = cache;
        _key = key;
        RetryUntilTrue(() =>
        {
            try
            {
                cache.GetAndLock(key, timeout ?? TimeSpan.MaxValue, out _lockHandle);
                return true;
            }
            catch (DataCacheException ex)
            {
                if (ex.ErrorCode == DataCacheErrorCode.KeyDoesNotExist)
                {
                    try
                    {
                        cache.Add(key, string.Empty);
                    }
                    catch (DataCacheException)
                    {
                    }
                    return false;
                }
                else if (ex.ErrorCode == DataCacheErrorCode.ObjectLocked)
                {
                    return false;
                }
                throw;
            }
        }, timeout);
    }

    public void Dispose()
    {
        if (_lockHandle != null)
        {
            _cache.Unlock(_key, _lockHandle);
            _lockHandle = null;
        }
    }           
}

Essentially a client will try to GetAndLock the specified key. If the key doesn’t exist it will create it. If it exists but is already locked, it will retry indefinitely or until the timeout value is reached.

I am not a big fan of having logic implemented around exceptions but we don’t have any other choices here with the AppFabric Caching API. You’ve probably noticed the use of the helper method RetryUntilTrue, here’s how this is implemented:

private static readonly Random _random = new Random();

private static void RetryUntilTrue(Func<bool> action, TimeSpan? timeout)
{
    int i = 0;
    DateTime utcNow = DateTime.UtcNow;
    while (!timeout.HasValue || DateTime.UtcNow – utcNow < timeout.Value)
    {
        i++;
        if (action())
        {
            return;
        }
        Thread.Sleep(_random.Next((int)Math.Pow(i, 2), (int)Math.Pow(i + 1, 2) + 1));
    }
    throw new TimeoutException(string.Format("Exceeded timeout of {0}", timeout.Value));
}

This will make the client retry at increasingly random intervals.

One thing to keep in mind, if you don’t specify a timeout and the client holding the lock terminates abruptly (Dispose doesn’t get called), all your other clients will be deadlocked indefinitely. A possible solution to avoid this behavior would be to limit the timeout to 1 minute internally and implement a timer within the DataCacheLock class that would call ResetObjectTimeout every 30 seconds and extend the object’s timeout for another minute for example.

Advertisements

Activator.CreateInstance Optimization

July 12, 2013 Leave a comment

Reflection is a powerful feature of the .NET platform. Whether it’s for querying a type’s properties or creating instances of objects dynamically, reflection can help in many architectural designs. But as Uncle Ben said:

With great power comes great responsibility

In fact, as a programmer you have to be careful when you use reflection because it comes with a cost. In most cases, that cost is minimal and will not impact the performance or scalability of your application. But in some cases, that cost can truly bring your application to its knees. In this article I’ll analyze the performance of the Activator class and provide optimized implementations for most of its methods.

It’s important to note that the performance of the Activator class has been improved in .NET 4 compared to .NET 3.5.

image

There are many flavors of optimized CreateInstance implementations out there but I find most of them not really intuitive to use. There are generally 2 approaches to this problem: Compiling lambda expressions or generating dynamic methods in IL. Both approaches require code generation at runtime and therefore cannot be used without a JIT compiler (mono under iOS for example). The IL approach executes slightly faster than compiled lambdas so that’s what I’ll be using.

As Jon Skeet points out in his blog, invocation through reflection is quite slow and delegates provide a faster way of invoking methods. So my strategy to improve the performance of CreateInstance is to create and cache a delegate to the constructor of a given type.

Activator.CreateInstance<T>()

To optimize the statically typed version of CreateInstance, we will use a static generic class which will hold the delegate to the constructor. So instead of calling:

Activator.CreateInstance<T>()

We will use:

Activator<T>.CreateInstance()

Simple and intuitive. Here’s the implementation:

public static class Activator<T> where T : class, new()
{
    public static Func<T> CreateInstance { get; private set; }

    static Activator()
    {
        CreateInstance = typeof(T).GetConstructorDelegate<T>();
    }
}

The magic happens in the extension method Type.GetConstructorDelegate<T> which we will cover later on. This statically typed Activator also works for constructors with parameters as long as you know the exact parameter types of the constructor signature you are targeting:

public static class Activator<T, TArg1> where T : class
{
    public static Func<TArg1, T> CreateInstance { get; private set; }

    static Activator()
    {
        CreateInstance = (Func<TArg1, T>)typeof(T).GetConstructorDelegate(typeof(Func<TArg1, T>));
    }
}

Which can be called like this:

Activator<T, TArg1>.CreateInstance(arg1)

You can create more versions of the Activator class depending on the number of arguments you want to support: Activator<T, TArg1, TArg2>, Activator<T, TArg1, TArg2, TArg3>, etc.

Activator.CreateInstance(Type)

To optimize this method we will create an extension method to the Type class. So instead of calling:

Activator.CreateInstance(type)

We will use:

type.CreateInstance()

Not as intuitive but this way we won’t have a namespace clash with multiple Activator classes. Another way would be to name the static classes FastActivator, FastActivator<T>, etc. and keep all the methods in one place. I’ll leave that up to you. Here’s how this extension method is implemented:

public static class TypeExtensions
{
    private static readonly ConcurrentDictionary<Type, Func<object>> _constructors = new ConcurrentDictionary<Type, Func<object>>();

    public static object CreateInstance(this Type type)
    {
        Func<object> constructor;
        if (!_constructors.TryGetValue(type, out constructor))
        {
            constructor = type.GetConstructorDelegate();
            _constructors.TryAdd(type, constructor);
        }
        return constructor();
    }
}

We can also create signatures with statically typed arguments:

public static object CreateInstance<TArg1>(this Type type, TArg1 arg1)
{
    return PrivateActivator<TArg1>.CreateInstance(type, arg1);
}

Which can be used like this:

type.CreateInstance(arg1)

A static method with its associated PrivateActivator class will need to be created to support more arguments. The implementation of the PrivateActivator is straightforward:

private static class PrivateActivator<TArg1>
{
    private static readonly ConcurrentDictionary<Type, Func<TArg1, object>> _constructors = new ConcurrentDictionary<Type, Func<TArg1, object>>();

    public static object CreateInstance(Type type, TArg1 arg1)
    {
        Func<TArg1, object> constructor;
        if (!_constructors.TryGetValue(type, out constructor))
        {
            constructor = (Func<TArg1, object>)type.GetConstructorDelegate(typeof(Func<TArg1, object>));
            _constructors.TryAdd(type, constructor);
        }
        return constructor(arg1);
    }
}

It’s important to note that the parameter types must match exactly the constructor signature as we are not dynamically figuring out inheritance.

Activator.CreateInstance(Type, params object[] args)

Unfortunately, I don’t have an optimized version of this method. If you look in reflector, it is madness. Optimizing it would be quite a challenge and I’ll leave that to someone else to figure out 😉

So now let’s have a look at the implementation of the Type.GetConstructorDelegate() extension method which is really the core of this implementation.

public static Func<TBase> GetConstructorDelegate<TBase>(this Type type)
{
    return (Func<TBase>)GetConstructorDelegate(type, typeof(Func<TBase>));
}

public static Func<object> GetConstructorDelegate(this Type type)
{
    return (Func<object>)GetConstructorDelegate(type, typeof(Func<object>));
}

public static Delegate GetConstructorDelegate(this Type type, Type delegateType)
{
    if (type == null)
        throw new ArgumentNullException("type");

    if (delegateType == null)
        throw new ArgumentNullException("delegateType");

    Type[] genericArguments = delegateType.GetGenericArguments();
    Type[] argTypes = genericArguments.Length > 1 ? genericArguments.Take(genericArguments.Length – 1).ToArray() : Type.EmptyTypes;

    ConstructorInfo constructor = type.GetConstructor(argTypes);
    if (constructor == null)
    {
        if (argTypes.Length == 0)
        {
            throw new InvalidProgramException(string.Format("Type '{0}' doesn't have a parameterless constructor.", type.Name));
        }
        throw new InvalidProgramException(string.Format("Type '{0}' doesn't have the requested constructor.", type.Name));
    }

    DynamicMethod dynamicMethod = new DynamicMethod("DM$_" + type.Name, type, argTypes, type);
    ILGenerator ilGen = dynamicMethod.GetILGenerator();
    for (int i = 0; i < argTypes.Length; i++)
    {
        ilGen.Emit(OpCodes.Ldarg, i);
    }
    ilGen.Emit(OpCodes.Newobj, constructor);
    ilGen.Emit(OpCodes.Ret);
    return dynamicMethod.CreateDelegate(delegateType);
}

So this is pretty straightforward, we find the ConstructorInfo corresponding to the input arguments portion of the delegateType. We then create a dynamic method that matches the delegateType. With the IL generator we load the arguments (if any), call the constructor and return the object.

Summary

So we’ve covered a lot of ground in this article. We’ve optimized most of the CreateInstance methods, cached everything and made sure our implementation was thread-safe by relying on concurrent collections and generic static classes. But how does it perform you might ask? Here’s a chart showing a comparison assuming a warm cache:

image

Generic ConcurrentPool

July 9, 2013 Leave a comment

This situation is fairly common: you need to re-use the same class over and over and you wish you didn’t have to pay the price for multiple allocations and garbage collection. The .NET framework doesn’t come with a generic pool class unfortunately so you have to create your own. I’ve seen very complicated implementations as well as others that weren’t thread-safe.

The following generic implementation relies on the .NET 4.0 ConcurrentBag<T> for storage which is thread-safe. The capacity parameter specifies the initial capacity of the pool.

public class ConcurrentPool<T> where T : class
{
    private ConcurrentBag<T> _bag = new ConcurrentBag<T>();
    private Func<T> _factoryMethod;

    public ConcurrentPool(int capacity)
    {
        if (capacity < 0)
            throw new ArgumentOutOfRangeException("capacity");

        if (typeof(T).GetConstructor(Type.EmptyTypes) == null)
            throw new ArgumentException(string.Format("Type '{0}' " +
                "doesn't have a parameterless constructor. " +
                "Specify a factoryMethod.", typeof(T).Name));

        _factoryMethod = () => Activator.CreateInstance<T>();
        Initialize(capacity);
    }
    public ConcurrentPool(int capacity, Func<T> factoryMethod)
    {
        if (capacity < 0)
            throw new ArgumentOutOfRangeException("capacity");

        if (factoryMethod == null)
            throw new ArgumentNullException("factoryMethod");

        _factoryMethod = factoryMethod;
        Initialize(capacity);
    }

    private void Initialize(int capacity)
    {
        for (int i = 0; i < capacity; i++)
        {
            _bag.Add(_factoryMethod());
        }
    }

    public virtual T Take()
    {
        T item;
        return _bag.TryTake(out item) ? item : _factoryMethod();
    }

    public virtual void Add(T item)
    {
        _bag.Add(item);
    }
}

As more objects are requested, new instances will be created. Note that the Take and Add methods are virtual if you need to perform some specific logic when taking or re-adding an object to the pool. You can also implement the IProducerConsumerCollection<T> interface in the ConcurrentPool if this is something you need (I’ve omitted it to keep this article short).

Any other IProducerConsumerCollection could be used as the underlying collection (ConcurrentQueue or ConcurrentStack for example). I’ve used the ConcurrentBag here because it provides the best performance out of those 3 for retrieval from what I’ve measured.

Overlay images with GDI

July 8, 2013 2 comments

Having good icons in your applications can really help users understand the relationships between their actions and the data. As a programmer you want to spend less time creating icons and more time implementing your features. This article shows you how to combine images at runtime to create state images or simply to add overlays to an image.

State images are used in many applications. For example in Visual Studio they are used to represent the source control status of a file:

State Images

Such images are typically 24 pixels wide by 16 pixels high. In this example the state portion of the image is 8×16 while the file icon is 16×16. Assuming you have an 8×16 PNG image for each FileStatus, here’s how you would combine then with a simple extension method (assuming you have pre-populated a dictionary with status images):

public static Image WithStatus(this Image image, FileStatus status)
{
    if (image == null)
        throw new ArgumentNullException("image");

    Image result = new Bitmap(24, 16);
    using (Graphics g = Graphics.FromImage(result))
    {
        g.DrawImage(_statusImages[status], 0, 0, 8, 16);
        g.DrawImage(image, 8, 0, 16, 16);
    }
    return result;
}

In other scenarios you might just need to add an overlay without changing the original size of your image:

Overlay1 Overlay2Overlays

To accomplish this you can use the following extension method:

public static Image WithOverlay(this Image image, Image overlay)
{
    if (image == null)
        throw new ArgumentNullException("image");

    if (overlay == null)
        throw new ArgumentNullException("overlay");

    int width = image.Width;
    int height = image.Height;
    Image result = new Bitmap(width, height);
    using (Graphics g = Graphics.FromImage(result))
    {
        Rectangle rect = new Rectangle(0, 0, width, height);
        g.DrawImage(image, rect);
        g.DrawImage(overlay, rect);
    }
    return result;
}

The nice thing with extension methods is that you can combine them programmatically to create powerful transformations with a single line of code:

return image.Disabled(true).WithOverlay(overlay).WithStatus(status);

GDI is relatively fast enough to create those bitmaps on the fly at runtime. You can obviously cache the resulting images if the performance becomes an issue though. This solution works well if you are using Windows Forms but I would not recommend it with WPF as there are better approaches. You might have noticed the Disabled() method in the snippet above. In the next article I’ll show how to create a disabled image with GDI.