SistemasOperativosDistribuidos(Orsi Gongora 6551)

SISTEMAS OPERATIVOS DISTRIBUIDOS 7 de abril de 2010

Tecnológico de Estudios Superiores de Ecatepec

Licenciatura en Informática

Sistemas Operativos I

SISTEMAS OPERATIVOS DISTRIBUIDOS

Investigación de las características de los Sistemas Operativos Mach,Chorus y Amoeba

Nombre:

Orsi Góngora Díaz

Grupo: 6551

Profesora:

Claudia Moran Sánchez


Ecatepec de Morelos, Estado de México Abril 7 de 2010.

INTRODUCCION

Un sistema distribuido es una colección de computadoras independientes que aparecen ante los usuarios del sistema coma una única computadora.

La razón numero uno de la tendencia hacia los sistemas distribuidos es que estos sistemas tienen en potencia una proporción precisión/desempeño mucho mejor que la de un sistema centralizado.

Los sistemas operativos no se pueden clasificar tan fácil como el hardware. Por su propia naturaleza, el software es vago y amorfo. Aun así, es más o menos posible distinguir dos tipos de sistemas operativos para los de varios CPU: los débilmente acoplados y los fuertemente acoplados.

El software débilmente acoplado permite que las maquinas y los usuarios de un sistema distribuido estén independientes entre sí en lo fundamental, pero que interactúen en cierto grado cuando sea necesario.

Consideremos un grupo de computadoras personales, cada una de las cuales tiene su propio CPU, su propia memoria, su propio disco duro y su propio sistema operativo, pero que comparten ciertos recursos, coma las impresoras laser y las bases de datos en una LAN. Este sistema esta débilmente acoplado, puesto que las maquinas individuales se distinguen con claridad, cada una de las cuales tiene su propio trabajo por realizar. Si la red falla por alguna razón, las maquinas individuales continúan su ejecución en cierto grado considerable, aunque se puede perder cierta funcionalidad (por ejemplo, la capacidad de imprimir archivos).Para mostrar lo difícil que resulta establecer definiciones en esta área, consideremos ahora el mismo sistema anterior, pero sin la red. Para imprimir un archivo, el usuario escribe un archivo en un disco flexible, lo lleva hasta la maquina que tiene la impresora, lo lee en ella y después lo imprime. ¿Es todavía un sistema distribuido, solo que ahora mas débilmente acoplado? Esto es difícil de decir. Desde un punto de vista fundamental, no existe una diferencia real entre la comunicación a través de una LAN y la comunicación mediante el traslado físico de los discos flexibles. Lo más que se puede decir es que las tasas de retraso y transmisión de los datos son peores en el segundo ejemplo.

En el otro extremo, podríamos tener el caso de un multiprocesador dedicado a la ejecución de un programa de ajedrez en paralelo. A cada CPU se le asigna un tablero para su evaluación y este ocupa su tiempo en la evaluación de este tablero y los que se pueden generar a partir de e1. Al terminar la evaluación, el CPU informa de sus


resultados y se le proporciona un nuevo tablero para trabajar con 61. El software para este sistema, es decir, el programa de aplicación y el sistema operativo necesario para soportarlo, están mejor acoplados que el ejemplo anterior.

Los sistemas distribuidos constan de CPU autónomos que funcionan juntos para que todo el sistema parezca como una computadora. Tienen varios puntos favorables potenciales, como buena proporción, precio/desempeño, se pueden ajustar bien a las aplicaciones distribuidas, pueden ser muy confiables y pueden aumentar su tamaño de manera gradual al aumentar la carga de trabajo. También tienen ciertas desventajas, como el hecho de tener un software más complejo, potenciales cuellos de botella en la comunicación y una seguridad débil. Sin embargo, existe un considerable interés mundial por su construcción e i instalación.

Los modernos sistemas de computó tienen con frecuencia varios CPU. Estos se pueden organizar como multiprocesadores (con memoria compartida) o como multicomputadoras (sin memoria compartida). Ambos tipos se pueden basar en un bus o en un conmutador. Los primeros tienden a ser fuertemente acoplados, mientras que los segundos tienden a ser débilmente acoplados.

