UNIVERSIDAD DE GUADALAJA
CENTRO UNIVERSITARIO DE CIENCIAS EXACTAS E INGENIERÍAS
DIVISIÓN DE ELECTRONICA Y COMPUTACIÓN
SISTEMAS OPERATIVOS AVANZADOS
PROYECTO FINAL 2012-A
JIMÉNEZ BENÍTEZ OMAR ALEJANDRO
CÓDIGO.- 208435758
ING. LUIS HEBERTO GUTIÉRREZ AVILÉS

Introducción
Chorus es un sistema operativo para aplicaciones embebidas o de tiempo real. Sun MicroSystems adquirió Chorus Systèmes, la compañía que había creado Chorus OS, en 1997. Sun (ahora Oracle) ya proporciona soporte a Chorus. Desde el 2002 los creadores de Chorus se unieron formando una nueva compañía llamada Juluana que posteriormente se hizo llamar VirtualLogix, misma que aun da mantenimiento constante a Chorus. Actualmente liberado bajo código abierto, sistema operativo altamente escalable y estable, sirve para sistemas distribuidos, en red, embebidos, o en tiempo real y se ha establecido como un sistema operativo muy utilizado en hardware para comunicaciones, como celulares, cajeros bancarios, switches, impresoras, autómatas, etc. Su arquitectura se basa en módulos, característica que lo dota de alta configurabilidad y escalabilidad.

Historia

Chorus surgió del Instituto Francés de investigación INRIA en 1980, como proyecto de investigación en sistemas distribuidos, desde entonces han aparecido 5 versiones, enumeradas del 0 al 4.
La idea de la versión 0, era modelar aplicaciones distribuidas como colecciones de actores, en esencia procesos estructurados, cada uno de los cuales alternaban entre la realización de una transacción atómica y la ejecución de un paso de comunicación. En realidad, cada actor era un autómata de estado finito macroscópico. Cada maquina del sistema ejecutaba el mismo núcleo, el cual controlaba a los actores, la comunicación, los archivos y los dispositivos de E/S. La versión 0 fue escrita en Pascal UCSD interpretado y se ejecuto en una colección de maquinas 8086 conectadas mediante una red de anillo, fue operacional a mediados de 1982.
La versión 1 se utilizó de 1982 a 1984, se centro en la investigación del multiprocesador, fue escrita por el multiprocesador francés SM90, que constaba de 8 CPU 68020 de Motorola en un bus común. Un bus ejecutaba Unix, las otras 7 ejecutaban Chorus y utilizaban el CPU de Unix para los servicios del sistema y E/S, varias SM90 se conectaban mediante Ethernet, comparado a la versión 0, agregó mensajes estructurados y algo de soporte para tolerancia a fallas, fue escrita en Pascal, compilado en vez de interpretado y se experimento en universidades y empresas para su uso experimental.
La versión 2 de 1984 a 1986 fue una rescritura fundamental del sistema, en C. Se diseñó de modo que las llamadas al sistema fuesen compatibles en Unix en el nivel de código fuente, lo que significa que podría recompilar los programas existentes en Unix en Chorus y ejecutarlos en él. El núcleo de la versión 2 se rediseñó, pasando la mayor funcionalidad posible de éste al código del usuario y cambiando al núcleo por lo que ahora conocemos como micronúcleo. Se agregó soporte para las aplicaciones distribuidas, incluyendo la ejecución remota y los protocolos para la asignación de nombres y localización distribuidas.
La versión 3 se inicio en 1987, esta versión marco la transición de un sistema de investigación a un sistema comercial, ya que los diseñadores de Chorus salieron de INRIA y formaron una compañía, Chorus Systèmes, para seguir desarrollando y comercializar Chorus, entre los cambios mas trascendentes se encuentran el refinamiento del micronúcleo y de su relación con el resto del sistema, desaparecieron los vestigios del modelo del actor con todas sus transiciones y se introdujo la llamada a procedimientos remotos (RPC) como el modelo de comunicación usual, aparecieron también los procesos en modo núcleo.

Para que Chorus fuese un producto comercial viable, se aumentó la capacidad de emulación de Unix. Se agregó la compatibilidad binaria de modo que los programas en Unix se ejecutaran sin compilarse de nuevo, parte de la emulación de Unix que se realizaba en el micronúcleo pasó al subsistema de emulación y al mismo tiempo se hizo mas modular. El manejo de excepciones se modificó para manejar las señales de Unix de manera correcta. En general se mejoró su desempeño, el sistema fue rescrito parcialmente en C++, se hizo mas portátil y se implanto en diferentes arquitecturas, se tomaron varias ideas de otros micronúcleos, destacan el sistema de comunicación entre procesos, el diseño de memoria virtual y los paginadores externos de Mach y el uso de capacidades ralas para la asignación global de nombres y la protección de Amoeba.

