Why Thread.Sleep() is so CPU intensive?

Question

I have an ASP.NET page with this pseduo code:

while (read)
{
   Response.OutputStream.Write(buffer, 0, buffer.Length);
   Response.Flush();
}

Answer 1

Just a guess:

I don't think it's Thread.Sleep() that's tying up the CPU - it's the fact that you're causing threads to be tied up responding to a request for so long, and the system needs to spin up new threads (and other resources) to respond to new requests since those sleeping threads are no longer available in the thread pool.

Answer 2

Let's take a look at whether Michael's answer seems reasonable.

Now, Michael wisely points out that Thread.Sleep(500) shouldn't cost much in the way of CPU. That's all well and good in theory, but let's see if that pans out in practice.

    static void Main(string[] args) {
        for(int i = 0; i != 10000; ++i)
        {
            Thread.Sleep(500);
        }
    }

Running this, the CPU use of the application hovers around the 0% mark.

Michael also points out that since all the threads that ASP.NET has to use are sleeping, it will have to spawn new threads, and offers that this is expensive. Let's try not sleeping, but doing lots of spawning:

    static void Main(string[] args) {
        for(int i = 0; i != 10000; ++i)
        {
            new Thread(o => {}).Start();
        }
    }

We create lots of threads, but they just execute a null operation. That uses a lot of CPU, even though the threads aren't doing anything.

The total number of threads never gets very high though, because each lives for such a short time. Lets combine the two:

    static void Main(string[] args) {
        for(int i = 0; i != 10000; ++i)
        {
            new Thread(o => {Thread.Sleep(500);}).Start();
        }
    }

Adding this operation that we have shown to be low in CPU use to each thread increases CPU use even more, as the threads mount up. If I run it in a debugger it pushes up to near 100% CPU. If I run it outside of a debugger, it performs a bit better, but only because it throws an out of memory exception before it gets a chance to hit 100%.

So, it isn't Thread.Sleep itself that is the problem, but the side-effect that having all available threads sleep forces more and more threads to be created to handle other work, just as Michael said.

Answer 3

Rather than an ASP.NET page you should implement an IHttpAsyncHandler. ASP.NET page code puts many things between your code and the browser that would not be appropriate for transferring binary files. Also, since you're attempting to perform rate limitation, you should use asynchronous code to limit resource usage, which would be difficult in an ASP.NET page. Creating an IHttpAsyncHandler is fairly simple. Just trigger some asynchronous operations in the BeginProcessRequest method, and don't forget to properly close the context to show you have reached the end of the file. IIS won't be able to close it for you here.

The following is my really bad example of how to perform an an asynchronous operation consisting of a series of steps, counting from 0 to 10, each performed at a 500ms interval.

using System;
using System.Threading;

namespace ConsoleApplication1 {
    class Program {
        static void Main() {
            // Create IO instances
            EventWaitHandle WaitHandle = new EventWaitHandle(false, EventResetMode.AutoReset); // We don't actually fire this event, just need a ref
            EventWaitHandle StopWaitHandle = new EventWaitHandle(false, EventResetMode.AutoReset);
            int Counter = 0;
            WaitOrTimerCallback AsyncIOMethod = (s, t) => { };
            AsyncIOMethod = (s, t) => {
                // Handle IO step
                Counter++;
                Console.WriteLine(Counter);
                if (Counter >= 10)
                    // Counter has reaced 10 so we stop
                    StopWaitHandle.Set();
                else
                    // Register the next step in the thread pool
                    ThreadPool.RegisterWaitForSingleObject(WaitHandle, AsyncIOMethod, null, 500, true);
            };

            // Do initial IO
            Console.WriteLine(Counter);
            // Register the first step in the thread pool
            ThreadPool.RegisterWaitForSingleObject(WaitHandle, AsyncIOMethod, null, 500, true);
            // We force the main thread to wait here so that the demo doesn't close instantly
            StopWaitHandle.WaitOne();
        }
    }
}

You'll also need to register your IHttpAsyncHandler implementation with IIS in whichever way is appropriate for your situation.

Answer 4

Its because the thread gets a priority boost every time it yields its time slice. Avoid calling sleep often ( particularly with low values ).