El software para los sistemas con varios CPU se pueden dividir en tres clases. Los sistemas operativos de red permiten a los usuarios en estaciones de trabajo independientes la comunicación por medio de un sistema compartido de archivos, pero dejan que cada usuario domine su propia estación de trabajo. Los sistemas operativos distribuidos convierten toda la colección de hardware y software en un sistema integrado, muy parecido a un sistema tradicional de tiempo compartido. Los multiprocesadores con memoria cornpartida también ofrecen la imagen de único sistema, pero lo hacen mediante la vía de centralizar todo, por lo que en realidad, este caso es un sistema. Los multiprocesadores con memoria compartida no son sistemas distribuidos.


Los sistemas distribuidos deben diseñarse con cuidado, puesto que existen muchas trampas para los incautos. Un aspecto clave es la transparencia: ocultar la distribución a los usuarios e incluso a los programas de aplicación. Otro aspecto es la flexibilidad. Puesto que el campo se encuentra todavía en su infancia, el diseño se debe hacer con la idea de facilitar los cambios futuros. A este respecto, los micro núcleos son superiores a los núcleos monolíticos. Otros aspectos importantes son la confiabilidad, el desempeño y la escalabilidad.


AMOEBA

Amoeba es un nuevo sistema operativo diseñado para hacer que una colección de computadoras independientes aparezca ante sus usuarios como un sistema de tiempo compartido. En general, los usuarios no están conscientes del sitio donde se ejecutan sus procesos (o incluso el tipo de CPU utilizado), ni del sitio donde se almacenan sus archivos o las copias de ellos mantenidas por razones de disponibilidad y desempeño. Sin embargo, los usuarios explícitamente interesados en la programación paralela pueden explotar la existencia de varios CPU mediante la subdivisión de un solo trabajo en varias maquinas.

Amoeba se basa en un micronúcleo que controla los procesos de bajo nivel, la administración de la memoria, la comunicación y la EIS. El sistema de archivos y el resto del sistema operativo se pueden ejecutar coma procesos usuario. Esta división del trabajo mantiene el núcleo pequeño y sencillo.

Amoeba tiene un mecanismo para nombrar y proteger a todos los objetos: las posibi-lidades. Cada posibilidad contiene los derechos que indican las operaciones permitidas mediante su uso. Las posibilidades se protegen por cifrado mediante las funciones de un solo sentido. Cada una contiene un campo para la suma de verificación, la cual garantiza la seguridad de la posibilidad.

Se soportan tres mecanismos de comunicación: RPC y FLIP simple para la comunicación puntual y la comunicación confiable en grupo para la comunicación entre varias partes. La RPC garantiza una semántica "al menos una vez". La comunicación en grupo se basa en la transmisión confiable proporcionada por el algoritmo del secuenciador. Ambos mecanismos se soportan sobre el protocolo FLIP y están fuertemente integrados. El FLIP simple solo se utilize en circunstancias especiales.

El sistema de archivos de Amoeba consta de tres servidores: el servidor de archivos para el almacenamiento de estos, el servidor de directorios para otorgar hombres y el servidor de replicas para la réplica de archivos. El servidor de archivos mantiene archivos inmutables que se almacenan en bloques adyacentes, en el disco y en el cache. El servidor de directorios es un servidor tolerante de fallas que asocia cadenas en ASCII con las posibilidades. El servidor de replicas controla la replica retrasada.

El objetivo principal del proyecto era construir un sistema operativo distribuido y trans-parente. Para el usuario promedio, el uso de Amoeba es igual al uso de un sistema


tradicional de tiempo compartido, como UNIX. Uno entra, edita y compila los programas, mueve archivos de un lugar a otro, etc. La diferencia es que cada una de estas acciones pace uso de varias maquinas, dispersas en la red. Entre estas maquinas están los servidores de procesos, los de archivos, los de directorios, los de computó y otros, pero el usuario no es consciente de ello. En la terminal, todo parece como un sistema ordinario de tiempo compartido.

Una distinción importante entre Amoeba y la mayoría de los demás sistemas distribui-dos es que Amoeba no tiene el concepto de "maquina de origen". Cuando un usuario entra al sistema, entra a este como un todo y no a una maquina especifica. Las maquinas no tienen propietarios. El shell inicial, que se ejecuta al entrar el usuario, se ejecuta en cierta maquina arbitraria, pero al ser iniciados los comandos, en general no se ejecutan en la misma máquina donde se ejecuta el shell. En vez de esto, el sistema busca de manera automática la maquina con la menor carga para ejecutar cada nuevo comando. Durante el curso de una larga sesión en la terminal, los procesos que se ejecutan a cargo de un usuario cualquiera estarán más o menos dispersos en todas las maquinas del sistema, dependiendo de la carga, por supuesto.

