I would like to close this month with the comparison of Parallel.For and serial for loop. For comparison, I took an INEFFICIENT algorithm to find if a given number is prime. Here is the algorithm:

Here is the serial for loop to find the primes from 2 to 100000:

And here is its output:


Note down the Thread ID, and it took 24511 milliseconds. And here is its equivalent Parallel code:



Here comes the output:

Did you notice that 6 different threads run the code in parallel and it took 18220 milliseconds? The Parallel class uses Task class behind the scenes, to parallelize the loop iterations. And depending upon the number of cores of your CPU, it determines the optimal number of threads and assigns these tasks to the threads.

This program determines prime number in a big range of 100000 numbers. But if you replace the both programs for less numbers, say 5000, or 10000, then the serial for loop will be more efficient. Because, Task objects creation incurs overhead and exceeds the solution time. So, if your problem is small try to avoid parallelize your code.

Breaking and Stopping Parallel Loop in Task Parallel Library

What if you want to exit from a Parallel.For method, like you could with for loop? You can not write code like this:

The problem here is that, For is a method of class Parallel. It is not a loop. And you can not exit from a method except with return statement.
The Solution:
TPL Team came with a great idea. You can pass in a delegate, which takes two parameters. On is the loop counter, and the other is of type class ParallelLoopState. ParallelLoopState has two methods to deal with exiting from loop:
Parallel.Break() is shared with all other concurrent threads in the system which are participating in the loop's execution. After calling Break(), no additional iterations past the iteration of the caller will be executed on the current thread, and other parallel workers will be stopped at their earliest convenience.

Parallel.Stop() is shared with all other concurrent threads in the system which are participating in the loop's execution. After calling Stop(), no additional iterations will be executed on the current thread, and other parallel workers will be stopped at their earliest convenience.

So, to stop the loop you should write the code as follows:


For a comprehensive overview of Parallel visit This Blog Post

Parallel Programming with .NET Framework 4.0

         In the mscorlib.dll version 4.0.0.0 there are three main namespaces: System.Threading, System.Threading.Tasks and System.Collections.Concurrent. System.Threading contains types like ThreadLocal, ParallelOptions, ParallelLoopState, ParallelLoopResult, Parallel, ManualResetEventSlim to name a few.
         System.Threading.Tasks contains Task, Task, TaskFactory etc to use the Task level parallelism. While the System.Collections.Concurrent contains the generic collections to work with data in thread save manner.
         To get started with TPL, there is simplest class Parallel in .NET Framework 4.0. Lets see what does it have to offer. It has four main methods Parallel.For, Parallel.For<>, Parallel.ForEach<> and Parallel.Invoke. First three methods are, as their names imply, provied to parallelize the loops. These methods have a lot of overloads to cover vast scenarios. While, Parallel.Invoke method has two overloads and just takes the array of Action delegate and invokes them in parallel.
         And here is an example of simplest for method:

Parallel.For takes three arguments: two integers and the third parameter Action delegate. This third delegate parameter is executed parallel on a multi-core machine.

Task Parallel Library (TPL) in .NET 4.0

Untill now, I have written about major enhancements to C# 4.0. Today, I want to talk about what is coming with the .NET Framework 4.0. There are a lot of new things coming with .NET 4.0, WPF 4.0, WCF 4.0, WF 4.0, Code Contracts to name a few. But for the matter of this post, I would like to throw light on the Task Parallel Library (TPL from now on, to save me typing).
TPL is the enhancement to the .NET Framework to make concurrent programming on multi core systems easier. We had an option previously to write parallel programs, Threads, but it was "expensive" and difficult. With "expensive", I mean, you have to create a thread object and it incurs system overhead. And by "difficult", I mean, it is very difficult to synchronize access to shared resources and finding dead locks etc.

The .NET Framework 4.0 provides another "high-level" layer on top of the stack to make our lives easier. Now, we don't need to create "Thread" ourselves. We only create a Task (class), and pass in the delegate or method to execute. The underlying framework determines itself either to create a thread or not for the particular task or to assign it to already executing task. Before I go into the details about the TPL, I would like you to read this post by Daniel moth.
In which he describes the "major over hauling" of ThreadPool in .NET 4.0.

C# 4.0 Consume First

C# 4.0 is coming with a great new feature, Consume First. You can consume any type first and define it after consuming. Lets jump straight into the coding, and see how does it work. Start by creating a Console Application, and type a class name, that is not declared, in the main method. I used the ConsumeFirstClass for this example. The intellisence doesn't show the class:

when you type the assignment operator, =, and new the intellisense starts showing this class:

Remember the class name is underlined because we don't have defined it. Now write an arbitrary method, I wrote ConsumeFirstMethod:

Our class object is showing in the intellisense. And pass in the string parameter, you can pass any thing, the method takes as parameter.
Now place the cursor on the ConsumeFirstClass variable declaration and press Ctrl + . to show the available options:


Select "Generate class for 'ConsumeFirstClass' ". Now visual studio 2010 places a new file named ConsumeFirstClass.cs.

Now go the the method call to ConsumeFirstMethod, press Ctrl + . (dot) and select Generate method stub ...

