uso threads thread sistemas relación programa proceso operativos multihilos multi mapa los hilos hebras entre diferencia definicion cuál comparativo multithreading process operating-system theory

multithreading - threads - multi thread definicion



¿Diferencia entre hilos de nivel de usuario y kernel? (4)

He estado buscando algunas notas basadas en este tema, y ​​aunque tengo una comprensión de los hilos en general, no estoy realmente seguro de las diferencias entre el nivel de usuario y los hilos del núcleo .

Sé que los procesos se componen básicamente de múltiples hilos o un solo hilo, pero ¿son estos hilos de los dos tipos mencionados anteriormente?

Por lo que entiendo, los hilos soportados por kernel tienen acceso al kernel para llamadas al sistema y otros usos no disponibles para hilos de nivel de usuario.

Entonces, ¿son los subprocesos de nivel de usuario simplemente subprocesos creados por el programador cuando luego utilizan subprocesos soportados por núcleo para realizar operaciones que normalmente no podrían realizarse debido a su estado?


Algunos entornos o lenguajes de desarrollo agregarán hilos propios como la característica, que se escribe para aprovechar algún conocimiento del entorno, por ejemplo, un entorno de GUI podría implementar alguna funcionalidad de subprocesos que cambie entre subprocesos de usuario en cada ciclo de evento. Una biblioteca de juegos podría tener un comportamiento similar a un hilo para los personajes. En algún momento el comportamiento de subprocesos del usuario se puede implementar de una manera diferente, por ejemplo, trabajo mucho con cocoa y tiene un mecanismo de temporizador que ejecuta tu código cada x número de segundos, usa fracciones de segundo y lo hace como un hilo. Ruby tiene una característica de rendimiento que es como hilos cooperativos. La ventaja de los hilos de usuario es que pueden cambiar a tiempos más predecibles. Con el hilo del kernel cada vez que un hilo se inicia nuevamente, necesita cargar cualquier dato en el que esté trabajando, esto puede llevar tiempo, con hilos de usuario que puede cambiar cuando haya terminado de trabajar en algunos datos, por lo que no es necesario recargado. No he encontrado hilos de usuario que tengan el mismo aspecto que los hilos del núcleo, solo mecanismos como el temporizador, aunque he leído sobre ellos en libros de texto antiguos, así que me pregunto si eran algo que era más popular en el pasado pero con el auge de los verdaderos sistemas operativos multiproceso (Windows moderno y Mac OS X) y hardware más potente me pregunto si han perdido vigencia.


Antes de entrar en comparación, primero comprendamos qué es un hilo. Los hilos son procesos livianos dentro del dominio de procesos independientes. Se requieren porque los procesos son pesados, consumen muchos recursos y, lo que es más importante,

dos procesos separados no pueden compartir un espacio de memoria.

Digamos que abre un editor de texto. Es un proceso independiente que se ejecuta en la memoria con una ubicación direccionable por separado. Necesitará muchos recursos dentro de este proceso, como insertar gráficos, correcciones ortográficas, etc. No es factible crear procesos separados para cada una de estas funcionalidades y mantenerlas de forma independiente en la memoria. Para evitar esto,

Se pueden crear múltiples subprocesos dentro de un proceso único, que puede compartir un espacio de memoria común, que existe independientemente dentro de un proceso.

Ahora, volviendo a sus preguntas, de a una por vez.

No estoy muy seguro de las diferencias entre los niveles de nivel de usuario y de núcleo.

Los hilos se clasifican ampliamente como subprocesos de nivel de usuario y subprocesos de nivel de kernel en función de su dominio de ejecución. También hay casos en que uno o varios hilos de usuarios se correlacionan con uno o varios hilos del kernel .

- Subprocesos de nivel de usuario

Los subprocesos de nivel de usuario se encuentran principalmente en el nivel de aplicación donde una aplicación crea estos subprocesos para mantener su ejecución en la memoria principal. A menos que sea necesario, estos subprocesos funcionan de forma aislada con los hilos del kernel.

Estos son más fáciles de crear ya que no tienen que referir muchos registros y el cambio de contexto es mucho más rápido que un hilo de nivel de kernel.

El subproceso de nivel de usuario, en su mayoría puede causar cambios en el nivel de aplicación y el subproceso de nivel de núcleo continúa ejecutándose a su propio ritmo.

- Hilos de nivel de kernel

Estos hilos son en su mayoría independientes de los procesos en curso y son ejecutados por el sistema operativo.

El sistema operativo requiere estos subprocesos para tareas como gestión de memoria, gestión de procesos, etc.

