I am tired of hearing people recommend that you should use only one thread per processor, while many programs use up to 100 per process! take for example some common programs

vb.net ide uses about 25 thread when not debugging
System uses about 100
chrome uses about 19
Avira uses more than about 50

Any time I post a thread related question, I am reminded almost every time that I should not use more that one thread per processor, and all the programs I mention above are ruining on my system with a single processor.

  • 7
    That recommendation is to broad. The limit of one thread per processor is appropriate only for computationally-bound applications. Most programs are IO-bound, whether it's network traffic, disk access, or even RAM. That's why web servers, databases etc. have thread pools with many more threads than processor cores. Jun 29, 2011 at 19:07
  • 2
    "I am reminded almost every time that I should not use more that one thread per processor"? Can you post links or examples? Almost every time?
    – S.Lott
    Jun 29, 2011 at 19:23
  • 2
    "...people recommend that you should use only one thread per process." Who are these people? Scheduling has advanced significantly since the Dark Ages. Jun 29, 2011 at 21:43
  • 2
    You should not have more than one UI thread per process.
    – SLaks
    Jun 29, 2011 at 21:58
  • 3
    @Billy ONeal, your edit made the question meaningless
    – SK-logic
    Jun 30, 2011 at 7:49

7 Answers 7


you should use only one thread per processor,

Possibly in HPC where you want maximum efifciency - but otherwise the stupidest thing I have heard today!

You should use the number of threads that are appropriate for the design of the program and still give acceptable performance.

For a web server it might be reasonable to fire a thread for each incoming connection (although there are better ways for very heavily loaded servers).

For an ide each tool running in it's own thread isn't unreasonable. I suspect many of the threads reported for the .Net IDE are things like logging and I/O tasks being started in their own threads so they can continue unblocked.

  • 9
    Now you've got me wondering what the stupidest thing you've ever heard is!
    – Michael K
    Jun 29, 2011 at 19:13
  • 3
    @Michael - I've taught undergrads and worked on defence contracts - you wouldn't believe the stupidest things I've heard! Jun 29, 2011 at 19:15
  • 1
    Have we seen them on TheDailyWTF.com ? Jun 29, 2011 at 19:27
  • i can't really find them now, but look at this link social.msdn.microsoft.com/Forums/en-US/vbgeneral/thread/…
    – Smith
    Jun 29, 2011 at 19:38
  • 2
    Have at most one CPU-bound thread per processor allocated to the application. IO-bound threads aren't a big problem (other than the memory they consume) and it's important to remember that apps can be restricted to only use a subset of the system's CPUs; after all, it's (usually) the user's/admin's computer and not the programmer's. Aug 15, 2011 at 12:33

The one-thread-per-core advice applies when the purpose is speed through parallel execution.

A completely different and equally valid reason is simplicity of code when it has to respond to unpredictable events. So if a program has to listen on 100 sockets, and appear to give its full attention to each one, that's a perfect use for threading. Another example is a UI, where one thread handles UI events, while another does background processing.

  • 1
    IO-bound processing can be done as one thread per event source, or multiple event sources could be multiplexed onto a single thread. Multiplexed code is usually both more complex and more efficient. Aug 15, 2011 at 12:36

You want one thread for each computation which can proceed at different rates than other computations.

For parallel CPU-bound computation, which comes in large blocks of work, you generally want one thread per CPU, because once they are all busy, more threads don't help and just create scheduler overhead. If the blocks of work have irregular sizes in time, or are generated dynamically at runtime (often happens when you have big complex data structures to process), you might want to attach those blocks to lots of threads, so a scheduler always has a large set to choose from when some block of work completes, to keep all the CPUs busy.

