Introduccin a la Sincronizacin en Sistemas Distribuidos

Adems de la comunicacin, es fundamental la forma en que los procesos [25, Tanenbaum]:

Cooperan.
Se sincronizan entre s.
Ejemplos:
Forma de implantar las regiones crticas.
Forma de asignar recursos en un sistema distribuido.
Los problemas relativos a las regiones crticas, exclusin mutua y la sincronizacin:
Generalmente se resuelven en sistemas de una sola cpu con mtodos como los
semforos y los monitores:
o Se basan en la memoria compartida.
o No son aplicables a sistemas distribuidos.
Otro problema de gran importancia es el tiempo y la forma de medirlo, ya que juega un papel
fundamental en algunos modelos de sincronizacin.
Sincronizacin de Relojes
Generalmente los algoritmos distribuidos tienen las siguientes propiedades [25, Tanenbaum]:
La informacin relevante se distribuye entre varias mquinas.
Los procesos toman las decisiones solo con base en la informacin disponible en forma
local.
Debe evitarse un nico punto de fallo en el sistema.
No existe un reloj comn o alguna otra fuente precisa del tiempo global.
Los primeros tres puntos indican que es inaceptable reunir toda la informacin en un solo lugar
para su procesamiento, pero lograr la sincronizacin sin centralizacin requiere hacer las cosas
distintas al caso de los sistemas operativos tradicionales.
El ltimo punto tambin es crucial:
En un sistema centralizado el tiempo no es ambiguo.
En un sistema distribuido no es trivial poner de acuerdo a todas las mquinas en la hora.
Se requiere un acuerdo global en el tiempo, pues la falta de sincronizacin en los relojes
puede ser drstica en procesos dependientes del tiempo.
La pregunta es si es posible sincronizar todos los relojes en un sistema distribuido.
Relojes Lgicos
Las computadoras poseen un circuito para el registro del tiempo conocido como dispositivo
reloj [25, Tanenbaum].
Es un cronmetro consistente en un cristal de cuarzo de precisin sometido a una tensin
elctrica que:
Oscila con una frecuencia bien definida que depende de:
o Al forma en que se corte el cristal.
o El tipo de cristal.
o La magnitud de la tensin.
A cada cristal se le asocian dos registros:
o Registro contador.
o Registro mantenedor.
Cada oscilacin del cristal decrementa en 1 al contador.
Cuando el contador llega a 0:
o Se genera una interrupcin.
o El contador se vuelve a cargar mediante el registro mantenedor.
Se puede programar un cronmetro para que genere una interrupcin x veces por
segundo.
Cada interrupcin se denomina marca de reloj.
Para una computadora y un reloj:
No interesan pequeos desfasajes del reloj porque:

Todos los procesos de la mquina usan el mismo reloj y tendrn consistencia

interna.
o Importan los tiempos relativos.
Para varias computadoras con sus respectivos relojes:
Es imposible garantizar que los cristales de computadoras distintas oscilen con la
misma frecuencia.
Habr una prdida de sincrona en los relojes (de software), es decir que tendrn
valores distintos al ser leidos.
La diferencia entre los valores del tiempo se llama distorsin del reloj y podra generar fallas en
los programas dependientes del tiempo.
Lamport demostr que la sincronizacin de relojes es posible y present un algoritmo para
lograrlo.
Lamport seal que la sincronizacin de relojes no tiene que ser absoluta:
Si 2 procesos no interactan no es necesario que sus relojes estn sincronizados.
Generalmente lo importante no es que los procesos estn de acuerdo en la hora, pero s
importa que coincidan en el orden en que ocurren los eventos.
Para ciertos algoritmos lo que importa es la consistencia interna de los relojes:
No interesa su cercana particular al tiempo real (oficial).
Los relojes se denominan relojes lgicos.
Los relojes fsicos son relojes que:
Deben ser iguales (estar sincronizados).
No deben desviarse del tiempo real ms all de cierta magnitud.
Para sincronizar los relojes lgicos, Lamport defini la relacin ocurre antes de (happensbefore):
Si a y b son eventos en el mismo proceso y a ocurre antes de b, entonces a
> b es verdadero.
Ocurre antes de es una relacin transitiva:
o Si a > b y b > c, entonces a > c.
Si dos eventos x e y estn en procesos diferentes que no intercambian mensajes,
entonces x > y no es verdadero, pero tampoco lo es y > x:
o Se dice que son eventos concurrentes.
Necesitamos una forma de medir el tiempo tal que a cada evento a, le podamos asociar un
valor del tiempo C(a) en el que todos los procesos estn de acuerdo:
Se debe cumplir que:
o Si a > b entonces C(a) < C(b).
o El tiempo del reloj, C, siempre debe ir hacia adelante (creciente), y nunca
hacia atrs (decreciente).
El algoritmo de Lamport asigna tiempos a los eventos.
Consideramos tres procesos que se ejecutan en diferentes mquinas, cada una con su propio
reloj y velocidad (ver Figura 9.1 [25, Tanenbaum]):
El proceso 0 enva el mensaje a al proceso 1 cuando el reloj de 0 marca 6.
El proceso 1 recibe el mensaje a cuando su reloj marca 16.
Si el mensaje acarrea el tiempo de inicio 6, el proceso 1 considerar que tard 10
marcas de reloj en viajar.
El mensaje b de 1 a 2 tarda 16 marcas de reloj.
El mensaje c de 2 a 1 sale en 60 y llega en 56, tardara un tiempo
negativo, lo cual es imposible.
El mensaje d de 1 a 0 sale en 64 y llega en 54.
Lamport utiliza la relacin ocurre antes de:
o Si c sale en 60 debe llegar en 61 o en un tiempo posterior.
o Cada mensaje acarrea el tiempo de envo, de acuerdo con el reloj del emisor.
o Cuando un mensaje llega y el reloj del receptor muestra un valor anterior al
tiempo en que se envi el mensaje:
o

