No dudes en compartir nuestro sitio y códigos con tus amigos, danos de tu ayuda para aumentar nuestra comunidad.
Solución:
Editar: La pregunta fue un poco confusa, así que la respondo de dos maneras diferentes.
Subprocesos a nivel de sistema operativo frente a subprocesos verdes
Para mayor claridad, generalmente digo “subprocesos a nivel de sistema operativo” o “subprocesos nativos” en lugar de “subprocesos a nivel de kernel” (que confundí con “subprocesos de kernel” en mi respuesta original a continuación). Los subprocesos de nivel de sistema operativo son creados y administrados por el SO. La mayoría de los idiomas los admiten. (C, Java reciente, etc.) Son extremadamente difíciles de usar porque eres 100% responsable de prevenir problemas. En algunos lenguajes, incluso las estructuras de datos nativas (como Hashes o Diccionarios) se romperán sin código de bloqueo adicional.
Lo opuesto a un subproceso del sistema operativo es un subproceso verde que es administrado por su idioma. Estos hilos reciben varios nombres según el idioma (corrutinas en C, gorutinas en Go, fibras en Ruby, etc.). Estos hilos solo existen dentro de su idioma y no en su sistema operativo. Debido a que el lenguaje elige cambios de contexto (es decir, al final de una declaración), evita TONELADAS de condiciones de carrera sutiles (como ver una estructura parcialmente copiada o necesitar bloquear la mayoría de las estructuras de datos). El programador ve llamadas “bloqueadas” (es decir, data = file.read() ), pero el lenguaje lo traduce en llamadas asíncronas al sistema operativo. Entonces el idioma permite otro hilos verdes para ejecutar mientras espera el resultado.
Los subprocesos verdes son mucho más simples para el programador, pero su rendimiento varía: si tiene MUCHOS subprocesos, los subprocesos verdes pueden ser mejores tanto para la CPU como para la RAM. Por otro lado, la mayoría de los lenguajes de hilos 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 biblioteca incorrecta puede detener todo el idioma al realizar una llamada al sistema operativo de bloqueo.
Lo mejor de ambos mundos es tener un subproceso del sistema operativo por CPU y muchos subprocesos verdes que se mueven mágicamente a los subprocesos del sistema operativo. Idiomas como Go y Erlang pueden hacer esto.
llamadas al sistema y otros usos no disponibles para hilos de nivel de usuario
Esto es solo la mitad true. Sí, puede causar problemas fácilmente si llama al sistema operativo usted mismo (es decir, hace algo que está bloqueando). Pero el lenguaje generalmente tiene reemplazos, por lo que ni siquiera se da cuenta. Estos reemplazos llaman al kernel, solo de manera ligeramente diferente de lo que cree.
Subprocesos del kernel frente a subprocesos de usuario
Editar: esta es mi respuesta original, pero se trata de subprocesos de espacio de usuario frente a subprocesos de solo kernel, que (en retrospectiva) probablemente no era la pregunta.
Los hilos de usuario y los hilos del kernel son exactamente iguales. (Puede ver en / proc / y ver que los subprocesos del kernel 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 a niveles de seguridad elevados.
Un hilo del kernel es aquel que solo ejecuta código del kernel y no está asociado con un proceso de espacio de usuario. Estos son como “demonios de UNIX”, excepto que son demonios de solo kernel. Entonces se podría decir que el kernel es un programa de múltiples subprocesos. Por ejemplo, hay un hilo de kernel para swap. Esto obliga a que todos los problemas de intercambio se “serialicen” en un solo flujo.
Si un hilo de usuario necesita algo, llamará al kernel, que marca ese hilo 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 aún, el “hilo de usuario” regresa del kernel al área de usuario como si nada hubiera pasado.
De hecho, todos los subprocesos comienzan en el espacio del kernel, porque la operación clone () ocurre en el espacio del kernel. (Y hay mucha contabilidad del kernel que hacer antes de que pueda ‘regresar’ a un nuevo proceso en el espacio de usuario).
Antes de pasar a la comparación, primero comprendamos qué es un hilo. Los subprocesos son procesos ligeros dentro del dominio de procesos independientes. Son necesarios 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 separada. Necesitará muchos recursos dentro de este proceso, como insertar gráficos, correcciones ortográficas, etc. No es posible crear procesos separados para cada una de estas funcionalidades y mantenerlos de forma independiente en la memoria. Para evitar esto,
Se pueden crear múltiples subprocesos dentro de un solo proceso, que puede compartir un espacio de memoria común, existiendo independientemente dentro de un proceso.
Ahora, volviendo a sus preguntas, una a la vez.
No estoy muy seguro de las diferencias entre los subprocesos a nivel de usuario y a nivel de kernel.
Los hilos se clasifican en términos generales como hilos de nivel de usuario y subprocesos a nivel de kernel basado en su dominio de ejecución. También hay casos en los que uno o varios subprocesos de usuario se asignan a uno o varios subprocesos del kernel.
– Hilos de nivel de usuario
Los subprocesos a nivel de usuario se encuentran principalmente en el nivel de la 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 subprocesos del kernel.
Estos son más fáciles de crear ya que no tienen que hacer referencia a muchos registros y el cambio de contexto es mucho más rápido que un hilo a nivel de kernel.
El hilo de nivel de usuario, en su mayoría, puede causar cambios a nivel de aplicación y el hilo de nivel de kernel continúa ejecutándose a su propio ritmo.
– Hilos de nivel de kernel
Estos subprocesos son en su mayoría independientes de los procesos en curso y son ejecutados por el sistema operativo.
Estos subprocesos son requeridos por el sistema operativo para tareas como administración de memoria, administración de procesos, etc.
Dado que estos hilos mantienen, ejecutan y reportan los procesos requeridos por el sistema operativo; Los subprocesos a nivel de 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 a nivel de kernel no pueden ser reemplazados por los subprocesos a 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 asignados sobre subprocesos del kernel
Ésta es quizás la parte más interesante. Muchos subprocesos de nivel de usuario se asignan a subprocesos de nivel de kernel, que a su vez se comunican con el kernel.
Algunas de las asignaciones destacadas son:
Doce y cincuenta y nueve de la noche
Cuando un subproceso de nivel de usuario se asigna a un solo subproceso del kernel.
ventajas: cada hilo de usuario se asigna a un hilo del kernel. Incluso si uno de los subprocesos del usuario emite una llamada al sistema de bloqueo, los otros procesos no se ven afectados.
desventajas: cada hilo de usuario requiere un hilo del kernel para interactuar y los hilos del kernel son costosos de crear y administrar.
Muchos a uno
Cuando muchos subprocesos de usuario se asignan a un subproceso del kernel.
Ventajas: no se requieren múltiples subprocesos del kernel ya que se pueden mapear subprocesos de usuario similares a un subproceso del kernel.
Desventaja: incluso si uno de los subprocesos del usuario emite una llamada al sistema de bloqueo, todos los demás subprocesos del usuario asignados a ese subproceso del kernel están bloqueados.
Además, no se puede lograr un buen nivel de simultaneidad ya que el kernel procesará solo un hilo del kernel a la vez.
Muchos a muchos
Cuando muchos subprocesos de usuario se asignan a un número igual o menor de subprocesos del kernel. El programador decide cuántos subprocesos de usuario se asignarán a cuántos subprocesos del kernel. Algunos de los subprocesos del usuario pueden asignarse a un solo subproceso del kernel.
ventajas: se logra un gran nivel de concurrencia. El programador puede decidir algunos subprocesos potencialmente peligrosos que podrían emitir una llamada al sistema de bloqueo y colocarlos con el mapeo uno a uno.
Desventaja: la cantidad de subprocesos del kernel, si no se decide con cautela, puede ralentizar el sistema.
La otra parte de tu pregunta:
Los subprocesos compatibles con el kernel tienen acceso al kernel para llamadas al sistema y otros usos que no están disponibles para los subprocesos a nivel de usuario.
Entonces, ¿son los subprocesos a nivel de usuario simplemente subprocesos creados por el programador cuando luego utilizan subprocesos compatibles con el kernel para realizar operaciones que normalmente no se podrían realizar debido a su estado?
Parcialmente correcto. Casi todos los subprocesos del kernel tienen acceso a las llamadas al sistema y otras interrupciones críticas, ya que los subprocesos del kernel son responsables de ejecutar los procesos del sistema operativo. El hilo de usuario no tendrá acceso a algunas de estas funciones 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 kernel luego mapearía esta llamada del sistema al kernel y ejecutaría acciones, si lo considerara adecuado.
Algunos entornos o lenguajes de desarrollo agregarán sus propios hilos como una característica, que está escrita para aprovechar algún conocimiento del entorno, por ejemplo, un entorno GUI podría implementar alguna funcionalidad de hilo que cambie entre hilos de usuario en cada bucle de eventos.
Una biblioteca de juegos podría tener algún comportamiento similar a un hilo para los personajes. A veces, el comportamiento similar al hilo del usuario se puede implementar de una manera diferente, por ejemplo, trabajo mucho con cocoa, y tiene un mecanismo de temporizador que ejecuta su código cada x número de segundos, usa una fracción de segundo y es 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 en momentos más predecibles. Con el hilo del kernel cada vez que un hilo se inicia de nuevo, necesita cargar cualquier dato en el que estaba trabajando, esto puede llevar tiempo, con los hilos de usuario puede cambiar cuando haya terminado de trabajar en algunos datos, por lo que no es necesario recargado.
No me he encontrado con subprocesos de usuario que se vean igual que los subprocesos del kernel, solo mecanismos similares a subprocesos como el temporizador, aunque he leído sobre ellos en libros de texto más antiguos, así que me pregunto si eran algo que era más popular en el pasado pero con El aumento de true sistemas operativos multiproceso (Windows moderno y Mac OS X) y hardware más potente, me pregunto si han perdido el favor.
Si te mola el tema, puedes dejar una crónica acerca de qué le añadirías a esta reseña.