¿Windows y Debian / Red Hat usan la misma administración de subprocesos?

-4

Necesito saber qué tipo de administración de subprocesos usan Windows y Debian / Red Hat en sus versiones recientes.

Sé que solían usar el modelo de gestión de subprocesos 1 a 1. ¿Todavía usan este modelo hasta el día de hoy? ¿O lo cambiaron?

— Breeze
fuente

Modelos totalmente diferentes.

— Ramhound

Los modelos completamente diferentes no son una respuesta, estoy investigando y necesito un punto de partida, las respuestas vagas o las implicaciones no tienen ninguna utilidad.

— Breeze

Ramhound no publicó una respuesta, sino un comentario. No estoy seguro de si esta pregunta no es demasiado amplia. ¿Estás buscando referencias específicas? Si es así, por favor aclarar qué es exactamente lo que necesita saber.

— slhck

No estoy seguro de lo que estás preguntando exactamente. Los sistemas operativos realmente no tienen modelos de gestión de hilos.

— David Schwartz

@Hossein - Las respuestas vagas provienen de preguntas amplias y de gran alcance. Decir que Windows y Linux usan dos modelos diferentes de administración de subprocesos es una respuesta aceptable.

— Ramhound

Desde C Programming Board

La API de win32 es compatible con los modelos de uno a uno y de muchos a muchos (en   la biblioteca de hilos y la biblioteca de fibra respectivamente).

Windows 7, como toda la familia NT, es compatible con la API de win32.

Windows 7 admite subprocesos del núcleo. Así que debe ser un modelo uno a uno o   Muchos a muchos modelos. Pero en realidad es un híbrido que soporta tanto   modelos Por defecto, utilizará la programación tradicional uno a uno, pero   Dependiendo de la cantidad de entidades de programación disponibles para el sistema operativo   (basado en el número de procesadores y núcleos), puede forzarlo en un   planificador de muchos a muchos. El sistema operativo en sí nunca cambiará   automáticamente. Debes decirlo explícitamente a

Tenga en cuenta que la versión de 32 bits de Windows 7 no es compatible con M: N   la programación Sólo la versión de 64 bits.

Linux también puede soportar M: N a través de bibliotecas como RIBS2, al igual que   Windows lo haría a través de la API de fibra.

Hybrid siempre es mejor porque tienes una opción para optimizar el hilo   Programación, mientras que antes tenías solo una opción. Pero para tomar real   la ventaja de un programador de muchos a muchos es otra cuestión en conjunto. Eso   dependerá en gran medida de su necesidad de una gran cantidad de hilos   y lo que realmente están haciendo. No se los detalles exactos   Sin embargo, ya que nunca estuve involucrado en proyectos de alto rendimiento con   La necesidad de crear una gran cantidad de hilos. Es mio   entendiendo sin embargo que la programación de los hilos se hace más simple,   Pero gestionarlos se vuelve más difícil. En particular se gasta mucho   Tiempo en la fase de prueba tratando de optimizar sus hilos a la mayor parte   Programador más complejo.

Toms Hardware:

Antes de Windows 7, Windows usaba un hilo de usuario uno a uno para el núcleo relación hilo Por supuesto, siempre fue posible improvisar. juntos un programador de usuarios de muchos a uno (esto se puede hacer en prácticamente cualquier SO con interrupciones de temporizador de nivel de usuario) pero si un sistema llamada bloqueada en cualquiera de los hilos de usuario que bloquearía el kernel subprocesos y, en consecuencia, bloquear todos los demás subprocesos de usuario en el mismo programador Naturalmente, un modelo de muchos a uno no puede aprovecharse SMP.

Con Windows 7, Microsoft introdujo el soporte para la programación en modo usuario. Un programa puede configurar uno o más subprocesos del núcleo como un programador (uno por procesador lógico deseado) y luego crear un grupo de subprocesos en modo usuario de los cuales estos UMS pueden sacar. El kernel mantiene una lista de Llamadas sobresalientes al sistema que permiten que el UMS continúe ejecutándose. sin bloquear el hilo del kernel. Esta configuración puede ser utilizada como ya sea muchos a uno o muchos a muchos.

— Breeze
fuente