El receptor adelanta su reloj para que tenga una unidad ms que el

tiempo de envo.

Este algoritmo cumple nuestras necesidades para el tiempo global, si se hace el siguiente
agregado:
Entre dos eventos cualesquiera, el reloj debe marcar al menos una vez.
Dos eventos no deben ocurrir exactamente al mismo tiempo.
Con este algoritmo se puede asignar un tiempo a todos los eventos en un sistema distribuido,
con las siguientes condiciones:
Si a ocurre antes de b en el mismo proceso, C(a) < C(b).
Si a y b son el envo y recepcin de un mensaje, C(a) < C(b).
Para todos los eventos a y b, C(a) es distinto de C(b).
Relojes Fsicos
El algoritmo de Lamport proporciona un orden de eventos sin ambigedades, pero [25,
Tanenbaum]:
Los valores de tiempo asignados a los eventos no tienen porqu ser cercanos a los
tiempos reales en los que ocurren.
En ciertos sistemas (ej.: sistemas de tiempo real ), es importante la hora real del reloj:
o Se precisan relojes fsicos externos (ms de uno).
o Se deben sincronizar:
Con los relojes del mundo real.
Entre s.
La medicin del tiempo real con alta precisin no es sencilla.
Desde antiguo el tiempo se ha medido astronmicamente.
Se considera el da solar al intervalo entre dos trnsitos consecutivos del sol, donde el trnsito
del sol es el evento en que el sol alcanza su punto aparentemente ms alto en el cielo.
El segundo solar se define como 1 / 86.400 de un da solar.
Como el perodo de rotacin de la tierra no es constante, se considera el segundo solar
promedio de un gran nmero de das.
Los fsicos definieron al segundo como el tiempo que tarda el tomo de cesio 133 para hacer
9.192.631.770 transiciones:

Se tom este nmero para que el segundo atmico coincida con el segundo solar
promedio de 1958.

La Oficina Internacional de la Hora en Pars (BIH) recibe las indicaciones de cerca de 50

relojes atmicos en el mundo y calcula el tiempo atmico internacional (TAI).
Como consecuencia de que el da solar promedio (DSP) es cada vez mayor, un da TAI es 3
mseg menor que un DSP:
La BIH introduce segundos de salto para hacer las correcciones necesarias para que
permanezcan en fase:
o El sistema de tiempo basado en los segundos TAI.
o El movimiento aparente del sol.
Surge el tiempo coordenado universal (UTC).
El Instituto Nacional del Tiempo Estndar (NIST) de EE. UU. y de otros pases:
Operan estaciones de radio de onda corta o satlites de comunicaciones.
Transmiten pulsos UTC con cierta regularidad establecida (cada segundo, cada 0,5
mseg, etc.).
Se deben conocer con precisin la posicin relativa del emisor y del receptor:
o Se debe compensar el retraso de propagacin de la seal.
o Si la seal se recibe por mdem tambin se debe compensar por la ruta de la
seal y la velocidad del mdem.
o Se dificulta la obtencin del tiempo con una precisin extremadamente alta.
Algoritmos Para la Sincronizacin de Relojes
Si una mquina tiene un receptor de UTC, todas las mquinas deben sincronizarse con ella [25,
Tanenbaum].
Si ninguna mquina tiene un receptor de UTC:
Cada mquina lleva el registro de su propio tiempo.
Se debe mantener el tiempo de todas las mquinas tan cercano como sea posible.
Se supone que cada mquina tiene un cronmetro que provoca una interrupcin h veces por
segundo.
Cuando el cronmetro se detiene, el manejador de interrupciones aade 1 a un reloj en
software.
El reloj en software mantiene un registro del nmero de marcas (interrupciones) a partir de
cierta fecha acordada antes; al valor de este reloj se lo llama C.
Cuando el tiempo UTC es t, el valor del reloj en la mquina p es Cp(t):
Lo ideal sera que Cp(t) = t para toda p y todo t:
o dC/dt debera ser 1.
Lo real es que los cronmetros no realizan interrupciones exactamente h veces por
segundo:
o Poseen un error relativo de aproximadamente 10-5 .
o El fabricante especifica una constante llamada tasa mxima de
alejamiento que acota el error.
o El cronmetro funciona dentro de su especificacin si existe una constante
y se cumple:
1 - dC / dt 1 + .
Si dos relojes se alejan de UTC en la direccin opuesta:
En un instante t luego de la sincronizacin podran estar tan alejados como: 2 t.
Para garantizar que no difieran ms de :
o Se deben volver a sincronizar (en software) al menos cada / 2 segundos.
Algoritmo de Cristian
Es adecuado para sistemas en los que:

Una mquina tiene un receptor UTC, por lo que se la llama despachador del tiempo.
El objetivo es sincronizar todas las mquinas con ella.
Cada mquina enva un mensaje al servidor para solicitar el tiempo actual, peridicamente, en
un tiempo no mayor que / 2 segundos.
El despachador del tiempo responde prontamente con un mensaje que contiene el tiempo actual
CUTC.
Cuando el emisor obtiene la respuesta puede hacer que su tiempo sea CUTC.
Un gran problema es que el tiempo no puede correr hacia atrs:
CUTC no puede ser menor que el tiempo actual C del emisor.
La atencin del requerimiento en el servidor de tiempos requiere un tiempo del
manejador de interrupciones.
Tambin se debe considerar el tiempo de transmisin.
El cambio del reloj se debe introducir de manera global:
Si el cronmetro genera 100 interrupciones por segundo:
o Cada interrupcin aade 10 mseg al tiempo.
o Para atrasar solo agregara 9 mseg.
o Para adelantar agregara 11 mseg.
La correccin por el tiempo del servidor y el tiempo de transmisin se hace midiendo en el
emisor:
El tiempo inicial (envo) T0.
El tiempo final (recepcin) T1.
Ambos tiempos se miden con el mismo reloj.
El tiempo de propagacin del mensaje ser (T1 - T0) / 2.
Si el tiempo del servidor para manejar la interrupcin y procesar el mensaje es I:
El tiempo de propagacin ser (T1 - T0 - I) / 2.
Para mejorar la precisin:
Se toman varias mediciones.
Se descartan los valores extremos.
Se promedia el resto.
El tiempo de propagacin se suma al tiempo del servidor para sincronizar al emisor cuando ste
recibe la respuesta.
Algoritmo de Berkeley
En el algoritmo de Cristian el servidor de tiempo es pasivo.
En el algoritmo de Berkeley el servidor de tiempo:
Es activo.
Realiza un muestreo peridico de todas las mquinas para preguntarles el tiempo.
Con las respuestas:
o Calcula un tiempo promedio.
o Indica a las dems mquinas que avancen su reloj o disminuyan la velocidad
del mismo hasta lograr la disminucin requerida.
Es adecuado cuando no se dispone de un receptor UTC.
Algoritmos con Promedio
Los anteriores son algoritmos centralizados.
Una clase de algoritmos descentralizados divide el tiempo en intervalos de resincronizacin de
longitud fija:
El i -simo intervalo:
o Inicia en T0 + i R y va hasta T0 + (i + 1) R.
o T0 es un momento ya acordado en el pasado.
o R es un parmetro del sistema.
Al inicio de cada intervalo cada mquina transmite el tiempo actual segn su reloj.
Debido a la diferente velocidad de los relojes las transmisiones no sern simultneas.

Luego de que una mquina transmite su hora, inicializa un cronmetro local para reunir las
dems transmisiones que lleguen en cierto intervalo S.
Cuando recibe todas las transmisiones se ejecuta un algoritmo para calcular una nueva hora
para los relojes.
Una variante es promediar los valores de todas las dems mquinas.
Otra variante es descartar los valores extremos antes de promediar (los m mayores y los m
menores).
Una mejora al algoritmo considera la correccin por tiempos de propagacin.
Varias Fuentes Externas de Tiempo
Los sistemas que requieren una sincronizacin muy precisa con UTC se pueden equipar con
varios receptores de UTC.
Las distintas fuentes de tiempo generaran distintos rangos (intervalos de tiempo) donde
caern los respectivos UTC, por lo que es necesaria una sincronizacin.
Como la transmisin no es instantnea se genera una cierta incertidumbre en el tiempo.
Cuando un procesador obtiene todos los rangos de UTC:
Verifica si alguno de ellos es ajeno a los dems y de serlo lo descarta por ser un valor
extremo.
Calcula la interseccin (en el tiempo) de los dems rangos.
La interseccin determina un intervalo cuyo punto medio ser el UTC y la hora del reloj
interno.
Se deben compensar los retrasos de transmisin y las diferencias de velocidades de los relojes.
Se debe asegurar que el tiempo no corra hacia atrs.
Se debe resincronizar peridicamente desde las fuentes externas de UTC.

Exclusin Mutua
Cuando un proceso debe leer o actualizar ciertas estructuras de datos compartidas [25,
Tanenbaum]:
Primero ingresa a una regin crtica para lograr la exclusin mutua y garantizar que
ningn otro proceso utilizar las estructuras de datos al mismo tiempo.
En sistemas monoprocesadores las regiones crticas se protegen con semforos, monitores y
similares.
En sistemas distribuidos la cuestin es ms compleja.
Un Algoritmo Centralizado
La forma ms directa de lograr la exclusin mutua en un sistema distribuido es simular a la
forma en que se lleva a cabo en un sistema monoprocesador.
Se elige un proceso coordinador.
Cuando un proceso desea ingresar a una regin crtica:
Enva un mensaje de solicitud al coordinador:
o Indicando la regin crtica.
o Solicitando permiso de acceso.
Si ningn otro proceso est en ese momento en esa regin crtica:
o El coordinador enva una respuesta otorgando el permiso.
Cuando llega la respuesta el proceso solicitante entra a la regin crtica.
Si un proceso pide permiso para entrar a una regin crtica ya asignada a otro proceso:
El coordinador no otorga el permiso y encola el pedido.
Cuando un proceso sale de la regin crtica enva un mensaje al coordinador para liberar su
acceso exclusivo:

