Transacciones distribuidas

Sistemas de Operación II
Transacciones distribuidas
Prof. Carlos Figueira
Basado en material de
Yudith Cardinale (USB)
Andrew Tanembaum y Marteen van Steen
Contenido
●
Transacciones: Introducción y definiciones
●
Algoritmos para completar transacciones
●
Control de concurrencia
●
Tratamientos de interbloqueos
Carlos Figueira/USB
2
Transacciones:
Introducción
Definiciones
Carlos Figueira/USB
3
Transacción
●
●
●
●
Unidad de cálculo consistente, confiable y
atómica
Aplica a datos recuperables
Puede estar formada por operaciones simples
o compuestas, pero deben ejecutarse de
manera atómica
Secuencia:
●
abre transacción, operaciones, cierra transacción
Carlos Figueira/USB
4
Transacción
A
B
C
Operaciones conflictivas
Retardo
Ejecución
Operaciones compuestas
Serialización
de
operaciones
conflictivas
Carlos Figueira/USB
5
Requerimientos: Todo o nada
●
●
Si una transacción termina exitosamente, los
efectos de todas sus operaciones son
registrados en espacio de datos
Si falla, no altera espacio de datos, incluso ante
fallas del servidor
Carlos Figueira/USB
6
Propiedades ACID
●
●
●
●
Atomicidad: la operación se realiza completa o
nada
Consistencia: sólo se empieza aquello que se
puede acabar.
Aislamiento (isolation): una operación no puede
afectar a otras.
Durabilidad: una vez realizada, la operación
persistirá, no se podrá deshacer aunque falle el
sistema.
Carlos Figueira/USB
7
Atomicidad
●
●
En la recuperación de caídas el sistema debe
decidir qué hacer:
●
Terminar de ejecutar el resto de las acciones
●
Deshacer acciones que ya había realizado
Se usan técnicas de almacenamiento estable
●
●
Se garantiza que permanecen incluso ante caídas
del servidor
Ejemplos: RAID, réplicas
Carlos Figueira/USB
8
Consistencia
●
●
●
Una transacción toma el sistema en un estado
consistente, y lo deja en un estado consistente
Sólo se ejecutan operaciones que no van a
romper reglas integridad de la BD.
¿Qué pasa con dos accesos simultáneos
conflictivos?
●
Ej: transferencias bancarias de cuenta A a cuentas
diferentes (B y C) cuyo monto total excede fondos
en A
Carlos Figueira/USB
9
Aislamiento
●
●
●
Dos transacciones sobre la misma información
son independientes y no generan error
Los efectos intermedios de una transacción son
invisibles a las otras
Ejecución concurrente obtiene mismo efecto
que ejecución secuencial
Carlos Figueira/USB
10
Primitivas sobre transacciones
●
●
inicio_transaccion → tid : inicia una transacción y devuelve un
identificador de la transacción
fin_transaccion → {Completar, Abortar}
●
●
●
●
Completar: la transacción termina exitosamente y sus efectos van a
almacenamiento permanente (commit: completar, consumar)
Abortar: no se reflejan los cambios. Pueden ser causados por la propia
naturaleza de la transacción, por conflictos con otras transacciones o
por fallas.
abortar_transaccion(tid): interrupción intencional.
leer y escribir: típicamente una transacción se compone de una
serie de lecturas y escrituras, y algunos cálculos.
Carlos Figueira/USB
11
Transacciones anidadas
●
●
●
●
Ej: envío de correo electrónico a varios dest.
Transacción realiza completar y una + externa
abortar, se pierden propiedades de atomicidad
y aislamiento por cumplir la durabilidad
Generalmente, la durabilidad sólo se considera
para la transacción más externa
En algunos sistemas, la transacción superior
puede decidir hacer completar aun cuando
alguna sub-transacción aborta
Carlos Figueira/USB
12
Implementación de transacciones
●
Espacio de trabajo privado
●
●
●
Se copian los datos en un espacio propio de cada
transacción
Al finalizar (exitosamente) la transacción, se
actualizan datos en almacenamiento permanente
Lista de intención (write-ahead log)
●
Actualizaciones realizadas directamente en la BD
●
Se lleva registro de cambios realizados
Carlos Figueira/USB
13
Transacciones Distribuidas
●
●
●
●
Involucran múltiples
servidores
X
Datos distribuidos entre
varios servidores
Y
Transacción de un cliente
puede incluir múltiples
servidores
Transacciones
distribuidas pueden ser
simples o anidadas
Carlos Figueira/USB
cliente
Z
Cliente:
inicio_transaccion
call X.x
call Y.y
call Z.z
end_transaccion
14
Transacciones Distribuidas
M
X
T11
T1
T
T12
Cliente
Y
N
T21
T2
P
T22
Transacción distribuida anidada
Carlos Figueira/USB
15
Transacciones Distribuidas
●
●
●
Cuando termina transacción distribuida, la
atomicidad exige que todos los servidores
acuerden lo mismo (completar o abortar) o
todos aborten (basta que uno aborte).
Existen protocolos para llegar a compromisos
(Two-phase-Commit y Three-Phase-Commit)
Transacciones distribuidas deben ser
globalmente serializables. Existen protocolos
de control de concurrencia distribuida
Carlos Figueira/USB
16
Procesamiento de transacciones
distribuidas
C
C
C
C
TPS
C
TPS
Transaction
Manager
scheduler
C
Transaction
Manager
comunicación
scheduler
Data Manager
Data Manager
Recovery
Manager
Recovery
Manager
Cache
Manager
Cache
Manager
Carlos Figueira/USB
TPS: Sistema de
Procesamiento
de Transacciones
(Transaction
Processing System)
17
Procesamiento de transacciones
distribuidas
●
●
●
●
Cliente inicia transacción sobre un TPS. El
Manejador de Transacciones identifica y localiza
objetos invocados.
Invocaciones a objetos locales son pasados al
Planificador local; invocaciones a objetos remotos
son pasados a su TPS
Cliente inicia transacción en un nodo => nodo
coordinador
Objeto reside en nodo único (no hay replicación de
objeto). La invocación del objeto se hace en ese
nodo
Carlos Figueira/USB
18
Procesamiento de transacciones
distribuidas
●
●
●
Deben existir mecanismos para localizar un
objeto, dado su identificador (único)
Las instancias del TPS deben cooperar
Cuando un cliente comienza una transacción,
envía un inicio_transaccion a un servidor TPS.
●
●
El servidor TPS se convierte en coordinador
El resto de TPS que intervengan en la transacción
se convierten en trabajadores
Carlos Figueira/USB
19
Coordinador de transacción
distribuida
●
●
Se requieren otras primitivas
AgregaServidor (tid, id_servidor del
coordinador)
●
●
Mensaje enviado por coordinador a otro servidor
informando que participará en transacción tid.
NuevoServidor (tid, id_servidor del trabajador)
●
●
Respuesta ante un AgregaServidor de un trabajador
al coordinador.
El coordinador lo registra en su lista de trabajadores
Carlos Figueira/USB
20
Algoritmos para completar (commit)
transacciones
Carlos Figueira/USB
21
Algoritmos de completar (commit)
●
Cuando el coordinador recibe un requerimiento
completar de una transacción, debe asegurar:
●
●
Atomicidad: todos los nodos completan cambios o
ninguno lo hace; cualquier otra transacción percibe
los cambios en todos los nodos o en ninguno
Aislamiento: los efectos de la transacción no son
visibles hasta que todos los nodos hayan tomado la
decisión (irrevocable) de completar o abortar
Carlos Figueira/USB
22
Protocolo Completar en Dos Fases
(C2F, Two-phase-commit)
●
●
●
●
Durante progreso de transacción, no hay
comunicación entre coordinador y trabajadores
(excepto AgregarServidor y NuevoServidor)
Requerimiento completar o abortar del cliente,
llega al coordinador
Si es abortar, el coordinador lo informa
inmediatamente a todos los trabajadores
Si es completar, se aplica protocolo C2F
Carlos Figueira/USB
23
Protocolo C2F
Máquina de estados finitos del
coordinador (a) y de los trabajadores (b)
Carlos Figueira/USB
24
Protocolo C2F: acciones del
coordinador (1/2)
Carlos Figueira/USB
25
Protocolo C2F: acciones del
coordinador (2/2)
Carlos Figueira/USB
26
Protocolo
C2F:
acciones del
trabajador
Carlos Figueira/USB
27
C2F: esperas acotadas para
tolerancia a fallas
●
Se usan temporizadores para acotar espera en
estados Espera, Completar y Abortar del
coordinador.
●
Expira (timeout) en el estado de Espera:
–
–
●
aborta, escribe en bitácora,
envía mensaje abortar_global a todos
Expira tiempo en estados Completar o Abortar:
–
–
envía mensaje completar_global o abortar_global, resp.,
a trabajadores que no han respondido
espera por confirmación
Carlos Figueira/USB
28
C2F: espera acotada en trabajador
●
●
●
Estados Inicial o Listo
Expira en estado Inicial: decide abortar. Si el
mensaje solicita_voto (vote_request) llega
después, trabajador envía un voto_abortar o lo
ignora.
Expira en estado Listo: se queda bloqueado
esperando
Carlos Figueira/USB
29
Paradigmas de comunicación para
el C2F
C2F centralizado
voto
Solicita
voto
C2F lineal
C/A_global
voto
C
1
2
voto
3
C/A_gl CarlosC/A_gl
Figueira/USB
C/A
voto
4
C/A_gl
Fase 1
N
C/A_gl
Fase 2
30
Paradigmas de comunicación: C2F
distribuido
●
●
●
El C/A_g (Commit/Abort_global) es decisión de
cada participante de acuerdo a los votos recibidos
Se elimina fase 2
Lineal y distribuidos requieren conocer ids de todos
los participantes
Solicita voto
Carlos Figueira/USB
C/A_ voto
C/A_g
31
Análisis de C2F
●
El protocolo C2F puede ocasionar retrasos a
los participantes en estado incierto (preparado
para completar)
●
●
●
Cuando coordinador falla y no puede responder a
peticiones de dameDecisión.
Lo mismo ocurre si es cooperativo y la pregunta va
a participantes en estado incierto
Solución: Protocolo Completar en Tres fases
(C3F)
Carlos Figueira/USB
32
Completar en Tres Fases (C3F
Three-Phase-Commit)
●
Los estados del coordinador y de cada
participante satisfacen las siguientes dos
condiciones:
1. No hay estado del cual sea posible hacer una
transición directamente al estado completar o
abortar
2. No hay estado en el cual no sea posible tomar una
decisión final, y del cual pueda ser realizada una
transición al estado completar
Carlos Figueira/USB
33
Completar en Tres Fases (C3F
Three-Phase-Commit)
Máquina de estados finitos del coordinador (a) y de
los trabajadores (b) en C3F
Carlos Figueira/USB
34
Control de Concurrencia
Carlos Figueira/USB
35
Control de Concurrencia
●
●
●
Resolver operaciones conflictivas: cuando sus
efectos combinados dependen del orden en el cual
fueron ejecutadas
Para dos transacciones, son conflictivas cualquier
combinación que tenga escritura/lectura o
escritura/escritura
Si hay operaciones conflictivas es necesario
serializarlas para asegurar la consistencia de los
datos después de su ejecución
Carlos Figueira/USB
36
Control de concurrencia
●
Ejecución
Las Operaciones conflictivas derivan en 2 problemas:
T
balance=200$
Actualizaciones perdidas
●
Transacción T
Transacción U
balance=b.getBalance()
balance=b.getBalance()
balance=220$
U
balance=200$
balance=220$
b.setBalance(balance*1.1) b.setBalance(balance*1.1) Balance debió ser 200+20+22=242
Ejecución; a=200$ , b=200$
V
W
Transacción V
Transacción W
a=200$-100$
lee a=100$
a.retirar(100)
unasucursal.totalSucursal(a,b)
lee b=200$
b.deposita(100))
b=200$+100$
Total=300$
Según la ejecución el total es 300$.
Solución: Equivalencia Secuencial =>
●
Recuperaciones inconsistentes
●
Control de concurrencia
Debió ser 400$
Carlos Figueira/USB
37
Transacciones abortadas
●
Cuando una transacción aborta, puede generar
dos problemas:
●
Lecturas sucias
●
Escrituras prematuras
Carlos Figueira/USB
38
Lecturas sucias
Transacción T
Transacción U
a.getBalance() (100$)
a.depositar(10) (110$)
a.getBalance() (110$)
a.deposita(20) (130$)
completar
aborta
U tomó el valor 110$ que ahora no es válido
Carlos Figueira/USB
39
Recuperación de lecturas sucias
●
●
Estrategia para recuperación: retrasar acción
completar de U hasta que T finalice
Esto puede generar Abortos en Cascada
●
si T aborta, U debe abortar también
Carlos Figueira/USB
40
Escrituras prematuras
●
Se pierden actualizaciones.
●
Ej: dos transacciones A y B sobre una cuenta.
Saldo inicial 100Bs. A pone balance en 105, B en
110, son secuencialmente equivalentes. B ejecuta
después de A.
–
–
●
Si B aborta y después A, coloca 100 en balance
(correcto).
Si A aborta y después B, coloca 105 en balance
(incorrecto)
Estrategia para recuperación
●
Retrasar escrituras hasta el momento de completar
Carlos Figueira/USB
41
Ejecución estricta
●
●
Se retrasa lectura/escritura de un objeto hasta
que todas las transacciones que escribieron el
objeto han sido completadas o abortadas
La ejecución estricta de las transacciones evita
tanto lecturas sucias como escrituras
prematuras (aislamiento)
Carlos Figueira/USB
42
Algoritmos de control de
concurrencia
●
Tres estrategias
●
Usando bloqueo (locking)
●
Optimista
●
Por marcas de tiempo (timestamp)
Carlos Figueira/USB
43
Control de concurrencia: Bloqueo
●
Cuando se requiere leer/escribir objeto en una
transacción, se bloquea objeto hasta que
culmine transacción (completar)
●
●
●
Si otra transacción desea acceder el objeto, debe
esperar a que se desbloquee
Los bloqueos (locks) son adquiridos/liberados
por administrador de transacciones (transparente
al programador)
Administrador puede ser centralizado o local a
cada máquina
Carlos Figueira/USB
44
Granularidad del Bloqueo
●
Se refiere al tamaño del objeto que se está
bloqueando:
●
●
●
A mayor granularidad, más pequeño (grano más
fino) es objeto
Bloqueo puede ser a nivel de dato (mayor
granularidad), página, archivo, BD (menor)
Paralelismo/concurrencia, y complejidad de
sistema, son directamente proporcionales a
granularidad
Carlos Figueira/USB
45
Bloqueo: mejoras
●
●
Bloqueos diferenciados para escritura y para
lectura permiten más concurrencia
Si varias transacciones requieren objeto para
lectura y luego escritura, se otorga bloqueo de
(sólo) lectura a todas, hasta que alguna
requiera escribir;
●
ésta solicita bloqueo de escritura (promoción de
bloqueo lectura a escritura), para lo cual debe
esperar que todas las demás liberen bloqueo de
lectura
Carlos Figueira/USB
46
Compatibilidad de bloqueos
●
●
Determina cómo manejar los bloqueos solicitados
sobre un objeto, sobre el cual existe un bloqueo
activo
Depende de los tipos de bloqueo solicitados y del
bloqueo activo sobre el objeto
Bloqueo activo Bloqueo solicitado
Ninguno
Lectura OK – Escritura OK
Lectura
Lectura OK – Escritura ESPERA
Escritura
Lectura ESPERA – Escritura ESPERA
Carlos Figueira/USB
47
Problemas resueltos usando
bloqueo
●
Recuperaciones inconsistentes
●
●
El bloqueo permite ordenar los accesos conflictivos
(en el ejemplo, evitando que W lea balance en b
antes que V lo actualice)
Pérdida de actualizaciones
●
si dos transacciones desean leer el mismo dato y
luego modificarlo, la solicitud de bloqueo de
escritura (promoción lectura a escritura) de ambas
forzará su ordenamiento
Carlos Figueira/USB
48
Equivalencia secuencial
Transacción T
Transacción U
bal=b.obtenBalance() (200)
b.ponBalance(bal*1.1) (220)
bal=b.obtentBalance() (220)
b.ponBalance(bal*1.1) (242)
a.extrae(bal/10) (80)
c.extrae(bal/10) (278)
●
Transacciones deben planificarse para que efectos sean
secuencialmente equivalentes, regulando solicitud/liberación
de recursos
Carlos Figueira/USB
49
Bloqueo en dos fases
●
Equivalencia Secuencial requiere que los accesos
conflictivos a objetos se hagan en el mismo orden
●
●
●
Solución: impedir que se pidan objetos después de liberar
Fase de Obtención: Transacción trata de obtener
bloqueos necesitados. Si no es posible obtenerlos
todos, entonces espera
Fase de Liberación: Comienza cuando transacción
libera algún bloqueo. A partir de ese momento, no podrá
solicitar ningún otro; si lo hace, será abortada
Carlos Figueira/USB
50
Ejemplo bloqueo 2 fases
Transacción T
Transacción U
abreTransaccion
bal=b.obtenBalance() (bloquea B)
b.ponBalance(bal*1.1)
abreTransaccion
a.extrae(bal/10) (bloquea A)
bal=b.obtentBalance() (espera)
CierraTransaccion (desbloquea A,B)
Bloquea B
b.ponBalance(bal*1.1)
c.extrae(bal/10) (bloquea C)
cierraTransaccion (desbloq.B,C)
Carlos Figueira/USB
51
Desventaja de Bloqueo en dos
fases
●
Si una transacción en fase de liberación había
desbloqueado algunos objetos que entonces
son accedidos por otras antes que la primera
haga completar, y ésta decide abortar,
entonces TODAS deben abortar
Carlos Figueira/USB
52
Bloqueo en dos fases estricto
●
●
●
La fase de liberación se realiza sólo cuando la
transacción hace completar
Ventaja: se evitan abortos en cascada
(conjunto de transacciones relacionadas con
los objetos bloqueados que deben abortar)
Desventajas:
●
Degrada nivel de paralelismo
●
Permanece la posibilidad de interbloqueo
●
Representa alto costo de mantenimiento
Carlos Figueira/USB
53
Bloqueo en dos fases
Bloqueo en dos fases
Bloqueo en dos fases estricto
Fase de crecimiento Fase de liberación
Fase de crecimiento Fase de liberación
Número de bloqueos
Número de bloqueos
Tiempo
Se liberan
todos los
bloqueos
Tiempo
Carlos Figueira/USB
54
Inconvenientes del uso de bloqueo
●
Sobrecarga. Incluso en lectura, cuando no es
necesario
●
Posibilidad de interbloqueo
●
Pérdida de concurrencia
●
Para impedir abortos en cascada, los bloqueos no
pueden ser liberados hasta el final de la
transacción
Carlos Figueira/USB
55
Control de concurrencia:
Algoritmo Optimista
●
●
Se basa en la premisa de que los conflictos son
poco frecuentes, por lo que es mejor no hacer
nada sino actuar cuando ocurran
Modificaciones se hacen sobre espacios
privados
●
●
●
Se lleva registro de los datos que han sido
modificados/accedidos
Al momento de completar, se verifica que los
espacios privados sean válidos; sino, aborta
Asigna número de secuencia a transacciones
Carlos Figueira/USB
56
Fases de Algoritmo Optimista
●
Tres fases: trabajo, validación y escritura
●
Trabajo
●
●
●
Toda lectura se ejecuta inmediatamente sobre
última versión completada del dato
Las escrituras crean versiones tentativas
Se mantiene conjunto de lectura (datos leídos) y
conjunto de escritura (versiones tentativas de
datos)
Carlos Figueira/USB
57
Fases de Algoritmo Optimista
●
Validación
●
●
Ante solicitud de completar, se valida si transacción
realizó operaciones conflictivas con otras
transacciones
Escritura
●
Si transacción es validada, todos los cambios sobre
espacios privados se respaldan en espacio
definitivo
Carlos Figueira/USB
58
Fase de Validación
●
●
Ante cierraTransaccion de Tv, pasa a fase de
validación; se asigna a cada transacción un número
de secuencia
Validación se basa en tres reglas (ver abajo, i<v)
Ti
Tv
Lectura
Escritura 1. Ti no debe leer datos escritos por Tv
Escritura Lectura
Regla
2. Tv no debe leer datos escritos por Ti
Escritura Escritura 3. Ti no debe escribir datos escritos por
Tv y viceversa
Carlos Figueira/USB
59
Validación hacia atrás
●
Se cumple regla 1:
●
●
Se cumple regla 3:
●
●
Puesto que Tv no escribe nada antes de llegar a
Validación
Si realizamos fases Validación y Escritura dentro de
una sección crítica
Sólo debemos validar regla 2 para cada Ti
Carlos Figueira/USB
60
Validación hacia atrás: regla 2
valido = true;
for (Ti=nTinicio+1;Ti<=nTfinal,Ti++) {
if (“conjunto_lectura” de Tv intersecta
“conjunto_escritura” Ti)
valido=false;
}
nTinicio: número de transacción mayor asignado a transacción
completada cuando Tv entra fase Trabajo
nTfinal: número de transacción mayor asignado al momento
que Tv entra a su fase de Validación
Carlos Figueira/USB
61
Validación hacia atrás
●
●
Sólo es necesario validar conjuntos de lecturas.
Las transacciones que sólo hacen escritura no se
validan
Si Tv no es válida, se aborta
T1
Transacciones
anteriores completadas
T2
T3
Transacción en validación
Tv
activa1
activa2
Validación
Trabajo
Escritura
Sólo se validan T2 y T3 T1 terminó
antes que Tv comenzara
Carlos Figueira/USB
62
Validación hacia adelante
●
●
Se satisface regla 2 porque transacciones activas
no escriben hasta que Tv no se ha completado
Sólo se valida regla 1 para cada Ti:
valido= true;
for (Tid=activa1;Tid<=activaN,Tid++) {
if (“con_escritura” de Tv intersecta “conj_lectura”
de Tid)
valido=false;
}
activaX: Transacciones que aún no entraron a fase de validación
Transacciones que sólo hacen lecturas no requieren ser validadas
Carlos Figueira/USB
63
Validación hacia adelante
●
Si Tv no es válida:
●
Aplazar validación (¿le irá mejor en el futuro?)
●
Abortar las activas y completa Tv
●
Abortar Tv (¿y si alguna de las futuras Tj es
abortada?)
Carlos Figueira/USB
64
Problemas con algoritmo optimista
●
Posibilidad de inanición
●
●
●
no se puede prevenir que una transacción pueda
abortar indefinidas veces
No funciona con carga alta
Produce sobrecarga porque hay que mantener
conjuntos de escrituras de transacciones que
ya terminaron (validación hacia atrás)
Carlos Figueira/USB
65
Algoritmos por Marcas de Tiempo
●
●
Las operaciones se validan al momento de ser
ejecutadas
Cuando comienza transacción, se le asigna fecha
(timestamp)
●
Usa versiones tentativas
●
Cada dato tiene asociado
–
●
●
Fecha de escritura (Tcompletar_esc), fecha de lectura
(Tlect) y conjunto de versiones tentativas con su fecha
Una escritura aceptada genera una versión tentativa
Una lectura se dirige a versión con mayor fecha y
que sea menor que fecha de transacción
Carlos Figueira/USB
66
Reglas de validación
Tc
Ti
Regla
Escritura
Lectura
1. Tc no debe escribir dato leído por Ti>Tc
Requiere Tc>=max(Tlect del dato)
Escritura
Escritura
2. Tc no debe escribir dato escrito por
Ti>Tc (requiere Tc>=max(Tcompletar_esc
del dato)
Lectura
Escritura
3. Tc no debe leer dato escrito por Ti>Tc
Requiere Tc>Tcompletar_esc
Carlos Figueira/USB
67
Algoritmos por Marcas de Tiempo
●
Para saber cuando escritura es válida, se
aplica el siguiente algoritmo (reglas de escritura
1 y 2)
Sea Tc una transacción que desea escribir
sobre el objeto D.
if ((Tc >= Max (Tlect en D)) &&
(Tc > Tcompletar_esc en D))
Proceder con escritura sobre una versión
tentativa nueva;
else // escritura muy tarde
Abortar Tc;
Carlos Figueira/USB
68
Alg Marcas Tiempo: reglas escritura
a) T3 escritura
antes
T2
después
T2
b) T3 escritura
T3
c) T3 escritura
antes
después
T1
T1
T1
T2
después
T1
T2
Versión
completada
T3
Versión
tentativa
d) T3 escritura
antes
T4
T3
antes
T4
después
Carlos Figueira/USB
T4
T3 Aborta
Tiempo
T4
69
Alg. Marcas de Tiempo: validación
de regla de lectura: Tc lee(D)
if (Tc > Tcompletar_esc en D) {
Dselec con Max (Tescritura <=Tc en D);
if (se completo (Dselec)) {
Procede lectura sobre Dselec;
} else {
Espera hasta que Ti que hizo versión
tentativa de Dselec haga completar o abortar;
volver a comenzar;
} else {
Abortar Tc;
}
Carlos Figueira/USB
70
Alg Marcas Tiempo: regla lectura
a) T3 lectura
T2
lectura se ejecuta
inmediatamente
Seleccionado
T2
T2
T4
lectura se ejecuta
inmediatamente
Seleccionado
c) T3 lectura
T1
b) T3 lectura
lectura espera
d) T3 lectura
T4
Versión
tentativa
T3 Aborta
Tiempo
Seleccionado
Carlos Figueira/USB
71
Interbloqueo
Carlos Figueira/USB
72
Condiciones para interbloqueo
1.Exclusión mutua.
Cada recurso está asignado a un único proceso o está disponible
2.Posesión y espera.
Procesos con recursos asignados pueden solicitar nuevos recursos.
3.No apropiación.
Recursos otorgados no pueden ser arrebatados a un proceso.
4.Espera circular.
Debe existir cadena circular de dos o más procesos, cada uno
esperando recurso poseído porl siguiente miembro de la cadena.
Carlos Figueira/USB
73
Políticas frente a interbloqueos
1. Ignorar:el tratamiento del interbloqueo es
responsabilidad del programador y/o de las acciones.
2. Detectar y recuperar:dejar que suceda y luego
recuperarse.
3. Prevenir: Evitar que estructuralmente sea posible el
interbloqueo, es decir, asegurar que al menos una de las
cuatro condiciones no se cumpla.
●
Algoritmo del Banquero: Necesita conocer requerimientos de
recursos de procesos. ¡Muy complejo en sistemas
distribuidos!
Carlos Figueira/USB
74
Tipos de interbloqueos
●
Interbloqueo por acceso a recursos.
●
Interbloqueo de comunicación
●
●
Ocurre con comunicaciones bloqueantes
Más frecuente en sistemas paralelos, por la
comunicación todos con todos. En sistemas
distribuidos, cliente-servidor es el esquema
dominante, en cuyo caso es muy raro que ocurra
A
send(B)
recv(C)
B
send(C)
recv(A)
Carlos Figueira/USB
C
send(A)
recv(B)
75
Algoritmos de Detección
Interbloqueos
●
Centralizado. Basado en grafos de espera
●
Actualización del grafo:
●
●
●
Cada máquina envía grafo a coordinador. Cada vez
que ocurra una variación le notifica.
Periódicamente cada máquina notifica sus últimos
cambios .
Periódicamente coordinador solicita la información
Carlos Figueira/USB
76
Algoritmo de detección centralizado
●
●
Interbloqueo no detectado; si coordinador asigna
recursos entonces no ocurre.
Interbloqueo falso. Ejemplo: Se pierden mensajes
–
Si B solicita a T y C libera a T y llega primero el mensaje
de B al coordinador, entonces cree que hay interbloqueo
Máquina 0
A
S
Máquina 1
Coordinador
A
S
S
C
C
R
R
T
T
B
B
Carlos Figueira/USB
77
Algoritmo de Detección Distribuido
●
Basado en grafo de recursos y procesos
●
Asume comunicación confiable
●
Se permite a procesos (o transacciones) pedir
varios recursos a la vez
Carlos Figueira/USB
78
Algoritmo de Detección Distribuido
●
Cuando un proceso tiene que esperar recurso
ocupado, envía mensaje Sonda al que tiene el
recurso.
●
●
Mensaje contiene: Id proceso que espera, Id
proceso que envía mensaje, Id de proceso que
recibe mensaje
Cuando proceso recibe mensaje Sonda
●
Si está en espera de otros recursos, agrega los
arcos respectivos. Si hay ciclo entonces hay
interbloqueo
Carlos Figueira/USB
79
Algoritmo de Detección Distribuido:
Recuperación
●
El proceso que detecta el interbloqueo puede
decidir terminar (sucidarse) y liberar sus
recursos
●
Puede inducir a otros suicidios innecesarios
●
Opción: seleccionar víctima
Carlos Figueira/USB
80