Historia

Desarrollado en la Universidad Vrije de Amsterdam, Holanda. Jefe de diseño:

Andrew S. Tanenbaum, otros desarrolladores Frans Kaashock, Sape J. Mullender,
Robbert Van Renesse, Leendert van Doorn, Verstoep Kees y muchos más.

En primer prototipo fue lanzado en 1983 (V1.0), última versión oficial en 1996
(V5.3)

Soporta múltiples arquitecturas: 68k, i80386, SPARC

Amoeba es un sistema operativo distribuido de investigación, basado en una

arquitectura de micronúcleo. Fue desarrollado por Andrew S. Tanenbaum y otros
en la Universidad Libre de Amsterdam. El objetivo del proyecto Amoeba era
construir un sistema de tiempo compartido que hiciera que una red entera de
computadores pareciera a los ojos de un usuario como una máquina única.
Los servicios suministrados por el núcleo incluyen threads, segmentos de memoria,
mecanismos de IPC (RPCs y mensajes) y E/S [160].
El desarrollo parece detenido, dado que la fecha de la última modificación en el
código data de febrero de 2001.
Existen versiones para varias plataformas, incluyendo i386, Sun-3 y SPARC.
El lenguaje de programación Python fue originalmente desarrollado para esta
plataforma.

Los objetivos de investigación

 Uno de los objetivos principales del desarrollo Amoeba fue diseñar un
sistema distribuido transparente que permite a los usuarios iniciar sesión en
el sistema en su conjunto.

Transparencia: Eso significa ocultar la conexión de un sistema distribuido

de los usuarios. Los usuarios Amoeba no deben preocuparse por el número
de los procesadores en el sistema, ni deben saber el lugar de las otras
máquinas o servidores (como el servidor del sistema de archivos...).

 Varias máquinas conectadas a través de una red funcionan como un único

sistema:

 Distribución. Amoeba da a sus usuarios la ilusión de interactuar con un,

único sistema de gran alcance.

2
  Paralelismo: En un sistema de Amoeba, un solo programa o comando
puede utilizar múltiples procesadores para aumentar el rendimiento. El
usuario simplemente pide una operación, y el sistema operativo Amoeba,
decide la mejor manera de cumplir la solicitud. Amoeba decidirá qué
procesador (o procesadores) son apropiados para la solicitud, basada en el
estado actual del sistema. 

Adicionalmente, el desarrollo de herramientas especiales se han hecho para

un entorno de Amoeba que aprovechan el paralelismo inherente. Por
ejemplo, Amoeba es compatible con una paralela "hacer" del programa.

 Peformance: Esto se logra con un nuevo desarrollo del protocolo de red de

alto rendimiento llamado Flip (Fast local Internet Protocol). Cuando la
FLIP se ha desarrollado, ninguno de los protocolos actuales proporcionan
un apoyo adecuado para sistemas distribuidos. La FLIP realiza, sencilla y
eficazmente comunicación limpia entre los nodos distribuidos.
 Desarrollo desde cero; no existía una base para el desarrollo de Amoeba.
 Amoeba interactúa con el usuario como un sistema UNIX de tiempo
compartido.

La arquitectura del sistema

Amoeba implementa el modelo cliente/servidor. De hecho, en el fondo todo el
sistema sólo necesita tres funciones para hacer todo el trabajo: La llamada
operación desde el cliente, y GetRequest y PutReply funciones en el lado del
servidor.  

Un sistema de Amoeba consta de cuatro componentes principales: 

1. Estaciones de trabajo
2. Pool procesadores
3. Servidores especiales (servidor de archivos ...)
4. Gateways

3
 Fig. 1 Componentes de un sistema Amoeba.

En más detalle:  
 

 Amoeba está diseñado como un conjunto de núcleos de micro. Así, el