El coordinador extrae el primer elemento de la cola de solicitudes diferidas y enva a

ese proceso un mensaje otorgando el permiso, con lo cual el proceso queda habilitado
para acceder a la regin crtica solicitada.
Es un esquema sencillo, justo y con pocos mensajes de control.
La limitante es que el coordinador puede ser un cuello de botella y puede fallar y bloquear a los
procesos que esperan una respuesta de habilitacin de acceso.
Un Algoritmo Distribuido
El objetivo es no tener un nico punto de fallo (el coordinador central).
Un ej. es el algoritmo de Lamport mejorado por Ricart y Agrawala.
Se requiere un orden total de todos los eventos en el sistema para saber cul ocurri primero.
Cuando un proceso desea entrar a una regin crtica:
Construye un mensaje con el nombre de la regin crtica, su nmero de proceso y la
hora actual.
Enva el mensaje a todos los dems procesos y de manera conceptual a l mismo.
Se supone que cada mensaje tiene un reconocimiento.
Si el receptor no est en la regin crtica y no desea entrar a ella, enva de regreso un mensaje
o.k. al emisor.
Si el receptor ya est en la regin crtica no responde y encola la solicitud.
Si el receptor desea entrar a la regin crtica pero an no lo logr, compara:
La marca de tiempo del mensaje recibido con,
La marca contenida en el mensaje que envi a cada uno.
La menor de las marcas gana.
Si el mensaje recibido es menor el receptor enva un o.k.
Si su propio mensaje tiene una marca menor el receptor no enva nada y encola el
pedido.
Luego de enviar las solicitudes un proceso:
Espera hasta que alguien ms obtiene el permiso.
Cuando llegan todos los permisos puede entrar a la regin crtica.
Cuando un proceso sale de la regin crtica:
Enva mensajes o.k. a todos los procesos en su cola.
Elimina a todos los elementos de la cola.
La exclusin mutua queda garantizada sin bloqueo ni inanicin.
El nmero de mensajes necesarios por entrada es 2(n - 1), siendo n el nmero total de
procesos en el sistema.
No existe un nico punto de fallo sino n:
Si cualquier proceso falla no responder a las solicitudes.
La falta de respuesta se interpretar como negacin de acceso:
o Se bloquearn los siguientes intentos de los dems procesos por entrar a todas
las regiones crticas.
Se incrementa la probabilidad de fallo en n veces y tambin el trfico en la red.
Se puede solucionar el bloqueo si:
El emisor espera y sigue intentando hasta que regresa una respuesta o,
El emisor concluye que el destinatario est fuera de servicio.
Otro problema es que:
Se utilizar una primitiva de comunicacin en grupo o,
Cada proceso debe mantener la lista de miembros del grupo, incluyendo los procesos
que ingresan, los que salen y los que fallan.
Se complica para gran nmero de procesos.
Un importante problema adicional es que:
Todos los procesos participan en todas las decisiones referentes a las entradas en las
regiones crticas.
Se sobrecarga el sistema.

Una mejora consiste en permitir que un proceso entre a una regin crtica con el permiso de una
mayora simple de los dems procesos (en vez de todos):
Luego de que un proceso otorg el permiso a otro para entrar a una regin crtica, no
puede otorgar el mismo permiso a otro proceso hasta que el primero libere su permiso.
Un Algoritmo de Anillo de Fichas (Token Ring)
Los procesos se organizan por software formando un anillo lgico asignndose a cada proceso
una posicin en el anillo.
Cada proceso sabe cul es el siguiente luego de l.
Al inicializar el anillo se le da al proceso 0 una ficha (token) que circula en todo el anillo,
que se transfiere del proceso k al k + 1 en mensajes puntuales.
Cuando un proceso obtiene la ficha de su vecino verifica si intenta entrar a una regin crtica:
En caso positivo:
o El proceso entra a la regin crtica, hace el proceso necesario y sale de ella.
o Despus de salir pasa la ficha a lo largo del anillo:
No se puede entrar a una segunda regin crtica con la misma ficha
(token o permiso).
En caso negativo:
o La vuelve a pasar.
En un instante dado solo un proceso puede estar en una regin crtica.
Si la ficha se pierde debe ser regenerada, pero es difcil detectar su perdida:
La cantidad de tiempo entre las apariciones sucesivas de la ficha en la red no est
acotada, por ello es difcil decidir si est perdida o demorada en algn proceso que no la
libera.
La falla de un proceso es detectada cuando su vecino intenta sin xito pasarle la ficha:
Se lo debe eliminar del grupo y pasar la ficha al siguiente proceso activo.
Todos los procesos deben mantener la configuracin actual del anillo.
Algoritmos de Eleccin
Son los algoritmos para la eleccin de un proceso coordinador, iniciador, secuenciador, etc.
[25, Tanenbaum].
El objetivo de un algoritmo de eleccin es garantizar que iniciada una eleccin sta concluya
con el acuerdo de todos los procesos con respecto a la identidad del nuevo coordinador.
El Algoritmo del Granduln o de Garca-Molina
Un proceso P inicia una eleccin cuando observa que el coordinador ya no responde a las
solicitudes.
P realiza una eleccin de la siguiente manera:
Enva un mensaje eleccin a los dems procesos con un nmero mayor.
Si nadie responde asume que gana la eleccin y se convierte en el nuevo coordinador.
Si un proceso con un nmero mayor responde, toma el control y el trabajo de P
termina.
Un proceso puede recibir en cualquier momento un mensaje eleccin de otros procesos con un
nmero menor:
Enva de regreso un mensaje o.k. al emisor para indicar que est vivo y que tomar el
control.
Realiza una eleccin salvo que ya est haciendo alguna.
En cierto momento todos los procesos han declinado ante uno de ellos, que ser el nuevo
coordinador, que enva un mensaje coordinador a todos los procesos para anunciarlo.
Si un proceso inactivo se activa realiza una eleccin:
Si l tiene el nmero ms alto ser el nuevo coordinador:
o Siempre gana el proceso que posee el nmero mayor, de ah el nombre
algoritmo del granduln.

