This is the kind of post you make, and immediately get 4 comments saying the class you requested is already in the framework....
I've been working a lot on multithreaded applications lately. I'm not specifically talking about taking advantage of multi-core CPUs on the client, but it's been clear for a while now that these are quickly becoming the norm and developers are going to have to adapt.
I've mostly been learning as I go, but it's made me realize that the tools available to developers are lacking. To be honest, I don't want to have to understand what the heck Greg Young is blogging about - he speaks a different language than me - I want tools and my programming language to help me out as much as possible. PLinq is interesting, but it's a minor part of the overall picture.
Java seems ahead of .NET when it comes to multithreading programming. They have true thread-safe collections that use lock-free algorithms. If you're doing multithreading programming, do yourself a favor and look up Lock Free Data Structures, you'll quickly realize that most of what you've read on MSDN as well as Microsoft own thread-safe collections are garbage. I've used Julian Bucknall's collections with quite a bit of success. It'd also be nice to have truly atomic variables in .NET, like those found in Java's java.util.concurrent.atomic package - there's something unsettling about playing with the Interlock class.
Like Chris Mullins, I wish there was an exposed ThreadPool class. I don't know if he ever solved his problem of thread starvation, but we've also had to write our own implementation because we couldn't guarantee all of our operations would be asynch. Coincidentally, if you're creating a socket server, there are numerous blog posts on the Conversant blog worth reading.
At the top of my wish list though is support for multithreading testing. Multithreaded applications might be hard to write, but they are a nightmare to test. It's easy enough to run multiple threads over your code, but I haven't yet seen (which doesn't mean it doesn't exist), something that lets you transparently test specific race and deadlock conditions. Was a waiting thread properly signaled? Was a deadlock properly resolved? So far my approach has been simply to put huge loads on the application and hope problems surface.