Click here to Skip to main content
Click here to Skip to main content

Tagged as

Go to top

All about .NET Timers - A Comparison

, 16 Mar 2011
Rate this:
Please Sign up or sign in to vote.
All about .NET Timers - A Comparison

Threads and Timers are the most common things that you need for your application. Any work that needs to be done in background without intervening the work that is running in the foreground needed to be done using a Thread. We create Threads to delegate a long running process in background so that the UI remains unblocked. Timers on the other hand are a special module which runs after a certain interval of time in background. So you would think Timers will also create a new Thread in background and run the module associated with it after a certain time. This is not always true.

In this post, I will compare most of the timers available with .NET right now, and later on discuss about DispatcherTimer in WPF.

Difference between Concurrency and Asynchrony?

Now, if you look back when Microsoft introduced async CTP in PDC 2010, or my own article on Async, it is clearly stated that Asynchrony and Concurrency are two different concepts. Asynchrony means running a job without blocking the Thread where it is working at. Concurrency is actually a special kind of asynchrony where it is achieved by creating a new Thread. Hence you can say, all sorts of concurrency is asynchrony while all asynchrony is not concurrency. You can have asynchrony without concurrency and it is really worth doing that, as you all know it is not good to put every work in a separate thread. ThreadPools could somewhat help by allowing you to manage threads but still Threads are for long running background processes, so beware to use it only when you absolutely require it.

Going ahead with this thought, let's compare the existing Timers.There are a number of Timers available with .NET before. Many of us might not know what is the basic difference between them. Let's put a comparative analysis on them one by one.

Comparison of Timers (Backtracking Thoughts)

System.Windows.Forms.Timer

Well, if you have ever worked in Windows based application in .NET, this object must be very well known to you. Windows.Forms.Timer is actually a normal Windows object which sends the messages directly to the Window messages which runs in background when no other foreground work is running. Hence, the Timer tick event is actually invoked directly into the UI thread and will invoke the EventHandler that we pass to it when the UI Thread is idle and processing window messages.

The Usage

private System.Windows.Forms.Timer WinTimer = new System.Windows.Forms.Timer();
 ObservableCollection<string> WinTimerList = new ObservableCollection<string>();
 private void btnwft_Click(object sender, RoutedEventArgs e)
 {
            this.WinTimer.Interval = 1000; //1 sec
            this.WinTimer.Tick += new EventHandler(WinTimer_Tick);
            this.WinTimer.Start();
            this.WinTimerList.Clear();
            this.lstwft.DataContext = this.WinTimerList;
 }

 void WinTimer_Tick(object sender, EventArgs e)
 {
    this.WinTimerList.Add(string.Format("Tick Generated from {0}", 
	Thread.CurrentThread.Name));
 }

So basically, the object timer has a well defined structure, which calls an event Tick after a certain time interval (in milliseconds).

Things to Remember

  1. Runs in UI Thread
  2. Does not generate event when current UI Thread is busy
  3. It inserts a Window Message to invoke the method when Application.DoEvents occurs. Explicit call to Application.DoEvents also generates the timer.

System.Timers.Timer

It is a special Timer that is designed for running in multi-threaded environment and also can be safely accessible from any thread. In fact, this timer safely calls a new thread from the ThreadPool and uses ISynchronizeInvoke object to achieve this.

The Timers.Timer is also capable of calling itself in a thread which you specify. It exposes SynchronizingObject which needs an object of ISyncrhonizeInvoke. As window forms objects are itself implemented from ISynchronizeInvoke, it can be attached easily with UI Threads. Thus by setting the ISynchronizeObject to window, will automatically call the Timer callback in the UI thread. Strangely, WPF does not support ISynchronizeInvoke, hence you need to create one yourself if you want to use it for WPF.

Usage