Un Algoritmo de Anillo
Se supone que los procesos tienen un orden fsico o lgico, es decir que cada proceso conoce a
su sucesor.
Cuando algn proceso observa que el coordinador no funciona:
Construye un mensaje eleccin con su propio nmero de proceso.
Enva el mensaje a su sucesor.
Si el sucesor est inactivo:
o El emisor va hacia el siguiente nmero del anillo o al siguiente de ste.
o Contina hasta localizar un proceso en ejecucin.
o En cada paso, al emisor aade su propio nmero de proceso a la lista en el
mensaje.
En cierto momento el mensaje regresa al proceso que lo inici:
o El proceso lo reconoce al recibir un mensaje con su propio nmero de proceso.
El mensaje de eleccin se transforma en mensaje coordinador y circula nuevamente:
o Informa a los dems procesos:
Quin es el coordinador, es decir, el miembro de la lista con el nmero
mayor.
Quines son los miembros del nuevo anillo.
Concluida la ronda de informacin el mensaje coordinador se elimina y continan los
procesos.
Transacciones Atmicas
Las tcnicas de sincronizacin ya vistas son de bajo nivel [25, Tanenbaum]:
El programador debe enfrentarse directamente con los detalles de:
o La exclusin mutua.
o El manejo de las regiones crticas.
o La prevencin de bloqueos.
o La recuperacin de fallas.
Se precisan tcnicas de abstraccin de mayor nivel que:
Oculten estos aspectos tcnicos.
Permitan a los programadores concentrarse en los algoritmos y la forma en que los
procesos trabajan juntos en paralelo.
Tal abstraccin la llamaremos transaccin atmica, transaccin o accin atmica.
La principal propiedad de la transaccin atmica es el todo o nada:
O se hace todo lo que se tena que hacer como una unidad o no se hace nada.
Ejemplo:
o Un cliente llama al Banco mediante una PC con un mdem para:
Retirar dinero de una cuenta.
Depositar el dinero en otra cuenta.
o La operacin tiene dos etapas.
o Si la conexin telefnica falla luego de la primer etapa pero antes de la
segunda:
Habr un retiro pero no un depsito.
o La solucin consiste en agrupar las dos operaciones en una transaccin
atmica:
Las dos operaciones terminaran o no terminara ninguna.
Se debe regresar al estado inicial si la transaccin no puede concluir.
El Modelo de Transaccin
Supondremos que [25, Tanenbaum]:
El sistema consta de varios procesos independientes que pueden fallar aleatoriamente.

El software subyacente maneja transparentemente los errores de comunicacin.

Almacenamiento Estable
Se puede implantar con una pareja de discos comunes.
Cada bloque de la unidad 2 es una copia exacta (espejo) del bloque correspondiente en la unidad
1.
Cuando se actualiza un bloque:
Primero se actualiza y verifica el bloque de la unidad 1.
Luego se actualiza y verifica el bloque de la unidad 2.
Si el sistema falla luego de actualizar la unidad 1 y antes de actualizar la unidad 2:
Luego de la recuperacin se pueden comparar ambos discos bloque por bloque:
o Se puede actualizar la unidad 2 en funcin de la 1.
Si se detecta el deterioro espontneo de un bloque, se lo regenera partiendo del bloque
correspondiente en la otra unidad.
Un esquema de este tipo es adecuado para las aplicaciones que requieren de un alto grado de
tolerancia de fallos, por ej. las transacciones atmicas.
Primitivas de Transaccin
Deben ser proporcionadas por el sistema operativo o por el sistema de tiempo de ejecucin del
lenguaje.
Ejemplos:
Begin_transaction: los comandos siguientes forman una transaccin.
End_transaction: termina la transaccin y se intenta un compromiso.
Abort_transaction: se elimina la transaccin; se recuperan los valores anteriores.
Read: se leen datos de un archivo (o algn otro objeto).
Write: se escriben datos en un archivo (o algn otro objeto).
Las operaciones entre Begin y End forman el cuerpo de la transaccin y deben ejecutarse todas
o ninguna de ellas:
Pueden ser llamadas al sistema, procedimiento de biblioteca o enunciados en un
lenguaje.
Propiedades de las Transacciones
Las propiedades fundamentales son:
Serializacin:
o Las transacciones concurrentes no interfieren entre s.
Atomicidad:
o Para el mundo exterior, la transaccin ocurre de manera indivisible.
Permanencia:
o Una vez comprometida una transaccin, los cambios son permanentes.
La serializacin garantiza que si dos o ms transacciones se ejecutan al mismo tiempo:
El resultado final aparece como si todas l as transacciones se ejecutasen de manera
secuencial en cierto orden:
o Para cada una de ellas y para los dems procesos.
La atomicidad garantiza que cada transaccin no ocurre o bien se realiza en su totalidad:
Se presenta como una accin indivisible e instantnea.
La permanencia se refiere a que una vez comprometida una transaccin:
Sigue adelante y los resultados son permanentes.
Transacciones Anidadas
Se presentan cuando las transacciones pueden contener subtransacciones (procesos hijos) que:
Se ejecuten en paralelo entre s en procesadores distintos.
Pueden originar nuevas subtransacciones.
Implantacin del Modelo de Transaccin

