You are on page 1of 20

Sincronizacin

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.

6.1.1 Relojes Fsicos


Casi todas las computadoras tienen un circuito para dar seguimiento al tiempo. A pesar del
amplio uso de la palabra reloj para hacer referencia a estos dispositivos, en realidad no son
relojes en el sentido usual. Tal vez cronmetro sea una mejor palabra con la cual designarlos.
Un cronmetro de computadora, en general, es un cristal de cuarzo mecanizado con precisin.
Cuando este dispositivo se mantiene sujeto a tensin, los cristales de cuarzo oscilan en una
frecuencia bien definida que depende del tipo de cristal, de la forma de su corte, y de la cantidad
de tensin. Hay dos registros asociados con cada cristal, un contador y un registro de
mantenedor. Cada oscilacin del cristal disminuye el contador en uno. Cuando el contador llega
a cero, se genera una interrupcin y el contador se reinicia a partir del registro de mantenedor.
De esta manera, es posible programar un cronmetro para generar una interrupcin 60 veces por
segundo, o a cualquier otra frecuencia deseada. A cada interrupcin se le conoce como marca de
reloj.
Con una sola computadora y un solo reloj, no importa mucho si este reloj est desfasado por
una pequea cantidad. Debido a que todos los procesos de la mquina utilizan el mismo reloj,
cuando se introducen varias CPU, cada una con su propio reloj, la situacin cambia radicalmente.
Aunque la frecuencia con la que oscila un cristal es en general bastante estable, resulta imposible
garantizar que los cristales de los diferentes computadores funcionen exactamente con la misma
frecuencia. En la prctica, cuando un sistema tiene n computadoras, los n cristales funcionarn
velocidades ligeramente diferentes, lo cual ocasiona que los relojes (software) se salgan
gradualmente de sincrona y arrojen diferentes valores cuando se leen. Esta diferencia en valores
se conoce como distorsin de reloj.
En algunos sistemas (por ejemplo, sistemas de tiempo real), la hora del reloj real es importante.
Bajo estas circunstancias, los relojes fsicos externos son necesarios. Por razones de eficiencia
y redundancia, generalmente se considera deseable tener varios relojes, lo cual genera dos
problemas:
(1) Cmo los sincronizamos con relojes reales?, y (2) Cmo los sincronizamos entre s?

6.1.2 Sistema de posicionamiento global


En respuesta a la interrogante cmo determinar nuestra posicin geogrfica en cualquier parte
del planeta?, y en conjunto con la bsqueda de la solucin del problema de sincronizado de
relojes, se ha determinado que el problema de
posicionamiento se resuelve por s mismo a travs de un sistema distribuido altamente
especfico y dedicado llamado GPS (por sus siglas en ingls Global Positioning System)
Definicin y caractersticas del GPS:
GPS significa sistema de posicionamiento global.
El GPS es un sistema distribuido basado en un satlite puesto en rbita en 1978.
Aunque ha sido utilizado principalmente en aplicaciones militares, en aos recientes ha
encontrado su camino para muchas aplicaciones civiles, principalmente en la navegacin.
En otras palabras, una medicin GPS proporcionar adems un conteo del tiempo.

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.

Cmo funciona el GPS?


El GPS utiliza 29 satlites que circulan cada uno en una rbita situada a una altura
aproximada de 20 000 km.
Cada satlite tiene hasta cuatro relojes atmicos que son calibrados regularmente desde
estaciones especiales ubicadas en la Tierra.
Un satlite transmite su posicin de manera continua, y registra el tiempo de cada mensaje
con su tiempo local.
Esta transmisin permite a cada receptor localizado en la Tierra calcular exactamente su propia
posicin, empleando en principio slo tres satlites.
Desventajas:
Hasta el momento hemos asumido que las mediciones son perfectamente exactas, pero no es as.
El GPS no considera segundos vacos, es decir, existe una desviacin sistemtica del UTC,
la cual a partir del 1 de enero de 2006 es de 14 segundos. Tal error puede compensarse
fcilmente en el software.
Los relojes atmicos satelitales no siempre se encuentran en perfecta sincrona, la posicin de
un satlite no se conoce con precisin, el reloj del receptor tiene una exactitud finita, la
velocidad de propagacin de la seal no es constante, etc.
La Tierra no es una esfera perfecta, lo que nos lleva a necesitar ms correcciones.