private System.Timers.Timer TTTimer = new System.Timers.Timer();
ObservableCollection<string> TTimerList = new ObservableCollection<string>();
private void btntt_Click(object sender, RoutedEventArgs e)
{
    this.TTTimer.Interval = 1000; //1 sec
    this.TTTimer.Elapsed += new System.Timers.ElapsedEventHandler(TTTimer_Elapsed);
    this.TTTimer.Start();
    this.TTimerList.Clear();
    this.lsttt.DataContext = this.TTimerList;
}

void TTTimer_Elapsed(object sender, System.Timers.ElapsedEventArgs e)
{
    string message = string.Format("Tick Generated from {0}", Thread.CurrentThread.Name);
    this.Dispatcher.Invoke((Action)delegate()
    {
        this.TTimerList.Add(message);
    });
}

So, you can see the interface is almost the same, while instead of normal EventHandler the Timers.Timer actually passes an ElapsedEventHandler.

Even though this can be assigned to UI Thread using ISynchronizeInvoke, yet one major difference with Forms.Timer is that it will always queue a message on every timer interval elapsed even though the UI thread is busy. Hence if for 2 seconds you put a Thread.Sleep statement on both the timers, the Timers.Timer will be called twice after 2 seconds, while the Forms.Timer will queue only once.

Things to Remember

  1. It invokes the available thread in ThreadPool to run the interface
  2. ThreadSafe, each eventhandler has explicit locks
  3. Can be run in any thread using ISynchronizeObject

The Internal

If you try to see the implementation detail of the Timer, you will see that the Timer actually puts an AutoResetEvent hooked with the Time for the next call. It invokes the callback using ISynchronizeObject.BeginInvoke. As Begin patterns actually creates a Thread from ThreadPool, it always uses a ThreadPool by default.

The Timer uses ChangeTimerNative to change time and gets the elapsed callback from AddTimeNative calls.

System.Threading.Timer

This Timer is actually widely used and creates a new Thread inside it to run the callback. The Threading.Timer class is not ThreadSafe. So you should always device your code if you need ThreadSafe access of objects. Even, the class is not well structured and user friendly. It needs every input in its constructor to call a thread. As it always runs on a new Thread from ThreadPool, you should not use it extensively as because even your UI Thread remains idle, it still waits to find other background Threads for its execution.

Usage

private System.Threading.Timer STTimer;
ObservableCollection<string> STimerList = new ObservableCollection<string>();
private void btnstt_Click(object sender, RoutedEventArgs e)
{
    this.STTimer = new Timer(this.TimerElapsed, null, 1000, 
			System.Threading.Timeout.Infinite);
            
    this.STimerList.Clear();
    this.lststt.DataContext = this.STimerList;
}
void TimerElapsed(object state)
{
    string message = string.Format("Tick Generated from {0}", Thread.CurrentThread.Name);
    this.Dispatcher.Invoke((Action)delegate()
    {
        this.STimerList.Add(message);
    });
}

Hence the constructor for Timer needs the callback method. The 2nd parameter is the state, which will be received to the callback. 3rd parameter represents the time after which the call will take place. 1000 means after 1 second the timer will invoke the Callback. TimeOut represents the periods, specify any numeric integers. 0 and Invinite will remove the subsequent calls to the method.

Like System.Timers.Timer, it also uses AddTimerNative call to get events from native environment. But it does always invoke the object in a new thread.

Things to Remember

  1. Runs in a new thread always
  2. Explicit call to period is required
  3. You can use the Change method to change the properties after the Timer is invoked
  4. Class does not support inheritance 
  5. Purely used for numerical timing, where UI update is not or very less required.

DispatcherTimer

In WPF, the most common Timer that we use is DispatcherTimer. It runs on the Dispatcher Thread by default (UI Thread) and invokes the callback based on DispatcherPriority. DispatcherTimer is a special Timing object for WPF just like Forms.Timer in Windows. Dispatcher timer is not restricted to only one thread, but rather runs every event on Dispatcher thread. If you are not aware of Dispatcher, you might want to read my WPF Tutorial series. DispatcherPriority is very useful when dealing with DispatcherTimer. The Threading model identifies the Priority of the Dispatcher callback and treats it accordingly.

