APUNTES DE SISTEMAS OPERATIVOS II POR ING.

PEDRO TAMAYO GOMEZ

UNIDAD I. LOS SISTEMAS OPERATIVOS EN AMBIENTES DISTRIBUIDOS.

1.1 SISTEMAS DISTRIBUIDOS

Un sistema distribuido es un conjunto de computadoras independientes que se presenta a los usuarios como un sistema nico. En el sistema distribuido cualquier computadora puede tener acceso a el software o hardware y el centralizado solo se encuentra en una computadora a la cual se le pide en servicio.

1.1.1

Ventajas y Desventajas de un sistema distribuido contra un sistema centralizado

Ventajas iene procesadores mas poderosos y menos costosos Desarrollo de estaciones con mas capacidad !as estaciones satisfacen las necesidades de los usuarios Uso de nuevas interfaces Desventajas "equerimientos de mayores controles de procesamiento Velocidad de pro#ramaci$n de informaci$n %muy lenta& 'ayores controles de acceso Ventajas 'ayor aprovechamiento de recursos Desventajas El software es mucho mas complejo

Distribuidos

Centralizado

Ventajas de los sistemas distribuidos sobre los centralizados Econom(a Velocidad #lobal de la instalaci$n )oluci$n a problemas* pasan por el empleo de computadoras f(sicamente distantes !a se#uridad ante la falla de un +,U puede reor#anizarse y se#uir operando correctamente pero con menos precisi$n Un sistema distribuido permite la aportaci$n de nuevos recursos de computo a fin de elevar su potencial #lobal y el crecimiento es muy util

a las empresas y en computadora normal soporta continuamente un aumento de la car#a de trabajo debido al crecimiento de la empresa y lle#ara el momento en que deber- ser sustituida e invertir en una nueva computadora. Sistema central
+liente +liente +liente

Servidor Sistema Distribuido

1.1.. 'odelo +liente )ervidor

/rquitectura +liente0 )ervidor Una arquitectura es un conjunto de re#las* definiciones* t1rminos y modelos. 2ue se emplea para producir la arquitectura cliente0servidor a#rupa conjuntos de elementos que efectan procesos distribuidos y computo operativo. Beneficios 'ayor aprovechamiento de la potencia de computo "educe el trafico en la red 3pera bajo sistemas abiertos ,ermite el uso de interfaces #raficas variadas

Cliente

+onjunto de software y hardware que invoca los servicios de uno o varios servidores.

1.1.4 +aracter(sticas 5ardware )istemas Distribuidos

Debemos considerar las diversas formas en que es posible interconectar varias computadoras o bien varias +,U). 6lynn propuso cuatro diferentes cate#or(as en que se podr(an clasificar lo sistemas hardware e7isten de acuerdo a dos par-metros numero de flujo de instrucciones y nmeros de flujos de datos. )8)D Un flujo de instrucci$n con flujo de datos )8'D Un flujo de instrucci$n varios flujos de datos '8)D Varios flujos de instrucciones un flujo de datos %no se usa& '8'D Varios flujos de instrucciones y varios flujos de datos

Dentro de esta cate#or(a se pueden encontrar dos tipos distintos de la forma en que se pueden interconectar el hardware. Es as(* como tenemos los si#uientes #randes #rupos 'U! 8,"3+E)/D3"E) 'U! 8+3',U /D3"E)

+ada uno de estos tipos permite una intercone7i$n de su componente tipo bus y tipo conmuta. Desde el punto de vista de las velocidades de comunicaci$n que pueden alcanzar estos dos #randes #rupos se tienen dos conceptos asociados. Sistemas fuertemente acoplados Sistemas dbilmente acoplados )6/ asa de transmisi$n alta* retraso de mensajes alto %mensajes cortos& )D/ retraso de mensajes entre maquines #rande y tasa de transmisi$n baja

'U! 8,"3+E)/D3" !os multiprocesadores corresponden a un conjunto de +,U) conectadas entres si que utilizan un espacio de direccionamiento virtual comn. 'U! 8,"3+E)/D3"E) +39 +39E:8;9 DE <U)

En este caso los +,U) est-n interconectadas entre s(* mediante un bus. +ada vez que una +,U quiere realizar un acceso de lectura o escritura debe acceder al bus. 'U! 8,"3+E)/D3"E) +39 +39E:8;9 +39'U / En este caso la memoria se divide en diversos bancos y las +,U) se interconectan con ellas no mediante un canal tipo bus* si no de otra manera. 'U! 8+3',U /D3"E) Esto se refiere a sistemas de computa con memoria distribuida* en esta caso cada computadora pasee su propia memoria local. 'U! 8+3',U /D3"E) +39 +39E:8;9 DE <U) Esta sistema es similar al caso de los multiprocesadores. +on cone7i$n tipo bus* solo que no se requiere que el canal de comunicaci$n sea tan alto como en el caso de los multiprocesadores.

1.1.= +aracter(sticas )oftware )istemas Distribuidos

TRANSPARENC A 14/FEBRERO/2008

)e define como la ocultaci$n al usuario y al pro#ramador de aplicaciones de la superaci$n de los componentes de un sistema distribuido. 3!E"/9+8/ / 6/!!3) Esto se basa en dos +urt iones complementar(as entre si. "edundancia hardware y recuperaci$n del software. +3',/" 8+8;9 DE "E+U")3) El termino >"E+U")3? es bastante abstracto pero es el que mejor caracteriza a el abanico de entidades que pueden compartirse en un sistema distribuido. /,E" U"/ %3peneness& Un sistema puede ser abierto o cerrado con respecto a e7tensiones hardware o con respecto a las e7tensiones software. +39+U""E9+8/ +uando e7isten varios procesos en una nica maquina decimos que se est-n ejecutando.

1.1.@ Direccionamiento !$#ico 6(sico )istemas Distribuidos

21/FEBRERO/2008 ) U<) El stup se implementa en el cliente como una rutina de biblioteca E),E+868+/+8;9 DE 89 E"6/A El servidor ",+ puede ser considerado como un modulo u objeto que implementa operaciones sobre datos ocultos y da a conocer estas operaciones a los clientes mediante lo que se denomina interfase constituida por las declaraciones de los m1todos que soporta. El primer paso es definir la interfaz es decir el conjunto de los prototipos de los procedimientos de servicios mediante un len#uaje determinado de interfaz* un compilador especial toma como estrada el fichero escrito en el len#uaje de interfaz y como salida #enera el c$di#o objeto de los procedimientos que constituyen el stups del cliente* por una parte y el stup servidor por la otra* el pro#rama cliente se enlaza con estos procedimientos objetos para #enerar el ejecutable* en cuanto al servidor los procedimientos de servicio escritos por el compilador se compilan previamente al len#uaje objeto y se enlazan con los procedimientos de stup en los que fi#ura el procedimiento principal del servidor 1.2

+oncepto +aracter(sticas )or

07/FEBRERO/2008 +ada elemento de c$mputo tiene su propia memoria y su propio sistema operativo. +ontrol de recursos locales y remotos. )istemas abiertos %facilidades de cambio y crecimiento&. 9o e7iste una plataforma est-ndar %uni7* 9 * 8ntel etcB&. 'edios de comunicaci$n %"edes* protocolos* dispositivos etcB&. +apacidad de procesamiento en paralelo. Dispersi$n y parcialidad.

6actores que an afectado el desarrollo del sistema distribuido /vances tecnol$#icos 9uevos requerimientos

Clobalizaci$n /spectos e7ternos %culturales* pol(ticos y econ$micos& 8nte#raci$n

1.4

+oncepto +aracter(sticas del )od

08/FEBRERO/2008

Caracter!sticas El cliente pide servicios a un nodo denominado servidor Detecta e intersecta peticiones de otras aplicaciones y puede redireccionarlas Dedicado a la secci$n de usuario El m1todo mas comn por el que se solicitan los servicios es atrav1s de ",+ %llamadas a procedimientos remotos&

6U9+839E) +3'U9E) DE! +!8E9 E 'antener y procesar todo el dialo#o con el usuario 'anejo de pantallas 'ens e interpretaci$n de comandos Entrada de datos y validaci$n ,rocesamiento de ayuda "ecuperaci$n de errores

",+ 6uncionamiento
+lienteD 0 0 0 ,roceso realiza llamada a funci$n !lamada empaqueta 8D de funci$n y ar#umentos en mensaje y los env(a a otro proceso 2ueda a la espera del resultado

)ervidorD 0 0 0 "ecibe mensajes con id de funci$n y ar#umentos )e invoca funci$n en el servidor "esultado de la funci$n se empaqueta en mensaje que se retransmite al cliente

3bjetivoE /cercar la sem-ntica de las llamadas a procedimientos convencional a un entorno distribuido %transparencia&

UNIDAD II COMUNICACIN EN LOS SISTEMAS OPERATIVOS DISTRIBUIDOS

26/FEBRERO/2008

..1 +3'U98+/+8;9
!a comunicaci$n entre procesos en sistemas con un nico procesador se lleva a cabo mediante el uso de memoria compartida entre los procesos. En los sistemas distribuidos* al no haber cone7i$n f(sica entre las distintas memorias de los equipos* la comunicaci$n se realiza mediante la transferencia de mensajes.

..1.1 +omunicaci$n +liente0)ervidor

Sockets Es un mecanismo de comunicacin, Permite a los sistemas cliente/servidor ser desarrollados Localmente en una sola mquina A travs de redes. Funciones tales como impresin, utileras de red, tales como rlogin !tp, usualmente usan soc"ets para comunicarse. Socket designa un concepto a#stracto por el cual dos programas $posi#lemente situados en computadoras distintas% pueden intercam#iarse cualquier !lu&o de datos, generalmente de manera !ia#le ordenada. 'n soc"et queda de!inido por una direccin (P, un protocolo un n)mero de puerto. Explicacin detallada Para que dos programas puedan comunicarse entre s es necesario que se cumplan ciertos requisitos* +ue un programa sea capa, de locali,ar al otro. +ue am#os programas sean capaces de intercam#iarse cualquier secuencia de octetos, es decir, datos relevantes a su !inalidad. Para ello son necesarios los tres recursos que originan el concepto de soc"et* 'n protocolo de comunicaciones, que permite el intercam#io de octetos.

'na direccin del Protocolo de -ed $.ireccin (P, si se utili,a el Protocolo /0P/(P%, que identi!ica una computadora. 'n n)mero de puerto, que identi!ica a un programa dentro de una computadora. Los soc"ets permiten implementar una arquitectura cliente1servidor. La comunicacin 2a de ser iniciada por uno de los programas que se denomina programa cliente. El segundo programa espera a que otro inicie la comunicacin, por este motivo se denomina programa servidor. 'n soc"et es un !ic2ero e3istente en la mquina cliente en la mquina servidora, que sirve en )ltima instancia para que el programa servidor el cliente lean escri#an la in!ormacin. Esta in!ormacin ser la transmitida por las di!erentes capas de red.

..1.. +omunicaci$n ",+

3tro paso en el diseFo de un sistema operativo distribuido plantea las llamadas a procedimientos remotos o ",+s. !os ",+ ampl(an la llamada local a procedimientos* y los #eneralizan a una llamada a un procedimiento localizado en cualquier lu#ar de todo el sistema distribuido. En un sistema distribuido no se deber(a distin#uir entre llamadas locales y ",+s* lo que favorece en #ran medida la transparencia del sistema. Una de las dificultades m-s evidentes a las que se enfrenta el ",+ es el formato de los par-metros de los procedimientos. Un ejemplo es la posibilidad de que en un sistema distribuido formado por diferentes tipos de ordenadores* un ordenador con formato little endian llamara a un procedimiento de otro ordenador con formato bi# endian* etc. Este problema se podr(a solucionar si tenemos en cuenta que ambos pro#ramas conocen el tipo de datos de los par-metros* o estableciendo un est-ndar en el formato de los par-metros* de forma que sea usado de forma nica. ,or ltimo queda por solucionar la tolerancia a fallos. Una llamada a un procedimiento remoto puede fallar por motivos que antes no e7ist(an* como la p1rdida de mensajes o el fallo del cliente o del servidor durante la ejecuci$n del procedimiento. !a limitaci$n del ",+ m-s clara en los sistemas distribuidos es que no permite enviar una solicitud y recibir respuesta de varias fuentes a la vez* sino que la comunicaci$n se realiza nicamente entre dos procesos. ,or motivos de tolerancia a fallos* bloqueos* u otros* ser(a interesante poder tratar la comunicaci$n en #rupo.

27/FEBRERO/2008 !a comunicaci$n en #rupo tiene que permitir la definici$n de #rupos* as( como caracter(sticas propias de los #rupos* como la distinci$n entre #rupos abiertos o que permiten el acceso y cerrados que lo limitan* o como la distinci$n del tipo de jerarqu(a dentro del #rupo. 8#ualmente* los #rupos han de tener operaciones relacionadas con su manejo* como la creaci$n o modificaci$n.

..1.4 +omunicaci$n en #rupo

2ue el sistema de archivos sea tolerante a fallos implica que el sistema debe #uardar varias copias del mismo archivo en distintos ordenadores para #arantizar la disponibilidad en caso de fallo del servidor ori#inal. /dem-s* se ha de aplicar un al#oritmo que nos permita mantener todas las copias actualizadas de forma consistente* o un m1todo alternativo que s$lo nos permita acceder al archivo actualizado* como invalidar el resto de copias cuando en cualquiera de ellas se vaya a realizar una operaci$n de escritura. El uso de memorias cache para a#ilizar el acceso a los archivos tambi1n es recomendable* pero este caso requiere analizar con especial atenci$n la consistencia del sistema.

..1.= olerancia a fallos

... )89+"398A/+8;9

29/FEBRERO/2008

El modelo cliente0servidor basa la comunicaci$n en una simplificaci$n del modelo 3)8. !as siete capas que proporciona producen un desaprovechamiento de la velocidad de transferencia de la red* con lo que s$lo se usar-n tres capasD f(sica %1&* enlace de datos %.& y solicitudGrespuesta %@&. !as transferencias se basan en el protocolo solicitudGrespuesta y se elimina la necesidad de cone7i$n.

....1 "elojes f(sicos

El al#oritmo de !amport proporciona un orden de eventos sin ambi#Hedades* peroD !os valores de tiempo asi#nados a los eventos no tienen porqu1 ser cercanos a los tiempos reales en los que ocurren. En ciertos sistemas %ej.D sistemas de tiempo real&* es importante la hora real del relojD )e precisan relojes f(sicos e7ternos %m-s de uno&. )e deben sincronizarD +on los relojes del mundo real. Entre s(. !a medici$n del tiempo real con alta precisi$n no es sencilla. Desde anti#uo el tiempo se ha medido astron$micamente. )e considera el d(a solar al intervalo entre dos tr-nsitos consecutivos del sol* donde el tr-nsito del sol es el evento en que el sol alcanza su punto aparentemente m-s alto en el cielo. El se#undo solar se define como 1 G IJ.=KK de un d(a solar. +omo el per(odo de rotaci$n de la tierra no es constante* se considera el se#undo solar promedio de un #ran nmero de d(as. !os f(sicos definieron al se#undo como el tiempo que tarda el -tomo de cesio 144 para hacer L.1L..J41.MMK transicionesD )e tom$ este nmero para que el se#undo at$mico coincida con el se#undo solar promedio de 1L@I.

..... "elojes !$#icos

!as computadoras poseen un circuito para el re#istro del tiempo conocido como dispositi"o reloj# Es un cron$metro consistente en un cristal de cuarzo de precisi$n sometido a una tensi$n el1ctrica queD 3scila con una frecuencia bien definida que depende deD !a forma en que se corte el cristal. El tipo de cristal. !a ma#nitud de la tensi$n. / cada cristal se le asocian dos re#istrosD "e#istro contador# "e#istro mantenedor# +ada oscilaci$n del cristal decrementa en %&' al contador. +uando el contador lle#a a %(') )e #enera una interrupci$n# El contador se vuelve a car#ar mediante el re#istro mantenedor. )e puede pro*ramar un cron$metro para que #enere una interrupci$n %+' "eces por se*undo# +ada interrupci$n se denomina marca de reloj# Para una computadora , un reloj) 9o interesan pequeFos desfasajes del reloj porqueD odos los procesos de la m-quina usan el mismo reloj y tendr-n consistencia interna# 8mportan los tiempos relati"os# Para "arias computadoras con sus respecti"os relojes) Es imposible #arantizar que los cristales de computadoras distintas oscilen con la misma frecuencia. 5abr- una prdida de sincron!a en los relojes -de soft.are/ * es decir que tendr-n "alores distintos al ser le(dos.

....4 Uso de la sincronizaci$n

04/MARZO/2008 !a Oficina Internaci na! "e !a # ra en Par$% &BI#' recibe las indicaciones de cerca de @K relojes at$micos en el mundo y calcula el tiempo at$mico internacional % /8&. +omo consecuencia de que el d!a solar promedio %D),& es cada vez mayor* un d!a TA es 4 mse# menor que un DSP) !a <85 introduce se*undos de salto para hacer las correcciones necesarias para que permanezcan en fase) El sistema de tiempo basado en los se#undos /8. El movimiento aparente del sol. )ur#e el tiempo coordenado uni"ersal %U +&. El 8nstituto 9acional del iempo Est-ndar %98) & de EE. UU. y de otros pa(sesD 3peran estaciones de radio de onda corta o sat1lites de comunicaciones.

ransmiten pulsos U + con cierta re#ularidad establecida %cada se#undo* cada K*@ mse#* etc.&. )e deben conocer con precisi$n la posici$n relativa del emisor y del receptorD )e debe compensar el retraso de propa#aci$n de la seFal. )i la seFal se recibe por m$dem tambi1n se debe compensar por la ruta de la seFal y la velocidad del m$dem. )e dificulta la obtenci$n del tiempo con una precisi$n e7tremadamente alta.

..4 93'89/+8;9
05/MARZO/2008

+orrespondencia entre objetos de datos l$#icos y f(sicos. ,or ejemplo* los usuarios tratan con objetos de datos l$#icos representados por nombre de archivos* mientras que el sistema manipula bloques de datos f(sicos almacenados en las pistas de los discos. Ceneralmente un usuario se refiere a un archivo utilizando un nombre* el cual se transforma en un identificador num1rico de bajo nivel* que a su vez se corresponde con bloques en disco. Esta correspondencia multinivel ofrece a los usuarios la abstracci$n de un archivo* que oculta los detalles de c$mo y donde se almacena el archivo en disco. )i se e7tiende un poco mas el tratamiento de los archivos como abstracciones* lle#amos a la posibilidad de replicas de archivos. Dado un nombre de archivo* la correspondencia devuelve un conjunto de posiciones de las replicas de este archivo. En esta abstracci$n se ocultan tanto la e7periencia de copias como su ubicaci$n. E%()e*a "e n *inaci+n 5ay tres enfoques principales para los esquemas de nominaci$n. En el enfoque m-s sencillo* los archivos se nombran con una combinaci$n del nombre de su anfitri$n y su nombre local* lo que #arantiza un nombre nico dentro de todo el sistema. El se#undo enfoque popularizado por el sistema de archivos de red %96)* 9etworN 6ile )ystem& de sun* ofrece una forma de unir directorios remotos a directorios locales* lo que da la apariencia a un -rbol de directorios coherentes. El tercer enfoque es la estructura mas compleja y dif(cil de mantener en la 96)* ya que cualquier directorio se puede unir a cualquier -rbol de direcciones locales y la jerarqu(a resultante puede estar poco estructurada. N *inaci+n , Tran%-arencia E7isten dos conceptos que hay que correspondencia de nombres en un )DD

distin#uir

en

relaci$n

con

la

Tran%-arencia "e N *inaci+n. El nombre de archivo no revela nin#n indicio sobre de la ubicaci$n del almacenamiento f(sico del archivo. In"e-en"encia "e U/icaci+n. 9o es necesario modificar el nombre de un archivo cuando cambia su ubicaci$n en el almacenamiento f(sico.

..4.1 +aracter(sticas y su estructura

05/MARZO/2008

los usuarios tratan con objetos de datos l$#icos representados por nombre de archivos* mientras que el sistema manipula bloques de datos f(sicos almacenados en las pistas de los discos. Ceneralmente un usuario se refiere a un archivo utilizando un nombre* el cual se transforma en un identificador num1rico de bajo nivel* que a su vez se corresponde con bloques en disco. Esta correspondencia multinivel ofrece a los usuarios la abstracci$n de un archivo* que oculta los detalles de c$mo y donde se almacena el archivo en disco. )i se e7tiende un poco mas el tratamiento de los archivos como abstracciones* lle#amos a la posibilidad de replicas de archivos. Dado un nombre de archivo* la correspondencia devuelve un conjunto de posiciones de las replicas de este archivo. En esta abstracci$n se ocultan tanto la e7periencia de copias como su ubicaci$n.

..4.. ipos de 9ombres

5ay tres enfoques principales para los esquemas de nominaci$n. En el enfoque m-s sencillo* los archivos se nombran con una combinaci$n del nombre de su anfitri$n y su nombre local* lo que #arantiza un nombre nico dentro de todo el sistema. El se#undo enfoque popularizado por el sistema de archivos de red %96)* 9etworN 6ile )ystem& de sun* ofrece una forma de unir directorios remotos a directorios locales* lo que da la apariencia a un -rbol de directorios coherentes. El tercer enfoque es la estructura mas compleja y dif(cil de mantener en la 96)* ya que cualquier directorio se puede unir a cualquier -rbol de direcciones locales y la jerarqu(a resultante puede estar poco estructurada.

..4.4 "esoluci$n y distribuci$n

06/MARZO/2008

E7isten dos conceptos que hay que distin#uir en relaci$n con al correspondencia de nombres en un )DD Tran%-arencia "e N *inaci+n. El nombre de archivo no revela nin#n indicio sobre de la ubicaci$n del almacenamiento f(sico del archivo. In"e-en"encia "e U/icaci+n. 9o es necesario modificar el nombre de un archivo cuando cambia su ubicaci$n en el almacenamiento f(sico.

..4.= )ervidores y a#entes de nombre

06/MARZO/2008 ,ara implantar una nominaci$n transparente se requiere un mecanismo para correspondencia entre un nombre de archivo y la ubicaci$n asociada. ,ara que esta correspondencia sea manejable* hay que a#rupar conjuntos de archivos en unidades componentes y proporcionar la correspondencia se#n las unidades componentes* no por archivos.

..4.@ 'apas de direcciones

07/MARZO/2008

E7iste una coherencia directa entre los accesos y el tr-fico que va y viene del servidor. De notar que se presenta una analo#(a directa entre los m1todos de acceso a disco en los sistemas de archivos convencionales y el m1todo de servicio remoto en un )D. El m1todo de servicio an-lo#o efecta un acceso al disco para cada solicitud de acceso. Una manera de lo#rar esta transferencia es a trav1s del m1todo de servicio remoto* con el cual se entre#an al servidor las solicitudes de acceso* la maquina servidora lleva a cabo dichos accesos y los usuarios se devuelven al usuario

..4.J 'apas de rutas

08/MARZO/2008 En un sistema distribuido* el usar un nombre para los prop$sitos de la comunicaci$n no es bastante. ,orque los procesos en ejecuci$n se comunican desde diferentes computadoras. El conocimiento de su localizaci$n actual es necesario. Esto conduce a los t1rminos b-sicos en esta -reaD un nombre* una direcci$n* y una ruta. El si#nificado de estos t1rminos se puede e7plicar usando las definiciones intuitivas si#uientes %)hoch 1LMI&D 1. El nombre de un objeto %por ejemplo* recursos* servidor& espec(fico que el proceso busca %al qu1 desea tener acceso& .. Una direcci$n especifica donde 1sta 4. Una ruta especifica c$mo esta ah( +ada uno de estos identificadores representa un atascamiento m-s apretado de la informaci$nD 1. !os nombres son mapeados en direcciones. Este mapeo es necesario para la aplicaci$n en ejecuci$n* puesto que la sinta7is y la sem-ntica de nombres dependen enteramente de qu1 tipos de entidades se est-n nombrando y tambi1n qu1 uso se est- haciendo de ellasE y .. !as direcciones son mapeadas en los routeadores.

..4.M 'odelo de erry

14/MARZO/2008

!os mensajes remitentes entre los procesos y objetos soportados por un sistema operativo precisa la presentaci$n para el sistema operativo de los nombres de los objetos que los procesos quieren #anar acceso a. El problema es c$mo localizar objetos nombrados. Esto est- directamente conectado a la #erencia del espacio de nombre y las estructuras de la facilidad de nombramiento. +omo ha visto* acto de servidores de nombre como a#entes obli#atorios distribuidos que amarran el nombre de un objeto para una cierta cantidad de sus propiedades* incluyendo la posici$n del objeto. /l#unos servidores de nombre pueden almacenar informaci$n acerca de los objetos particulares. ales servidores de nombre se llaman las autoridades que nombra o servidores autoritarios de nombre para eso objetan. El problema es c$mo distribuir servidores de nombre* esto es* que de las estructuras de una facilidad de nombramiento es el mejor. !os criterios diferentes pueden ser tomados en cuenta al desarrollar la facilidad de nombramiento para sistemas de c$mputo distribuidos. En la etapa de an-lisis de la estructura de facilidad de nombramiento* usaremos la mayor parte de importante de esos criterios* a saber actuaci$n. Este criterio es importante para un ambiente distribuido porque que hay usualmente un nmero de redes interconectadas %lo mismo es cierto en caso de una red de -rea local conectando un nmero #rande de computadoras personales y G o los puestos de trabajo* y los servidores diferentes&* lo cual insina que el costo de comunicaci$n entre clientes y servidores de nombre es el cuello de botella principal en localizar recursos remotos. En este caso* la actuaci$n de averi#uaciones del servidor de nombre es dominada por el nmero de servidores de nombre que deben ser a los que se #an$ acceso y el costo de #anar acceso a esos los servidores de nombre.

U98D/D 888 ,"3+E)3) O ,"3+E)/D3"E) E9 )8) E'/) D8) "8<U8D3)

01/ABRIL/2008

4.1 ,"3+E)3) O ,"3E+E)/D3"E) +39+E, 3) </)8+3)

Un procesos son todos o todas las actividades o pro#ramas compilados y desuerados que se encuentran #uardados en una memoria. Un procesador es el dispositivo de hardware que se encar#a de ejecutar los procesos. 93 /E )i e7isten varios procesadores dentro de una computadora es un servidor y si e7isten varias computadoras que comparte el servidor es una arquitectura distribuida.

4.. 58!3) O 'U! 858!3)

!os hilos son mini procesos. +ada hilo se ejecuta en forma estrictamente secuencial y tiene su propio contador de pro#rama una pila para llevar un re#istro de su posici$n. !os hilos comparten +,U de la misma forma que lo hacen los procesos secuencialmente y tiempo compartido. )olo en un miltiprocesodor se pueden ejecutar realmente en paralelo. !os hilos pueden crear hilos hijos* mientras un hilo esta bloqueado se puede ejecutar otra fila del mismo proceso en los distintos hilos de un proceso comparten un espacio de direcciones* y los hilos pueden tener distintos estados %en ejecuci$n* bloqueado* listo y terminaci$n&. 'uchos sistemas operativos distribuidos soportan mltiples hilos de control dentro de un proceso que comparten un nico espacio de direcciones que ejecutan casi paralelamente como si fueran procesos independientes. ,or ejemploD Un servidor de archivos que debe bloquearse ocasionalmente en espera de acceso al disco si tiene hilos de control podr(a ejecutar un se#undo hilo mientras el primero espera el resultado seria mejor rendimiento y desempeFo.

4.4 '3DE!3) DE ,"3+E)/D3"E)

En un sistema distribuido con varios procesadores un aspecto fundamental en el diseFo es como se utiliza a los procesadores que se pueden or#anizar de varias formasD De estaci$n de trabajo De pila de procesadores 5ibrido

4.4.1 DE E) /+8;9 DE "/</P3

Este sistema consta de computadoras dispersas conectadas entre si mediante una red de -rea local puede contar o no con disco duro en cada una de ellas* los usuarios tienen una cantidad fija de poder de computo y un alto #rado de autonom(a para asi#nar sus recursos locales. !a idea consiste en ordenar realmente la ejecuci$n de procesos en estaciones de trabajo inactivas. O los aspectos claves sonD Q+omo encontrar una estaci$n de trabajo inactivaR +uando nadie toca el rat$n o teclado* y no se ejecutan procesos iniciados por el usuario. Q+omo lo#rar que un proceso remoto se ejecute de forma transparenteR ,ara ejecutar un proceso en la estaci$n remota seleccionada se debe lo#rar el desplazamiento del c$di#o* la confi#uraci$n del proceso remoto de modo que se vea el mismo ambiente que tendr(a en el caso local* y se ejecute de la misma forma que en el caso local. Q2ue ocurre si re#resa el usuario y ejecuta un procesoR )i re#resa el usuario se puede eliminar el proceso perdi1ndose el trabajo hecho y #enerando un caos en el sistema de archivos* o eliminar el proceso

ordenadamente* salvando el trabajo ya hecho y preservando la inte#ridad del sistema de archivos se podr(a emi#rar el proceso a otra estaci$n de trabajo.

4.4...0'odelo De ,ila De ,rocesadores

02/ABRIL/2008

,ara este modelo se dispone un conjunto de +,U que se pueden asi#nar din-micamente a los usuarios se#n la demanda. 9o e7iste el concepto de propiedad de los procesadores por que permanecen a todos y se utiliza compartidamente. El principio ar#umentado para la centralizaci$n como una pila de procesadores proviene de la teor(a de colas. El modo de pila es m-s eficiente que el modelo de bsqueda de estaciones inactivas.

4.4.4.0'odelo De ,rocesador 5ibrido

03/ABRIL/2008 El modelo hibrido que consta de estaciones de trabajo y una pila de procesadores. !os trabajos interactivos se ejecutan en las estaciones de trabajo mientras que los no interactivos se ejecutan en la pila de procesadores. El modelo de las estacione de trabajo suele coincidir en la actualidad con la mayor(a de las or#anizaciones cuando se utiliza este modelo hay una serie de aspectos atener en cuenta. !a /si#naci$n de procesos de procesadores !os al#oritmos de distribuci$n de la car#a ,lanificaci$n de los procesadores en un sistema distribuido

4.= '3DE!3 D8)ES3 E 8',!E'E9 /+839 DE /!C3"8 '3)

!os /l#oritmos diseFados se escribir-n de forma de pseudos c$di#o* para cada al#oritmo hay c$di#os representativos en el len#uaje de desarrollo 92+. ,ara implementar la arquitectura subsumption se debe implementar el si#uiente m1todoD Un asN encar#ado de manejar todos los comportamientos tambi1n lleva a cabo la coordinaci$n de los comportamientos.

4.@ +3,!/9868+/+8;9

Es en el cual se toman en cuenta los patrones de comunicaci$n entre los procesos durante la planificaci$n para #arantizar que todos los miembros de un #rupo se ejecuten al mismo tiempo.

4.J 3!E"/9+8/ / 6/!!3)

!a tolerancia a fallos es un aspecto cr(tico para aplicaciones a #ran escala* ya que aquellas simulaciones que pueden tardar del orden de varios d(as o semanas para ofrecer resultados deben tener la posibilidad de manejar cierto tipo de fallos del sistema o de al#una tarea de la aplicaci$n. )in la capacidad de detectar fallos y recuperarse de estos* dichas simulaciones pueden no lle#ar a completarse. Es m-s* al#unos tipos de aplicaciones requieren ser ejecutadas en un entorno tolerante a fallos debido al nivel de se#uridad requeridos. De cualquier forma* en ciertos casos deber(a haber al#n modo de detectar y responder autom-ticamente a ciertos fallos del sistema o al menos ofrecer cierta informaci$n al usuario en el caso de producirse un fallo. En ,V' hay un mecanismo de notificaci$n de fallos* de forma que una tarea puede manejar notificaciones sobre ciertas tareas de las que espera recibir un mensaje. ,or ejemplo* si una tarea muere* otra que estuviese esperando un mensaje de la primera recibir- una notificaci$n en lu#ar del mensaje que esperaba. De esta forma* la notificaci$n le da la oportunidad de responder al fallo sin tener que fallar forzosamente.

4.M.0)istema Distribuido En iempo "eal

08/ABRIL/2008 !a capacidad de procesamiento esta distribuida entre varias computadoras interconectadas* las actividades del sistema tiene requerimientos de tiempo* e7iste necesidad de alta capacidad de procesos* distribuci$n f(sica del sistema y tolerancia a fallos. )e considera d1bilmente acoplados se aplica enD )istemas 'ultimedia /viaci$n 6abricaci$n 8nte#rada "ob$tica En medio de comunicaci$n en sistemas mono procesadores el procesado suele ser el nico recurso a planificar* los mensajes tienen un plazo desde que se solicita su envi$ hasta que se recibe. !os procesadores tienen recursos ilimitados* replicaci$n de tareas* requisitos de utilizaci$n de recursos espec(ficos y distribuci$n #eo#r-fica. Utilizan sincronizaci$n de relojes y tolerancia a fallos. UNIDAD IV. MEMORIA COMPARTIDA DISTRIBUIDA. &MCD'

Sincronizacin de relojes
Los algoritmos distribuidos tienen las siguientes propiedades: 1. 2. 3. 4. 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 o e!iste un relo" comn

Los primeros tres aspectos dicen que es inaceptable recoger toda la informacin en un nico punto. El ltimo aspecto es que a#ora nos interesa. En un sistema centrali$ado% el tiempo se solicita mediante una llamada al sistema% como la llamada & '( time. )i un proceso A solicita el tiempo * poco despu+s lo solicita el proceso B, B obtiene un tiempo posterior al de A% *a que ambos consultan el mismo relo". En un sistema distribuido% en que A * B corren en mquinas distintas * consultan distintos relo"es% si el relo" de , es ligeramente ms lento que el de -% , puede conseguir un tiempo posterior al de B a pesar de #abero solicitado antes. .eamos un e"emplo en un sistema distribuido en el que esta anomal/a tiene sus consecuencias. )upongamos que el editor corre en la mquina A * el compilador en la mquina B. A contendr programas con e!tensin .c * B programas con e!tensin .o. )upongamos que disponemos del fic#ero pepo.c en A * de pepo.o en B. )upongamos que el relo" de A es ms lento que el de B * que tras la creacin de pepo.o% pepo.c es rpidamente modificado% tal * como indica la figura 3.1.

Fig. 3.1 0uando cada mquina tiene su propio relo" un evento posterior puede ser etiquetado como anterior.

pepo.c% aunque #a sido creado en un instante posterior en t+rminos de tiempo absoluto% es marcado por el sistema de fic#eros de la mquina del editor como creado en el instante 2143. El ob"eto pepo.o% aunque es ms antiguo% #a sido marcado por el sistema de fic#eros de la mquina del compilador como creado en el instante 2144 1ms antiguo2. El efecto global es que un proceso make de carcter distribuido no detecta que el fuente #a sido modificado porque registra un instante de modificacin anterior al ob"eto. 0omo consecuencia% no se actuali$a el ob"eto * los cambios en el fuente no se traducen en un nuevo e"ecutable% lo que provocar el desconcierto del programador: make no funciona bien% pensar% cuando el problema reside en el sistema operativo% ms concretamente en el registro correcto del tiempo de los eventos en el

sistema% como la creacin de un fic#ero. La cuestin que surge es 3es posible sincroni$ar los relo"es en un sistema distribuido4

Re! 0e% !+1ic %

Leslie Lamport% en 1567 18Les6792% mostr que la sincroni$acin de relo"es para producir un patrn de tiempo comn a ms de una mquina es posible * present un algoritmo para lograrlo. Lamport afirm que no es necesario disponer de un registro comn absoluto del tiempo cuando los procesos no interactan *% cuando lo #acen% tampoco es necesario en la ma*or/a de las aplicaciones. :ara muc#os casos% lo imporante es que los procesos que interactan se pongan de acuerdo en el tiempo en que los eventos ocurren. En el e"emplo de make% lo importante es que pepo.c sea ms antiguo que pepo.o% no el instante preciso de creacin de ambos. ,s/% para ciertas clases de algoritmos% lo que importa es la consistencia interna de los relo"es% no la e!actitud particular de cada uno de ellos. :ara estos algoritmos% es conveniente #ablar de relojes lgicos. 0uando el ob"etivo es mantener todos los relo"es dentro de un margen error dado respecto al tiempo absoluto% es conveniente #ablar de relojes fsicos. Lamport defini la relacin ocurre-antes% a b% le/da ;a ocurre antes que b;% * significa que a ocurre antes que b * todos los procesos estn de acuerdo en ello. Lamport defini esta relacin como sigue: 1. )i los eventos a * b ocurren en el mismo proceso * a ocurre antes que b% entonces a b. .. )i a es el evento que consiste en el env/o de un mensa"e a otro proceso * b es el evento que consiste en la recepcin del mensa"e en otro proceso% entonces a b. 4. )i a b * b c% entonces b c.

Fig. 3.2 Eventos de tres procesos.

:or otra parte% ;ocurre<antes; no es una relacin de orden total% *a que #a* eventos que no estn relacionados entre s/. , estos eventos se les denomina concurrentes. La relacin == se ilustra en la figura 3.2 con tres procesos. En ella podemos ver que a b% *a que los eventos ocurren en este orden en el proceso p1. 'gualmente c d * e f. :or otra parte b c% *a que son los eventos de emisin * recepcin del mensa"e m1. :or la misma ra$n% d f. a * e son eventos concurrentes. 3>u+ es un relo" lgico4 Lamport invent un mecansimo mu* sencillo que e!presaba num+ricamente la relacin ;ocurre antes;. Lo que necesitamos es una funcin C(a) que proporcione el tiempo de un evento a de modo que si a b% entonces C(a) C(b). La

funcin C es denominada un reloj lgico% *a que es una funcin monotnicamente creciente * que no tiene que guardar relacin alguna con ningn relo" f/sico. 0ada proceso guarda su propio relo" lgico. El relo" lgico del proceso p es Cp% encargado de marcar el tiempo de sus eventos. La marca del tiempo lgico asociado a un evento se denomina en la literatura en ingl+s ;timestamp;. osotros la llamaremos la etiqueta temporal. El algoritmo de Lamport sirve para asignar etiquetas temporales a los eventos de un grupo de procesos: 1. En un proceso p% antes de que se produ$ca el siguiente evento% Cp es incrementado% de modo que Cp !Cp"1. 0uando se produ$ca el siguiente evento se le etiqueta con el valor de Cp. 2. a) 0uando un proceso p env/a un mensa"e m% el mensa"e transporta un valor t que es el valor del relo" lgico Cp% su etiqueta temporal. b) 0uando el mensa"e es recibido por un proceso q% entonces q calcula Cq ! ma#(Cq, t) * aplica el paso anterior antes de etiquetar al evento de recibir el mensa"e m. La figura 3.3 ilustra cmo el algoritmo de Lamport etiqueta los eventos de la figura 3.2. 0omo puede apreciarse% si a b% entonces C(a) $ C(b), aunque a * b pertene$can a procesos distintos. Relojes lgicos totalmente ordenados )i ordenamos los eventos por el tiempo lgico en el que ocurren% este criterio introduce un orden parcial en el con"unto de eventos. :arcial porque el relo" lgico no relaciona los eventos a * e de la figura 3.3 *a que son eventos concurrentes * pueden tomar el mismo valor. :ara des#acer el empate podemos a?adir una coma decimal * el identificador de proceso al que pertenece el evento. @endr/amos el evento 1%1 en p1 * 1%3 en p%% llegando a una relacin de orden total en el con"unto de eventos. La figura 3.4 muestra una aplicacin del algoritmo de Lamport para sincroni$ar los relo"es f/sicos de tres mquinas diferentes.

Fig. 3.3 Etiquetas temporales lgicas para los eventos de la figura 3.2.

Relojes fsicos
El d/a solar es el tiempo que transcurre desde que el sol alcan$a su punto ms alto en el #ori$onte #asta que vuelve a alcan$arlo. &n d/a tiene 24 #oras% de modo que definimos el segundo solar como 1A124BCDBCD2 E 1A7C4DD de un d/a solar. En 154D se descubri que la duracin del d/a no era constante. Estudios actuales sobre coral antiguo #an llevado a los gelogos a pensar que #ace 3DD millones de a?os #ab/a 4DD d/as en un a?o. o es que el a?o fuera ms largo. Es que los d/as eran ms cortos. La tierra rotaba sobre s/ misma ms rpido que en la actualidad. ,dems de esta tendencia a largo pla$o% la tierra e!perimenta perturbaciones espordicas en su tiempo de rotacin debido a las turbulencias de su ncleo de #ierro. Estas oscilaciones llevaron a los astrnomos a determinar la duracin del segundo como la media de un gran nmero de ellas. Fividida esta cantidad por 7C4DD obtenemos el segundo solar medio. 0on la invencin del relo" atmico en 1547% la medida del tiempo pas de ser responsabilidad de los astrnomos a ser responsabilidad de los f/sicos. Fefinieron el segundo atmico como el tiempo que tarda el istopo 133 del cesio en reali$ar 5152C3166D transiciones. Este nmero de transiciones fue escogido% por supuesto% porque son las que igualaban la duracin del segundo solar medio el d/a que el segundo atmico fue introducido. El segundo atmico es ms preciso que el segundo solar% pero no es absolutamente preciso. En el mundo e!isten actualmente unos GD laboratorios que disponen de un relo" de 1330s. 0ada uno de ellos registra el nmero de ticHs acumulados desde las cero #oras del primero de enero de 15G7. En :ar/s e!iste una organi$acin que se llama la Ificina 'nternacional de la Jora que promedia los ticHs de estos GD laboratorios. ,l resultado lo divide por 5152C3166D para obtener el @iempo ,tmico 'nternacional 1@,'2. El @,' es e!trordinariamente estable * est a disposicin de cualquiera que lo solicite. )in embargo% como el periodo de rotacin de la tierra est aumentando continuamente% el segundo solar aumenta en la misma medida. ,s/% un d/a solar% que son 7C4DD segundos solares% tiene a#ora 7C4DD.DD3 segundos @,'. &sar el tiempo @,' es ms e!acto% pero llegar un momento que el mediod/a no ser a las 12% sino a las doce * cuarto. Los segundos @,' duran menos que los segundos solares. :ara ello% cuando un relo" solar #a perdido D.7 segundos respecto al tiempo @,'% por e"emplo% el tiempo es de 4.D @,' * de 3.2 solar% se e!tingue ese segundo solar para que pase directamente de 3.2 a 4.D * mantener la sincron/a con el tiempo @,'. Esto da una medida del tiempo con intervalos irregulares% llamado el @iempo &niversal 0oordinado 1&@02% que es la base actual del registro

D
Fig. 3.4 a2 @res procesos% cada uno con su propio relo"% cada uno de ellos con diferente frecuencia. b2 El algoritmo de Lamport corrige los relo"es.

del tiempo. Ja reempla$ado al antiguo estndar de la medida del tiempo% el KL@ 1KreenMic# Leridian @ime2% que es tiempo solar. :ara proporcionar el tiempo &@0% una institucin de Estados &nidos% el 'nstituto acional del @iempo Estndar 1 ')@2% mantiene una estacin de radio de onda corta que radia un pulso cada ve$ que comien$a un segundo &@0. La precisin de esta estacin es de un milisegundo% pero el ruido atmosf+rico eleva este error en la prctica a 1D milisegundos. En 'nglaterra * otros pa/ses e!isten estaciones similares. @ambi+n sat+lites proporcionan el tiempo &@0% * lo #acen con una precisin de D.G milisegundos% veinte veces ma*or que las estaciones de radio de onda corta. El costo de este servicio var/a% segn su e!actitud% entre 1DD.DDD pts * varios millones de pesetas segn su precisin. Ja* un medio ms barato% que es obtenerlo del ')@ por tel+fono. Este es el m+todo ms ine!acto% *a que #a* que corregir el retraso de la se?al en la l/nea * el modem. 0onclu*endo% podemos decir que el tiempo absoluto puede ser proporcionado al computador% pero a un precio alto * siempre con un margen de error no despreciable. Las informacin: #ttp:AAMMM.cstv.to.cnr.itAtoiAuHAutctime.#tml

Algoritmos de sincronizacin de relojes

La medida del tiempo en las mquinas se lleva a cabo mediante un oscilador de cristal. &n c&ip denominado tempori$ador recibe la se?al peridica del oscilador e interrumpe la &0: cada cierto nmero de oscilaciones% previamente programado. .alores t/picos oscilan entre GD * 1DD interrupciones por segundo a la &0:. :or preciso que sea un oscilador a cristal% siempre e!iste un margen de error que conlleva la discrepancia de la medida del tiempo de dos mquinas diferentes. En una red local% por e"emplo% ninguna mquina tiene el mismo registro del tiempo. :ara disminuir la discrepancia entre relo"es% se puede tener acceso a una estacin de onda corta de las *a citadas. El caso general% sin embargo% es que este servicio no est disponible% * el problema que se plantea es% dado un con"unto de mquinas% mantener sus relo"es lo ms cercanos que sea posible mediante softMare. )e #an propuesto para ello muc#os algoritmos% todos ellos con el mismo principio% que a#ora describimos. )e supone que cada mquina dispone de un tempori$ador que interrumpe a la &0: ' veces por segundo. El ncleo dispone de una variable que es incrementada en la unidad por la rutina de interrupcin del relo". Esta variable registra el nmero de ticHs recibidos desde la puesta en marc#a del sistema% por e"emplo. Esta variable se considera el relo" del sistema * vamos a denominar el valor que almacena como C. 0uando el tiempo es t% el tiempo registrado por la mquina p es Cp(t). 'dealmente Cp(t) debiera ser igual a t% para todo p * todo t. En otras palabras% dC(dt debiera ser idealmente 1. @ericamente% un tempori$ador con '!CD interrumpe al relo" sesenta veces por segundo. En una #ora interrumpe CDBCDBCD E 21CDDD veces. En la prctica% se puede contar este nmero de interrupciones * descubrir que no son e!actamente esas% sino que el dato var/a entre 21G557 * 21CDD2 ticHs en una #ora% lo que representa un error relativo de apro!imadamente 1D<G. La precisin de un tempori$ador viene dada por su tasa de deri)a m*#ima D% de modo que si
1- dC 1" dt

se dice que el relo" opera dentro de sus especificaciones. Fos relo"es iguales dentro de sus especificaciones pueden generar una direferencia m!ima en su medida del tiempo cuando la deriva toma en ellos el valor m!imo * de signo opuesto. ,s/% partiendo ambos de cero% en un intervalo t % el relo" uno toma un valor de C1 ( t) ! (1- )t * el relo" dos un valor de C+ ( t) ! (1" )t D% obteniendo una

 t D. )i los dise?adores del sistema desean que nunca diferencia m!ima en la medida de + dos relo"es muestren diferencias ma*ores a una constante D% + t $ D% de modo que t $ ( + D% lo que significa que los relo"es deben ser sincroni$ados cada ( + D segundos. , continuacin vamos a ver algunos algoritmos que llevan a cabo esta resincroni$acin.

El algoritmo de Cristian Este algoritmo requiere que una de las mquinas disponga de un receptor de onda corta * el ob"etivo es lograr que todas las dems operen sincroni$adas con ella. , esta mquina la vamos a llamar un servidor de tiempo. :eridicamente% * siempre antes de ( + segundos% cada una de las mquinas env/a un mensa"e al servidor de tiempo solicitando el tiempo C,-C% que es servido tan rpido como es posible como indica la figura 3.G (( falta ((. El algoritmo tiene dos problemas% uno ms leve * otro ms serio. El ms serio es que un reloj nunca puede ser retrasado. )i el relo" de la mquina que solicita el tiempo es rpido% el tiempo C,-C recogido es menor * su relo" debe ser atrasado. Esto no se puede permitir porque muc#as aplicaciones% como make% conf/an en la secuencia temporal de eventos en el sistema como la base de su operacin. , un evento que ocurre despu+s de otro% como la generacin de un fic#ero ob"eto% no se le puede asignar un tiempo de creacin o ltima modificacin inferior al del programa fuente. La modificacin del relo" debe reali$arse gradualmente. &na forma de #acerlo es la siguiente. )upongamos que el tempori$ador interrumpe la &0: cien veces por segundo% lo que significa que un ticH de relo" es un intervalo de tiempo de die$ milisegundos. La rutina de interrupcin incrementa un contador en el ncleo% el relo"% en una unidad% lo que equivale a sumar al tiempo die$ milisegundos. :ara retrasar el relo" un segundo se puede de"ar de incrementar el contador una de cada cien interrupciones <por e"emplo% la d+cima<% lo que significa que cada segundo retrasamos el relo" die$ milisegundos. :ara retrasarlo un segundo necesitamos cien segundos. :ara adelantar el relo" se puede utili$ar esta misma t+cnica. ,l cabo de 1DD segundos% #abremos adelantado el relo" un segundo. @ambi+n se puede adelantar el relo" de una sla ve$ a?adiendo 1DD ticHs al relo"% *a que el adelantamiento del tiempo no causa problemas. El problema secundario es que desde que una mquina solicita el tiempo C,-C% la r+plica del servidor de tiempo tarda en llegar una cantidad de tiempo no despreciable *% lo que es peor% que var/a con la congestin de la red. El algoritmo de 0ristian aborda este problema intentando medirlo. El cliente registra el tiempo local @D en que env/a el mensa"e * el tiempo @1 en el que llega * estima que la r+plica tard en llegar (-1--.)(+. Este tiempo que es local *% por ser peque?o% relativo e!acto aunque el relo" se #a*a ale"ado sensiblemente del tiempo &@0. (-1--.)(+ se suma al C,-C que trae el mensa"e * el resulado es el C,-C que finalmente el cliente adopta. :ara me"orar la e!actitud se puede reali$ar un muestreo entre distintos tiempos de retorno de la peticin de tiempo * reali$ar una media. )e aconse"a descartar los valores que superan un umbral dado para evitar introducir en la estimacin r+plicas obtenidas en momentos de congestin. El algoritmo de Ber ele! Es el adoptado por & '( -)F. Nrente al algoritmo de 0ristian% basado en un servidor pasivo que responde a las peticiones de clientes% el algoritmo de -erHele* toma una apro!imacin activa. Es til cuando no se dispone del tiempo &@0% v/a un receptor de onda u otro. &n demonio & '( peridicamente reali$a un escrutinio de las mquinas% aquella en la que reside incluida% a fin de obtener el valor de sus relo"es. Oeali$a una media de todos ellos * la comunica a todas la mquinas para que avancen o retrasen sus relo"es.

Algoritmos de "romediado Los algoritmos anteriores tienen la desventa"a de su apro!imacin centrali$ada *% por lo tanto% tienen un nico punto de fallo. :resentamos a continuacin un algoritmo descentrali$ado. Las mquinas dividen el tiempo en intervalos de longitud /% de modo que el comien$o del i<+simo intervalo comien$a en el instante -."i/ se prolonga #asta el instante -."(i"1)/% donde -. es un instante pasado previamente acordado. 0uando comien$a uno de estos intervalos% cada mquina reali$a una difusin del tiempo segn su relo". Febido a la deriba particular de cada relo"% dos difusiones no ocurren simultneamente. Fespu+s de la difusin de su tiempo% cada mquina establece un tempori$ador * espera el mensa"e correspondiente al broadcast del resto de las mquinas en un intervalo 0. 0uando #an llegado todos los mesa"es% un algoritmo de promediado proporciona el nuevo tiempo. El algoritmo ms simple es reali$ar la media aritm+tica de los tiempos. &na variacin es descartar previamente los valores e!tremos a fin de protegernos frente a relo"es defectuosos. Itra variacin es estimar el tiempo de propagacin de cada mensa"e para a?adirlo al tiempo que el mensa"e transporta. Esta estimacin puede llevarse a cabo a partir de un conocimiento previo de la topolog/a de la red o reali$ando mediciones del tiempo de retorno de algunos mensa"es de prueba.

El em"leo de la sincronizacin de relojes

Jasta #ace poco tiempo no se #a presentado la necesidad de sincroni$ar los relo"es de mquinas en una red de rea anc#a. ,#ora es posible sincroni$ar relo"es distribuidos a lo largo de toda la 'nternet en mrgenes de precisin de unos pocos milisegundos respecto al tiempo &@0. La disponibilidad de algoritmos de ba"o costo para mantener la sincroni$acin de relo"es #a incitado el desarrollo de algoritmos distribuidos que e!plotan esta circunstancia disminu*endo el nmero de mensa"es implicados en las versiones que no la e!plotan. , continuacin ilustramos el empleo de la sincroni$acin de relo"es en el problema de la consistencia de la cac#+ de un sistema de fic#eros distribuidos. La referencia 8Lis539 contiene ms e"emplos. &n e"emplo de la utilidad de algoritmos basados en el uso de relo"es sincroni$ados est relacionado con la consistencia de la cac#e de disco en un sistema de fic#eros distribuido. Oa$ones de prestaciones e!igen una cac#+ en el cliente. Fos clientes operando sobre un mismo fic#ero mantienen cada uno de ellos una copia del fic#ero en su propia mquina. La inconsistencia de las cac#+s surge cuando uno de los clientes trata de escribir en el fic#ero. @radicionalmente% cuando un cliente deseaba escribir un fic#ero de su cac#+ solicitaba permiso al servidor. 'nmediatamente% el servidor est obligado a solicitar permiso al proceso o procesos que estn le*endo del fic#ero para que de"en de #acerlo 1* lo descarten de la cac#+2% * esperar a que todos los permisos lleguen antes de conceder el permiso de escritura% lo que introduce una fuerte sobrecarga en tiempo * anc#o de banda en la red. La introduccin de los relo"es sincroni$ados agili$a este tipo de protocolos de los sistemas de fic#eros distribuidos. La idea bsica es que cuando un cliente solicita un fic#ero% el servidor le otorga una concesin en la que detalla el tiempo de e#piracin de la misma 1. 0omo cliente * servidor tienen los tiempos sincroni$ados% el pla$o es el mismo en ambos. Lientras dura la concesin% el cliente tiene la garant/a de que opera sobre el fic#ero de forma consistente. &n cliente no necesita comunicar al servidor que #a terminado la operacin de lectura. )i un cliente solicita la escritura de un fic#ero% el servidor debe pedir a los clientes lectores la terminacin prematura de la concesin. 3>u+ ocurre cuando no #a* respuesta por parte del cliente lector4 El servidor no sabe si el cliente simplemente se #a ca/do. En este caso% el

servidor no obtiene respuesta% lo que plantear/a un problema en el algoritmo tradicional. 0on los relo"es sincroni$ados% simplemente espera a que cumpla el pla$o de la concesin del fic#ero.

E#cl$sin m$t$a
0uando dos o ms procesos comparten una estructura de datos% su lectura o actuali$acin no debe ser simultnea. :ara evitar la simultneidad de acceso% * con ello la incosistencia de la estructura% el cdigo de acceso * actuali$acin de la misma se denomina regin cr/tica * su e"ecucin es protegida mediante construcciones como semforos% monitores% etc. En esta seccin e!aminamos algunos e"emplos de cmo construir regiones cr/ticas en sistemas distribuidos.

%n algoritmo centralizado
La forma ms directa de conseguir la e!clusin mutua en un sistema distribuido es simular al mecanismo de los sistemas centrali$ados. )e requiere de un proceso que acta como coordinador. Este registra las regiones cr/ticas de los procesos. 0uando un proceso desea entrar en una regin cr/tica env/a un mensa"e al coordinador con el nmero de la regin cr/tica. )i ningn otro proceso est e"ecutando la regin cr/tica% el coordinador env/a una r+plica al proceso con la concesin de entrada% tal * como muestra la figura 3.G. 0uando la r+plica llega% el proceso entra en la regin cr/tica.

Fig. 3.& a2 )olicitud * concesin de entrada en regin cr/tica. b2 La concesin se retrasa #asta mientras la regin cr/tica est+ en uso. c2 0oncesin tras ser liberada

)upongamos que el proceso 3 de la figura desea entrar en la misma regin cr/tica antes de que el proceso 2 salga. La peticin llega al coordinador% que sabiendo que el proceso 2 est dentro% no env/a r+plica alguna al proceso 3% que permanece bloqueado esperndola <tambi+n se puede implementar la denegacin mediante un mensa"e<% pero lo registra en la cola de la regin como solicitante. 0uando el proceso 2 sale de la regin cr/tica lo comunica al coordinador mediante un mensa"e de liberacin. El coordinador procesa el mensa"e determinando si e!iste en la cola de la regin reci+n liberada algn proceso esperando. En nuestro caso% efectivamente lo #a*. Es el proceso 3% que por fin recibe el mensa"e de concesin de entrada. Este algoritmo garanti$a la e!clusin mutua. :rimero% el coordinador slo permite entrar en la misma a un proceso. )egundo% es "usto% *a que las peticiones son atendidas en el orden en que llegan. @ercero% ningn proceso espera indefinidamente por la entrada. El esquema es fcil de implementar * es eficiente% *a que requiere tres mensa"es para usar una regin cr/tica. El

defecto principal del algoritmo% como todos los algoritmos centrali$ados es la e!istencia de un nico punto de fallo.

El algoritmo distri'$ido de Ricart ! Agra(ala

Oicart * ,graMala presentaron en 1571 un algoritmo de e!clusin mutua distribuido. 0onsideramos un con"unto de procesos con una esctructura sencilla en la que alternan los clculos fuera de la regin cr/tica * dentro de la regin cr/tica. Las condiciones del algoritmo son las siguientes: 1. Los procesos se comunican mediante mensa"es de capacidad no nula. 2. Los mensa"es pueden llegar a un proceso en cualquier punto de la e"ecucin% bien dentro o bien fuera de la regin cr/tica. Fe cualquier modo una interrupcin% e!cepcin% mane"ador de se?al% etc% se encarga de procesar la llegada del mensa"e. 3. )e asume que la comunicacin es fiable * los mensa"es entre dos procesos son entregados en el orden en el que fueron enviados. 4. Es preciso una relacin de orden total entre los eventos de todo el sistema. 0onsideramos que para que un proceso entre en la regin cr/tica deben tener el permiso todos * cada uno del resto de los procesos% permiso que solicita enviando un mensa"e a todos ellos% v/a multicasting% difusin o uno a uno. El mensa"e acarrea una etiqueta temporal que es el valor del relo" lgico local correspondiente a su env/o. 0uando un proceso recibe un mensa"e de solicitud de permiso% la accin que toma el proceso receptor es la siguiente: 1. )i el receptor no est en su regin cr/tica * no desea entrar en ella% se dice que est en situacin de permiso concedido 10I 0EF'FI2 * env/a inmediatamente un mensa"e de r+plica al proceso que solit el permiso. 2. )i el receptor est e"ecutando en su regin cr/tica% se dice que tiene el permiso 1I@IOK,FI2% no env/a r+plica al emisor * encola la peticin. 0omo vemos% si un proceso no contesta significa que no concede el permiso de entrada. 3. )i el receptor desea tambi+n entrar en la regin cr/tica% pero an no lo #a conseguido se dice que est en estado de solicitud 1)IL'0'@, FI2% compara el relo" del mensa"e entrante con el del mensa"e que #a enviado al resto de los procesos para solicitar el permiso. El ms ba"o gana. )i gana el emisor del mensa"e entrante% el receptor env/a a este la r+plica. )i gana el receptor% encola el mensa"e * no env/a r+plica. La figura 3.C describe el algoritmo ms formalmente. )i el grupo de procesos interesados en la regin cr/tica tiene n procesos% obtener el permiso lleva +(n-1) mensa"es% n-1 para solicitarlo * otros tantos para concederlo. En el algoritmo centrali$ado anterior son necesarios dos mensa"es nicamente. &no para solicitarlo * otro para concederlo% algo que lo #ace muc#o ms eficiente que el algoritmo de Oicart * ,graMala. :or otra parte% en este ltimo todo proceso est involucrado en todas las solicitudes de entrada en la regin cr/tica% para las que debe aportar ciclos de &0:% lo cual resta an ms eficiencia al algoritmo de Oicart * ,graMala. El algoritmo reempla$a un punto de fallo del algoritmo anterior por n puntos de fallo. )i un proceso termina inesperadamente% no responder a ninguna solicitud de entrada% por lo que bloquear al resto% *a que su silencio es interpretado por el resto como que la regin cr/tica est ocupada. Pa que la probabilidad de que uno de los n procesos caiga es n veces superior a que caiga el servidor del algoritmo anterior% es algoritmo de Oicart * ,graMala es n veces menos robusto que el algoritmo del servidor.

En con"unto% el algoritmo es ms lento% ms complicado * menos robusto que el algoritmo centrali$ado% de modo que 3porqu+ molestarse estudindolo4 :orque demuestra que un algoritmo distribuido% sin un control central% es posible% lo que estimula el estudio de soluciones distribuidas ms avan$adas.

El algoritmo en anillo
Esta basado en una disposicin de los n procesos que estn interesados en utili$ar la regin cr/tica en un anillo lgico. )e concede la entrada en la regin cr/tica al proceso que obtiene el denominado testigo. El testigo es un mensa"e que se pasa de proceso en proceso en un sentido nico recorriendo el anillo. 0ada proceso tiene la direccin del proceso al que pasa el testigo. 0uando un proceso recibe el testigo% si no est interesado en la regin cr/tica% pasa es testigo a su vecino. )i necesita entrar en la regin cr/tica% espera bloqueado la llegada del testigo% que es retenido * no es entregado al vecino sino cuando abandona la regin cr/tica. :ara obtener el testigo% como m!imo se emplean n-1 mensa"es. &na desventa"a es que los mensa"es se env/an continuamente aun en el caso de que ningn proceso reclame el testigo. Itra es que este algoritmo tiene n puntos de fallo% si bien la recuperacin es ms fcil que en los casos anteriores. )i cada ve$ que se recibe el testigo se env/a un mensa"e de confirmacin% es sencillo detectar la ca/da de un proceso * retirarlo del anillo.

Algoritmos de eleccin
&na eleccin es un procedimiento cu*a funcin es elegir un proceso en un grupo a fin de que este desempe?e un papel determinado% como puede ser centrali$ar peticiones de entrada en una regin cr/tica% a modo de coordinador. .amos a considerar que los procesos implicados en la eleccin son id+nticos% sin que ninguno de ellos tenga una caracter/stica destacable como para ser el coordinador idneo. 0ada proceso tiene un identificador nico como puede ser su direccin de red. En general% los algoritmos de eleccin intentan locali$ar al proceso con el identificador ms alto para #acerlo coordinador. :ara enviar los mensa"es% los procesos
(niciali,acin* estado*40560E.(.57 Para o#tener el permiso* estado*4S5L(0(/A6.57 multicast de solicitud de permiso al resto7 /*4-elo& lgico del mensa&e de peticin7 8ait until$6)mero de rplicas reci#idas4n19%7 estado*45/5-:A.57 0uando se reci#e una peticin ;0i, pi< en p&* i!$estado45/5-:A.5 or $estado4S5L(0(/A6.5 and 0.p& ; 0.pi% % t2en Encola la peticin de pi sin replicar else -eplica inmediatamente a pi !i Para conceder el permiso tras a#andonar la regin crtica* estado40560E.(.57 -eplica a todos las peticiones en la cola7 Fig. 3.) El algoritmo de Oicart * ,graMala

necesitan conocer las direcciones de red de todo el grupo de procesos en busca de coordinador% de modo que la eleccin *a estar/a #ec#a de antemano. El problema es que los procesos desconocen cules de ellos estn an activos * 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 matn Este algoritmo data de 1572 * es debido a Karc/a<Lolina. 0uando un proceso se apercibe de que el coordinador no responde a sus mensa"es% inicia una convocatoria de eleccin. &na eleccin se desarrolla como sigue: 1. 2 env/a un mensa"e de tipo ELE00'I a todos los procesos con identificadores ms altos. 2. )i ninguno de ellos responde% 2 gana la eleccin * se convierte en el coordinador. 3. En cuanto 2 recibe el mensa"e de respuesta de alguno de ellos% renuncia a ser el coordinador * su traba"o #a terminado. 0ada uno de estos procesos% tras enviar el mensa"e% convocan una eleccin En cualquier momento% un proceso puede recibir un mensa"e ELE0@'I de uno de los procesos con identificador inferior. La rutina que sirve el mensa"e env/a un mensa"e de confirmacin * toma el control iniciando una eleccin% a menos que *a est+ celebrando una. Llega un momento en que todos los procesos renuncian * uno de ellos se convierte en el nuevo coordinador% #ec#o que anuncia al resto de los procesos mediante el env/o de un mensa"e. )i un proceso que inicialmente estaba ca/do se recupera% inicia una eleccin. )i es el de identificador ms alto% ganar la eleccin * asumir el papel de coordinador. )iempre gana el proceso de identificador ms grande% de a#/ el nombre del algoritmo. En la figura 3.6 vemos el desarrollo de una eleccin en un grupo de oc#o procesos numerados del D al 6% siendo este ltimo el coordinador que% en un momento dado% de"a de estar operativo. El proceso 4 es el primero en darse cuenta de que el coordinador no responde * convoca una eleccin% enviando un mensa"e de tipo ELE00'I a los procesos G% C * 6% los dos primeros confirmando el mensa"e. En cuanto el proceso 4 recibe la confirmacin del proceso G da su traba"o por terminado. )abe que +l no ser el coordinador% sino uno de los superiores que #an confirmado. Los procesos G * C convocan elecciones de forma ms o menos simultnea. El proceso cinco recibe confirmacin del C * renuncia. El proceso C no recibe confirmacin alguna% de modo que se erige en ganador% algo que anuncia al resto envindoles un mensa"e 0IIOF' ,FIO. El proceso 4% que estaba esperando el resultado de la eleccin <aunque *a lo casi lo conoc/a< reanuda su traba"o% esta ve$ con un nuevo coordinador.

*ransacciones atmicas
El paradigma cliente<servidor proporciona una buena forma de estructurar el sistema * de desarrollar aplicaciones% pero necesita del concepto de transaccin para controlar secuencias comple"as de interacciones entre el cliente * el servidor. )in transacciones no se puede conseguir que los sistemas distribuidos funcionen en las aplicaciones t/picas de la vida real. Los conceptos de transacciones fueron concebidos para poder abordar la comple"idad de las aplicaciones on<line en sistemas de un nico procesador. Estos conceptos% *a veteranos% son

#o* d/a incluso ms cr/ticos en la implementacin con +!ito de sistemas masivamente distribuidos% que operan * fallan en formas muc#o ms comple"as. Los sistemas de proceso de trasacciones fueron pioneros en conceptos de computacin distribuida * computacin tolerante a fallos. Ellos introdu"eron los datos distribuidos en aras de la fiabilidad% disponibilidad * prestaciones. Ellos desarrollaron el almacenamiento tolerante a fallos * el proceso tolerante a fallos a fin de garanti$ar la disponibilidad de datos * aplicaciones. P fueron ellos quienes desarrollaron el modelo cliente<servidor * las llamadas a procedimiento remoto para la computacin distribuida. P% lo ms importante% las propiedades ,0'F de las transacciones #an emergido como los conceptos unificadores de la computacin distribuida 18Kra5392. 0omo puede apreciarse% no es posible obviar el tpico de las transacciones atmicas en un curso sobre sistemas distribuidos. En esta seccin nos ocupamos de ellas% tratando algunos de sus mltiples aspectos.

Fig. 3.+ &n e"emplo del algoritmo del matn.

,ntrod$ccin a las transacciones atmicas

:ensemos en una primitiva de sincroni$acin como un semforo. )ubir o ba"ar un semforno es una operacin de mu* ba"o nivel que obliga al programador a tratar los detalles de la e!clusin mutua% la gestin de la regin cr/tica% la recuperacin en caso de fallo% etc% cuando opera sobre datos compartidos. Lo que nos gustar/a en un entorno de datos compartidos * con componentes susceptibles de fallo es disponer de primitivas de manipulacin de datos de ms alto nivel que permitan al programador: 1. 0oncentrarse en el problema% ignorando que los datos son accedidos de forma concurrente 2. 'gnorar que un fallo puede de"ar los datos en un estado inconsistente.

Estas primitivas se utili$an ampliamente en los sistemas distribuidos 1su finalidad es compartir datos * recursos * tienen ms posibilidades de fallo2 * se llaman transacciones atmicas. El uso de las transacciones se remonta a los a?os CD cuando los datos se almacenaban en cintas magn+ticas. &na base de datos resid/a en una cinta. que se llamaba el =fic#ero maestroQ. Las actuali$aciones resid/an en una o ms cintas 1por e"emplo las ventas diarias o semanales2 llamadas =fic#eros de movimientosQ. Laestro * movimientos se montaban en el computador para producir un nuevo fic#ero maestro% que ser/a utili$ado al d/a o a la semana siguiente con nuevos fic#eros de movimientos. La venta"a de este m+todo <no reconocida suficientemente en aquellos a?os< es que si el programa que llevaba a cabo las actuali$aciones fallaba% se produc/a una ca/da en la alimentacin el+ctirica% etc * el proceso de actuali$acin se interrump/a% siempre se pod/a descartar la nueva cinta que #ab/a quedado a medias * volver sobre el maestro * las actuali$aciones para generar de nuevo el fic#ero maestro. ,s/% una actuali$acin del maestro proced/a correctamente #asta el final o no se modificaba en absoluto. Esta propiedad era una transaccin atmica sobre el ob"eto =fic#ero maestroQ. 0onsideremos a#ora una aplicacin bancaria que reali$a una retirada de una cantidad de una cuenta * el ingreso correspondiente en otra cuenta distinta. )i el computador falla despu+s de la retirada * antes del ingreso% el dinero se desvanece. :uede que ambas cuentas residan en distintas mquinas * el fallo se deba a una p+rdida de la cone!in telefnica entre ambas operaciones. )er/a necesario agrupar ambas operaciones en una transaccin atmica como en el e"emplo de la cinta magn+tica que garanti$ase que la operacin se reali$a completamente o no se reali$a. La clave reside en volver al estado inicial de las cuentas si es que se #a producido un fallo en mitad del proceso. Esta #abilidad es proporcionada por las transacciones atmicas.

Ser-icios transaccionales
0onviene e!aminar la aplicacin bancaria anterior en el conte!to del modelo cliente<servidor. 0uando decimos que un servidor porporciona operaciones atmicas significa que el efecto de desarrollar una operacin en beneficio del cliente: 1. Est libre de interferencia de las operaciones reali$adas en beneficio de otros clientes 2. -ien la operacin conclu*e completamente o no tiene efecto alguno si el servidor falla. &na transaccin entre un cliente * un servidor es una secuencia de interacciones. El servidor bancario proporciona las operaciones Depsito% Retirada% Balance% TotalSucursal. sobre una serie de ob"etos% en este caso cuentas: Depsito(Cuenta, Cantidad) Feposita la cantidad Cantidad en la cuenta Cuenta Retirada(Cuenta, Cantidad) Oetira la cantidad Cantidad de la cuenta Cuenta Balance(Cuenta) Cantidad Fevuelve el balance de la cuenta Cuenta TotalSucursal Total Fevuelve la suma de todos los balances

0onsideremos un cliente que quiere reali$ar una serie de operaciones sobre las cuentas ,% -% 0. La primera operacin transfiere 1DD pesetas de , a -. La segunda transfiere 2DD pesetas de 0 a -: Transaccin: T: Retirada(A, 100) Depsito(B, 100) Retirada(C, !00) Depsito(B, !00) "ndTransaccin(T) 0omo vemos% desde el punto de vista del cliente% una transaccin es una secuencia de operaciones que se reali$an en un slo paso% llevando al servidor de un estado consistente a otro. El cliente no es consciente de que otros clientes pueden reali$ar operaciones sobre las cuentas , * -. , un servidor de este tipo se le conoce como servidor transaccional o que provee de un ser)icio transaccional. En un servicio transaccional% el cliente% cuando inicia una transaccin con el servidor% emite la peticin A#rirTransaccin * el servidor le devuelve un indentificador de transaccin. Este indentificador ser usado en las operaciones siguientes. El cliente notifica al servidor el final de la secuencia de operaciones mediante la primitiva CierraTransaccin. A#rirTransaccin Trans ,rranca en el servidor una nueva transaccin * devuelve un nico identificador de transaccin o @'F% que ser usado como parmetro en el resto de las operaciones de la transaccin CerrarTransaccin(Trans) (Compromiso, A#orto) @ermina la transaccin. )i devuelve un compromiso% indica que la transaccin se #a comprometido 1se #a reali$ado en su totalidad2. )i devuelve un valor de ,borto% la transaccin no se #a reali$ado. A#ortarTransaccin(Trans) ,borta la transaccin

La transaccin puede abortar por varias ra$ones. Entre ellas la naturale$a misma de la transaccin * su desarrollo% conflictos con otra transaccin o el fallo de procesos o mquinas. La transaccin puede ser abortada% tanto por el cliente como por el servidor. 0uando el servidor decide unilateralmente abortar la transaccin en curso% la operacin en curso devuelve un cdigo de error como )EO.EOR,-IO@. .eamos cual es el comportamiento de cliente * servidor en presencia de fallos: Fallo en el ser-idor )i un servidor transaccional falla inesperadamente% cuando vuelve a arrancar% aborta toda transaccin no comprometida utili$ando un procedimiento de recuperacin para restaurar los valores de los items de datos provisionales a los valores definitivos producidos por la transaccin comprometida ms recientemente previa al fallo. Oeplica al cliente la operacin solicitada con un valor )EO.EOR,-IO@. Itra posibilidad es que el cliente d+ un pla$o de respuesta al servidor para cada operacin emitida. )i el servidor se recupera dentro del pla$o% contina con la transaccin en curso en lugar de abortarla. Fallo en el cliente

)i un cliente falla inesperadamente en el desarrollo de una transaccin% el servidor puede dar un pla$o de e!piracin a la transaccin. )i una nueva operacin de la transaccin no llega en ese pla$o el servidor aborta la transaccin e inicia el procedimiento de recuperacin.

.ro"iedades de las transacciones atmicas

Las transacciones tienen cuatro propiedades fundamentales que se conocen por el acrnimo ,0'F: Atomicidad% Consistencia% seriali$abilidad o aislamiento 1=,solationQ2 * /urabilidad. Atomicidad La atomicidad garanti$a que la transaccin procede #asta que se completa o no se reali$a en absoluto. )i se completa% esto ocurre en una accin indivisible e instantnea. Lientras una transaccin est en progreso% otros procesos% est+n o no est+n implicados en transacciones% no pueden ver los estados intermedios. :or e"emplo% supongamos una transaccin que se ocupa de a?adir octetos a un fic#ero de 1D octetos. Lientras la transaccin esta en curso% otro proceso debe ver un fic#ero de slo 1D b*tes. 0uando la transaccin se compromete% el fic#ero instantnemente aparece con su nuevo tama?o. &n sistema de fic#eros que garanti$a este comportamiento es un sistema de fic#eros transaccional. La ma*or/a de los sistemas de fic#eros no son transaccionales. Consistencia La propiedad de la consistencia obliga cumplir ciertos invariantes de los datos del servidor. :or e"emplo% como resultado de una transferencia interna% una sucursal bancaria debe mantener el mismo dinero en su saldo que antes de que la transaccin se realice. La consistencia de los datos puede ser violada por el cliente si las operaciones que emite no son consistentes * por el servidor si no dispone de un adecuado mecanismo de control de concurrencia. )i las operaciones de forman una transaccin @ que emite un cliente son consistentes% el servidor garanti$a que la consistencia de los datos que @ comparte con otra transaccin & no va ser violada por la concurrencia de las operaciones de &. Serializa'ilidad La tercera propiedad dice que las transacciones deben ser aisladas. ,islada significa transacciones concurrentes en un servidor no interfieren las unas con las otras. &na forma de lograr el aislamiento es anular la concurrencia del servidor de modo que e"ecute las transacciones de forma estrictamente secuencial% una tras otra. El ob"etivo de un servidor% sin embargo es ma!imi$ar sus prestaciones% algo que pasa por la atencin concurrente al ma*or nmero de transacciones posible. Esto significa que si un servidor est atendiendo a dos o ms transacciones simultneamente que operan sobre datos compartidos por los clientes <un fic#ero% por e"emplo<% el servidor transaccional debe garanti$ar que el resultado final de estos datos es aquel que produce una reali$acin estrictamente secuencial de las transacciones. Esta reali$acin% no obstante% es decidida arbitrariamente por el servidor. )upongamos que un servidor transaccional mantiene una variable # que es accedida por tres clientes. Las transacciones de los clientes en un momento dado son las siguientes: .roceso 1: A#rirTransaccin $ :% 0 $ :% $ & 1 CerrarTransaccin

.roceso 2: A#rirTransaccin $ :% 0 $ :% $ & ! CerrarTransaccin .roceso 3: A#rirTransaccin $ :% 0 $ :% $ & ' CerrarTransaccin Las peticiones de las distintas transacciones llegan al servidor entrela$adas. , cada secuencia de e"ecucin de las peticiones por parte del servidor se le llama entrela$ado o planificacin. )i el servidor es transaccional% no todas las planificaciones son vlidas. En la tabla que sigue vemos tres planificaciones posibles% donde el tiempo transcurre #acia la derec#a: Plani!icacin 9 Plani!icacin = Plani!icacin > ! :E DS ! :E ! T ! :E DS 1S ! :E DS ! :E DS ! :E ! T 1S ! :E DS ! :E DS ! :E ! T 1S tiempo ! :E ! T 2S ! :E ! T 2S ! :E DS ! :E DS ! :E DS ! :E ! T 2S ! :E ! T 3S ! :E ! T 3S ! :E ! T 3S legal legal ilegal

En la planificacin 1 las transacciones son e"ecutadas de forma estrictamente secuencial% * el valor final es 3. Fecimos que esta planificacin #a sido seriali$ada. La planificacin 2 no es seriali$ada% pero es legal por que% al final% # toma un valor que podr/a #aber sido alcan$ado por una planificacin estrictamente secuencial. La planificacin 3 es ilegal% *a que # termina con un valor de G% valor que imposible alcan$ar con una planificacin seriali$ada. E0$i-alencia serial )i un entrela$ado de dos o ms transacciones tiene el mismo efecto sobre los datos que alguna e"ecucin seriali$ada de dic#as transacciones decimos que el entrela$ado es serialmente equivalente. La planificacin 2 de la figura es serialmente equi)alente. /$ra'ilidad &na transaccin debe ser durable. Esta propiedad establece que si un servidor compromete una transaccin <por e"emplo con una r+plica a una primitiva CerrarTransaccin(Trans)que devuelva el valor Compromiso<% no importa lo que ocurra% los cambios son *a permanentes. ingn fallo despu+s del compromiso puede desacer los resultados o causar su desaparicin% con la consiguiente confusin posterior en el cliente.

Rec$"eracin de transacciones
30mo se implementan las transacciones4 30mo se garanti$a la atomicidad% de forma que todas las operaciones se reali$an o no se realia$a ninguna de ellas4 30mo se reanuda una transaccin ante una ca/da del servidor4 30mo se implementa la durabilidad4 E!isten varios m+todos en uso. , continuacin vamos a e!aminar uno de ellos: el de la lista de intenciones o =Mritea#ead logQ. ,ntes de que un bloque de un fic#ero en un servidor transaccional sea escrito como consecuencia del servicio a una peticin% el servidor escribe en disco% en un

fic#ero denominado =logQ% qu+ transaccin est #aciendo el cambio% qu+ fic#ero * bloque pretendemos cambiar * cul es el nuevo valor del bloque < o rango de octetos afectados dentro del bloque <. )lo despu+s de que el registro de la operacin se #a reali$ado completamente en el =logQ% se #ace la modificacin en el fic#ero.
$ :% 0 ( :% 0 A#rirTransaccin() $ :% $ & 1 ( :% ( & ! $ :% ( ) ( CerrarTransaccin()

tiempo Log ! :E DA1

Log ! :E DA1 * :E DA2

Log ! :E DA1 * :E DA2 ! :E 1A4 1d2

1a2

1b2

1c2

Fig. 3.1 1a2 &na transaccin. 1b2<1d2 El log antes de que cada operacin sea e"ecutada.

La figura 3.7 muestra cmo funciona el log. En 1a2 tenemos una transaccin que usa dos variables compartidas 1u otros ob"etos2% $ e (% ambas iniciali$adas a cero. :ara cada una de las operaciones de la transaccin% el log es escrito antes de e"ecutar la operacin. El valor antiguo ( el nuevo se muestran separados por una barra inclinada. El log va creciendo a medida que las operaciones de la transaccin se van e"ecutando. )i todas las operaciones tienen +!ito% el servidor% al recibir la primitiva CerrarTransaccin% escribe en el log una marca que significa que la transaccin est comprometida. )upongamos que el cliente aborta la transaccin mediante una primitiva A#ortarTransaccin()% entonces el servidor restaura los valores de las variables $ e ( a partir de la informacin del log. , esta accin se le denomina rebobinado o rollbac3. El log tambi+n se usa para recuperacin del fallos en el servidor. )upongamos que el servidor de la figura 3.7 se cae despu+s de #aber escrito en el log la ltima modificacin de $ 142 pero antes de cambiarla. 0uando el servidor arranca% e!amina el log para determinar si alguna transaccin estaba en curso cuando se produ"o la ca/da. El servidor descubre que la variable $ tiene el valor 1 mientras que el log registra el valor de 4. Est claro que la ca/da se produ"o antes de la actuali$acin efectiva de la variable% de modo que se actuali$a a 4 * espera la llegada de una nueva operacin desde el cliente. )i% tras el rearranque% $ vale 4% est igualmente claro que la ca/da se produ"o despu+s de la actuali$acin *% por lo tanto% no necesita ser cambiada. &sando el log% es posible ir #acia adelante o #acia atrs en la transaccin.

.rotocolos de com"romiso atmico

Es posible que los datos que mane"a una transaccin est+n distribuidos en dos o ms servidores. , estas transacciones se las denomina transacciones distribuidas. &no de los servidores acta como coordinador * al resto se les considera tabajadores. La primitiva A#rirTransaccin()% se env/a al coordinador. El identificador de la transaccin Trans devuelto al cliente es utili$ado por este para comunicar a los traba"adores que estn involucrados en una transaccin. ,s/% dos nuevas primitivas son necesarias en las transacciones distribuidas: A*adirSer+idor(Trans, ,dCoordinador) 0on esta primitiva% el cliente informa al servidor traba"ador que est implicado en la transaccin Trans * qui+n es el coordinador en la transaccin -ue+oSer+idor(Trans, ,dCoordinador)

'nvocada por un nuevo traba"ador que se incorpora a la transaccin dirigida al coordinador para informarle de su participacin. El coordinador toma nota en una lista de traba"adores. 0on estas primitivas% el coordinador conoce cules son los traba"adores * los traba"adores conocen cul es el coordinador% informacin que necesitarn cuando llegue el tiempo de reali$ar el compromiso de la transaccin. Furante el progreso de la transaccin% no #a* comunicacin entre el coordinador * los traba"adores aparte del paso del mensa"e con el que cada traba"ador informa al coordinador cuando se incorpora a una transaccin. La figura 3.7 muestra el desarrollo de una transaccin distribuida.

Fig. 3.1 &na transaccin bancaria distribuida.

&no de los mecanismos que garanti$an la atomicidad de las transacciones distribuidas es el denominado protocolo de compromiso en dos fases % que% aunque no es el nico% s/ es el ms ampliamente utili$ado. 0uando se utili$a el protocolo de compromiso en dos fases% la llamada CerrarTransaccin o A#ortarTransaccin por parte del cliente se dirige al coordinador. Es cuando se invoca CerrarTransaccin cuando comien$a el protocolo de compromiso en dos fases. La figura 3.5 ilustra el protocolo.

Fig. 3.2 El protocolo de compromiso en dos fases

,l recibir CerrarTransaccin% el coordinador escribe una entrada en un log diciendo que el protocolo #a comen$ado *% a continuacin% env/a un mensa"e a los traba"adores comunicndoles que su traba"o #a terminado * que se preparen para comprometerse. 0uando el traba"ador recibe el mensa"e% comprueba que est preparado para comprometerse% #ace una anotacin en su log * env/a un mensa"e al coordinador con su decisin. 0uando el coordinador #a recibido todas las respuestas% sabe si comprometer la transaccin o abortarla. )i todas las respuestas son favorables% la transaccin se compromete. )i alguna de ellas no es favorable% la transaccin se aborta. Ja concluido la primera fase. 0omprometida o abortada% la decisin acerca de la suerte de la transaccin es escrita por el coordinador en su log * env/a un mensa"e a cada traba"ador informndole sobre la decisin% que tambi+n env/a al cliente como la r+plica a CerrarTransaccin. )i el coordinador falla despu+s de #aber escrito la marca =:reparadoQ en el log% tras el rearranque puede continuar donde lo de". )i se cae despu+s de #aber de #aber escrito en el log el resultado de la votacin% tras el rearranque puede reinformar a los traba"adores de este. )i un traba"ador se cae antes de #aber replicado al primer mensa"e% el coordinador seguir envindole mensa"es #asta que renuncie. )i falla despu+s% tras el rearranque descubre donde estaba * contina el traba"o.

Control de conc$rrencia
En general% un servidor e"ecuta operaciones en beneficio de varios clientes cu*as operaciones pueden estar entrela$adas. Las transacciones atmicas permiten a los clientes especificar secuencias atmicas de operaciones. Estas secuencias de operaciones deben ser planificadas en el servidor de tal forma que su efecto sobre los datos compartidos sea serialmente equivalente. Estos m+todos de planificacin son conocidos como m+todos o algoritmos de control de concurrencia. Esta seccin vamos a e!aminar tres de ellos.

Blo0$eo
&n e"emplo simple de mecanismo de seriali$acin es el uso de bloqueos e!clusivos. En este m+todo% el servidor intenta bloquear cualquier dato que utili$a la transaccin en curso. )i el clienteP pide el acceso a un dato que *a #a sido bloqueado por otra transaccin de un cliente (%

la peticin es suspendida * el cliente P debe esperar #asta que el dato sea desbloqueado. La figura 3.1D ilustra el uso de los bloqueos e!clusivos. *ransaccin *3 Retirada(A, .) Depsito(B, .) 5peraciones A#rirTransaccin #alance :% *ransaccin %3 Retirada(C, ') Depsito(B, ') 5peraciones

?loqueos #lo/uea A

?loqueos

A.Read() A."scri#e(#alanc e0.) A#rirTransaccin #alance :% C.Read() #lo/uea C C."scri#e(#alance0 ') #alance :% B.Read() #alance :% B.Read() espera por B B."scri#e(#alanc e&.) CierraTransacci Des#lo/uea n A,B #lo/uea B B."scri#e(#alance & ') CierraTransaccin
Fig. 3.14 Fos transacciones concurrentes con bloqueos e!clusivos

#lo/uea B

des#lo/uea B, C

,mbas transacciones comparten la cuenta bancaria - * el problema es ma!imi$ar todo lo posible la concurrencia de estas transacciones mediante una planificacin serialmente equivalente. La planicacin de la figura #a sido reali$ada mediante el algoritmo de bloqueo en dos fases% que consiste en que a una transaccin no se le permite bloquear un nuevo dato si es que *a #a #a cedido un bloqueo. Esta pol/tica conduce a que cada transaccin tiene una primera fase denominada fase de crecimiento en la que adquiere todos los bloqueos sobre los datos que accede * una segunda fase en la que libera los bloqueos% denominada fase de reduccin en que libera los datos que de"a de utili$ar. ,s/% en la figura 3.1D vemos cmo la transaccin @ bloquea la cuenta , * accede a ella% despu+s & bloquea la cuenta 0 * accede a ella * @ bloquea - * accede a ella. 0omo @ no va a utili$ar ms datos% la fase de crecimiento de @ #a terminado. En ese instante% & se dispone a acceder a la cuenta - * trata de bloquearla pero se encuentra con que & *a la #a bloqueado% de modo que le toca esperar #asta que @ la libere cuando #a*a terminado con ella. Es entonces cuando la bloquea para s/ * termina su fase de crecimiento. 0omo vemos% el algoritmo de bloqueo en dos fases garanti$a la serialidad de una planificacin * proporciona cierto grado de concurrencia. :or esta ra$n% es ampliamente utili$ado. En algunos sistemas% la fase de reduccin no empie$a #asta que la transaccin no #a acabado% bien por que se #a comprometido o bien por que #a sido abortada. , esta variante se la

denomina bloqueo en dos fases estricto. La figura anterior lo utili$a. La venta"a es que toda transacin siempre lee un valor escrito por una transaccin comprometida. En el algoritmo no estricto% ser/a posible que en la fase de reduccin de una transaccin @ libersemos el bloqueo de un dato% * antes de concluir la fase de reduccin% otra transaccin & accediese a ese dato. La fase de reduccin de @ contina% pero antes de concluir recibe una operacin de aborto por parte del cliente. La transaccin entera debe ser desec#a rebobinando el log. El problema es que a#ora & tiene un dato errneo <denominado lectura sucia<% por lo que el servidor debe tomar la decisin de abortar &. Este aborto puede provocar nuevos abortos% etc. En suma se evitan los denominados abortos en cascada.

Control de conc$rrencia o"timista

Uung * Oobinson 115712 identificaron un nmero de desventa"as del mecanismo de bloqueo * propusieron una apro!imacin alternativa optimista a la seriali$acin de transacciones que evitan sus defectos. Entre los defectos del bloqueo identificaron los siguientes: El mantenimiento de los bloqueos representa una sobrecarga para un servidor transaccional. 'ncluso las transacciones que slo leen datos% como las bsquedas% que no tienen posibilidad de afectar a la integridad de los datos% necesitan bloqueo de tipo lectura a fin de garanti$ar que el dato que se est le*endo no es modificado por otras transacciones al mismo tiempo. El uso de los bloqueos% incluso el bloqueo en dos fases% puede conducir a interbloqueos. )i dos procesos tratan cada uno de adquirir el mismo par de bloqueos pero en orden opuesto% resulta el bloqueo. Los interbloqueos se pueden prevenir utili$ando t+cnicas como numerar los datos en un orden cannico e imponiendo a la transaccin un acceso a los mismos en orden creciente. Nrente a la evitacin del interbloqueo est el permitir que se produ$can *% cuando esto ocurre% detectarlo. :or e"emplo% se puede imponer a la transaccin que no mantenga un bloqueo sobre un dato un tiempo ma*or de - segundos. 0uando esto ocurre% salta un tempori$ador asociado al dato% lo que indica que con alta probabilidad se #a producido un interbloqueo. :ara evitar abortos en cascada% los bloqueos no pueden se cedidos #asta el final de la transaccin% lo que reduce sustancialmente el grado de concurrencia. La alternativa de Uung * Oobinson es optimista porque est basada en la observacin de que% en la ma*or/a de las veces la verosimilitud de que dos transacciones accedan al mismo dato es ba"a. , las transacciones se les permite continuar como si no #ubiese posibilidad de conflicto #asta que el cliente emite la primitiva CerrarTransaccin. Es a#ora% antes de comprometer la transaccin cuando se evala la posibilidad de conflicto con otras transacciones. )i se detecta% la transaccin no se compromete% sino que simplemente se aborta para que el cliente la reinicie% esta ve$ qui$ con me"or suerte. 0ada transaccin sigue tres fases% la fase de lectura% la fase de validacin * la fase de escritura. 1. Fase de lect$ra. El servicio de la transaccin constru*e una copia de los datos que la transaccin utili$a. , esta copia se la denomina tambi+n )ersin tentati)a. La transaccin traba"a sobre la copia * no sobre los fic#eros reales. Las operaciones de lectura son reali$adas inmediatamente% bien desde la copia o% si an no se #a creado la copia de un dato% desde la versin real ms recientemente comprometida. Las operaciones de escritura registran los valores de los datos en la copia. 0uando varias transacciones acceden al mismo dato% varias copias de ese dato coe!isten% una por transaccin. .. Fase de -alidacin. 0uando se recibe la operacin CierraTransaccin la transaccin se valida. , grandes rasgos% si los datos que utili$a la transaccin en curso #an sido utili$ados por otras transacciones desde que comen$ la transaccin en curso% la validacin falla. )i la

validacin tiene +!ito% la transaccin se compromete. En caso contrario% debe utili$arse alguna forma de resolucin de conflicto * bien abortar la transaccin actual o aquellas implicadas en el conflicto. 3. Fase de escrit$ra. )i la transaccin es validada% todos los cambios registrados en la versin tentativa se #acen permanentes. Las transacciones de slo lectura pueden comprometerse inmediatamente% mientras que las de escritura tienen que esperar a ser grabadas en disco.

Eti0$etado tem"oral
&na apro!imacin completamente diferente al control de concurrencia es asignar una etiqueta temporal a la transaccin en el cliente cuando este invoca A#rirTransaccin. &sando el algoritmo de Lamport% podemos asegurar que las etiquetas temporales son nicas. El algoritmo de control de concurrencia basado en etiquetas temporales utili$a tambi+n el concepto de copias o versiones tentativas de los datos. ,s/% cada transaccin dispone de una copia para cada dato al que accede. Las operaciones de escritura se graban en versiones tentativas #asta que el cliente emita la primitiva CerrarTransaccin en que la transaccin se compromete * la versin tentativa del dato se transforma en definitiva. @anto el dato como cada una de sus copias tienen asociados una etiqueta temporal de escritura. El dato tiene un con"unto de etiquetas de lectura que son resumidas por la etiqueta ms reciente. 0uando una transaccin se compromete% la copia de cada dato accedido por la transaccin se convierte en el dato * la etiqueta temporal de cada copia se convierte en la etiqueta temporal del dato correspondiente. En control de concurrencia por etiquetado temporal% el servidor comprueba que cada operacin de lectura o escritura sobre un dato es conforme con las reglas de conflicto. &na operacin de la transaccin en curso @" puede entrar en conflicto con operaciones previas #ec#as por otras transacciones @i bien comprometidas% bien an no comprometidas. Las reglas de conflicto son las siguientes. Regla 1. 2. 3. *j Escritura Escritura Lectura

@" no debe escribir un dato que #a sido le/do por alguna @i ms reciente 1@i V @"2 @" no debe escribir un dato que #a sido escrito por alguna @i ms reciente @" no debe leer un dato que #a sido escrito por una @i ms reciente

Regla de escrit$ra. 0ombinando las reglas 1 * 2 tenemos la siguiente regla para decidir si aceptar una operacin de escritura de la transaccin @" sobre el dato F.
T2 m3$ima eti/ueta de lectura en D A-D T2 4 eti/ueta de escritura del dato comprometido D T5"- reali6a la operacin de escritura en la copia de D con eti/ueta de escritura T2 "7S" A#orta la transaccin T2 () "s demasiado tarde )) "-D ,1

>ue significa que: )i @" es ms moderna que la transaccin que cre el dato * es ms moderna que la transaccin que le* el dato por ltima ve$% entonces escribe en la copia. En caso contrario aborta la transaccin.

Regla de lect$ra. &sando la regla 3 tenemos el siguiente procedimiento para decidir si aceptar inmediatamente% esperar o rec#a$ar una operacin de lectura de la transaccin @" sobre el dato F.
,1 T2 4 eti/ueta de escritura del dato comprometido D T5"Sea Ds la copia 8ec8a por la transaccin m3s reciente m3s anti9ua o i9ual /ue T2 ,1 Ds no e$iste T5"- 7ee de D "7S" "sperar 8asta /ue la transaccin /ue copi Ds se comprometa o a#orte "-D "7S" A#orta T2 "-D

tese que: )i @" *a #a escrito en la copia su versin del dato% este ser el usado. &na operacin de lectura que llega demasiado pronto <transacciones ms antiguas que tambi+n usan F an no se #an comprometido< espera a que la transaccin anterior se comprometa. )i la transaccin anterior se llega a compometer% entoces @" leer de su versin comprometida. )i aborta% @" repetir la operacin de lectura 1* seleccionar la versin previa2. Esta regla evita las lecturas sucias. &na lectura que llega demasiado tarde% es decir% otra transaccin ms reciente *a #a escrito el dato * se #a comprometido% es abortada. 0onviene repasar el mecanismo de escritura con un e"emplo. )upongamos que tenemos tres transacciones :% > * O de etiquetas temporales E :% E> * EO respectivamente. : e"ecut #ace muc#o tiempo * utili$ todos los fic#eros que van a utili$ar > * O. @odas las etiquetas temporales de estos fic#eros valen E :. > * O comien$an concurrentemente% siendo O ms moderna que >% por lo que la etiqueta temporal E> W EO. 0onsideremos una operacin de > en la que accede a un fic#ero para escribir. Las etiquetas de lectura * escritura de este fic#ero son O N * XN respectivamente% : se comprometi #ace tiempo * tenemos que ON E E: * XN E E:. )e cumple la condicin del ,1 de escritura * se actuali$a la copia de N con la escritura #ec#a por >. ,#ora la etiqueta de la copia de N de la transaccin >% XN>% es E> 1XN> E E>2% pero la etiqueta del dato sigue siendo la anterior E: 1XN E E:2. )upongamos a#ora que% despu+s de que > escribe sobre N% pero antes de que > se comprometa% O reali$a una operacin de escritura sobre el fic#ero N. 0omo el dato N no se #a tocado% las condiciones son las mismas que antes: en el ,1 de escritura se compara la etiqueta de la transaccin * la de la versin comprometida del dato% de modo que se actuali$a la copia de N de O. @enemos a#ora dos copias de N% con etiquetas 1XN> E E>2 * 1XNO E EO2% mientras la etiqueta de escritura del dato N es 1XN E E:2. 0omo vemos% ambas transacciones operan concurentemente% despreocupadas% cada una escribiendo sobre su propia copia. )upongamos que% una ve$ creadas ambas copias% O se compromete. Esto significa que >% siendo anterior a O% #a llegado al servidor demasiado tarde. .eamos lo que ocurre cuando O intenta escribir sobre N. @enemos que E O W XN% *a que O acaba de escribir * comprometerse% luego no se cumple la segunda condicin del ,1 de escritura * la transaccin O aborta. 0omo vemos% este mecanismo es% en cierto sentido% optimista% En el m+todo de Uung * Oobinson% esperamos que dos transacciones no usen los mismos fic#eros. ,qu/ no nos importa si dos transacciones usan los mismos fic#eros. )lo que la transaccin ms antigua llegue antes. )i O llega antes que >% * reali$a una operacin de lectura% O aborta no importa si > se compromete o no.

Oepasemos tambi+n el mecanismo de lectura. 0onsideremos una operacin de > en la que accede a un fic#ero para leer. Las etiquetas de lectura * escritura de este fic#ero son ON * XN respectivamente% : se comprometi #ace tiempo * tenemos que ON E E: * XN E E:. )e cumple la condicin del ,1 de lectura. o #a* otras transacciones en curso% por lo que no #a* que esperar a otra transaccin ms reciente * se lee del dato N. La etiqueta de lectura del dato es a#ora E > 1ON E E>2. )upongamos a#ora que% despu+s de que > lee de N% pero antes de que > se comprometa% O reali$a una operacin de lectura sobre el fic#ero N. 0omo el dato N no se #a tocado% las condiciones son las mismas que antes: en el ,1 de lectura se compara la etiqueta de la transaccin > * la versin comprometida de escritura del dato N% de modo que pasamos a comprobar si una transaccin ms antigua que O tiene alguna copia de N. 0omo ni > ni ninguna otra transaccin #an tratado de escribir sobre N% no e!iste ninguna copia% por lo que la lectura se atiende * la etiqueta de lectura del dato N se actuali$a a E O 1ON E EO2. En el caso de que > #ubiese escrito N antes de que O le*ese% esta copia s/ e!istir/a% por lo que si O lee del dato% leer/a una versin obsoleta. Es me"or leer de la copia% ms actual% pero 3>u+ ocurre si > aborta4 Estar/amos le*endo un valor errneo. La solucin es que O debe esperar a que > se comprometa para leer de N. Ibservemos que esta espera no se produce en el caso de escritura% donde cada transaccin escribe su propia copia del dato. Eso s/% si O se compromet/a antes que >% > deb/a abortar.

UNIDAD V. USOS Y TENDENCIAS DE LOS SISTEMAS DISTRIBUIDOS.

5istoria de Amoe'a
/moeba es un projecto que naci$ en la Universidad de Vrije* /msterdam en 1LI1. El profersor /ndrew anenbaum era el l(der del projecto y sus colaboradores tres estudiantes de tesis doctoral. En 1LI4 sali$ a la luz /moeba 1.K. En la actualidad* /moeba es un projecto en el colaboran varias instituciones en toda Europa. !a versi$n que estudiamos en este cap(tulo es /moeba @... Meta% "e !a in2e%ti1aci+n 'uchos projectos de investi#aci$n sobre sistemas distribuidos toman como base una versi$n de U98: y le aFaden nuevas caracter(sticas como llamadas al sistema de comunicaci$n a trav1s de red* servidores de ficheros y otros fin de hacerlo m-s distribuido. /moeba* por el contrario* parti$ desde el principio confi#ur-ndose como un sistema completamente nuevo. !a idea era e7perimenar con nuevas ideas sin el lastre de #arantizar compatibilidad al#una a las aplicaciones. !a primera finalidad de /moeba era construir un sistema operativo distribuido transparente. Un usuario se conecta al sistema en un terminal a trav1s de lo9in y lanza comandos en la manera convencional. !a diferencia es que la ejecuci$n de un comando implica a muchas m-quinas en lu#ar de a una sola* ya que los servicios prestados por /moeba se encuentran dispersos en las mismas. En /moeba no e7iste el concepto de Tm-quina localT* en la que se lanza un comando y* si est- sobrecar#ada* se busca su ejecuci$n en otra remota. El shell inicial corre ya en otra m-quina y los comandos los lanza a m-quinas menos car#adas. / diferencia del modelo de estaci$n de trabajo* los recursos de una m-quina no est-n dedicados a su usuario propietario* sino que todos

los recursos de todas las m-quinas pertenecen al sistema en conjunto. Un ejemplo es el comando amake* la respuesta de /moeba al comando U98: make. / diferencia de make* amake hace que las compilaciones se realicen en serie o en paralelo y en las m-quinas que /moeba considere oportunas* todo ello con total transparencia para el usuario. Una se#unda meta de /moeba es proporcionar un banco de pruebas para trabajar en aplicaciones paralelas y distribuidas. En la actualidad* /moeba es utilizado en projectos de investi#aci$n sobre al#oritmos* len#uajes y aplicaciones paralelas y distribuidas. ,ara este pr$posito* ha sido diseFado un len#uaje espec(fico denominado 3rca. /moeba* sin embar#o* ha sido escrito en +.

6a ar0$itect$ra 7ard(are de Amoe'a

/ntes de entrar en la estructura de /moeba* es preciso comentar las caracter(sticas del hardware en el que ejecuta /moebaD 1. El sistema tiene un #ran nmero de U+,Us. .. +ada U+, tiene decenas de 'bytes de memoria. /unque en la mayor(a de las or#anizaciones no se dispone de hardware de estas caracter(sticas* en un futuro pr$7imo* si estar-n disponibles. El problema principal que trata de resolver /moeba es c$mo poner a dispoci$n de los usuarios del sistema un #ran nmero de U+,Us* tal vez miles. )upon#amos un sistema con 1KKK U+,Us. Una forma de asi#narlas es dar a cada usuario un mutiprocesador de @K U+,Us. )in embar#o* la mayor(a del tiempo* casi todos los procesadores de este multiprocesador estar-n ociosos y* adem-s* cuando este usuario decida ejecutar una aplicaci$n masivamente paralela* que necesite m-s de @K procesadores* se encontrar- que no puede hacer uso de los multiprocesadores de otros usuarios. !a apro7imaci$n al problema de /moeba es disponer la potencia de c-lculo en el fondo de procesadores* al modo de la fi#ura @.1. +ada una de las U+,Us tiene su propia memoria local y su cone7i$n a la red. !os procesadores pueden ser ),/"+* 7IJ o JIK7K. /moeba ha sido diseFada para tratar con arquitecturas hetero#1neas y es incluso posible que un proceso cree un hijo que ejecute en una U+, de aquitectura distinta. Vamos a e7aminar los tres componentes esenciales de /moebaD el fondo de procesadores* los terminales y los servidores.

3i1. 4.1 !a arquitectura de /moeba.

El fondo de procesadores es compartido por todos los usuarios. +uando un usuario emite un comando* /moeba eli#e el procesador en el que ejecutarlo.

+uando la ejecuci$n termina* el procesador es devuelto al fondo. +uando el fondo se a#ota* los procesadores operan en multiproceso* siendo el comando asi#nado a una de las U+,Us menos car#adas. !os procesadores no tienen que ser necesariamente computadores en una nica tarjeta placa. ,ueden ser estaciones de trabajo o ,+Us ya e7istentes. !a ubicaci$n de estas placas o estaciones es irrelevante. ,ueden estar incluso en diferentes pa(ses. !a ventaja de la placa nica frente a las estaciones estriba en que no es preciso #astar en teclados* monitores* etc. El se#undo elemento del sistema son los terminales. ,ueden ser terminales : o ,+Us corriendo un servidor :0windows. !a combinaci$n de fondo de procesadores m-s terminales : hace posible un sistema /moeba con un fondo de @K procesadores y 1KK terminales : para 1KK usuarios frente a la soluci$n de compar 1KK estaciones de trabajo por el mismo precio. El ltimo componente de un sistema /moeba son los servidores. !os servicios se prestan a los clientes a trav1s de su definici$n* con independencia de cu-ntos servidores cooperan para proporcionarlo. !a tolerancia a fallos del servicio se lo#ra mediante la replicaci$n de servidores. !os servidores son procesos que no ejecutan en los procesadores del fondo* sino en m-quinas dedicadas para aumentar su eficiencia.

6a ar0$itect$ra soft(are de Amoe'a

/cabamos de e7aminar el hardware de /moeba. /hora presentaremos el software. /moeba se divide en dos piezas* una es el microNernel* que reside en todas las U+,Us del fondo de procesadores* y otra es una colecci$n de servidores* que proporcionan la funcionalidad del sistema operativo. E! *icr 5erne! A* e/a El microNernel tiene cuatro funciones principalesD 1. Cestionar procesos e threads. .. ,roporcionar un nivel bajo de #esti$n de memoria. 4. +omunicaciones. =. 'anejadores de dispositivo. En cuanto a la #esti$n de memoria* un thread puede solicitar y liberar bloques de memoria denominados se#mentos. !os se#mentos pueden ser le(dos y escritos y pueden ser asi#nados y desasi#nados al espacio de direccionemiemto de un thread. /moeba proporciona dos tipos de comunicaci$n. Una es punto a punto y la otra es comunicaci$n de #rupo. !a comunicaci$n punto a punto est- basada en el modelo cliente0servidor* en el que el cliente env(a un mensaje a un servidor y se bloquea hasta que lle#a la r1plica. +asi todo /omeba se basa en este paradi#ma. ,ara cada dispositivo asociado a una m-quina hay un manejador compilado y enlazado al ncleo. !a comunicaci$n entre un servidor de ficheros y un manejador se realiza mediante el env(o de un mensaje al manejador se#uido de una r1plica de 1ste se#n el modelo cliente servidor* donde el servidor de ficheros acta como un cliente del manejador de disco. !as dos formas de comunicaci$n de /moeba hacen uso del protocolo de red 6!8,* espec(ficamente diseFado para ser utilizado en comunicaci$n distribuida. L % %er2i" re% A* e/a

odo aquello que no es estrictamente imprescindible en el ncleo reside en un servidor. Esta es la filosof(a microNernel. ,or otra parte* /moeba estconstruido sobre el modelo cliente servidor. Ceneralmente* los usuarios escriben los clientes y los pro#ramadores del sistema escriben los servidores* si bien el usuario es libre de escribir sus propios servidores. ambi1n central en /moeba es el concepto de objeto. Un fichero* por ejemplo* es un objeto con una operaci$n caracter(stica como read* entre otras.!os objetos son #estionados por servidores. )on objetos los ficheros* los directorios* se#mentos de memoria* ventanas* procesadores* discos* etc. odos ellos son accedidos de una manera uniforme que se denomina capacidad. /s(mismo* todos ellos contienen un cabo que esconde los detalles de comunicaci$n a los clientes. )e dispone de un compilador de cabos para los usuarios que construyen sus propios servidores.

8'jetos ! ca"acidades en Amoe'a

Un objeto /moeba es b-sicamente un tipo abstracto de datos. !os objetos son pasivos en el sentido de que no continen procesos o m1todos u otras entidades activas. +ada objeto es #estiondo por un servidor. ,ara realizar una operaci$n sobre un objeto* un cliente invoca una llamada ",+ sobre el servidor del objeto. En la llamada se especifica el objeto* la operaci$n y sus par-metros* si los hay. El thread cliente ",+ se bloquea hasta que se obtiene la r1plica. !os clientes desconocen en qu1 m-quinas residen los objetos y sus servidores. ,ueden localizarse en la m-quina del cliente o en otra a miles de Nil$metros de distancia. ,or otra parte* la mayor(a de los servidores corren en espacio de usuario pero no todos ellos lo hacen as(. ,or ejemplo* el servidor de se#mentos corre en el ncleo en aras de la eficiencia. Esta distinci$n es tambi1n invisible para los procesos cliente* a fin de que el pro#ramador se concentre en lo que tiene que hacer* no d$nde lo tiene que hacer.

Ca"acidades
+ada objeto es nombrado y prote#ido mediante un TticNetT denominado una capacidad. ,ara crear un objeto* un cliente emite una llamada ",+ a un servidor adecuado. El servidor crea el objeto y devuelve una capacidad al cliente. En las consi#uientes operaciones sobre el objeto* el cliente presenta la capacidad para identificar el objeto. Una capacidad es simplemente un nmero binario mostrado en la fi#ura @... El campo puerto del ser"idor es una direcci$n l$#ica que identifica al servidor. El puerto est- asociado al pro#rama y no a la m-quina en la que ejecuta. +uando un cliente quiere realizar una operaci$n sobre un objeto*

Fig. &.2 &na capacidad en ,moeba

llama a un procedimiento de biblioteca que construye un mensaje que

contiene la capacidad y* a continuaci$n* ejecuta un trap al ncleo. El ncleo nicamente e7amina el puerto del servidor. Una tabla interna re#istra la m-quina en la que el servidor est- actualmente ejecutando. El resto de la capacidad es i#norado por el ncleo* que lo pasa al servidor. El campo objeto lo utiliza el servidor como un identificador del objeto implicado. ,or ejemplo* dado un servidor de ficheros* el objeto es un fichero y el campo objeto viene a ser como el nmero de i0nodo del fichero en un sistema U98:. El campo derec0os es un mapa de bits que informa de* entre las operaciones que es posible realizar sobre el objeto* cu-les son las permitidas al proceso que presenta la capacidad. El campo c0ec1 se usa para validad la capacidad. )$lo el campo puerto es e7aminado por el ncleo. El resto es manipulado por el proceso de usuario y reenviado al servidor. Es el servidor el que se ocupa de detectar falsificaciones de capacidades por parte de los procesos de usuario.

.roteccin de o'jetos
Vamos a presentar el al#oritmo utilizado por /moeba para prote#er los objetos. +uando un cliente crea un objeto* necesita una capacidad para acceder al mismo despu1s. En atenci$n al mensaje de creaci$n* el servidor eli#e un nmero aleatorio C. Este nmero es almacenado en una tabla interna y tambi1n es devuelto en el campo checN de la capacidad al proceso que cre$ el objeto. Esta capacidad devuelta al proceso creador se denomina capacidad de propietario y tiene todos los bits del campo derechos puestos a 1. !a capacidad de propietaro puede ser comunicada por 1ste a otros procesos de usuario a fin de que estos puedan realizar operaciones sobre el objeto* pero #eneralmente es m-s conveniente enviarles capacidades restrin#idas como e7aminaremos despu1s. )i el resto de los procesos desconoce el campo checN y env(an uno err$neo* el servidor lo detectar- y abortar- la operaci$n. /divinar la comprobaci$n C de un objeto %=I bits& tiene una probabilidad de 1G.=I* al#o realmente dif(cil. En ocasiones* el propietario de un objeto desea compartilo* pero restrin#iendo los derechos de acceso. ,or ejemplo* otros usuarios podr-n leer* pero no escribir el objeto. En /moeba* nuevos derechos si#nifica #enerar una nueva capacidad* denominada capacidad restrin#ida. !a fi#ura @.4 muestra c$mo se #enera la capacidad restrin#ida* que ahora tendr- un nuevo campo de derechos y un nuevo campo de comprobaci$n.

3i1. 4.6 Despacho de una petici$n de #eneraci$n de capacidad restrin#ida

El propietario del objeto env(a la capacidad de propietario al servidor por el mecanismo usual* m-s un nuevo mapa de derechos en el mensaje. El servidor toma el campo de comprobaci$n C almacenado en sus tablas* y realiza una operaci$n 3" e7clusiva de C* y el nuevo mapa de derechos* m. /l resultado* le aplica una funci$n f de modo que , 2 f-C 34R m/. , es el campo de comprobaci$n de la capacidad restrin#ida. El servidor replica al cliente con la nueva capacidad* que tiene un nuevo campo de derechos* m* y el nuevo campo de comprobaci$n* ,. El propietario puede comunicar esta capacidad restrin#ida a otros procesos. )upon#amos que el propietario u otro proceso al que ha comunicado la capacidad restrin#ida realiza una operaci$n sobre el objeto presentando esta nueva capacidad de campos m e ,. El servidor ve que no todos los bits del campo derechos son unos* lo que si#nifica que la capacidad es restrin#ida. Entonces* calcula ,5 2 f-C 34R m/. )i , 2 ,5 entonces la operaci$n es aceptada. El cliente tiene la contraseFa. ,uede confiarse en 1l. )i no es as(* la operaci$n falla. ,ara un cliente con una capacidad restrin#ida sobre un objeto* resulta tentador presentar un campo m con todos unos y tratar de adivinar C a partir de ,* que es el c$di#o de comprobaci$n del que dispone. ,ara ello puede aplicar la funci$n t 2 f6&-,/ y* a continuaci$n e7traer C a partir de t y de m. El problema es que el cliente no dispone de la funci$n f y* aunque as( fuera* la definici$n de f no permite obtener el inverso. / estas funciones se las denomina funciones de sentido nico.

8"eraciones est9ndar
/l#unas operaciones sobre objetos dependen del tipo de objeto mismo* por ejemplo aFadir octetos a un fichero* pero e7isten operaciones que son comunes a la mayor(a de los objetos. Estas operaciones sonD A9eD Es posible crear un objeto y despu1s perder la capacidad para el objeto. Este objeto nunca ser- accedido y consumir- recursos de forma improductiva. /moeba debe proporcionar un mecanismo para* de al#una forma solucionar este problema. +onsiste en que todo servidor dispon#a de una rutina de reco#ida de basuras % 7arba*e collection&. )e ejecuta

peri$dicamente y elimina todos los objetos que no han sido accedidos al cabo de n ciclos de reco#ida. ,ues bien* la llamada a#e obli#a a que se ejecute un ciclo de reco#ida. Cop(D Es un atajo que hace posible que se duplique un objeto sin tr-fico en la red. )in esta primitiva* hacer una copia de un fichero conlleva el traslado del fichero al cliente en una operaci$n de lectura* y despu1s del cliente al servidor en una operaci$n de creaci$n de la copia. Destro(D Elimina un objeto. 3bviamente* se necesitan los permisos necesarios. :etparams y SetparamsD ratan con el servidor m-s que con un objeto particular. ,ermiten al administrador del sistema leer y escribir par-metros que controlan la operaci$n del sistema. ,or ejemplo* se puede seleccionar el al#oritmo para ele#ir procesadores con este mecanismo. ,n;o y statusD Devuelven informaci$n de estado. El primero devuelve una cadena de caracteres que describen el objeto brevemente. !a se#unda ofrece informaci$n del servidor como* por ejemplo* la memoria libre que le queda. /yuda al administrador del sistema. RestrictD Cenera una capacidad restrin#ida para un objeto dado.

:estin de "rocesos en Amoe'a

En /moeba* un proceso es b-sicamente un espacio de direccionamiento m-s una colecci$n de threads dentro del mismo. En esta secci$n e7plicamos c$mo funcionan y c$mo se han implementado los procesos y los threads en /moeba.

.rocesos
En /moeba* un proceso es un objeto. +uando un proceso se crea* al padre se le proporciona una capacidad para el proceso hijo como si fuese un objeto cualquiera. 'ediante esta capacidad* el padre puede suspenderlo* reanudarlo* seFalarlo o destruirlo. !a creaci$n de un proceso en /moeba es diferente de la de U98:. En U98:* el padre invoca ;ork para crear una copia de s( mismo. !a copia invoca a continuaci$n e$ec para convertirse en un nuevo proceso. !a creaci$n del proceso replicado representa una fuerte sobrecar#a en un entorno distribuido* ya que supone* entre otras cosas* asi#narle memoria para despu1s liberarla y asi#nar nueva memoria al proceso resultado de e$ec. /s(* en /moeba* el nuevo proceso es creado en un procesador determinado desde el comienzo* sin necesidad de invocar una costosa llamada intermedia como ;ork. !a #esti$n de procesos se lleva a cabo en /moeba en tres niveles. En el nivel m-s profundo se encuentran los ser"idores de procesos. !os servidores de procesos son threads dentro del espacio de direccionamiento del ncleo* se#n muestra la fi#ura @.=. 5ay un servidor de procesos en cada m-quina. ,ara crear un proceso en una m-quina B* otro proceso en una m-quina A realiza un ",+ con el servidor de procesos de B.

3i1. 4.7 Despacho de una petici$n de #eneraci$n de capacidad restrin#ida

En el si#uiente nivel de la jerarqu(a de procesos se encuentra una biblioteca de procedimientos que los procesos de usuario invocan para crear un proceso. !as rutinas de esta biblioteca est-n divididas a su vez en dos niveles* llamados interface de alto nivel e interface de bajo nivel. Estos ltimos hacen su trabajo invocando a los procedimientos de interface de bajo nivel. De estos ltimos son dos los que m-s nos interesan. e$ec es el m-s importante. iene dos par-metros* el primero es la capacidad de un servidor de procesos y el se#undo es un puntero a un descriptor de proceso. )u funci$n es hacer un ",+ con el servidor de proceso dado como primer par-metro para que corra el proceso dado como se#undo par-metro. Devuelve la capacidad del nuevo proceso* que ser- utilizada por su creador para controlarlo. Un se#undo procedimiento importante es 9etload. Devuelve informaci$n sobre la U+,* su car#a actual y la memoria libre. Es invocada #eneralmente por el servidor de ejecuci$n para decidir cu-l es la mejor m-quina en la que lanzar un proceso. De entre los procedimientos de alto nivel podemos destacar ne<proc. ne<proc toma como ar#umento una cadena de caracteres que es nombre del fichero ejecutable y unos punteros a cadenas con el nombre de los ar#umentos y el entorno. /l#o similar a la llamada U98: e$ec. ,ar-metros adicionales proporcionan m-s control sobre el estado inicial. En el nivel m-s alto se encuentra el servidor de ejecuci$n* que es el que hace el trabajo de determinar d$nde correr un proceso. ,ara ello invoca a la biblioteca de interface anterior. ,ara un proceso de usuario* la forma m-s sencilla de crear un proceso es invocar al servidor de ejecuci$n.