coding-time.blogspot.com
[1]I admit that it's kind of a stretch to use the word now for a blog post that old.
1) You shouldn't lock on a type, because it can deadlock the entire CLR process (Type works like a multiton in .NET, so you get one actual instance per distinct type loaded into your AppDomain). MSDN points this out, in the docs on the Monitor class (I think) -- which is what lock() uses internally.
2) If you use Delegate.BeginInvoke(), it executes on a threadpool thread. Since you only get a limited number of these threads per process (by default), if you run a long-running calculation, you might end up freezing some other parts of your code. This is of particular importance in ASP.NET, since it makes heavy use of the ThreadPool.
3) If you loop over the EndInvoke() calls there, you're going to end up blocking on each one to wait for the threads to complete. While you obviously need to wait for all of the threads to finish, you might be tying up ThreadPool threads if some threads are stuck waiting to return results.
Here's some more info on this: http://www.lukepuplett.com/2009/05/using-delegates-oh-for-f-...
Also, I remember reading that the CLR team had to make some major changes under the hood to the ThreadPool and other related classes in order to get the parallel extensions to perform like they should.
Could they at least implement slices, map, and fold/reduce?