.NET Reference Guide

Exploring Options for Better Timers

Last updated Sep 24, 2010.

As I showed previously, .NET timer resolution is limited to about 15 milliseconds (66 ticks per second). Accuracy of the timers is somewhat limited, too. My testing showed that you can expect a tick to occur within 30 milliseconds of when it was supposed to occur. Typically it's within 15 ms, but there are situations where that isn't true.

I'll grant that it's not often that you want a timer to notify you more often than 66 times per second, but it does happen. And there are many situations when you'll want a timer tick to happen as closely as possible to exactly on time. When you ask for a tick frequency of 40 times per second (once every 25 milliseconds), getting a tick every 40 milliseconds (25 times per second) just doesn't cut it.

Can we get better timer resolution under Windows?

A correction

In my previous article, I stated that the .NET thread timers are based on Windows Timer Queue Timers. That's true, in a sense. At the time I wrote that, I believed thatSystem.Threading.Timer was essentially a managed wrapper around the Timer Queue API. It turns out that the "timer queue" used in .NET is implemented in the runtime and doesn't call the Timer Queue API at all. Thread timers are based on Windows Timer Queues only in the sense that the API and implementation are very similar.

I apologize if my statement in the previous article caused any confusion.

Windows timer objects

Windows has been around in one incarnation or another for over 20 years. In that time it has supported a bewildering number of different timers, all of which appear to still be supported. The backward compatibility is commendable, but trying to make sense of the different timers and when to use each is at best confusing. At worst, choosing the wrong type of timer can lead to poor application performance, high CPU usage, decreased battery life on mobile devices, and potential deadlocks.

Early versions of Windows had a single timer object, which was created by calling theSetTimer API function. This timer was based on the default DOS timer interrupt, and had a maximum resolution of about 54 milliseconds. This is the same timer that's used by theWindows.Forms.Timer component in .NET, although resolution these days is the same as for other .NET timers: about 15 milliseconds. This timer is commonly referred to as the WM_TIMER timer, because it posts aWM_TIMER message to your window procedure.

Windows 3.1 (perhaps earlier) included a multimedia timer that in theory supported a resolution of one millisecond. Actually achieving one millisecond resolution turned out to be somewhat difficult due to hardware limitations, but this timer was a huge improvement over the WM_TIMER timer, primarily because:

Accuracy was much improved. If you asked for a timer frequency of 50 ms, you got 50 ms. With WM_TIMER, accuracy was limited to increments of 54 ms.

Re-entrancy was supported. With WM_TIMER, you do not get another timer tick until the first one is fully processed. So if it took too long to process a tick, you'd miss the next one. In general, it's a bad idea for your timer callback to take longer than the timer period to process, but sometimes it's unavoidable. The multimedia timer will happily call your callback at every tick, regardless of whether the previous callback has returned.

The multimedia timer supports periodic ticks (one tick every 50 milliseconds, for example), or can be operated as a one-shot: fire a tick and then stop. In addition, it can be configured to call a callback function or to signal or pulse an event. All in all, the multimedia timer was a welcome addition to the Windows API, and with today's hardware can easily achieve one millisecond accuracy.

Useful as the multimedia timer was in the past, current documentation for thetimeSetEvent API function says that the multimedia timers are obsolete and recommends using a timer queue timer (see below).

Windows 2000 (perhaps a version of Windows NT before that) introduced the Waitable Timer synchronization object, which combines the functionality of a periodic timer and a waitable synchronization object. As with other Windows synchronization objects, waitable timers can be named and shared among processes, so one process can create and set the timer, and others can wait on it to be signaled. Like the multimedia timers, waitable timers can be configured as periodic timers or one-shots. In addition, the event can be configured as a manual reset or auto reset. The timer is in a real sense similar to combining a .NET timer object with aManualResetEvent orAutoResetEvent.

Waitable timers have one other very cool feature: they can "wake" your system from sleep or hibernation at a given time. You can set the timer for midnight, put your laptop in hibernation, and go to bed knowing that at midnight your computer will wake up, the timer will fire, and any program that's waiting on the event will get the signal and continue processing. My article, Waitable Timers in .NET with C# shows how to use this type of timer in C# programs.

Windows 2000 also introduced Timer Queues and Timer Queue Timers. The idea behind timer queues is that you can have multiple logical timers controlled by a single timer interrupt. The timer interrupt occurs periodically (for example, once every 15 milliseconds), and any of the logical timers whose times have expired since the last interrupt are fired and rescheduled. This design is much more efficient because a logical timer requires relatively few bytes in memory, and almost no processor resources except when its due time expires.

Like the multimedia timer, timer queue timers have a maximum resolution of one millisecond, which is easily achievable with today's hardware. The API exposes functions that let you create and delete timer queues and individual timers within those queues. The timers themselves have a bewildering number of options for specifying how the callback function is called when the timer period expires. Unfortunately, the documentation is rather sparse on the details of when you should use a particular option.

Windows Vista and Windows Server 2008 introduced one more timer type: the threadpool timer. Conceptually, these timers work in much the same way as the timer queue timers, but they're designed to work with the thread pool design in the newer versions of Windows. The API for these timers is much simplified over the timer queue API.

To my knowledge, those are all of the timer types available in Windows today.

Which one to use?

Of all the timer types, which one should we use to replaceSystem.Threading.Timer? We obviously don't want to use the original Windows timer object that requires a message loop. That's the same timer used by `Windows.Forms.Timer`. We also don't want to use a multimedia timer, since the documentation says that it's obsolete.

The waitable timer is certainly a useful object, and if you need synchronization on a timer it's the only way to go. But as a global synchronization object, it's going to be somewhat heavyweight: you probably don't want to create very many of them.

That leaves us with the timer queue timers and the threadpool timers as the only ones that can support a large number of timers efficiently. And, since the threadpool timers aren't supported in Windows XP, they're out too. I know that Microsoft is about to stop supporting Windows XP, but the truth is that lots of people still use it. So we're left with creating a .NET wrapper around the Timer Queue API. That'll be the project for next time.