La siguiente función System.Threading.Thread.Sleep(); retrasa el subproceso en milisegundos y toma el valor entero como un parámetro. ¿Hay algún método de retraso de hilo en microsegundos? ¿O puede la función de dormir tomar los valores de flotación? GraciasRetardo de tiempo en C#
No. Para citar a Will Dean de 85122
no puede 'dormir' significativamente (es decir, renunciar a su CPU programada) durante tan cortos períodos. Si quieres demorar por un tiempo corto, entonces necesitas girar, verificando repetidamente un temporizador de alta resolución (por ejemplo, el "temporizador de rendimiento") y esperando que algo de alta prioridad no te prevenga de todos modos.
La mejor granularidad que encontrará para Thread.Sleep es usar la clase TimeSpan. Desafortunadamente, la granularidad más pequeña que admite es de milisegundos. No hay forma de dormir en el rango de microsegundos.
El sueño no es exacto al milisegundo en primer lugar. Creo que su resolución depende del hardware, y el menor período de tiempo que puede dormir será, generalmente, de alrededor de 20 ms. Esto tiene que ver con que Sleep realmente libera lo que podría quedar del timeslice actual del thread; y permite que se ejecute otro subproceso. La primera vez que su subproceso se podrá ejecutar de nuevo, es después de que haya pasado un ciclo de tiempo del planificador de subprocesos. Por lo tanto, la resolución es de aproximadamente 20 ms (suponiendo que el tiempo de su sistema es de 20 ms).
Dado que Windows no es un sistema operativo en tiempo real; El sueño y otras funciones de espera nunca pueden ser totalmente deterministas.
Dependiendo de su aplicación, tal vez pueda hacer un sueño la mayor parte del tiempo y luego hacer una espera ocupada donde el tiempo es crítico. O reescriba la estructura para que pueda medir el tiempo pasado con precisión (use System.Diagnostics.Stopwatch); pero no dependa de poder dormir durante un período de tiempo preciso en el rango de milisegundos.
El first answer in this thread on MSDN también lo explica muy bien.
Siempre pensé que la granularidad era ~ 55ms, es decir, 18 tics/segundo. – RedFilter
Esto fue en los buenos viejos días de DOS (y tal vez en Windows temprano). 1,193,180 Hz/2^16 –
Tuve que escribir un programa de música donde las notas tuvieran que comenzar/detenerse en la duración correcta, precisamente, así que usé el temporizador de alta resolución en DirectX para hacerlo, pero mi aplicación también se mantendría en la parte superior y acapara la CPU, por lo que podría seguir buscando cuándo hacer la siguiente acción.
Dado que no hay forma de saber exactamente cuándo el sistema operativo devolverá el control a su aplicación, Thread.Sleep será una opción muy mala y, como se mencionó, el incremento de tiempo más pequeño puede variar entre 10 y 50 ms, en mi experiencia.
Proporcionar una respuesta significativa a esta pregunta sería más fácil si usted indica por qué necesita dormir por períodos tan cortos. Quizás haya un enfoque diferente para lograr lo que necesita de una manera que no requiera ninguna llamada a Sleep(). – LBushkin
[mira lo que dije en otra pregunta sobre el cronómetro] (http://stackoverflow.com/questions/1631501/need-microsecond-delay-in-net-app-for-throttling-udp-multicast-transmission-rate/ 1631542 # 1631542) – Fredou
no vio que era una pregunta de mayo :-p – Fredou