sistema consiste en muchos CPUs conectados a través de la red
Amoeba. Cada CPU posee su propia memoria local en el intervalo de 2 MB a
100 MB. Un gran número de procesadores construye el
llamado Processorpool. Este grupo de CPU se puede asignar
dinámicamente según sea necesario por el sistema y los usuarios. servidores
especializados, llamado servidor de ejecución, los procesos de
distribución de manera justa a estas máquinas. 

 Diferentes arquitecturas de procesador son compatibles: i80386 (Pentium),

68k, SPARC. Hoy en día, sólo la arquitectura i80386 es significativa para la
construcción de un sistema Amoeba.

 Estaciones de trabajo permiten a los usuarios acceder al sistema

Amoeba. Normalmente hay una estación de trabajo por usuario, y la
estación de trabajo son en su mayoría sin disco, sólo un núcleo de la estación
de trabajo debe ser arrancado (desde disquete, a través de TFTP, se
encendieron en Flash EEPROM). Ameba apoya X-Windows y la emulación
de UNIX.

 En el fondo del sistema de Amoeba varios servidores especializados que

llevan a cabo la sincronización de las operaciones fundamentales del
núcleo. Amoeba tiene un servidor de directorio (llamada SOAP) que es el
servicio de nombres para todos los objetos utilizados en el sistema. SOAP
proporciona un modo de asignar nombres ASCII a un objeto por lo que es
más fácil de manipular (por los seres humanos). 

 El servidor de directorios puede reproducir archivos sin temor a su

cambio. Amoeba tiene por supuesto un servidor de archivos (llamado el
servidor de bala) que implementa un servicio estable de archivos de alta
velocidad que se consigue mediante el uso de una caché de buffer de gran
tamaño. Dado que los archivos se crea por primera vez en la memoria caché,
y sólo se escriben en el disco cuando se cierran, todos los archivos se pueden
almacenar contiguamente. La idea que subyace detrás de los archivos
inmutables es evitar que el mecanismo de replicación de someterse a las

4
 condiciones de carrera. Y el servidor bloquea archivos normalmente no dan
lugar a un sistema de archivos incompatible. 

 El servidor bala utiliza el servidor de disco virtual para realizar I / O en el

disco, así que es posible que el servidor de archivos se ejecute como un
programa de usuario normal. El servidor de inicio de control de todos los
servidores del sistema mundial (fuera del núcleo), visita de inicio y encuesta,
reinicie si se estrelló.

 Todos los objetos Amoeba (archivos, programas, segmentos de memoria,

servidores) están protegidos y se describen las denominadas capacidades.

Microkernel  de Amoeba
Después de analizar el modelo de hardware de Amoeba, pasemos al modelo de
software. Amoeba consta de dos partes fundamentales: un micronúcieo 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.

Fig. 2 Estructura del software Amoeba

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.

5
3. Soportar la comunicación.
4. Controlar la E/S de bajo nivel.

Consideraremos cada una de estas funciones a su tiempo.

Como la mayoría de los sistemas operativos, Amoeba soporta el concepto de
proceso. Además, 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.
Por el contrario, aunque un proceso con varios hilos posee también un espacio de
direcciones compartido por todos los hilos, cada uno de éstos tiene, desde el punto
de vista lógico sus propios registros, su contador del programa y su pila. De hecho,
una colección de hilos de un proceso es análoga a una colección de procesos
independientes en UNIX, excepto que comparten un espacio de direcciones común.

Un uso típico de varios hilos sería el de un servidor de archivos, donde cada

solicitud recibida es asignada a un hilo para su procesamiento. Ese hilo podría
comenzar a procesar la solicitud, después bloquearse en espera del disco y después
seguir con su trabajo. Al dividir el servidor en varios hilos, cada uno de ellos puede
ser secuencial, aunque deba bloquearse en espera de E/S. Sin embargo, todos los
hilos pueden, por ejemplo, tener acceso a un caché compartido en software. Los
hilos se pueden sincronizar mediante semáforos o mútex para evitar que dos hilos
tengan acceso simultáneo al caché compartido.

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 bloquesde
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 llamada. 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 comunicación puntual se basa en el modelo de un cliente que envía un mensaje
a un servidor y que después se bloquea hasta que el servidor envía una respuesta.
Este intercambio solicitud/respuesta es la base para la construcción de todo lo
demás.

