I'm Looking Forward To: Parallelism in .Net 4.0

I've written a lot here to date about what I've been able to do with SQL Server Integration Services and Data Warehousing - within my organization as well as within the community.  The largest push for me to do any and all of that is to address "pain points" - irritations with the current process, or a desire to do away with repetitive manual interaction.  I'm not only talking about relieving pain points that I run into.  Part of my job (and my passion) has always been to use what tools and knowledge I have to relieve others' pain points.  Because nobody pays me to make my own job easier - they pay me to make their jobs easier, and achieve better results doing it.
Today I'm going to look at things the other way.  Who out there is going to help me?  (Selfish question, isn't it!)  There are a few answers to that question, I'm glad to say.  I'm looking forward to some new technologies that are on their way, some learning opportunities, some economic recovery, and lots of other things.  Here's the first in (what will hopefully turn out to be) a series of posts to make you (and I) thankful to receive the fruits of other people's labour!
Parallelism in .Net 4.0
A great technological cherry I'm waiting for is in the .Net Framework v4.0 - Parallelism. 
Even before I went to DevTeach and listened to a very informative talk by Ranjan Sen, I was always disgusted by the waste in today's software.  Disgust is a strong word - but I mean it.  This is an era where "waste" in software development typically describes developers or applications that consume massive amounts of memory or disk space, but the kind of waste I'm talking about is a little unorthodox.  I don't know how you feel - but it's driven me to the point of insanity over the past few years having to wait for software to grind through what I've asked it to do - all the while watching it use only one of my processor's cores.  And I've only ever had a dual-core machine!  I would surely have been in the looney bin if I'd sprung for a quad-core.  (In fact, that's one reason I didn't!)
Upcoming in the .Net Framework v4.0 are some great advances in bringing parallel computing to the masses.  Let me start by saying that (AFAIK) there is absolutely nothing in here for the "hard core" parallel computing fan.  Everything a true power-user of .Net's threading capabilities is still there, relatively unchanged.  What is new is parallelism for developers (and applications) that don't understand (or don't have the time to understand) how to manually multi-thread their application.  The architect(s) who pushed for these changes in Microsoft is/are rock stars - I wish I could say he/she had groupies, but sadly, we all know they don't. 
The new capabilities make retrofitting parallelism into existing applications a ton easier, and using parallelism in a new application will be amazingly simple.  How are they doing that?  Not by adding more locking constructs, or thread pooling - no, those are still "too close to the metal" for developers uncomfortable with threading to feel good about.  What they've done is basically taken some common situations where threading would do an app some good, and built some language constructs to almost transparently support multi-threading for them.  Think "design patterns" for threading.
Future<T>
Let's take an example: populating controls on a form - say, dropdown lists.  Now, I'm an ancient developer - I'm not so into databinding and all that, and one of the reasons is that if I databind a combobox control to a database source, it's going to cause visible performance problems in my app at runtime as it goes to "fetch" the data.  So I've typically done this loading manually in a threaded manner, in order to provide a better UI experience.  The new capabilities in .Net 4.0 make this even easier, by introducing a new generic called Future<T> Quite simply, it makes anything you assign to that variable an asynchronous call, but on top of that, it automatically joins the spawned thread back once you actually want to use the results.  Take this code:
List<string> items = MyClass.GoGetItems();
List<string> otherItems = MyOtherClass.GoGetOtherItems();
// do some other work here
// now use my first item list
foreach (string item in items)
{
    cboItems.Items.Add(item);
}
// and now the second list
lblOtherItemCount.Text = otherItems.Count.ToString() + " items in other list.";
The problem with the above is that if it takes "GoGetItems" ten seconds to retrieve whatever it is that it's retrieving, those are ten seconds that the UI (and the user) has to wait.  Then they both have to wait again for "GoGetOtherItems"!
The Future<T> generic allows you to seamlessly spawn threads to handle those calls, like this:
Future<List<string>> items = MyClass.GoGetItems();
Future<List<string>> otherItems = MyOtherClass.GoGetOtherItems();
// do some other work here
// now use my first item list
foreach (string item in items)
{
 cboItems.Items.Add(item);
}
// and now the second list
lblOtherItemCount.Text = otherItems.Count.ToString() + " items in other list.";
What's happening here is that the call to GoGetItems is being started, but doesn't block the rest of the code from executing.  The call to GoGetOtherItems is made immediately, and so is the "do some other work here".  Transparently to you, the compiler recognizes that the start of the foreach loop is requesting use of the results of your first call.  If the spawned call to GoGetItems has already completed, it executes immediately.  If not, it waits until the results are available - again, all transparent to you, the developer.
More Capabilities
Add on to that the parallel for loops and other goodies - and I think you'll see this is a "good thing".  Here's hoping that developers everywhere start to use more than one core... and yes, I'm looking at you Microsofties!
Additional Information
On the Parallel Programming Team's blog:
.NET 4 Beta 1 is now available, with parallelism!
Parallelism Videos Galore
Parallel For Loops over Non-Integral Types