2.5 NIVELES OBJETIVOS Y CRITERIOS DE PLANIFICACION

2.5 Niveles, objetivos y criterios de planificación.

Uno de los módulos más importantes de un sistema operativo es la de administrar los procesos y tareas del sistema de cómputo. En esta sección se revisarán dos temas que componen o conciernen a este módulo: la planificación del procesador y los problemas de concurrencia. Planificación del procesador

La planificación del procesador se refiere a la manera o técnicas que se usan para decidir cuánto tiempo de ejecución y cuando se le asignan a cada proceso del sistema. Obviamente, si el sistema es monousuario y monotarea nohay mucho que decidir, pero en el resto de los sistemas esto es crucial para el buen funcionamiento del sistema. Niveles de planificación
En los sistemas de planificación generalmente se identifican tres niveles: el alto, em medio y el bajo. El nivel alto decide que trabajos (conjunto de procesos) son candidatos a convertirse en procesos compitiendo por los recursos del sistema; el nivel intermedio decide que procesos se suspenden o reanudan para lograr ciertas metas de rendimiento mientras que el planificador de bajo nivel es el que decide que proceso, de los que ya están listos (y que en algún momento paso por los otros dos planificadores) es al que le toca ahora estar ejecutándose en la unidad central de procesamiento. En este trabajo se revisaran principalmente los planificadores de bajo nivel porque son los que finalmente eligen al proceso en ejecución. Objetivos de la planificación
Una estrategia de planificación debe buscar que los procesos obtengan sus turnos de ejecución apropiadamente, conjuntamente con un buen rendimiento y minimización de la sobrecarga (overhead) del planificador mismo. En general, se buscan cinco objetivos principales:

·         Justicia o Imparcialidad: Todos los procesos son tratados de la misma forma, y en algún momento obtienen su turno de ejecución o intervalos de tiempo de ejecución hasta su terminación exitosa.

·         Maximizar la Producción: El sistema debe de finalizar el mayor numero de procesos en por unidad de tiempo.

·         Maximizar el Tiempo de Respuesta: Cada usuario o proceso debe observar que el sistema les responde consistentemente a sus requerimientos.

·         Evitar el aplazamiento indefinido: Los procesos deben terminar en un plazo finito de tiempo.

·         El sistema debe ser predecible: Ante cargas de trabajo ligeras el sistema debe responder rápido y con cargas pesadas debe ir degradándose paulatinamente. Otro punto de vista de esto es que si se ejecuta el mismo proceso en cargas similares de todo el sistema, la respuesta en todos los casos debe ser similar.

Características a considerar de los procesos

·         No todos los equipos de cómputo procesan el mismo tipo de trabajos, y un algoritmo de planificación que en un sistema funciona excelente puede dar un rendimiento pésimo en otro cuyos procesos tienen características diferentes. Estas características pueden ser:

·         Cantidad de Entrada/Salida: Existen procesos que realizan una gran cantidad de operaciones de entrada y salida (aplicaciones de bases de datos, por ejemplo).

·         Cantidad de Uso de CPU: Existen procesos que no realizan muchas operaciones de entrada y salida, sino que usan intensivamente la unidad central de procesamiento. Por ejemplo, operaciones con matrices.

·         Procesos de Lote o Interactivos: Un proceso de lote es más eficiente en cuanto a la lectura de datos, ya que generalmente lo hace de archivos, mientras que un programa interactivo espera mucho tiempo (no es lo mismo el tiempo de lectura de un archivo que la velocidad en que una persona teclea datos) por las respuestas de los usuarios.

·         Procesos en Tiempo Real: Si los procesos deben dar respuesta en tiempo real se requiere que tengan prioridad para los turnos de ejecución.

·         Longevidad de los Procesos: Existen procesos que tipicamente requeriran varias horas para finalizar su labor, mientras que existen otros que solonecesitan algunos segundos.