La otra forma de comunicación es de grupo. Permite el envío de mensajes de una

fuente a varios destinos. Los protocolos en software proporcionan una
comunicación en grupo confiable y tolerante de fallas a los procesos del usuario, en
presencia de mensajes perdidos u otros errores.
La cuarta función del núcleo es la administración de la E/S de bajo nivel.

6
Para cada dispositivo de E/S conectado a una máquina, 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 controladores de dispositivos se comunican con el resto del sistema mediante
los mensajes usuales de solicitud y respuesta. Un proceso, como por ejemplo un
servidor de archivos, que necesite comunicarse con el controlador del disco, le
envía mensajes de solicitud y recibe de regreso ciertas respuestas. En general, el
cliente no tiene que saber que se comunica con un controlador. Desde su punto de
vista, sólo se comunica con un hilo en algún lugar.

Tanto el sistema de mensajes puntuales como la comunicación en grupo hacen uso

de un protocolo especializado llamado FLIP. Este protocolo es un protocolo de
capas de la red y fue diseñado en especial para cubrir las necesidades del cómputo
distribuido. Trabaja tanto con la unitransmisión como con la multitransm'isión en
redes complejas.

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 dientes 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. Por ejemplo, los objetos
archivo tienen una operación READ, entre otras.
Los objetos son controlados por los servidores. Cuando un proceso crea un objeto,
el servidor que lo controla regresa al cliente una posibilidad protegida en forma
cifrada para el objeto. Para el uso posterior del objeto, hay que presentar la
posibilidad adecuada.

Todos los objetos del sistema, tanto del hardware como del software, reciben un
nombre, una protección y son controlados por las posibilidades. Algunos de los
objetos soportados por esta vía son los archivos, los directorios, los segmentos de
memoria, las ventanas en la pantalla, los procesadores, los discos y las unidades de
cinta. Esta interfaz uniforme para todos los objetos proporciona generalidad y
sencillez.
Todos los servidores estándar tienen procedimientos de resguardo en la biblioteca.
Para utilizar un servidor, por lo general un cliente llama por lo regular al resguardo,
7
el cual ordena los parámetros, envía el mensaje y se bloquea hasta recibir la
respuesta. Este mecanismo oculta todos los detalles de la implantación al usuario.
Se tiene un compilador de resguardo para los usuarios que deseen producir
procedimientos de resguardo para sus servidores.

Tal vez 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.

Otro servidor importante es el servidor de directorios, que por ciertas oscuras

razones históricas también se conoce como el servidor soap (jabón). Este
servidor controla los directorios y los nombres de las rutas de acceso y las asocia
con las posibilidades. Para leer un archivo, un proceso le pide al servidor de
directorios que busque el nombre de la ruta de acceso. En una búsqueda exitosa, el
servidor de directorios regresa la posibilidad correspondiente al archivo (o algún
otro objeto).

Las operaciones posteriores en el archivo no utilizan al servidor de directorios, sino

que van directamente al servidor de archivos. La separación del sistema de archivos
en estos dos componentes aumenta la flexibilidad y hace a cada parte más sencilla,
puesto que sólo tiene que controlar un tipo de objeto (directorios o archivos) y no
dos.

Se tienen otros servidores estándar para el manejo de la réplica de objetos, el inicio

de procesos, el monitoreo de servidores en búsqueda de fallas y la comunicación
con el mundo exterior. Los servidores de los usuarios llevan a cabo gran variedad
de tareas específicas a cada aplicación.

El resto del capítulo tiene la siguiente estructura. En primer lugar describiremos los
objetos y las posibilidades, puesto que forman el corazón de todo el sistema.
Después analizaremos el núcleo, con énfasis en la administración de los procesos,
la administración de la memoria y la comunicación. Por último, examinaremos
algunos de los principales servidores, como el servidor de archivos, el servidor de
directorios, el servidor de réplicas y el servidor de ejecución.

Objetivo y posibilidades en Amoeba 

OBJETOS
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.
8
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 a cabo una operación en un objeto, un cliente hace una RPC con el
servidor, donde se específica 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.

Los clientes no son conscientes de las posiciones de los objetos que utilizan y los
servidores que los controlan. Un servidor se podría ejecutar en la misma máquina
que el cliente, en una distinta en la misma LAN e incluso en una máquina a cientos
de kilómetros de distancia. Además, aunque la mayoría de los servidores se
ejecutan como procesos del usuario, unos cuantos servidores de bajo nivel, como el
servidor de segmentos (es decir, de memoria) o el servidor de procesos, se ejecutan
como hilos en el núcleo. Esta distinción también es invisible para los clientes.

El protocolo RPC para comunicarse con los servidores del usuario o los servidores
del núcleo, ya sean locales o remotos, es idéntico en todos los casos. Así, un cliente
sólo se preocupa por lo que debe realizar, no de la posición donde se guardan los
objetos o donde se ejecutan los servidores-Cierto directorio contiene las posi-
bilidades para todos los servidores de archivos accesibles junto con una
especificación de la opción por omisión, de modo que un usuario pueda evitar esta
opción en los casos donde esto sea importante. Por lo general, el administrador del
sistema define la opción por omisión como la local.

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. 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.

Bits 24 8 48 48
Puerto del servidor Objeto Dere- Verificación
chos
Fig. 3 Una posibilidad en Amoeba.

Cuando un cliente desea llevar a cabo una operación en un objeto, llama a un

procedimiento de resguardo, el cual construye un mensaje con la posibilidad del
objeto y después hace un señalamiento al núcleo. Éste extrae el campo Puerto del

9
servidor de la posibilidad y lo busca en su caché para localizar la máquina donde
reside el servidor. Si el puerto no está en el caché, lo localiza mediante una
transmisión que describiremos más adelante. El puerto es en sí una dirección
lógica mediante la cual se puede alcanzar al servidor.

Así, se asocian los puertos de servidor a cada servidor específico (o a un conjunto

de servidores) y no con una máquina específica. Si un servidor se desplaza a una
nueva máquina, se lleva consigo el puerto del servidor. Muchos de los puertos de
servidor, como el correspondiente al servidor de archivos, se conocen en forma
pública y son estables durante años. La única forma en que uno se puede dirigir a
un servidor es a través de su puerto, que en un principio se elige a sí mismo.

El resto de la información en la posibilidad es ignorada por los núcleos y se

transfiere al servidor para su uso. El campo Objeto es utilizado por el servidor para
identificar el objeto específico en cuestión. Por ejemplo, un servidor de archivos
puede controlar miles de archivos y utilizar el número de objeto para indicar el
archivo en el cual opera en un momento dado. En cierto sentido, el campo Objeto
de una posibilidad de un archivo es similar al número de nodo-i de UNIX.

El campo Derechos es un mapa de bits que indica las operaciones permitidas al

propietario de una posibilidad. Por ejemplo, aunque un objeto particular soporte la
lectura y la escritura, se puede construir una posibilidad particular donde se
desactiven todos los bits de derechos excepto el correspondiente a READ.

El campo Verificación se utiliza para dar validez a la posibilidad. Éstas son

controladas de forma directa por los procesos del usuario. Sin cierta forma de
protección, no habría manera de evitar que los procesos del usuario moldeen las
posibilidades.

Procesos en Amoeba
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 creación de un proceso en Amoeba es distinta de la de UNIX. El modelo de

UNIX para la creación de un proceso hijo mediante la clonación del padre no es
adecuada en un sistema distribuido, debido al costo considerable de crear primero
una copia en alguna parte (FORK) para reemplazar en forma casi inmediata la
copia con un programa nuevo (EXEC). En vez de esto, Amoeba permite crear un
proceso nuevo en un procesador específico donde la supuesta imagen en memoria
comience justo al principio. En este respecto, la creación de un proceso en Amoeba
es similar al caso de MS-DOS. Sin embargo, a diferencia de MS-DOS, un proceso
puede continuar su ejecución en paralelo con su hijo, con lo cual puede crear un
número arbitrario de hijos adicionales. El hijo puede, a su vez, crear sus propios
hijos, lo que produce un árbol de procesos.

10
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.
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
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. Analizaremos el servidor de ejecución en una sección
posterior de este capítulo.

Algunas de las llamadas para la administración de procesos utilizan una estructura

de datos llamada descriptor del proceso donde se proporciona la información
relativa a un proceso que está por ejecutarse. Un campo del descriptor del proceso
(véase la figura 7-6) indica las arquitecturas de CPU donde se puede ejecutar el
proceso. En los sistemas heterogéneos, este campo es esencial para garantizar que
los binarios 386 no se ejecuten en SPARC, etcétera.
Otro campo contiene la posibilidad del propietario del proceso. Cuando el proceso
termina o queda incapacitado (véase más adelante), se realiza una RPC mediante
esta posibilidad para informar del evento. También contiene descriptores de todos
los segmentos del proceso, los cuales definen en forma colectiva su espacio de
direcciones, así como los descriptores de todos sus hilos.

Por último, el descriptor del proceso contiene también un descriptor para cada hilo
del proceso. El contenido de un descriptor de hilo depende de la arquitectura, pero
como mínimo, contiene el contador del programa y el apuntador a la pila del hilo.
También puede contener la información adicional necesaria para ejecutar el hilo,
donde se incluyen otros registros, el estado del hilo y varias banderas. Los procesos
más recientes contienen sólo un hilo en sus descriptores de procesos, pero los
procesos incapacitados pueden haber creado más hilos antes de incapacitarse.

La interfaz de bajo nivel consta de cerca de media docena de procedimientos de

biblioteca. De éstos, sólo nos interesan tres. El primero, exec, es el más importante.
Tiene dos parámetros de entrada, la posibilidad de un servidor de procesos y un
descriptor de proceso. Su función es realizar una RPC con el servidor de procesos
específico para solicitar la ejecución del proceso. Si la llamada tiene éxito, una
posibilidad para el nuevo proceso regresa al punto donde se hizo la llamada.

Un segundo procedimiento de biblioteca importante es getload. Regresa la

información relativa a la velocidad del CPU, la carga actual y la cantidad de
memoria libre en ese momento.

11
 El servidor de ejecución lo utiliza para determinar la mejor posición para la
ejecución de un nuevo proceso

Fig. 4 Un descriptor de proceso

se ejecutan en los servidores se convierten en huérfanos. Cuando los servidores

finalmente terminan y envían sus respuestas, éstas se descartan en última
instancia.
La interfaz de procesos de alto nivel no necesita un descriptor de procesos por
completo formado. Una de las llamadas, newproc, toma como sus primeros tres
parámetros el nombre del archivo binario y los apuntadores a los arreglos del
argumento y del ambiente, de manera similar al caso de UNIX. Otros parámetros
proporcionan un control más detallado del estado inicial.

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.