Existen varios mtodos de implantacin [25, Tanenbaum].

Espacio de Trabajo Particular
Consiste en que cuando un proceso inicia una transaccin se le otorga un espacio de trabajo
particular:
Contiene todos los archivos (y otros objetos) a los cuales tiene acceso.
Las lecturas y escrituras irn a este espacio hasta que la transaccin se complete o
aborte:
o El espacio real es el sistema de archivos normal.
Significa alto consumo de recursos por las copias de los objetos al espacio de trabajo
particular.
Cuando un proceso inicia una transaccin, basta crear un espacio de trabajo particular para l
que sea vaco excepto por un apuntador de regreso al espacio de trabajo de su proceso padre.
Para una transaccin del nivel superior el espacio de trabajo del padre es el sistema de archivos
real.
Cuando el proceso abre un archivo para lectura, se siguen los apuntadores de regreso hasta
localizar el archivo en el espacio de trabajo del padre (o algn antecesor).
Cuando se abre un archivo para escritura:
Se lo localiza de manera similar que para lectura.
Se copia en primer lugar al espacio de trabajo particular:
o Una optimizacin consiste en copiar solo el ndice del archivo en el espacio de
trabajo particular:
El ndice es el bloque de datos asociado a cada archivo e indica la
localizacin de sus bloques en el disco.
Es el nodo-i correspondiente.
La lectura por medio del ndice particular (del espacio de trabajo particular) no es problemtica,
pues las direcciones en disco a las que referencia son las originales.
La modificacin de un bloque de un archivo requiere:
Hacer una copia del bloque.
Insertar en el ndice la direccin de la copia.
La modificacin sobre la copia no afecta al bloque original.
Un tratamiento similar se da al agregado de bloques; los nuevos bloques se llaman bloques
sombra (shadow blocks).
El proceso que ejecuta la transaccin ve el archivo modificado pero los dems procesos ven el
archivo original.
Si la transaccin aborta (termina anormalmente):
El espacio de trabajo particular se elimina.
Los bloques particulares a los que apunta se colocan nuevamente en la lista de bloques
libres.
Si la transaccin se compromete (termina normalmente):
Los ndices particulares se desplazan al espacio de trabajo del padre de manera atmica.
Los bloques que no son alcanzables se colocan en la lista de bloques libres.
Bitcora de Escritura Anticipada
Este mtodo tambin se denomina lista de intenciones.
Los archivos realmente se modifican pero antes de cambiar cualquier bloque:
Se graba un registro en la bitcora (log) de escritura anticipada en un espacio de
almacenamiento estable:
o Se indica la transaccin que produce el cambio, el archivo y bloque
modificados y los valores anterior y nuevo.
Si la transaccin tiene xito y se hace un compromiso:
Se escribe un registro del compromiso en la bitcora.
Las estructuras de datos no tienen que modificarse, puesto que ya han sido actualizadas.
Si la transaccin aborta:
Se puede utilizar la bitcora para respaldo del estado original:

A partir del final y hacia atrs:

Se lee cada registro de la bitcora.
Se deshace cada cambio descripto en l.
Esta accin se denomina retroalimentacin.
Por medio de la bitcora se puede:
Ir hacia adelante (realizar la transaccin).
Ir hacia atrs (deshacer la transaccin).
o

Protocolo de Compromiso de Dos Fases (Two - Phase Commit)

Uno de los procesos que intervienen funciona como el coordinador.
El coordinador escribe una entrada en la bitcora para indicar que inicia el protocolo.
El coordinador enva a cada uno de los procesos relacionados (subordinados) un mensaje para
que estn preparados para el compromiso.
Cuando un subordinado recibe el mensaje:
Verifica si est listo para comprometerse.
Escribe una entrada en la bitcora.
Enva de regreso su decisin.
Cuando el coordinador ha recibido todas las respuestas sabe si debe establecer el compromiso o
abortar:
Si todos los procesos estn listos para comprometerse cierra la transaccin.
Si alguno de los procesos no se compromete (o no responde) la transaccin se aborta.
El coordinador:
o Escribe una entrada en la bitcora.
o Enva un mensaje a cada subordinado para informarle de la decisin.
Control de Concurrencia en el Modelo de Transaccin
Los algoritmos de control de concurrencia son necesarios cuando se ejecutan varias
transacciones de manera simultnea [25, Tanenbaum]:
En distintos procesos.
En distintos procesadores.
Los principales algoritmos son:
El de la cerradura.
El del control optimista de la concurrencia.
El de las marcas de tiempo.
Cerradura (locking)
Cuando un proceso debe leer o escribir en un archivo (u otro objeto) como parte de una
transaccin, primero cierra el archivo.
La cerradura se puede hacer mediante:
Un nico manejador centralizado de cerraduras.
Un manejador local de cerraduras en cada mquina.
El manejador de cerraduras:
Mantiene una lista de los archivos cerrados.
Rechaza todos los intentos por cerrar archivos ya cerrados por otros procesos.
El sistema de transacciones generalmente adquiere y libera las cerraduras sin accin por parte
del programador.
Una mejora consiste en distinguir las cerraduras para lectura de las cerraduras para escritura.
Una cerradura para lectura no impide otras cerraduras para lectura:
Las cerraduras para lectura se comparten.
Una cerradura para escritura s impide otras cerraduras (de lectura o de escritura):
Las cerraduras para escritura no se comparten, es decir que deben ser exclusivas.
El elemento por cerrar puede ser un archivo, un registro, un campo, etc. y lo relativo al tamao
del elemento por cerrar se llama la granularidad de la cerradura.

Mientras ms fina sea la granularidad:

Puede ser ms precisa la cerradura.
Se puede lograr un mayor paralelismo en el acceso al recurso.
Se requiere un mayor nmero de cerraduras.
Generalmente se utiliza la cerradura de dos fases:
El proceso adquiere todas las cerraduras necesarias durante la fase de crecimiento.
El proceso las libera en la fase de reduccin.
Se deben evitar situaciones de aborto en cascada:
Se graba en un archivo y luego se libera su cerradura.
Otra transaccin lo cierra, realiza su trabajo y luego establece un compromiso.
La transaccin original aborta.
La segunda transaccin (ya comprometida) debe deshacerse, ya que sus resultados se
basan en un archivo que no debera haber visto cuando lo hizo.
Las cerraduras comunes y de dos fases pueden provocar bloqueos cuando dos procesos
intentan adquirir la misma pareja de cerraduras pero en orden opuesto, por lo tanto se deben
utilizar tcnicas de prevencin y de deteccin de bloqueos para superar el problema.
Control Optimista de la Concurrencia
La idea es muy sencilla:
Se sigue adelante y se hace todo lo que se deba hacer, sin prestar atencin a lo que
hacen los dems.
Se acta a posteriori si se presenta algn problema.
Se mantiene un registro de los archivos ledos o grabados.
En el momento del compromiso:
Se verifican todas las dems transacciones para ver si alguno de los archivos ha sido
modificado desde el inicio de la transaccin:
o Si esto ocurre la transaccin aborta.
o Si esto no ocurre se realiza el compromiso.
Las principales ventajas son:
Ausencia de bloqueos.
Paralelismo mximo ya que no se esperan cerraduras.
La principal desventaja es:
Re-ejecucin de la transaccin en caso de falla.
La probabilidad de fallo puede crecer si la carga de trabajo es muy alta.
Marcas de Tiempo
Se asocia a cada transaccin una marca de tiempo al iniciar (begin_transaction).
Se garantiza que las marcas son nicas mediante el algoritmo de Lamport.
Cada archivo del sistema tiene asociadas una marca de tiempo para la lectura y otra para la
escritura, que indican la ltima transaccin comprometida que realiz la lectura o escritura.
Cuando un proceso intente acceder a un archivo, lo lograr si las marcas de tiempo de lectura y
escritura son menores (ms antiguas) que la marca de la transaccin activa.
Si la marca de tiempo de la transaccin activa es menor que la del archivo que intenta acceder:
Una transaccin iniciada posteriormente ha accedido al archivo y ha efectuado un
compromiso.
La transaccin activa se ha realizado tarde y se aborta.
En el mtodo de las marcas no preocupa que las transacciones concurrentes utilicen los mismos
archivos, pero s importa que la transaccin con el nmero menor est en primer lugar.
Las marcas de tiempo tienen propiedades distintas a las de los bloqueos:
Una transaccin aborta cuando encuentra una marca mayor (posterior).
En iguales circunstancias y en un esquema de cerraduras podra esperar o continuar
inmediatamente.
Las marcas de tiempo son libres de bloqueos, lo que es una gran ventaja.

