Multi-threading musings

Recently, my team and I have been working on an SOA implementation that uses some relatively “expensive” ESRI COM objects within the services tier.  For example, instantiating an IWorkspace can take a long time, relatively speaking.  Since ArcObjects are COM-based, clearly multi-threading isn’t going to solve all of our problems due to the thread affinity of STA objects, however if there is a long running WCF service that uses these expensive objects, we can create a “pool” of service connections complete with cached objects and have them ready for use by consumers of the service…effectively front-loading the performance hit to the service startup process.

So what we wanted was a managed thread pool…separate from the default thread pool so we’re not stealing resources from the core application…and nobody really relishes the opportunity to build their own thread pool from scratch.  At least I don’t. For info on when not to use the default system thread pool, check out Chris Mullins’ excellent post over here.  Here’s a couple of options we explored in the hopes that someone may find them useful.

Our first look was at Microsoft’s Concurrency and Coordination Runtime which is very kewl and, at least in its initial releases, featured only a token licensing fee for commercial use. Originally written for robotics development, the Dispatcher and DispatcherQueue objects provide the critical access to thread management functions.

The thread pool we finally wound up going with was the PowerThreading API from the good folks over at Wintellect. This is another good resource that Stacy Harris of Microsoft turned us on to and actually did alot of customization work on it for us to tailor it a bit more to our purposes. Curiously you must have a member login at the Wintellect site to even read about the product ????

Also, this little foray was my first deep dive into the world of mutli-threaded apps to any great level of detail. I simply haven’t had to leverage this functionality much in the past. Here’s a great starting point for all things threaded over at the TechRepublic.

Final musing: Once we got into the whole multi-threading thing, I started doing a quick code review on some existing patterns we had in place, and much like Chris Johnson, I noticed some issues with a couple of singleton patterns that I had implemented whilst I was completely ignorant of multi-threaded implications. In short, my implementations were not thread safe.  First, you could always start reading the MSDN exploration of the singleton pattern over here, but Jon Skeet’s summary of singleton pattern implementation options in .NET should be required reading for everyone IMHO.