Sincronización Algoritmos de Sincronización 6.1 Sincronización del Reloj Se dice que en un sistema no puede haber tiempos ambiguos, al momento que dos procesos (compartiendo recursos) en secuencia realicen una petición 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 podrán 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 modificación no tendrá que compilar todos los arc hivos de ese programa solo el archivo que modificó, teniendo esto en cuenta imaginemos el siguiente caso: Imaginemos que dos archivos están enlazados pero se ejecutan en máquinas diferentes las cuales tienen horas ligeramente diferentes y que el archivo B depende del archivo A, si el archivo A tiene una fecha mayor mayor a B pero B hizo la última modificación modificación pero el sistema sistema en donde está corriendo B tiene una fecha menor que el sistema donde está corriendo A habría un conflicto ya que no se guardaran las modificaciones de B porque no hubo una sincronización correcta.
6.1.1 Relojes Físicos Casi todas las computadoras tienen un circuito para dar seguimiento al tiempo. A pesar del ealidad no son amplio uso de la palabra “reloj” para hacer referencia a estos dispositivos, en r ealidad relojes en el sentido usual. Tal vez cronómetro sea una mejor palabra con la cual designarlos. Un cronómetro de computadora, en general, es un cristal de cuarzo mecanizado con precisión. Cuando este dispositivo se mantiene sujeto a tensión, 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 tensión. Hay dos registros asociados con cada cristal, un contador y un registro de mantenedor. Cada oscilación del cristal disminuye el contador en uno. Cuando el contador llega a cero, se genera una interrupción y el contador se reinicia a partir del registro de mantenedor. De esta manera, es posible programar un cronómetro para generar una interrupción 60 veces por segundo, o a cualquier otra frecuencia deseada. A cada interrupción 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 pequeña cantidad. Debido a que todos los procesos de la máquina utilizan el mismo reloj, cuando se introducen varias CPU, cada una con su propio reloj, la situación 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 práctica, cuando un sistema tiene n computadoras, los n cristales funcionarán velocidades ligeramente diferentes, lo cual ocasiona que los relojes (software) se salgan gradualmente de sincronía y arrojen diferentes valores cuando se leen. Esta diferencia en valores se conoce como distorsión de reloj. En algunos sistemas (por ejemplo, sistemas de tiempo real), la hora del reloj real es importante. Bajo estas circunstancias, los relojes físicos externos son necesarios. Por razones de eficiencia y redundancia, generalmente se considera deseable tener varios relojes, lo cual genera dos problemas: (1) ¿Cómo los sincronizamos con relojes reales?, y (2) ¿Cómo los sincronizamos entre sí?
6.1.2 Sistema de posicionamiento posicionamiento global En respuesta a la interrogante ¿cómo determinar nuestra posición geográfica en cualquier parte del planeta?, y en conjunto con la búsqueda de la solución del problema de sincronizado de relojes, se ha determinado que el problema de posicionamiento posicionamiento se resuelve por sí mismo a través de un sistema distribuido altamente específico y dedicado llamado GPS (por sus siglas en inglés Global Positioning System)
Definición y características del GPS: GPS significa sistema de posicionamiento global. El GPS es un sistema distribuido basado en un satélite puesto en órbita en 1978. Aunque ha sido utilizado principalmente en aplicaciones militares, en años recientes ha encontrado su camino para muchas aplicaciones civiles, principalmente en la navegación. En otras palabras, una medición GPS proporcionará además un conteo del tiempo.
Campos de Aplicación: Los teléfonos GPS ahora permiten a quienes llaman rastrear la posición del otro, una característica que puede ser extremadamente útil cuando se está perdido o en problemas. Este principio puede aplicarse fácilmente para rastrear otras cosas, incluso mascotas, niños, automóviles, naves, etc.
¿Cómo funciona el GPS? El GPS utiliza 29 satélites que circulan cada uno en una órbita situada a una altura aproximada de 20 000 km. Cada satélite tiene hasta cuatro relojes atómicos que son calibrados regularmente desde estaciones especiales ubicadas en la Tierra. Un satélite transmite su posición de manera continua, y registra el tiempo de cada mensaje con su tiempo local. Esta transmisión permite a cada receptor localizado en la Tierra calcular exactamente su propia posición, empleando empleando en principio sólo sólo tres satélites.
Desventajas: Hasta el momento hemos asumido que las mediciones son perfectamente exactas, pero no es así. El GPS no considera segundos vacíos, es decir, existe una desviación sistemática del UTC, la cual a partir del 1 de enero de 2006 es de 14 segundos. Tal error puede compensarse fácilmente en el software. Los relojes atómicos satelitales no siempre se encuentran en perfecta sincronía, la posición de un satélite no se conoce con precisión, el reloj del receptor tiene una exactitud finita, la velocidad de propagación de la señal no es constante, etc. La Tierra no es una esfera perfecta, lo que nos lleva a necesitar más correcciones.
6.1.3 Algoritmos de sincronización de relojes En los últimos años se ha abordado el problema de la sincronización de relojes de computadoras desde diferentes puntos de vista. En esta sección se exponen los principales algoritmos que resuelven el problema. Hay, además 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 comunicación 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 sincronización de sistemas distribuidos y se basa en la relación “sucede antes” más la utilización de los mensajes entre las
computadoras como indicadores precisos de esta relación. Más específicamente, un mensaje no puede ser recibido antes de ser enviado y, por lo tanto, si se tienen marcas de tiempo de los envíos de los mensajes se puede verificar si el tiempo actual es coherente con la definición de la relación “antes de”. Para ello se definen relojes lógicos. Un resumen de lo que realiza el algoritmo sería: Se analiza qué sucede antes
a-->b significa a antes de b Si en un proceso el evento b sucede después 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 resolución 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 envía un mensaje, se le agrega al mismo una marca de tiempo (timestamp) con el tiempo local del queenvía. 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 están 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ó más 1 (asumiendo, por ejemplo, que la transmisión necesita 1 unidad de tiempo)
Algoritmo de Cristian Cristian definió los conceptos de sincronización interna y externa, ya vistos. Recordamos que sincronización 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 algún valor conocido. La sincronización externa podría definirse como mantener sincronización interna con alguna fuente fiable de hora tipo UTC.En este marco de definición, Cristian propone sincronizar un conjunto de relojes demáquinas a partir de una que esté sincronizada externamente (tiempo u hora real), a través de la red de comunicaciones de datos entre computadoras. El algoritmo de Cristian es probabilístico ya que no garantiza que un procesador pueda leer un reloj remoto con una precisión específica. Sin embargo, intentando una cantidad de veces suficiente, la hora recuperada puede ser leída con una precisión dada, con una probabilidad cerca de uno, según lo deseado. Por otro lado, no se sabe cuánto es el máximo tiempo de envío de un mensaje entre dos computadoras. Algunos algoritmos suponen un tiempo máximo de envío. Son algoritmos determinísticos en el sentido que suponen que siempre llega el mensaje con la referencia en un tiempo menor al tiempo máximo. No pueden ser usados para sincronizar sistemas asincrónicos, ya que es imposible determinar el tiempo máximo. Estos algoritmos suponen un intercambio de mensajes, para n procesos a sincronizar, de n2. Esto dificulta la escalabilidad en redes con gran número de nodos. Cristian asume que: 1) El tiempo mínimo de demora de un mensaje min t es conocido. 2) La función de distribución 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 pérdida 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 demás fallas. Por ejemplo un proceso que reacciona demasiado rápido o que envía información errónea.
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 cuestión es con relación al ajuste del reloj. Si la hora de referencia recibida desde el máster 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 traería aparejados múltiples inconvenientes;
entre otros (http://virtual.ups.edu.ec/presencial49/mod/folder/view.php? id=29268), uno bastante grave: la hora de actualización de archivos. En algunos aparecerían 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 clienteservidor.
Algoritmo de Berkeley
El algoritmo pasa por tres fases: 1) El servidor (máster) es activo, pregunta a cada cliente (slave) por su hora. 2) Calcula el promedio, descontando los que están lejos del mismo. 3) Informa a cada cliente cómo debe cambiar la hora.
Estos intercambios de información se realizan a través de paquetes de datos que circulan por la red de interconexión entre las computadoras que se desea sincronizar, con las demoras correspondientes. Estas demoras deberán tenerse en cuenta a la hora de evaluar la corrección para sincronizar los relojes.
6.2 Relojes Lógicos No es posible reunir toda la información sobre el sistema en un punto y que luego algún proceso la examine y tome las decisiones. Si para asignar un recurso de E/S un proceso debe recolectar información de todos los procesos para tomar la decisión esto implica una gran carga para este proceso y su caída afectaría en mucho al sistema. Idealmente, un sistema distribuido debería ser más confiable que las máquinas individuales. Alcanzar la sincronización sin la centralización requiere hacer cosas en forma distinta a los sistemas operativos tradicionales. La sincronización 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 versión de input.c. Lamport (1978) mostró que aunque la sincronización de relojes es posible, no necesita ser absoluta. Lo más 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 lógicos 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 después 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 envío de un mensaje
por un proceso y b es el evento de la recepción del mensaje por otro proceso, entonces a>b es verdadero De qué forma podemos sincronizar relojes lógicos? – Necesitamos una forma de asociar a cada evento a un valor de tiempo C(a) en el que todos los procesos estén de acuerdo – Los valores de tiempo deben tener la propiedad de que si a>b entonces C(a) Algorítmo de Lamport – Cada mensaje acarrea el tiempo de envío, 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 más que el tiempo
de envío. – 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 envía 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 número 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 número de eventos que han ocurrido hasta el momento en Pi. En otras palabras, VCi[i] es el reloj lógico 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 envían.
Pasos de la Segunda Propiedad Antes de ejecutar un evento (es decir, enviar un mensaje por la red, entregar un mensaje a una aplicación, o algún otro evento interno), Pi ejecuta VCi[i] ← VCi[i] _ 1.
Cuando el proceso Pi envía un mensaje m a Pj, éste establece el registro de tiempo de m, ts (m), igual a VCi después de haber ejecutado el paso anterior. Una vez que se recibe el mensaje m, el proceso Pj ajusta su propio vector configurando VCj[k] ← máx{VCj[k], ts(m)[k]} para cada k, después de lo cual ejecuta el primer paso y libera el
mensaje a la aplicación. Imposición de la comunicación causal: Al utilizar relojes vectoriales, ahora ya es posible garantizar que un mensaje sea entregado sólo si todos los mensajes que causalmente lo preceden también han sido recibidos.
Transmisión causalmente ordenada: Si dos mensajes no están 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, sólo captura la potencial causalidad. Una desventaja de tener únicamente soluciones al nivel de aplicación es que el desarrollador se ve obligado a concentrarse en las cuestiones que no se relacionan de inmediato con la funcionalidad central de la aplicación.
Exclusión Mutua Para los sistemas distribuidos resultan fundamentales la concurrencia y la colaboración entre diversos procesos. En muchos casos, esto significa también que los procesos necesitarán de acceso Simultáneo 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 exclusión mutua pueden clasificarse en dos diferentes categorías. Soluciones basadas en token, la exclusión mutua se logra pasando entre los procesos un mensaje especial conocido como token. Sólo 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 organización de los procesos, éstos pueden garantizar fácilmente que todos tendrán la oportunidad de acceder a los recursos. En otras palabras, evitan la inanición. 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 fácilmente, contribuyendo a su simplicidad.
Método 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 más directa de lograr la exclusión 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, envía un mensaje de petición al coordinador mencionando el recurso al que desea acceder, y solicita permiso. Si ningún 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 614(a). Cuando la respuesta llega, el proceso solicitante puede continuar.
El método centralizado también 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 después de hacer una petición, no pueden distinguir un coordinador desactivado de un “permiso negado” ya que, en ambos casos, ningún mensaje regresa. Además, 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 más que las potenciales desventajas.
Algoritmo Descentralizado Con frecuencia, tener un solo coordinador es un mal método. Demos un vistazo a una solución totalmente descentralizada. Se supone que cada recurso se replica n veces. Cada réplica 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 votación 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 básicamente hace que la solución original centralizada sea menos vulnerable ante las fallas de un
solo coordinador. La suposición es que cuando un coordinador falla, se recupera rápidamente 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, después de su recuperación 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 probabilísticamente correcto por lo que investigadores han elaborado algoritmo algoritmos distribuidos deterministas de exclusión mutua, el artículo de Lamport en 1978 presento el primer algoritmo sobre la sincronización de relojes.
En 1981 Ricart y Agrawala realizaron un algoritmo más 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 número de proceso, y el tiempo actual (lógico). Entonces envía el mensaje a todos los demás procesos, incluyéndose de manera conceptual. Se supone que el envío de los mensajes es confiable; es decir, no se pierde mensaje alguno.
Cuando un proceso recibe un mensaje de petición de otro proceso, la acción 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, envía 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 petición en una cola. 3. Si el receptor también quiere acceder al recurso, pero aún 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 envía 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 envía nada. Después de pedir permiso y enviar las peticiones, un proceso espera hasta que todos los demás tengan permiso. Tan pronto como todos los permisos están dentro, el proceso puede
continuar. Cuando termina, envía un mensaje de OK a todos los procesos de su cola y elimina todos los demás.
Ejemplo
El proceso 0 envía a todos una petición con un registro de tiempo de 8, mientras que al mismo tiempo, el proceso 2 envía a todos una petición con registro de 12. El proceso 1 no está interesado en el recurso, de manera que envía 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 petición de 2, para su posterior procesamiento y acceso al recurso. Cuando termina, elimina la petición de 2 de su cola y envía 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 demás coinciden en el orden de los registros, la exclusión mutua se garantiza sin interbloqueos o inanición, el número de mensajes requerido por entrada ahora es 2(n 1), en donde n es el número 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 críticas. No obstante, este algoritmo es más lento, más complicado, más caro, y menos robusto que el original centralizado. El algoritmo se puede parchar mediante un truco. Cuando llega una petición, el destinatario siempre envía una respuesta, ya sea autorizando o negando el permiso. Cada vez que se pierde una petición o una respuesta, el remitente agota el tiempo y continúa hasta que obtiene una respuesta, o el remitente concluye que el destinatario está desactivado. Después de que se niega una petición, 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 tamaño 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 ningún recurso la señal circula a alta velocidad por el anillo, el grado de exactitud de este algoritmo es fácil 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 demás recursos deben esperar.
Comparación de los cuatro algoritmos
El algoritmo centralizado es el más simple y también el más eficiente. Sólo requiere de tres mensajes para entrar y salir de una región crítica: una petición, un permiso para entrar, y una liberación 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 petición, uno para cada uno de los demás procesos, y los n _ 1 mensajes adicionales de autorización, para un total de 2(n – 1). (Suponemos que solamente se utilizan los canales de comunicación punto a punto.)
El algoritmo de anillo de token, el número es variable. Si cada proceso requiere entrar de manera constante a una región crítica, entonces cada token arrojará como resultado una entrada y una salida, para un promedio de un mensaje por región crítica introducida. Por otra parte, en ocasiones el token puede circular por horas sin que ningún proceso se interese en él. En este caso, el número de mensajes por entrada a una región crítica es ilimitado.
Posicionamiento global de los nodos Cuando aumenta el número de nodos en un sistema distribuido, se vuelve cada vez más difícil para cualquier nodo dar seguimiento a los demás. En redes geométricas sobrepuestas, a cada nodo se le asigna una posición dentro de un espacio geométrico mdimensional, tal que la distancia entre dos nodos en dicho espacio refleja una métrica de rendimiento en el mundo real. El ejemplo más simple, y más 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 círculo sobre el que se localiza; hacer
contacto con sólo dos nodos le informará con respecto a la posición de la intersección de los dos círculos (lo que por lo general consta de dos puntos); contactar un tercer nodo permitirá de
manera subsiguiente que P calcule su ubicación real. El nodo P puede calcular sus propias coordenadas (Xp,Yp) mediante la resolución de las tres ecuaciones con las incógnitas Xp y Yp :
ALGORITMOS DE ELECCIÓN La elección de algoritmos intenta localizar el proceso que tenga el número más grande y designar como coordinador. El objetivo de un algoritmo de elección es garantizar que cuando inicie una elección, ésta concluya con todos los procesos de acuerdo con el que será el nuevo coordinador.
6.5.1 Algoritmos de elección tradicional El algoritmo del abusón (Bully) Cuando cualquier proceso advierte que el coordinador ya no está respondiendo peticiones, inicia una elección. Un proceso, P, celebra una elección de la siguiente manera:
1. P
envía un mensaje de ELECCIÓN a todos los procesos con números superiores. 2. Si ningún proceso responde, P gana la elección y se convierte en el coordinador. 3. Si uno de los procesos superiores responde, toma el mando. El trabajo de P estáhecho. En cualquier momento, un proceso puede recibir un mensaje de ELECCIÓN de alguno de sus colegas con número menor. Cuando llega un mensaje de este tipo, el destinatario envía un mensaje de OK de vuelta al remitente para indicarle que está activo y que tomará el control. El destinatario celebra entonces una elección, a menos que ya tenga una. En algún 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 elección que contiene su propio número de proceso y envía el mensaje a su sucesor y así sucesivamente hasta que localice un proceso en ejecución. El mensaje regresa al proceso que inició todo. Ese proceso reconoce este evento cuando recibe un mensaje entrante que contiene su propio número de proceso. En ese punto, el tipo de mensaje cambia a COORDINADOR y circula una vez más, para informar a todos que es el coordinador y cuáles son los miembros del nuevo anillo.
Elecciones en ambientes inalámbricos Los algoritmos tradicionales de elección generalmente se basan en suposiciones que no son reales en ambientes inalámbricos. Una propiedad importante de su solución es que el mejor líder puede elegirse, en lugar de hacerlo al azar. Considere una red inalámbrica a la medida. Para elegir un líder, cualquier nodo de la red, llamado fuente, puede iniciar una elección enviando un mensaje de ELECCIÓN a sus vecinos inmediatos (es decir, a los nodos de su rango). Cuando un nodo recibe una ELECCIÓN por primera vez, designa al remitente como su padre, y posteriormente envía un mensaje de ELECCIÓN a sus vecinos inmediatos, con excepción del padre. Cuando un nodo recibe un mensaje de ELECCIÓN 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 reenvía el mensaje de ELECCIÓN a sus vecinos inmediatos (excepto a Q) y espera la llegada de los acuses antes de enviar acuse de recibo del mensaje de ELECCIÓN 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 más específica, si todos los vecinos ya tienen un padre, R es un nodo hoja y podrá responder rápidamente a Q. Al hacerlo, también reporta información tal como el tiempo de vida de la pila y otras capacidades de los recursos. Esta información permitirá más 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 líder. Por supuesto, Q ha enviado un mensaje de ELECCIÓN sólo porque su padre, P, lo ha hecho también. A su vez, cuando Q en algún momento acuse la recepción del mensaje de ELECCIÓN previamente enviado por P, éste pasará también el nodo más elegible a P. De este modo, la fuente deberá saber en algún momento cuál es el mejor nodo para seleccionarlo como líder, y después transmitirá esta información a los demás nodos.
6.5.3 Elecciones en sistemas de gran escala En sistemas distribuidos de tamaño medio y grande existen situaciones en las que el algoritmo necesita la elección de varios nodos, como es el caso de los superpuntos de las redes punto a punto.
Para la elección 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 través de la red sobrepuesta. Debe haber una porción predefinida de superpuntos, relativa al número total de nodos de la red sobrepuesta. Cada superpunto no debe necesitar servir a más de un número fijo de nodos normales.