En otras palabras, todos los recursos pertenecen al sistema como un todo y son contro-lados por él. No están dedicados a usuarios específicos, excepto por periodos cortos para la ejecución de procesos individuales.

La arquitectura del sistema Amoeba

Amoeba se diseño con dos hipótesis respecto al hardware:

1. Los sistemas tienen un número muy grande de CPU.

2. Cada CPU tendrá decenas de megabytes de memoria.

La fuerza motriz detrás de la arquitectura del sistema es la necesidad de incorporar un gran número de CPU de manera directa. En otras palabras, qué hacer si cada usuario puede disponer de 10 a 100 CPU? Una solución consiste en darle a cada usuario un multiprocesador personal de 10 o 100 nodos.

Amoeba se basa en el modelo que se muestra en la figura 7-1. En este modelo, todo el poder de cómputo se localiza en una o más pilas de procesadores. Una pila de procesadores consta de varios CPU, cada uno con su propia memoria local y conexión a la red. No se necesita la memoria compartida, ni siquiera se espera que exista; pero si está presente, se le utiliza para optimizar la transferencia de mensajes al hacer el copiado de una memoria a otra, en vez de enviar mensajes a través de la red.


Amoeba esta diseñado de forma que pueda trabajar con varias arquitecturas y sistemas heterogéneos. Incluso es posible que los hijos de un proceso se ejecuten en arquitecturas diferentes.

La pila de procesadores no es "poseída" por usuario alguno. Cuando un usuario escribe un comando, el sistema operativo asigna en forma dinámica uno o más procesadores para ejecutar ese comando. Al terminar el comando, se terminan los procesos y los recursos regresan a la pila, en espera del siguiente comando, que muy probablemente sea de un usuario diferente. Si existe una reducción en el número de procesadores en la pila, se comparte el tiempo de los procesadores individuales, de modo que los nuevos procesos lean asignados al CPU con menor carga. El punto importante en este momento es que este modelo es un poco distinto de los sistemas actuales, donde cada usuario tiene exactamente una estación de trabajo para todas sus actividades de cómputo.

El segundo elemento de la arquitectura de Amoeba es la terminal. El usuario tiene acceso al sistema a través de la terminal. Una terminal usual de Amoeba es la terminal X, con una pantalla de gran tamaño (con un mapa de bits) y un ratón. Otra alternativa consiste en que también se pueda utilizar como terminal una computadora personal o una estación de trabajo que ejecute ventanas X. Aunque Amoeba no prohíbe la ejecución de los programas del usuario en la terminal, la idea detrás de este modelo es proporcionar a los usuarios terminales relativamente baratas y concentrar los ciclos de cómputo en una pila común para utilizarlos con mayor eficiencia.

Otro componente importante de la configuración de Amoeba son los servidores espe-cializados, como los servidores de archivos, que por razones de hardware o software necesitan ejecutarse en un procesador aparte. En ciertos casos, es posible que un servidor se ejecute en un procesador de la pila, para que se inicie cuando sea necesario, pero por razones de desempeño es mejor que se ejecute todo el tiempo.


El micronúcleo de Amoeba

Amoeba consta de dos partes fundamentales: un micronúcleo que se ejecuta en cada procesador, y una colección de servidores que proporcionan la mayor parte de la funcionalidad de un sistema operativo tradicional. La estructura general se muestra en la figura 7-2.

El micronúcleo de Amoeba se ejecuta en todas las maquinas del sistema. El mismo núcleo se utiliza en los procesadores de la pila, las terminales (suponiendo que sean computadoras en vez de terminales X) y los servidores especializados. El micronúcleo tiene cuatro funciones basicas:

1. Controlar los procesos e hilos.2. Proporcionar el soporte de la administración de memoria de bajo nivel.

3. Soporta la comunicación.

4. Controlar la EIS de bajo nivel.

Amoeba soporta también varios hilos de control dentro de un espacio de direcciones. Un proceso con un hilo es en esencia igual a un proceso en UNIX. Tal proceso tiene un espacio de direcciones, un conjunto de registros, un contador del programa y una pila.


