So Thread.Sleep() es malo (http://msmvps.com/blogs/peterritchie/archive/2007/04/26/thread-sleep-is-a-sign-of-a-poorly-designed-program.aspx).Alternativas a Thread.Sleep() para simular pausas
¿Existe alguna alternativa recomendada para simular una pausa en la ejecución de un programa? Por ejemplo, un bucle? Aunque supongo que esto implica una gran cantidad de gastos generales en la inicialización de las variables, comprobar el estado bool, etc.
Gracias
Creo Raymond Chen ha recomendado para establecer la prioridad del hilo inferior
http://blogs.msdn.com/oldnewthing/archive/2009/07/27/9849503.aspx
No entiendo muy bien por qué quiere pausar cada cierto tiempo. ¿Por qué no solo haces el trabajo con baja prioridad? Cuando hay cosas más importantes que hacer, tu hilo de fondo dejará de hacer lo que sea que esté haciendo. Cuando hay una CPU disponible, el hilo de fondo hará su trabajo lo más rápido posible (hasta que llegue algo con mayor prioridad).
Su recomendación es con respecto al "tercer" uso del sueño: para ralentizar la operación y no consumir demasiado tiempo de CPU. La pregunta es sobre la simulación de pausas, que es el uso perfecto para Thread.Sleep. El segundo uso, que el artículo dado en una respuesta diferente discute, es la votación, y eso es malo. – configurator
Si está esperando a que se produzca algún código o evento, puede usar los identificadores de espera.
incluso puede usar waithandles en lugar de Thread.Sleep (time) para hacer lógica periódica. – Alan
No estoy de acuerdo con la evaluación de que Thread.Sleep() es "malo". Depende de la situación.
En un programa de modo de consola, puede ser perfectamente apropiado para dormir el hilo si está esperando algo. Tal vez incluso en un ciclo: verifique la condición, duerma un poco si no está satisfecho, repita.
Sin embargo, en un programa gráfico, normalmente no dormiría en el hilo principal (GUI). Esto se debe a que en la actualidad las interfaces GUI están diseñadas con un solo hilo interactivo. Si duerme en ese hilo, toda su GUI aparecerá "bloqueada" por el tiempo que duerme. Una mejor situación podría ser utilizar algún tipo de temporizador (todos los marcos de GUI tienen ese concepto).
Una cosa que usted hace no quiere hacer es escribir un bucle que comprueba continuamente si alguna condición es verdadera, sin siquiera dormir. Esto hará que una CPU se ejecute hasta el 100% porque la CPU quiere hacer su trabajo lo más rápido posible. Esto no solo es inesperado desde el punto de vista de un usuario, sino que no es amistoso porque tal actividad puede privar al proceso de que realmente está esperando suficientes ciclos para obtener ¡Su trabajo es!
Para eso están las primitivas de sincronización. Ese es el objetivo de la publicación de blog. – ebo
Pero "simular una pausa en la ejecución de un programa" no es para qué sirven las primitivas de sincronización. Ese es el punto de la ** pregunta **. –
Pero está escribiendo que está bien usarlo para la comunicación, que no es así. – ebo
Según lo que ha dicho, está intentando simular una pausa en ejecución.
Thread.Sleep es perfectamente válido para eso. Incluso el artículo que vinculó comienza con:
Thread.Sleep tiene su uso: simula operaciones largas mientras prueba/depura en un hilo MTA.
Si sólo se va a simular una pausa (como en fines de prueba), creo que Thread.Sleep es un enfoque perfectamente válido. Por otro lado, si realmente está esperando algo, algún tipo de mecanismo de señalización seguro de subprocesos sería mejor (compruebe los tipos que heredan WaitHandle).
simulando una pausa
"Simulación" suena como algo que sólo se haría en la depuración. Thread.Sleep debería estar bien.
El principal problema con Sleep es que generalmente debe esperar que ocurra algo específico en lugar de esperar un retraso arbitrario.
El otro aspecto a tener en cuenta es llamar al Thread.Sleep desde un subproceso de IU, lo que hará que la IU no responda. Es mejor inhabilitar las partes de la interfaz de usuario con las que no desea que el usuario interactúe y luego utilizar un control Timer para implementar el retraso.
¡Esta es una sugerencia perfecta! Funcionó como yo quería en mi programa. Acabo de agregar otro temporizador para esperar un tiempo específico antes de pasar a otra parte del programa. – AndHeCodedIt
utilizo el System.Timers:
http://msdn.microsoft.com/en-us/library/system.timers.timer.aspx
Mientras que el artículo en sí es discutible, estoy de acuerdo con su frase de partida, que se ocupa de su preocupación
Thread.Sleep tiene su uso : simulando operaciones prolongadas mientras se prueba/depura en un hilo MTA . En .NET no hay otra razón para usar .
creo que es lo que usted está planteando (simulando pausas) y es el principal uso de Thread.Sleep() que
yo estaría dispuesto a apostar que en la mayoría de los casos en que un programador piensa usando Thread.Sleep(), algún código simple que use event s funcionaría muy bien.
Quiero votar ese artículo, pero no puedo. StackOverflow ha arruinado el resto de Internet para mí. – MusiGenesis
Quiero que ese artículo explique por qué el uso del 100% de la CPU en un ciclo continuo de trabajo es una alternativa preferida a Thread.Sleep (1). – StingyJack