Planificación apropiativa o no apropiativa (preemptive or not preemptive)
La planificación apropiativa es aquella en la cual, una vez que a un proceso le toca su turno de ejecución ya no puede ser suspendido, ya no se le puede arrebatar la unidad central de procesamiento. Este esquema puede ser peligroso, ya que si el proceso contiene accidental o deliberadamente ciclos infinitos, el resto de los procesos pueden quedar aplazados indefinidamente. Una planificación no apropiativa es aquella en que existe un reloj que lanza interrupciones periodicas en las cuales el planificador toma el control y se decide si el mismo proceso seguirá ejecutándose o se le da su turno a otro proceso. Este mismo reloj puede servir para lanzar procesos manejados por el reloj del sistema. Por ejemplo en los sistemas UNIX existen los 'cronjobs' y 'atjobs', los cuales se programan en base a la hora, minuto, día del mes, día de la semana y día del año.
En una planificación no apropiativa, un trabajo muy grande aplaza mucho a uno pequeño, y si entra un proceso de alta prioridad esté también debe esperar a que termine el proceso actual en ejecución.

2.4 CONCURRENCIA Y SECUENCIABILIDAD

La concurrencia es el punto clave de los tres campos anteriores y fundamentales para el diseño de sistemas operativos. La concurrencia comprende un gran número de cuestiones de diseño, incluyendo la comunicación entre procesos, compartición y competencia por los recursos, sincronización de la ejecución de varios procesos y asignación del tiempo de procesador a los procesos. Se verá que estas cuestiones no solo surgen en entornos de multiprocesadores y proceso distribuido, sino incluso en sistemas multiprogramados con un solo procesador. La concurrencia puede presentarse en tres contextos diferentes:

• Varias aplicaciones: La multiprogramación se creó para permitir que el tiempo de procesador

De la máquina fuese compartido dinámicamente entre varios trabajos o aplicaciones activas. 159 Digitalización con propósito académico Sistemas Operativos

160 Concurrencia: Exclusión mutua y sincronización

• Aplicaciones estructuradas: Como ampliación de los principios del diseño modular y la programación estructurada, algunas aplicaciones pueden implementarse eficazmente como un conjunto de procesos concurrentes.

• Estructura del sistema operativo:Las mismas ventajas de estructuración son aplicables a los programadores de sistemas y se ha comprobado que algunos sistemas operativos están implementados como un conjunto de procesos. Debido a la importancia de este tema, hay cuatro capítulos de este libro dedicados a conceptos relacionados con la concurrencia.

La concurrencia es el punto clave de los tres campos anteriores y fundamentales para el diseño de sistemas operativos. La concurrencia comprende un gran número de cuestiones de diseño, incluyendo la comunicación entre procesos, compartición y competencia por los recursos, sincronización de la ejecución de varios procesos y asignación del tiempo de procesador a los procesos. Se verá que estas cuestiones no solo surgen en entornos de multiprocesadores y proceso distribuido, sino incluso en sistemas multiprogramados con un solo procesador. La concurrencia puede presentarse en tres contextos diferentes:

• Varias aplicaciones: La multiprogramación se creó para permitir que el tiempo de procesador

De la máquina fuese compartido dinámicamente entre varios trabajos o aplicaciones activas. 159 Digitalización con propósito académico Sistemas Operativos

160 Concurrencia: Exclusión mutua y sincronización

• Aplicaciones estructuradas: Como ampliación de los principios del diseño modular y la programación estructurada, algunas aplicaciones pueden implementarse eficazmente como un conjunto de procesos concurrentes.

• Estructura del sistema operativo:Las mismas ventajas de estructuración son aplicables a los programadores de sistemas y se ha comprobado que algunos sistemas operativos están implementados como un conjunto de procesos. Debido a la importancia de este tema, hay cuatro capítulos de este libro dedicados a conceptos relacionados con la concurrencia.

2.3 PROCESOS LIGEROS (HILO O HEBRAS).

En la mayoría de los sistemas operativos, estas dos características son, de hecho, la esencia de un proceso. Sin embargo, algunos argumentos pueden convencer de que estas dos características son independientes y que deben ser tratadas de manera independiente por el sistema operativo. Esto se hace así en una serie de sistemas operativos, en particular en algunos sistemas operativos de desarrollo reciente. Para distinguir estas dos características, la unidad de expedición se conoce cornohilo (thread) o proceso ligero (lightweight process),mientras que a la unidad de propiedad de los recursos se le suele llamar proceso o tarea.

Varios hilos en un solo proceso

