Sistemas de Operación II

Presentación del tema: "Sistemas de Operación II"— Transcripción de la presentación:

1 Sistemas de Operación II
Transacciones distribuidas Prof. Carlos Figueira Basado en material de Yudith Cardinale (USB) Andrew Tanembaum y Marteen van Steen

2 Contenido Transacciones: Introducción y definiciones
Algoritmos para completar transacciones Control de concurrencia Tratamientos de interbloqueos Carlos Figueira/USB

3 Transacciones: Introducción Definiciones
Carlos Figueira/USB

4 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

5 Transacción Serialización de operaciones conflictivas A B C
Operaciones compuestas Operaciones conflictivas Retardo Ejecución Serialización de operaciones conflictivas Carlos Figueira/USB

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 Transacciones Distribuidas
Involucran múltiples servidores Datos distribuidos entre varios servidores Transacción de un cliente puede incluir múltiples servidores Transacciones distribuidas pueden ser simples o anidadas cliente X Z Y Cliente: inicio_transaccion call X.x call Y.y call Z.z end_transaccion Carlos Figueira/USB

15 Transacciones Distribuidas
M T11 X T1 T N T12 T21 Cliente Y T2 P T22 Transacción distribuida anidada Carlos Figueira/USB

16 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

17 Procesamiento de transacciones distribuidas
TPS TPS Transaction Manager Transaction Manager TPS: Sistema de Procesamiento de Transacciones (Transaction Processing System) scheduler scheduler comunicación Data Manager Data Manager Recovery Manager Recovery Manager Cache Manager Cache Manager Carlos Figueira/USB

18 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

19 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

20 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

21 Algoritmos para completar (commit) transacciones
Carlos Figueira/USB

22 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

23 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

24 Protocolo C2F Máquina de estados finitos del coordinador (a) y de los trabajadores (b) Carlos Figueira/USB

25 Protocolo C2F: acciones del coordinador (1/2)
Carlos Figueira/USB

26 Protocolo C2F: acciones del coordinador (2/2)
Carlos Figueira/USB

27 Protocolo C2F: acciones del trabajador
Carlos Figueira/USB

28 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

29 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

30 Paradigmas de comunicación para el C2F
C2F centralizado voto C/A_global C/A Solicita voto C2F lineal voto voto voto C Fase 1 1 2 3 4 N Fase 2 C/A_gl C/A_gl C/A_gl C/A_gl Carlos Figueira/USB

31 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 C/A_ voto C/A_g Carlos Figueira/USB

32 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

33 Completar en Tres Fases (C3F Three-Phase-Commit)
Los estados del coordinador y de cada participante satisfacen las siguientes dos condiciones: No hay estado del cual sea posible hacer una transición directamente al estado completar o abortar 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

34 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

35 Control de Concurrencia
Carlos Figueira/USB

36 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

37 Control de concurrencia
Ejecución T U balance=200$ balance=220$ Balance debió ser =242 Las Operaciones conflictivas derivan en 2 problemas: Actualizaciones perdidas Transacción T Transacción U balance=b.getBalance() balance=b.getBalance() b.setBalance(balance*1.1) b.setBalance(balance*1.1) Recuperaciones inconsistentes Transacción V Transacción W a.retirar(100) unasucursal.totalSucursal(a,b) b.deposita(100)) Solución: Equivalencia Secuencial => Control de concurrencia Ejecución; a=200$ , b=200$ V W a=200$-100$ lee a=100$ lee b=200$ b=200$+100$ Total=300$ Según la ejecución el total es 300$. Debió ser 400$ Carlos Figueira/USB

38 Transacciones abortadas
Cuando una transacción aborta, puede generar dos problemas: Lecturas sucias Escrituras prematuras Carlos Figueira/USB

39 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

40 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

41 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 Se llama escritura prematura, porque se alteran los datos antes que la transaccion termine, y por tanto no se sabe si va a culminar con exito o no. Si otra transaccion (B) lee el dato, si aborta (despues de A), colocara el valor original que leyo en espacio permanente. Pero si A aborta, ese valor es incorrecto. Carlos Figueira/USB

42 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

43 Algoritmos de control de concurrencia
Tres estrategias Usando bloqueo (locking) Optimista Por marcas de tiempo (timestamp) Carlos Figueira/USB

44 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

45 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

46 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

47 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

48 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

49 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

50 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

51 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

52 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

53 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

54 Bloqueo en dos fases Bloqueo en dos fases
Bloqueo en dos fases estricto Número de bloqueos Fase de crecimiento Fase de liberación Número de bloqueos Fase de crecimiento Fase de liberación Se liberan todos los bloqueos Tiempo Tiempo Carlos Figueira/USB

55 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

56 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

57 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

58 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

59 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 Regla Lectura Escritura 1. Ti no debe leer datos escritos por Tv 2. Tv no debe leer datos escritos por Ti 3. Ti no debe escribir datos escritos por Tv y viceversa Carlos Figueira/USB

60 Validación hacia atrás
Se cumple regla 1: Puesto que Tv no escribe nada antes de llegar a Validación Se cumple regla 3: 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

61 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

62 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 T2 T3 Tv activa1 activa2 Transacciones anteriores completadas Transacción en validación Trabajo Validación Escritura Sólo se validan T2 y T3 T1 terminó antes que Tv comenzara Carlos Figueira/USB

63 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

64 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

65 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

66 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

67 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) 2. Tc no debe escribir dato escrito por Ti>Tc (requiere Tc>=max(Tcompletar_esc del dato) 3. Tc no debe leer dato escrito por Ti>Tc Requiere Tc>Tcompletar_esc Carlos Figueira/USB

68 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

69 Alg Marcas Tiempo: reglas escritura
a) T3 escritura b) T3 escritura T2 antes antes Versión completada después T3 después T2 T3 c) T3 escritura d) T3 escritura Versión tentativa T4 antes antes T3 Aborta Tiempo después T3 T4 después Carlos Figueira/USB

70 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; Abortar Tc; } Carlos Figueira/USB

71 Alg Marcas Tiempo: regla lectura
a) T3 lectura b) T3 lectura lectura se ejecuta inmediatamente T4 lectura se ejecuta inmediatamente Seleccionado Seleccionado c) T3 lectura d) T3 lectura Versión tentativa T2 lectura espera T3 Aborta Tiempo Seleccionado Carlos Figueira/USB

72 Interbloqueo Carlos Figueira/USB

73 Condiciones para interbloqueo
Exclusión mutua. Cada recurso está asignado a un único proceso o está disponible Posesión y espera. Procesos con recursos asignados pueden solicitar nuevos recursos. No apropiación. Recursos otorgados no pueden ser arrebatados a un proceso. 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

74 Políticas frente a interbloqueos
Ignorar:el tratamiento del interbloqueo es responsabilidad del programador y/o de las acciones. Detectar y recuperar:dejar que suceda y luego recuperarse. 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

75 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 B C send(B) send(C) send(A) recv(C) recv(A) recv(B) Carlos Figueira/USB

76 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

77 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 S B R A T C Máquina 0 Máquina 1 Coordinador Carlos Figueira/USB

78 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

79 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

80 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