La segunda tarea del núcleo es proporcionar la administración de la memoria de bajo nivel. Los hilos pueden asignar o eliminar la asignación de los bloques de memoria, llamados segmentos. Estos segmentos se pueden leer o escribir y ser asociados o desasociados al espacio de direcciones del proceso al cual pertenece el hilo que realiza la Ramada. Un proceso debe poseer al menos un segmento, pero también puede tener varios. Los segmentos se pueden utilizar para el texto, los datos, la pila o para cualquier otro fin que desee el proceso. El sistema operativo no obliga a utilizar algún patrón particular de uso de los segmentos.

La tercera tarea del núcleo es controlar la comunicación entre los procesos. Se dispone de dos formas de comunicación: puntual y de grupo. Ambas están muy integradas entre sí, de modo que sean lo más parecidas posible.

La cuarta función del núcleo es la administración de la E/S de bajo nivel. Para cada dispositivo de E/S conectado a una maquina, existe un controlador del dispositivo en el núcleo. Este controlador se encarga de toda la E/S del dispositivo. Los controladores están ligados con el núcleo y no se pueden cargar de manera dinámica.

Los servidores de AmoebaTodo lo que no se lleva a cabo dentro del núcleo lo realizan los procesos servidores. La idea detrás de este diseño es minimizar el tamaño del núcleo y rnejorar la flexibilidad. Como el sistema de archivos y otros dispositivos estándar no se integran al nivel, estos se pueden modificar con facilidad y se pueden ejecutar en forma simultánea varias versiones para las distintas poblaciones de usuarios.

Objetos y Posibilidades en Amoeba

Objetos

El concepto básico y unificador subyacente en todos los servidores de Amoeba y los servicios que estos proporcionan es el objeto. Un objeto es una pieza encapsulada de datos en la que se pueden llevar a cabo ciertas operaciones bien definidas. Es en esencia, un tipo de dato abstracto. Los objetos son pasivos. No contienen procesos o métodos o alguna otra entidad activa que "haga" cosas; en Lugar de esto, cada objeto es controlado por un proceso servidor.

Posibilidades

Los objetos reciben su nombre y protección de manera uniforme mediante boletos especiales llamados posibilidades. Para crear un objeto, un cliente real iza una RPC


con el servidor apropiado, donde indica lo que desea. El servidor crea entonces el objeto y regresa una posibilidad al cliente. En las operaciones siguientes, el cliente debe presentar la posibilidad para identificar al objeto. Una posibilidad no es más que un número binario de gran tamaño.

Administración de Procesos en Amoeba

Un proceso en Amoeba es básicamente un espacio de direcciones y una colección de hilos que se ejecutan en el. Un proceso con un hilo es muy semejante a un proceso en UNIX o en MS-DOS, en términos de su comportamiento o su función. En esta sección explicaremos el funcionamiento de los procesos e hilos y la forma de implantarlos.

Un proceso es un objeto en Amoeba. Al crear un proceso, el proceso padre obtiene una posibilidad para el proceso hijo, al igual que con cualquier otro objeto recién creado. Mediante esta posibilidad, el hijo se puede suspender, reiniciar o destruir.

Amoeba permite crear un proceso nuevo en un procesador específico donde la supuesta imagen en memoria comience justo al principio.

La administración de procesos es controlada en tres niveles distintos en Amoeba. En el nivel inferior están los servidores de procesos, hilos del núcleo que se ejecutan en cada una de las maquinas. Para crear un proceso en una máquina dada, otro proceso realiza una RPC con el servidor de procesos de esa máquina, proporcionando la información necesaria.En el siguiente nivel tenemos un conjunto de procedimientos de biblioteca que propor-cionan una interfaz más conveniente para los programas del usuario. Se tienen distintos gustos. Hacen su trabajo al Ilamar a los procedimientos de interfaz de bajo nivel.Por último, la forma más sencilla de crear un proceso es utilizar el servidor de ejecución, que hace la mayor parte del trabajo para determinar el lugar donde se ejecuta el nuevo proceso.

Administration de Memoria en Amoeba

Amoeba tiene un modelo de memoria en extremo sencillo. Un proceso puede tener el número de segmentos que desee y éstos se pueden local izar en cualquier parte del espacio de direcciones virtuales del proceso. Los segmentos no se intercambian ni se paginan, por lo que un proceso debe estar por completo contenido en la memoria


