System.Timers.Timer vs System.Threading.Timer

He estado revisando algunas de las posibles temporizadores últimamente, y System.Threading.Timery System.Timers.Timerson las que se ven necesaria para mí (ya que el apoyo conjunto de hilos).

Estoy haciendo un juego y planeo usar todo tipo de eventos, con diferentes intervalos, etc.

¿Cuál sería el mejor?

Este artículo ofrece una explicación bastante completa:

" Comparación de las clases de temporizador en la biblioteca de clases de .NET Framework " - también disponible como un archivo .chm

La diferencia específica parece ser que System.Timers.Timerestá orientada a aplicaciones multiproceso y, por lo tanto, es segura para subprocesos a través de su SynchronizationObjectpropiedad, mientras que, System.Threading.Timerirónicamente, no es segura para subprocesos de fábrica.

No creo que haya una diferencia entre los dos en lo que respecta a cuán pequeños pueden ser sus intervalos.

System.Threading.TimerEs un simple temporizador. Le devuelve la llamada a un subproceso de grupo de subprocesos (del grupo de trabajo).

System.Timers.Timeres un System.ComponentModel.Componentque envuelve un System.Threading.Timer, y proporciona algunas características adicionales utilizadas para el envío en un hilo particular.

System.Windows.Forms.Timeren su lugar, envuelve un mensaje nativo solo HWND y usa temporizadores de ventana para generar eventos en ese bucle de mensajes HWND.

Si su aplicación no tiene interfaz de usuario y desea el temporizador .Net más liviano y de uso general posible (porque está contento de descubrir su propio enhebrado / despacho), entonces System.Threading.Timeres tan bueno como se obtiene en el marco.

No estoy completamente claro cuáles son los supuestos problemas de 'no es seguro para subprocesos' System.Threading.Timer. Quizás sea lo mismo que se hizo en esta pregunta: Seguridad de subprocesos de System.Timers.Timer vs System.Threading.Timer , o tal vez todo el mundo solo quiere decir que:

1. es fácil escribir las condiciones de carrera cuando usas temporizadores. Por ejemplo, vea esta pregunta: Seguridad del hilo del temporizador (System.Threading)

2. reencuentro de notificaciones de temporizador, donde su evento de temporizador puede activarse y devolverle la llamada por segunda vez antes de que termine de procesar el primer evento. Por ejemplo, vea esta pregunta: Ejecución segura para subprocesos utilizando System.Threading.Timer y Monitor

En su libro " CLR Via C # ", Jeff Ritcher desalienta el uso de System.Timers.Timereste temporizador System.ComponentModel.Component, lo que permite su uso en la superficie de diseño de Visual Studio. De modo que solo sería útil si desea un temporizador en una superficie de diseño.

Prefiere utilizarlo System.Threading.Timerpara tareas en segundo plano en un subproceso de grupo de subprocesos.

Información de Microsoft sobre esto (ver Comentarios en MSDN ):

• System.Timers.Timer , que activa un evento y ejecuta el código en uno o más receptores de eventos a intervalos regulares. La clase está diseñada para usarse como un componente de servicio o basado en servidor en un entorno multiproceso; no tiene interfaz de usuario y no es visible en tiempo de ejecución.
• System.Threading.Timer , que ejecuta un único método de devolución de llamada en un subproceso de grupo de subprocesos a intervalos regulares. El método de devolución de llamada se define cuando se crea una instancia del temporizador y no se puede cambiar. Al igual que la clase System.Timers.Timer, esta clase está diseñada para usarse como un componente de servicio o basado en servidor en un entorno multiproceso; no tiene interfaz de usuario y no es visible en tiempo de ejecución.
• System.Windows.Forms.Timer (solo .NET Framework), un componente de Windows Forms que activa un evento y ejecuta el código en uno o más receptores de eventos a intervalos regulares. El componente no tiene interfaz de usuario y está diseñado para su uso en un entorno de subproceso único; se ejecuta en el hilo de la interfaz de usuario.
• System.Web.UI.Timer (solo .NET Framework), un componente ASP.NET que realiza devoluciones de página web asíncronas o síncronas a intervalos regulares.

