java - móviles - manual de programacion android pdf
Hilos verdes versus hilos no verdes (7)
El artículo de Wikipedia Green Threads lo explica muy bien.
Los hilos verdes son "hilos de nivel de usuario". Están programados por un proceso de nivel de usuario "ordinario", no por el kernel. Por lo tanto, se pueden usar para simular multihebras en plataformas que no proporcionan esa capacidad.
En el contexto de Java específicamente, los hilos verdes son una cosa del pasado. Vea este artículo . (Se trata de Solaris, pero el hecho de que los hilos verdes ya no se usen es válido para las plataformas habituales).
Los hilos verdes fueron abandonados en Sun JVM para Linux a partir del lanzamiento de la versión 1.3 (ver Tecnología Java [tm] en la Plataforma Linux en archive.org). Eso data de 2000. Para Solaris, los subprocesos nativos estaban disponibles desde JDK 1.2. Eso data de 1998. Ni siquiera creo que haya habido una implementación de hilos verdes para Windows, pero no puedo encontrar una referencia para eso.
Hay algunas excepciones, como se señala en el artículo de Wikipedia, me reúno principalmente para dispositivos de baja potencia (integrados).
Me gustaría entender las ventajas que ofrece este tipo de subprocesos.
¿En qué entorno Green Threads es mejor que Non Green? Algunos dicen que los hilos verdes son mejores para el procesador multi core.
Cualquier problema de comportamiento esperado.
La memoria del hilo verde se asigna desde el montón en lugar de tener una pila creada por el sistema operativo. Esto puede potencialmente dar un orden de magnitud o más aumento en los hilos concurrentes. Como han mencionado otras personas, esto no tomaría ventaja de múltiples procesadores automáticamente, sin embargo, el caso de uso es típicamente para bloquear E / S, por ejemplo, los hilos verdes podrían permitirle manejar 100k conexiones simultáneas en lugar de 10k.
Entonces, en otras palabras, los hilos verdes son mejores para las operaciones IO vinculadas a cierta escala.
Los hilos verdes no están programados por el sistema operativo.
Eso significa que la programación para ellos ocurre en el espacio de usuario y no es manejada por el kernel. Esto significa que normalmente no se puede hacer que los hilos verdes usen todos los núcleos de la CPU.
Para cualquier plataforma convencional que ejecute Java actualmente (por ejemplo, x86 o x64), utilizará hilos de verdad.
Los subprocesos verdes son significativamente más rápidos que los subprocesos nativos cuando tienen más hilos activos que los procesadores.
Inicialmente, Java tenía soporte para hilos verdes, pero a diferencia de la mayoría de las implementaciones modernas de enhebrado verde, no podía escalar sobre múltiples procesadores, lo que hacía que Java no pudiera utilizar múltiples núcleos.
Luego Java eliminó el enhebrado verde para poder confiar únicamente en los hilos nativos. Eso hizo que Java Threads fuera más lento que los hilos verdes.
Tenga en cuenta que no estoy hablando específicamente de la implementación de Java de hilos verdes que tuvo inconvenientes, ya que a diferencia de otras implicaciones de subprocesos verdes no se podía escalar en un sistema multinúcleo o multiprocesador.
Los subprocesos verdes son subprocesos de nivel de usuario en lugar de subprocesos de nivel de kernel. Están programados por bibliotecas de usuarios en lugar de kernel. Puede tener su propio mecanismo de programación para programar los hilos en lugar de depender del programador del sistema operativo.
Los subprocesos verdes emulan entornos multiproceso sin depender de ninguna capacidad de sistema operativo nativo, y se administran en espacio de usuario en lugar de en espacio de kernel, lo que les permite trabajar en entornos que no tienen soporte nativo de subprocesos
Performace:
En un procesador multi-core, las implementaciones de subprocesos nativos pueden asignar automáticamente trabajo a múltiples procesadores, mientras que las implementaciones de subprocesos verdes normalmente no pueden. Los subprocesos verdes superan significativamente a los subprocesos nativos de Linux en la activación y sincronización de subprocesos.
Cuando un hilo verde ejecuta una llamada al sistema de bloqueo, no solo ese hilo está bloqueado, sino que todos los hilos dentro del proceso están bloqueados.
Los subprocesos verdes son subprocesos implementados en el nivel de aplicación en lugar de en el sistema operativo. Esto generalmente se hace cuando el sistema operativo no proporciona una API de subprocesos, o no funciona de la manera que necesita.
Por lo tanto, la ventaja es que obtienes la funcionalidad de subprocesos. La desventaja es que los hilos verdes no pueden usar múltiples núcleos.
Hubo algunas primeras JVM que usaron hilos verdes (el IIRC, el puerto Blackdown JVM para Linux), pero hoy en día todas las JVM convencionales usan hilos reales. Puede haber algunas JVM incorporadas que todavía usan hilos verdes.
JAVA Multi-Threading se implementa mediante dos modelos:
- Modelo de hilo verde
- Modelo de sistema operativo nativo
Modelo de subproceso verde: el subproceso que es administrado por JVM, sin tener soporte de sistema operativo subyacente se llama subproceso verde. Muy pocos sistemas operativos como Sun Solaris brindan soporte para el modelo de hilo verde. Está en desuso y no se recomienda su uso.
Modelo de sistema operativo nativo: El subproceso administrado por la JVM con la ayuda del sistema operativo subyacente se denomina modelo de sistema operativo nativo. Todos los sistemas operativos de Windows brindan soporte para el modelo de sistema operativo nativo.