jueves, 21 de mayo de 2009

Diseñando un ThreadPool

Sin lugar a dudas, la base de todo Framework Multihilo pasa por tener un ThreadPool robusto y rápido, sobre todo rápido. Debe ser capaz de "tragarse" tareas como si estuviera endemoniado :-D

Si ya de por sí diseñar código Thread Safe de forma eficiente es jodido de cojones, lo puede ser más el efecto conocido como thread starvation.
Esta situación se provoca debido a que varios hilos solicitan de forma simultánea una tarea de la cola, generando sobrecarga en la sincronización y disminuyendo el rendimiento de forma notable. El mismo código que te funciona de puta madre en un equipo con DualCore puede ir de pena en un QuadCore o superior.

Otro asunto es el balanceo de carga entre hilos. No puede ser que haya algunos hilos con mucha carga de trabajo en espera mientras otros se rascan la barriga. Así se pueden ir sumando problemas que indican la complejidad que puede entrañar el diseño de un buen ThreadPool.

Para aliviar algunos de los problemas citados, se pueden emplear técnicas como el Work-Stealing Queue. Este patrón es una cola que permite encolar tareas de forma privada (sin bloqueos desde un mismo hilo) y robar tareas desde otros hilos (con alguna penalización en la sincronización).

Un detalle de implementación de un maestro del threading : Joe Duffy

Por cierto, en la nueva versión del CLR (la 4.0) de .NET se está rediseñando el ThreadPool para que sea más eficiente y se pueda enredar con él para variar su comportamiento interno.