Como estos subprocesos mantienen, ejecutan e informan los procesos requeridos por el sistema operativo; Los subprocesos de nivel kernel son más costosos de crear y administrar, y el cambio de contexto de estos subprocesos es lento.

La mayoría de los subprocesos de nivel de núcleo no pueden ser sustituidos por los subprocesos de nivel de usuario.

MS DOS written for Intel 8088 didn''t have dual mode of operation. Thus, a user level process had the ability to corrupt the entire operating system.

- Subprocesos de nivel de usuario mapeados sobre Kernel Threads

Esta es quizás la parte más interesante. Muchos subprocesos de nivel de usuario se asignan a la secuencia de nivel del kernel, que a su vez se comunican con el kernel.

Algunas de las asignaciones prominentes son:

Doce y cincuenta y nueve de la noche

Cuando un subproceso de nivel de usuario se asigna a un solo hilo del kernel.

ventajas: cada hilo de usuario se correlaciona con un hilo del núcleo. Incluso si uno de los hilos del usuario emite una llamada al sistema de bloqueo, los demás procesos no se verán afectados.

desventajas: cada subproceso de usuario requiere un subproceso de kernel para interactuar y los subprocesos de kernel son caros de crear y administrar.

Muchos a uno

Cuando muchos subprocesos de usuario se asignan a un subproceso kernel.

ventajas: no se requieren múltiples hilos del kernel, ya que hilos de usuario similares se pueden mapear a un hilo del kernel.

desventaja: incluso si uno de los hilos del usuario emite una llamada al sistema de bloqueo, todos los otros hilos de usuario mapeados a ese hilo del núcleo están bloqueados.

Además, no se puede lograr un buen nivel de concurrencia ya que el kernel procesará solo un hilo del núcleo a la vez.

Muchos a muchos

Cuando muchos subprocesos de usuario se correlacionan con un número igual o menor de subprocesos de kernel. El programador decide cuántos subprocesos del usuario asignarán a cuántos subprocesos del kernel. Algunos de los subprocesos del usuario pueden correlacionarse con solo un hilo del kernel.

ventajas: se logra un gran nivel de concurrencia. El programador puede decidir algunos subprocesos potencialmente peligrosos que pueden emitir una llamada al sistema de bloqueo y colocarlos con el mapeo de uno a uno.

desventaja: la cantidad de hilos del kernel, si no se decide con cautela, puede ralentizar el sistema.

La otra parte de tu pregunta:

Los subprocesos compatibles con kernel tienen acceso al núcleo para llamadas al sistema y otros usos no disponibles para subprocesos de nivel de usuario.

Entonces, ¿son los subprocesos de nivel de usuario simplemente subprocesos creados por el programador cuando luego utilizan subprocesos soportados por núcleo para realizar operaciones que normalmente no podrían realizarse debido a su estado?

Parcialmente correcto. Casi todos los hilos del kernel tienen acceso a las llamadas al sistema y otras interrupciones críticas ya que los hilos del kernel son responsables de ejecutar los procesos del sistema operativo. El hilo del usuario no tendrá acceso a algunas de estas características críticas. por ejemplo, un editor de texto nunca puede disparar un hilo que tenga la capacidad de cambiar la dirección física del proceso. Pero si es necesario, un hilo de usuario puede mapear el hilo del kernel y emitir algunas de las llamadas al sistema que no podría hacer como una entidad independiente. El hilo del núcleo correlacionaría esta llamada al kernel y ejecutaría acciones, si lo consideraba conveniente.


Subprocesos de usuario: 1. La biblioteca proporciona soporte para la creación, programación y administración de subprocesos sin soporte del kernel. 2. El kernel que desconoce la creación y programación de subprocesos a nivel de usuario se realiza en el espacio de usuario sin la intervención del kernel. 3. El subproceso de nivel de usuario generalmente es rápido de crear y administrar, pero tienen inconvenientes. 4. Si el kernel es de subproceso único, cualquier subproceso de nivel de usuario que realice una llamada al sistema de bloqueo hará que todo el proceso se bloquee, incluso si hay otros subprocesos disponibles para ejecutarse dentro de la aplicación. 5. Las bibliotecas de subprocesos de usuario incluyen POSIX Pthreads, Mach C-threads y Solaris 2 UI-threads.

Hilos del Kernel: 1. El kernel realiza la creación, programación y administración del hilo en el espacio del kernel. 2. Los hilos del kernel generalmente son más lentos de crear y administrar que los hilos del usuario. 3. el núcleo está administrando los hilos, si un hilo realiza una llamada al sistema de bloqueo. 4. Un entorno multiprocesador, el kernel puede programar hilos en diferentes procesadores. 5.incluyendo los hilos del kernel de soporte de Windows NT, Windows 2000, Solaris 2, BeOS y Tru64 UNIX (formerly Digital UN1X).


