Do .NET Timers Run Asynchronously?

I have a messaging aspect of my application using Jabber-net (an XMPP library.)

What I would like to do, if for some reason the connection to the Server is ended, is keep trying to connect every minute or so.

If I start a Timer to wait for a period of time before the next attempt, does that timer run asynchronously and the resulting Tick event join the main thread, or would I need to start my own thread and start the timer from within there?

From stackoverflow

• The timer will effectively run in the background and cause events in your main thread to be executed.

  MrEdmundo : Thanks, I thought that was the case, just needed to sound it out with someone.

• What kind of timer are you using?

  • System.Windows.Forms.Timer will execute in the UI thread
  • System.Timers.Timer executes in a thread-pool thread unless you specify a SynchronizingObject
  • System.Threading.Timer executes its callback in a thread-pool thread

  In all cases, the timer itself will be asynchronous - it won't "take up" a thread until it fires.

  Byron Ross : Remember if you are not using the System.Windows.Forms.Timer that accessing a Control will throw an Exception unless you do the appropriate InvokeRequired check and invocation.

  MrEdmundo : You're right, In my question I should have said I wasn't sure which timer I should use. Looking at the three options you have supplied and reading MSDN the System.Timers.Timer looks like the right one for this case as on the Tick a call will need to be made to a object created in the main thread.

  Jon Skeet : @MrEdmundo: What exactly do you mean by "the main thread"?

  Jon Skeet : @Byron Ross: An alternative being System.Timers.Timer with the SynchronizingObject set to a control.

  MrEdmundo : I consider the main thread to be the thread that the application is executing under and other threads are created from. Is the correct term for this UI Thread?

  Quibblesome : Well that depends on whether your app has a UI or not. ;). The whole UI thread business is based on apps that have a "main" UI (typically an Application.Run() somewhere). The sync rule is that you cannot access a UI control on a thread that didn't create the control.

  MrEdmundo : Yeah I understand that thanks, just trying to clarify it's the only way I learn. Just out of interest what is the "main" thread called for a non UI app?

  Jon Skeet : Well, there's the thread which executes the Main() method. However, you'll need to run *some* sort of message pump (or something similar) if you want to be able to marshal calls to it.

• I'm not sure how the Timers in .NET are implemented, but if they use the windows API for creating a timer the form message loop receives a WM_TIMER message and only when the form thread is not busy can it proces that request, so the timer would fire at the right time, but you could be stalling the UI thread. The timer would be started with the SetTimer API and the OS will make sure to post a WM_TIMER message.

  I've checked, only System.Windows.Forms.Timer+TimerNativeWindow.StartTimer(Int32) depends on:

  [DllImport("user32.dll", CharSet=CharSet.Auto, ExactSpelling=true)]
  public static extern IntPtr SetTimer(HandleRef hWnd, int nIDEvent, int uElapse, IntPtr lpTimerFunc);
  

  So only this timer has the described "problem".