For I/O bound computation, you generally want one thread for each independent I/O "channel" since they communicate at different rates, and threads blocked on on channel then don't prevent other threads for making progress.

  • Just be aware that this style of threading can lead to some oddly-architected programs. I've seen a 4-threaded program that had a thread to read records from a DB table, a thread to write transformed records to a socket, a thread to read the answers to those socket writes (which came back out-of-order and asynchronously), and a thread to modify the original DB record with the answer. Unintuitive error conditions ensued. Jun 29, 2011 at 20:37
  • One view is that this style produces odd programs. Another view is this the natural style the programs should have had. Dunno about the "unintuitive" error conditions; if you have lots of things happening, and one of them gets an error, making sure it is propagated properly across the asynchronous computations is an issue for many langauges [stupidly, Java exceptions aren't defined at thread boundaries], but isn't an issue with the program style. (Our PARLANSE programming langauge [see my bio] handles exceptions across thread boundaries cleanly so it is possible to do this right.).
    – Ira Baxter
    Jun 29, 2011 at 22:13

The rule of thumb for threads is, you want at least one "active" (able to have its commands executed immediately given CPU time) worker thread for each "execution unit" available on the computer. An "execution unit" is one logical instruction processor, so a quad-chip, quad-core Xeon hyperthreaded server would have 32 EUs (4 chips, 4 cores per chip, each hyperthreaded). Your average Core i7 would have 8.

One thread per EU is the fullest use of the CPU's power, provided that the threads will always be in a running state; this is almost never the case, as threads need access to non-cached memory, the hard disk, network ports, etc. that they must wait for, and that don't require active CPU attention to perform. You can thus further increase overall efficiency with more threads queued up and raring to go. This does come at a cost; when a CPU switches a thread, it must cache the thread's registers, execution pointer and other state info normally kept in the innermost workings of an EU and very quickly accessed, allowing other EUs in that CPU chip to pick it up. It also requires threads in the OS to decide which thread should be switched to. Lastly, when an EU switches threads, it loses the performance gains of the pipelining that most processor architectures use; it has to flush the pipeline before switching threads. But, as all this still takes far less time on average than simply waiting for the hard drive or even RAM to come back with information, it's worth the cost.

However, in general, once you get beyond twice the number of "active" threads as EUs, the OS starts spending more of the EUs' time scheduling threads, and the EUs spend more time switching between them, than are actually spent running active threads of programs. This is the point of diseconomies of scale; it will actually take longer for a multithreaded algorithm to run if you were to add an extra thread at this point.

So, overall, you want to maintain at least as many threads in your program as you have EUs on the computer, but you want to avoid having more than double that number that aren't waiting or sleeping.

  • If N is the number of threads and U the number of units, the OP questioned the "N = U" rule. You're relaxing it to a "U <= N <= 2 U" rule. I'd go a bit further and say that "N <= c U" for a "reasonably small" constant (known to the programmer) c is acceptable (if benchmarks show reasonable performance). I would be very concerned if the number of threads can grow to a potentially unlimited number.
    – 5gon12eder
    Jan 16, 2017 at 21:15

You should use one thread for:

Each processor you need to keep busy.

Each I/O you can usefully pend concurrently that you cannot perform in a non-blocking way. (For example, reads from a local disk.)

Each task that requires a dedicated thread, for example calling into a library that has no non-blocking interface or where non-blocking interfaces aren't appropriate. This includes tasks like monitoring the system clock, firing timers, and so on.

A few extra to protect against unexpected blocking such as page faults.

A few extra to protect against expected blocking that's not worth optimizing out, for example in non-critical code. (For example, if you might very rarely need to do a DNS request, it's probably not worth the effort to do DNS requests asynchronously. Just create a few extra threads and make your life easier.)

If you follow the "one thread per processor" rule, then all your code is performance critical. Any code that blocks for some reason means your process cannot use that processor. That makes programming much harder for no good reason.


You can either spawn processes and threads to enable utilization of a multicore\multiprocessor system for a single program in which case you gain no benefit (for the single program at least) from having more threads\processes then cores.

Or you can have routines that poll for an event which typically block further execution. Rather then tie up the CPU with polling, you can instead create a thread that will sit in an idle state until the appropriate event wakes it. This method is very commonly used in web servers, and GUI event queues. Most programs want to have some sort of central data store (even if its program execution code) that all threads can access, so I guess that's why they use threading over processes.


The apps you mention are rarely running all those tens of threads simultaneously. Most of them just sit there because they're in a thread pool. The app send various tasks to a queue, which is purged by threads in the thread pool.

Why is the pool sized so large then? Because, often threads have to wait for other resources such as disk, network, the user, some other thread, etc. While a thread is waiting, it's appropriate to run other threads to fully utilize the processor. Sizing the pool appropriately is tricky, though. Too few threads, and you'll lose performance because the processor is not fully utilized while waiting for something. Too many threads, and you'll lose performance because of switching between them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.