Siéntete libre de compartir nuestra página y códigos en tus redes, apóyanos para hacer crecer nuestra comunidad.
El WaitHandle type y los tipos derivados proporcionan un mecanismo de espera controlado por eventos que se vincula con el sistema operativo. Por ejemplo, cuando tienes un Task y esperas el resultado accediendo task.Result, la implementación interna no realiza encuestas con Thread.Sleep llamadas en el medio. Está usando un WaitHandle-Tipo derivado para hacer espera y sincronización.
A veces es necesario un enfoque basado en encuestas, como en algunos de los ejemplos que dio en su lista de viñetas, pero a menudo poder en su lugar, utilice un enfoque basado en eventos. No es eso Thread.Sleep es siempre malo, es solo que es muy a menudo mal utilizado.
Es la naturaleza del software esperar otras cosas en un entorno de subprocesos múltiples con factores externos que afectan su código, a veces es necesario esperar …
A Espere está bien. A esperar con la votación a menudo no es . Si hay alguna forma de que pueda utilizar unespera impulsada por eventos
, normalmente deberías esforzarte por usarlo.
No tengo una idea muy clara de qué es exactamente lo que estás preguntando, así que no daré más detalles. Si dejas un comentario, puedo ampliar mi respuesta. La razón teórica
esperando con la votación
//START
Begin();
while (!Done())
Thread.Sleep(D);
//STOP
Begin() es malo es el siguiente: Done() Supongamos que tengo un código que se parece a esto: true inicia alguna operación. T regresando
- significa que la operación ha finalizado. Suponga que esto sucederá después de aproximadamente
Done()hora. Entonces:T/DEl hilo se despierta y verifica la condición (llama - )
STARTvecesSTOPLa duración desdeD/2aThread.Sleep
incluye un esperado D puramente por el D¿Qué valor de START deberías elegir? A medida que aumenta STOP , la forma de duración esperada Da 1/Daumenta linealmente. A medida que disminuyes D , el (límite en el) número de iteraciones aumenta a medida que
. Ambos son malos y encontrar el derecho es problemático.Ahora compare esto con un
//START
Begin();
WaitDone();
//STOP
espera impulsada por eventos WaitDone() : Teóricamente hablando, siempre que de alguna manera espera mágicamente hasta que la operación haya terminado, pero ya no, ambos problemas identificados en el
esperando con la votación WaitHandle caso han desaparecido: este hilo espera exactamente la cantidad de tiempo correcta, ¡ni más ni menos!
Para reiterar el punto con el que comencé: en .NET, el
La clase y los tipos derivados son los que facilitan este enfoque.
Bueno, dijiste la mayor parte. Citando “Todos sabemos que la creación de subprocesos es costosa y el bloqueo de subprocesos significa contención en el grupo”, por lo que incluso comprende de qué se trata el uso de un grupo de subprocesos.
También comprende que bloquear el hilo de la interfaz de usuario es malo.
Mirando el modelo de grupo de subprocesos nuevamente: tiene un grupo de subprocesos, tal vez uno por procesador, y luego les pasa tareas. ¿Qué sentido tendría que uno de esos hilos se bloqueara? Si no tiene trabajo que realizar ahora, simplemente debería proceder a una tarea diferente.
Entonces, yendo directamente a su pregunta “Lo que me lleva a mi punto, si realmente necesita realizar un sueño, ¿qué debería usar si no es Thread.Sleep?”, En un programa moderno y bien diseñado, nunca necesitaría hacer , simplemente programaría una tarea para este último.
- Debe pensar en los subprocesos de un grupo, al igual que en los procesadores de un sistema, como recursos, que deben liberarse a otros cuando no se necesitan.
- En cuanto a sus ejemplos, está demasiado involucrado en el paradigma de la programación imperativa.
- No necesitas esperar a que desaparezca un proceso … No me imagino por qué necesitas esto, pero si tienes que esperar es porque tienes trabajo que realizar después de algún tiempo, la “continuación” de tu función. Debe configurar un temporizador para esta “continuación”.
Los ejemplos de archivos deberían tener otros mecanismos para ello, si no los tienen … ese sería un buen diseño de sistema operativo. Por ejemplo, la única forma segura de esperar a que se vacíen los búferes sería una primitiva del sistema operativo, como fsync.
Si alguien escribe en un archivo y luego otra lectura del archivo, entonces se necesita un mecanismo de sincronización, no una espera programada (a menos que el archivo sea solo para agregar, en cuyo caso el archivo en sí es el mecanismo de sincronización).
Esperar un mecanismo de sincronización no es “malo”.
Te invitamos a ayudar nuestra labor ejecutando un comentario y dejando una valoración te damos la bienvenida.