DynamicMethod in C#

DynamicMethod, One of the interesting and not so useful feature in .NET 2.0. It is a part of System.Reflection.Emit namespace. It allows to create and execute the methods at runtime without creating any dynamic assembly or dynamic type. It has one interesting thing; when a DynamicMethod is bound to a type, it will have access to all private and public members of that type.

Below is one simple sample for using the DynamicMethod

static void Main(string[] args)

{
Type[] helloArgs = { typeof(string), typeof(int) };
DynamicMethod hello = new DynamicMethod("Hello",
typeof(int),
helloArgs,
typeof(string).Module);


Type[] writeStringArgs = { typeof(string) };
MethodInfo writeString = typeof(Console).GetMethod("WriteLine",writeStringArgs);
ILGenerator il = hello.GetILGenerator(256);
// Load the first argument, which is a string, onto the stack.
il.Emit(OpCodes.Ldarg_0);
// Call the overload of Console.WriteLine that prints a string.
il.EmitCall(OpCodes.Call, writeString, null);
// The Hello method returns the value of the second argument;
// to do this, load the onto the stack and return.
il.Emit(OpCodes.Ldarg_1);
il.Emit(OpCodes.Ret);
object[] invokeArgs = { "\r\nHello, World!", 42 };
object objRet = hello.Invoke(null, BindingFlags.ExactBinding, null, invokeArgs, new CultureInfo("en-us"));
Console.WriteLine("hello.Invoke returned: " + objRet);
}

Design Patterns - Fire and Forget Pattern

Often in modeling for application development, you want a process to call another process and continue the process flow without waiting for a response from the called process. This pattern is called the "fire and forget" pattern.
This can be achieved in C# using the delegates.
Delegate has the following options which will help to achieve the fire and forget pattern.
Invoke (Synchronous)
BeginInvoke and EndInvoke (Asynchronous)
DynamicInvoke (Synchronous)

The difference between Invoke and DynamicInvoke is that, Invoke needs the instance of object to execute the method while DynamicInvoke doesn't need. We will be using BeginInvoke, EndInvoke and DynamicInvoke to achieve the "Fire and Forget" pattern.

public class ThreadUtils

{
delegate void DelegateWrapper(Delegate d, object[] args);
static DelegateWrapper wrapperInstance = new DelegateWrapper(InvokeWrappedDelegate);
static AsyncCallback callback = new AsyncCallback(EndWrapperInvoke);

public static void FireAndForget(Delegate d, params object[] args)
{
wrapperInstance.BeginInvoke(d, args, callback, null);
}

static void InvokeWrappedDelegate(Delegate d, object[] args)
{
d.DynamicInvoke(args);
}

static void EndWrapperInvoke(IAsyncResult ar)
{
wrapperInstance.EndInvoke(ar);
ar.AsyncWaitHandle.Close();
}
} 

This "ThreadUtils" class is provided by Peter A Boomberg in his article on "Fire and Forget" pattern.

FireAndForget method takes delegate as input and invokes it's own delegate asynchronously and that delegate executes the one you have provided synchronosuly. At the same time, ThreadUtils class takes care of the dirty job of calling EndInvoke on the internal delegate using the AsynCallback mechanism.

Invoking code: 

class Program

{
delegate void InsertDelegate(string first, string second, int num);

static void Main(string[] args)
{
Delegate dWrite = new InsertDelegate(WriteIt);
for (int i = 0; i < 1000; i++)
{
ThreadUtils.FireAndForget(dWrite, new object[] { "hoohoo", "hahaa", i });
}
}
static void WriteIt(string first, string second, int num)
{
//do some intesive IO operations
}
} 

Immutability in C#

Recently I was coming across with Patrick Smacchia's blog. He was talking about "Immutabiltiy". He says "There is a powerful and simple concept in programming that I think is really underused: Immutability".
He says that, make the objects immutable if their state is not going to change during the course of time. In this way we are avoiding the additional overhead of maintaining synchronization between the threads in mutithreaded applications.

The following are the 3 great benefits of Immutable objects

• Simplify Muti-threaded programs
• Can be used for Hashtable keys
• Simplify state comparision

Immutability in C# can be achieved using "const" and "readonly" keywords. They are used by the C# compiler to ensure that the state of a field won’t be changed once an object is created.
The "readonly" keyword allows state modification within constructor(s) while the "const" keyword doesn’t.

Extension Methods in C#

Recently, I come across with the blog of Troelsen. He was mentioning that "Extension" methods in .NET 3.5 are good example of "Decorator Pattern". Here is the sample for extension method which satisfies the "Decorator Pattern" definition.

Decorator Pattern - Definition:

The decorator pattern provides a formal way to add new functionality to an existing type, without sub-classing. This will be useful when the class is sealed and classic inheritance will be not feasible to use.

Sample code:


public class TextMessage
{

string _message = string.Empty;
public string Message
{

get { return _message; }

set { _message = value; }

}

public void Display()
{

Console.WriteLine("Here we go: " + _message);

}

}

public static class TextMessageExtensions
{
public static void DisplayWithHello(this TextMessage tm)
{

Console.WriteLine("Hello");

tm.Display();
}

public static void DisplayWithHi(this TextMessage tm)
{

Console.WriteLine("Hi");

tm.Display();

}

}

Race condition, Dead lock, Live Lock and Starvation in multithreaded applications

Race Condition


A race occurs when two or more threads in a mutithreaded program try to access the same shared data and at least one of the accesses is a write operation. Races are hard to identify. The consequences will be visible at a much later time or even in totally different part of the program itself.

Deadlock

A deadlock occurs when two or more threads wait on each other, forming a cycle and preventing all of them from making any forward progress. Deadlocks are usually introduced by developers trying to solve the race conditions.

Starvation

Starvation is an idefinite delay or permanent blocking of one or more runnable threads in a multithreaded application. hreads that are not being scheduled to run even though they are not blocking or waiting on anything else are said to be starving.

Livelock

Livelocks occur when threads are scheduled but are not making forward progress because they are continuously reacting to each other's state changes. High CPU utilization with no sign of real work being done is a classic warning sign of a livelock. Livelocks are incredibly difficult to detect and diagnose.