Tuesday, June 03, 2008 1:45 PM
Dividing up work to run in separate threads can be really challenging. Proper division of labor, synchronization, scheduling, and all that is just a tough job. I've gotten pretty well-versed in Windows concurrency using the standard Windows.Threading classes (many of them wrapping the Win32 entities). Understanding semaphores, mutexes, locks, wait queues and other related concepts takes some real work and head stretching. Once you understand them though, you may still struggle with actually fitting them into your code properly. In many cases, you just need to run some code in parallel with your UI. Much of this doesn't even apply then. A BackgroundWorker object will serve your needs just fine in many cases. On the other hand, if you are batch processing and want to divide up a large quantity of work items to multiple threads (especially when the work is network-bound rather than CPU-bound), it's easy to make a fatal mistake that will overwhelm your system resources, lock up your application, or worse still -- corrupt data. I worked with the Intel Threading Tools some time ago and really liked the idea. I also played with OpenMP a bit and I could really see the advantage. Both are libraries that make it substantially easier to divide up work for concurrency by "marking up" your standard serial code in various ways. Unfortunately, these are not managed code tools.
Microsoft just released the second CTP of Parallel Extensions to the .NET Framework. This supports task parallelization, data parallelization (using LINQ), and shared state coordination facilities. I haven't actually written any code with it yet, but it looks very promising. Microsoft has been starting to push the idea of parallel code, and I've blogged about it in the past. Even large-scale commercial projects don't do enough to execute tasks in parallel. I shouldn't have to wait for my media player while it's indexing. I shouldn't need to wait for my photo software to tag images. Apps shouldn't lock up while synchronizing with a server. Even if I'm locked out of making changes, the application itself should never freeze, and I should always be in control. Writing for concurrency from the start solves this problem. Hopefully these extensions, once mature, will make it easier for people to bake in parallel processing from the start.
More info: http://msdn.microsoft.com/en-us/concurrency/default.aspx
Source: http://blogs.msdn.com/somasegar/archive/2008/06/02/june-2008-ctp-parallel-extensions-to-the-net-fx.aspx