¿Es un éxito de rendimiento crear subprocesos que hacen un bucle mucho para comprobar las cosas?

7

Esta es una pregunta genérica que siempre me he preguntado.

En general, ¿es intensivo para una CPU crear subprocesos que realizan bucles "si bien no es cierto ..." o algo similar?

Por ejemplo, supongamos que sí:

// pseudo-code
new Thread(function() {
    while (!useHasDoneSomething) {
        // do nothing...
    }
    alert("you did something!");
}

Así que es solo un fragmento de código que se ejecuta en un hilo que espera que algo suceda.

Por alguna razón, imagino que esto presionaría a la CPU. Después de todo, aunque solo sea un pequeño bucle, se vuelve a ejecutar el bucle en el instante en que se realiza un ciclo. ¿No significa esto que está pasando por el ciclo muchas veces por milisegundo? ... ¿Por nanosegundo ??

El sistema operativo "manejará" el programa y los subprocesos, ¿verdad? Pero eso sigue siendo una gran cantidad de atención para ejecutar un bucle. Si la CPU no tiene nada más que hacer, ¿no se centrará simplemente en ese bucle y, por lo tanto, consumirá todo el tiempo de inactividad ?

¿Qué pasa si creo 1000 subprocesos que todos hacen el mismo bucle? ¿Cómo podría afectar eso al rendimiento / ciclos de CPU?

Además, ¿es así como los eventos funcionan internamente? Cuando está 'escuchando' un evento en Java, .NET, Javascript, etc. (como presionar un botón o cambiar el tamaño de una ventana), ¿se ha creado un hilo que crea bucles?

    
pregunta Rowan Freeman 22.05.2013 - 06:14

4 respuestas

12
  

En general, ¿es intensivo para una CPU crear subprocesos que realicen bucles "si bien no es cierto ..." o algo similar?

Sí. El uso de dicho bucle se denomina ocupado esperando y se llama así por un motivo. Estos bucles ocupados comprueban la condición tan a menudo y tan rápido como el procesador puede administrarlo, con el resultado de que, si permanece en el bucle el tiempo suficiente, la carga del procesador se incrementa de manera confiable al 100%.

  

¿Qué pasa si creo 1000 hilos que todos hacen el mismo bucle? ¿Cómo podría afectar eso a los ciclos de rendimiento / CPU?

Solo crea más trabajo para la CPU haciendo anotaciones.

  

Además, ¿es así como funcionan los eventos internamente? Cuando está 'escuchando' un evento en Java, .NET, Javascript, etc. (como presionar un botón o cambiar el tamaño de una ventana), ¿se ha creado un hilo que crea bucles?

No. Los bucles ocupados son una forma de sondeo y también muy ineficiente. Los sistemas operativos tienen otros mecanismos para detectar que ha ocurrido un evento (por ejemplo, una interrupción o una llamada específica) y tienen mecanismos para dejar que un hilo lo espere sin consumir tiempo de CPU. Estos mecanismos también se utilizarán para implementar los mecanismos de eventos de lenguajes como Java.

    
respondido por el Bart van Ingen Schenau 22.05.2013 - 08:46
9

Tu instinto es correcto. Busy-waiting así se describe como

  

El spinning puede ser una estrategia válida en ciertas circunstancias, especialmente en la implementación de los spinlocks en sistemas operativos diseñados para ejecutarse en sistemas SMP. En general, sin embargo, la rotación se considera un antipatrón y debe evitarse, ya que el tiempo del procesador que podría usarse para ejecutar una tarea diferente se desperdicia en una actividad inútil.

En su lugar, debe considerar una primitiva de control de concurrencia que permita que el hilo realmente quede inactivo hasta que tenga un trabajo útil que hacer, por ejemplo, un semáforo o una variable de condición :

  

Para muchas aplicaciones, la exclusión mutua no es suficiente. Es posible que los hilos que intentan una operación tengan que esperar hasta que alguna condición sea verdadera. Un bucle de espera ocupado, como

while not( condition ) do 
   // nothing
end
     

no funcionará, ya que la exclusión mutua evitará que cualquier otro hilo entre en el monitor para que la condición sea verdadera. Existen otras "soluciones". Como tener un bucle que desbloquea el monitor, espera una cierta cantidad, lo bloquea y verifica la condición P. En teoría, funciona y no se bloquea, pero surgen problemas. Es difícil decidir una cantidad apropiada de tiempo de espera, demasiado pequeño y el hilo acaparará la CPU, demasiado grande y aparentemente no responderá. Lo que se necesita es una forma de señalar el hilo cuando la condición P es verdadera (o podría ser cierta).   La solución son las variables condicionales. Conceptualmente, una variable de condición es una cola de subprocesos, asociada con un monitor, en la que un subproceso puede esperar a que se cumpla alguna condición. Así, cada variable de condición está asociada con una aserción. Mientras un subproceso está esperando en una variable de condición, no se considera que ese subproceso ocupe el monitor, por lo que otros subprocesos pueden ingresar al monitor para cambiar el estado del monitor. En la mayoría de los tipos de monitores, estos otros hilos pueden señalar la variable de condición para indicar que la afirmación es verdadera en el estado actual.

    
respondido por el Steven Schlansker 22.05.2013 - 07:30
2

Los subprocesos deben esperar los eventos entrantes, no los cambios de variables.

Los eventos entrantes son semáforos que están disponibles, que las colas de mensajes no están vacías o el tiempo transcurrido:

semGet()
msqRead()
sleep()

Desde el punto de vista del hilo, estas llamadas de función están bloqueando: el hilo espera hasta que llegue el evento, dejando la carga de la CPU en otros subprocesos.

Desde el punto de vista del sistema, el hilo está marcado como "En espera del evento" y no se programará mientras el evento no haya aparecido.

Sobre los eventos de hardware, se manejan mediante interrupciones que son señales eléctricas para la CPU y que activan la ejecución de ISR (rutinas de servicio de interrupción), cuya función es producir un evento de software en semáforos, colas de mensajes o tiempo. p>     

respondido por el mouviciel 22.05.2013 - 09:43
0

La parte //do nothing dentro de la condición while en un escenario normal es WAIT en algún semáforo, o en otros términos SLEEP. Duerme hasta que alguna interrupción te haya despertado. Y, por lo tanto, el hilo pasa al "estado de suspensión" o simplemente diga "no está ejecutando el estado". Sólo los procesos que están en estado de ejecución consumen CPU. El proceso de estado de suspensión no consumirá CPU. Pueden estar consumiendo memoria, pero esa memoria se intercambiará internamente por el sistema de memoria virtual. Así que incluso si crea 1000 hilos de este tipo, no supondrán una gran amenaza para su sistema.

    
respondido por el Manoj R 22.05.2013 - 07:03

Lea otras preguntas en las etiquetas