1

In the good old days of VB6 you could not rely on the timer control to fire at exactly the specified interval. If your program was doing some intense processing the Timer_Tick event is pushed onto the stack and only when it gets to the instruction is it processed, which may be some seconds(?) later.

So my question is - has the .NET timer control been improved such that this can be relied upon to fire at exactly the time interval specified? I guess the above still applies doesn't it? But is it any better than the VB6 version?

Are there any alternatives to using the timer control that ensure that an event fires after a specified interval?

Matt Wilko
  • 26,994
  • 10
  • 93
  • 143
  • http://stackoverflow.com/questions/4532850/windows-forms-timer-or-system-threading-timer – Mitch Wheat Aug 18 '11 at 10:26
  • Nothing to do with C#, here retagged. – Zenwalker Aug 18 '11 at 10:29
  • How do you think it could do better? A single threaded timer needs to wait until the previous handler is finished. Of course you can use multithreaded timers, but that adds a lot of complexity. That's not an improvement, but something for different use cases. – CodesInChaos Aug 18 '11 at 11:53
  • The Timer *component* works exactly the same way as the VB6 timer. The asynchronous timer classes in VB.NET have no corresponding VB6 equivalent, VB6 didn't support threads. Be sure to educate yourself on threading before you use them. – Hans Passant Aug 18 '11 at 13:51

2 Answers2

4

System.Windows.Forms.Timer runs on the UI thread and relies on a message pump; it works essentially in the same way as a VB6 timer.

But .NET has other timers - System.Threading.Timer, System.Timers.Timer that use worker threads in a multi-threaded environment.

Which is "better" depends on your requirement - using a multithreaded timer may fire more nearly at the requested interval, but this comes at the cost of the added complexity inherent in using threading.

Joe
  • 122,218
  • 32
  • 205
  • 338
0

The problem with Timers is that it's OS dependent in a sense. The timer work has to be scheduled by the OS and if there's another high priority process using up a lot of the processing power then it might decide to schedule your code to run at a later time giving more time for another more important line of work to progress.

For the most part newer timers are probably more reliable but they are only as reliable as the subsystem is. I'm not sure if windows implements hardware timers (which are more reliable) or if the .NET VB uses it if it does but from what I've worked with in the past it seems to be hit or miss. Most of the time it's almost dead on within a very small margin and other times I've seen it get delayed by up to a second under certain conditions.

My advice is don't use sleeps and use Timers instead and you shouldn't have very many problems.

P.S: It is relatively difficult for it to happen at EXACT time intervals, there will usually be a couple of milliseconds difference so you shouldn't rely on very very exact Timer granularity.

Jesus Ramos
  • 22,940
  • 10
  • 58
  • 88