¿Alguien puede encontrar algunos puntos de comparación entre Thread Spawning vs Thread Pooling, cuál es mejor? Considere el .NET Framework como una implementación de referencia que admite ambos.Thread Pool vs Thread Spawning
Un "grupo" contiene una lista de "hilos" disponibles listos para ser utilizados, mientras que "desove" se refiere a crear un nuevo hilo.
La utilidad de "Agrupamiento de subprocesos" radica en "menor tiempo de uso": se evita la sobrecarga de tiempo de creación.
En términos de "cuál es mejor": depende. Si la sobrecarga de tiempo de creación es un problema, use Thread-pooling. Este es un problema común en entornos donde se deben realizar muchas "tareas de corta duración".
Como ha señalado otras personas, hay una "sobrecarga de administración" de rosca-Pooling: esta es mínima si se aplica adecuadamente. P.ej. limitar el número de subprocesos en el grupo es trivial.
hay una gran diferencia (en términos de consumo de tiempo) en crear un nuevo hilo en comparación con elegir una tarea de una cola y asignarla a un hilo desde un grupo, en Windows XP OS? – reonze
No he hecho ninguna programación seria de Windows en años, pero estoy bastante seguro de que elegir un hilo disponible de una lista (operación simple) es mucho más barato que generar un nuevo hilo. – jldupont
Engendrar un nuevo hilo físico significará una transición al modo Kernel y la configuración de varias estructuras de mernel, por lo que la sobrecarga será mayor. Pero como todos sabemos, no debes optimizar prematuramente.Si solo creas un hilo, no notarás la sobrecarga, si creas miles probablemente lo harás, pero incluso eso probablemente dependa del trabajo que está haciendo el hilo, lo que puede saturar el tiempo que lleva crear el hilo. –
Depende de lo que desea ejecutar en el otro subproceso.
Para tareas cortas, es mejor utilizar un grupo de subprocesos, para tareas largas puede ser mejor generar un nuevo subproceso, ya que podría privar al grupo de subprocesos para otras tareas.
También es bueno para el análisis de rendimiento y el registro que puede cambiar el nombre de un hilo generado y así facilitar el análisis del rendimiento: si se trata de un hilo, es más difícil adivinar qué hilo pertenece a cada tarea. – weismat
Para obtener una definición de "mejor", generalmente quiere ir con un grupo de subprocesos. Sin saber cuál es su caso de uso, considere que con un grupo de subprocesos, tiene un número fijo de subprocesos que pueden crearse al inicio o pueden crearse según demanda (pero el número de subprocesos no puede exceder el tamaño del grupo). Si se envía una tarea y no hay ningún hilo disponible, se coloca en una cola hasta que haya un hilo libre para manejarla.
Si estás generando hilos en respuesta a solicitudes o algún otro tipo de disparador, corres el riesgo de agotar todos tus recursos ya que no hay nada que limite la cantidad de hilos creados.
Otro beneficio para la agrupación de subprocesos es la reutilización: los mismos subprocesos se utilizan una y otra vez para manejar tareas diferentes, en lugar de tener que crear un nuevo subproceso cada vez.
Según lo señalado por otros, si tiene un número pequeño de tareas que se ejecutarán durante mucho tiempo, esto anularía los beneficios obtenidos al evitar la creación frecuente de subprocesos (ya que no necesitaría crear una tonelada de subprocesos de todos modos)
No hay ninguna razón por la que no puedas limitar el número de subprocesos generados. –
Eso es cierto, no dije que fuera imposible. Pero entonces, ¿por qué no usar un grupo? – danben
Bueno, a menos que 'en general' sea una tarea relativamente larga (en realidad algo más de unos pocos segundos es realmente). (Ab) usar el grupo de subprocesos para operaciones de larga duración podría conducir a formas desagradables de interbloqueos, etc. –
La diferencia principal es que un ThreadPool mantiene un conjunto de subprocesos que ya están configurados y disponibles para su uso, porque iniciar un nuevo subproceso puede ser costoso para el procesador.
Sin embargo, tenga en cuenta que incluso un ThreadPool necesita "engendrar" hilos ... generalmente depende de la carga de trabajo; si hay mucho trabajo por hacer, un buen threadpool activará nuevos hilos para manejar la carga en función de configuración y recursos del sistema.
Todo depende de su situación. La creación de nuevos hilos consume muchos recursos y es una operación costosa. La mayoría de las operaciones asíncronas muy cortas (menos de unos pocos segundos como máximo) podrían hacer uso del grupo de subprocesos.
Para operaciones de ejecución prolongada que desea ejecutar en segundo plano, normalmente crearía (generaría) su propio hilo. (Ab) utilizando una plataforma/subprocesos de tiempo de ejecución incorporados para operaciones de larga ejecución podría conducir a formas desagradables de interbloqueos, etc.
Se necesita poco tiempo adicional para crear/engendrar hilo, mientras que la encuesta de hilos ya contiene hilos creados que están listos para ser utilizados.
Mi sensación es que deberías comenzar simplemente creando un hilo según sea necesario ... Si el rendimiento de esto está bien, entonces has terminado. Si en algún momento detecta que necesita una latencia menor en torno a la creación de subprocesos generalmente puede soltar un grupo de subprocesos sin romper nada ...
Los subprocesos de grupo de subprocesos son mucho más baratos que un subproceso normal, agrupan los recursos de sistema necesarios para hilos. Pero tienen una serie de limitaciones que pueden hacerlos no aptos:
Las dos últimas restricciones son un efecto secundario del planificador de subprocesos, trata de limitar el número de subprocesos activos al número de núcleos que tiene su CPU. Esto puede causar largas demoras si programa muchos hilos de ejecución larga que bloquean a menudo.
Muchas otras implementaciones de subprocesos tienen limitaciones similares, dar o recibir.
Esta respuesta es totalmente específica de idioma/plataforma, pero está redactada como si fuera una respuesta general. Como OP no mencionó ni una plataforma ni un idioma: -1 –
de acuerdo con usted. – Rubyrider
La agrupación de subprocesos generalmente se considera mejor, porque los subprocesos se crean por adelantado y se usan según sea necesario. Por lo tanto, si usa muchos hilos para tareas relativamente cortas, puede ser mucho más rápido. Esto se debe a que se guardan para uso futuro y no se destruyen y luego se vuelven a crear.
Por el contrario, si solo necesita 2-3 hilos y solo se crearán una vez, esto será mejor. Esto se debe a que no obtiene ganancias del almacenamiento en memoria caché de los hilos existentes para usarlos en el futuro, y no está creando hilos adicionales que podrían no ser utilizados.
Este answer es un buen resumen pero por si acaso, aquí está el enlace a Wikipedia:
para Multi ejecución de rosca combinada con la obtención de los valores de retorno de la ejecución, o de una manera fácil de detectar que se ha completado un threadpool, se podría usar java Callables.
Ver https://blogs.oracle.com/CoreJavaTechTips/entry/get_netbeans_6 para obtener más información.
"mejor" depende de su plataforma – skaffman