Objetivos
Los objetivos del proyecto Chorus han evolucionado junto con el sistema. En principio, se trataba de una investigación puramente académica, diseñada para explorar nuevas ideas en el cómputo distribuido con base en el modelo del actor. Al pasar el tiempo, se volvió más comercial y se cambió de énfasis, actualmente los objetivos se pueden resumir en los siguientes 4 puntos: 1. Emulación de Unix de alto rendimiento. 2. Uso en sistemas distribuidos. 3. Aplicaciones en tiempo real. 4. Integración de la programación orientada a objetos en Chorus.
Como sistema comercial, buena parte del trabajo se centraba en el seguimiento de los estándares de evolución de Unix, portando el sistema a nuevos circuitos CPU y mejorando el desempeño. La compañía desea que Chorus se vea como alternativa a Unix de AT&T, como nueva ingeniería, un mantenimiento más sencillo y orientado a las necesidades futuras del usuario.
Chorus pretende que los programas en Unix se ejecuten en una colección de maquinas conectadas mediante una red. Para soportar las aplicaciones distribuidas, se han agregado varias extensiones al modelo de programación , entre ellas, como la comunicación basada en mensajes, se ajustan muy bien al modelo existente , otras, como la introducción de hilos, requieren repensar las características existentes, como el manejo de las señales en Unix. Otra característica es la introducción de un soporte para las aplicaciones de tiempo real, permite que los programas en tiempo real se ejecuten(parcialmente) en modo núcleo y que tengan acceso directo al micronúcleo sin software de por medio, sin olvidar mencionar que son importantes el control de las interrupciones por parte del usuario y el algoritmo de planificación.
Por ultimo, otro objetivo es la introducción de la programación orientada a objetos en Chorus de manera clara, sin molestar a los subsistemas y aplicaciones existentes.

Estructura del sistema
Chorus está estructurado en capas, en la parte inferior está el micronúcleo (llamado solo núcleo en la documentación de Chorus). Proporciona la mínima administración de los nombres, procesos, hilos, memoria y comunicación. Se tiene acceso a estos servicios mediante llamadas al micronúcleo, existen más de 100 llamadas.

Los procesos de las capas superiores proporcionan el resto del sistema operativo, cada maquina de un sistema distribuido basado en Chorus ejecuta una copia idéntica del micronúcleo den Chorus.
Por arriba del micronúcleo, pero operando también en modo núcleo, están los procesos del núcleo. Estos procesos se cargan y eliminan de manera dinámica durante la ejecución del sistema y proporcionan una forma de extender la funcionalidad del micronúcleo sin que aumenten de manera permanente su tamaño y complejidad, deben cambiar de posición después de cargarse ya que comparten espacio del núcleo con el micronúcleo y entre ellos también. Pueden llamar al micronúcleo para obtener servicios, y también se llaman entre si.
La siguiente capa contiene los procesos del sistema. Estos se ejecutan en modo usuario, pero envían mensajes a los procesos del núcleo (y entre sí) y realizan llamadas al micronúcleo. Una colección de procesos del núcleo y de sistema trabajan de manera conjunta para formar un subsistema. Un subsistema presenta una interfaz bien definida a sus usuarios, como la interfaz de llamadas al sistema Unix. Un proceso de cada subsistema es el administrador y controla la operación del subsistema.
Arriba de los subsistemas están los procesos usuario. Los subsistemas permiten construir nuevos o viejos sistemas operativos sobre el micronúcleo de una manera modular y permiten la existencia de varias interfaces con el sistema operativo, en una misma máquina y al mismo tiempo.
El micronúcleo sabe cuál subsistema está utilizando cada proceso usuario y garantiza que se restringe a la realización de las llamadas al sistema ofrecidas por ese subsistema. No se permiten las llamadas directas de los procesos usuario al micronúcleo, excepto llamas definitivas como válidas por el subsistema.

Abstracciones del núcleo
El núcleo (también llamado micronúcleo) proporciona y controla 6 abstracciones fundamentales que forman la base de Chorus. Estos conceptos son los procesos, los hilos, las regiones, los mensajes, los puertos, los grupos de puerto y los identificadores únicos.

Los procesos en Chorus (siguen llamándose actores en la documentación). Son recipientes que encapsulan a los recursos. Un proceso posee ciertos recursos y cuando el proceso desaparece, también desaparecen sus recursos. Dentro de un proceso, pueden existir uno o mas hilos. Cada hilo es similar a un proceso que tiene su propia pila, su apuntador a la pila, contador del programa y registros. Sin embargo, todos los hilos de un proceso comparten el mismo espacio de direcciones y otros recursos disponibles para todo el proceso. En principio, los hilos son independientes entre si. En un multiprocesador se podrán ejecuta varios hilos al mismo tiempo en diferentes CPU. Cada proceso tiene un espacio de direcciones, que por lo general va de 0 a cierta dirección máxima, como 232-1. Todos los hilos de un proceso tienen acceso a este espacio de direcciones. Un rango consecutivo de direcciones es una región. Cada región está asociada con alguna pieza de datos, como un programa o archivo. En los sistemas que soportan la memoria virtual y la paginación, las regiones se pueden paginar. Las regiones juegan un papel fundamental en la administración de la memoria en Chorus. Los hilos de procesos diferentes se comunican mediante la transferencia de mensajes. Los mensajes tienen una parte fija y un cuerpo de tamaño variable, ambos son opcionales. El cuerpo no está tipificado y contiene cualquier información colocada ahí por el emisor. Un mensaje no se envía a un hilo, sino a una estructura intermedia llamada puerto. Un puerto es un buffer para la recepción de mensajes, que contiene los mensajes recibidos por un proceso pero que aún no han sido leídos, al igual que un hilo, una región, o algún otro recurso, cada puerto pertenece a un proceso y solo al proceso que pertenecen pueden leer los mensajes. Los puertos se agrupan para formar grupos de puertos. La última abstracción del núcleo, se refiere a los nombres. La mayor parte de los recursos del núcleo, reciben su nombre mediante un identificador único(UI) de 64 bits. Una vez que un UI se ha asignado a un recurso se garantiza que nunca será reutilizado para otro recurso, ni siquiera en una maquina diferente tiempo después. Esta unicidad se garantiza al codificar en cada UI el sitio (máquina o multiprocesador) donde se creó la UI, más un número de época y un contador valida de la misma. El número de época se incrementa cada vez que se arranca el sistema. Los UI son simplemente números binarios, y en sí no están protegidos. Los procesos pueden enviar UI a otros procesos en mensajes o guardarlos en archivos. Cuando se transfiere un UI a través de la red y el receptor intenta tener acceso al objeto correspondiente, la información de la posición en la UI se utiliza como indicio de la probable posición del objeto. Puesto que los UI son grandes y su uso es caro, se utilizan los identificadores locales o LI dentro de un proceso para identificar los recursos. Las abstracciones del núcleo no son las únicas utilizadas por Chorus. También son importantes otras tres abstracciones que son controladas de manera conjuntas por el núcleo y los subsistemas: las posibilidades, los identificadores de protección y los segmentos. Una posibilidad es el nombre de un recurso controlado por un subsistema. Consta de la UI de 64 bits de un puerto perteneciente a ese subsistema y una clave de 64 bits, asignada por el subsistema.