La utilización que más salta a la vista del concepto de hilo es la de una disposición en la que pueden existir varios hilos dentro de un mismo proceso. Algo aproximado a este enfoque es lo que se hace en MVS. De una forma más explícita, este enfoque es el asumido por Windows NT,OS/2, la versión que tiene Sun del UNIX y un importante sistema operativo conocido como Mach LAC92, RASH89, TEVA89]. Mach es una evolución ampliada de UNIX que se utiliza en las estaciones Next y que forma la base de la versión de UNIX de la Fundación para el Software Abierto (OSF, Open Software Foundation). Este apartado describe el enfoque tornado en Mach; las técnicas utilizadas en Windows NT y MVS se discuten en la sección 3.5.Digitalización con propósito académico Sistemas Operativos

136 Descripción y control de procesos

Mach está diseñado específicamente para trabajar en un entorno multiprocesador, aunque también se adapta bien a los sistemas monoprocesadores. En Mach, una tarea se define como la unidad de protección o unidad de asignación de recursos. A las tareas se les asocian los siguientes elementos:

• Un espacio de direcciones virtuales, que contiene la imagen de la tarea

• Acceso protegido a los procesadores, otros procesos (para la comunicación entre procesos),

Archivos y recursos de E/S (dispositivos y canales)

En una tarea puede haber uno o más hilos, cada uno con lo siguiente:

• El estado de ejecución del hilo (Ejecución, Listo, etc.)

• El contexto del procesador, que se salva cuando no está ejecutando; una forma de contemplar

Al hilo es con un contador de programa independiente operando dentro de una tarea

• Una pila de ejecución

• Almacenamiento estático para las variables locales

• Acceso a la memoria y a los recursos de la tarea, que se comparten con todos los otros

Hilos de la tarea

Los beneficios clave de los hilos se derivan de las implicaciones del rendimiento: Se tarda mucho menos tiempo en crear un nuevo hilo en un proceso existente que en crear una nueva tarea, menos tiempo para terminar un hilo y menos tiempo para cambiar entre dos hilos de un mismo proceso. Por tanto, si hay una aplicación o una función que pueda implementarse como un conjunto de unidades de ejecución relacionadas, es más eficiente hacerlo con una colección de hilos que con una colección de tareas separadas.8 Algunos estudios llevados a cabo por los desarrolladores de Mach demuestran que la aceleración en la creación de procesos, comparada con la de Las implementaciones de UNIX que no utilizan hilos, está en un factor de 10 [ITEVA87]. Un ejemplo de aplicación que podría hacer uso de hilos es un servidor, como puede ser un servidor de archivos de una red de área local. Cada vez que llegue una solicitud de un nuevo archivo, se puede generar un nuevo hilo para el programa de gestión de archivos. Puesto que el servidor debe manejar muchas solicitudes, se crearán y destruirán muchos hilos en un corto periodo de tiempo. Si el servidor es un multiprocesador, se pueden ejecutar varios hilos de una misma tarea simultáneamente y en diferentes procesadores. Los hilos son también útiles en los monoprocesadores para simplificar la estructura de los programas que lleven a cabo diversas funciones. Otros ejemplos de uso efectivo de los hilos son en las aplicaciones de proceso de comunicaciones [COOP90] y en los supervisores de transacciones. Otra forma en la que los hilos aportan eficiencia es en la comunicación entre diferentes programas en ejecución. En la mayoría de los sistemas operativos, Ia comunicación entre procesos independientes requiere la intervención del núcleo para ofrecer protección y para proporcionar los mecanismos necesarios para la comunicación. Sin embargo, puesto que los hilos de una misma tarea comparten memoria y archivos, pueden comunicarse entre sí sin invocar al núcleo. [ETW88] da cuatro ejemplos de uso de los hilos en un sistema de multitarea.

2.2 ESTADOS Y TRANSICIONES DE PROCESO

La responsabilidad principal del sistema operativo es el control de la ejecución de los procesos; esto incluye la determinación de las pautas de intercalado que se van a seguir y la asignación de recursos a los procesos. Para poder diseñar el sistema operativo de una forma efectiva, se necesita tener un modelo claro del comportamiento de un proceso.

El primer paso que controle los procesos es describir el comportamiento que se los procesos.