para su ejecución. Además, aunque se utiliza el hardware MMU, cada segmento se almacena de manera adyacente a los demás en la memoria.

La segunda razón para este diseño es la sencillez. El hecho de no utilizar el intercambio o la paginación hace más sencillo al sistema y hace que el núcleo sea más pequeño y controlable.

La memoria será tan barata que, al cabo de pocos años, es probable que todas las maquinas Amoeba tengan cientos de megabytes de la misma.

Comunicación en Amoeba

Amoeba soporta dos formas de comunicación: RPC mediante Ia transferencia puntual de mensajes y la comunicación en grupo. En el nivel más bajo, una RPC consta de un mensaje de solicitud seguido de un mensaje de respuesta. La comunicación en grupo utiliza la transmisión en hardware o multitransmisión si se dispone de esta; en caso contrario, la simula de manera transparente mediante mensajes individuales


MACH

Mach es un sistema operativo basado en un micronúcleo. Se diseño con el fin de pro-porcionar una base para la construcción de nuevos sistemas operativos y la emulación de los ya existentes. También proporciona una forma flexible de extender UNIX a los multiprocesadores y los sistemas distribuidos. Mach se basa en los conceptos de procesos, hilos, puertos y mensajes. Un proceso en Mach es un espacio de direcciones y una colección de hilos que se ejecutan en el. Las entidades activas son los hilos. El proceso es simplemente un recipiente para ellos. Cada proceso e hilo tiene un puerto al que se puede escribir para hacer que las Ilamadas al núcleo se lleven a cabo, lo que elimina la necesidad de las llamadas directas al sistema.

Mach tiene un sistema de memoria virtual muy elaborado, con objetos de memoria que se pueden asociar o desasociar de los espacios de direcciones, respaldado por administradores de memoria externos a nivel usuario. De esta forma, se puede escribir o leer de los archivos en forma directa, por ejemplo. Los objetos de memoria se pueden compartir de varias maneras, entre las cuales se encuentra el copiado durante la escritura. Los atributos de herencia determinan las partes del espacio de direcciones de un proceso que deben transferirse a sus hijos.

La comunicación en Mach se basa en los puertos, objetos del núcleo que contienen mensajes. Todos los mensajes se dirigen a los puertos, a los cuales se tiene acceso mediante las posibilidades; estas se almacenan dentro del núcleo y se hace referencia a ellas mediante enteros de 32 bits, que son por lo general índices a listas de posibilidades. Los puertos se pueden transferir de un proceso a otro al incluirlos en los mensajes complejos.

La emulación del UNIX BSD se realiza mediante una biblioteca de emulación que vive en el espacio de direcciones de cada proceso UNIX. Su trabajo es capturar las


llamadas al sistema reflejadas hacia ella por el núcleo y transferirlas al servidor UNIX para que se Ileven a cabo. Unas cuantas Ilamadas se controlan en forma local, dentro del espacio de direcciones del proceso. Se estan desarrollando otros emuladores de UNIX.

Amoeba y Mach tienen muchos aspectos en común, pero también varias diferencias. Ambos tienen procesos e hilos y se basan en la transferencia de mensajes. Amoeba tiene como primitiva a la transmisión confiable, mientras que Mach no; pero Mach tiene paginación según la demanda, y Amoeba no. En general, Amoeba esta mas orientado a hacer que una colección de maquinas distribuidas actúe como una computadora, mientras que Mach esta mas orientado hacia el use eficaz de los multiprocesadores. Ambos se están desarrollando de manera continua y sin duda se verán modificados con el curso del tiempo.

Objetivos de Mach

Los actuales objetivos principales de Mach se pueden resumir de la manera siguiente:

1. Proporcionar una base para la construcción de otros sistemas operativos (por ejemplo,

UNIX).

1. Soporte de un espacio de direcciones ralo y de gran tamaño.

2. Permitir el acceso transparente a los recursos de la red.

3. Explotar el paralelismo tanto en el sistema como en las aplicaciones.

4. Racer que Mach se pueda transportar a una colección más grande de maquinas.

El micronúcleo de Mach

El micronúcleo de Mach se diseño como base para emular UNIX y otros sistemas operativos. La emulación se lleva a cabo mediante una capa del software que se ejecuta fuera del núcleo, en el espacio del usuario, como se muestra en la figura 8-1. Cada emulador consta de una parte que está presente en el espacio de direcciones de los programas de aplicación, así como uno o más servidores que se ejecutan de manera independiente a los programas de aplicación. Hay que observar que se pueden ejecutar varios emuladores al mismo tiempo, por lo que es posible ejecutar programas en 4.3BSD, el Sistema V y MS-DOS, en la misma máquina al mismo tiempo.


