Opinión Alan Cox sobre threads

Mi opinión es muy próxima a la suya, pero él es Alan Cox, yo soy... nadie en comparación


A Computer is a state machine. Threads are for people who can't program state machines.
Alan Cox

Y no es el único gurú que tiene opiniones parecidas...


If you think you need threads then your processes are too fat 
Rob Pike



Esto no significa que se esté en contra del proceso simultáneo. En absoluto.

Ni siquiera del proceso simultáneo apropiativo.

Y obviamente no del proceso simultáneo distribuido.


¡¡¡AUPA   EEEEERRRRLAAAAAANNNNNNGGGG!!!


Paralelismo sí, pero en condiciones


¿Porqué podemos querer ejecución paralela?


¿Para que las cosas vayan más rápido?
Rara vez. Y en esos casos, estas limitado al número de procesadores reales.

¿Para hacer la lógica del programa más sencilla?
Entonces Alan Cox tiene razón.

¿Por seguridad?
Entonces las hebras es lo peor, porque te aumenta la inseguridad.


Si lo queremos para escalar horizontalmente (distribuyendo), para simplificar la lógica del programa (en algunos casos de forma radical), o por seguridad, lo mejor son procesos.


Una buena opción es separarlos con un middleware, más que una opción, es una obligación.


Pero podemos combinar esto, con un sistema orientado a procesos de forma que maximicemos al máximo los beneficios de ejecutar en paralelo, CON PROCESOS.

¡¡¡AUPA   EEEEERRRRLAAAAAANNNNNNGGGG!!!

¿Para qué no queremos threads?

O dicho de otra forma, dónde los threads aportan poco.

Para que el usuario no se quede esperando mientras ha pedido algo.

¿Funcionará más rápido?  NO
¿Funcionará más seguro? NO
¿Tendrá una lógica más sencilla? NO

¿entonces, "paqué"?



Yo era uno de esos ingenuos que pensaba que las hebras eran una chulada, la solución a los males del mundo. Y los semáforos, regiones críticas y mutex, nuestra gran ayuda. Eso sí, muy lejos del alto nivel del "rendezvous" de ADA.

Pero la vida real me puso en su sitio. Todos esos mecanismos para evitar problemas con la concurrencia y memoria compartida, destruían la concurrencia al mismo tiempo que complican enormemente el código haciéndolo inmantenible e intocable.

Los errores de la concurrencia apropiativa con memoria compartida, son difíciles de encontrar y pueden pasar en cualquier momento.

En este sentido, estoy compartiendo la opinión de Joe Amstrong y Martin Ordesky (citada en sus respectivos libros de sus respectivos lenguajes de programación)