Sincronizacin en sistemas distribuidos
Marisol Garca Valls
Arquitecturas Distribuidas
2 Ingeniero de Telecomunicacin (Telemtica)
Departamento de Ingeniera Telemtica Universidad Carlos III de Madrid
[email protected]
ndice
Introduccin a la sincronizacin en sistemas distribuidos. Sincronizacin mediante relojes.
Relojes lgicos y relojes fsicos. Algoritmos de sincronizacin de relojes lgicos Algoritmos de sincronizacin de relojes fsicos. Aplicaciones de sincronizacin de relojes
Exclusin mutua en sistemas distribuidos.
Algoritmos centralizados, distribuidos y en anillo.
Algoritmos de eleccin.
Transacciones atmicas.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
Bibliografa
A.S. Tanenbaum. Distributed Operating Systems. PrenticeHall. 1995
Captulo 3.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
Comunicacin y sincronizacin distribuida
La comunicacin entre procesos puede realizarse mediante protocolos de capas, paso de mensajes segn el protocolo de peticin-respuesta, RPC y comunicacin de grupos. Los procesos no slo comunican sino que deben cooperar y sincronizarse. Cmo se implementan las secciones crticas en un sistema distribuido? Cmo se asignan los recursos? En sistemas centralizados los problemas de sincronizacin como la exclusin mutua se resuelven con mtodos como semforos, monitores, etc.
Estos no sirven en sistemas distribuidos porque utilizan memoria compartida.
Dos procesos que usan un semforo deben poder acceder a l. P.ej. si los procesos estn en dos mquinas distintas este mtodo no funciona. Determinar si un evento A ocurre antes que el evento B no es trivial.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
Sincronizacin mediante relojes
La sincronizacin en sistemas distribuidos se basa en algoritmos distribuidos. Las caractersticas de un algoritmo distribuido son:
Tienen la informacin relevante distribuida entre mltiples mquinas. Los procesos toman decisiones basndose nicamente en informacin local. Deben evitarse los puntos nicos de fallo en el sistema. No existe un reloj comn o ningn tiempo global de precisin.
En un sistema centralizado el tiempo es no ambiguo. En un sistema distribuido alcanzar un acuerdo sobre el tiempo no es trivial.
2144
Mquina en la que ejecuta el compilador
2145
output.class creado
2146
2147
Tiempo segn el reloj local
output.java creado
Mquina en la que ejecuta el editor
2142
2143
2144
2145
Tiempo segn el reloj local
2005 Marisol Garca Valls
Arquitecturas Distribuidas
El reloj
Los computadores tienen un circuito que permite contabilizar el tiempo : el reloj o temporizador. Es un cristal de cuarzo que oscila a una frecuencia bien definida cuando se le aplica una tensin. Cada cristal tiene dos registros asociados: un contador (counter) y un registro mantenedor (holding register). Cada oscilacin del cristal disminuye el contador en una unidad.
Cuando el contador llega a 0 se genera una interrupcin y el contador se recarga con el valor del registro mantenedor.
Cada interrupcin es conocida como un tic de reloj (clock tick). En un sistema con una sola CPU todos los procesos comparten el mismo reloj. Si hay varias CPUs, los relojes software no estarn sincronizados. Sus diferentes valores son conocidos como la desviacin del reloj. Es posible sincronizar todos los relojes para obtener un nico y no ambiguo estndar de tiempo?
Arquitecturas Distribuidas
2005 Marisol Garca Valls
Relojes lgicos y relojes fsicos
Acordar el tiempo exacto no es lo ms importante, sino acordar el orden en que suceden los eventos.
En ciertos algoritmos basta con que las mquinas conozcan el mismo tiempo, es decir, que presenten una consistencia interna respecto a sus relojes.
En estos tipos de algoritmos se suele hablar de relojes lgicos. Si adems de acordar el mismo tiempo, los relojes no pueden desviarse del tiempo real ms de una cierta cantidad se suele hablar de relojes fsicos.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
Sincronizacin de relojes lgicos. Algoritmo de Lamport I
Se define la relacin sucede antes como a b : todos los procesos acuerdan que el evento a sucede antes que el evento b. a b es cierto de forma directa en dos situaciones: Si a y b son eventos en el mismo proceso y a ocurre antes que b
Si a es el evento de un mensaje que es enviado por un proceso y b es el evento de un mensaje que es recibido por otro proceso
a b es transitiva.
Si los eventos x e y suceden en distintos procesos que no intercambian mensajes entonces x y no es cierta y tampoco lo es y x .
Se quiere asignar a los eventos un valor de tiempo C sobre el que todos los procesos estn de acuerdo. Los valores de tiempo cumplirn que si a b entonces C(a) < C(b) . Adems, se cumple que el tiempo de reloj C siempre se incrementa. Las correcciones se efectan sumando valores positivos.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
Sincronizacin de relojes lgicos. Algoritmo de Lamport II
0 0
1 0
2 0
0 0
1 0
2 0
6
12 18 24
8
16 24 32 B
10
20 30 40
6
12 18 24
8
16 24 32 B
10
20 30 40
30
36 42 48
40
48 56 64 C
50
60 70 80
30
36 42 48
40
48 61 69 C
50
60 70 80
54
60
72
80
90
100
70
76
77
85
90
100
2005 Marisol Garca Valls
Arquitecturas Distribuidas
10
Relojes fsicos
El algoritmo anterior ordena la sucesin de eventos pero no les asigna valores de tiempo real. En algunos sistemas (por ejemplo, en sistemas de tiempo real) el valor real del reloj es importante. Para estos sistemas se requieren varios relojes fsicos exteriores. Esto presenta problemas de sincronizacin de unos relojes respecto a otros y respecto al tiempo del mundo real. El tiempo del mundo real se mide respecto al Tiempo Universal Coordinado (UTC). El UTC es difundido por el NIST (Instituto Nacional de Tiempo Estndar) que opera una estacin de radio de onda corta WWV. WWV enva un pulso corto al comienzo de cada segundo UTC con una precisin de 1 ms (debido a las condiciones atmosfricas 10 ms ).
Arquitecturas Distribuidas
2005 Marisol Garca Valls
11
Sincronizacin de relojes fsicos
Algoritmo de Berkeley Algoritmos de media Mltiples fuentes externas de hora Aplicaciones de relojes sincronizados
2005 Marisol Garca Valls
Arquitecturas Distribuidas
12
Sincronizacin de relojes fsicos. Algoritmo de Berkeley
El servidor de tiempo es activo; es un daemon de tiempo. Peridicamente pregunta a cada mquina su valor de tiempo. Segn las respuestas obtiene la media del valor de tiempo e informa al resto de mquinas que deben ajustar sus relojes.
Este sistema es adecuado cuando ninguna mquina tiene un receptor WWV.
3:00
3:00
+25
-10
-20
+15
2005 Marisol Garca Valls
Arquitecturas Distribuidas
13
Sincronizacin de relojes fsicos. Algoritmos de media
Al contrario que el anterior, ste es un algoritmo descentralizado. Se divide el tiempo en intervalos de resincronizacin y de duracin fija. El intervalo i-simo es [T0 + iR, T0 + (i+1)R] donde T0 es un instante pasado y R es un parmetro de sistema. Al comienzo de cada intervalo cada mquina difunde su tiempo actual. Se arranca un temporizador para recoger todas las difusiones de otros. Cuando llegan, se ejecuta un algoritmo que calcula el nuevo tiempo. Variaciones de este algoritmo pueden ser:
Media de los valores. Descartar los valores ms alejados (ms altos y ms bajos) y obtener la media del resto (medida contra relojes defectuosos). Correccin de cada mensaje con una estimacin del tiempo de propagacin del origen.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
14
Sincronizacin de relojes fsicos. Mltiples fuentes externas de hora
Sistemas que requieren mucha precisin en la sincronizacin con el UTC pueden tener varios receptores WWV. El sistema operativo produce un rango o intervalo de tiempo en el que est el UTC que calcula. Distintas fuentes de UTC producirn distintos intervalos, por lo que debern alcanzar un acuerdo.
La base de este acuerdo est en que cada mquina con una fuente de UTC puede difundir su intervalo peridicamente (p.ej. al inicio de cada minuto UTC).
Cada procesador recoger los paquetes dentro de un tiempo determinado, segn: la distancia entre ellos, el nmero de pasarelas, colisiones, etc. Los sistemas operativos realizan este acuerdo de una forma diferente.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
15
Aplicaciones de sincronizacin de relojes
Entrega nica de mensajes (At-Most-Once Message Delivery)
Consistencia de cach basada en el reloj
2005 Marisol Garca Valls
Arquitecturas Distribuidas
16
Entrega nica de mensajes (At-Most-Once Message Delivery)
Los mensajes llegan a travs de una cierta conexin. Cada mensaje lleva un identificador de conexin y una marca de tiempo (timestamp).
Para cada conexin el servidor registra en una tabla las marcas ms recientes.
Si un mensaje llega con una marca de tiempo menor que la almacenada para esa conexin, el mensaje es un duplicado y se rechaza.
Para descartar marcas de tiempo viejas, cada servidor mantiene una variable:
G = TiempoActual MaxTiempoDeVida - MaxDesvoReloj
Cualquier marca de tiempo mayor que G puede ser borrada de forma segura. Los mensajes de conexiones desconocidas se aceptan si su marca es ms reciente que G.
Cada cierto tiempo T, el tiempo actual se escribe en el disco.
Despus de una cada se recarga G del disco incrementado con el perodo de actualizacin T.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
17
Consistencia de cach basada en el reloj
Si un cliente tiene en cach un fichero para lectura y otro lo pide para escritura, el servidor debe pedir al primero que lo invalide, aunque lo pidiera hace horas. La utilizacin de relojes sincronizados elimina esta sobrecarga.
Cuando un cliente pide un fichero, se le da un alquiler (lease) sobre el fichero que indica el tiempo durante el que la copia ser vlida.
Cuando la copia est a punto de expirar el cliente puede pedir la renovacin. Si expira, ya no podr utilizarse y no hay que mandar un mensaje al servidor. Si expira y sigue en la cach, el cliente puede preguntar al servidor si la copia (identificada por una marca de tiempo) an es la copia actual. Si sigue siendo la actual, se genera un nuevo alquiler y la copia no necesita ser reenviada. Si la copia est cacheada en varios clientes y uno pide escribir, el servidor tiene que pedir al resto que terminen su alquiler prematuramente. Si un cliente cae, el servidor no puede saber si ha muerto o es demasiado lento.
Utilizando temporizadores el servidor puede esperar y dejar que el alquiler expire.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
18
Algoritmos de exclusin mutua en sistemas distribuidos
Centralizado Distribuido Paso de testigo en anillo (token ring)
2005 Marisol Garca Valls
Arquitecturas Distribuidas
19
Algoritmo centralizado
Se basa en simular cmo es el comportamiento en un monoprocesador. Se selecciona un proceso como el coordinador. Si un proceso P quiere entrar en la seccin crtica enva un mensaje de peticin al coordinador indicando qu seccin crtica quiere obtener. Si actualmente no hay otro proceso en la seccin crtica, el coordinador enva una respuesta de concesin. Cuando P recibe la respuesta, entra en la seccin crtica.
0
Peticin
1
Peticin
2
Sin respuesta
0
Liberar
2
OK
OK
C
Coordinador
Cola vaca
2005 Marisol Garca Valls
Arquitecturas Distribuidas
20
Algoritmo centralizado (contina)
Se garantiza la exclusin mutua. Es justo. No se produce inanicin. Es un esquema fcil de implementar: slo se requieren tres mensajes por utilizacin de la seccin crtica (peticin, concesin, liberacin). Puede utilizarse para gestin de recursos en general (no slo asignacin de secciones crticas). Tener un coordinador centralizado tambin presenta problemas:
El coordinador constituye un nico punto de fallo. En un sistema grande, el coordinador puede presentar un cuello de botella en cuanto al rendimiento.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
21
Intenta evitar tener un nico punto de fallo. Este algoritmo [Ricart y Agrawala 1981] asume la existencia de una ordenacin total de todos los eventos en el sistema. El algoritmo de Lamport se toma como base y se usa para obtener marcas de tiempo para la exclusin mutua distribuida. Para entrar en una seccin crtica, P crea un mensaje de peticin que contiene: su nmero de proceso, la seccin crtica S que le interesa y el tiempo actual. P enva el mensaje a todos los procesos (l incluido). Se asume que el envo de mensajes es fiable (se reciben asentimientos). Cuando un proceso recibe un mensaje de peticin:
Si el receptor no est en S y no quiere entrar en ella, enva a P un mensaje OK. Si est en S, no contesta y encola la peticin. Si no est en S pero quiere entrar, compara marcas de tiempo. Gana la ms baja y procede segn sea el resultado.
Algoritmo distribuido
Al enviar la peticin, P espera hasta recibir todos los mensajes de concesin para S. Cuando salga de S, enviar mensajes OK a todos los procesos de la cola y los borra.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
22
Algoritmo distribuido II
8
0
8 8 12 OK 12
Entra en la seccin crtica
0
OK
0
OK Entra en la
1
12
1
OK
2 seccin crtica
Se garantiza la exclusin mutua sin interbloqueo ni inanicin. Se requiere 2(n-1) mensajes por entrada en la seccin crtica (ms que antes). Ahora existen n puntos de fallo: qu significa el silencio de un proceso? Puede mejorarse este algoritmo de forma que cuando se reciba una peticin, el receptor siempre enve una respuesta (sea de concesin o denegacin). Se utilizar un temporizador para tratar los mensajes perdidos.
Al recibir una denegacin, deber esperarse hasta recibir mensajes de concesin.
Otra mejora: permitir que un proceso entre en la seccin crtica si recibe mensajes de concesin de la mayora de procesos.
Este algoritmo es ms lento, complicado y menos robusto que el centralizado.
Arquitecturas Distribuidas
2005 Marisol Garca Valls
23
Algoritmo de paso de testigo en anillo (Token Ring)
Se asume un ordenamiento software de los procesos de forma que se construye un anillo lgico: los procesos conocen a su sucesor en el anillo. En el comienzo, el proceso 0 recibe un testigo que circular por el anillo. Para entrar en la seccin crtica un proceso deber poseer el testigo.
No se permite entrar en una segunda seccin crtica con el mismo testigo.
Se asegura la exclusin mutua: slo uno tiene el testigo. No se da inanicin. Un proceso esperar como mximo que el resto entre una vez en su seccin crtica. Es difcil detectar la prdida del testigo.
Es ms fcil recuperarse de las cadas de los procesos. Esto se detectar cuando un proceso intente pasarle el testigo a su vecino y falle.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
24
Comparacin de los tres algoritmos
Algoritmo
Mensajes por entrada/salida
Retardo en la entrada (en tiempo de mensajes)
Problemas
Centralizado Distribuido
3 2(n-1) 1a
2 2(n-1)
Cada del coordinador Cada de cualquier proceso Prdida del testigo Cada de un proceso
Anillo
0 a n-1
2005 Marisol Garca Valls
Arquitecturas Distribuidas
25
Algoritmos de eleccin de coordinador
En varios algoritmos hemos hablado de la existencia de coordinadores. pero cmo se determina quin es el coordinador?
Un proceso coordinador es aqul que se encarga de controlar los pasos a seguir en los procedimientos u operaciones tpicas de un sistema distribuido.
Veremos dos algoritmos bsicos para la eleccin de procesos coordinadores:
Alg. Bully
Alg. en anillo
2005 Marisol Garca Valls
Arquitecturas Distribuidas
26
Algoritmo bully
En el momento en que un proceso detecta que el coordinador actual no responde, inicia un proceso de votacin. Un proceso P que realiza una votacin procede de la siguiente forma:
P enva un mensaje VOTACION a todos los procesos con nmero mayor que l. Si no responde nadie, P gana la votacin y pasa a ser el nuevo coordinador. Si un proceso de mayor numeracin responde, ste continua el trabajo.
Si un proceso recibe un mensaje VOTACION de un proceso de menor numeracin, ste responde con un mensaje OK. El mensaje OK indica que el receptor est vivo y seguir el proceso de votacin. Al final todos los procesos desisten menos uno: el nuevo coordinador. Si un proceso que estaba cado arranca, iniciar un proceso de votacin.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
27
Algoritmos de eleccin. Algoritmo bully
El proceso 7 era el coordinador y cae. El proceso 4 es el primero que se da cuenta e inicia el proceso de votacin enviando mensajes de VOTACION a los procesos ms altos.
Al final, el proceso 6 ser el nuevo coordinador.
Si se arranca de nuevo el proceso 7, ste enviar un mensaje COORDINADOR al resto y ganar al resto.
2 4 0 1 5
Votacin Votacin Votacin
6
3
7
Coordinador previo
2005 Marisol Garca Valls
Arquitecturas Distribuidas
28
Algoritmo en anillo (Ring)
Todos los procesos estn fsicamente o lgicamente ordenados.
Cada proceso sabe cul es su sucesor; forman un anillo pero sin pasar un testigo.
Cuando un proceso nota que el coordinador no funciona, construye un mensaje de VOTACION con su nmero de proceso. Enva el mensaje VOTACION a su sucesor. Si el sucesor est cado el emisor lo salta y lo pasa al siguiente proceso en el anillo hasta encontrar un proceso no cado. En cada paso, el emisor aade su nmero de proceso en la lista del mensaje. Cuando el mensaje vuelve al proceso origen, reconoce su nmero en el mensaje. El tipo de mensaje se cambia a COORDINADOR y circula otra vez para informar a todos quin es el coordinador (el miembro de la lista con mayor numeracin). Cuando ha circulado el mensaje COORDINADOR es retirado y se sigue de forma normal.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
29
Algoritmo en anillo (Ring)
Los procesos 2 y 5 descubren de forma simultnea que el coordinador previo, el proceso 7, ha cado. Los dos comienzan un proceso de votacin enviando un mensaje VOTACION.
5 6 0
Mensaje de VOTACION 2
0
5 6 Coordinador previo ha cado 7
3
2 3
No hay respuesta
6
5
5
Mensaje de VOTACION
2005 Marisol Garca Valls
Arquitecturas Distribuidas
30
Transacciones atmicas. Introduccin
Las tcnicas de sincronizacin vistas hasta ahora son de muy bajo nivel. Existen mecanismos de mayor nivel de abstraccin que ocultan todos los detalles tcnicos. Esto permite concentrarse en los algoritmos en s que se quieren programar y en cmo los procesos trabajan juntos en paralelo. Estos mecanismos de alto nivel se llaman transacciones atmicas (tambin se conocen como acciones atmicas o, simplemente, transacciones).
2005 Marisol Garca Valls
Arquitecturas Distribuidas
31
Transacciones atmicas. Introduccin (cont.)
El modelo original de las transacciones atmicas est inspirado en los contratos que tienen lugar en el mundo de los negocios.
Un proceso P anuncia que quiere comenzar una transaccin con otros procesos.
Entonces comienzan una serie de negociaciones (creacin y destruccin de objetos, etc.). P anunciar que quiere que los otros procesos se comprometan respecto a las operaciones que han realizado hasta entonces. Si todos estn de acuerdo, los resultados se hacen definitivos (permanentes). Si alguno no est de acuerdo, el trabajo se deshace y se vuelve al mismo punto en el que se estaba antes de la transaccin. Por lo tanto, las transacciones tienen la propiedad todo o nada.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
32
Transacciones atmicas. Ejemplo
Supongamos el sistema informtico de un banco. A travs de este sistema se pueden realizar operaciones de transferencias entre dos cuentas distintas de un cliente. Estas transferencias actualizan una base de datos que mantiene la informacin relevante de la situacin de las cuentas. Un usuario se conecta al sistema del banco a travs de mdem para sacar dinero de una cuenta A y traspasarlo a otra cuenta B. La operacin se efecta en dos pasos:
Reintegrar(cantidad, cuentaA) Depositar(cantidad, cuentaB)
Supongamos que la conexin telefnica se corta despus del reintegro: el dinero se esfuma.
La solucin sera agrupar las dos operaciones en una transaccin atmica. De esta forma, o se completan las dos o ninguna de ellas. Las transacciones debern poder deshacerse (roll back), es decir, volver al estado inicial en caso de ser abortadas antes de completarse.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
33
El modelo de Transaccin. Almacenamiento estable
Existen tres categoras de almacenamiento: RAM, disco y almacenamiento estable. El almacenamiento estable est diseado para aguantar cualquier tipo de fallos. Puede implementarse con dos discos. Cuando suceden actualizaciones, los bloques de uno de ellos son copiados en el otro disco.
Almacenamiento estable Disco 1 g f e d h g f e d a b c Almacenamiento estable Almacenamiento estable
a
b c
h
g f
a
b c
h
g f
a
b c Error de checksum
e d h a
e d h a
Disco 2
g f e d
b c
g f e d c
2005 Marisol Garca Valls
Arquitecturas Distribuidas
34
El modelo de Transaccin. Primitivas de transaccin
La programacin utilizando transacciones requiere la utilizacin de ciertas primitivas.
Estas son ofrecidas por el sistema operativo o por el entorno de ejecucin del lenguaje utilizado.
BEGIN_TRANSACTION END_TRANSACTION ABORT_TRANSACTION READ WRITE
Las primitivas dependen del tipo de objetos o informacin utilizada en la transaccin. Las operaciones entre las dos primitivas BEGIN_TRANSACTION y END_TRANSACTION son el cuerpo de la transaccin. Veamos un ejemplo de reserva de billetes utilizando transacciones:
BEGIN_TRANSACTION reservar MAD-JFK; reservar JFK-SLO; reservar SLO-ABQ; END_TRANSACTION BEGIN_TRANSACTION reservar MAD-JFK; reservar JFK-SLO; SLO-ABQ lleno ABORT_TRANSACTION; END_TRANSACTION
2005 Marisol Garca Valls
Arquitecturas Distribuidas
35
El modelo de Transaccin. Propiedades de las transacciones
Una transaccin debe presentar las siguientes propiedades (ACID). ATOMICIDAD: la transaccin sucede de forma indivisible.
O sucede completamente o no suceden ninguna de sus operaciones. Mientras est en curso ningn proceso puede ver sus estados intermedios.
CONSISTENCIA: se mantienen todas las invariantes del sistema.
En el entorno bancario, una invariante es la conservacin del dinero.
AISLAMIENTO: las transacciones concurrentes no interfieren entre s.
BEGIN_TRANSACTION x = 0; x = x + 1; END_TRANSACTION
Plan 1 Plan 2 Plan 3 x = 0; x = 0; x = 0; x = x + 1; x = 0; x = 0; BEGIN_TRANSACTION x = 0; x = x + 2; END_TRANSACTION x = 0; x = x + 1; x = x + 1; x = x + 2; x = x + 2; x = 0; BEGIN_TRANSACTION x = 0; x = x + 3; END_TRANSACTION x = 0; x = 0; x = x + 2; x = x + 3; x = x + 3; x = x + 3; Bien Bien Mal
DURACION: una vez la transaccin se compromete (commit) los cambios ocasionados por una transaccin son permanentes.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
36
Implementacin de las transacciones
Espacio privado de trabajo Lista de intenciones (Writeahead Log)
Protocolo de compromiso en dos fases
2005 Marisol Garca Valls
Arquitecturas Distribuidas
37
Espacio de trabajo privado
El espacio de trabajo de un proceso comprende el conjunto de todos los ficheros y objetos que utiliza durante su ejecucin.
Cuando un proceso comienza una transaccin, se le da un espacio de trabajo privado. Hasta que la transaccin se compromete o se aborta, todos los accesos se hacen sobre los objetos del espacio privado. El problema es el coste prohibitivo de copiar todo a un espacio privado. Existen varias formas de solucionar este problema. Si un objeto se abre slo para lectura, no se hace una copia al espacio privado. De esta forma, el espacio privado slo contiene una referencia al espacio padre. Si un objeto se abre para escritura, se localiza a travs de la referencia pero antes de ser modificado se copia al espacio privado.
Arquitecturas Distribuidas
2005 Marisol Garca Valls
38
Espacio de trabajo privado
Una mejora consiste en no copiar todo el objeto o fichero. Slo se copiar el ndice del fichero al espacio privado.
ndice 0 1 2
ndice original 0 1 2
Espacio de trabajo privado 0 1 2 0 1 2
2 0
0 3
2 0 3
2005 Marisol Garca Valls
Arquitecturas Distribuidas
39
Los ficheros son modificados directamente (no hay copias locales). Las modificaciones se registran en una lista de intenciones en almacenamiento estable. Para cada modificacin se escribe una entrada o registro en la lista que contiene:
La transaccin que la realiza. Fichero y bloque que son modificados. Antiguo y nuevo valor.
Lista de intenciones
El cambio se har efectivo despus de que la lista de intenciones haya sido actualizada de forma exitosa. Durante una transaccin, antes de ejecutar una operacin que implique una modificacin, se escribe un registro con los valores antiguo y nuevo. Si la transaccin se compromete, se escribe un registro de compromiso en la lista. Si la transaccin se aborta, la lista se utiliza para volver al estado original.
Empezando por el final, cada registro es ledo y se deshace el cambio que ste describe.
Despus de una cada, utilizando la lista de intenciones es posible terminar una transaccin o deshacerla. Arquitecturas Distribuidas
2005 Marisol Garca Valls
40
Lista de intenciones (cont.)
Tenemos una transaccin simple que utiliza dos variables (u objetos) compartidas: x e y.
x = 0; y = 0; BEGIN_TRANSACTION x = x + 1; y = y + 2; x = y * y; END_TRANSACTION
Lista de intenciones
Lista de intenciones
Lista de intenciones
x=0/1
x=0/1 y=0/2
x=0/1 y=0/2 x=1/4
2005 Marisol Garca Valls
Arquitecturas Distribuidas
41
Protocolo de compromiso en dos fases
Cuando finalizan todas las operaciones de una transaccin, sta debe comprometerse (commit), es decir, indicar que ha finalizado de forma exitosa. En un entorno distribuido el compromiso de una transaccin puede requerir la cooperacin de mltiples procesos en mquinas diferentes. El compromiso debe hacerse de forma atmica (de forma instantnea e indivisible). Se basa en la existencia de un proceso coordinador. Normalmente, el coordinador es el proceso que ejecuta la transaccin. Coordinador
Escribir Preparar en la lista Enviar mensaje Preparar
Subordinado
Fase 1
Recoger todas las respuestas Escribir registro en lista Enviar mensaje Comprometer
Escribir Preparado en la lista Enviar mensaje Preparado
Fase 2
Escribir Compromiso en lista
Comprometerse
Enviar mensaje Finalizado
2005 Marisol Garca Valls
Arquitecturas Distribuidas
42
Protocolo de compromiso en dos fases (cont.)
Cuando el coordinador escribe un registro de compromiso (en la fase 2), es cuando realmente se compromete la transaccin. En ese momento la transaccin se realizar sin importar lo que suceda. Este protocolo es muy flexible ante las cadas de las mquinas. Si el coordinador cae despus de escribir el registro inicial (Preparar), cuando se recupere continuar donde lo dej. Si cae despus de escribir el resultado recibido de los subordinados, cuando se recupere reinformar a los subordinados del resultado. Si un subordinado cae antes de haber contestado al primer mensaje, el coordinador continuar mandndole mensajes por un tiempo. Si cae despus, cuando se recupere leer la lista y ver cmo proceder.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
43
Control de la concurrencia. Cerrojos (Locking)
Cuando un proceso va a leer o escribir un objeto como parte de una transaccin debe bloquear (echarle el cerrojo) el fichero.
El bloqueo puede hacerse a travs de un nico gestor de bloqueo centralizado o con un gestor local de bloqueos en cada mquina para gestionar ficheros locales.
El gestor mantiene una lista de objetos bloqueados y rechaza peticiones de bloquear estos objetos.
Los cerrojos sobre estos objetos normalmente son adquiridos y liberados por el sistema de transacciones y no por los programadores.
Este mecanismo puede ser mejorado distinguiendo cerrojos de lectura de cerrojos de escritura. Los cerrojos de lectura son compartidos; los de escritura son exclusivos. La unidad de bloqueo suele ser el objeto entero, aunque puede ser ms amplio o menor. El tamao del objeto a bloquear se llama granularidad del bloqueo.
Con una granularidad pequea se tienen bloqueos ms precisos y mayor paralelismo, pero se requieren ms cerrojos, es ms compleja y mayor riesgo de interbloqueos.
Arquitecturas Distribuidas
2005 Marisol Garca Valls
44
Control de la concurrencia. Cerrojos (Locking) (cont.)
La mayora de transacciones implementadas con cerrojos (o bloqueo de objetos) usan el bloqueo de dos fases.
En la fase de crecimiento, el proceso primero adquiere todos los cerrojos que necesita.
En la fase de disminucin, el proceso los libera. Existe una variante de bloqueo estricto en dos fases donde la fase de disminucin no se comienza hasta que la transaccin no ha terminado. As la transaccin siempre leer el valor escritor por la transaccin que se ha comprometido.
Punto de bloqueo Nmero de cerrojos
Fase de crecimiento
Fase de disminucin
Tiempo
Arquitecturas Distribuidas
2005 Marisol Garca Valls
45
Control de la concurrencia. Control de concurrencia optimista
Este protocolo se basa en que los procesos se ejecutan sin preocuparse de lo que est haciendo el resto.
Si existe algn problema, ste se tratar cuando aparezca.
Funciona bastante bien porque en la prctica los conflictos se producen en raras ocasiones. El protocolo anota los objetos que han sido ledos o escritos. Cuando la transaccin A va a comprometerse, comprueba las otras transacciones para ver si alguno de sus ficheros ha sido modificado desde que A comenz. Si es as, A es abortada. Si no A se compromete. Este protocolo se suele implementar con la tcnica de los espacios de trabajo privados. Sus ventajas son que no se producen interbloqueos y permite mximo paralelismo.
El problema es que si una transaccin falla, deber ejecutarse de nuevo. Adems en casos de alta carga, este protocolo baja su rendimiento de forma notable.
2005 Marisol Garca Valls
Arquitecturas Distribuidas
46
Control de la concurrencia. Marcas de tiempo (timestamps)
A cada transaccin se le asigna una marca de tiempo. Cada objeto tiene una marca de tiempo para lectura y otra para escritura. El procesamiento de las transacciones se considerar correcto siempre que cuando desde una transaccin A se acceda a un fichero u objeto F, se encuentre que la marca de tiempo de F es menor que la de A. Si la marca de F es mayor que la de A significar que una transaccin que empez ms tarde que A ha modificado el objeto y se ha comprometido. A ser abortada. La transaccin con una marca menor siempre deber ejecutarse primero.
2 intenta escribir
TRD TWR (1) T (2) TRD TWR (3) TWR (1) T (2)
2 intenta leer
TWR TTENT T (1) (3) (2) T TWR TTENT
(2)
(3)
2 intenta escribir EXITO
3 ha escrito o ledo el fichero y se compromete Se aborta 2
2 intenta leer EXITO
3 2 intenta intenta leer, debe escribir esperar EXITO
3 escribe y se compromete o est apunto Se aborta 2
Arquitecturas Distribuidas
2005 Marisol Garca Valls