12
Aunque todos los hilos de proceso comparten el mismo texto y datos globales de un
programa, cada hilo tiene su pila, su apuntador a la pila y su copia de los registros
de la máquina. Además, si un hilo desea crear y utilizar variables globales a todos
sus procedimientos pero invisibles para los demás hilos, se dispone de
procedimientos de biblioteca para tales fines. Tales variables son globales.
Un procedimiento de biblioteca asigna un bloque de memoria global del tamaño
necesario y regresa un apuntador a él. Se hace referencia a los bloques de memoria
global mediante enteros, en vez de cadenas. Se dispone de una llamada al sistema
para que un hilo adquiera su apuntador global.
Se dispone de tres métodos para la sincronización de hilos: señales, mútex y
semáforos. Las señales son interrupciones asíncronas que se envían de un hilo a
otro en el mismo proceso. Desde el punto de vista conceptual, son similares a las
señales de UNIX, excepto que se envían entre hilos en vez de procesos. Las señales
se pueden enviar, capturar o ignorar. Las interrupciones asíncronas entre los
procesos utilizan el mecanismo de incapacidad.

La segunda forma de comunicación entre los hilos es el mútex. Un mútex es como

un semáforo binario. Puede tener uno de dos estados, cerrado o abierto. El intento
por cerrar un mútex abierto cierra éste. El hilo que realiza la llamada continúa. El
intento por cerrar un mútex ya cerrado hace que el hilo que hace la llamada se
bloquee hasta que otro hilo abra el mútex. Si más de un hilo espera un mútex, al
momento de abrir éste, libera exactamente un hilo. Además de las llamadas para
cerrar o abrir un mútex, también existe una llamada para intentar cerrar un mútex,
pero si ésta no puede hacerlo durante un intervalo de tiempo dado, concluye su
tiempo y regresa un código de error.

La tercera forma de comunicación entre los hilos es mediante el conteo de

semáforos. Son más lentos que los mútex, pero hay ocasiones en que son
necesarios. Funcionan de la manera usual, excepto que en este caso existe una
llamada adicional para permitir que termine el tiempo de una operación DOWN si
no tiene éxito durante cierto intervalo de tiempo.

El núcleo controla todos los hilos. La ventaja de este diseño es que cuando un hilo
realiza una RPC, el núcleo puede bloquearlo y programar la ejecución de otro hilo
del mismo proceso si alguno está listo. La planeación del procesamiento de los
hilos se realiza mediante el uso de prioridades, donde los hilos del núcleo tienen
mayor prioridad que los hilos del usuario. La planeación del procesamiento de los
hilos se puede configurar con prioridades o para ejecutarse hasta terminar (es
decir, que los hilos continúen su ejecución hasta bloquearse), conforme lo desee el
proceso.

Administración de la memoria
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
13
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.

Aunque es posible que este diseño sea poco usual en esta época, se realizó así por
tres razones: desempeño, sencillez y economía. El hecho de que un proceso esté por
completo contenido en la memoria hace más rápida la RPC. Cuando hay que enviar
un bloque de datos de gran tamaño, el sistema sabe que todos los datos están
adyacentes, no sólo en la memoria virtual, sino también en la memoria física. Esto
evita verificar si se dispone en cierto momento de todas las páginas necesarias
dentro del buffer y elimina la espera de las mismas si no estuvieran dentro del
buffer.

De manera análoga, en la entrada, el buffer siempre está dentro de la memoria, por

lo que los datos recibidos se pueden colocar ahí sin fallos de páginas. Este diseño
ha permitido a Amoeba lograr tasas de transferencia muy altas para RPC de gran
tamaño.

La segunda razón para este diseño es la sencillez. El hecho de no utilizare!

intercambio o la paginación hace más sencillo al sistema y hace que el núcleo sea
más pequeño y controlable. Sin embargo, la tercera razón es la que hace factibles a
las dos primeras. La memoria será tan barata que, al cabo de pocos años, es
probable que todas las máquinas Amoeba tengan cientos de megabytes de la
misma. Tales memorias de gran tamaño reducirán en forma esencial la necesidad
de la paginación o el intercambio, para que los programas de gran tamaño se
ajusten a máquinas pequeñas.