El núcleo de Mach, al igual que otros micronúcleos, proporciona la administración de procesos, la administración de la memoria, la comunicación y los servicios de EIS. Los archivos, directorios y demás funciones tradicionales del sistema operativo se controlan el espacio del usuario. La idea subyacente en el n6cleo de Mach es proporcionar los mecanismos necesarios para que el sistema funcione, pero dejando Ia politica a los procesos a nivel usuario.

El núcleo controla cinco abstracciones principales:

1. Procesos.2. Hilos.2. Objetos de la memoria.3. Puertos.4. Mensajes.

El servidor BSD UNIX de Mach

Esta estructura tiene varias ventajas significativas sobre un núcleo monolítico. En primer lugar, al separar sistema en una parte que controla la administración de los recursos (el núcleo) y otra que controla las llamadas al sistema (el servidor de UNIX), ambas partes son más sencillas y fáciles de mantener.

En segundo lugar, al colocar a UNIX en el espacio del usuario, puede hacerse muy independiente de la maquina, mejorando con ello su portabilidad a una amplia gama de computadoras. Todas las dependencias de la maquina se pueden eliminar de UNIX y ocultarse en el núcleo de Mach.

En tercer lugar, como hemos mencionado, se pueden ejecutar varios sistemas


operativos en forma simultánea.

En cuarto lugar, se puede añadir al sistema la operación en tiempo real, puesto que todos los obstáculos tradicionales que UNIX presenta en el trabajo en tiempo real, como la desactivación de interrupciones para la actualización de las tablas críticas se eliminan en su conjunto o se desplazan al espacio del usuario. El núcleo se puede estructurar con cuidado para no tener este tipo de dificultades en las aplicaciones de tiempo real.

Por último, este orden se puede utilizar para proporcionar una mayor seguridad entre los procesos, en caso necesario. Si cada proceso tiene su propia versión de UNIX, es muy difícil que un proceso pueda husmear en los archivos de otro proceso.

Administracion de Procesos en MACH

La administración de los procesos en Mach se encarga de los procesos, los hilos y la planificación.

Un proceso en Mach consta principalmente de un espacio de direcciones y una colección de bits que se ejecutan en ese espacio de direcciones. Los procesos son pasivos. La ejecución se asocia con los hilos. Los procesos se utilizan para recolectar en recipientes convenientes todos los recursos relacionados con un grupo de hilos que cooperan entre sí.


Las entidades activas en Mach son los hilos. Estos ejecutan instrucciones y controlan sus registros y espacio de direcciones. Cada hilo pertenece con exactitud a un proceso. Este no puede Ilevar nada a cabo si no tiene uno o más hilos. Todos los hilos de un proceso comparten el espacio de direcciones y todos los recursos a todo lo ancho del proceso

La planificación de Mach se ha vista muy influida por su objetivo de ejecución en multiprocesadores. Puesto que un sistema con un procesador es en realidad un caso particular de un multiprocesador (con un CPU), nuestro análisis se centra en la planificación en sistemas de multiprocesadores. La planificación de los hilos en Mach se basa en las prioridades. Las prioridades son números de 0 hasta un número máximo (por lo general, 31 o 127), donde 0 representa la máxima prioridad y 31 o 127 la mínima.

Administracion de procesos en Mach

Mach tiene un poderoso sistema para la administración de la memoria, muy elaborado y muy flexible, basado en la paginación, con características que se encuentran poco en otros sistemas operativos.

En particular, separa las partes independientes de la máquina de dicho sistema para la administración de la memoria de las partes dependientes de la máquina, de manera poco usual pero en extremo clara. Esta separación hace que la administración de la memoria sea más portable que en otros sistemas

