Aunque los hilos parecen ser un pequeño paso de la computación secuencial, de hecho, representan un gran paso. Descartan las propiedades más esenciales y atractivas de la computación secuencial: comprensibilidad, previsibilidad y determinismo. Los subprocesos, como modelo de cálculo, son tremendamente no deterministas, y el trabajo del programador se convierte en el de podar ese no determinismo.
- El problema con hilos (www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf).
Si bien hay algunas ventajas de rendimiento que se pueden obtener al usar hilos en los que puede distribuir el trabajo en múltiples núcleos, a menudo tienen un excelente precio.
Una de las desventajas del uso de subprocesos no mencionados aún aquí es la pérdida de compartimentación de recursos que se obtiene con espacios de proceso de subproceso único. Por ejemplo, supongamos que se encuentra con el caso de una segfault. Es posible, en algunos casos, recuperarse de esto en una aplicación multiproceso, ya que simplemente deja morir al niño con fallas y reaparece uno nuevo. Este es el caso en el backend prefork de Apache. Cuando una instancia de httpd se arruina, el peor de los casos es que la solicitud HTTP en particular puede descartarse para ese proceso, pero Apache genera un nuevo hijo y, a menudo, la solicitud solo se reenvía y se atiende. El resultado final es que Apache en su conjunto no se elimina con el hilo defectuoso.
Otra consideración en este escenario son las pérdidas de memoria. Hay algunos casos en los que puede manejar con gracia un bloqueo de subproceso (en UNIX, es posible recuperarse de algunas señales específicas, incluso segfault / fpviolation), pero incluso en ese caso, puede haber perdido toda la memoria asignada por ese subproceso (malloc, nuevo, etc.). Por lo tanto, aunque el proceso puede continuar, pierde cada vez más memoria con el tiempo con cada falla / recuperación. Una vez más, hay algunas formas de minimizar esto, como el uso de agrupaciones de memoria de Apache. Pero esto todavía no protege contra la memoria que podría haber sido asignada por librerías de terceros que el hilo podría haber estado usando.
Y, como han señalado algunas personas, comprender las primitivas de sincronización es quizás lo más difícil de entender. Este problema en sí mismo, solo obtener la lógica general correcta para todo su código, puede ser un gran dolor de cabeza. Los puntos muertos misteriosos son propensos a suceder en los momentos más extraños, y a veces ni siquiera hasta que su programa se haya ejecutado en producción, lo que hace que la depuración sea aún más difícil. Agregue a esto el hecho de que las primitivas de sincronización a menudo varían ampliamente con la plataforma (Windows vs. POSIX), y la depuración a menudo puede ser más difícil, así como la posibilidad de condiciones de carrera en cualquier momento (inicio / inicialización, tiempo de ejecución y apagado), La programación con hilos realmente tiene poca piedad para los principiantes. E incluso para expertos, Todavía hay poca misericordia solo porque el conocimiento del enhebrado en sí no minimiza la complejidad en general. Cada línea de código enhebrado a veces parece agravar exponencialmente la complejidad general del programa y también aumenta la probabilidad de que surja un punto muerto oculto o una extraña condición de carrera en cualquier momento. También puede ser muy difícil escribir casos de prueba para descubrir estas cosas.
Es por eso que algunos proyectos como Apache y PostgreSQL están en su mayor parte basados en procesos. PostgreSQL ejecuta cada subproceso de fondo en un proceso separado. Por supuesto, esto todavía no alivia el problema de la sincronización y las condiciones de carrera, pero agrega bastante protección y de alguna manera simplifica las cosas.
Múltiples procesos que ejecutan cada uno un solo subproceso de ejecución pueden ser mucho mejores que múltiples subprocesos que se ejecutan en un solo proceso. Y con la llegada de gran parte del nuevo código de igual a igual como AMQP (RabbitMQ, Qpid, etc.) y ZeroMQ, es mucho más fácil dividir subprocesos en diferentes espacios de proceso e incluso máquinas y redes, lo que simplifica enormemente las cosas. Pero aún así, no es una bala de plata. Todavía hay complejidad con la que lidiar. Simplemente mueve algunas de sus variables del espacio de procesos a la red.
La conclusión es que la decisión de ingresar al dominio de hilos no es ligera. Una vez que pisas ese territorio, casi instantáneamente todo se vuelve más complejo y nuevas razas de problemas entran en tu vida. Puede ser divertido y genial, pero es como la energía nuclear: cuando las cosas van mal, pueden ir mal y rápido. Recuerdo haber tomado una clase de entrenamiento en criticidad hace muchos años y mostraron fotos de algunos científicos en Los Alamos que jugaban con plutonio en los laboratorios de la Segunda Guerra Mundial. Muchos tomaron pocas o ninguna precaución contra el evento de una exposición, y en un abrir y cerrar de ojos, en un solo destello brillante e indoloro, todo habría terminado para ellos. Días después estaban muertos. Richard Feynman más tarde se refirió a esto como " cosquillas en la cola del dragón"."Así es como puede ser jugar con hilos (al menos para mí de todos modos). Parece bastante inocuo al principio, y cuando te muerden, te rascas la cabeza por la rapidez con la que las cosas se pusieron mal. Pero al menos los hilos ganaron No te mato.