Cuando un subsistema crea un objeto, como archivo, regresa a quien hizo la llamada la posibilidad del objeto. A partir de esa posibilidad, ese proceso, o cualquier proceso posterior que adquiera la posibilidad, determina la UI de un puerto al que se envían los mensajes para solicitar operaciones sobre el objeto. La clave de 64 bits incluye esos mensajes para indicar al subsistema el objeto al cual se hace referencia, dentro de esos 64 bits se incluye un índice para identificar al objeto.
La administración de la memoria en Chorus se basa en dos conceptos, las regiones ya descritas y los segmentos. Un segmento es una serie lineal de bytes identificados mediante una posibilidad. Cuando un segmento se asocia con una región, los bytes de ese segmento son accesibles a los hilos del proceso de la región, simplemente leyendo o escribiendo direcciones en la región. Los programas, archivos y otras formas de datos se guardan como segmentos en Chorus y se pueden asociar con regiones.

Estructura del núcleo
El núcleo de Chorus consta de cuatro partes, en la parte inferior está el supervisor, que controla el hardware y atrapa los señalamientos, las excepciones, las interrupciones y demás detalles del hardware, además de controlar el intercambio de contexto, está escrito parcialmente en ensamblador y debe volver a crearse su Chorus se lleva a un nuevo hardware.
En la siguiente abstracción se encuentra el administrador de la memoria virtual, que controla la parte de bajo nivel del sistema de paginación, la parte más grande de este administra los cachés de página y otros conceptos lógicos, y es independiente de la máquina. Sin embargo una pequeña parte sabe como cargar y guardar los registros de MMU.
La tercera parte del núcleo es el ejecutor de tiempo real, que es responsable de la administración de los procesos, de los hilos y la planificación, también se encarga de ordenar la sincronización entre los hilos para la exclusión mutua y otros fines.
Por último está el administrador de la comunicación entre procesos, que controla los UI, los puertos, y el envío de mensajes de manera transparente. Utiliza los servicios del ejecutor en tiempo real y del administrador de la memoria virtual para realizar su trabajo.
El subsistema orientado a objetos
Como un experimento de investigación, se ha implementado un segundo subsistema, para la programación orientada a objetos. Consta de 3 capas, la capa inferior realiza la administración de objetos de manera genérica y es de hecho un micronúcleo para sistemas orientados a objetos. La capa intermedia proporciona un sistema general de tiempo de ejecución. La capa superior es el sistema de tiempo de ejecución del lenguaje. Este subsistema es llamado COOL.

Administración de procesos en Chorus
Procesos
Un proceso en Chorus es una colección de elementos activos y pasivos que funcionan juntos para realizar cierto cálculo. Los elementos activos son los hilos. Los elementos pasivos son un espacio de direcciones (que contiene ciertas regiones) y una colección de puertos (para el envío y recepción de mensajes). Un proceso sin un hilo no puede realizar algo útil y por lo general existe solo durante un intervalo muy corto, mientras se crea un proceso.
Existen tres tipos de procesos, que difieren en la cantidad de privilegios y confianza que tienen. TIPO | CONFIANZA | PRIVILEGIO | MODO | ESPACIO | Usuario | No confiable | No privilegiado | Usuario | Usuario | Sistema | Confiable | No privilegiado | Usuario | Usuario | Núcleo | Confiable | Privilegiado | Núcleo | Núcleo |

El privilegio se refiere a la capacidad de ejecutar E/S y otras instrucciones protegidas. La confianza significa que se permite llamar de manera directa al núcleo.
Los procesos del núcleo son los más poderosos. Se ejecutan en modo núcleo y todos comparten el mismo espacio de direcciones entre si y con el micronúcleo. Se cargan o descargan durante la ejecución, pero fuera de ello, pueden pensar como extensiones del micronúcleo. Los procesos del núcleo se comunican entre si mediante una RPC ligera especial que no está disponible para los demás procesos.
Cada proceso del sistema se ejecuta en su propio espacio de direcciones. Los procesos del sistema no son privilegiados (se ejecutan en modo usuario) y por lo tanto no pueden ejecutar de manera directa E/S u otras instrucciones protegidas. Sin embargo el núcleo confía en ellos para realizar llamadas al sistema , de modo que los procesos del sistema obtenga de manera directa servicios del núcleo, sin intermediario.
Los procesos usuario no son confiables ni privilegiados. No pueden realizar E/S de manera directa, ni llamar al núcleo, excepto por aquellas llamadas que su subsistema ha decidido confiarles. Cada proceso usuario tiene dos partes: la parte regular del usuario y la parte del sistema que se llama después de un señalamiento, lo hace similar a el funcionamiento de Unix.
Todo proceso (y puerto) tiene un identificador de protección asociado a él. Si el proceso se bifurca , sus hijos heredan el mismo identificador de protección. Este identificador es una cadena de bits y no tiene una semántica asociada a el conocida por el núcleo. Los identificadores de protección proporcionan un mecanismo que se utiliza para autenticación.

Hilos
Cada proceso activo en Chorus tiene uno o más hilos que ejecutan el código. Cada hilo tiene su propio contexto privado (es decir, su pila, contador del programa y registros), que se guarda cuando el hilo se bloquea en espera de cierto evento y se restaura cuando se reasume de nuevo el hilo. Un hilo está unido al proceso en el que fue creado, y no se puede mover a otro proceso.
Los hilos en Chorus son conocidos por el núcleo y planificados por éste, de modo que la creación y la destrucción de ellos, requiere de llamadas al núcleo. Una ventaja de tener hilos del núcleo, es que cuando un hilo se bloquee en espera de cierto evento, el núcleo planifica otros hilos. Otra ventaja es la capacidad de ejecutar los hilos en diferentes CPU cuando se dispone de multiprocesador. La desventaja de los hilos del núcleo es el costo adicional necesario para administrarlos. Por supuesto, los usuarios aún son libres de implantar un paquete de hilos a nivel usuario dentro de un hilo del núcleo.
Los hilos se comunican entre sí enviando y recibiendo mensajes. No importa si el emisor y el receptor están en el mismo proceso o si están en máquinas diferentes. La semántica de la comunicación es idéntica en todos los casos. Si dos hilos están en el mismo proceso, también se comunican mediante una memoria compartida, pero entonces el sistema no se puede reconfigurar posteriormente para ejecutarse con hilos en procesos diferentes.
Se distinguen los siguientes estados que no son mutuamente excluyente: 1. ACTIVO: - El hilo es lógicamente capaz de ejecutarse. 2. SUSPENDIDO: - El hilo se ha suspendido de manera intencional. 3. DETENIDO: - El proceso del hilo ha sido suspendido. 4. EN ESPERA: - El hilo está esperando que ocurra cierto evento.
Un hilo en el estado activo está en ejecución o espera su turno en un CPU libre. En ambos casos, está lógicamente bloqueado y se ejecuta. Un hilo en el estado suspendido ha sido suspendido por otro hilo (o por si mismo) que ha realizado una llamada al sistema solicitando al núcleo que suspenda otro hilo. De manera análoga, cuando se realiza una llamada al núcleo ACTIVO se coloca en el estado de DETENIDO hasta que se libera al proceso. Cuando un hilo realiza una operación de bloqueo que no se completa de manera inmediata, el hilo se coloca en el estado de ESPERA hasta que ocurra el evento.
Un hilo puede estar en más de un estado al mismo tiempo. Por ejemplo, un hilo en estado SUSPENDIDO entra posteriormente al estado DETENIDO si su proceso es suspendido. Desde el punto de vista conceptual, cada hilo tiene 3 bits independientes asociados con él, uno para cada uno de los estados SUSPENDIDO, DETENIDO EN ESPERA. El hilo se ejecuta solo cuando los tres bits son igual a cero.
Los hilos de un proceso del núcleo se ejecutan en modo núcleo, y los hilos de un proceso usuario se ejecutan en modo usuario. El núcleo proporciona dos mecanismos de sincronización que utilizan los hilos, el primero es el semáforo tradicional (de conteo), con operaciones UP y DOWN. Estas operaciones siempre se implantan mediante llamadas al núcleo, por lo que son caras. El segundo mecanismo es el mútex, que es en esencia un semáforo pero se restringen sus valores a 0 y 1. Los mútex sólo se utilizan para exclusión mutua.
Un problema que ocurre en todo sistema basado en hilos es la forma de administrar los datos particulares de cada hilo, como su pila. Chorus resuelve este problema asignando dos registros de software especiales a cada hilo. Uno de ellos contiene el apuntador a los datos particulares del hilo cuando está en modo usuario. El otro contiene un apuntador a los datos particulares cuando el hilo ha hecho un señalamiento al núcleo y ejecuta una llamada al núcleo.
Planificación
La planificación de los CPU se realiza mediante el uso de prioridades con base en los hilos. Cada proceso tiene prioridad y cada hilo tiene prioridad relativa dentro de su proceso. La prioridad absoluta de un hilo es la suma de la prioridad de su proceso y su prioridad relativa. El núcleo mantiene un registro de la prioridad de cada hilo en estado ACTIVO y ejecuta el que tiene la máxima prioridad absoluta, en un multiprocesador con k CPU, se ejecutan k hilos con la máxima prioridad.
Para adecuarse a los procesos en tiempo real, se ha agregado una característica adicional al algoritmo. Se hace una distinción entre los hilos cuya prioridad está por arriba de cierto nivel y los hilos con una prioridad por debajo de este.

