What happens when timer threads don't finish on time

Question

I am using System.Threading Timers to poll sensors on different threads (one at a time was slow due to communication latency). It also allows the user change the polling rate by changing the timer period.

What I can't work out is what happens if timers don't finish before the next period. I wrote a test program, but it didn't really answer anything.

If I have a function that takes ~1.7s to run and call it every 10s, it finishes before the next one starts, and my CPU usage fluctuates between 13% (one core 100%) and 0%.

t = new Timer(doWork, null, 0, 10000);

private void doWork(object o)
{
    for(int i = 0; i < numberItts; i++)
    {
    }
}

If I then lower the timer period to 1s I would expect it to either not execute a thread until the previous one is finished, or keep spawning new threads and the CPU usage would climb as more threads start before other finish. What actually happens is CPU usage fluctuates between 13% and 25%.

Changing the period to 500ms, the CPU useage then fluctuates between 38% and 50%. Surely at this point they should be starting much faster than they are ending.

How are these threads managed? What is limiting the amount created when the polling rate is faster than the rate at which threads can be finished?

Answer 1

Unlike System.Windows.Forms.Timer, System.Threading.Timer uses a thread pool and is not subject to being blocked if your timer handler takes longer than the timer interval to complete.

So if your doWork takes about "~1.7s" to complete and your timer interval is one second, you would expect to see multiple concurrent threads entering doWork.

How are these threads managed? What is limiting the amount created when the polling rate is faster than the rate at which threads can be finished?

That's all handled by the Timer class and associated thread pool.

MSDN has this to say:

The callback method executed by the timer should be reentrant, because it is called on ThreadPool threads. The callback can be executed simultaneously on two thread pool threads if the timer interval is less than the time required to execute the callback, or if all thread pool threads are in use and the callback is queued multiple times. more...

So given this piece of code, where the timer interval is 2 seconds and handler processing time is 1 second, we can expect the same thread each time because its generally better to re-use the same thread than spin up a new one:

class Program
{
    static void Main(string[] args)
    {
        var t = new Timer(doWork, null, 0, 1000);


        Console.WriteLine("Press any key to quit");
        Console.ReadKey();
    }

    private static void doWork(object o)
    {
        Console.WriteLine("Thread: {0}", Environment.CurrentManagedThreadId);

        // simulate lengthy process
        Thread.Sleep(1000);
    }
}

Changing the interval and processing time to 1 second, leads to random threads due to the slight overlap.

Changing the interval to 200ms and keeping processing time to 1 second results in a higher number of worker threads than before. The reason being is that the thread pool has realised that delegates are taking longer to complete than the timer interval so it tries to keep up:

Answer 2

I think the following happens for a timer period of 1s:

• at 0 seconds: Thread 1 is started. One processor is busy -> ~13%
• at 1 second: Thread 2 is started. Two processors are busy -> ~25%
• at 1.7 seconds: Thread 1 is completed. Only one processor is busy -> ~13%
• at 2 seconds: Thread 3 is started. Two processors are busy ->~25%
• at 2.7 seconds: Thread 2 is completed. Only one processor is busy -> ~13%
• ...

I.e. still the threads are processed faster than they are created. Even for 500ms this will be true.

I think the behaviour you expected will occur when you reduce the timer period to a value < 1.7s/8 = ~0.2125s (Assuming you have 8 processors available doing nothing but process your threads which takes them 1.7s.)