Windows.Forms.Timer or System.Threading.Timer

Threading.Timer vs. Forms.Timer

Forms.Timer registers the timer to send a message when the timer goes off. The event raised is treated like a GUI event. System.Threading.Timer uses a thread blocking approach. Basically, you should use Forms.Timer for your GUI oriented timers (to add some effects to the user interface) and Threading.Timer for scheduling tasks and other things.

Windows.Forms.Timer OR System.Threading.Timer

This article provides an excellent comparison and should contain the information you need: Comparing the Timer Classes in the .NET Framework Class Library:

                                    Windows.Forms  System.Timers         System.Threading 
Timer event runs on what thread?    UI thread      UI or worker thread   Worker thread 
Instances are thread safe?          No             Yes                   No 
Familiar/intuitive object model?    Yes            Yes                   No 
Requires Windows Forms?             Yes            No                    No 
Metronome-quality beat?             No             Yes*                  Yes* 
Timer event supports state object?  No             No                    Yes 
Initial timer event schedulable?    No             No                    Yes 
Class supports inheritance?         Yes            Yes                   No

* Depending on the availability of system resources (for example, worker threads)

System.Timers.Timer vs System.Threading.Timer

This article offers a fairly comprehensive explanation:

"Comparing the Timer Classes in the .NET Framework Class Library" - also available as a .chm file

The specific difference appears to be that System.Timers.Timer is geared towards multithreaded applications and is therefore thread-safe via its SynchronizationObject property, whereas System.Threading.Timer is ironically not thread-safe out-of-the-box.

I don't believe that there is a difference between the two as it pertains to how small your intervals can be.

Does the System.Windows.Forms.Timer run on a different thread than the UI?

No, the timer events are raised on the UI thread.

You won't have any synchronicity problems. This is the correct version of the timer control to use in a WinForms application; it's specifically designed to do what you're asking. It's implemented under the hood using a standard Windows timer.

The documentation confirms this in the Remarks section:

A Timer is used to raise an event at user-defined intervals. This Windows timer is designed for a single-threaded environment where UI threads are used to perform processing. It requires that the user code have a UI message pump available and always operate from the same thread, or marshal the call onto another thread.

When you use this timer, use the Tick event to perform a polling operation or to display a splash screen for a specified period of time. Whenever the Enabled property is set to true and the Interval property is greater than zero, the Tick event is raised at intervals based on the Interval property setting.

Why use Windows.Forms.Timer at all?

The main convenience of the Windows.Forms.Timer is that its events are fired on the UI (Winforms) thread. If your timer events perform UI operations, it may be the simplest alternative (instead of calling Control.Invoke/BeginInvoke or SynchronizationContext.Post/Send inside all of your events).

Thread-safety of System.Timers.Timer vs System.Threading.Timer

No, that's not the way it works. The .NET asynchronous Timer classes are perfectly thread-safe. The problem with thread-safety is that it is not a transitive property, it doesn't make the other code that's executed thread-safe as well. The code that you wrote, not a .NET Framework programmer.

It is the same kind of problem with the very common assumption that Windows UI code is fundamentally thread-unsafe. It is not, the code inside Windows is perfectly thread-safe. The problem is all the code that runs that is not part of Windows and not written by a Microsoft programmer. There's always a lot of that code, triggered by a SendMessage() call. Which runs custom code that a programmer wrote. Or code he didn't write, like a hook installed by some utility. Code that assumes that the program doesn't make it difficult and just executes message handlers on one thread. He usually does, not doing that buys him a lot of trouble.

Same problem with the System.Timers.Timer.Elapsed event and the System.Threading.Timer callback. Programmers make lots of mistakes writing that code. It runs complete asynchronously on an arbitrary threadpool thread, touching any shared variable really does require locking to protect state. Very easy to overlook. And worse, much worse, very easy to get yourself into a pile of trouble when the code runs again, before the previous invocation stopped running. Triggered when the timer interval is too low or the machine is too heavily loaded. Now there are two threads running the same code, that rarely comes to a good end.

Threading is hard, news at eleven.

Update Winforms controls from Timers

The Windows.Forms.Timer is optimized to be used with the UI.

From the above link. emphasis mine:

A Timer is used to raise an event at user-defined intervals. This Windows timer is designed for a single-threaded environment where UI threads are used to perform processing. It requires that the user code have a UI message pump available and always operate from the same thread, or marshal the call onto another thread.

The System.Timers.Timer has a SynchronizingObject which can be set to the Form Object if you are wanting to use that one.

From Above link:

When SynchronizingObject is null, the method that handles the Elapsed event is called on a thread from the system-thread pool. For more information on system-thread pools, see ThreadPool.
When the Elapsed event is handled by a visual Windows Forms component, such as a button, accessing the component through the system-thread pool might result in an exception or just might not work. Avoid this effect by setting SynchronizingObject to a Windows Forms component, which causes the method that handles the Elapsed event to be called on the same thread that the component was created on.

Timer and Threading in C# can't be together?

Why can't I use Timer and Thread in same class?

The problem is:

There is a Timer class in both namespaces:

System.Timers.Timer;
System.Threading.Timer;

So .NET is not able to determine which timer you want to use if you just declare a timer like:

Timer timer; // Compile Error

You need to be more specific so that the compiler knows which timer you want to use:

System.Timers.Timer timer = new System.Timers.Timer();
System.Threading.Timer otherTimer = new System.Threading.Timer(MyCallBackMethod);

If you want to use the timer class from System.Timers together with components from System.Threading you can decide to use an namespace alias for the System.Timers namespace to make code more readable:

using t = System.Timers;

public void MyMethod()
{
   t.Timer = new t.Timer(); 
   // this code is equals to 
   // System.Timers.Timer timer = new System.Timers.Timer();
}

---

Related Topics