Taking Advantage of Multiple CPUs
A few months back I wrote about the Map Reduce pattern made popular by Google. It is one example of techniques taking advantage of multi core and/or multi CPU hardware. Map reduce takes work and shards it, distributes the work close to the data, retrieves the results from each of the processes and stiches the final results back together.
Today Jim writes in with other techniques he has used to take advantage of multi-threaded applications. Multi-threading is a technique many developers avoid due to the challenge of synchronizing threads. Synchronizing threads and managing dependencies of multiple threads are just a couple of many issues that may arise. The parallel Dot Net threading libraries make this kind of programming much easier. So, if you’re interested in parallel thread management, it is a good library to consider.
Even LINQ has been optimized to take advantage of multiple threads. Often referred to as PLINQ (Parallel LINQ) this library maintains a straight forward syntax for dealing with sets while allowing work to be distributed across multiple threads.
Here are some thoughts from Jim…
I note your column of Jun. 26, 2012 on thread pools and multithreading.
The techniques for concurrent, interleaved processing have been used for decades. On a single CPE system, they let us to exploit the difference in speed between the CPU and IO subsystems. The limiting factors were memory, I/O bandwidth, and the sophistication of the code. In one case, I wrote an I/O driver that spawned a task for every write operation; which was scary fast to the user, who never had to wait for a write to complete before moving on to the next task.
Java and .Net offer additional opportunities to exploit the hardware’s multitasking capabilities, as do layered development, message queues, frameworks, and products like Hibernate.
Clever programming, especially when quick response is part of the SLA, goes a long way toward getting the full benefit. De-serializing code takes effort and involves that anathema of many developers: risk. Synchronizing the results of several threads can be tricky and debugging in a dynamic landscape is more difficult than back-stepping through a static stack trace. But, it’s worth it.
Assess the risk if a thread or task fails. Include a recovery, repair or retry mechanism in the design (e.g., save the key of an email confirmation to be sent; build a process that checks for and retries unsent items – I know, that’s a queue, thinly disguised; I’m just using it as an example). BTW, an event driven, rather than polling, queue manager generally exploits multithreading.
Understand the concept. Look for opportunities. Go boldly!
I hope you have found this series interesting. Perhaps it has given you some ideas for areas you wish to do more research.
Cheers,
Ben
SSWUGtv
With Stephen Wynkoop
Cloud can be challenging, so what should you do to make sure your ‘stuff’ is safe? Patrick Townsend is on today’s show with the answers!
Watch the Show
$$SWYNK$$
Featured Article(s)
Do you risk hiring someone that is under-qualified?
In today’s tight economy, many employers contemplate hiring under-qualified candidates at a lower rate. Should you take on a promising employee that you know you’ll have to spend substantial time training, but could pay off? And if so, how do you identify such a candidate?
Featured White Paper(s)
How to Use SQL Server’s Extended Events and Notifications to Proactively Resolve Performance Issues
read more)