Help me understand the performance and behavior of sleeping threads

Lets say I have created a number of threads (~100) and I have put most of them to sleep while a few of them are working on purely CPU bound problems. What is the effect on performance versus JUST creating the handful of threads that are doing work and no threads that are sleeping? Does the existence of many threads, regardless of whether they are sleeping, degrade performance significantly because of all the context switching, OR are the sleeping threads largely ignored and the CPU divided mostly between the active threads?

I'm not looking for an answer like "50% performance degradation", I'm simply trying to understand in mor开发者_开发技巧e detail how sleeping threads effect the cpu available to other threads.

Based on the .net tags, I'm going to presume you're dealing with threads on Windows.

At least in the case of the normal Windows scheduler, sleeping threads will normally affect performance extremely minimally.

The threads will consume some resources -- for example, each thread you create gets its own stack, a thread information block, etc. There's some memory and CPU time consumed when you create the thread. That memory may be paged out if you're low, and that'll take a bit more time (CPU time, memory and I/O bandwidth, etc.)

However, once the thread is sleeping, it won't normally consume CPU time on an ongoing basis.

At the same time, this sounds like a pretty lousy design. Instead of creating a lot of threads that spend most of their time sleeping, you generally want a fairly small thread pool, and just submit tasks to be carried out by those threads. This saves the time to create the threads, reduces memory usage, cleans up the design, and makes it easier to take advantage of varying processor resources (e.g., increasing the thread pool size if you have more processors).

Threads in any state other than 'running' are not running. 'Ready' threads can run and are waiting for a processor to become available. Context-changes can only occur between a running thread and a ready thread.

Like Nathan says - there can be no context switching to/from sleeping threads.

That said, if you bloat out the OS system state with thousands of sleeping threads, then there may be some slight, measurable increase in scheduling/dispatching, so I would not like to say there is no effect whatsoever, just that there is no effect relevant to 99.999% of applications.

You could easily code up a test for this. Create 1000 sleep(INFINITE) threads in a loop and just leave them be. Use your box. Does Firefox seem any different when rendering web pages? Is uTorrent slower? Make a ridiculously large spreadsheet with Excel so that the recalculation time is measurable with a stopwatch. Is it slower with the extra 1000 threads sleeping?

How many threads loaded on your system now? My Task Manager/Performance says 1195. Most of these are not running because the CPU usage is 0-1%. My box is operating just fine.

Rgds, Martin

My suggestion would be to scale back the number of threads and have a few do the work for you. It sounds like you are using threads like class instances instead of like workers. Every time you create a thread, you take up some resources. Granted, this is not a lot in today's era of fast CPUs and lots of RAM, but it is still an issue.

Here is a decent article on Thread Pooling that answers your question as well:

http://www.theukwebdesigncompany.com/articles/iocp-thread-pooling.php

I would suggest that you either go with less threads or you take advantage of the new threading features of .NET 4.0 that really revolutionize threading in applications.

http://www.albahari.com/threading/#_Introduction