How many threads is too many?

[Alexander Walker]

Hello

Is it inefficient to create an application that has many threads that
individually may do a small amount of work over a given period of time as
opposed to an application that has a smaller number of threads that do a larger
amount of work over a given time period

here is an oversimplified example

application 1 has 4 threads
every second each thread makes an http request for a file on a different server
and then saves the file it requested to disk

application 2 has 1 thread
every second the thread makes four http requests for a file to four different
servers one after the other after each request it saves the file to disk

you could say that application 1 and application 2 do the same thing, but they
do it in different ways

how expensive is it to switch between threads?

image application 1 and 2 where doing something other than requesting files,
such as reading or writing from a database or executing some operations on data

I ask this because I have a windows service that creates 4 threads, the number
of threads it creates is variable so in the future it might create more threads
or less threads, each thread performs an operation every second, should I be
concerned about how many threads I'm creating? I think that I should, but I'm
not sure how to determine how many threads is too many

thanks

Alex

 

[Mark Harris]

I'd not be asking the question of how many threads is too many, but more
what are those threads doing, and can they be merged into one?

If your actions in each thread take a second to execute, and it needs to
be done every second then a single thread will not be fast enough as you
need to have four seconds to execute the four actions. However if those
actions only take miliseconds, or less then it would make sense just to
run them one after another. Additionally, is each of these actions using
CPU? or is it mostly low CPU/IO that is happening? If each thread uses
100% CPU for the second it runs in, threading would be pointless on
anything other than a quad CPU or dual core dual cpu system - each thread
would be competing for CPU to process.

For example, my application is going to find every computer on the network
and retrieve its computer name and logged in user assume this takes 3
seconds to do for each PC. If i did this all one computer after another
this would take a huge amount of time on a network with 100-200 PC's -
this is five to ten minutes to refresh the network list - pretty long.
However if i were to create a set of 60 worker threads thats handled the
100-200 PC's then you would be getting 60 PC's per 3 seconds. Thats 5-10
seconds for the list to refresh - much more sensible. However the 3
seconds it needs to wait is mostly network latency and computers talking
to each other, 0.02% cpu per thread if your lucky, and a few bytes/second
over the network. This situation is ideal for threading. A situation that
is not idea for threading would be scanning the hard drive (lots of IO
Wait) or performing complex math, eg drawing fractals (lots of CPU wait).

Hope this helps

- Mark

 

[Peter Huang [MSFT]]

Hi Alex,

Commonly the thread count depends on the concrete scenario in the operating
system and your concrete program request.
The Threads is scheduled by the Operating system. The OS will control when
to switch to another thread, and the thead may not be the second thread you
created in your process.

e.g. On a OS, there are many threads and many resources are occupied. In
this scenario, if you create a few threads, the performance may not
improve, maybe even worse.
or
You have a job which will finished in a short time which is not CPU
consuming. We do not need to handle it with more threads.


For you scenario, I think you may use a ThreadPool in your windows
Service, which will help to schedue your threads.
Here is link for your reference.
Programming the Thread Pool in the .NET Framework
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/ht
ml/progthrepool.asp

If you still have any concern, please feel free to post here.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Leon Lambert]

Just something to keep in mind. For the near future computing speed is
going to be gotten by going to multi-core computers. We will be seeing 4
computers on on chip soon and who knows how many more that will go up
too. Single thread applications will not take advantage of this
technology. So your application 2 would not take advantage of the new
technologies coming to your desktop soon. Of course this doesn't mean
hundreds of threads is a good thing.

Just something to think about
Leon Lambert

 

[Willy Denoyette [MVP]]

Note that this assumes that your application has only one single thread,
which is not the case in .NET where all applications have three threads to
start with. Something else to think about is that your application is not
the only one running on a system like windows, other processes may have
threads that need to be scheduled as well, in reality, you will never have
as many CPU's as there are (run-able)threads in a system, so a thread will
stay a precious resource and thread switching will remain a (too) costly
operation.

Willy.


| Just something to keep in mind. For the near future computing speed is
| going to be gotten by going to multi-core computers. We will be seeing 4
| computers on on chip soon and who knows how many more that will go up
| too. Single thread applications will not take advantage of this
| technology. So your application 2 would not take advantage of the new
| technologies coming to your desktop soon. Of course this doesn't mean
| hundreds of threads is a good thing.
|
| Just something to think about
| Leon Lambert
|
| Alexander Walker wrote:
| > Hello
| >
| > Is it inefficient to create an application that has many threads that
| > individually may do a small amount of work over a given period of time
as
| > opposed to an application that has a smaller number of threads that do a
larger
| > amount of work over a given time period
| >
| > here is an oversimplified example
| >
| > application 1 has 4 threads
| > every second each thread makes an http request for a file on a different
server
| > and then saves the file it requested to disk
| >
| > application 2 has 1 thread
| > every second the thread makes four http requests for a file to four
different
| > servers one after the other after each request it saves the file to disk
| >
| > you could say that application 1 and application 2 do the same thing,
but they
| > do it in different ways
| >
| > how expensive is it to switch between threads?
| >
| > image application 1 and 2 where doing something other than requesting
files,
| > such as reading or writing from a database or executing some operations
on data
| >
| > I ask this because I have a windows service that creates 4 threads, the
number
| > of threads it creates is variable so in the future it might create more
threads
| > or less threads, each thread performs an operation every second, should
I be
| > concerned about how many threads I'm creating? I think that I should,
but I'm
| > not sure how to determine how many threads is too many
| >
| > thanks
| >
| > Alex
| >
| >

 

[Michael C]

Note that this assumes that your application has only one single thread,
which is not the case in .NET where all applications have three threads to
start with. Something else to think about is that your application is not
the only one running on a system like windows, other processes may have
threads that need to be scheduled as well, in reality, you will never have
as many CPU's as there are (run-able)threads in a system, so a thread will
stay a precious resource and thread switching will remain a (too) costly
operation.

It's also not much use if each thread is pretty much idle.

Michael

 

[Nick Hounsome]

Just something to keep in mind. For the near future computing speed is
going to be gotten by going to multi-core computers. We will be seeing 4
computers on on chip soon and who knows how many more that will go up too.
Single thread applications will not take advantage of this technology.

You are making the rather rash assumption that your computer has nothing
better to do than run your app realy fast.

Last time I looked at the task manager there were over 100 processes running
and there will probably be more in future :-(

Most apps I've ever written are I/O bound anyway so provided that you don't
block your threads on a network call when there is something useful to be
done (usualy the GUI) then it doesn't realy make much difference adding more
threads except where it makes the code easier to understand.