Es interesante mencionar que System.Timers.Timerfue obsoleto con .NET Core 1.0, pero se implementó nuevamente en .NET Core 2.0 (/ .NET Standard 2.0). El objetivo con .NET Standard 2.0 era que debería ser lo más fácil posible cambiar de .NET Framework, que probablemente sea la razón por la que regresó.

Cuando quedó en desuso, el Complemento de .NET Portability Analyzer Visual Studio recomendó usar System.Threading.Timeren su lugar.

Parece que Microsoft favorece System.Threading.Timerantes System.Timers.Timer.

NOTA DE EDICIÓN 15/11/2018: entrego para cambiar mi respuesta ya que la información anterior sobre .NET Core 1.0 ya no era válida.

Una diferencia importante no mencionada anteriormente que podría atraparte es que System.Timers.Timersilenciosamente traga excepciones, mientras System.Threading.Timerque no.

Por ejemplo:

var timer = new System.Timers.Timer { AutoReset = false };
timer.Elapsed += (sender, args) =>
{
    var z = 0;
    var i = 1 / z;
};
timer.Start();

vs

var timer = new System.Threading.Timer(x =>
{
    var z = 0;
    var i = 1 / z;
}, null, 0, Timeout.Infinite);

Encontré una breve comparación de MSDN

.NET Framework Class Library incluye cuatro clases llamadas Timer, cada una de las cuales ofrece una funcionalidad diferente:

System.Timers.Timer, que activa un evento y ejecuta el código en uno o más receptores de eventos a intervalos regulares. La clase está diseñada para usarse como un componente de servicio o basado en servidor en un entorno multiproceso; no tiene interfaz de usuario y no es visible en tiempo de ejecución.

System.Threading.Timer, que ejecuta un único método de devolución de llamada en un subproceso de grupo de subprocesos a intervalos regulares. El método de devolución de llamada se define cuando se crea una instancia del temporizador y no se puede cambiar. Al igual que la clase System.Timers.Timer, esta clase está diseñada para usarse como un componente de servicio o basado en servidor en un entorno multiproceso; no tiene interfaz de usuario y no es visible en tiempo de ejecución.

System.Windows.Forms.Timer, un componente de Windows Forms que dispara un evento y ejecuta el código en uno o más receptores de eventos a intervalos regulares. El componente no tiene interfaz de usuario y está diseñado para su uso en un entorno de subproceso único.

System.Web.UI.Timer, un componente ASP.NET que realiza devoluciones de datos asíncronas o síncronas de páginas web a intervalos regulares.

Las dos clases son funcionalmente equivalentes, excepto que System.Timers.Timertiene una opción para invocar todas sus devoluciones de llamada de caducidad del temporizador a través de ISynchronizeInvoke configurando SynchronizingObject . De lo contrario, ambos temporizadores invocan devoluciones de llamada de vencimiento en subprocesos de grupo de subprocesos.

Cuando arrastra un objeto System.Timers.Timera una superficie de diseño de formularios Windows Forms, Visual Studio establece SynchronizingObject en el objeto formulario, lo que provoca que todas las devoluciones de llamada de vencimiento se invoquen en el subproceso de la interfaz de usuario.

Desde MSDN: System.Threading.Timeres un temporizador simple y liviano que utiliza métodos de devolución de llamada y es atendido por subprocesos de grupo de subprocesos. No se recomienda su uso con Windows Forms, ya que sus devoluciones de llamada no se producen en el hilo de la interfaz de usuario. System.Windows.Forms.Timeres una mejor opción para usar con Windows Forms. Para la funcionalidad del temporizador basado en el servidor, puede considerar el uso System.Timers.Timer, que genera eventos y tiene características adicionales.

Fuente