2

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 more detail how sleeping threads effect the cpu available to other threads.

Suraj
  • 35,905
  • 47
  • 139
  • 250
  • why would you create a bunch of threads only to put them to sleep? sounds like a waste of resources and/or time. edit - if the threads are asleep then there is no context switching until the thread awakes, the thread has voluntarily yielded. – Nathan Jun 01 '11 at 16:22
  • @Nathan - added my use case in comment to @Jerry Coffin spot – Suraj Jun 01 '11 at 17:24
  • thanks, sounds like a singleton Queue combined with the ThreadPool class should serve your needs well. – Nathan Jun 02 '11 at 06:50

3 Answers3

4

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).

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
  • thanks! Correct, windows. Here's the actual design: I have a web service that I cannot load balance to multiple machines (financial restrictions - i.e. we don't have the $ for more resources). There are periods of time when the web service gets slammed with requests. So what I want to do is put most of the requests (each coming in on their own thread) to sleep, process a few requests at a time until the queue is empty. The clients are perfectly happen to wait for the server to do its thing, they are in no rush. If the server tries to process all requests at once it will die. =) – Suraj Jun 01 '11 at 17:27
  • @SFun28: I'd have one queue and a few threads. Each thread just retrieves and processes requests from the queue. Scale the number of threads to the available processors, not the amount of incoming activity. – Jerry Coffin Jun 01 '11 at 17:30
  • good advice. I'm using WFC and it seems my control of the "queue" is limited to one of two options: let all requests come in on their own threads or only allow one thread/request with the others queued for me. The problem with the latter is that there are performance advantages to having multiple threads executing. So it seems that I have to accept all threads coming-in and then place them in a queue, putting most to sleep. – Suraj Jun 01 '11 at 17:36
  • @Sfun28: in that case, I'd use a different queue. If you're not going to use a one of Windows built-in thread pool implementations (there are at least three) you might consider something similar to one I posted previously: http://stackoverflow.com/questions/3054701/is-there-a-set-of-win32-api-functions-to-manage-synchronized-queues/3054795#3054795 – Jerry Coffin Jun 01 '11 at 17:42
1

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

Martin James
  • 24,453
  • 3
  • 36
  • 60
  • great response and good suggestion on the tests. At most I'll have 100 threads, so it seems that there is no harm to the sleeping threads. – Suraj Jun 01 '11 at 17:29
0

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

IAmTimCorey
  • 16,412
  • 5
  • 39
  • 75
  • @BriggsTRC - I appreciate the links and perspective on my use-case. I wrote a bit more about my use case in my response to @Jerry's post. – Suraj Jun 01 '11 at 17:30
  • @SFun28 - I agree with Jerry. Basically, you need to look at this situation differently. Your application will work best if you scale the number of threads to be in proportion to the number of processors. Use a Thread Pool (see info above) to help you manage your threads properly. – IAmTimCorey Jun 01 '11 at 17:36
  • I responded with a bit more details. I don't see how this will be possible with WCF. – Suraj Jun 01 '11 at 17:37