Amoeba

Amoeba

Historia de Amoeba

Amoeba se originó en Vrije Universiteit, Amsterdam, Holanda, en 1981, como proyecto de investigación en cómputo distribuido y paralelo. Fue diseñado en un principio por Andrew S. Tanenbaum y tres de sus estudiantes de doctorado, Frans Kaashoek, Sape J. Mullender y Robbert van Renesse, aunque muchas otras personas contribuyeron en el diseño y la implantación.

Objetivos de investigación

Muchos de los proyectos de investigación en los sistemas operativos distribuidos han partido de un sistema existente y agregando nuevas características como el uso de redes y un sistema compartido de archivos para hacerlo más distribuido. El proyecto Amoeba siguió un método diferente. Partió de un plan limpio y desarrolló un sistema nuevo a partir de cero. La idea era tener un comienzo fresco y experimentar nuevas ideas sin tener que preocuparse por la compatibilidad retroactiva con cualquiera de los sistemas existentes. Para evitar el enorme trabajo de escribir grandes cantidades de software de aplicación, se añadió posteriormente un paquete de emulación de UNIX.

La arquitectura del sistema Amoeba

Antes de describir la forma en que Amoeba está estructurado, es útil delinear en primer lugar el tipo de configuración en hardware para el que fue diseñado Amoeba, puesto que difiere un poco de lo que poseen la mayor parte de las organizaciones actuales. Amoeba se diseñó 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.

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.

 El micronúcleo de Amoeba se ejecuta en todas las máquinas 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 básicas:

1. Controlar los procesos e hilos.

2. Proporcionar el soporte de la administración de memoria de bajo nivel.

3. Soportar la comunicación.

4. Controlar la E/S de bajo nivel.

Los servidores de Amoeba

Todo 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 mejorar la flexibilidad. Como el sistema de archivos y otros dispositivos estándar no se integran al núcleo, éstos se pueden modificar con facilidad y se pueden ejecutar en forma simultánea varias versiones para las distintas poblaciones de usuarios. Amoeba se basa en el modelo cliente-servidor. Los clientes son escritos en general por los usuarios, mientras que los servidores son escritos por los programadores del sistema,aunque los usuarios pueden escribir sus propios servidores si así lo desean. El concepto de objeto es central en el diseño de todo el software; un objeto es como un tipo de dato abstracto.Cada objeto consta de ciertos datos encapsulados, con ciertas operaciones definidas en ellos. el servidor más importante sea el servidor de archivos. Proporciona las primitivas para la administración de archivos, su creación, lectura, eliminación, etc. A diferencia de la mayoría de los servidores de archivos, los archivos creados son inmutables. Una vez creado, un archivo no se puede modificar, pero puede ser eliminado. Los archivos inmutables facilitan la réplica automática, puesto que evitan muchas de las condiciones de competencia inherentes en la réplica de archivos sujetos a modificaciones durante tal proceso.

Objetos y posibilidades en Amoeba

El concepto básico y unificador subyacente en todos los servidores de Amoeba y los servicios que éstos 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.

Para llevar acabo una operación en un objeto, un cliente hace una RPC con el servidor, donde se especifica el objeto, la operación por desarrollar y, de manera opcional, los parámetros necesarios. El servidor lleva a cabo el trabajo y regresa la respuesta. Las operaciones se llevan a cabo en forma sincronizada; es decir, después que se inicia una RPC con un servidor para obtener cierto trabajo, el hilo del cliente se bloquea hasta que el servidor responde. Sin embargo, se pueden ejecutar otros hilos en el mismo proceso.

Posibilidades

Los objetos reciben su nombre y protección de manera uniforme mediante boletos especiales llamados posibilidades. Para crear un objeto, un cliente realiza una RPC con el servidor apropiado, donde indica lo que desea 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.

Protección de objetos

El algoritmo básico para la protección de objetos es el siguiente. Cuando se crea un objeto, el servidor elige un campo Verificación al azar y lo guarda en la nueva posibilidad y dentro de sus propias tablas. Se activan todos los bits de derechos a una nueva posibilidad y esta posibilidad del propietario es lo que regresa al cliente. Cuando la posibilidad regresa al servidor en una solicitud para llevar a cabo una operación, se verifica el campo verificación.

Administración de procesos en Amoeba

Procesos

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. 

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 máquinas.

En el siguiente nivel tenemos un conjunto de procedimientos de biblioteca que proporcionan una interfaz más conveniente para los programas del usuario. Se tienen distintos gustos. Hacen su trabajo al llamar 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.

Hilos

Amoeba soporta un modelo sencillo de hilos. Al iniciar un proceso, éste tiene al menos un hilo. Durante la ejecución, el proceso puede crear más hilos y los existentes pueden terminar su labor. Así, el número de hilos es por completo dinámico. Al crearse un nuevo hilo, los parámetros de la llamada especifican el procedimiento por ejecutar y el tamaño de la pila inicial.

Administración 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 localizar 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.

Comunicación en Amoeba

Amoeba soporta dos formas de comunicación: RPC mediante la 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 ésta; en caso contrario, la simula de manera transparente mediante mensajes individuales.

Llamada a un procedimiento remoto (RPC)

La comunicación puntual en Amoeba consta de un cliente que envía un mensaje a un servidor, seguida de una respuesta del servidor al cliente. No es posible que un cliente envíe un mensaje y después haga otra cosa, excepto al pasar por alto la interfaz RPC, lo cual ocurre sólo bajo circunstancias muy especiales.

Cada servidor estándar define una interfaz de procedimientos que los clientes pueden llamar. Estas rutinas de biblioteca son resguardos que empaquetan los parámetros en mensajes y llaman a las primitivas del núcleo para enviar en realidad el mensaje.

Primitivas de RPC

El mecanismo RPC utiliza principalmente tres primitivas del núcleo:

1. get_request, indica la disposición de un servidor para escuchar a un puerto.

2. put_reply, llevada a cabo por un servidor cuando tiene un mensaje que desea enviar.

3. irans, envía un mensaje del cliente al servidor y espera la respuesta.

Los servidores de Amoeba

El servidor de archivos

El sistema de archivos se ejecuta como colección de procesos servidores. Los usuarios que no quieran utilizar los estándares, pueden escribir los suyos propios. El sistema de archivos estándar consta de tres servidores, el servidor de archivos, que controla el espacio de almacenamiento de archivos; el servidor de directorios, que se encarga de los nombres de los archivos y del manejo de los directorios y el servidor de réplicas, el cual controla la réplica de archivos.

La interfaz del servidor de archivos

El servidor de archivos soporta seis operaciones: