En lo que a mí respecta, la cantidad ideal de subprocesos es 3: uno para la interfaz de usuario, uno para recursos de CPU y uno para recursos de IO.¿Cuándo debo usar los hilos?
Pero probablemente estoy equivocado.
Me acaban de presentar, pero siempre he usado uno para la interfaz de usuario y otro para todo lo demás.
¿Cuándo debería usar hilos y cómo? ¿Cómo sé si debería usarlos?
Desafortunadamente, no existen reglas estrictas para usar Threads. Si tiene demasiados hilos, el procesador pasará todo el tiempo generando y cambiando entre ellos. Use muy pocos hilos, no obtendrá el rendimiento que desea en su aplicación. Además, usar hilos no es fácil. Un lenguaje como C# lo hace más fácil porque tiene herramientas como ThreadPool.QueueUserWorkItem. Esto permite que el sistema administre la creación y destrucción de hilos. Esto ayuda a mitigar la sobrecarga de crear un nuevo hilo para pasar el trabajo. Debes recordar que la creación de un hilo no es una operación que obtienes por "gratis". Hay costos asociados con el inicio de un hilo, por lo que siempre se debe tener en cuenta.
Dependiendo del idioma que use para escribir su aplicación, le dirá cuánto debe preocuparse por el uso de los hilos.
Los tiempos me parecen más a menudo que tengo que considerar la creación de hilos explícitamente son:
Desde SQLite FAQ: "Threads are evil. Evítelos". Solo úselos cuando sea absolutamente necesario.
Si es necesario, tome medidas para evitar la carnicería habitual. Utilice grupos de subprocesos para ejecutar tareas detalladas sin interdependencias, utilizando instalaciones proporcionadas por GUI-framework para enviar resultados a la interfaz de usuario. Evite compartir datos entre hilos de larga ejecución; use las colas de mensajes para pasar información entre ellos (y para sincronizar).
Una solución más exótica es utilizar lenguajes como Erlang que están diseñados explícitamente para el paralelismo de grano fino sin sacrificar la seguridad y la comprensibilidad. La concurrencia en sí es de fundamental importancia para el futuro de la computación; los hilos son simplemente una forma horrible y rota de expresarlo.
no seas dogmático. Los hilos no son malvados por sí mismos. Es un gran patrón para separar la interfaz de usuario y el hilo de actividad de fondo, proporciona una mejor experiencia de usuario. – Andrey
+1: si puede salirse con la suya sin utilizar los subprocesos, hágalo, sin duda hará que las pruebas y la depuración sean mucho más fáciles, y probablemente contribuyan a un producto más estable a largo plazo. Si * tiene * para usar hilos, hágalo juiciosamente. –
@Andrey, las personas más inteligentes que conozco son las menos optimistas sobre el uso de subprocesos en su código. Siga el enlace en PDF que proporcioné. –
La respuesta depende totalmente de lo que planeas hacer. Sin embargo, uno de los recursos de la CPU es un mal movimiento: su CPU puede tener hasta seis núcleos, más hyperthreading, en una CPU minorista, y la mayoría de las CPU tendrá dos o más. En este caso, debe tener tantos hilos como núcleos de CPU, más algunos más para programar percances. La CPU completa no es una bestia de un solo subproceso, puede tener muchos núcleos y necesita muchos subprocesos para un 100% de utilización.
Debería usar subprocesos si y solo si su grupo demográfico objetivo tendrá virtualmente todos los núcleos múltiples (como es el caso en los mercados actuales de computadoras de escritorio/laptops), y ha determinado que un núcleo no es suficiente.
El La "cantidad ideal de hilos" depende de su problema particular y de cuánto paralelismo puede aprovechar.Si tiene un problema que es "vergonzosamente paralelo" en el sentido de que puede subdividirse en problemas independientes con poca o ninguna comunicación entre ellos, y tiene suficientes núcleos que realmente puede obtener el paralelismo verdadero, entonces, ¿cuántos subprocesos usar depende de cosas como el tamaño del problema, el tamaño de la línea de caché, el cambio de contexto y la sobrecarga de desove, y varias otras cosas que son realmente difíciles de calcular de antemano. Para tales situaciones, realmente tiene que hacer algunos perfiles para elegir una fragmentación/partición óptima de su problema en los hilos. Sin embargo, normalmente no tiene sentido usar más hilos que núcleos. También es cierto que si tiene mucha sincronización, entonces, de hecho, puede tener una penalización de rendimiento por usar subprocesos. Depende en gran medida del problema particular y de cuán interdependientes son los diversos pasos. Como principio rector, debe tener en cuenta que los hilos de desove y la sincronización de subprocesos son operaciones costosas, pero realizar cálculos en paralelo puede aumentar el rendimiento si la comunicación y otras formas de sincronización son mínimas. También debe tener en cuenta que el enhebrado puede conducir a un rendimiento de caché muy pobre si sus hilos terminan invalidando una línea de caché mutuamente compartida.
Herb Sutter escribió an article para el Dr. Dobb's Journal en el que habla de los tres pilares de la simultaneidad. Este artículo hace un muy buen trabajo al desglosar qué problemas son buenos candidatos para ser resueltos mediante construcciones de subprocesos.
Habrá más respuestas en profundidad que la mía, pero con respecto a la IU, tener múltiples hilos puede dar al usuario la apariencia de un mayor tiempo de respuesta en circunstancias adecuadas, aunque el rendimiento puede ser menor; por ejemplo, cargar pestañas en una web navegador, 1 hilo por pestaña Es caso por caso, por supuesto. – Phil