See Also: Timer Members
The System.Timers.Timer component is a server-based timer, which allows you to specify a recurring interval at which the Timer.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 System.Timers.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 System.Timers.Timer is designed for use with worker threads in a multithreaded environment. Server timers can move among threads to handle the raised Timer.Elapsed event, resulting in more accuracy than Windows timers in raising the event on time.
The System.Timers.Timer component raises the Timer.Elapsed event, based on the value of the Timer.Interval property. You can handle this event to perform the processing you need. For example, suppose that you have an online sales application that continuously posts sales orders to a database. The service that compiles the instructions for shipping operates on a batch of orders rather than processing each order individually. You could use a System.Timers.Timer to start the batch processing every 30 minutes.
When Timer.AutoReset is set to false, the System.Timers.Timer raises the Timer.Elapsed event only once, after the first Timer.Interval has elapsed. To keep raising the Timer.Elapsed event on the Timer.Interval, set Timer.AutoReset to true.
In the .NET Framework version 2.0 and earlier, the System.Timers.Timer component catches and suppresses all exceptions thrown by event handlers for the Timer.Elapsed event. This behavior is subject to change in future releases of the .NET Framework.
If the Timer.SynchronizingObject property is null, the Timer.Elapsed event is raised on a System.Threading.ThreadPool thread. If processing of the Timer.Elapsed event lasts longer than Timer.Interval, the event might be raised again on another System.Threading.ThreadPool thread. In this situation, the event handler should be reentrant.
The event-handling method might run on one thread at the same time that another thread calls the Timer.Stop method or sets the Timer.Enabled property to false. This might result in the Timer.Elapsed event being raised after the timer is stopped. The example code for the Timer.Stop method shows one way to avoid this race condition.
Even if Timer.SynchronizingObject is not null, Timer.Elapsed events can occur after the erload:System.Timers.Timer.Dispose or Timer.Stop method has been called or after the Timer.Enabled property has been set to false, because the signal to raise the Timer.Elapsed event is always queued for execution on a thread pool thread. One way to resolve this race condition is to set a flag that tells the event handler for the Timer.Elapsed event to ignore subsequent events.
If you use the System.Timers.Timer with a user interface element, such as a form or control, without placing the timer on that user interface element, assign the form or control that contains the System.Timers.Timer to the Timer.SynchronizingObject property, so that the event is marshaled to the user interface thread.
The System.Timers.Timer is not visible at run time.
For a list of initial property values for an instance of System.Timers.Timer, see the Timer.#ctor constructor.