Professional Documents
Culture Documents
Algoritmos de Sincronizacin
6.1 Sincronizacin del Reloj
Se dice que en un sistema no puede haber tiempos ambiguos, al momento que dos procesos
(compartiendo recursos) en secuencia realicen una peticin al sistema para saber la hora, el
segundo proceso no puede tener una hora menor que el primer proceso, esto puede ocasionar
muchos problemas ya que al no estar sincronizados no podrn llegar a una convergencia entre
los procesos ya que no se tiene un tiempo global al cual apegarse.
Para un mejor entendimiento expongamos el caso del programa make de UNIX, en UNIX
cuando un programa es grande se divide en varios archivos fuentes esto ayuda al programador
en el momento que el desee realizar una modificacin no tendr que compilar todos los archivos
de ese programa solo el archivo que modific, teniendo esto en cuenta imaginemos el siguiente
caso:
Imaginemos que dos archivos estn enlazados pero se ejecutan en mquinas diferentes las cuales
tienen horas ligeramente diferentes y que el archivo B depende del archivo A, si el archivo A
tiene una fecha mayor a B pero B hizo la ltima modificacin pero el sistema en donde est
corriendo B tiene una fecha menor que el sistema donde est corriendo A habra un conflicto ya
que no se guardaran las modificaciones de B porque no hubo una sincronizacin correcta.
Campos de Aplicacin:
Los telfonos GPS ahora permiten a quienes llaman rastrear la posicin del otro, una
caracterstica que puede ser extremadamente til cuando se est perdido o en problemas.
Este principio puede aplicarse fcilmente para rastrear otras cosas, incluso mascotas, nios,
automviles, naves, etc.
Algoritmo de Lamport
El algoritmo de Lamport es uno de los primeros propuestos para la sincronizacin de sistemas
distribuidos y se basa en la relacin sucede antes ms la utilizacin de los mensajes entre las
computadoras como indicadores precisos de esta relacin. Ms especficamente, un mensaje no
puede ser recibido antes de ser enviado y, por lo tanto, si se tienen marcas de tiempo de los
envos de los mensajes se puede verificar si el tiempo actual es coherente con la definicin de la
relacin antes de. Para ello se definen relojes lgicos. Un resumen de lo que realiza el
algoritmo sera:
Se analiza qu sucede antes
Las tareas a llevar a cabo en cada computadora son relativamente sencillas, aunque afectan, en
cierta manera, la forma en que se procesan los mensajes:
1. Se tiene un reloj local.
2. Cada vez que se enva un mensaje, se le agrega al mismo una marca de tiempo (timestamp)
con el tiempo local del queenva.
3. Cada vez que llega un mensaje, se analiza la marca de tiempo del que envi, y si la marca de
tiempo es menor que eltiempo local, se asume que las computadoras estn sincronizadas,si la
marca de tiempo es mayor o igual que el tiempo local, se cambia el tiempo local con la marca
de tiempo del mensaje que se recibi ms 1 (asumiendo, por ejemplo, que la transmisin
necesita 1 unidad de tiempo)
Algoritmo de Cristian
Cristian defini los conceptos de sincronizacin interna y externa, ya vistos. Recordamos que
sincronizacin interna se refiere a mantener un grupo de relojes sincronizados, no importa qu
hora tengan pero que en el grupo sea la misma, o con un margen de diferencias acotado a algn
valor conocido. La sincronizacin externa podra definirse como mantener sincronizacin
interna con alguna fuente fiable de hora tipo UTC.En este marco de definicin, Cristian propone
sincronizar un conjunto de relojes demquinas a partir de una que est sincronizada externamente
(tiempo u hora real), a travs de la red de comunicaciones de datos entre computadoras.
El algoritmo de Cristian es probabilstico ya que no garantiza que un procesador pueda leer un
reloj remoto con una precisin especfica. Sin embargo, intentando una cantidad de veces
suficiente, la hora recuperada puede ser leda con una precisin dada, con una probabilidad cerca
de uno, segn lo deseado.
Por otro lado, no se sabe cunto es el mximo tiempo de envo de un mensaje entre dos
computadoras. Algunos algoritmos suponen un tiempo mximo de envo. Son algoritmos
determinsticos en el sentido que suponen que siempre llega el mensaje con la referencia en un
tiempo menor al tiempo mximo. No pueden ser usados para sincronizar sistemas asincrnicos,
ya que es imposible determinar el tiempo mximo.
Estos algoritmos suponen un intercambio de mensajes, para n procesos a sincronizar, de n2. Esto
dificulta la escalabilidad en redes con gran nmero de nodos.
Cristian asume que:
1) El tiempo mnimo de demora de un mensaje min t es conocido.
2) La funcin de distribucin de la demora en los mensajes es conocida.
Pueden ocurrir tres tipos de fallas en un proceso que trata de sincronizar:
Por rotura: cuando ante la prdida de un evento no puede recuperarse
Por performance: cuando reacciona ante el evento muy lentamente, posiblemente por culpa
del sistema operativo y excede la demora .
Arbitraria: Son las dems fallas. Por ejemplo un proceso que reacciona demasiado rpido o
que enva informacin errnea.
El algoritmo de Cristian presenta ciertos inconvenientes:
Al contar con un servidor de hora, si este falla, queda sin referencia. Cristian propone que los
clientes hagan los requerimientos a varios servidores y se queden con la referencia que llegue
primero.
La segunda cuestin es con relacin al ajuste del reloj. Si la hora de referencia recibida desde
el mster es menor a la que se desea ajustar, dicho ajuste implica un atraso, con lo cual dicho
reloj pasa dos veces por la misma hora. Esto traera aparejados mltiples inconvenientes
entre otros (http://virtual.ups.edu.ec/presencial49/mod/folder/view.php?
id=29268), uno bastante grave: la hora de actualizacin de archivos. En algunos apareceran
en el futuro modificaciones del pasado, con los inconvenientes que ello presenta, por
ejemplo, para utilidades como make. En las implementaciones de este algoritmo, para
atrasar, se baja la frecuencia del reloj durante el tiempo necesario para atrasarlo sin
escalones.
Tiene los problemas de escalabilidad de toda arquitectura
cliente-servidor.
Algoritmo de Berkeley
Si para asignar un recurso de E/S un proceso debe recolectar informacin de todos los procesos
para tomar la decisin esto implica una gran carga para este proceso y su cada afectara en
mucho al sistema.
Idealmente, un sistema distribuido debera ser ms confiable que las mquinas individuales.
Alcanzar la sincronizacin sin la centralizacin requiere hacer cosas en forma distinta a los
sistemas operativos tradicionales.
Mattern y Fidge desarrollaron relojes vectoriales para mejorar la deficiencia de los relojes
de Lamport, del hecho que no podemos deducir que un reloj vectorial para un sistema de N
procesos es un vector de N enteros.
Cada proceso mantiene su propio reloj vectorial Vi, que utiliza para colocar marcas de
tiempo en los sucesos locales. Como las marcas de tiempo de Lamport, cada proceso adhiere
el vector de marcas de tiempo en los mensajes que enva al resto, y hay unas reglas sencillas
para actualizar los relojes.
Los vectores de marcas de tiempo tienen la desventaja, comparados con las marcas de tiempo
de Lamport, de precisar una cantidad de almacenamiento y de carga real de mensajes que es
proporcional a N, el nmero de procesos.
Reloj Vectorial: Los relojes vectoriales se construyen de manera que cada proceso Pi mantenga
un vector VCi con las dos siguientes propiedades:
VCi[i] es el nmero de eventos que han ocurrido hasta el momento en Pi. En otras palabras,
VCi[i] es el reloj lgico del proceso Pi.
Si VCi[j] = k, entonces Pi sabe que han ocurrido k eventos en Pj. As, ste es el conocimiento
de Pi del tiempo local en Pj.
Propiedades:
La segunda propiedad se mantiene encimando los vectores junto con los mensajes que se
envan.
Cuando el proceso Pi enva un mensaje m a Pj, ste establece el registro de tiempo de m, ts (m),
igual a VCi despus de haber ejecutado el paso anterior.
Una vez que se recibe el mensaje m, el proceso Pj ajusta su propio vector configurando VCj[k]
mx{VCj[k], ts(m)[k]} para cada k, despus de lo cual ejecuta el primer paso y libera el
mensaje a la aplicacin.
Existen dos problemas principales con dejar que el middleware trate con el ordenamiento de
mensajes.
Exclusin Mutua
Para los sistemas distribuidos resultan fundamentales la concurrencia y la colaboracin entre
diversos procesos. En muchos casos, esto significa tambin que los procesos necesitarn de
acceso Simultneo a los mismos recursos. Para evitar que tales accesos concurrentes corrompan
los recursos, o que los vuelvan inconsistentes, se necesita encontrar soluciones que garanticen
que los procesos tengan acceso mutuamente exclusivo.
Los algoritmos distribuidos de exclusin mutua pueden clasificarse en dos diferentes categoras.
Soluciones basadas en token, la exclusin mutua se logra pasando entre los procesos un
mensaje especial conocido como token. Slo hay un token disponible, y quien lo tenga puede
acceder al recurso compartido. Cuando termina, el token pasa al siguiente proceso. Si un
proceso tiene el token pero no est interesado en acceder al recurso, simplemente lo pasa.
Las soluciones basadas en token tienen algunas propiedades importantes:
Primero, de acuerdo con la organizacin de los procesos, stos pueden garantizar fcilmente
que todos tendrn la oportunidad de acceder a los recursos. En otras palabras, evitan la
inanicin.
Segundo, el interbloqueomediante los cuales diversos procesos se esperan unos a otros
(http://virtual.ups.edu.ec/presencial49/mod/folder/view.php?id=29268) para continuar
pueden evitarse fcilmente, contribuyendo a su simplicidad.
Mtodo basado en permisos. En este caso, un proceso que desea el primer acceso a los recursos
requiere el permiso de los otros
(http://virtual.ups.edu.ec/presencial49/mod/folder/view.php?id=29268) procesos.
Algoritmo Centralizado
En un sistema distribuido, la manera ms directa de lograr la exclusin mutua es simular lo que
se hace en un sistema de un procesador. Se elige un proceso como coordinador. Siempre que un
proceso desea acceder a un recurso compartido, enva un mensaje de peticin al coordinador
mencionando el recurso al que desea acceder, y solicita permiso. Si ningn otro proceso est
accediendo al recurso en ese momento, el coordinador devuelve una respuesta en la que otorga
el permiso, como se muestra en la figura 6-14(a). Cuando la respuesta llega, el proceso solicitante
puede continuar.
El mtodo centralizado tambin tiene defectos. El coordinador es un solo punto de falla, por
lo que si falla, todo el sistema puede irse abajo. Si los procesos normalmente se bloquean
despus de hacer una peticin, no pueden distinguir un coordinador desactivado de un
permiso negado ya que, en ambos casos, ningn mensaje regresa. Adems, en un sistema
grande, un solo coordinador puede volverse un cuello de botella en cuanto a rendimiento. Sin
embargo, los beneficios provenientes de su simplicidad pesan ms que las potenciales
desventajas.
Algoritmo Descentralizado
Con frecuencia, tener un solo coordinador es un mal mtodo. Demos un vistazo a una solucin
totalmente descentralizada. Se supone que cada recurso se replica n veces. Cada rplica tiene su
propio coordinador para controlar el acceso de procesos concurrentes. Sin embargo, siempre que
un proceso desee acceder al recurso, ste simplemente tendr que lograr una votacin mayoritaria
a partir de m > n/2 coordinadores. A diferencia del esquema centralizado que explicamos antes,
asumimos que cuando un coordinador no otorga el permiso para acceder a un recurso (lo que
har cuando haya otorgado el permiso a otro proceso), se lo informa al solicitante. Este esquema
bsicamente hace que la solucin original centralizada sea menos vulnerable ante las fallas de un
solo coordinador. La suposicin es que cuando un coordinador falla, se recupera rpidamente
pero habr olvidado cualquier voto otorgado antes de fallar. Otra forma de ver esto es que el
coordinador se reinicia a s mismo en cualquier momento. El riesgo que corremos es que un
reinicio har que el coordinador olvide los permisos otorgados previamente a algunos procesos
para acceder al recurso. En consecuencia, despus de su recuperacin puede nuevamente otorgar,
de manera incorrecta, permiso a otro proceso.
Sea p la probabilidad de que un coordinador se reinicie durante un intervalo de tiempo t. La
probabilidad, P[k], de que cada k de m coordinadores se reinicie durante el mismo intervalo es:
UN ALGORITMO DISTRIBUIDO
No es suficiente con un algoritmo probabilsticamente correcto por lo que investigadores han
elaborado algoritmo algoritmos distribuidos deterministas de exclusin mutua, el artculo de
Lamport en 1978 presento el primer algoritmo sobre la sincronizacin de relojes.
Ejemplo
El proceso 0 enva a todos una peticin con un registro de tiempo de 8, mientras que al mismo
tiempo, el proceso 2 enva a todos una peticin con registro de 12. El proceso 1 no est interesado
en el recurso, de manera que enva OK a ambos remitentes. Los procesos 0 y 2 ven el conflicto
y comparan los registros de tiempo. El proceso 2 ve que perdi, de manera que le concede
permiso a 0 al enviar OK. Ahora el proceso 0 forma en la cola a la peticin de 2, para su posterior
procesamiento y acceso al recurso. Cuando termina, elimina la peticin de 2 de su cola y enva
un mensaje de OK para procesar 2, permitiendo a este ltimo seguir adelante,
El algoritmo funciona debido a que, en caso de un conflicto, el menor registro de tiempo gana y
todos los dems coinciden en el orden de los registros, la exclusin mutua se garantiza sin
interbloqueos o inanicin, el nmero de mensajes requerido por entrada ahora es 2(n - 1), en
donde n es el nmero total de procesos.
Lo mejor de todo es que son posibles muchas mejoras menores para este algoritmo, Por
desgracia, el nico punto de falla se reemplaz por n puntos de falla. Si alguno de los procesos
falla, fallar en responder las peticiones lo cual bloquear todos los intentos posteriores de los
procesos para entrar a las regiones crticas. No obstante, este algoritmo es ms lento, ms
complicado, ms caro, y menos robusto que el original centralizado.
El algoritmo se puede parchar mediante un truco. Cuando llega una peticin, el destinatario
siempre enva una respuesta, ya sea autorizando o negando el permiso. Cada vez que se pierde
una peticin o una respuesta, el remitente agota el tiempo y contina hasta que obtiene una
respuesta, o el remitente concluye que el destinatario est desactivado. Despus de que se niega
una peticin, el remitente debe lanzar un bloqueo y esperar un mensaje posterior de OK.
UN ALGORITMO DE ANILLO DE TOKEN
Cuando se inicia el anillo, al proceso 0 se le asigna un token. El token circula alrededor del anillo.
Se pasa desde el proceso k al proceso k + 1 (modula el tamao del anillo) en los mensajes punto
a punto. Cuando un proceso adquiere el token de su vecino, verifica si necesita acceder al recurso
compartido. Si es as, el proceso sigue adelante, hace el trabajo que requiere hacer, y libera los
recursos. Una vez que ha terminado, pasa el token a lo largo del anillo. No est permitido acceder
de inmediato de nuevo al recurso mediante el uso del mismo token.
Si un proceso no necesita ningn recurso la seal circula a alta velocidad por el anillo, el grado
de exactitud de este algoritmo es fcil por lo que solo un proceso tiene el token por lo que
solamente l puede llegar al recurso. Cuando un proceso accede al recurso, los dems recursos
deben esperar.
El caso descentralizado, vemos que estos mensajes necesitan ser realizados por cada uno de
los m coordinadores, pero ahora es posible que se necesiten varios intentos (para ello
introducimos la variable k).
El algoritmo distribuido requiere n 1 mensajes de peticin, uno para cada uno de los dems
procesos, y los n _ 1 mensajes adicionales de autorizacin, para un total de 2(n 1).
(Suponemos que solamente se utilizan los canales de comunicacin punto a punto.)
La eleccin de algoritmos intenta localizar el proceso que tenga el nmero ms grande y designar
como coordinador. El objetivo de un algoritmo de eleccin es garantizar que cuando inicie una
eleccin, sta concluya con todos los procesos de acuerdo con el que ser el nuevo coordinador.
Primero, observe que los vecinos que ya han seleccionado un padre de inmediato responden a R.
De manera ms especfica, si todos los vecinos ya tienen un padre, R es un nodo hoja y podr
responder rpidamente a Q. Al hacerlo, tambin reporta informacin tal como el tiempo de vida
de la pila y otras capacidades de los recursos.
Esta informacin permitir ms tarde a Q comparar las capacidades de R con las de otros
(http://virtual.ups.edu.ec/presencial49/mod/folder/view.php?id=29268) nodos, y seleccionar al
mejor nodo para que sea el lder. Por supuesto, Q ha enviado un mensaje de ELECCIN slo
porque su padre, P, lo ha hecho tambin. A su vez, cuando Q en algn momento acuse la
recepcin del mensaje de ELECCIN previamente enviado por P, ste pasar tambin el nodo
ms elegible a P. De este modo, la fuente deber saber en algn momento cul es el mejor nodo
para seleccionarlo como lder, y despus transmitir esta informacin a los dems nodos.
En sistemas distribuidos de tamao medio y grande existen situaciones en las que el algoritmo
necesita la eleccin de varios nodos, como es el caso de los superpuntos de las redes punto a
punto.
Para la eleccin de los superpuntos, es necesario cumplir los siguientes requerimientos:
Los nodos normales deben tener acceso de baja latencia a los superpuntos.
Los superpuntos deben distribuirse uniformemente a travs de la red sobrepuesta.
Debe haber una porcin predefinida de superpuntos, relativa al nmero total de nodos de la
red sobrepuesta.
Cada superpunto no debe necesitar servir a ms de un nmero fijo de nodos normales.