Resumen
Los diferentes esquemas ofrecen distintas ventajas pero el problema principal es la gran
complejidad de su implantacin.
Bloqueos en Sistemas Distribuidos
Son peores que los bloqueos en sistemas monoprocesador [25, Tanenbaum]:
Son ms difciles de evitar, prevenir, detectar y solucionar.
Toda la informacin relevante est dispersa en muchas mquinas.
Son especialmente crticos en sistemas de bases de datos distribuidos.
Las estrategias usuales para el manejo de los bloqueos son:
Algoritmo del avestruz:
o Ignorar el problema.
Deteccin:
o Permitir que ocurran los bloqueos, detectarlos e intentar recuperarse de ellos.
Prevencin:
o Hacer que los bloqueos sean imposibles desde el punto de vista estructural.
Evitarlos:
o Evitar los bloqueos mediante la asignacin cuidadosa de los recursos.
El algoritmo del avestruz merece las mismas consideraciones que en el caso de monoprocesador.
En los sistemas distribuidos resulta muy difcil implantar algoritmos para evitar los bloqueos:
Se requiere saber de antemano la proporcin de cada recurso que necesitar cada
proceso.
Es muy difcil disponer de esta informacin en forma prctica.
Las tcnicas ms aplicables para el anlisis de los bloqueos en sistemas distribuidos son:
Deteccin.
Prevencin.
Deteccin Distribuida de Bloqueos
Cuando se detecta un bloqueo en un S. O. convencional se resuelve eliminando uno o ms
procesos [25, Tanenbaum].
Cuando se detecta un bloqueo en un sistema basado en transacciones atmicas se resuelve
abortando una o ms transacciones:
El sistema restaura el estado que tena antes de iniciar la transaccin.
La transaccin puede volver a comenzar.
Las consecuencias de la eliminacin de un proceso son mucho menos severas si se utilizan las
transacciones que en caso de que no se utilicen.
Deteccin Centralizada de Bloqueos
Cada mquina mantiene la grfica de recursos de sus propios procesos y recursos.
Un coordinador central mantiene la grfica de recursos de todo el sistema, que es la unin de
todas las grficas individuales.
Cuando el coordinador detecta un ciclo elimina uno de los procesos para romper el bloqueo.
La informacin de control se debe transmitir explcitamente, existiendo las siguientes variantes:
Cada mquina informa cada actualizacin al coordinador.
Cada mquina informa peridicamente las modificaciones desde la ltima actualizacin.
El coordinador requiere la informacin cuando la necesita.
La informacin de control incompleta o retrasada puede llevar a falsos bloqueos:
El coordinador interpreta errneamente que existe un bloqueo y elimina un proceso.
Una posible solucin es utilizar el algoritmo de Lamport para disponer de un tiempo
global.
Deteccin Distribuida de Bloqueos
Un algoritmo tpico es el de Chandy-Misra-Haas.

Los procesos pueden solicitar varios recursos (por ejemplo cerraduras) al mismo tiempo, en vez
de uno cada vez.
Se permiten las solicitudes simultneas de varios procesos:
Un proceso puede esperar a uno o ms recursos simultneamente.
Los recursos que espera un proceso pueden ser locales o remotos (de otra mquina).
Si el proceso 0 se bloquea debido al proceso 1:
Se genera un mensaje de exploracin que se enva al proceso (o procesos) que detienen
los recursos necesarios.
El mensaje consta de tres nmeros:
o El proceso recin bloqueado, el proceso que enva el mensaje y el proceso al
cual se enva.
Al llegar el mensaje el receptor verifica si l mismo espera a algunos procesos, en cuyo
caso:
o El mensaje se actualiza:
Se conserva el primer campo.
Se reemplaza el segundo por su propio nmero de proceso y el tercero
por el nmero del proceso al cual espera.
o El mensaje se enva al proceso debido al cual se bloquea:
Si se bloquea debido a varios procesos les enva mensajes (diferentes) a
todos ellos.
Si un mensaje recorre todo el camino y regresa a su emisor original (el proceso
enlistado en el primer campo), entonces:
o Existe un ciclo y el sistema est bloqueado.
Una forma de romper el bloqueo es que el proceso que inici la exploracin se comprometa a
suicidarse y, si varios procesos se bloquean al mismo tiempo e inician exploraciones, todos
ellos se suicidarn.
Una variante es eliminar solo al proceso del ciclo que tiene el nmero ms alto.
Prevencin Distribuida de Bloqueos
La prevencin consiste en el diseo cuidadoso del sistema para que los bloqueos sean
imposibles estructuralmente [25, Tanenbaum].
Entre las distintas tcnicas se incluye:
Permitir a los procesos que solo conserven un recurso a la vez.
Exigir a los procesos que soliciten todos sus recursos desde un principio.
Hacer que todos los procesos liberen todos sus recursos cuando soliciten uno nuevo.
En un sistema distribuido con tiempo global y transacciones atmicas:
Se puede asociar a cada transaccin una marca de tiempo global al momento de su
inicio.
No pueden haber parejas de transacciones con igual marca de tiempo asociada.
La idea es que cuando un proceso est a punto de bloquearse en espera de un recurso que est
utilizando otro proceso:
Se verifica cul de ellos tiene la marca de tiempo mayor (es ms joven).
Se puede permitir la espera solo si el proceso en estado de espera tiene una marca
inferior (ms viejo) que el otro.
Al seguir cualquier cadena de procesos en espera:
Las marcas aparecen en forma creciente.
Los ciclos son imposibles.
Otra posibilidad es permitir la espera de procesos solo si el proceso que espera tiene una marca
mayor (es ms joven) que el otro proceso; las marcas aparecen en la cadena en forma
descendente.
Es ms sabio dar prioridad a los procesos ms viejos:
Se ha invertido tiempo de proceso en ellos.
Probablemente conservan ms recursos.