When I wrote about Microsoft's Parallel Extensions Library in April, I had studied the documentation and followed its progress pretty closely. Over the last few months, I've had the chance to gain hands-on experience working with the library, so it seems like a good time to write an update. (Author's note: I recently submitted an article about the Parallel Extensions Library to MSDN Magazine.)
In my previous post, I talked a lot about the constructs for parallelizing tasks, but there wasn't much to say about the data end of things (a number of readers commented about this shortcoming). With the June 2008 CTP release of the library though, things have changed. The latest release includes a number of objects to build thread-safe (whatever your definition of thread-safe may be) components. There is a new Collection object that is thread safe. There is also a new SpinLock object, which I really like; it works similar to using a monitor or a critical section (with the "SyncLock" block in VB.NET or "lock" in C#). Unlike monitors or critical sections, SpinLock does not require that you provide it with an object that the lock operates on. Instead, SpinLock is an object that you instantiate, and you simply call its Enter() and Exit() methods. Is this a major breakthrough? Of course not. If I had to guess, I suspect that SpinLock just maintains an object inside of itself and calls Monitor.Enter() and Monitor.Exit() on that object. It does, however, make the conceptualization a bit clearer when working with multithreaded code, which is always an improvement.
It's insanely easy to use the new parallel versions of methods, which include Parallel.ForEach() and Parallel.For(). It only takes a little bit of work to turn existing code into a lambda expression suitable for use in these methods. You will you need to make some changes to existing code. For example, the "break" statement ("Exit For" in VB.NET) makes little sense when the loop is not sequentially iterating. Instead, you send a signal to the loop via a ParallelState object (it's very similar to how the BackgroundWorker handles cancellation and such) to request that it stop as soon as possible. There are other changes, but this is the big gotcha that I've found so far.
One area where the Parallel Extensions Library is lacking is the documentation. I know this is a CTP, but for the few dozen objects (each of which only has a few properties and methods), the Help file needs more than a "stub" description for each item. I spent more time trying to figure out the "why" rather than the "how" because the documentation is so poor. I don't think that this package can leave CTP status until the documentation is of better quality. The only thing that keeps this from being a showstopper to using the CTP is that, the package makes the work so easy compared to how the work usually gets done, the concepts involved are much easier to grasp. In other words, a poorly documented Parallel Extensions Library is still much easier to deal with than a well-documented implementation using monitors, semaphores, etc. and expecting the developer to figure out on their own how to write a parallel "foreach" loop.
Another sign of the Parallel Extensions Library's CTP status is the list of known bugs in the documentation. While it is great that Microsoft is finding bugs to fix, it shouldn't be called "production ready" until those bugs are fixed.
Overall, I was pretty impressed with the library. I was working with it to transform code written to operate sequentially to code that worked in parallel. It took me less than 15 minutes to make the transformation, which included turning the existing code into a lambda expression, making the needed changes within the code, adding data locks, and so on. The code worked with zero found defects after the transformation, too. It used to take me well over an hour, and much longer than that if I wanted to do things like artificially limit the number of running threads when I would do this work by hand, and the code would be filled with errors.
If you are working on a project that could benefit from a multithreaded operation or parallel processing, you should check out the Parallel Extensions Library.
J.JaDisclosure of Justin's industry affiliations: Justin James has a contract with Spiceworks to write product buying guides.
———————————————————————————————————————————-Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!
Justin James is the Lead Architect for Conigent.