The Parallel.Do method is a static method that takes two or more delegates as arguments and potentially executes them in parallel.

So running Parallel.Do(MessMe); should be pretty much like running MessMe();

Parallel.For() actually runs the interations in multiple threads so it works faster but requires you to make sure the iterations are independent of each other.

When you ran For, you told the framework to do the work division for you, which means that you gave it more freedom to parallelize your code.

More here: msdn.microsoft.com/…/default.aspx

I’m not risking any other CTP\WIP bits installations now

Anyway, there’s a difference between running parallization on MessMe which contains a for loop inside than running Parallel.For whith a delegate that represent one loop iteration.

I don’t think Parallel.Do(MessMe); can go inside MessMe() and parallelize the fir loop inside it (it can’t know or assume that the iterations are not dependent and MessMe should be an atomic operation for it)

Eran, Omer – the question is not how to use it, but in current 3.5 RTM a lot of this concept already implemented

Back to connection of context.

Assembler – if you’re doing something wrong, you’re get very bad results

C++ – if you’re doing something wrong, you’re get blue screen or nothing works

C# 1.1-2.0 – you, probably, can do things wrong, but you’re going pay for it

C# 3.0-3.5+ – you, probably, do something wrong, ‘cos we have too much things to do wrong

C# 4.0 and up – I do not want to be developer, due to fact, that if I’ll do something ok, I’ll get very bad results

That’s my point:)

"please someone can explain me what exactly wrong I’m doing?"

Which to me read:

"how should I use this?"

But maybe I’m off here. What is the question being posed by this post?

Parallel.For will run the parallel delegate as many times as it can at the same time with the different inputs.

Your test is probably not very good in that you are writing to a static object. There could be locking issues there.

However, what you should bear in mind that your code spends most of its time in kernel mode, executing Console.KeyAvailable (which boils down to kernel32!PeekConsoleInput).  So this is really a bad example of parallelizing anything, since the majority of work here is polling the console input handle.

The following is a slightly better scenario which shows the added value of parallel extensions, because the work is CPU-bound:

       static int primeSum;

       static void Compute(int i)

       {

           for (int j = 1; j <= Math.Sqrt(i); ++j)

           {

               if (i % j == 0)

                   primeSum += j;

           }

       }

Take this method and call it 500,000 times and here’s what you get on my PC (a modest Core 2 Duo 1.86 GHz)…

Using a simple loop (from 0 to 500,000) it performs 40,900 operations per second with 50% CPU utilization.

Using Parallel.For (from 0 to 500,000) it performs 77,000 operations per second (which is really good, considering that the first few thousand invocations of Compute are really really cheap and therefore the overhead of the delegate call dominates), with 100% CPU utilization.

Using Parallel.Do it performs 40,400 operations per second (which is the amortized cost of the initial Parallel.Do overhead), with 50% CPU utilization.

All these results are perfectly on par with the way the parallel extensions are supposed to work.  In fact, it’s hardly magic – you could easily implement this kind of framework yourself.  What I find valuable here is that Microsoft finally released a parallelization framework which might actually be accessible for those 80% of developers who do not read blogs, read books or attend conferences.  And that’s what makes me happy.