El aspecto de la administración de memoria de Mach que establece la diferencia con los demás es que el código se divide en tres partes. La primera es el módulo pmap, que se ejecuta en el núcleo y se encarga del manejo del MMU. Configura los registros de MMU y las tablas de páginas del hardware, además de capturar todos los fallos de página. Este código depende de la arquitectura MMU y debe ser escrito de nuevo para cada una de las maquinas nuevas a las que se traslade Mach. La segunda parte es el c6digo del núcleo independiente de la maquina, encargado del procesamiento de los fallos de pagina, el manejo de los mapas de direcciones y el reemplazo de páginas. La tercera parte del código de administración de la memoria se ejecuta como proceso usuario Ilamado administrador de la memoria o a veces paginado externo. Controla la parte lógica (en contraposición a la parte física) del sistema para la administración de memoria, principalmente el manejo de los espacios de respaldo (disco).


Cada proceso tiene con exactitud una lista de posibilidades. Cuando un bit pide al núcleo crear un puerto para él, el núcleo lo hace e introduce una posibilidad para el hilo en la lista de posibilidades del proceso al que pertenece el hilo.

Comunicación en Mach

El objetivo de la comunicación en Mach es soportar una gama de estilos de comunicación de manera confiable y flexible.

Controla la transferencia asíncrona de mensajes, RPC, flujos de bytes y otras formas. El mecanismo de comunicación entre procesos de Mach se basa en el de sus antecesores, RIG y Accent. Debido a esta evolución, el mecanismo utilizado ha sido optimizado para el caso local (un nodo) en vez del caso remoto (sistema distribuido).

La base de toda la comunicación en Mach es una estructura de datos en el núcleo Ilamado puerto. Un puerto es en esencia un buzón protegido. Cuando un hilo de un proceso desea comunicarse con un hilo de otro procesos, el hilo emisor escribe el mensaje al puerto y el hilo receptor lo obtiene de él. Cada puerto está protegido para garantizar que solo los procesos autorizados puedan enviar y recibir de él.

El núcleo mantiene para cada proceso una tabla de todos los puertos a los cuales tiene acceso dicho proceso. Esta tabla se mantiene segura dentro del núcleo, donde los procesos usuario no puedan alcanzarla. Los procesos se refieren a los puertos mediante su posición en esta tabla; es decir, la entrada I, la entrada 2, etc. Estas entradas de la tabla son posibilidades clásicas.


Cada entrada de la lista de posibilidades es uno de los cuatro elementos siguientes:

1. Una posibilidad para un puerto.

2. Una posibilidad para un conjunto de puertos.

3. Una entrada nula.4. Un código que indica que el puerto que se encontraba en ese lugar está muerto ahora.

CHORUS

Como Amoeba y Mach, Chorus es un sistema operativo basado en un micronúcleo para su use en los sistemas distribuidos. Proporciona una compatibilidad binaria con el System V de UNIX, un soporte para las aplicaciones de tiempo real, y la programación orientada a objetos.

Chorus consta de tres capas conceptuales: la capa del núcleo, los subsistemas, y los procesos usuario. La capa del núcleo contiene al micronúcleo propiamente dicho, así como algunos procesos del núcleo que se ejecutan en modo núcleo y comparten el espacio de direcciones del micronúcleo. La capa intermedia contiene los subsistemas, que se utilizan para proporcionar el soporte del sistema operativo a los programas usuarios, que residen en la capa superior.

El micronúcleo proporciona seis abstracciones fundamentales: los procesos, los hilos, las regiones, los mensajes, los puertos. los grupos de puertos y los identificadores 6nicos. Los procesos proporcionan una forma de reunir y controlar los recursos. Los hilos son los entes activos del sistema, y son planificados por el núcleo mediante un planificador basado en prioridades. Las regiones son áreas del espacio de direcciones virtuales que pueden tener segmentos asociados a ellas. Los puertos son buffers que se utilizan para guardar los mensajes recibidos que no han sido leídos. Los identificadores únicos son nornbres binarios utilizados para la identificación de los recursos.


El micronúcleo y los subsistemas proporcionan juntos tres construcciones adicionales: las posibilidades, los identificadores de protección y los segmentos. Los primeros dos se utilizan para nombrar y proteger a los recursos del subsistema. La tercera es la base para la asignación de memoria, tanto dentro de un proceso en ejecución como en el disco.

Objetivos de Chorus

Los objetivos del proyecto Chorus han evolucionado junto con el sistema. En un prin-cipio, 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 cambi6 el énfasis. Los objetivos actuales se pueden resumir como sigue:

1. Emulación de UNIX de alto rendimiento.2. Uso en sistemas distribuidos.3. Aplicaciones de tiempo real.4. Integración de la programación orientada a objetos en Chorus.

