Revisiting Thread.Abort() - ¿es seguro?

Question

MSDN sobre la migración de las aplicaciones multitarea heredados (this de página en el manejo de excepciones en las discusiones):

En general, el cambio va a exponer a problemas de programación no reconocidos previamente para que puedan ser corregidos. En algunos casos, sin embargo, los programadores podrían haber aprovechado el backstop de tiempo de ejecución, por ejemplo, para terminar subprocesos. Dependiendo de la situación, deberían considerar una de las siguientes estrategias de migración:

Reestructurar el código para que el hilo salga con elegancia cuando se reciba una señal.

Utilice el método Thread.Abort para abortar el hilo.

Si un hilo debe detenerse para que la finalización del proceso pueda continuar, haga que el hilo sea un hilo de fondo para que termine automáticamente al salir del proceso.

En todos los casos, la estrategia debe seguir las pautas de diseño para excepciones. Ver Pautas de diseño para excepciones.

Esto sugiere que usar Thread.Abort es una forma apropiada de terminar un hilo. ¿Ha cambiado algo mientras yo no estaba mirando? Lo último que escuché fue que esto podría causar comportamientos inesperados, por lo que no debería usarse.

Answer 1

Thread.Abort es mucho más seguro de lo que solía ser por las siguientes razones.

• El tiempo de ejecución diferirá las interrupciones mientras la ejecución está en código no administrado.
• El aborto permitirá que se ejecuten finally bloques.

Sin embargo, todavía hay un problema con exactamente cuándo se inyecta el ThreadAbortException. Considera este código.

public class Example 
{ 
    private DateTime value = DateTime.MinValue; 

    public void DoSomething() 
    { 
    try 
    { 
     value = DateTime.UtcNow; 
    } 
    finally 
    { 
    } 
    } 
} 

Si este código se ejecuta en una plataforma de 32 bits de la variable value podría resultar dañada si Thread.Abort fue llamado y la ThreadAbortException fueron inyectados en el medio de la escritura a value. Como el DateTime tiene 8 bytes, la escritura debe realizarse utilizando más de una instrucción.

Es posible evitar esto colocando el código crítico en un bloque finally y usando Constrained Execution Regions, pero sería increíblemente difícil hacerlo bien para todos excepto para los tipos más simples que defina. Y aun así, no puede simplemente poner todo en un bloque finally.

Answer 2

En general, Thread.Abort matará a los hilos, dejando los datos que estaban procesando en ese momento en un estado desconocido. Como se desconoce el estado, generalmente no es seguro tratar con esos datos nunca más. Sin embargo, cuando intenta terminar un proceso, ya no espera tratar con los datos de ese hilo, entonces, ¿por qué no cancelarlo?

Answer 3

Bueno, el problema con Thread.Abort() es que abortará el hilo posiblemente en el medio del trabajo. Eso podría causar que tu estado se corrompa. Es por eso que es aconsejable usar una bandera bool volátil para controlar el hilo, y dejar que el hilo termine su tarea correctamente, pero basado en ese indicador.

Para más detalles, recuerdo this blog post.