Take the 2-minute tour ×

A comment to another of my questions says that I can only run "so many" threads concurretnly, a notion which I have seen elsewhere.

As a threading novoice, how can I determine the maximum number of threads to use? Or is this a "how long is a piece of string" question? What does it depends on? Hardware config or what?

(VB in MS Visual Studio with .Net 3.5, if that matters)

Update: is anyone aware of any s/w tool which could suggest a number of threads (or tasks), or should I just code my own which keeps trying different numbers until thoughput drops?

share|improve this question
What are the threads doing? –  David Heffernan Jan 28 '11 at 12:43
+1 good question. They each make one SOAP call to transmit soem data and wait for it to return –  Mawg Jan 28 '11 at 12:58
Except, of course, that the "return" is asynch, so they are not really waiting. Other threads can run as soon as the SOAP request (fcuntion call) is sent over HTTP –  Mawg Jan 31 '11 at 6:29
add comment

4 Answers

up vote 5 down vote accepted

It depends on hardware as you're (probably) not using a theoretical computer but a physical hardware one, so you have limited resources.

Read: Does Windows have a limit of 2000 threads per process?

Furthermore, even if could run 5000+ threads, depending of your hardware, that could run much slower than a 10 thread equivalent program. I think you should take a look at thread pooling.

God bless

share|improve this answer
+1 Thanks. That gives me somethign to look at and start trying to understand. Are you aware of any s/w tool which could suggest a number of threads? –  Mawg Jan 28 '11 at 12:56
I guess that using one thread per CPU core is a sensible choice, but it really depends on the problem you're trying to solve. –  Trinidad Jan 28 '11 at 13:08
+1 With one per core it is going to be difficult to simulate hundreds of devices –  Mawg Jan 28 '11 at 14:14
If you're using a network device then all data will be sent in a serial fashion anyway, so I guess there'll be no performance gain there. I think maybe there's no need to have lots of threads, you could use one to keep sending data and another to read the results and identify to which request the response belongs, instead of having lots of idle threads sending data once and waiting for a reply. –  Trinidad Jan 28 '11 at 15:18
+1 a good point. Being SOAP, it's all just HTTP traffic –  Mawg Jan 31 '11 at 6:30
add comment

It very much depends on the machine - CPU and memory are the main limiting factors (though OS limits may come into it).

In regards to .NET the thread pool configuration also comes into play.

share|improve this answer
+1 Thanks for the feedback –  Mawg Jan 28 '11 at 12:58
add comment

Each thread consumes more memory (kernel stack, thread environment block, thread-local, stack....). AFAIK there are no explicit limit in Windows, therefore the constrain will be memory (probably the stack for each thread).

In Linux threads are more like processes (with shared memory) and you're constrained by:

cat /proc/sys/kernel/threads-max
share|improve this answer
+ tahnks for the info –  Mawg Jan 28 '11 at 14:15
Awesome reply, +1 for the command line hint –  user93692 Feb 7 at 20:03
add comment

Typically, the number of threads the run truly concurrently is determined by the number of CPUs and CPU cores (including hyper threading) you have. That is to say that at any given time the number of threads running (in the operating system) is equal to the number of "cores".

How many threads you can run concurrently in your app depends on a large number of factors. The best (lay man's) number would be the number of cores on the machine but of course that's like pretending no one (no other application) else exists :).

Frankly, I'd say do a lot more study on multi-threading in .NET/Windows because one tends to do more "damage" than good when one doesn't have a really solid understanding. .NET has the concept of a thread pool and you need to know how that works in addition to Windows.

In .NET 3.5/4.0 you should be looking at Tasks (Task Parallel Library) as the library does a much better job of determining how many threads (if at all) to spawn. With the TPL the threadpool gets a major overhaul and it is a lot smarter about spawning threads and task stealing etc. But you typically work with Tasks and not threads.

This is a complex area and as a result, the .NET framework introduced Tasks so as to abstract programmers from threads and therefore allowing the runtime to be smart about this while the programmer just say what she wants and not so much about how to do it.

share|improve this answer
+1 Yup, I fear that I might do more damage than good. I will also look at tasks, thanks –  Mawg Jan 28 '11 at 12:57
It's useful, I find, to distinguish between the terms "concurrency" and "parallelism" (i.e. what you referred to as "truly concurrent"). –  skaffman Jan 28 '11 at 13:19
+1 good point, thanks –  Mawg Jan 28 '11 at 14:14
add comment

Your Answer