6.1.3 Algoritmos de sincronizacin de relojes


En los ltimos aos se ha abordado el problema de la sincronizacin de relojes de computadoras
desde diferentes puntos de vista. En esta seccin se exponen los principales algoritmos que
resuelven el problema. Hay, adems de los presentados, otros
(http://virtual.ups.edu.ec/presencial49/mod/folder/view.php?id=29268) algoritmos derivados de
los expuestos. En todos los casos, para la comunicacin de las referencias de tiempo, se utiliza
el sistema de comunicaciones ya existente entre las computadoras que se desea sincronizar.

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

a-->b significa a antes de b


Si en un proceso el evento b sucede despus de a, entonces a-->b es verdadero
Si a identifica el evento de enviar un mensaje y b el de recibirlo, a-->b es verdadero (no
puede ser recibido antes de ser enviado)
Si asigno valores en el tiempo C(a) y C(b), C(a) < C(b)
Si no se cumple, adiciono el valor necesario a C(b). Nunca resto, ya que el tiempo debe
ser siempre creciente
En un mismo proceso, para dos eventos a y b C(a) debe ser diferente de C(b) (exigencia
de resolucin de reloj)

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

El algoritmo pasa por tres fases:


1) El servidor (mster) es activo, pregunta a cada cliente (slave) por su hora.
2) Calcula el promedio, descontando los que estn lejos del mismo.
3) Informa a cada cliente cmo debe cambiar la hora.
Estos intercambios de informacin se realizan a travs de paquetes de datos que circulan por la
red de interconexin entre las computadoras que se desea sincronizar, con las demoras
correspondientes. Estas demoras debern tenerse en cuenta a la hora de evaluar la correccin
para sincronizar los relojes.

6.2 Relojes Lgicos


No es posible reunir toda la informacin sobre el sistema en un punto y que luego algn proceso
la examine y tome las decisiones.

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.

La sincronizacin de relojes est naturalmente relacionada con el tiempo real.


Para ejecutar make resulta adecuado que dos nodos acuerden que input.o sea actualizado
por una nueva versin de input.c.
Lamport (1978) mostr que aunque la sincronizacin de relojes es posible, no necesita
ser absoluta.
Lo ms importante no es que todos los procesos coincidan con el tiempo sino que coincidan
en el orden en que ocurren los eventos.

6.2.1 Relojes lgicos de Lamport


Lamport defini a>b y se lee a ocurre antes de b que indica que todos los procesos coinciden
en que primero ocurre a y despus b >Se cumple: Si a y b son dos eventos en el mismo proceso
y a ocurre antes que b, entonces a->b es verdadero Si a es el evento del envo de un mensaje
por un proceso y b es el evento de la recepcin del mensaje por otro proceso, entonces a->b es
verdadero
De qu forma podemos sincronizar relojes lgicos? Necesitamos una forma de asociar a cada
evento a un valor de tiempo C(a) en el que todos los procesos estn de acuerdo Los valores
de tiempo deben tener la propiedad de que si a->b entonces C(a)
Algortmo de Lamport Cada mensaje acarrea el tiempo de envo, de acuerdo con el reloj del
emisor. Cuando un mensaje llega y el reloj del receptor muestra un valor anterior al tiempo en
que se envi el mensaje, el receptor adelanta su reloj para que tenga una unidad ms que el tiempo
de envo. Entre dos eventos cualesquiera, el reloj debe marcar al menos una vez. Dos eventos
no deben ocurrir exactamente al mismo tiempo.
.

6.2.2 Relojes vectoriales

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 primera propiedad se mantiene incrementando VCi[i] ante la ocurrencia de cada nuevo