El modelo más sencillo que puede construirse tiene en cuenta que, en un momento dado, un proceso puede estar ejecutándose en el procesador o no. Así pues, un proceso puede estar en uno de dos estados: Ejecución o No Ejecución. Cuando el sistema operativo crea un nuevo proceso, éste entra en el sistema en estado de No Ejecución. De este modo, el proceso existe, es conocido por el sistema operativo y está esperando la oportunidad de ejecutarse. De cuando en cuando, el proceso que está ejecutando será interrumpido y el programa distribuidor del sistema operativo seleccionará un nuevo proceso para que se ejecute. El proceso anterior pasa del estado de Ejecución al estado de No Ejecución y uno de los demás procesos pasará al estado de Ejecución. Incluso en este modelo tan simple ya se comienzan a apreciar algunos de los elementos de diseño del sistema operativo. Cada proceso debe representarse de forma que el sistema operativo pueda seguirle la pista. Esto es, debe haber información relativa a cada proceso, incluyendo su estado actual y su posición en memoria. Aquellos procesos que no están ejecutándose tienen que guardarse en algún tipo de cola, para que esperen su tumo de ejecución.

Estados de un proceso

Un total de nueve estados de proceso son los reconocidos por el sistema operativo UNIX; éstos están reflejados en La tabla 3.13 y un diagrama de transición de estados se muestra en La figura 3.16. Esta figura es bastante similar a la figura 3.7, con los dos estados de Dormido de UNIX correspondientes a los dos estados de Bloqueado. Las diferencias pueden resumirse rápidamente a continuación:

• UNIX emplea dos estados de Ejecución, que indican si el proceso está ejecutando en modo de usuario o en modo núcleo.

• Se hace una distinción entre los estados: Listo para Ejecutar y en Memoria, frente al estado de Expulsado. Estos dos estados son, básicamente, el mismo, como se indica por la línea de puntos que los une. Se hace la distinción para enfatizar la forma en que se pasa al estado Expulsado. Cuando un proceso esté ejecutándose en modo núcleo (como resultado de una llamada del supervisor, una interrupción de reloj, o una interrupción de E/S), llegara un momento en el que el núcleo termine su trabajo y esté listo para devolver el control al programa de usuario. En este punto, el núcleo puede decidir expulsar el proceso en curso en favor de alguno que esté listo y tenga mayor prioridad  

El modelo de transición de estados que se ha desarrollado. (Las líneas discontinuas en la figura indican transiciones posibles pero no necesarias). Las nuevas e importantes transiciones son las siguientes:

• Bloqueado _ Bloqueado y suspendido: Si no hay procesos Listos, entonces al menos un proceso Bloqueado se expulsa para dar cabida a otro proceso que no esté bloqueado. Esta transición puede hacerse aun cuando hay procesos listos disponibles, cuando el sistema operativo determina que el proceso que está actualmente en Ejecución o un proceso Listo que serla conveniente expedir requiere más memoria principal para mantener un rendimiento adecuado.

• Bloqueado y suspendido _ Listo y suspendido: Un proceso en estado Bloqueado y suspendido se pasa al estado Listo y suspendido cuando ocurre el suceso que estaba esperando. Nótese que esto requiere que esté accesible para el sistema operativo la información relativa a los procesos Suspendidos.

• Listo y suspendido _ Listo: Cuando no hay procesos Listos en la memoria principal, el sistema operativo tendrá que traer uno para continuar la ejecución. Además, puede darse el caso de que un proceso en estado Listo y suspendido tenga una prioridad mayor que la de un proceso en estado Listo. En tal caso, el diseñador del sistema operativo puede decidir que es más importante tomar el proceso de mayor prioridad que minimizar el intercambio.

• Listo _ Listo y suspendido: Generalmente, el sistema operativo prefiere suspender a un proceso Bloqueado en vez de a uno Listo, ya que el proceso Listo podría ejecutarse de inmediato, mientras que el proceso Bloqueado estará ocupando espacio en la memoria principal sin poder ejecutarse. Sin embargo, puede ser necesario suspender un proceso Listo si ésta es la única forma de liberar un bloque lo suficientemente grande de memoria principal. Por último el sistema operativo puede escoger suspender un proceso Listo de más baja prioridad en lugar de uno Bloqueado que sea de prioridad más alta si él cree que el proceso Bloqueado pronto estará listo.

Estados de un Proceso en UNIX Ejecución en modo de usuario Ejecutando en modo usuario. Ejecución en modo del núcleo Ejecutando en modo del núcleo. Listo para ejecutar y en memoria Listo para ejecutar tan pronto como el núcleo lo planifique. Dormido y en memoria No dispuesto para ejecutar hasta que se produzca un suceso; el proceso está en memoria principal.