Editar: La pregunta fue un poco confusa, así que la estoy respondiendo de dos maneras diferentes.

Subprocesos de nivel de sistema operativo contra subprocesos verdes

Para mayor claridad, generalmente digo "subprocesos de nivel de sistema operativo" o "subprocesos nativos" en lugar de "subprocesos de núcleo" (que confundí con "subprocesos de núcleo" en mi respuesta original a continuación). Los subprocesos de nivel de sistema operativo son creados y gestionados por el sistema operativo. La mayoría de los idiomas tienen soporte para ellos. (C, Java reciente, etc.) Son extremadamente difíciles de usar porque usted es 100% responsable de prevenir problemas. En algunos idiomas, incluso las estructuras de datos nativas (como Hashes o Dictionaries) se romperán sin código de bloqueo adicional.

Lo contrario de un subproceso del sistema operativo es un hilo verde administrado por su idioma. Estos hilos reciben varios nombres según el idioma (corutinas en C, goroutinas en Go, fibras en Ruby, etc.). Estos hilos solo existen dentro de su lenguaje y no en su sistema operativo. Debido a que el lenguaje elige los cambios de contexto (es decir, al final de un enunciado), previene TONELADAS de condiciones de carrera sutiles (como ver una estructura parcialmente copiada, o la necesidad de bloquear la mayoría de las estructuras de datos). El programador ve llamadas de "bloqueo" (es decir, data = file.read() ), pero el lenguaje lo traduce en llamadas asincrónicas al sistema operativo. El lenguaje luego permite que otros hilos verdes se ejecuten mientras se espera el resultado.

Los hilos verdes son mucho más simples para el programador, pero su rendimiento varía: si tiene MUCHOS hilos, los hilos verdes pueden ser mejores para la CPU y la RAM. Por otro lado, la mayoría de los lenguajes de subprocesos verdes no pueden aprovechar múltiples núcleos. (¡Ya no puedes comprar una computadora o un teléfono de un solo núcleo!). Y una mala biblioteca puede detener todo el lenguaje haciendo una llamada al sistema operativo de bloqueo.

Lo mejor de ambos mundos es tener un hilo del sistema operativo por CPU, y muchos hilos verdes que mágicamente se mueven alrededor de los hilos del sistema operativo. Idiomas como Go y Erlang pueden hacer esto.

Llamadas de sistema y otros usos no disponibles para subprocesos de nivel de usuario

Esto es solo verdad a medias. Sí, puede causar problemas fácilmente si llama al sistema operativo usted mismo (es decir, hace algo que bloquea). Pero el lenguaje generalmente tiene reemplazos, por lo que ni siquiera se da cuenta. Estos reemplazos llaman kernel, solo ligeramente diferente de lo que piensas.

Subprocesos de kernel vs subprocesos de usuario

Editar: Esta es mi respuesta original, pero se trata de hilos de espacio de usuario frente a hilos de núcleo solamente, que (en retrospectiva) probablemente no era la pregunta.

Los hilos de usuario y los hilos del Kernel son exactamente iguales. (Puede ver buscando en / proc / y ver que los hilos del núcleo también están allí).

Un hilo de usuario es aquel que ejecuta código de espacio de usuario. Pero puede llamar al espacio del kernel en cualquier momento. Todavía se considera un hilo de "Usuario", a pesar de que está ejecutando el código del kernel en niveles de seguridad elevados.

Un hilo Kernel es uno que solo ejecuta código kernel y no está asociado con un proceso de espacio de usuario. Estos son como "demonios de UNIX", excepto que son demonios solo de kernel. Entonces, podrías decir que el kernel es un programa de subprocesos múltiples. Por ejemplo, hay una cadena de kernel para swap. Esto fuerza a todos los problemas de intercambio a ser "serializados" en una sola transmisión.

Si un subproceso de usuario necesita algo, se llamará al kernel, que lo marca como inactivo. Más tarde, el hilo de intercambio encuentra los datos, por lo que marca el hilo del usuario como ejecutable. Más tarde, el "hilo de usuario" regresa del kernel de regreso a la tierra de usuario como si nada hubiera sucedido.

De hecho, todos los hilos comienzan en el espacio del kernel, porque la operación clone () ocurre en el espacio del kernel. (Y hay una gran cantidad de contabilidad de kernel que hacer antes de poder ''regresar'' a un nuevo proceso en el espacio de usuario).