De todos modos, cuando tienes demasiados threads lo que tienes es un problema, que a veces te has podido buscar tú mismo;)
Sin duda. Por mi experiencia, no es buena idea tener más de 16 threads en estado "ready to run" por procesador, e incluso así, es conveniente ayudar al planificador del SO. Los threads de "trabajo" han de estar en proporción a la capacidad/dimensión del sistema.
Por cierto que todo lo que hablas me suena al Parallel Programming Patterns del que hablaba en la entrada anterior...;) (Quitando el tema de los timeslices o quanta)
Rayos, me alegro. Cuando me topaba con esos problemas había mucha menos documentación que ahora. La referencia para solucionar los problemas las tomaba del diseño de CPUs superescalares con ejecución fuera de orden y de modelos de planificación de la producción. Los libros de patrones de diseño me parecen bien para tener una base para afrontar/comprender/identificar los problemas, aún a riesgo de que algún compañero te "acuse" de ignorante por no conocer tal o cual patrón ("uaaaala tú que sabes tanto no conoces el patrón X"):-)
Re:Vaya
(Puntos:2)( http://www.voluntariado.net/ | Última bitácora: Domingo, 10 Junio de 2012, 21:48h )
Sin duda. Por mi experiencia, no es buena idea tener más de 16 threads en estado "ready to run" por procesador, e incluso así, es conveniente ayudar al planificador del SO. Los threads de "trabajo" han de estar en proporción a la capacidad/dimensión del sistema.
Rayos, me alegro. Cuando me topaba con esos problemas había mucha menos documentación que ahora. La referencia para solucionar los problemas las tomaba del diseño de CPUs superescalares con ejecución fuera de orden y de modelos de planificación de la producción. Los libros de patrones de diseño me parecen bien para tener una base para afrontar/comprender/identificar los problemas, aún a riesgo de que algún compañero te "acuse" de ignorante por no conocer tal o cual patrón ("uaaaala tú que sabes tanto no conoces el patrón X")