Comparar usando Thread.Sleep y Timer para la ejecución retrasada

Question

Tengo un método que se debe retrasar durante un período de tiempo específico.

¿Debo usar

Thread thread = new Thread(() => { 
    Thread.Sleep(millisecond); 
    action(); 
}); 
thread.IsBackground = true; 
thread.Start(); 

O

Timer timer = new Timer(o => action(), null, millisecond, -1); 

había leído algunas articles sobre el uso de Thread.Sleep es un mal diseño. Pero realmente no entiendo por qué.

Pero para usar el temporizador, el temporizador tiene un método de eliminación. Dado que la ejecución se retrasa, no sé cómo deshacerme del temporizador. ¿Tienes alguna sugerencia?

O si tiene códigos alternativos para la ejecución diferida también son apreciados.

Answer 1

Una diferencia es que System.Threading.Timer distribuye la devolución de llamada en un subproceso de grupo de subprocesos, en lugar de crear un nuevo subproceso cada vez. Si necesita que esto suceda más de una vez durante la vida de su aplicación, esto ahorrará la sobrecarga de crear y destruir un grupo de hilos (un proceso que consume muchos recursos, como señala el artículo que referencia), ya que lo hará solo reutilice los hilos en el grupo, y si va a tener más de un temporizador funcionando a la vez, significa que tendrá menos hilos ejecutándose al mismo tiempo (lo que también ahorrará considerables recursos).

En otras palabras, Timer va a ser mucho más eficiente. También puede ser más preciso, ya que Thread.Sleep solo garantiza que esperará al menos el tiempo que especifique (el sistema operativo puede ponerlo a dormir durante mucho más tiempo). De acuerdo, Timer aún no será exactamente exacto, pero la intención es disparar la devolución de llamada lo más cerca posible del tiempo especificado, mientras que NO es necesariamente la intención de Thread.Sleep.

En cuanto a la destrucción del temporizador, la devolución de llamada puede aceptar un parámetro, por lo que puede pasar el temporizador como parámetro y llamar a Dispose en la devolución de llamada (aunque no lo he probado, supongo que es es posible que el temporizador se bloquee durante la devolución de llamada).

Editar: No, supongo que no puede hacer esto, ya que tiene que especificar el parámetro de devolución de llamada en el propio constructor del temporizador.

Quizás algo como esto? (De nuevo, en realidad no han probado)

class TimerState 
{ 
    public Timer Timer; 
} 

... y para iniciar el temporizador:

TimerState state = new TimerState(); 

lock (state) 
{ 
    state.Timer = new Timer((callbackState) => { 
     action(); 
     lock (callbackState) { callbackState.Timer.Dispose(); } 
     }, state, millisecond, -1); 
} 

El bloqueo debe impedir la devolución de llamada del temporizador de tratar de liberar el temporizador antes de que el temporizador campo que se ha establecido.

---

Adición: Como el comentarista señaló, si la acción() hace algo con la interfaz de usuario, y luego usando un System.Windows.Forms.Timer es probablemente una mejor opción, ya que se ejecutará la devolución de llamada en la interfaz de usuario hilo. Sin embargo, si este no es el caso, y depende de Thread.Sleep vs. Threading.Timer, Threading.Timer es el camino a seguir.

Answer 2

Creo que Thread.Sleep está bien si realmente desea pausar la aplicación durante un período de tiempo específico. Creo que la razón por la que las personas dicen que es un mal diseño es porque en la mayoría de las situaciones las personas no quieren que la aplicación haga una pausa.

Por ejemplo, estaba trabajando en un cliente pop3 donde el programador estaba usando Thread.Sleep (1000) para esperar mientras el socket recuperaba el correo. En esa situación, era mejor conectar un controlador de eventos al zócalo y continuar la ejecución del programa después de que el socket se hubiera completado.

Answer 3

La única carne que tengo con el System.Timer es que la mayoría de las veces que he visto que se usa para los largos retrasos (horas, minutos) en los servicios de votación y los desarrolladores a menudo se olvide de poner en marcha el evento Antes de que empiecen el temporizador Esto significa que si inicio la aplicación o el servicio, tengo que esperar hasta que el temporizador haya transcurrido (horas, minutos) antes de que se ejecute.

Claro, esto no es un problema con el temporizador, pero creo que a menudo se usa incorrectamente porque es muy fácil de usar.

Answer 4

uso ThreadPool.RegisterWaitForSingleObject en lugar de temporizador:

//Wait 5 seconds then print out to console. 
//You can replace AutoResetEvent with a Semaphore or EventWaitHandle if you want to execute the command on those events and/or the timeout 
System.Threading.ThreadPool.RegisterWaitForSingleObject(new AutoResetEvent(false), (state, bTimeout) => Console.WriteLine(state), "This is my state variable", TimeSpan.FromSeconds(5), true); 

Answer 5

@miniscalope n no utilice ThreadPool.RegisterWaitForSingleObject en lugar de temporizador, System.Threading.Timer pondrá en cola una devolución de llamada a ejecutar en un subproceso del grupo de subprocesos cuando el ha transcurrido el tiempo y no requiere un identificador de espera, espere a que un solo objeto inmovilice un subproceso de subprocesamiento esperando a que se señalice el evento o expire el tiempo de espera antes de que el subproceso llame a la devolución de llamada.

Answer 6

Recuerdo implementar una solución similar a la de Eric. Esto es sin embargo un funcionamiento uno;)

class OneTimer 
    { 
     // Created by Roy Feintuch 2009 
     // Basically we wrap a timer object in order to send itself as a context in order to dispose it after the cb invocation finished. This solves the problem of timer being GCed because going out of context 
     public static void DoOneTime(ThreadStart cb, TimeSpan dueTime) 
     { 
      var td = new TimerDisposer(); 
      var timer = new Timer(myTdToKill => 
      { 
       try 
       { 
        cb(); 
       } 
       catch (Exception ex) 
       { 
        Trace.WriteLine(string.Format("[DoOneTime] Error occured while invoking delegate. {0}", ex), "[OneTimer]"); 
       } 
       finally 
       { 
        ((TimerDisposer)myTdToKill).InternalTimer.Dispose(); 
       } 
      }, 
         td, dueTime, TimeSpan.FromMilliseconds(-1)); 

      td.InternalTimer = timer; 
     } 
    } 

    class TimerDisposer 
    { 
     public Timer InternalTimer { get; set; } 
    }