Sistemas de Operación II

Transcripció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 2

3 Transacciones: Introducción Definiciones Carlos Figueira/USB 3

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 4

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

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 6

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 7

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 8

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 9

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 10

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 11

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 12

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 13

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 Cliente: inicio_transaccion call X.x call Y.y call Z.z end_transaccion X Y Z Carlos Figueira/USB 14

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

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 16

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

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 18

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 19

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 20

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

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 22

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 23

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

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

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

27 Protocolo C2F: acciones del trabajador Carlos Figueira/USB 27

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 28

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 29

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

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 31

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 32

33 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

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 34

35 Control de Concurrencia Carlos Figueira/USB 35

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 36

37 Control de concurrencia Las Operaciones conflictivas derivan en 2 problemas: Actualizaciones perdidas Transacción T balance=b.getbalance() Transacción U balance=b.getbalance() b.setbalance(balance*1.1) b.setbalance(balance*1.1) Ejecución T U balance=200$ balance=200$ balance=220$ balance=220$ Balance debió ser =242 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 37

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

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 39

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 40

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 Carlos Figueira/USB 41

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 42

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

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 44

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 45

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 46

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 Ninguno Lectura Escritura Bloqueo solicitado Lectura OK Escritura OK Lectura OK Escritura ESPERA Lectura ESPERA Escritura ESPERA Carlos Figueira/USB 47

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 48

49 Equivalencia secuencial Transacción T bal=b.obtenbalance() (200) b.ponbalance(bal*1.1) (220) a.extrae(bal/10) (80) Transacción U bal=b.obtentbalance() (220) b.ponbalance(bal*1.1) (242) c.extrae(bal/10) (278) Transacciones deben planificarse para que efectos sean secuencialmente equivalentes, regulando solicitud/liberación de recursos Carlos Figueira/USB 49

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 50

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 51

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 52

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 53

54 Número de bloqueos Número de bloqueos 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 Se liberan todos los bloqueos Tiempo Tiempo Carlos Figueira/USB 54

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 55

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 56

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 57

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 58

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 Escritura Lectura 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

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 60

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 61

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

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 63

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 64

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 65

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 66

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) 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

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 68

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

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

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

72 Interbloqueo Carlos Figueira/USB 72

73 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

74 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

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 75

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 76

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

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 78

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 79

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 80