Señalamientos, excepciones e interrupciones
El software de Chorus distingue 3 tipos de entrada al núcleo.
Los señalamientos son llamadas intencionales al núcleo o a un subsistema para llamar a servicios. Los programas causan señalamientos llamando a un procedimiento de biblioteca para una llamada al sistema. El sistema soporta dos formas de manejo de señalamientos. En la primera, todos los señalamientos de un vector de señalamientos particular van a un hilo del núcleo que previamente ha anunciado su disposición para manejar ese vector. En la segunda forma, cada vector de señalamientos se une con un arreglo de hilos del núcleo, y el supervisor de Chorus utiliza el contenido de cierto registro para formar un índice de arreglo y elegir un hilo. El segundo mecanismo permite que todas las llamadas al sistema utilicen el mismo vector de señalamientos, de modo que se utilice e numero de la llamada al sistema que va al registro para seleccionar un controlador.
Las excepciones son eventos inesperados que son causados por accidente, como la excepción de división entre cero, el desbordamiento de punto flotante, o un fallo de página. Es posible hacer que un hilo del núcleo sea llamado para manejar una excepción. Si el controlador puede terminar el procesamiento, regresa un código especial y concluye el manejo de la excepción, en caso contrario, el núcleo suspende al hilo que causó la excepción y envía un mensaje a un puerto especial para el manejo de excepciones asociado con el proceso del hilo.
Las interrupciones son causadas por eventos asíncronos, como las marcas del reloj o la terminación de una solicitud de E/S. Estas no necesariamente están relacionadas con algo realizado por el hilo activo, por lo que no es posible permitir que el hilo las maneje. En vez de ello, es posible arreglar de antemano que cuando ocurra una interrupción en cierto vector de interrupciones (un dispositivo especifico), se cree un nuevo hilo del núcleo, de manera espontanea para procesarlo. Los hilos con interrupciones pueden llamar solamente a un conjunto limitado de servicios del núcleo puesto que el sistema está en un estado desconocido cuando se inicia. Todo lo que pueden, son operaciones sobre semáforos y mútex, o enviar mini mensajes a mini puertos especiales.
Llamadas al núcleo para la administración de procesos
La mejor forma para ver lo que un núcleo o un sistema operativo realiza, es examinar su interfaz, es decir, las llamadas a sistema que proporciona a sus usuarios. Llamada | Descripción | actorCreate | Crea un nuevo proceso | ActorDelete | Elimina un proceso | actorStop | Detiene un proceso, coloca sus hilos en estado detenido | actorStart | Reinicia un proceso desde el estado detenido | actorPriority | Obtiene o configura la prioridad de un proceso | actorExcept | Obtiene o configura el puerto utilizado para el manejo de excepciones |

ActorCreate crea un proceso nuevo y regresa la posibilidad de ese proceso a quien hizo la llamada. El proceso nuevo hereda la prioridad, el identificador de protección y el puerto de excepción del proceso padre. Los parámetros especifican si el proceso nuevo será un proceso usuario, del sistema o del núcleo e indica el estado en el que comienza. Justo después de la creación, el proceso nuevo está vacío, sin hilos ni regiones y con un puerto, el puerto por omisión.
ActorDelete elimina un proceso, el proceso por eliminar se especifica mediante la posibilidad transferida como parámetro.
ActorStop congela un proceso, colocando todos sus hilos en estado de DETENIDO, los hilos se ejecutan de nuevo cuando se hace una llamada a ActorStart. Un proceso se detiene a si mismo, estas llamadas se utilizan por lo general para una depuración.
ActorPriority permite que un proceso lea la prioridad del otro proceso y, opcionalmente, que le de un valor nuevo. Aunque Chorus es por lo general transparente con respecto de la posición, no es perfecto.
ActorExcept se utiliza para obtener o modificar el puerto de excepción para quien hizo la llamada o algún otro proceso para el que, quien hizo la llamada, tenga una posibilidad, también se utiliza para eliminar el puerto de excepción, en cuyo caso su hay que enviar una excepción al proceso, éste se elimina.
El siguiente grupo de llamadas al núcleo se relacionan con los hilos. Llamada | Descripción | threadCreate | Crea un hilo nuevo | threadDelete | Elimina un hilo | threadSuspend | Suspende un hilo | threadResume | Reinicia un hilo suspendido | threadPriority | Obtiene o configura la prioridad de un hilo | threadLoad | Obtiene el apuntador al contexto al hilo | threadStore | Configura el apuntador al contexto del hilo | threadContext | Obtiene o configura el contexto de ejecución de un hilo |

Las operaciones de sincronización son las siguientes, se dispone de llamadas para iniciar, adquirir y liberar mútex y semáforos. Funcionan de manera usual. Llamada | Descripción | mutexInit | Inicia un mútex | mutexGet | Intenta adquirir un mútex | mutexRel | Libera un mútex | semInit | Inicia un semáforo | semP | Realiza un DOWN sobre un semáforo | semV | Realiza un UP sobre un semáforo |