DispatcherPriority

  • Inactive - throws an exception
  • SystemIdle - called when System is Idle or SystemIdle process takes maximum CPU time
  • ApplicationIdle - Processes when Application is idle means UI thread is free
  • ContextIdle - Processed when background operation is complete
  • Background - Processed in background means processed only when all other non-idle operations are complete
  • Send- Highest, and sent immediately

There are other priorities too, which might be used.

Usage

DispatcherTimer dispTimer = new DispatcherTimer(DispatcherPriority.SystemIdle);
ObservableCollection<string> stDispatcher = new ObservableCollection<string>();
private void btnDispatcher_Click(object sender, RoutedEventArgs e)
{
    dispTimer.Interval = TimeSpan.FromSeconds(1);
    dispTimer.Tick += new EventHandler(dispTimer_Tick);
    dispTimer.IsEnabled = true;
    stDispatcher.Clear();
    this.lstDispatcher.DataContext = stDispatcher;
}

void dispTimer_Tick(object sender, EventArgs e)
{
    this.stDispatcher.Add(string.Format("Tick Generated from {0}", 
				Thread.CurrentThread.Name));
}

Now this will ensure that the dispTimer will be called after 1 second, and require the System to be Idle. If you are running complex operations, the Timer will not be called. Hence this gives you a chance to ensure that the timer will be called only when all other foreground operation is complete. Instead of that, if you specify DispatcherPriority.Send, it will be immediately processed.

The DispatcherTimer is elapsed on the Dispatcher Thread, and hence it is safe to use for any WPF applications.

The Internals

If you see the internals of the DispatcherTimer, you will eventually find that the DispatcherTimer is also using the same native API to call the eventhandler. But the only difference is that it uses DispatcherThread to process the code.

The hooks lets us specify the various DispatcherEvents and allows it to Raise Timer event based on situation of the Dispatcher.

You should note that DispatcherTimer is ThreadSafe.

Conclusion

In this brief case study, I think you might be clear about the usage of different timers. I hope to find feedback. Feel free to write.

Thank you for reading.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Abhishek Sur
Architect
India India
Did you like his post?
 
Oh, lets go a bit further to know him better.
Visit his Website : www.abhisheksur.com to know more about Abhishek.
 
Abhishek also authored a book on .NET 4.5 Features and recommends you to read it, you will learn a lot from it.
http://bit.ly/EXPERTCookBook
 
Basically he is from India, who loves to explore the .NET world. He loves to code and in his leisure you always find him talking about technical stuffs.
 
Presently he is working in WPF, a new foundation to UI development, but mostly he likes to work on architecture and business classes. ASP.NET is one of his strength as well.
Have any problem? Write to him in his Forum.
 
You can also mail him directly to abhi2434@yahoo.com
 
Want a Coder like him for your project?
Drop him a mail to contact@abhisheksur.com
 
Visit His Blog

Dotnet Tricks and Tips



Dont forget to vote or share your comments about his Writing
Follow on   Twitter   Google+

Comments and Discussions

 
GeneralMy vote of 5 PinmemberFarhan Ghumra2-Jul-12 3:12 
Excellent
GeneralMy vote of 5 PinmemberDarkWalkerRzn5-May-11 21:20 
GeneralBy the way... PinmemberNenad L.22-Mar-11 3:43 
GeneralYour conclusion is rubish while the rest of the article looks pretty good... PinmemberJV999922-Mar-11 0:11 
GeneralRe: Your conclusion is rubish while the rest of the article looks pretty good... Pinmemberkevdelkevdel17-May-12 7:01 
GeneralThere is another timer - Multimedia timer PinmemberShai Goldberg21-Mar-11 21:55 
GeneralMy vote of 5 PinmemberMicroImaging21-Mar-11 13:31 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web02 | 2.8.140921.1 | Last Updated 16 Mar 2011
Article Copyright 2011 by Abhishek Sur
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid