Sistemas Operativos Distribuidos

Autor: I.S.C. Angelica Nicolas Gonzlez anicolas_gonzalez@hotmail.com

1.2. concepto y caractersticas de los sistemas operativos de redes

SOR. Es aquel en el que cada mquina tiene un alto grado de autonoma y existen pocos requisitos a lo largo del sistema.

Software dbilmente acoplado en hardware dbilmente acoplado Ejemplo: estaciones de trabajo conectadas mediante una LAN Cada usuario tiene su propia estacin de trabajo Tiene su propio S.O.

 A veces se conecta de manera remota

con otra estacin Manera primitiva de hacerlo Solucin: proporcionar un sistema de archivos global, compartido, accesible desde todas las estaciones de trabajo. Servidores de archivos. acepta solicitudes de lectura y escritura de otras mquinas(clientes)

 Los clientes tienen un punto de vista

distinto del servidor de archivos El S.O. debe controlar las estaciones de trabajo en lo individual, a los servidores de archivo y encargarse de comunicacin entre ellos. No necesariamente tienen el mismo S.O.

1.3. conceptos y caractersticas de los sistemas operativos distribuidos

S.O.D. Software fuertemente acoplado en hardware dbilmente acoplado (en multicomputadoras) Parecer que toda la red es un sistema de tiempo compartido (imagen de nico sistema). Es aquel que se ejecuta en una coleccin de mquinas enlazadas mediante una red actan como un uniprocesador virtual. Ninguno actualmente cumple con ese requisito

Caractersticas de los SOD

Mecanismo de comunicacin global entre procesos.

Cualquier proceso se puede comunicar con otros local o remoto. Esquema global de proteccin. Acceso a listas de control Misma administracin de procesos. (crean, destruyen, inician o detienen los procesos) La apariencia del sistema de archivos debe ser la misma en todas partes . (por ejemplo, si el nombre del archivo es limitado a 11 caracteres)

 Todo archivo debe ser visible en cualquier posicin

(sujeto a restricciones de proteccin y seguridad) Se necesita un sistema global de archivos. (todos los ncleos deben cooperar en la bsqueda del mejor lugar para ejecutar un proceso). Cada ncleo debe tener control sobre sus propios recursos. (memoria)

ASPECTOS DEL DISEO DE UN SOD

TRANSPARENCIA. Que los usuarios piensen que la

coleccin de mquinas es tan solo un sistema compartido de un procesador. DE LOCALIZACION.(no ubican recursos) DE MIGRACION. (r. se mueven sin cambiar su nombre) DE REPLICA. (no indican el numero de copias existentes) DE CONCURRENCIA. (varios usuarios comparten recursos) DE PARALELISMO. (las actividades en paralelo sin saberlo los usuarios)

 FLEXIBILIDAD. (fcil manejo)

Ncleo monoltico. Cada mquina debe ejecutar un ncleo que proporcione la mayora de los servicios. S.O. bsico centralizado, aumentado con capacidades de red y la integracin de servicios remotos. (UNIX). microncleo. Debe soportar lo menos posible y que el servicio de s.o. se obtenga a partir de los servidores . (solo proporciona cuatro servicios) 1. Mecanismo de comunicacin entre procesos 2. Administracin de la memoria 3. Cantidad limitada de planificacin y administracin de procesos de bajo nivel. 4. Entrada/salida de bajo nivel

 CONFIABILIDAD. Si una mquina falla alguna otra se

encargue del trabajo.

Disponibilidad. Se refiere a la fraccin de tiempo en que se puede utilizar el sistema. Un sistema ampliamente confiable debe ser muy disponible. Tolerancia a fallas. (facilidad de recuperacin de datos) Los datos no deben perderse o mezclarse de manera alguna y si los dato se almacenan en varios servidores todas las copias deben ser consistentes, adems de que deben ser protegidos contra el uso no autorizado.

 DESEMPEO. Tiempo de respuesta, el rendimiento

(nmero de trabajos por hora), uso del sistema y cantidad consuma de la capacidad de la red. La comunicacin en un SOD es lenta (minimizar el nmero de mensajes) La mejora es tener muchas actividades en ejecucin paralela en distintos procesadores. Paralelismo de grano fino. Gran nmero de pequeos clculos. Comunicacin lenta. Paralelismo de grano grueso. grandes clculos y baja interaccin.

 ESCALABILIDAD. Mayor uso del numero de CPU

Unidad II. Comunicacin en los sod

Debido a la usencia de memoria compartida , toda la comunicacin en los sistemas distribuidos se basa en la transferencia de mensajes.

2.1. Comunicacin
Cuando un proceso A quiere comunicarse con el proceso B, construye primero un mensaje en su propio espacio de direcciones. Entonces ejecuta una llamada al sistema para que el sistema operativo busque el mensaje y lo enve a travs de la red hacia B. A y B deben coincidir en los significados de los bits que enven.

Modelo OSI
Desarrollado por la organizacin internacional de

estndares (ISO). OSI (modelo de referencia para interconexin de sistemas abiertos). Permite la comunicacin de los sistemas abiertos. Sistema abierto. Es aquel preparado para comunicarse con cualquier otro sistema abierto mediante estndares que gobiernan el formato, contenido y significado de los mensajes enviados y recibidos (protocolos).

protocolos
Orientados a hacia la conexin. Antes de intercambiar los datos el emisor y el receptor establecen primero en forma explicita una conexin y es probable que negocien el protocolo a utilizar (telfono).
Sin conexin. No es necesaria una conexin previa. Simplemente el emisor transmite el primer mensaje cuando este listo (buzn).

2.1.1. comunicacin con cliente servidor (socket)

Con la idea de estructurar el S.O. como un

grupo de procesos en cooperacin, llamados servidores, que ofrezcan servicios a los usuarios, llamados clientes. Las mquinas de los clientes y servidores ejecutan por lo general el mismo micronucleo y ambos se ejecutan como procesos del usuario.

 Para evitar

un gasto excesivo en los protocolos orientados a conexin, lo usual es que el modelo cliente-servidor se base en un protocolo solicitud/respuesta sencillo y sin conexin.

Solicitud

cliente respuesta
Ncleo RED

servidor
Ncleo

2.1.2. comunicacin con RPC

Aunque el modelo cliente servidor es una forma conveniente de estructurar un sistema operativo distribuido, adolece de una enfermedad incurable: el paradigma bsico en torno al cual se construye la comunicacin es la entrada/salida. Los procedimientos send y receive estn reservados para la realizacin de E/S.

Birrel y Nelson (1984)

Sugirieron permitir a los programas que llamasen a procedimientos localizados en otras mquinas. Cuando un proceso en la maquina A llama a un procedimiento en la maquina B, el proceso que realiza la llamada a A se suspende y la ejecucin del procedimiento se realiza en B. la informacin se puede transportar de un lado a otro mediante los parmetros y puede regresar en el resultado del procedimiento. A esto se le conoce como RPC.

Problemas de los RPC

Provocan

algunas complicaciones. Como los procedimientos se encuentran en maquinas diferentes, utilizan espacio de direcciones distintos. Se pueden complicar la transmisin de parmetros y resultados si las maquinas no son idnticas. Se pueden descomponer ambas maquinas y cada una de las posibles fallas puede ser la causa de diversos problemas.

Operacin Bsica de RPC

El cliente llama al cabo cliente en la manera convencional. El cabo cliente construye un mensaje empaquetando los parmetros del procedimiento y salta al kernel mediante un trap. El kernel local enva el mensaje al kernel remoto. El kernel remoto entrega el mensaje al cabo servidor.

El cabo servidor desempaqueta los parmetros y llama al procedimiento de servicio.

El procedimiento de servicio hace el trabajo y devuelve el resultado. El cabo servidor empaqueta el resultado y salta al kernel mediante un trap. El kernel remoto enva el mensaje al kernel local. El kernel local enva el mensaje al cabo del cliente, ahora suspendido esperndolo. El cabo local desempaqueta el resultado y lo devuelve al cliente.

El paso de parmetros
La funcin del cabo cliente es empaquetar los parmetros en un mensaje y enviarlo al cabo servidor. Este examina el cdigo del procedimiento en una sentencia tipo switch e invoca el procedimiento de forma local. El resultado es de nuevo empaquetado en un mensaje y enviado al cabo cliente. Esta interaccin, que parece directa, no es tan simple como aparenta ser. Mientras las arquitecturas del cliente y del servidor sean iguales no se presenta ningn problema especial

Una forma de solucionar todos estos problemas de representacin es convertir los datos a una forma cannica antes de ser enviados a la red. Cuando los parmetros llegan a su destino, por ejemplo, es preciso reconvertir el formato cannico al de la arquitectura del servidor. El problema de este mtodo es que es ineficiente en interacciones entre mquinas de igual arquitectura, de modo que otra aproximacin al problema es incorporar en el mensaje un primer byte que identifique la arquitectura del emisor. Si es la misma que la del receptor, no es necesaria conversin alguna.

El problema ms difcil de tratar en las llamadas a procedimiento remoto es el paso de punteros, ya que estos slo tienen sentido en un espacio de direccionamiento dado. Un entero pasado a una rutina de servicio tiene un significado pleno, pero un puntero es simplemente una referencia intil. No obstante, el paso de punteros en las aplicaciones de usuario es tan comn que el prescindir de ellos en las llamadas a rutinas remotas hara perder al concepto de RPC gran parte de su atractivo. Afortunadamente, el problema puede abordarse. En el lenguaje C, por ejemplo, estn disponibles dos formas de pasar parmetros.

Un mecanismo adicional de paso de parmetros es denominado de copia-restauracin. Consiste en realizar una copia del parmetro en la pila. Si esta copia parmetro es modificada en el procedimiento, se restaura su nuevo valor a la variable original.

Especificacin de interface
El servidor RPC puede ser considerado como un mdulo u objeto que implementa unas operaciones sobre datos ocultos. El servidor de a conocer estas operaciones a los clientes mediante lo que se denomina su interface, constituida por las declaraciones de los mtodos que soporta. El objetivo del mecanismo RPC es lograr que un programa tenga acceso a los servicios de uno de estos mdulos, aunque residan en otro espacio de direccionamiento, posiblemente remoto

Por brillante que sea la idea de la interaccin clienteservidor a travs de RPC, si el programador debe encarar la construccin de los cabos, el progreso de los sistemas distribuidos se ver comprometido por la falta de uso en la prctica. Es preciso que la generacin de cabos en el cliente y el servidor se realice de forma automtica. Pues bien, la interfaz del servidor se utiliza como la base de esta generacin automtica de cabos.

Enlace dinmico
No es conveniente que un servicio est ligado a una mquina. A veces las mquinas no estn operativas, de modo que los servicios se mueven a otra mquina. El cliente est interesado en el servicio, no en qu mquina ejecuta el servidor. Para solicitar un servicio, un cliente podra enviar un mensaje en una sentencia como la siguiente: send(33.33.33.33@20, &mens); En el cdigo fuente que implementa la llamada RPC. Esta solucin es inflexible, puesto que, si dentro de la mquina 33.33.33.33 el servidor pasa a escuchar en otro puerto distinto del 20, el cliente debe ser recompilado. Lo mismo ocurre si el servidor cambia de mquina.

En la especificacin formal del servidor intervienen el nombre del servidor y su nmero de versin. Ambos datos identifican un servidor. Un servidor con el mismo nombre y la misma versin, no obstante, pueden estar replicados en dos o ms mquinas a fin de mejorar el servicio o proporcionar tolerancia a fallos. El cliente debe solicitar un servicio invocando su nombre y versin, sin citar direccin alguna. El nmero de versin es conveniente a fin de que un servidor que evoluciona conserve su nombre. Un servidor puede evolucionar ofertando nuevos servicios, cancelando otros y modificando otros. A pesar de esta evolucin, es preciso que clientes antiguos, desconocedores de los cambios, sigan obteniendo el mismo tipo de servicio. Es preciso comprender, no obstante, que un servidor con el mismo nombre pero con nmero de versin distinto es un servidor diferente.

Las ventajas de identificar al servidor por su nombre son evidentes, pero, cmo el cliente localiza al servidor? Quin le proporciona su direccin? Este es un problema al que algunos sistemas RPC, entre ellos Sun RPC, dan respuesta mediante lo que se llama el enlace dinmico, que no es sino averiguar la direccin del servidor en tiempo de ejecucin. El enlace dinmico est basado en un tercer proceso denominado el enlazador. Cuando el servidor arranca, en su cdigo de inicializacin previo al bucle principal, enva un mensaje al enlazador a fin de registrarse como un proceso que presta un servicio. El enlazador es, al fin y al cabo, un registrador de servicios, un servidor de nombres. El servidor entrega su nombre, su nmero de versin y su direccin. Se dice que el servidor exporta su interfaz.

Semntica de RPC en Presencia de Fallos

El problema se presenta cuando aparecen los errores, ya que las diferencias entre las llamadas locales y remotas no son tan fciles de encubrir. Se consideraran las siguientes situaciones: El cliente no puede localizar al servidor. Se pierde el mensaje de solicitud del cliente al servidor. Se pierde el mensaje de respuesta del servidor al cliente. El servidor falla antes de recibir una solicitud. El cliente falla despus de enviar una solicitud.

Implementacin de software RPC

El xito o el fracaso de un sistema operativo distribuido radica en sus prestaciones. Si un sistema es lento, no tiene xito. Las prestaciones de un sistema operativo distribuido radican en gran parte en la velocidad de las comunicaciones, y esta velocidad depende fundamentalmente de la implementacin del protocolo de comunicacin ms que en sus principios abstractos. Protocolos RPC En los sistemas comerciales actuales, el software RPC est implementado como una biblioteca de funciones que el programa de usuario invoca. Tanto el cabo cliente como el cabo servidor no son sino un conjunto de llamadas a funciones de la biblioteca RPC

 A la hora de construir un software RPC, hay que

considerar varias cuestiones. Una de ellas es el un protocolo orientado a conexin es que la comunicacin es mucho ms fcil de implementar. Se enva un mensaje y tenemos la seguridad plena de que ha llegado a su destino. Una segunda cuestin a ponderar es el uso de un protocolo de comunicacin de propsito general o bien disear un protocolo especfico que se adapte mejor al paradigma RPC. Una tercera cuestin a considerar en el diseo del software RPC es la longitud permitida de los mensajes RPC.

Copias
La copia de datos entre espacios de direccionamiento es el cuello de botella en las prestaciones de un software RPC. En el mejor de los casos, cuando un mensaje llega al adaptador de red, este puede copiarlo a un buffer del driver del adaptador en el kernel. El kernel lo copia a continuacin al espacio del proceso de usuario en una estructura de datos del cabo.

Problemas abiertos
Una de las metas de una llamada RPC es que sea completamente transparente al programador. La total transparencia de RPC supone: La distribucin de la aplicacin o el sistema operativo no puede conllevar la prohibicin de ciertas construcciones en las llamadas a procedimiento remoto que son legales en las llamadas a procedimiento local. Tampoco debe requerir de construcciones que antes eran opcionales.

2.1.3. comunicacin en grupo

La caracterstica principal de un grupo de procesos es que cuando se enva un mensaje al grupo, todos sus componentes lo reciben. Por otra parte, los grupos son dinmicos. Los grupos nacen y mueren y en cada grupo terminan algunos procesos y se incorporan otros. Por lo tanto es necesario un mecanismo de gestin de grupos. Un proceso puede pertenecer a ms de un grupo y abandonar un grupo para unirse a otro. Un grupo es una abstraccin cuyo propsito es evitar, en las llamadas de comunicacin con grupos de procesos, parmetros molestos como el nmero de elementos en el grupo o la localizacin de cada proceso del grupo y proporcionar primitivas ms potentes y transparentes.

La implementacin de grupos depende mucho del hardware de comunicacin disponible. En algunas redes, como ethernet, existen unas direcciones especiales en las que pueden escuchar ms de una mquina. Para ello es necesario configurar el adaptador de red ethernet en cada mquina. Un nico marco o enviado a esta direccin es ledo por todas las mquinas que escuchan en ella. Estas direcciones se denominan multicasting.

Existen redes que si bien no admiten multicasting, s admiten difusin. Marcos ethernet con la direccin de destino 111...111 son recibidos por todas las mquinas de la red. La difusin puede ser utilizada para implementar grupos, pero es menos eficiente, porque el marco se enva a todas las mquinas, tanto las que pertenecen al grupo como las que no. De todas formas, el envo al grupo de procesos requiere de un solo paquete. Si el nivel de enlace no proporciona multicasting ni difusin, an es posible la implementacin de grupos. Para ello, el emisor debe enviar un paquete particular a cada miembro del grupo. Por supuesto, esta es la implementacin menos eficiente.

 Grupo cerrado. Solo los miembros del grupo pueden

enviar hacia el grupo. Se utiliza en el procesamiento en paralelo. Grupo abierto. proceso que no pertenece a un grupo puede enviar mensajes a este grupo. son apropiados para problemas como el de los servidores replicados, donde un cliente enva una peticin al grupo.

 Grupos iguales frente a Grupos jerrquicos.En algunos

grupos un proceso es el jefe o coordinador y el resto trabajan para l. En otros, todos los procesos tienen la misma categora y las decisiones se toman de forma colectiva. En el primer caso, cuando uno de los trabajadores o un cliente externo solicita una peticin, esta es enviada al coordinador, que decide cul de los trabajadores es el ms apropiado para servirla. Cada una de estas organizaciones tiene sus ventajas y sus inconvenientes. Los grupos pares no tienen un nico punto de fallo. Si un trabajador deja de existir, la carga se reparte en el resto. Sin embargo, incurren en el retraso que supone el ponerse de acuerdo para decidir quin sirve una peticin. Los grupos jerrquicos tienen las propiedades opuestas.

 Pertenencia de grupos.

Se necesita un mtodo para crear, destruir y modificar los grupos. Una solucin es introducir un proceso denominado el servidor de grupos. El servidor de grupos mantiene tablas con los grupos existentes y sus integrantes. Esta solucin es eficiente y fcil de implementar. El problema es que el servidor de grupos es una tcnica centralizadora y, como tal, constituye un nico punto de fallo. La opcin opuesta es la gestin distribuida. Un nuevo proceso que se incorpora al grupo puede enviar un mensaje al grupo y todos los procesos toman nota de su existencia. Cuando un proceso del grupo termina, enva un mensaje de adis.

Surge un problema cuando un proceso del grupo termina

inesperadamente. El resto del grupo tiene que descubrirlo experimentalmente, ya que el proceso nunca responde a nada. Cuando todos los miembros lo han constatado, se le da de baja.

 Direccionamiento de grupos.Para dirigir un mensaje a

un grupo, el grupo debe tener una direccin. Si el nivel de enlace de la red -en adelante, la red- soporta multicasting, se puede implementar una direccin de grupo como una direccin multicasting. Si la red soporta difusin, pero no multicasting, el mensaje debe ser recibido por todos los ncleos y extraer de l la direccin del grupo. Si ninguno de los procesos de la mquina es miembro del grupo, el mensaje es descartado. En otro caso, es pasado a todos los procesos que pertenecen al grupo. Si la red no soporta ni difusin ni multicasting, el ncleo de la mquina emisora tendr que tener una lista de los procesos que pertenecen al grupo y enviar un mensaje a cada uno de los componentes del grupo.

Primitivas send y receive

No es conveniente que los procesos de usuario puedan

utilizar las primitivas send y receive por separado. Segn Tanenbaum, send y receive se corresponden en programacin distribuida con la construccin "go to" en programacin convencional. Si se permite send y receive a los procesos de usuario, se pueden aprovechar estas primitivas para realizar la comunicacin de grupo. En el caso de la comunicacin convencional cliente servidor, el primer parmetro de send es un nmero de puerto en la red y el segundo parmetro es el mensaje.

Atomicidad de la difusin
Una de las caractersticas de la comunicacin de grupos es que un mensaje enviado a un grupo debe ser recibido por todos los miembros del grupo o por ninguno de ellos. A esta propiedad se la denomina la atomicidad de la difusin o simplemente la atomicidad. La atomicidad facilita en gran medida la programacin de sistemas distribuidos.

todo o nada

Ordenacin de mensajes
Para que la comunicacin en grupo sea fcil de usar y

comprender requiere de dos propiedades. La primera es la atomicidad, examinada ms arriba y la segunda es el orden de los mensajes. Un sistema debe tener una semntica bien definida con respecto al orden de entrega de los mensajes. La mejor garanta es la entrega inmediata de todos los mensajes, en el orden en que fueron enviados:

 Todos los mensajes destinados a un grupo deben

entregarse antes de comenzar a entregar la siguiente serie de mensajes. Todos los receptores reciben todos los mensajes en el mismo orden. Este esquema se denomina ordenamiento con respecto al tiempo global. La propiedad de orden temporal global exige que cada miembro del grupo reciba primero el mensaje del proceso 0 y despus el mensaje del proceso 4. Una red local que soporte difusin garantiza el orden temporal global.

Grupos solapados
En el apartado anterior vimos el problema de la

ordenacin temporal global aplicada a un grupo dado. Dos procesos del mismo grupo enviaban simultneamente un mensaje al grupo. Hemos mencionado previamente que un proceso puede pertenecer a ms de un grupo, de manera que los grupos pueden solaparse. Este solapamiento produce un nuevo tipo de inconsistencia temporal.

El problema es el siguiente: Existe un ordenamiento con respecto al tiempo global dentro de cada grupo. No existe coordinacin entre varios grupos. Resulta muy complicado implantar el orden con respecto al tiempo entre los distintos grupos, pero no siempre es necesario hacerlo. Una comunicacin de grupo que garantiza que esto no ocurre se dice que tiene la propiedad de orden temporal entre grupos solapados. La implementacin del orden temporal entre grupos solapados es costosa y difcil de implementar

Escalabilidad
Muchos algoritmos de comunicacin de grupos funcionan bien siempre que los grupos sean pequeos y haya pocos grupos, pero qu ocurre cuando cada grupo tiene muchos procesos y hay miles de grupos? Y qu ocurre cuando los grupos se extienden geogrficamente entre continentes? Para ellos es preciso sobrepasar los estrechos lmites de la red local e introducir encaminadores y muchas redes locales. La presencia de encaminadores afecta a las propiedades de la comunicacin del sistema operativo distribuido, ya que estn basadas en la suposicin de ausencia de encaminadores.

2.2. sincronizacin
La comunicacin no lo es todo. Una cuestin relacionada, pero distinta, es la sincronizacin. Cmo se implementa, por ejemplo una regin crtica en un entorno distribuido? En los sistemas centralizados los procesos comparten la memoria, de modo que es posible utilizar variables como el semforo para implementar regiones crticas. En un entorno distribuido la memoria comn no existe. Por otra parte, en los sistemas distribuidos, es difcil decidir qu evento ocurri antes que otro, debido a que cada mquina tiene su propio reloj y no existe, por tanto, una base de tiempos comn.

Sincronizacin de relojes
Los algoritmos distribuidos tienen las siguientes propiedades: La informacin relevante est repartida entre mltiples mquinas Los procesos toman decisiones basados nicamente en informacin local Es preciso evitar un nico punto de fallo No existe un reloj comn Los primeros tres aspectos dicen que es inaceptable recoger toda la informacin en un nico punto. El ltimo aspecto es que ahora nos interesa.

2.2.1. relojes lgicos

Lamport. lo importante es que los procesos que interactan

se pongan de acuerdo en el tiempo en que los eventos ocurren. As, para ciertas clases de algoritmos, lo que importa es la consistencia interna de los relojes, no la exactitud particular de cada uno de ellos. Para estos algoritmos, es conveniente hablar de relojes lgicos. Cuando el objetivo es mantener todos los relojes dentro de un margen error dado respecto al tiempo absoluto, es conveniente hablar de relojes fsicos. Permite capturar numricamente la relacin sucedi-antes Es un contador software que se incrementa montonamente y no tiene ninguna relacin con el reloj fsico

 Para ciertos

algoritmos lo que importa es la consistencia interna de los relojes: No interesa su cercana particular al tiempo real (oficial). Los relojes se denominan relojes lgicos. Los relojes fsicos son relojes que: Deben ser iguales (estar sincronizados). No deben desviarse del tiempo real ms all de cierta magnitud. Para sincronizar los relojes lgicos, Lamport defini la relacin ocurre antes de (happens-before):
Si a y b son eventos en el mismo proceso y a ocurre

antes de b, entonces a > b es verdadero. Ocurre antes de es una relacin transitiva: Si a > b y b > c, entonces a > c.

 Si dos eventos x e y estn en procesos diferentes que no

intercambian mensajes, entonces x > y no es verdadero, pero tampoco lo es y > x: Se dice que son eventos concurrentes. Necesitamos una forma de medir el tiempo tal que a cada evento a, le podamos asociar un valor del tiempo C(a) en el que todos los procesos estn de acuerdo: Se debe cumplir que: Si a > b entonces C(a) < C(b). El tiempo del reloj, C, siempre debe ir hacia adelante (creciente), y nunca hacia atrs (decreciente). Consideramos tres procesos que se ejecutan en diferentes mquinas, cada una con su propio reloj y velocidad: El proceso 0 enva el mensaje a al proceso 1 cuando el reloj de 0 marca 6.

 El proceso 1 recibe el mensaje a cuando su reloj marca 16. Si el mensaje acarrea el tiempo de inicio 6, el proceso 1

considerar que tard 10 marcas de reloj en viajar. El mensaje b de 1 a 2 tarda 16 marcas de reloj. El mensaje c de 2 a 1 sale en 60 y llega en 56, tardara un tiempo negativo, lo cual es imposible. El mensaje d de 1 a 0 sale en 64 y llega en 54. Lamport utiliza la relacin ocurre antes de:
Si c sale en 60 debe llegar en 61 o en un tiempo posterior. Cada mensaje acarrea el tiempo de envo, de acuerdo con el reloj del

emisor. Cuando un mensaje llega y el reloj del receptor muestra un valor anterior al tiempo en que se envi el mensaje: El receptor adelanta su reloj para que tenga una unidad ms que el tiempo de envo.

 Este algoritmo cumple nuestras necesidades para el

tiempo global, si se hace el siguiente agregado: Entre dos eventos cualesquiera, el reloj debe marcar al menos una vez. Dos eventos no deben ocurrir exactamente al mismo tiempo. Con este algoritmo se puede asignar un tiempo a todos los eventos en un sistema distribuido, con las siguientes condiciones: Si a ocurre antes de b en el mismo proceso, C(a) < C(b). Si a y b son el envo y recepcin de un mensaje, C(a) < C(b). Para todos los eventos a y b, C(a) es distinto de C(b).

El algoritmo de Lamport proporciona un orden de eventos sin ambigedades, pero [25, Tanenbaum]: Los valores de tiempo asignados a los eventos no tienen porqu ser cercanos a los tiempos reales en los que ocurren. En ciertos sistemas (ej.: sistemas de tiempo real ), es importante la hora real del reloj:
Se precisan relojes fsicos externos (ms de uno). Se deben sincronizar:

2.2.2. relojes fsicos

Con los relojes del mundo real. Entre s.

La medicin del tiempo real con alta precisin no es sencilla

podemos decir que el tiempo absoluto puede ser proporcionado al computador, pero a un precio alto y siempre con un margen de error no despreciable.

 Como el perodo de rotacin de la tierra no es constante, se

considera el segundo solar promedio de un gran nmero de das. Los fsicos definieron al segundo como el tiempo que tarda el tomo de cesio 133 para hacer 9.192.631.770 transiciones: Se tom este nmero para que el segundo atmico coincida con el segundo solar promedio de 1958. La Oficina Internacional de la Hora en Pars (BIH) recibe las indicaciones de cerca de 50 relojes atmicos en el mundo y calcula el tiempo atmico internacional (TAI). Como consecuencia de que el da solar promedio (DSP) es cada vez mayor, un da TAI es 3 mseg menor que un DSP: La BIH introduce segundos de salto para hacer las correcciones necesarias para que permanezcan en fase: El sistema de tiempo basado en los segundos TAI. El movimiento aparente del sol. Surge el tiempo coordenado universal (UTC).

 El Instituto Nacional del Tiempo Estndar (NIST)

de EE. UU. y de otros pases: Operan estaciones de radio de onda corta o satlites de comunicaciones. Transmiten pulsos UTC con cierta regularidad establecida (cada segundo, cada 0,5 mseg, etc.). Se deben conocer con precisin la posicin relativa del emisor y del receptor:
Se debe compensar el retraso de propagacin de la seal.
Si la seal se recibe por mdem tambin se debe

compensar por la ruta de la seal y la velocidad del mdem. Se dificulta la obtencin del tiempo con una precisin extremadamente alta.

2.2.3. usos de la sincronizacin (manejo de cach, comunicacin en grupo, exclusin mutua, eleccin, transacciones atmicas e interbloqueo)
Exclusin mutua. Cuando dos o ms procesos comparten

una estructura de datos, su lectura o actualizacin no debe ser simultnea. Para evitar la simultaneidad de acceso, y con ello la inconsistencia de la estructura, el cdigo de acceso y actualizacin de la misma se denomina regin crtica y su ejecucin es protegida mediante construcciones como semforos, monitores, etc. Algoritmo centralizado. ( se elije un proceso coordinador, regin critica). Un Algoritmo Distribuido. (enva mensajes y a el mismo, el receptor no esta en la reg critica y no quiere entrar en el resp=ok, si ya esta no responde y encola la solicitud) Algoritmo token ring (fichas)

 Eleccin. El objetivo de un algoritmo de eleccin es

garantizar que iniciada una eleccin sta concluya con el acuerdo de todos los procesos con respecto a la identidad del nuevo coordinador. En general, los algoritmos de eleccin intentan localizar al proceso con el identificador ms alto para hacerlo coordinador. Para enviar los mensajes, los procesos necesitan conocer las direcciones de red de todo el grupo de procesos en busca de coordinador, de modo que la eleccin ya estara hecha de antemano. El problema es que los procesos desconocen cules de ellos estn an activos y cules no. El requisito que debe cumplir una eleccin de coordinador es que esta sea nica. Los algoritmos difieren unos de otros en el modo de conseguirlo

 El Algoritmo del Granduln o de Garca-Molina (si

el coordinador ya no responde, si nadie responde gana, nmero mayor=nuevo coordinador) Un Algoritmo de Anillo. Se supone que los procesos tienen un orden

fsico o lgico, es decir que cada proceso conoce a su sucesor. Cuando algn proceso observa que el coordinador no funciona: Construye un mensaje eleccin con su propio nmero de proceso. Enva el mensaje a su sucesor. Si el sucesor est inactivo:
El emisor va hacia el siguiente nmero del anillo o al siguiente de ste. Contina hasta localizar un proceso en ejecucin. En cada paso, al emisor aade su propio nmero de proceso a la lista en el mensaje.

En cierto momento el mensaje regresa al proceso que lo inici:

El proceso lo reconoce al recibir un mensaje con su propio nmero de proceso. Informa a los dems procesos: Quin es el coordinador, es decir, el miembro de la lista con el nmero mayor. Quines son los miembros del nuevo anillo.

El mensaje de eleccin se transforma en mensaje coordinador y circula nuevamente:

Concluida la ronda de informacin el mensaje coordinador se elimina y continan los procesos.

 Transacciones atmicas.
La principal propiedad de la transaccin atmica es el todo o nada:
O se hace todo lo que se tena que hacer como una unidad o no se hace

nada. Ejemplo:
Un cliente llama al Banco mediante una PC con un mdem para:

Retirar dinero de una cuenta. Depositar el dinero en otra cuenta. La operacin tiene dos etapas. Si la conexin telefnica falla luego de la primer etapa pero antes de la segunda: Habr un retiro pero no un depsito. La solucin consiste en agrupar las dos operaciones en una transaccin atmica: Las dos operaciones terminaran o no terminara ninguna. Se debe regresar al estado inicial si la transaccin no puede concluir.

 Las propiedades fundamentales son La serializacin garantiza que si dos o ms

transacciones se ejecutan al mismo tiempo: El resultado final aparece como si todas l as transacciones se ejecutasen de manera secuencial en cierto orden:
Para cada una de ellas y para los dems procesos.

La atomicidad garantiza que cada transaccin no

ocurre o bien se realiza en su totalidad: Se presenta como una accin indivisible e instantnea. La permanencia se refiere a que una vez comprometida una transaccin: Sigue adelante y los resultados son permanentes.

 Los algoritmos de control de concurrencia son

necesarios cuando se ejecutan varias transacciones de manera simultnea [25, Tanenbaum]:

En distintos procesos.

En distintos procesadores.

Los principales algoritmos son: El de la cerradura. El del control optimista de la concurrencia. El de las marcas de tiempo.

2.3. nominacin

2.3.1. caractersticas y estructuras

2.3.2. tipos de nombres(de usuario y de sistema)

2.3.3. resolucin y distribucin

2.3.4. servidores y agentes de nombres

servidores de nombre como agentes obligatorios

distribuidos que amarran el nombre de un objeto para una cierta cantidad de sus propiedades, incluyendo la posicin del objeto. Algunos servidores de nombre pueden almacenar informacin acerca de los objetos particulares. Tales servidores de nombre se llaman las autoridades que nombra o servidores autoritarios de nombre para eso objetan. El problema es cmo distribuir servidores de nombre, esto es, que de las estructuras de una facilidad de nombramiento es el mejor.

2.3.5. mapeo de direcciones

Para poder ejecutar instrucciones, si no sabemos en qu parte de la memoria estarn cargadas, debemos

tener un mecanismo de traduccin de direcciones virtuales a reales. Para ello, se necesitan dos cosas. Primero, el compilador manejar una direccin base ms un desplazamiento al referirse a las instrucciones. Segundo, el sistema operativo asignar como direccin base el nmero de pgina, al paginar al proceso. De esta manera, puede buscarse el inicio de una pgina en memoria, sumarle el desplazamiento y as obtener la direccin real de una instruccin

2.3.6. mapeo de rutas

Rutas y ruteamientos Por lo general, un sistema distribuido de archivos tiene dos componentes razonablemente distintos: El verdadero servicio de archivos y El servicio de directorios. El primero se encarga de las operaciones en los archivos individuales, como la lectura, escritura y adicin, mientras que el segundo se encarga crear y administrar directorios, aadir y eliminar archivos de los directorios. En los mainframes existen muchos tipos de archivos, cada uno con distintas propiedades. Por ejemplo, un archivo se puede estructurar como una serie de registros, con llamadas al sistema operativo para leer o escribir un registro particular. Por lo general se puede especificar el registro mediante su nmero. En el segundo caso, el sistema operativo mantiene el archivo como un rbol B o alguna otra estructura adecuada, o bien tablas de distribucin para localizar con rapidez los registros. Puesto que la mayora de los sistemas distribuidos estn planeados para ambientes UNIX y MS-DOS, la mayora de los servidores tratan a los archivos como secuencia de bytes.

2.3.7. modelo de terry

Las siguientes estructuras bsicas de facilidad de

nombramiento para los sistemas operativos distribuidos han sido identificadas por Terry (1984) e Indulska y Goscinski (1989): (1) una facilidad centralizada de nombramiento (2) una facilidad replegada de nombramiento (3) una facilidad descentralizada de nombramiento (4) una facilidad distribuida de nombramiento (5) una facilidad jerrquica de nombramiento.

Fin de la presentacin