System.Timers.Timer vs System.Threading.Timer

Question

He estado revisando algunos de los posibles temporizadores últimamente, y Threading.Timer y Timers.Timer son los que me parecen más necesarios (dado que admiten la agrupación de subprocesos).

estoy haciendo un juego, y que va a utilizar todo tipo de eventos, con diferentes intervalos, etc.

¿Cuál sería la mejor?

Answer 1

En este artículo se ofrece una explicación bastante completa:

"Comparing the Timer Classes in the .NET Framework Class Library" - también disponible as a .chm file

La diferencia específica parece ser que System.Timers.Timer está orientada a las aplicaciones multitarea, y es por lo tanto seguro para subprocesos a través de su propiedad SynchronizationObject , mientras que System.Threading.Timer irónicamente no es seguro para hilos fuera de la caja.

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

Answer 2

En su libro "CLR a través de C#", Jeff Ritcher desalienta utilizando System.Timers.Timer, este temporizador se deriva de System.ComponentModel.Component, lo que le permite ser utilizado en la superficie de diseño de Visual Studio. De modo que solo sería útil si quiere un temporizador en una superficie de diseño.

Prefiere usar System.Threading.Timer para tareas en segundo plano en un subproceso de grupo de subprocesos.

Answer 3

System.Threading.Timer es un temporizador simple. Te devuelve la llamada a un hilo del grupo de subprocesos (del grupo de trabajadores).

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

System.Windows.Forms.Timer envuelve un nativo message-only-HWND y usa Window Timers para generar eventos en ese bucle de mensajes HWNDs.

Si su aplicación no tiene interfaz de usuario, y desea el temporizador .Net más ligero y de propósito general posible (porque está contento con su propio enhebrado/despacho) entonces System.Threading.Timer es tan bueno como lo consigue en el marco.

No estoy del todo seguro de lo que se supone que son los supuestos problemas con 'System.Threading.Timer'. Quizás es simplemente igual que pidió en esta pregunta: Thread-safety of System.Timers.Timer vs System.Threading.Timer, o tal vez todo el mundo sólo significa que:

1. es fácil escribir las condiciones de carrera cuando se está utilizando temporizadores. P.ej. ver esta pregunta: Timer (System.Threading) thread safety

2. reentrada de las notificaciones del temporizador, donde su evento de temporizador puede activar y volver a llamar al segundo tiempo antes de terminar de procesar la primera evento. P.ej.ver esta pregunta: Thread-safe execution using System.Threading.Timer and Monitor

Answer 4

me encontré con un corto de comparación MSDN

El .NET Framework Class Library incluye cuatro clases denominadas temporizador, cada uno de los cuales ofrece una funcionalidad diferente:

System.Timers.Timer , que dispara un evento y ejecuta el código en uno o más receptores de eventos a intervalos regulares. La clase está destinada al para su uso como componente de servicio o 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 hilo del grupo de subprocesos a intervalos regulares. El método de devolución de llamada es definido cuando se crea una instancia del temporizador y no se puede cambiar. Al igual que la clase System.Timers.Timer, esta clase está pensada para su uso como un componente de servicio o servidor en un entorno multiproceso; no tiene interfaz de usuario y no está visible en el 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 de . El componente no tiene interfaz de usuario y está diseñado para el uso en un entorno de subproceso único.

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

Answer 5

Las dos clases son funcionalmente equivalentes, excepto que System.Timers.Timer tiene una opción para invocar todas sus devoluciones de llamada de expiración del temporizador a través ISynchronizeInvoke estableciendo SynchronizingObject. De lo contrario, ambos temporizadores invocarán devoluciones de llamada de vencimiento en los hilos del grupo de subprocesos.

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

Answer 6

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

Source

Answer 7

Una diferencia importante no citados anteriormente que podría atrapar a salir es que System.Timers.Timer traga silencio excepciones, mientras que System.Threading.Timer 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); 

Answer 8

System.Timers.Timer parece estar en desuso con .NET y ASP.NET Core Core. Intenta usar System.Threading.Timer en futuras aplicaciones.

---

EDIT: OK, quiero ser más preciso:

Con el nuevo Marco de base de .NET, Microsoft suspendió algunas tecnologías de .NET Framework. Para entender eso: .NET Core es un marco totalmente nuevo - reescrito, multiplataforma, etc. No quiero profundizar aquí en detalle - por favor, lea el .NET Blog.

En el blog es un buen artículo abundando portar a .NET Core que explica también las dificultades que puede golpear. Una parte de esto es usar el .NET Portability Analyzer Visual Studio Add-In y corregir los errores que recibe.

Para la clase System.Timers.Timer, dijo, que .NET Framework, se admite versión = v4.6.2, pero .NET Core, Version = v5.0 y .NETPlatform, versión = v5.0 no lo es. Cambios recomendados: Use System.Threading.Timer.

Así que eso me parece que System.Timers.Timer se ha ido para .NET Core.

P.S .: Pero podría volver: Microsoft anunció que desea realizar algunos cambios en CoreCLR (el nombre del marco que utiliza para .NET Core) para facilitar el esfuerzo de portabilidad.