Estructura del sistema

Chorus está estructurado en capas, como se muestra en la figura 9-1. En la parte inferior esta 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 Ilamadas al micronúcleo. Existen más de 100 llamadas.Los procesos de las capas superiores proporcionan el resto del sistema operativo. Cada máquina de un sistema distribuido basado en Chorus ejecuta una copia idéntica del


micronúcleo de Chorus.

Abstracciones del núcleo

El núcleo (Ilamado el micron6cleo en nuestra nomenclatura) proporciona y controla seis 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.


Cada proceso tiene un espacio de direcciones, que por lo general van 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 mensajes tienen una parte fija y un cuerpo de tamaño variable, ambos 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 Hamada puerto. Un puerto es un buffer para la recepción de mensajes, que contiene los mensajes recibidos por un proceso pero que aun no han sido leídos. Al igual que un hilo, una región o algún otro recurso, en cualquier memento, cada puerto pertenece a un proceso. Solo ese proceso puede leer sus 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 n6cleo (por ejemplo, los procesos y los puertos) reciben su nombre mediante un identificador único (UI) de 64 bits.

Administracion de Procesos en Chorus

Se refiere al funcionamiento de los procesos y los hilos en Chorus, la forma en que se manejan las excepciones y la forma en que se realiza la planificación.

Un proceso en Chorus es una colección de elementos activos y pasivos que función juntos para realizar cierto calculo. Los elementos activos son los hilos. Los elementos pasivos son un espacio de direcciones (que contiene ciertas regiones) y una colección puertos (para el envío y recepción de mensajes).

Los procesos se ejecutan en modo núcleo y todos comparten el mismo espacio de direcciones entre si y con el micro núcleo. Se cargan o descargan durante la ejecución.

Cada proceso activo en Chorus tiene uno o más hilos que ejecutan 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 esta unido al proceso en el que fue creado, y no se puede mover a otro proceso.

La planificación de los CPU se realiza mediante el use 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.

Este mecanismo proporciona la suficiente generalidad para la mayoría de las aplica-ciones en tiempo real. Se dispone de Ilamadas del sistema para modificar las prioridades de los procesos y los hilos, de modo que las aplicaciones puedan decir al sistema los hilos que son más importantes y los que son menos importantes. Se dispone de algoritmos adicionales de planificación para soportar los procesos de tiempo real y de sistema, para el System V.

Administración de Memoria en Chorus

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 1 024 a 6 143. Las regiones son una propiedad de los procesos y todos los bytes de un proceso y en las mismas regiones.

Un segmento es una colección adyacente de bytes que reciben el nombre y 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 proporcionen 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 EIS sobre los archivos.

Chorus soporta paginadores externos del estilo de Mach, Ilamados 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.

La administración de memoria en Chorus soporta 26 Ilamadas al sistema diferentes, más algunas otras Ilamadas del núcleo a los asociadores.

Las llamadas proporcionan una imagen razonable del funcionamiento de la administración de la memoria en Chorus.

Comunicación en Chorus

El paradigma básico de comunicación en Chorus es la transferencia de mensajes.

Cada mensaje contiene un encabezado (solo para uso interno del micro nú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, si está presente, siempre tiene una longitud de 64 bytes y esta por completo bajo el control del usuario. El cuerpo tiene un tamaño variable, con un máximo de 64K bytes, y también esta por completo bajo el control del usuario.

Los mensajes se envían a los puertos, cada uno de los cuales contiene un espacio para guardar cierto número de mensajes. Si se envía un mensaje a un puerto lleno, el emisor se suspende hasta que se dispone del espacio suficiente. Al crear un puerto, el proceso que hizo la llamada recibe un identificador único y un identificado local. El primero se puede enviar a otros procesos de modo que estos pueden enviar mensajes al puerto. El segundo se utiliza dentro del proceso para hacer referencia de manera directa al puerto.


Chorus proporciona dos tipos de operaciones de comunicación: envío asíncrono y RPC.

El envío asíncrono permute que un hilo solo envié un mensaje a un puerto. No existe garantía de que el mensaje Ilegue a su destino y no existe una notificación si algo sale mal. Esta 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.

Comparación de Amoeba, Mach y Chorus

SistemasOperativosDistribuidos(Orsi Gongora 6551)

Documents

Transcript of SistemasOperativosDistribuidos(Orsi Gongora 6551)