Administración de memoria en Chorus
La administración de memoria en Chorus recupera varias ideas de Mach. Sin embargo también contiene ciertas ideas no contenidas en Mach.
Regiones y Segmentos
Los conceptos principales detrás de la administración de memoria en Chorus son las regiones y los segmentos. Una Región es un rango adyacente de direcciones virtuales, por ejemplo de 1024 a 6143. En teoría, una región puede comenzar o terminar en cualquier dirección virtual, pero para hacer algo útil, debe de estar alineada con respecto de las páginas y tener una longitud igual a cierto numero entero de paginas. Todos los bytes de una región tienen las mismas características de protección. Las regiones son una propiedad de los procesos y todos los hilos de un proceso ven las mismas regiones. Dos regiones del mismo proceso no deben traslaparse.
Un Segmento es una colección adyacente de bytes que reciben el nombre y la protección de una posibilidad. Los archivos y las áreas de intercambio son los tipos más comunes de segmentos. Los segmentos se pueden leer o escribir en ellos utilizando llamadas al sistema que proporcionan la posibilidad, el desplazamiento, el número de bytes, el buffer y la dirección de transferencia del segmento. Estas llamadas se utilizan para realizar las operaciones tradicionales de E/S sobre los archivos.
Sin embargo otra posibilidad consiste en asociar segmentos a regiones. No es necesario que un segmento tenga el tamaño exacto de una región. Si el segmento es mayor que la región, solo una parte del segmento será visible en el espacio de direcciones, aunque se puede cambiar de porción visible mediante una reasociación. Si el segmento es menor que la región, el resultado de la lectura de una dirección no asociada es trabajo del asociador. El núcleo soporta segmentos especiales de E/S para el acceso a los registros de E/S de la maquina en maquinas con registros de dispositivos asociados con memoria. Al utilizar estos segmentos, los hilos del núcleo pueden realizar E/S leyendo o escribiendo de manera directa en la memoria.

Asociadores
Chorus soporta paginadores externos del estilo de Mach, llamados Asociadores. Cada asociador controla uno o más segmentos que son asociados con regiones, un segmento se asocia con varias regiones, incluso en diferentes espacios de direcciones al mismo tiempo,
El administrador de la memoria virtual en cada núcleo mantiene un caché de página y lleva un registro de la página correspondiente a cada segmento. Las páginas en el caché local pertenecen a segmentos con nombre, como archivo, o sin nombre, como las áreas de intercambio. El núcleo lleva un registro de las páginas limpias y sucias. Pueden descartar las páginas limpias a voluntad, pero regresa las páginas sucias a los asociadores adecuados para reclamar su espacio.
Cuando un asociador recibe la solicitud, verifica si la pagina necesaria está en su caché (en su espacio de direcciones). Sino, envía un mensaje al hilo que controla el disco para realizar una E/S y recuperar la página. Cuando llega la página (o si ya estaba presente) el asociador informa de esto al núcleo, que entonces acepta la página, ajusta las tablas de página MMU y reasume el hilo fallido.
El asociador también toma la iniciativa y pide al núcleo que le regrese las páginas sucias. Cuando el núcleo las regresa, el asociador conserva alguna de ellas en el caché y escribe otras al disco. Se dispone de varias llamadas para que el asociador especifique las páginas que desea regresar. La mayor parte de los asociadores no llevan un registro de la cantidad de marcos de página que ocupan sus segmentos, puesto que el núcleo es libre de descartar páginas limpias y regresar páginas sucias a sus asociadores cuando el espacio se compacta.
El mismo mecanismo de ocultamiento y administración se utiliza para las páginas que son parte de los segmentos asociados y para las páginas que son escritas y leídas utilizando instrucciones explicitas de E/S de segmentos. Este método garantiza que si un proceso modifica una pagina asociada y escribe en ella, de inmediato otro proceso intenta leer el archivo del que es parte, el segundo proceso obtendrá los nuevos datos, puesto que solo existe una copia de la página en memoria.

Memoria Compartida Distribuida
Chorus soporta la memoria compartida distribuida paginada en el estilo de IVY. Utiliza un algoritmo descentralizado dinámico, lo que significa que diferentes administradores llevan un registro de diferentes páginas y el administrador de una página cambia si la página se mueve a través del sistema (para paginas de escritura).
La unidad para compartir entre las diversas maquinas en el segmento. Los segmentos se dividen en fragmentos de una o más paginas, en cualquier instante, cada fragmento es exclusivo para lectura, y en potencia está presente en varias máquinas; o bien, sirve para lectura y escritura, y solo está presente en una máquina.

Llamadas al núcleo para administración de memoria
La administración de memoria en Chorus soporta 26 llamadas al sistema diferentes, más algunas otras llamadas en asociadores. Llamada | Descripción | RgnAllocate | Asigna una región de memoria y configura sus propiedades | RgnFree | Libera una región previamente asignada | RgnInit | Asigna una región y la asigna mediante un segmento dado | RgnSetInherit | Configura las propiedades hereditarias de una región | RgnSetPaging | Configura las propiedades de paginación de una región | RgnSetProtect | Configura las opciones de protección de una región | RgnStat | Obtiene las estadísticas asociadas con una región |