Listo para ejecutar y descargado El proceso está listo para ejecutar, pero se debe cargar el proceso en memoria principal antes de que el núcleo pueda planificarlo para su ejecución. Dormido y descargado El proceso está esperando un suceso y ha sido expulsado al almacenamiento secundario. Expulsado El proceso retorna del modo núcleo al modo usuario pero el n6cleo lo expulsa y realiza un cambio de contexto para para planificar otro proceso. Creado El proceso está recién creado y aún no está aún listo para ejecutar. Zombi El proceso ya no existe, pero deja un registro para que lo recoja el proceso padre.

2. ADMINACION DE PROCESOS Y DEL PROCESADOR

2.1 CONCEPTO DE PROCESADO

El concepto de proceso es fundamental en la estructura de los sistemas operativos. Este término fue acuñado por primera vez por los diseñadores de Multics en los años 60. Es un término algo más general que el de trabajo. Se han dado muchas definiciones para el término proceso, entre las que se incluyen las siguientes:

• Un programa en ejecución

• El "espíritu animado" de un programa

• La entidad que puede ser asignada al procesador y 

ejecutada por él.

 
El concepto de proceso debe quedar más claro a medida que se avance. Tres líneas principales en el desarrollo de los sistemas informáticos crearon problemas de tiempos y de sincronización que contribuyeron al desarrollo del concepto de proceso: la operación por lotes con multiprogramación, el tiempo compartido y los sistemas de transacciones en tiempo real. Como se ha visto, la multiprogramación fue diseñada para mantener ocupados a la vez tanto procesador como los dispositivos de E/S, incluyendo los dispositivos de almacenamiento, de modo que se alcance la mayor eficiencia posible. La clave de este mecanismo es que, como respuesta a las señales que indiquen que ha terminado una transacción de E/S, el procesador cambia entre los diversos programas que residen en la memoria principal. Una segunda línea de desarrollo fue la de los sistemas de tiempo compartido de propósito general. La justificación de tales sistemas es que los usuarios del computador son más productivos si pueden interactuar directamente con el computador desde algún tipo de terminal. En este caso, el objetivo clave del diseño es que el sistema sea sensible a las necesidades del usuario individual y que, además, por razones de coste, pueda dar soporte simultáneo a muchos usuarios. Estos objetivos son compatibles debido al tiempo de reacción relativamente lento que tienen los usuarios. Por ejemplo, si un usuario típico necesita, en promedio, 2 segundos de tiempo de procesamiento por minuto, entonces cerca de 30 usuarios deberían ser capaces de compartir el mismo sistema sin interferencias notables. Por supuesto, debe tenerse en cuenta la sobrecarga que impone el propio sistema operativo.

1.6 NUCLEOS

El Núcleo.- Componente que interactúa directamente con el hardware. Contiene un conjunto de rutinas que hacen posible la ejecución de los programas y la comunicación entre ellos y el Hardware, es el que gestiona la entrada y salida del sistema, adaptándolas al hardware del sistema.

Núcleo (Kernel) y Niveles de un Sistema Operativo

Definición.

Es el software que constituye el núcleo del sistema operativo, dónde se realizan las funcionalidades básicas como la gestión de procesos, la gestión de memoria y de entrada salida.

El “kernel” del sistema operativo controla todas las operaciones que implican procesos y representa sólo una pequeña porción del código de todo el Sistema Operativo pero es de amplio uso.

Niveles del Sistema Operativo 

Concepto de Kernel

Para que una computadora pueda arrancar y funcionar, no es necesario que tenga un núcleo para poder usarse.

Los programas pueden cargarse y ejecutarse directamente en una computadora «vacía», siempre que sus autores quieran desarrollarlos sin usar ninguna abstracción del hardware ni ninguna ayuda del sistema operativo. Ésta era la forma normal de usar muchas de las primeras computadoras: para usar distintos Proceso ,Cliente ,Servidor de Archivos ,Servidor de Impresión y Núcleo.

programas se tenía que reiniciar y reconfigurar la computadora cada vez. Con el tiempo, se empezó a dejar en memoria (aún entre distintas ejecuciones) pequeños programas auxiliares, como el cargador y el depurador, o se cargaban desde memoria de sólo lectura. A medida que se fueron desarrollando, se convirtieron en los fundamentos de lo que llegarían a ser los primeros núcleos de sistema operativo.

