Microsoft Research and the CLR team are working on something called the Task Parallel Library, which looks like it will make .NET-based parallel processing a whole lot easier than it is today. The library is supposed to be released as a CTP sometime yet this year.
The article in MSDN Magazine has all the details, and is a great read. The parallel “for” loop looks extremely useful, and accordingly gets a lot of column inches in the article — including some tips on how much parallelism is too much, and things to think about when you tune its performance. They’ve also got a convenient way to execute two (or more) methods in parallel. The higher-level stuff is all implemented in terms of task and future classes that you can use on their own.
One of the best things about this library is that it handles exceptions nicely. If you run a loop in parallel, and any of the parallel threads throws an exception, all the other threads are canceled, and the exception is re-thrown in the place you originally started the loop — just like it would be if you’d used an ordinary “for” loop. This exception handling is baked into the base Task class, so it’s there for everything in the library.
I particularly liked some of the ways they squeeze the best performance out of the library. For example, if you create a future, and later you ask for its return value, but it hasn’t yet started to run, it’ll just be run immediately on the calling thread. No task switching. That’s kinda cool! They also optimize for single-core (e.g., Parallel.For just runs as a simple loop if you only have a single-core processor), and they scale up the number of worker threads if there’s a lot of blocking going on.
All in all, this looks like it’ll be a terrific library when it ships. Of course, I found this article after I’d put experimental multithreading support into DGrok! I’ll probably rip out my code and use theirs when they ship — they’re much more expert at multithreading than I am, so not only are they a lot more likely to get all the fringe cases right than I am, but they should be faster than mine as well.
Thanks to Allen Bauer for the link to the MSDN article.