evento en el proceso Pi.

La segunda propiedad se mantiene encimando los vectores junto con los mensajes que se
envan.

Pasos de la Segunda Propiedad


Antes de ejecutar un evento (es decir, enviar un mensaje por la red, entregar un mensaje a una
aplicacin, o algn otro evento interno), Pi ejecuta VCi[i] VCi[i] _ 1.

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.

Imposicin de la comunicacin causal: Al utilizar relojes vectoriales, ahora ya es posible


garantizar que un mensaje sea entregado slo si todos los mensajes que causalmente lo preceden
tambin han sido recibidos.
Transmisin causalmente ordenada: Si dos mensajes no estn relacionados de ninguna manera,
no nos interesa el orden en que se entregan a las aplicaciones pueden incluso entregarse en
diferente orden en diferentes ubicaciones.

Una nota sobre la entrega ordenada de mensajes

Existen dos problemas principales con dejar que el middleware trate con el ordenamiento de
mensajes.

. El middleware no puede decir qu contiene un mensaje, slo captura la potencial causalidad.


Una desventaja de tener nicamente soluciones al nivel de aplicacin es que el desarrollador
se ve obligado a concentrarse en las cuestiones que no se relacionan de inmediato con la
funcionalidad central de la aplicacin.

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.

En 1981 Ricart y Agrawala realizaron un algoritmo ms eficiente que requiere un ordenamiento


total de todos los eventos del sistema, el algoritmo funciona de la siguiente manera cuando un
proceso desea acceder a un recurso compartido, elabora un mensaje que contiene el nombre del
recurso, su nmero de proceso, y el tiempo actual (lgico).
Entonces enva el mensaje a todos los dems procesos, incluyndose de manera conceptual.
Se supone que el envo de los mensajes es confiable es decir, no se pierde mensaje alguno.
Cuando un proceso recibe un mensaje de peticin de otro proceso, la accin que tome
depender de su propio estado con respecto al recurso mencionado en el mensaje. Se deben
distinguir claramente tres casos:
1. Si el destinatario no accede al recurso y no desea acceder a l, enva un mensaje de OK
al remitente.
2. Si el destinatario ya cuenta con acceso al recurso, simplemente no responde. En vez de
eso, coloca la peticin en una cola.
3. Si el receptor tambin quiere acceder al recurso, pero an no lo ha hecho, compara el
registro de tiempo del mensaje entrante con el del mensaje que ya ha enviado a todos. El
menor gana. Si el mensaje entrante tiene un registro de tiempo menor, el receptor enva
de vuelta un mensaje de OK. Si su propio mensaje tiene un registro menor, el destinatario
coloca en la cola el mensaje entrante y no enva nada.
Despus de pedir permiso y enviar las peticiones, un proceso espera hasta que todos los
dems tengan permiso. Tan pronto como todos los permisos estn dentro, el proceso puede
continuar. Cuando termina, enva un mensaje de OK a todos los procesos de su cola y
elimina todos los dems.

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.

Comparacin de los cuatro algoritmos


El algoritmo centralizado es el ms simple y tambin el ms eficiente. Slo requiere de tres
mensajes para entrar y salir de una regin crtica: una peticin, un permiso para entrar, y una
liberacin para salir.

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

El algoritmo de anillo de token, el nmero es variable. Si cada proceso requiere entrar de


manera constante a una regin crtica, entonces cada token arrojar como resultado una
entrada y una salida, para un promedio de un mensaje por regin crtica introducida. Por otra
parte, en ocasiones el token puede circular por horas sin que ningn proceso se interese en
l. En este caso, el nmero de mensajes por entrada a una regin crtica es ilimitado.

Posicionamiento global de los nodos


