Understanding C# Timers

All of this information is taken from VS2005 RC2 MSDN Documentation unless otherwise specified; unfortunately information about Timers is littered about the docs and not all in one place. So, in trying to make sense of it all, I made this compilation:

There are three timer controls in Visual Studio and the .NET Framework — the server-based timer you can see on the Components tab of the Toolbox, the standard Windows-based timer you can see on the Windows Forms tab of the Toolbox, and the thread timer that is only available programmatically.

1. The Windows-based timer is optimized for use in Windows Forms applications.
2. The server-based timer is an update of the traditional timer that has been optimized to run in a server environment.
3. The thread timer is a simple, lightweight timer that uses callback methods instead of events and is served by thread-pool threads.

There are two types of threads in Win32 architecture: UI threads, and worker threads. UI threads sit idle most of the time and wait for messages to arrive in their message loops. Once they receive a message, they handle it and then wait for the next message to arrive. Alternatively, worker threads are used to perform background processing and do not use message loops. Both the Windows timer and the server-based timer run using an Interval property. The interval of the thread timer is set in the Timer constructor. The timers are designed for different purposes, as evidenced by their handling of threads:

• The Windows timer is designed for a single-threaded environment where UI threads are used to perform processing. The accuracy of Windows timers is limited to 55 milliseconds. These traditional timers require that the user code have a UI message pump available and always operate from the same thread, or marshal the call onto another thread. For a COM component, this would be detrimental to performance.
• The server-based timer is designed for use with worker threads in a multi-threaded environment. Because they use a different architecture, server-based timers have the potential to be much more accurate than Windows timers. Server timers can move among threads to handle the raised events.
• The thread timer is useful in scenarios where messages are not pumped on the thread. For example, the Windows-based timer relies on operating-system timer support, and if you are not pumping messages on the thread, the event associated with your timer will not occur. The thread timer is more useful in this case.

Windows Form Timer
This class wraps the counters we had in Win32 based on Windows messages. Use this class only if you do not plan to develop a multithreaded application. The Windows Forms Timer component has an Interval property that specifies the number of milliseconds that pass between one timer event and the next. Unless the component is disabled, a timer continues to receive the Tick event at roughly equal intervals of time. This component is designed for a Windows Forms environment. If you need a timer that is suitable for a server environment, see Introduction to Server-Based Timers.

The Interval Property
The Interval property has a few limitations to consider when you are programming a Timer component:

• If your application or another application is making heavy demands on the system — such as long loops, intensive calculations, or drive, network, or port access — your application may not get timer events as often as the Interval property specifies.
• The interval can be between 1 and 64,767, inclusive, which means that even the longest interval will not be much longer than one minute (about 64.8 seconds).
• The interval is not guaranteed to elapse exactly on time. To ensure accuracy, the timer should check the system clock as needed, rather than try to keep track of accumulated time internally.
• The system generates 18 clock ticks per second — so even though the Interval property is measured in milliseconds, the true precision of an interval is no more than one-eighteenth of a second.

Thread safety: Any public static members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

Server-Based Timers (System.Timers)
The Timer component is a server-based timer, which allows you to specify a recurring interval at which the Elapsed event is raised in your application. You can then handle this event to provide regular processing. For example, suppose you have a critical server that must be kept running 24 hours a day, 7 days a week. You could create a service that uses a Timer to periodically check the server and ensure that the system is up and running. If the system is not responding, the service could attempt to restart the server or notify an administrator. The server-based Timer is designed for use with worker threads in a multithreaded environment.

Server timers can move among threads to handle the raised Elapsed event, resulting in more accuracy than Windows timers in raising the event on time. For more information on server-based timers, see Introduction to Server-Based Timers.

Key Programming Elements of Server-Based Timers
The Timer component raises an event called Elapsed. You can create handlers for this event to perform whatever processing needs to occur. Some of the more important properties and methods of a Timer component include the following:

• The Interval property is used to set the time span, in milliseconds, at which events should be raised. For example, an interval of 1000 will raise an event once a second.
• The AutoReset property determines whether the timer continues raising events after the given interval elapses. If set to true, the timer continues to recount the interval and raise events. If false, it raises one event after the interval elapses and then stops.
• The Start method sets the timer's Enabled property to true, which allows the timer to begin raising events. If the timer is already enabled, calling the Start method resets the timer.
• The Stop method sets the timer's Enabled property to false, preventing the timer from raising any more events.

Thread safety: any public static members of this type are safe for multithreaded operations. Any instance members are not guaranteed to be thread safe.

Thread-timer (System.Threading.Timer)
Use a TimerCallback delegate to specify the method you want the Timer to execute. The timer delegate is specified when the timer is constructed, and cannot be changed. The method does not execute on the thread that created the timer; it executes on a ThreadPool thread supplied by the system. 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.

When you create a timer, you can specify an amount of time to wait before the first execution of the method (due time), and an amount of time to wait between subsequent executions (period). You can change these values, or disable the timer, using the Change method.

As long as you are using a Timer, you must keep a reference to it. As with any managed object, a Timer is subject to garbage collection when there are no references to it. The fact that a Timer is still active does not prevent it from being collected.

Note: System.Threading.Timer is a simple, lightweight timer that uses callback methods and is served by threadpool threads. You might also consider System.Windows.Forms.Timer for use with Windows forms, and System.Timers.Timer for server-based timer functionality. These timers use events and have additional features.

Thread safety: This type is safe for multithreaded operations.

Other Timers
1. timeGetTime() : This Windows.DLL call can give you up to 1 microsecond of accuracy on some operating systems; however it can be up to 5 microseconds on Windows NT.
2. System.Tickcount (Environment.TickCount): Gets the number of milliseconds elapsed since the system started.
3. DateTime.Ticks: The value of this property represents the number of 100-nanosecond intervals that have elapsed since 12:00:00 midnight, January 1, 0001.
4. QueryPerformanceCounter: often used in C++ Windows games. Provides a high resolution timer of less than 1 microsecond. Not exposed in managed code, so you would have to write a wrapper for it.

References
Programming the Thread Pool in the .NET Framework
System.Timers Namespace
Introduction to Server-Based Timers
Timer Programming Architecture
Introduction to the Windows Forms Timer Component

Other C# Timer Resources
Comparing the Timer Classes in the .NET Framework Class Library (added 12/15/05 5:37PM)
http://www.mvps.org/directx/articles/selecting_timer_functions.htm (added 12/20/05 2:20)
The mvps link is very revealing; it discusses timers in the context of high performance games and evaluates them via benchmarking.