The class definition looks something like this:

The visual studio 2010 class generator is smart enough that it determined our method signature, it takes a string and returns an int.
Now remove the throw statement and place a return statement:

And here is the output...

Ohhhhhhhhhh......... I think something went wrong. Let me fix it. Here is the fixed output:


That is for now. You can declare any type, enum, struct, class by this method. Yes, You can write a class AtomBomb and define a method Blast using Consume First.

C# 4.0 Generics and Variance

Yesterday I blogged about using the variance with delegates. Today I will expand that discussion to the Generics. In C# 3.0, arrays are co-variant, meaning array of a child class is also an array of its base class. e.g.
string[] astr = new string[] {"a", "b", "cde" };
object[] aobj = astr;
There was no support for generic variance.
C# 4.0 introduces covariance and contra variance. And changes the definition of IEnumerable to IEnumerable<out T>. The <out T> specifies that if there is a method which takes Enumerable, then the programmer can also pass the IEnumerable<"Derived class of T">. Consider this code:

PlayAll method takes an IEnumerable and two calls to this method inside main work well even we pass IEnumerable and IEnumerable. Because IEnumerable is covariant, so it is legal to pass any derived types IEnumerable where a base class IEnumerable is required.

Delegate Covariance and Contra-variance in C# 4.0

C# 4.0 introduces co and contra-variance. Consider this code:

The out and in keywords in the delegate definitions above specify the delegates to be co or contra variant. out keyword says that, Child class of T can be used instead of T in Func1 definition. While in keyword specifies that the base class of T can be used instead of T in Action1 definition.
Try to play with this code, and try switching the places of out and in keywords in the above delegate definitions.

C# 4.0's new Keyword 'dynamic'

CSharp 4.0 introduces a new keyword dynamic. This keyword is introduced in C# to make interaction of CSharp with Dynamic Languages, JavaScript, Python and Ruby etc, easier. About the dynamic keyword, Anders Hejlsberg says "The dynamic keyword says that the static type of this variable is 'dynamic'.". i.e. I don't know the type of this variable at compile time. So, leave it untill run time. But I can call any method defined on the type. These method calls would be made to the actual method defined. If that method is not defined, a run time exception would be thrown.

For example, we have a JavaScript calculator. We want to use that in C# 3.0 or below. We will have to go to the .NET Reflection. Reflection is very slow mechanism. But with C# 4.0, we will write:



GetJSCalculator() method will return the JavaScript calculator at run time. For more information visit these links:
http://blogs.msdn.com/cburrows/archive/2008/10/27/c-dynamic.aspx
http://blogs.msdn.com/samng/archive/2008/10/29/dynamic-in-c.aspx
http://gsraj.tripod.com/dotnet/reflection.html

Optional and Namded Prameters in C# 4.0

C# 4.0 is coming with a lot of new features. Covariance, Contra-variance, dynamic programming, optional parameters etc. Today I'll talk about my most favorite feature, which was available in C++, optional parameters.
We can use the optional parameters to reduce the number of method overloads. For example, upto C# 3.0 we had to write:

public class Complex
{
private double real, imag;
public Complex()
{
real = imag = 0.0;
}
public Complex(double r)
{
real = r;
imag = 0.0;
}
public Complex(double r, double img)
{
real = r;
imag = 0.0;
}
}

Now with C# 4.0, we can write above Complex class with a single constructor:
public class Complex
{
private double real, imag;
public Complex(double r = 0.0, double img = 0.0)
{
real = r;
imag = 0.0;
}
}

But, with C# 4.0, a new gift comes free. Named Parameters, not available in C++, make the order of parameters irrelevant. Consider this Main method:

public class Program
{
static void Main()
{
Complex c = new Complex(img:4.0); //Pass imaginary value, real is 0.0 by defalult
Complex c1 = new Complex(r:4.0); //Pass real value, imaginary is 0.0 by defalult
Complex c2 = new Complex(); //dont Pass any value, both are 0.0 by defalult
}
}

The parameters names are from the method definition.

TemplateBinding in Silverlight

A week ago, or two, on silverlight forums there was a question regarding the TemplateBinding of background property to foreground. The question was:
Can I bind background property to foreground property? I tried this but it didn't work:

<ControlTemplate Key="btnTemplate" TargetType="Button">
<Rectangle>
<Rectangle.Fill>

<SolidColorBrush Color="TemplateBinding Background.Brush">
</SolidColorBrush>

</Rectangle.Fill>

</Rectangle>
</ControlTemplate>

The Red Color code is the main problem. We can bind properties of same Type regardless of their name. The problem here is that, the type of Background is Brush while the programmer is specifying a concrete class SolidColorBrush. Background is not necessarily of type SolidColorBrush. It can be RadialGradientBrush, VideoBrush, DrawingBrush etc. Here is the right code:

<ControlTemplate Key="btnTemplate" TargetType="Button">
<Rectangle Fill="{TemplateBinding Background}" />
</ControlTemplate>

Moral:
Don't try to restrict your options to only SolidColorBrush if it provides you with the richness of other Brush(es), also.