c# - threading - timers timer vb net

Seguridad de subprocesos de System.Timers.Timer vs System.Threading.Timer

Question

En este artículo: http://msdn.microsoft.com/en-us/magazine/cc164015.aspx el autor afirma que System.Threading.Timer no es seguro para subprocesos .

Desde entonces, esto se ha repetido en los blogs, en el libro de Richter "CLR via C #", en SO, pero esto nunca se justifica.

Además, la documentación de MSDN asegura que "este tipo es seguro para subprocesos".

1) ¿Quién dice la verdad?

2) Si este es el artículo original, ¿qué hace que System.Threading.Timer no sea seguro para subprocesos y cómo su envoltura System.Timers.Timer logra una mayor seguridad de subprocesos?

Gracias

Answer 1

No, no es así como funciona. Las clases de .NET asynchronous Timer son perfectamente seguras para subprocesos. El problema con la seguridad de subprocesos es que no es una propiedad transitiva, tampoco hace que el otro código que se ejecuta sea seguro para subprocesos. El código que escribiste, no un programador de .NET Framework.

Es el mismo tipo de problema con la suposición muy común de que el código de la interfaz de usuario de Windows es fundamentalmente inseguro de subprocesos. No lo es, el código dentro de Windows es perfectamente seguro para subprocesos. El problema es que todo el código que se ejecuta no es parte de Windows y no está escrito por un programador de Microsoft. Siempre hay mucho de ese código, activado por una llamada SendMessage (). Que ejecuta código personalizado que escribió un programador. O código que no escribió, como un gancho instalado por alguna utilidad. Código que asume que el programa no lo hace difícil y solo ejecuta los manejadores de mensajes en un hilo. Normalmente lo hace, no hacerlo le causa muchos problemas.

Mismo problema con el evento System.Timers.Timer.Elapsed y la devolución de llamada System.Threading.Timer. Los programadores cometen muchos errores al escribir ese código. Se ejecuta de forma asíncrona en un subproceso de subprocesos arbitrario, tocar cualquier variable compartida realmente requiere bloqueo para proteger el estado. Muy fácil de pasar por alto. Y peor aún, mucho peor, es muy fácil meterse en un montón de problemas cuando el código se ejecuta nuevamente , antes de que la invocación anterior dejara de ejecutarse. Se dispara cuando el intervalo del temporizador es demasiado bajo o la máquina está demasiado cargada. Ahora hay dos hilos que ejecutan el mismo código, que rara vez llega a un buen final.

Roscar es difícil, noticias a las once.