Instituto Tecnolgico Superior de Coatzacoalcos

ROJAS SANTIAGO CESAR ROBERTO

Docente: Eduardo Lpez de los SantosActividad : ENSAYOUnidad 2

Sincronizacin en Sistemas Distribuidos

Ya hemos visto la forma en que los procesos se comunican entre si en un sistema distribuido. Los mtodos que analizamos fueron los protocolos con capas, transferencia de mensajes solicitud/respuesta (RPC incluida) y comunicacin en grupo. Aunque la comunicacin es importante, no es todo lo que hay que considerar. Intirnamente relacionada con esto est la forma en que los procesos cooperan y se sincronizan entre s. Por ejemplo, la forma dc implantar tas regiones crticas o asignar recursos en un sistema distribuido. En los sistemas con un CPU, los problemas relativos a las regiones crticas, la exclusin mutua y la sincronizacin se resuelven en general mediante mtodos tales como los semforos y los monitores. Estos mtodos no son adecuados para su uso en los sistemas distribuidos, puesto que siempre se basan (de manera implcita) en la existencia de la memoria compartida. Por ejemplo, dos procesos que interactan mediante un semforo deben tener acceso a ste. Si se ejecutan en la misma mquina, pueden compartir el semforo al guardarlo en el ncleo y realizar llamadas al sistema para tener acceso a l. Sin embargo, si se ejecutan en mquinas distintas, este mtodo ya no funciona, por lo que se necesitan otras tcnicas. Incluso las cuestiones ms sencillas, como el hecho de determinar si el evento A ocurri antes o despus del evento B requiere una reflexin cuidadosa. Comenzaremos con el tiempo y la forma de medirlo, puesto que ste juega un papel fundamental en algunos modelos de sincronizacin. SINCRONIZACIN DE RELOJESLa sincronizacin es ms compleja en los sistemas distribuidos que en los centralizados, puesto que los primeros deben utilizar algoritmos distribuidos. Por lo general, no es posible (o recomendable) reunir toda la informacin relativa al sistema en un lugar y despus dejar que cierto proceso la examine y tome una decisin, como se hace en el caso centralizado. En general, los algoritmos distribuidos tienen las siguientes propiedades: 1. La informacin relevante se distribuye entre varias mquinas. 2. Los procesos toman las decisiones slo con base en la informacin disponible en forma local. 3. Debe evitarse un punto de fallo en el sistema. 4. No existe un reloj comn o alguna otra fuente precisa del ~iempo global. Los primeros tres puntos indican que es inaceptable reunir toda la informacin en un lugar para su procesamiento. Por ejemplo, para llevar a cabo la asignacin de recursos (asignar los dispositivos de E/S en una forma libre dc bloqueos), por lo general no es aceptable enviar todas las solicitudes aun administrador de procesos, el cual examina a todos y otorga o niega las solicitudes con base en la informacin de sus tablas. En un sistema de gran tamao, tal solucin pone en predicamentos a dicho proceso. Adems, el hecho de que slo exista un punto de fallo como ste hace que el sistema no sea confiable. Lo ideal es que un sistema distribuido debera ser ms confiable que las mquinas individuales. Si alguna de ellas falla, el resto puede continuar su funcionamiento. Lo ltimo que quisiramos es una situacin donde una mquina falle (por ejemplo, el asignador de recursos) y con ello detenga a un gran nmero de mquinas diversas. Para lograr la sincronizacin sin centralizacin necesitamos algo distinto al caso dc los sistemas operativos tradicionales. El ltimo punto de la lista tambin es crucial. En un sistema centralizado, el tiempo no tiene ambiguedades. Cuando un proceso desea conocer la hora, llama al sistema y el ncleo se la dice. Si el proceso A pide a hora y un poco despus, el proceso B tambin la pide, el valor obtenido por B es mayor o igual que el valor obtenido porA. Ciertamente, no debe ser menor. En un sistema distribuido, no es trivial poner de acuerdo a todas las mquinas en la hora. Por ejemplo, pensemos por un momento las implicaciones de la carencia de un tiempo global en el programa make de UNIX. En UNIX los programas de gran tamao se dividen por lo general en varios archivos fuentes, de modo que un cambio al archivo fuente slo necesite una nueva compilacin de un archivo y no de todos. Si un programa consta de 100 archivos y no hay que volverlo a compilar por la modificacin de un archivo, la velocidad de trabajo de los programadores aumenta en gran medida. La forma de funcionamiento de make es muy sencilla. Cuando el programador termina de modificar todos los archivos fuentes, inicia make, el cual examina las horas en que todos tos archivos fuentes y objetos fueron modificados por ltima vez. Si el archivo fuente input.c tiene la hora 5456 y el correspondiente archivo objeto input.o tiene la hora 5455, make sabe que nput.c tiene modificaciones desde la creacin de input.o, por lo que entonces hay que volver a compilar input.c. Por otro lado, si output.c tiene la hora 2 144 y output.o tiene lahora2 145, entonces no es necesario volvera compilar. As, make revisa todos los archivos fuentes para determinar aquellos que deban volverse a compilar y llama al compilador para que realice esta tarea. Puesto que el tiempo es fundamental para la forma de pensar de la gente y el efecto de carecer de sincronizacin en los relojes puede sermuy drstico, como hemos visto, podemos iniciar nuestro estudio de la sincronizacin con la siguiente sencilla pregunta: "Es posible sincronizar todos los relojes en un sistema distribuido? RELOJES LGICOS.Casi todas las computadoras tienen un circuito para el registro del tiempo. A pesar del uso generalizado de la palabra "reloj" para hacer referencia a dichos dispositivos, en realidad no son relojes en el sentido usual., cronmetro sera una mejor palabra. Un cronmetro de computadora es por lo general un cristal de cuarzo trabajado con precisin. Cuando se mantiene sujeto a tensin, un cristal de cuarzo oscila con frecuencia bien definida, que depende dei tipo de cristal, la foriina en que se corte y la magnitud de la tensin. A cada cristal se le asocian dos registros, un contador y un registro mantenedor. Cada oscilacin del cristal disminuye en 1 a contador, cuando el contador toma el valor 0, se genera una interrupcin y el contador se vuelve a cargar mediante el registro mantenedor. De esta forma, es posible programar un cronmetro de modo que genere una interrupcin 60 veces por cada segundo o con cualquier frecuencia que se desee. Cada intenrupcin recibe el nombre de marca de reloj. Cuando se arranca por vez primera el sistema, por lo general se pide al operador que escriba la fecha y la hora, las cuales se convierten al nmero de mareas despus de cierta fecha conocida y se guardan en la memoria. En cada marca de reloj, el procedimiento de servicio de interrupciones aade 1 al tiempo guardado en memoria. De esta forma, el reloj (de software) se mantiene actualizado. En el caso de una computadora y un reloj, no importa si ste se desfasa un poco. Puesto que todos los procesos de la mquina utilizan el mismo reloj, tendrn consistencia interna. Por ejemplo, si el archivo input.c tiene la hora 251 y el archivo influj.o tiene la hora 250, make vuelve a compilar el archivo fuente, aunque el reloj se desfase en 2 y los tiempos reales sean 253 y 252, respectivamente. Todo lo que importa son los tiempos relativos. Tan pronto se comienza a trabajar con varias mquinas, cada una con su propio reloj, la situacin es distinta. Aunque la frecuencia de un oscilador de cristal es muy estable, es imposible garantizar que los cristales de computadoras distintas oscilen precisamente con lamisma frecuencia. En la prctica, cuando un sistema tienen computadoras, los n cristales correspondientes oscilarn a tasas un poco distintas, lo que provoca una prdida de sincrona en los relojes (de software) y que al leerlos tengan valores distintos. La diferencia entre los valores del tiempo se llama distorsin del reloj. Como consecuencia de esta distorsin, podran fallar los programas que esperan que el tiempo asociado a un archivo, objeto, proceso o mcnsaje sea correcto e independiente del sitio donde haya sido generado (es decir, del reloj utilizado), como hemos visto en el ejemplo anterior de make. Esto nos regresa a nuestra pregunta original, saber si es posible sincronizar todos los relojes para obtener un estndar de tiempo nico, sin ambignedades. En un artculo clsico, Lamport(l 978) demostr que la sincronizacin de relojes es posible y present un algoritmo para lograr esto. Ampli su trabajo en (Lamport, 1990). Lamport seal que la sincronizacin de relojes no tiene que ser absoluta. Si dos procesos no interactian, no es necesario que sus relojes estn sincronizados, puesto que la carencia de sincronizacin no seria observable y por tanto no podra provocar problemas. Adems, senal que lo que importa por lo general, no es que todos los procesos concuerden dc manera exacta en la hora, sino que coincidan en el orden en que ocurren los eventos. En el ejemplo anterior de make, lo que importa es si inpul.c es anterior o posterior a input.o y no la hora exacta en que fueron creados. Para la mayora de los fines, basta que todas las mquinas coincidan en la misma hora. No es esencial que esta hora tambin coincida con la hora real, como se anuncia en la radio cada hora. Por ejemplo, para ejecutar nake, es adecuado que todas las mquinas estn de acuerdo en quesean las 10:00, aunque en realidad sean las 10:02. As, para una cierta clase de algoritmos, lo que importa es la consistencia interna de los relojes, no su panicular cercana al tiempo real. Para estos algoritmos, conviene hablar de los relojes como relojes lgicos. Cuando existe la restriccin adicional de que los relojes no slo deben ser iguales, sino que adems no se desven del tiempo real ms ah de cierta magnitud, los relojes reciben el nombre de relojes fsicos". A continuacion analizaremos elalgoritmo de Lamport, el cual sincroniza los relojes lgicos. Lamport defini una relacin llamada ocurre antes de. La expresin A B se lee: A ocurre antes de B, e indicaque todos los procesos coinciden en que primero ocurre el evento A y despus el evento B. La relacrn "ocurre antes de" se puede observar de manera directa en dos situaciones: Si A y B son eventos en el mismo proceso y A ocurre antes de B, entonces A ~ B es verdadero. 2. Si A es el evento del envio de un mensaje por un proceso y B es el evento de la recepcin del mensaje por otro, entonces A ~ B tambin es verdadero. Un mensaje no se puede recibir antes de ser enviado o al mismo tiempo en que se enva, puesto que tarda en llegar una cantidad finita de tiempo. "Ocurre antes de" es una relacin transitiva, de modo que si A B y B C, entonces A C. Si dos eventos, X y Y, estn en procesos diferentes que no intercambian mensajes (ni siquiera en forma indirecta por medio de un tercero), X Y no es verdadero, ni tampoco lo es Y X. Se dice que estos eventos son concurrentes, lo que significa que nada se puede decir (o se necesita decir) acerca del momento en el que ocurren o cul de ellos es el primero. Lo que necesitamos es una forma de medir el tiempo tal que, acada evento A, le podamos asociar un valor del tiempo C(A) en el que todos los procesos estn de acuerdo. Estos valores del tiempo deben tener la propiedad de que si A B , entonces C(A) < C(B). En otros trminos, si A y B son dos procesos dentro del mismo evento y A ocurre antes de B, entonces C(A) < C(B). De manera anloga, si Aa es el envo de un mensaje por un proceso y B la recepcin de ese mensaje por otro proceso, entonces C(A) y C{B) deben ser asignados de tal forma que todos estn de acuerdo en los valores de C(a) y C(b) con C(a)