RgnAllocate especifica una región proporcionando la posibilidad de un proceso, una dirección inicial, un tamaño y varias opciones. Sino existen conflictos con otras regiones ni otros problemas, se crea la región.
RgnFree regresa una región previamente asignada de manera que su porción del espacio de direcciones esté libre para su asignación a su región o a otras regiones.
RgnInit es similar a RgnAllocate, excepto que después de asignar la región, también se llena a partir de un segmento cuya posibilidad es un parámetro de la llamada.
RgnSetInherit se relaciona con la posibilidad de que una región pueda copiarse posteriormente, y especifica si la copia tendrá sus propias páginas o compartirá las páginas de su región original.
RgnSetPaging es utilizada principalmente por los procesos interesados en proporcionar una respuesta en tiempo real y no pueden tolerar fallos de página o los intercambios, también indica lo que debe realizarse si el proceso intenta asignar una región no intercambiable ni paginable que está ya configurada pero sin que se disponga de la memoria suficiente.
RgnSetProtect modifica los bits de lectura/escritura/ejecutable asociados con una región y también puede hacer que una región solo sea accesible al núcleo.
RgnStat regresa al proceso que hizo la llamada el tamaño de una región y más información.

Las llamadas de entrada y salida de segmentos son los siguientes: Llamada | Descripción | sgRead | Lee datos de un segmento | sgWrite | Escribe datos a un segmento | sgStat | Solicita información relativa a un caché de página | sgFlush | Solicitud de un asociador al núcleo pidiendo páginas sucias |

sgRead y sgWrite son las llamadas básicas de E/S que permiten a un proceso leer o escribir en un segmento. El segmento queda especificado por un descriptor, también se proporciona el desplazamiento y el número de bytes, al igual que la dirección del buffer al que se desea copiar. sgStat permite a quien hizo la llamada que por lo general es un asociador, solicitar la información estadística a cerca de un caché de página. sgFlush permiten a los asociadores pedir al núcleo que le envíe páginas para guardarlas en el espacio de direcciones del asociador y escribirlas de nuevo en sus segmentos del disco, éste mecanismo se usa por ejemplo, para garantizar que un grupo de asociadores que juntos soportan la memoria compartida distribuida puedan eliminar las páginas en las que se escriba de todas las máquinas excepto una.
Las siguientes llamadas, son llamadas al asociador , ya sea desde el núcleo o desde un programa de aplicación que solicita al asociador que realice cierta labor para quien hizo la llamada. Llamada | Descripción | MpCreate | Solicitud para crear un segmento para intercambio | MpRelease | Solicitud para liberar un segmento creado con anterioridad | MpPullIn | Solicitud de una o más páginas | MpPushOut | Solicitud para que asociador acepte una o más páginas |

MpCreate se utiliza cuando el núcleo, o un programa intercambian un segmento y necesita asignarle un espacio en disco. Responde asignando un nuevo segmento es disco y regresando una posibilidad para él.
MpRelease regresa un segmento creado mediante MpCreate.
MpPullIn es utilizada por el núcleo para adquirir datos de un segmento recién creado o existente, se pide al asociador responda enviando un mensaje que contiene las paginas necesarias. Si se utiliza una programación MMU hábil, no es necesario copiar físicamente las páginas.
MpPushOut sirve para las transferencias en sentido opuesto, del núcleo al asociador, ya sea en una respuesta a una llamada SgFlush, o cuando el núcleo intercambia un segmento por su cuenta. Comunicación en Chorus
El paradigma básico de comunicación en Chorus es la transferencia de mensajes, durante la era de la versión 1, cuando la investigación se centró en los multiprocesadores, se consideraba el uso de la memoria compartida como el paradigma de comunicación, pero se rechazó por no ser lo bastante general.
Mensajes
Cada mensaje contiene un encabezado (sólo para uso interno del micronúcleo), una parte fija opcional y un cuerpo opcional. El encabezado identifica la fuente y destino y contiene varios identificadores de protección y banderas. La parte fija, sí está presente, siempre tiene una longitud de 64 bytes y está por completo bajo el control del usuario. El cuerpo tiene tamaño variable, con un máximo de 64K bytes, y también está por completo bajo el control del usuario. Desde el punto de vista del núcleo, la parte fija y el cuerpo son arreglos de bytes no tipificados, en el sentido de que el núcleo no se preocupa por lo que contienen.
Cuando se envía un mensaje a un hilo en una máquina diferente, siempre se copia. Cuando se envía un hilo en la misma maquina, existe una opción entre copiarlo en realidad o simplemente asociarlo con el espacio de direcciones del receptor. Si el receptor escribe sobre una página asociada, se crea una copia genuina en ese punto. Cuando un mensaje no tiene un numero entero de páginas pero el mensaje es asociado, solo se perderán algunos datos detrás (o delante) del buffer cuando se asocie la última (o primera) página.
Otra forma de mensaje es el minimensaje, que solo se utiliza entre los procesos del núcleo para los mensajes breves de sincronización, por lo general para indicar la ocurrencia de una interrupción. Los minimensajes se envían a minipuertos especiales de bajo costo.

