This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
paul nisset wrote:
What do you consider a good use case for parallel/concurrent programming?
I'd say, whenever it either improves the performance by a noticeable amount (if something is fast enough single-threaded, why bother with multi-threading?) or makes the programming easier. Basically, if there is some natural parallelism in the program that can be exploited, and it's worth the effort.
Joined: May 13, 2009
Thank you. I guess what I was asking is there a class of applications that lend themselves more naturally to Parallelism? For example a web service or a heavily used web app where each user session might get routed into one of several threads from a pool of threads ?
Yes, it's a good example. That's why the cloud computing can use a lot of parallelism: it handles a lot of inherently parallel requests.
Sometimes you can add the parallelism by partitioning the data in some obvious way. For example, if you handle the stock quotes, each stock symbol is handled independently from the others. So you can separate them into multiple threads, each one handling its own subset of symbols. As long as some data is independent from the others, it can always be separated into another thread. The difficulties start when the dependencies in the data processing appear.
You can find parallelism everywhere. Some examples:
- If you have a user interface which is not responsive, then this might be due to a long running task. A nice way to handle such a thing is to keep that long running task out of the main user interface thread and run it in the background. Then you may be able to only block a small part of the user interface while that task is running. This "pattern" is used a lot in the Eclipse IDE user interface for example.
- If you want to speed up a long running server task, then often such a task can be broken up in some parallel tasks. In such a case I draw the server process in a diagram (e.g. UML activity diagram). If you do not think parallel, then often you draw a sequential diagram, but often a lot of these sequential steps are unrelated to each other and may be performed in parallel. For example:
Start -> Validate order -> Persist order -> Update customer -> Inform logistics -> Send customer e-mail -> End
Parallel (the update customer, inform logistics and send customer e-mail can be executed in parallel):
Start -> Validate order -> Persist order -> (Update customer | Inform logistics | Send customer e-mail) -> End - The example which has been already mentioned, a system (e.g. web application) with multiple input channels (e.g. user sessions) which may not interfere.
Finally don't over-parallelize, as Sergey indicated, there is no need to complicate things if there is nothing to gain. On the other hand I advise you to experiment with it, because a lot of things look complicated when you have never done them before. And as you get more and more experienced with the subject and your tool set grows, you will be able to handle more difficult problems with more ease.