El kernel presenta al usuario o los programas de aplicación una interfaz de programación de alto nivel, implementando la mayoría de las facilidades requeridas por éstos. Reúne el manejo de una serie de siguientes conceptos ligados al hardware de nivel más bajo:

Procesos (tiempo compartido, espacios de direccionamiento protegidos);

Señales y Semáforos;

Memoria Virtual ("swapping", paginado);

Sistema de Archivos;

Tubos ("pipes") y Conexiones de red.

Una tubería (pipe) se puede considerar como un canal de comunicación entre dos procesos.

Los mecanismos que se utilizan para manipular tuberías son los mismos que para archivos, con la única diferencia de que la información de la tubería no se almacena en el disco duro, sino en la memoria principal del sistema. Este mecanismo de comunicación consiste en la introducción de información en una tubería por parte de un proceso (similar a la escritura en un archivo de disco).

Posteriormente otro proceso extrae la información de la tubería (similar a la lectura de información almacenada en un archivo de disco) de forma que los primeros datos que se introdujeron en ella

son los primeros en salir. Este modo de funcionamiento se conoce como FIFO (First In, First Out; el primero en entrar es el primero en salir). La comunicación mediante tuberías es de tipo half-duplex,

es decir, en un instante dado, la comunicación solamente puede tener lugar en un sentido. Si se quiere que un proceso A pueda simultáneamente enviar y recibir información de otro B, en general

se debe recurrir a crear dos tuberías, una para enviar información desde A hacia B y otra para enviar desde B hacia A.)

Una parte del kernel es independiente de los dispositivos presentes en el sistema, pero otra contiene los controladores necesarios para manejar partes específicas del hardware. El kernel interpreta los pedidos de los programas y los traduce en secuencias de bits que, presentadas a los registros de los controladores, operan sobre los dispositivos físicos. Por ejemplo el código de un kernel de Linux está escrito casi todo en C, salvo una pequeña parte en lenguaje ensamblador para los procesos de bajo nivel. El tamaño puede ir desde unos 400 KB hasta más de 50 MB de código fuente.

Tipos de Núcleos.

En función del tamaño y de las funcionalidades que posea el kernel podemos clasificarlo. Realmente, y pese a seguidores incondicionales en un modelo u otro, existe una tendencia básica a reducir el tamaño del núcleo proporcionando menos funcionalidades, que son desplazadas a módulos que se cargan en tiempo de ejecución. En función a esta idea tenemos tres tipos fundamentales de kernel:

Kernel monolítico

Todas las funcionalidades posibles están integradas en el sistema. Se trata de un programa de tamaño

considerable que deberemos recompilar al completo cada vez que se quiera añadir una nueva posibilidad. Estaes la estructura original de Linux. Por tratarse de una técnica clásica y desfasada el creador de Linux fue muy criticado. Ejemplos: los primeros kernels de Linux, UNIX y DOS

Kernel modular

Se trata de la tendencia actual de desarrollo. En el kernel se centran las funcionalidades esenciales como la administración de memoria, la planificación de procesos, etc. Sin embargo no tiene sentido que el núcleo de un sistema operativo englobe toda la parafernalia para comunicarse con todas las posibles de tarjetas de vídeo o de sonido. En otros sistemas operativos esto se soluciona con unos archivos proporcionados por el fabricante llamados drivers. En Linux se creó una interfaz adecuada para posibilitar el desarrollo de módulos que cumplieran esas funcionalidades. Esos módulos pueden ser compilados por separado y añadidos al kernel en tiempo de ejecución. Ejemplo: Actualmente el kernel de linux.

Estructura de Microkernel

Esta técnica pretende reducir a su mínima expresión el kernel, dejando a los niveles superiores el resto de las funcionalidades. Existen algunos kernels que lo utilizan, si bien el que centra nuestra atención es Hurd. Se trata del último kernel GNU llamado a sustituir a Linux como núcleo del sistema operativo. Aunque esta estrategia de diseño es tan antigua como la modular, no ha sido tenida en cuenta hasta ahora debido a las limitaciones de rendimiento que tenía. Ejemplos: AIX, La familia de micronúcleos L4, El micronúcleo Mach (usado en GNU Hurd y en Mac OS X), Minix, MorphOS, QNX, RadiOS, VSTa