Puertos
Los mensajes se envían a los puertos, cada uno de los cuales contiene un espacio para guardar un cierto número de mensajes. Si se envía un mensaje a un puerto lleno, el emisor se suspende hasta que se dispone de un espacio suficiente. Al crear un puerto, el proceso que hizo la llamada recibe un identificador único y un identificador local. El identificador único se puede enviar a otros procesos de modo que éstos puedan enviar mensajes al puerto.
Los identificadores locales se utilizan dentro del proceso para hacer referencia de manera directa al puerto. Solo los hilos del proceso que posee en cierto momento al puerto pueden ser leídos de éste (Los puertos pueden emigrar).
Al crear un proceso, obtiene de forma automática un puerto por omisión, utilizado por el núcleo para enviar mensajes de excepción. También crea el número de puertos adicionales necesarios. Estos puertos adicionales se mueven a otros procesos, incluso en otras máquinas. Cuando se mueve un puerto, todos los mensajes que se encuentran se mueven con el. El movimiento de los puertos es útil, por ejemplo cuando un servidor en una máquina se apaga por mantenimiento, permite que otro servidor en una máquina diferente realice su trabajo. De esta manera, los servicios se mantienen de manera transparente, incluso cuando las máquinas servidor se apaguen y posteriormente vuelvan a trabajar.
Chorus proporciona una forma de reunir varios puertos en un grupo de puertos. Para esto, un proceso crea primero un grupo de puertos vacío, y regresa una posibilidad para él. Por medio de ésta posibilidad, puede agregar puertos al grupo y también puede utilizarla para eliminar posteriormente puertos del grupo.
Un puerto puede estar presente en varios grupos de puerto.
Los grupos se utilizan por lo general para proporcionar servicios reconfigurables. En principio, cierto conjunto de servidores pertenecen al grupo, el cual proporciona cierto servicio. Los clientes envían mensajes al grupo sin tener que conocer cuales servidores están disponibles para realizar el trabajo. Posteriormente se pueden unir al grupo otros servidores y los anteriores salen sin perturbar el servicio y sin que los clientes tengan conciencia de que el sistema ha sido reconfigurado.

Operaciones de Comunicación
Chorus proporciona dos tipos de operaciones de comunicación: Envío Asíncrono y RPC.
El envío asíncrono permite que un hilo solo envíe mensaje a un puerto. No existe garantía de que el mensaje llegue a su destino y no existe una notificación si algo sale mal. Ésta es la forma más pura de datagrama y permite que los usuarios construyan patrones de comunicación arbitrarios utilizando Chorus.
La otra operación de comunicación es la RPC, cuando un proceso ejecuta una operación de RPC, se bloquea en forma automática hasta que llega la respuesta o expira el cronómetro de la RPC, en cuyo momento se elimina el bloqueo del emisor. Se garantiza que el mensaje que elimina el bloqueo del emisor es la respuesta a la solicitud. Cualquier mensaje que no incluya el identificador de transacción de la RPC se guardará en el puerto para su consumo posterior pero no despertará al emisor.
Las RPC utilizan una semántica “a lo más una vez” lo que significa que en el caso de una comunicación no recuperable o una falla de procesamiento, el sistema garantiza que una RPC regresará un código de error en vez de intentar la ejecución más de una vez.
También es posible enviar un mensaje a un grupo de puertos, se dispone de varias opciones. Estas opciones determinan la cantidad de mensajes que se envían y a cuales puertos.
Los envíos a grupos de puertos utilizan el envío asíncrono, los envíos de transmisión (a todos los miembros) no son controlados por el flujo. Si se requiere un control del flujo, debe ser proporcionado por el usuario.
Para recibir un mensaje, un hilo hace una llamada al núcleo indicando el puerto donde desea recibirlo. Si se dispone de un mensaje, la parte fija de éste se copia en el espacio de direcciones de quien hizo la llamada, y el cuerpo, si existe, se copia o se asocia, según las opciones. Sino se dispone de un mensaje, el hilo se suspende hasta que llega un mensaje y expira un cronometro especificado por el usuario.
Un proceso especifica lo que desea recibir de alguno de los puertos que posee, sin importarle cual. Esta opción puede refinarse aún más, deshabilitando alguno de los puertos, en cuyo caso solo los puertos habilitados pueden satisfacen a la solicitud. Los puertos tienen asignadas prioridades, si mas de un puerto habilitado tiene un mensaje, se selecciona el puerto habilitado con mayor prioridad, se habilitan de manera dinámica y se modifican las prioridades a voluntad.

Llamadas al Núcleo Para la Comunicación
Las llamadas que se hacen al núcleo para administrar los puertos son las siguientes:
Las primeras cuatro llamadas son directas y permiten crear, destruir, habilitar y deshabilitar puertos. La última especifica un puerto y un proceso. Cuando concluye la llamada, el puerto ya no pertenece a su propietario original (que no tiene que ser quien hizo la llamada), sino al proceso objetivo. Solo él podrá leer ahora los mensajes del puerto. Llamada | Descripción | portCreate | Crea un puerto y regresa su posibilidad | portDelete | Destruye un puerto | portEnable | Habilita un puerto de modo que sus mensajes cuenten con una recepción de todos los puertos | portDisable | Inhabilita un puerto | portMigrate | Mueve un puerto a otro proceso |

Existen tres llamadas para la administración de grupos de puertos, son las siguientes: Llamada | Descripción | grpAllocate | Crea un grupo de puertos | grpPortInsert | Agrega un nuevo puerto a un grupo de puertos existentes | grpPortRemove | Elimina un puerto de un grupo de puertos |

grpAllocate crea un grupo de puertos y regresa una posibilidad para el grupo quien hizo la llamada. Por medio de esta posibilidad, quien hizo la llamada o cualquier otro proceso que posteriormente adquiera la posibilidad puede agregar o eliminar puertos del grupo.
El último grupo de llamadas al núcleo maneja el envío y la recepción reales de los mensajes: Llamada | Descripción | ipcSend | Envía un mensaje de manera asíncrona | ipcReceive | Se bloquea hasta que llega un mensaje | ipcGetData | Obtiene el cuerpo del mensaje actual | ipcReply | Envía respuesta al mensaje actual | ipcCall | Realiza una llamada a un procedimiento remoto |