BlogEngine.Net 1.XX where have you gone?

When is multi-threading not a good idea?

18. September 2008 09:40 by Scott in   //  Tags:   //   Comments (3)
 
I was recently asked when not to use mulit-threading so I gave them the best answer possible.  I think my answer below fits the bill pretty nicely.
  1. On a single processor machine and a desktop application, you use multi threads so you don't freeze the app but for nothing else really.
  2. On a single processor server and a web based app, no need for multi threading because IIS handles most of it.
  3. On a multi processor machine and desktop app, you are suggested to use multi threads and parallel programming. Make as many threads as there are processors.
  4. On a mulit processor server and a web based app, no need again for multi threads because IIS handles it.

In total, if you use multi threads for other than un-freezing desktop apps and any other generic answer, you will make the app slower over time IF you have a single core machine.

Why? Well because of the hardware switches. It takes time for the hardware to switch between threads in total. On a multi core box, go ahead and use 1 thread for each core and you will greatly see a ramp up in speed at the start and over time as the cores heat up.

kick it on DotNetKicks.com
If you liked this post, please be sure to subscribe to my RSS Feed.

Comments (3) -

Greg Beech
Greg Beech
9/18/2008 4:38:06 PM #

Actually, it's a lot more complex than that. What you're saying is approximately true for CPU-bound applications, but if you have threads that are bound by other things (e.g. blocking on I/O completion ports, see technet.microsoft.com/.../bb963891.aspx) then using multiple threads per CPU can provide a significant performance benefit even on a single core machine.

Rob Desbois
Rob Desbois
9/19/2008 1:36:00 AM #

That seems a very limited view of the programming world..as Greg says, blocking I/O is a major consideration - I develop on an embedded platform running Linux receiving input from hardware components and acting on it, as well as performing Internet socket operations. MT is necessary here for independence between these elements.

The world is also not just made up of desktop apps and Web apps on IIS...

Threads are good for parallel data-processing algorithms, although I have no experience in this field.
There are, I'm sure, many other situations where they is beneficial, if not necessary.

philip
philip
9/19/2008 2:20:47 AM #

You havn't gone into the details at all.

Multi-thread applications suffer when the number of threads goes over a certain amount due to thread contention, eg, 100 threads in a process, the CPU spends more time switching between threads than it does processing them. In such a case it is better to consider why you have so many threads, splitting it up into different processes isn't a complete solution either, you have to consider clustering.

If your going multi-thread you should have a good reason for doing it - are you making a server that needs to handle many connections, consider how app servers and web servers handles it such as apache, they have a thread pool. Find out why. Also why not stick to the standards of J2EE or other technology and let the app server handle the threading and resources for you.

Honestly, the technical benefits do not out-weigh the complexity which you then face, you introduce un-necessary complexity to your code which you should avoid, its better to code less so there is less to maintain.

What other reason do you need to go multi-threaded? I think not many cases, a desktop app perhaps to prevent blocking UI, not many reasons to worry about it - there are standards which help to scale in most languages Java, .NET, PHP, if you follow them you can scale ok.