¿Cuál es la diferencia entre un hilo y una fibra? He oído hablar de fibras de rubí y he leído que están disponibles en otros idiomas, ¿podría alguien explicarme en términos simples cuál es la diferencia entre un hilo y una fibra?
¿Cuál es la diferencia entre un hilo y una fibra? He oído hablar de fibras de rubí y he leído que están disponibles en otros idiomas, ¿podría alguien explicarme en términos simples cuál es la diferencia entre un hilo y una fibra?
Respuestas:
En los términos más simples, los hilos generalmente se consideran preventivos (aunque esto no siempre es cierto, dependiendo del sistema operativo), mientras que las fibras se consideran hilos ligeros y cooperativos. Ambas son rutas de ejecución separadas para su aplicación.
Con subprocesos: la ruta de ejecución actual puede interrumpirse o adelantarse en cualquier momento (nota: esta declaración es una generalización y puede no ser cierta según el sistema operativo / paquete de subprocesos / etc.). Esto significa que para los subprocesos, la integridad de los datos es un gran problema porque un subproceso puede detenerse en medio de la actualización de un fragmento de datos, dejando la integridad de los datos en un estado incorrecto o incompleto. Esto también significa que el sistema operativo puede aprovechar múltiples CPU y núcleos de CPU al ejecutar más de un hilo al mismo tiempo y dejar que el desarrollador se encargue del acceso a los datos.
Con fibras: la ruta de ejecución actual solo se interrumpe cuando la fibra produce ejecución (la misma nota que la anterior). Esto significa que las fibras siempre comienzan y se detienen en lugares bien definidos, por lo que la integridad de los datos es un problema mucho menor. Además, debido a que las fibras a menudo se administran en el espacio del usuario, no es necesario realizar costosos cambios de contexto y cambios de estado de la CPU, lo que hace que el cambio de una fibra a la siguiente sea extremadamente eficiente. Por otro lado, dado que no pueden ejecutarse dos fibras exactamente al mismo tiempo, el solo uso de fibras no aprovechará múltiples CPU o múltiples núcleos de CPU.
Los hilos usan programación preventiva , mientras que las fibras usan programación cooperativa .
Con un subproceso, el flujo de control podría interrumpirse en cualquier momento y otro subproceso puede asumir el control. Con varios procesadores, puede tener varios subprocesos ejecutándose todos al mismo tiempo (subprocesamiento múltiple simultáneo o SMT). Como resultado, debe tener mucho cuidado con el acceso simultáneo a los datos y proteger sus datos con mutexes, semáforos, variables de condición, etc. A menudo es muy difícil hacerlo bien.
Con una fibra, el control solo cambia cuando se lo indica, generalmente con una llamada de función llamada algo así yield(). Esto facilita el acceso simultáneo a los datos, ya que no tiene que preocuparse por la atomicidad de las estructuras de datos o mutexes. Siempre y cuando no ceda, no hay peligro de ser reemplazado y tener otra fibra tratando de leer o modificar los datos con los que está trabajando. Como resultado, sin embargo, si su fibra entra en un bucle infinito, no se puede ejecutar ninguna otra fibra, ya que no está cediendo.
También puede mezclar hilos y fibras, lo que da lugar a los problemas que enfrentan ambos. No se recomienda, pero a veces puede ser lo correcto si se hace con cuidado.
En Win32, una fibra es una especie de subproceso administrado por el usuario. Una fibra tiene su propia pila y su propio puntero de instrucciones, etc., pero las fibras no están programadas por el sistema operativo: debe llamar explícitamente a SwitchToFiber. Los hilos, por el contrario, son programados de manera preventiva por el sistema operativo. En términos generales, una fibra es un subproceso que se administra a nivel de aplicación / tiempo de ejecución en lugar de ser un verdadero subproceso del sistema operativo.
Las consecuencias son que las fibras son más baratas y que la aplicación tiene más control sobre la programación. Esto puede ser importante si la aplicación crea muchas tareas concurrentes y / o quiere optimizar de cerca cuando se ejecutan. Por ejemplo, un servidor de base de datos podría optar por utilizar fibras en lugar de hilos.
(Puede haber otros usos para el mismo término; como se señaló, esta es la definición de Win32).
Primero, recomendaría leer esta explicación de la diferencia entre procesos y subprocesos como material de fondo.
Una vez que hayas leído eso, es bastante sencillo. Los subprocesos se pueden implementar en el núcleo, en el espacio del usuario, o los dos se pueden mezclar. Las fibras son básicamente hilos implementados en el espacio del usuario.
En la sección 11.4 "Procesos y subprocesos en Windows Vista" en sistemas operativos modernos, Tanenbaum comenta:
Aunque las fibras se programan de manera cooperativa, si hay múltiples hilos que programan las fibras, se requiere una sincronización cuidadosa para asegurarse de que las fibras no interfieran entre sí. Para simplificar la interacción entre hilos y fibras, a menudo es útil crear solo tantos hilos como procesadores para ejecutarlos, y afinar los hilos a cada ejecución solo en un conjunto distinto de procesadores disponibles, o incluso en un solo procesador. Cada hilo puede ejecutar un subconjunto particular de fibras, estableciendo una relación uno a muchos entre hilos y fibras que simplifica la sincronización. Aun así, todavía hay muchas dificultades con las fibras. La mayoría de las bibliotecas Win32 desconocen por completo las fibras, y las aplicaciones que intentan usar fibras como si fueran hilos encontrarán varios fallos. El núcleo no tiene conocimiento de las fibras, y cuando una fibra ingresa al núcleo, el hilo en el que se está ejecutando puede bloquearse y el núcleo programará un hilo arbitrario en el procesador, por lo que no estará disponible para ejecutar otras fibras. Por estas razones, las fibras rara vez se usan, excepto cuando se transfiere código de otros sistemas que necesitan explícitamente la funcionalidad proporcionada por las fibras.
Tenga en cuenta que, además de hilos y fibras, Windows 7 presenta la programación en modo de usuario :
La programación en modo de usuario (UMS) es un mecanismo ligero que las aplicaciones pueden usar para programar sus propios subprocesos. Una aplicación puede cambiar entre subprocesos UMS en modo de usuario sin involucrar al programador del sistema y recuperar el control del procesador si un subproceso UMS se bloquea en el núcleo. Los subprocesos UMS difieren de las fibras en que cada subproceso UMS tiene su propio contexto de subproceso en lugar de compartir el contexto del subproceso de un solo subproceso. La capacidad de cambiar entre hilos en modo de usuario hace que UMS sea más eficiente que los grupos de hilos para administrar grandes cantidades de elementos de trabajo de corta duración que requieren pocas llamadas al sistema.
Para obtener más información sobre hilos, fibras y UMS, consulte Dave Probert: Inside Windows 7 - User Mode Scheduler (UMS) .
Los subprocesos son programados por el sistema operativo (preventivo). El sistema operativo puede detener o reanudar un subproceso en cualquier momento, pero las fibras se manejan más o menos por sí mismas (cooperativas) y ceden entre sí. Es decir, el programador controla cuándo las fibras realizan su procesamiento y cuándo ese procesamiento cambia a otra fibra.
Los subprocesos generalmente dependen del núcleo para interrumpir el subproceso para que este u otro subproceso pueda ejecutarse (lo que se conoce mejor como multitarea preventiva), mientras que las fibras usan multitarea cooperativa donde es la fibra misma la que abandona su tiempo de ejecución para que otras fibras pueden correr.
Algunos enlaces útiles que lo explican mejor de lo que probablemente hice son:
Los hilos fueron creados originalmente como procesos ligeros. De manera similar, las fibras son un hilo liviano, que se basa (de manera simplista) en las fibras para programarse entre sí, al ceder el control.
Supongo que el siguiente paso serán los hilos donde tendrás que enviarles una señal cada vez que quieras que ejecuten una instrucción (no muy diferente de mi hijo de 5 años :-). En los viejos tiempos (e incluso ahora en algunas plataformas integradas), todos los subprocesos eran fibras, no había preferencia y tenía que escribir sus subprocesos para comportarse bien.
La definición de fibra Win32 es, de hecho, la definición de "hilo verde" establecida en Sun Microsystems. No hay necesidad de desperdiciar el término fibra en el hilo de algún tipo, es decir, un hilo que se ejecuta en el espacio de usuario bajo el código de usuario / control de biblioteca de hilos.
Para aclarar el argumento, mire los siguientes comentarios:
Debemos suponer que los procesos están hechos de hilos y que los hilos deben estar hechos de fibras. Con esa lógica en mente, usar fibras para otro tipo de hilos está mal.