Cuando aumenta el nmero de nodos en un sistema distribuido, se vuelve cada vez ms difcil
para cualquier nodo dar seguimiento a los dems. En redes geomtricas sobrepuestas, a cada
nodo se le asigna una posicin dentro de un espacio geomtrico m-dimensional, tal que la
distancia entre dos nodos en dicho espacio refleja una mtrica de rendimiento en el mundo real.
El ejemplo ms simple, y ms aplicado, es en donde la distancia se corresponde con la latencia
internodal. En otras palabras, dados dos nodos P y Q, entonces la distancia d (P, Q) refleja el
tiempo que le toma a un mensaje viajar desde P hacia Q y viceversa.
Hacer contacto solamente con un nodo le dir a P el crculo sobre el que se localiza hacer
contacto con slo dos nodos le informar con respecto a la posicin de la interseccin de los dos
crculos (lo que por lo general consta de dos puntos) contactar un tercer nodo permitir de
manera subsiguiente que P calcule su ubicacin real.
El nodo P puede calcular sus propias coordenadas (Xp,Yp) mediante la resolucin de las tres
ecuaciones con las incgnitas Xp y Yp :
ALGORITMOS DE ELECCIN

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.

6.5.1 Algoritmos de eleccin tradicional

El algoritmo del abusn (Bully)


Cuando cualquier proceso advierte que el coordinador ya no est
respondiendo peticiones, inicia una eleccin. Un proceso, P, celebra
una eleccin de la siguiente manera:

1. P enva un mensaje de ELECCIN a todos los procesos con nmeros superiores.


2. Si ningn proceso responde, P gana la eleccin y se convierte en el coordinador.
3. Si uno de los procesos superiores responde, toma el mando. El trabajo de P esthecho.

En cualquier momento, un proceso puede recibir un mensaje de ELECCIN de alguno de sus


colegas con nmero menor. Cuando llega un mensaje de este tipo, el destinatario enva un
mensaje de OK de vuelta al remitente para indicarle que est activo y que tomar el control. El
destinatario celebra entonces una eleccin, a menos que ya tenga una. En algn momento, todos
los procesos se rinden menos uno, que es entonces el nuevo coordinador. Este anuncia su victoria
enviando un mensaje a todos los procesos en el que les indica que a partir de ese momento es el
nuevo coordinador.
Un algoritmo de anillo

Este algoritmo no utiliza un token.


Cuando cualquier proceso advierte que el coordinador no funciona, elabora un mensaje de
eleccin que contiene su propio nmero de proceso y enva el mensaje a su sucesor y as
sucesivamente hasta que localice un proceso en ejecucin.
El mensaje regresa al proceso que inici todo. Ese proceso reconoce este evento cuando recibe
un mensaje entrante que contiene su propio nmero de proceso. En ese punto, el tipo de mensaje
cambia a COORDINADOR y circula una vez ms, para informar a todos que es el coordinador
y cules son los miembros del nuevo anillo.
Elecciones en ambientes inalmbricos
Los algoritmos tradicionales de eleccin generalmente se basan en suposiciones que no son reales
en ambientes inalmbricos.
Una propiedad importante de su solucin es que el mejor lder puede elegirse, en lugar de hacerlo
al azar.
Considere una red inalmbrica a la medida. Para elegir un lder, cualquier nodo de la red,
llamado fuente, puede iniciar una eleccin enviando un mensaje de ELECCIN a sus vecinos
inmediatos (es decir, a los nodos de su rango). Cuando un nodo recibe una ELECCIN por
primera vez, designa al remitente como su padre, y posteriormente enva un mensaje de
ELECCIN
a sus vecinos inmediatos, con excepcin del padre. Cuando un nodo recibe un mensaje de
ELECCIN de otro nodo
que no sea su padre, simplemente acusa de recibido.

Cuando el nodo R ha designado al nodo Q como su padre, ste reenva el mensaje de


ELECCIN a sus vecinos inmediatos (excepto a Q) y espera la llegada de los acuses antes
de enviar acuse de recibo del mensaje de ELECCIN de Q.

Esta espera tiene una importante consecuencia.

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.

6.5.3 Elecciones en sistemas de gran escala

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.

You might also like