.net - tick - System.Timers.Timer vs System.Threading.Timer

timer tick

Question

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

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

¿Cuál sería el mejor?

Answer 1

De MSDN: System.Threading.Timer es un temporizador simple y ligero 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, porque sus devoluciones de llamada no se producen en el hilo de la interfaz de usuario. System.Windows.Forms.Timer es una mejor opción para usar con Windows Forms. Para la funcionalidad de temporizador basada en servidor, puede considerar usar System.Timers.Timer , que genera eventos y tiene características adicionales.

Source

Answer 2

En su libro " CLR Via C # ", Jeff Ritcher no System.Timers.Timer uso de los temporizadores de tiempo del sistema. Este temporizador se deriva de 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 usar System.Threading.Timer para tareas en segundo plano en un grupo de subprocesos.

Answer 3

Encontré una breve comparación de MSDN

La biblioteca de clases de .NET Framework incluye cuatro clases llamadas Temporizador, 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 el temporizador se crea una instancia 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 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 un solo hilo.

System.Web.UI.Timer , un componente de ASP.NET que realiza devoluciones de datos de página web asíncronas o síncronas en un intervalo regular.

Answer 4

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 archivo .chm

La diferencia específica parece ser que System.Timers.Timer está orientado hacia aplicaciones de múltiples subprocesos y, por lo tanto, es seguro para subprocesos a través de su propiedad SynchronizationObject , mientras que System.Threading.Timer irónicamente, no es seguro para subprocesos.

No creo que haya una diferencia entre los dos en cuanto a lo pequeños que pueden ser tus intervalos.

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 de ISynchronizeInvoke configurando SynchronizingObject . De lo contrario, ambos temporizadores invocan devoluciones de llamada de caducidad en subprocesos de agrupación de hilos.

Cuando arrastra un System.Timers.Timer a una superficie de diseño de Windows Forms, Visual Studio establece SynchronizingObject en el objeto de formulario, lo que hace que todas las devoluciones de llamada de caducidad sean llamadas en el subproceso de la interfaz de usuario.

Answer 6

Una diferencia importante que no se mencionó anteriormente y que podría sorprenderlo es que System.Timers.Timer silencia las excepciones, mientras que System.Threading.Timer no lo hace.

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 7

System.Threading.Timer es un temporizador simple. Te devuelve la llamada a un subproceso de subproceso (desde el grupo de trabajo).

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 lugar, System.Windows.Forms.Timer ajusta un message-only-HWND nativo message-only-HWND y utiliza los temporizadores de ventana para generar eventos en ese bucle de mensajes HWND.

Si su aplicación no tiene una interfaz de usuario y desea el temporizador .Net más liviano y de propósito general posible (porque está contento de descubrir su propio subprocesamiento / envío), entonces System.Threading.Timer es tan bueno como entra el marco.

No estoy completamente claro cuáles son los problemas supuestos ''no seguros para subprocesos'' con System.Threading.Timer . Tal vez sea exactamente igual a lo que se pregunta en esta pregunta: Seguridad de subprocesos de System.Timers.Timer vs System.Threading.Timer , o quizás todo el mundo simplemente significa que:

1. Es fácil escribir condiciones de carrera cuando estás usando temporizadores. Por ejemplo, vea esta pregunta: Temporizador (System.Threading) hilo de seguridad

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

Answer 8

System.Timers.Timer parece estar obsoleto con .NET Core y ASP.NET Core. Así que intente usar System.Threading.Timer en aplicaciones futuras.

EDITAR: OK, déjame ser más preciso:

Con el nuevo .NET Core Framework, Microsoft descontinuó algunas tecnologías de .NET Framework. Para comprender que: .NET Core es un marco totalmente nuevo (reescrito, multiplataforma, etc. No quiero profundizar en detalles aquí), lea el Blog de .NET .

En el blog hay un buen artículo que abunda en el uso de .NET Core, que explica también las dificultades que puede encontrar. Una parte de esto es usar el complemento de Visual Studio del analizador de portabilidad .NET y corregir los errores que obtenga.

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

Así que eso busca que System.Timers.Timer se haya ido para .NET Core.

PD: Pero podría volver: Microsoft anunció que desea realizar algunos cambios en CoreCLR (el nombre del marco que usa para .NET Core) para facilitar el esfuerzo de adaptación.