Segmentos
Los procesos disponen de varias llamadas al sistema para el manejo de los
segmentos. Entre las más importantes están las que permiten crear, destruir, leer y
escribir segmentos. Al crear un segmento, el proceso que hizo la llamada recibe a
cambio una posibilidad, la cual es utilizada para la lectura y escritura del segmento,
así como para las demás llamadas relacionadas con el segmento.

Un segmento recién creado recibe un tamaño inicial, el cual puede cambiar durante
la ejecución del proceso. También puede tener un valor inicial, ya sea de otro
segmento o de algún archivo.

Puesto que los segmentos se pueden leer o escribir, es posible utilizarlos para
construir un servidor de archivos de la memoria principal. Para comenzar, el
servidor crea un segmento del mayor tamaño posible.
Puede determinar ese tamaño máximo preguntando al núcleo. Este segmento se
utilizará como un disco simulado. Después, el servidor le da formato al segmento
como un sistema de archivos, con todas las estructuras necesarias para llevar el
registro de los archivos. Después de todo eso, se abre al público para aceptar y
procesar solicitudes de los clientes.

14
Segmentos asociados
Los espacios de direcciones virtuales en Amoeba se construyen a partir de los
segmentos.
Al iniciar un proceso, éste debe tener al menos un segmento. Sin embargo, durante
su ejecución, un proceso puede crear más segmentos y asociarlos con su espacio de
direcciones en cualquier dirección virtual no utilizada.

Un proceso también puede desasociar segmentos. Además, un proceso puede

especificar un rango de direcciones virtuales y solicitar que el rango sea
desasociado, después de lo cual dichas direcciones ya no serán válidas. Al
desasociar un segmento o un rango de direcciones, se regresa una posibilidad, de
modo que se pueda mantener el acceso al segmento o incluso que pueda ser
asociado más adelante, tal vez en una dirección virtual distinta.

Un segmento se puede asociar con el espacio de direcciones de dos o más procesos

a la vez. Esto permite que los procesos operen en la memoria compartida. Sin
embargo, por lo general es mejor crear un proceso con varios hilos cuando se
necesite la memoria compartida. La principal razón para tener varios procesos es
una mejor protección, pero si los dos procesos la comparten, lo usual es que no se
desee la protección.

Comunicación en Amoeba
En todos los procesos el núcleo también pueden comunicarse con un estándar de
RPC (Llamada a procedimiento remoto) de la interfaz. Sólo hay tres funciones para
alcanzar este objetivo:

 transporte ( , req_buf req_header, req_size, rep_header, rep_buf,

rep_size )

-> Hacer una transacción a otro servidor

 getreq (req_header, req_buf, req_size)

-> Obtener una petición del cliente

 putrep (rep_header, rep_buf, rep_size)

-> Enviar una respuesta al cliente

15
La primera función es utilizada por el cliente para enviar un mensaje a un servidor,
y recibe una respuesta del servidor en esta solicitud. La solicitud y respuesta son
buffers de memoria genérica (char). La solicitud y los encabezados respuesta son
estructuras de datos simples para describir la solicitud y la capacidad del
servidor. Por otro lado, el servidor de llamadas dentro de un bucle infinito utiliza la
función getreq. 

Cada vez que un cliente envía al servidor (determinado por un puerto del servidor)
un mensaje, el getreq devuelve los datos del cliente y llena en El búfer de solicitud,
en su caso. El encabezado de la solicitud contiene la información sobre la solicitud
del cliente.

Debido a que el cliente espera una respuesta, el servidor debe enviar una respuesta
(ya sea con o sin datos de respuesta) utilizando la respuesta de la función.

La segunda forma de comunicación en Amoeba es la comunicación en grupo y las

llamadas que proporciona para este tipo de comunicación nos permiten crear
nuevos grupos, unir procesos a grupos existentes, enviar información a grupos y
una serie tareas más para gestionar esta comunicación.

16
 Bibliografía

Tanenbaum, Andrew S. Sistemas Operativos Distribuidos.

Pearson Education, 2001.

17