Same syntax as System.Threading.Tasks so now[1] us poor enterprise drones, who can't see Visual Studio 2010 and .NET 4 being installed anytime soon, can get our feet wet.<p>[1]I admit that it's kind of a stretch to use the word now for a blog post that old.
This is a cool idea...but WOW! There are some major no-no's in that code.<p>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.<p>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.<p>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.<p>Here's some more info on this: <a href="http://www.lukepuplett.com/2009/05/using-delegates-oh-for-f-sake-moment.html" rel="nofollow">http://www.lukepuplett.com/2009/05/using-delegates-oh-for-f-...</a><p>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.
Disappointing but unsurprising that the data-parallel primitive in their standard library is the least-abstract, most-stateful implementation, <i>and is named For/ForEach!</i><p>Could they at least implement slices, map, and fold/reduce?