Transacciones

Texto completo

(1)
(2)

Transacciones

• Las técnicas de sincronización ya vistas son de bajo nivel: – El programador debe enfrentarse directamente con los

detalles de:

• La exclusión mutua.

• El manejo de las regiones críticas. • La prevención de bloqueos.

• La recuperación de fallas.

• Se precisan técnicas de abstracción de mayor nivel que: – Oculten estos aspectos técnicos.

– Permitan a los programadores concentrarse en los

algoritmos y la forma en que los procesos trabajan juntos en paralelo.

• Tal abstracción la llamaremos transacción atómica,

(3)

Transacciones

• Las transacciones fueron originalmente desarrolladas para ser utilizadas dentro de los sistemas de base de datos,

donde se usaba para ayudar en el mantenimiento de los

datos de las aplicaciones y que dependían de la consistencia de la información almacenada.

• Las transacciones son mecanismos que ayudan a simplificar la construcción de sistemas confiables mediante procesos que proporcionan soporte uniforme para invocar y

sincronizar operaciones como:

– Operaciones de comparación de datos

– Aseguramiento de la seriabilidad de las transacciones con otras

(4)

Transacciones

• La palabra transacción describe una secuencia de

operaciones con uno o más recursos que transforman su estado actual en un nuevo estado de consistencia.

• Es un conjunto de operaciones sobre datos que son tratadas como una unidad.

• Una transacción puede terminar, haciendo sus cambios persistentes, o abortar voluntaria o involuntariamente. • Una transacción es una colección de operaciones que

hacen transformaciones consistentes de los estados de un sistema conservando la consistencia del sistema.

(5)

Transacciones

• Un esquema para garantizar la adecuada sincronización de la información en sistemas centralizados como distribuidos son el uso de transacciones.

La principal propiedad de la transacción atómica es el “todo o nada”:

– O se hace todo lo que se tenía que hacer como una unidad o no se hace nada.

• Una transacción es especificada por un cliente como un

conjunto de operaciones sobre objetos que será, realizadas como una unidad indivisible por el servidor.

(6)

Transacciones

– Un cliente se conecta a la pagina del Banco para:

• Retirar dinero de una cuenta.

Depositar el dinero en otra cuenta.

– La operación tiene dos etapas.

– Si la conexión telefónica falla luego de la primer etapa pero antes de la segunda:

Habrá un retiro pero no un depósito.

– La solución consiste en agrupar las dos operaciones en una transacción atómica:

Las dos operaciones terminarían o no terminaría ninguna. Se debe regresar al estado inicial si la transacción no puede

concluir.

(7)

Transacciones -

Propiedades

• Atomicidad: Todo o nada

• Aislamiento: Las transacciones se debe realizar sin interferencia de otra (serialización).

• Permanencia: Una vez que una transacción se ha realizado satisfactoriamente, los cambios son permanentes.

• Consistencia: las transacciones no pueden dejar datos inconsistentes

La permanencia, implica que los objetos deben ser durables cuando el proceso servidor crash por hard o soft y para ello los cambios deben estar disponibles en almacenamiento

(8)

Transacciones -

Propiedades

• La atomicidad garantiza que cada transacción no ocurre o bien se realiza en su totalidad:

– Se presenta como una acción indivisible e instantánea. • El aislamiento, solo se puede evitar si existe una

sincronización en las operaciones realizadas por el servidor de transacciones.

• La serialización es una forma de lograr la sincronización, asignando a cada operación un tiempo y un orden

preestablecido.

• La serialización garantiza que si dos o más transacciones se ejecutan al mismo tiempo:

– El resultado final aparece como si todas las transacciones se ejecutasen de manera secuencial en cierto orden:

(9)

Transacciones -

Propiedades

Ejemplo: suponga X una variable compartida por 3 procesos,

cuyo valor final deberá ser 1, 2 o 3:

Begin_transaction X=0; X=X+1; End_transaction Begin_transaction X=0; X=X+2; End_transaction Begin_transaction X=0; X=X+3; End_transaction

Dos transacciones A y B son serializables, si el resultado de su ejecución sobre un sistema transaccional, es el

(10)

Transacciones -

Propiedades

Ejemplo: suponga X una variable compartida por 3 procesos,

cuyo valor final deberá ser 1, 2 o 3:

Planif.1: X=0 X=X+1 X=0 X=X+2 X=0 X=X+3

Planif.2: X=0 X=X+2 X=0 X=X+1 X=0 X=X+3

Planif.3: X=0 X=0 X=X+1 X=0 X= X+2 X=X+3

No Serializable Serializable

Serializable

Planif.3: X=0 X=0 X=0 X=X+1 X= X+2 X=X+3

(11)

Transacciones -

Propiedades

• La permanencia se refiere a que una vez comprometida una transacción:

– Sigue adelante y los resultados son permanentes.

• La permanencia, implica que los objetos deben ser durables cuando el proceso servidor crash por hard o soft y para ello los cambios deben estar disponibles en almacenamiento

permanente.

El objetivo de cualquier servidor que maneje transacciones, es maximizar la concurrencia.

Dos o mas transacciones de ejecutan concurrentemente si tienen el mismo efecto de ejecutarse serialmente. Son

(12)

Transacciones

• Deben ser proporcionadas por el sistema operativo o por el sistema de tiempo de ejecución del lenguaje.

• Del lado Cliente

Begin_transaction: los comandos siguientes forman una transacción.

End_transaction: termina la transacción y se intenta un compromiso.

Abort_transaction: se elimina la transacción; se recuperan los valores anteriores.

(13)

Transacciones

• Del lado Servidor

Abort_transaction (): se elimina la transacción; se recuperan los valores anteriores.

Abort_transaction(): es el retorno de un aviso de errorCommit(): implica una señal de éxito

Read: se leen datos de un archivo (o algún otro objeto). Write: se escriben datos en un archivo (o algún otro

objeto).

(14)

Transacciones

• Las operaciones entre Begin y End forman el cuerpo de la transacción y deben ejecutarse todas o ninguna de ellas:

– Pueden ser llamadas al sistema, procedimiento de biblioteca o enunciados en un lenguaje.

(15)

Transacciones

Ejemplo: reservar un pasaje de San Juan a Calafate

Se ejecutaron las tres reservas

Reservar San Juan -BsAs

Reservar BsAs – Bahía Blanca Reservar Bahía Blanca – Calafate Begin_transaction

if (not OK ) Abort_transaction End_transaction

OK

OK

OK

El server retorna commit()

(16)

Transacciones

Ejemplo 1: reservar un pasaje de San Juan a Calafate

Ninguna se

ejecuta

Reservar San Juan -BsAs

Reservar BsAs – Bahía Blanca Reservar Bahía Blanca – Calafate Begin_transaction

if (not OK ) Abort_transaction

End_transaction

OK

OK

FULL

(17)

Transacciones -

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 recuperación se pueden comparar ambos discos bloque por bloque:

• Se puede actualizar la unidad 2 en función de la 1.

• Si se detecta el deterioro espontáneo de un bloque, se lo regenera partiendo del bloque correspondiente en la otra unidad.

(18)

Transacciones -

Almacenamiento Estable

a b c e d

Disco 1 Disco 1

crash Disco 1

Disco 2

a bb c e d

a b c e d

(19)

Transacciones

• Son métodos para asegurar la consistencia de los objetos. • Si cada proceso que ejecuta una transacción solo actualiza

los objetos usados.

– La transacción no es atómica.

– Los canbios no desaparecen si la transacción se aborta. – Los resultados de la ejecución de varias transacciones

no serán serializables.

• Métodos:

(20)

Transacciones

• Otorgar a cada proceso un espacio e memoria particular en el momento e que inicia una transacción.

• Este espacio contiene todos los archivos a los cuales tiene acceso.

– Todas las lecturas y escrituras van a este espacio. • Problema: costo el copiado al espacio de trabajo.

(21)

Transacciones

• Cuando un proceso inicia una transacción se le asigna un espacio de trabajo vacío con un puntero al espacio de trabajo del padre.

• 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 algún 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:

• Una optimización 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 localización de sus bloques en el disco.

– Es el i-nodo correspondiente.

(22)

Transacciones

• La lectura por medio del índice particular (del espacio de trabajo particular) no es problemática, pues las direcciones en disco a las que referencia son las originales.

• La modificación de un bloque de un archivo requiere:

– Hacer una copia del bloque.

– Insertar en el índice la dirección de la copia.

– La modificación 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 transacción ve el archivo

modificado pero los demás procesos ven el archivo original.

(23)

Transacciones

Si la transacción 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 transacción se compromete (termina normalmente):

– Los índices particulares se desplazan al espacio de trabajo del padre de manera atómica.

– Los bloques que no son alcanzables se colocan en la lista de bloques libres.

(24)

Transacciones

(25)

Transacciones

Antes de escribir cualquier bloque se escribe un registro en el

archivo de log del sistema.

Es un espacio de almacenamiento estable que indica:La transacción que realizo el cambio.

El archivo o bloque modificado.Los valores anteriores y nuevos.

• Solo después de escribir en el log se realizan los cambios en el archivo.

• Si la transacción tiene éxito y se establece un compromiso se registra en el log.

• Si la transacción se aborta se usa el log para respaldar el estado original.

(26)

Transacciones

Por ejemplo

X = 0 Y = 0

Begin transaction x = x + 1

y = y + 2 y = y * y End transaction

Log X = 0 / 1

Log X = 0 / 1

y = 0 / 2

Log X = 0 / 1

y = 0 / 2 y = 2 / 4

Log de escritura adelantada

(27)

Transacciones

Antes de escribir cualquier bloque se escribe un registro en el

archivo de log del sistema.

Es un espacio de almacenamiento estable que indica:La transacción que realizo el cambio.

El archivo o bloque modificado.Los valores anteriores y nuevos.

• Solo después de escribir en el log se realizan los cambios en el archivo.

• Si la transacción tiene éxito y se establece un compromiso se registra en el log.

• Si la transacción se aborta se usa el log para respaldar el estado original.

(28)
(29)

Control de Concurrencia

• Cuando se ejecutan varias transacciones simultáneamente, es necesario implementar mecanismos para que no se

interpongan unas a otras.

• Los mecanismos de control de concurrencia garantizan que las operaciones que se realizan concurrentemente procedan en exclusión mutua.

• El Control de Concurrencia es fundamental para lograr aislamiento y consistencia.

• La problemática de las transacciones concurrentes se debe a:

o Operaciones de lectura y escritura simultánea.

(30)

Control de Concurrencia

La idea es resolver las operaciones conflictivas

Operaciones conflictivas: 2 operaciones son conflictivas

cuando sus efectos combinados dependen del orden en el cual fueron ejecutadas.

Para dos transacciones A y B, se consideran conflictivas las siguientes operaciones:

A B

read read No conflictivo

read write Conflictivo

write write Conflictivo

Cuando dos o más transacciones son conflictivas es

(31)

Control de Concurrencia

Los métodos de resolución aplicados son: – Locking

(32)

Locking

• Cuando un proceso quiere usar un recurso, lo bloquea hasta que la transacción culmine exitosamente (commit) y

cualquier otra transacción que desee hacer alguna

operación sobre dicho objeto tendrá que esperar hasta que él sea desbloqueado.

• Los locks son adquiridos y liberados por el administrador de transacciones, esto implica que todo lo concerniente al control de concurrencia es transparente para el

programador.

• El administrador de locks puede ser centralizado o local para cada máquina.

(33)

Locking

• Los lock pueden ser de:

– lectura (compartidos)

– escritura (excluyentes)

• Si en un recurso se establece un lock de lectura, se permiten mas lock de lectura  asegura que no se puede modificar.

• Si en un recurso se establece un lock de escritura, no se permite ningún otro lock

El problema del algoritmo de locking es que puede

(34)

Granularidad del Locking

• Tiene que ver con el tamaño del objeto o dato que se está bloqueando.

• A mayor granularidad (mayor fineza del grano), más pequeño es el tamaño del objeto.

• El nivel del bloqueo es directamente proporcional al grado de paralelismo y concurrencia, pero también es

directamente proporcional al grado de complejidad de los sistemas

• Mientras mayor sea la fineza del grano, mejor será el grado de paralelismo/concurrencia, pero mayor será la complejidad del sistema.

(35)

Locking – Reglas de conflicto

• Si una transacción T esta realizando un read, otra transacción U no puede write hasta que T termine o aborte.

• Si una transacción T esta realizando un write, otra transacción U no puede read, ni write hasta que T termine o aborte.

• Si una transacción tiene un lock read no lo puede cambiar a lock write, porque estaría en conflicto con los demás lock read

 la transacción debe pedir un lock write y esperar a que los demás lock read sean liberados.

• La migración de un lock a otro mas excluyente se denomina Migración, y debe observar para cualquier objeto.

(36)

Locking - Mejoras

• Una mejora: utilizar locks de escritura y locks de lectura para ofrecer un mejor paralelismo al permitir que se

realicen concurrentemente transacciones que hagan operaciones no conflictivas.

• Otra mejora: promoción de locks, si varias transacciones necesitan un objeto para lectura y luego para escritura, se les puede otorgar un lock de lectura hasta que alguna

necesite escribir en el objeto. Se le otorgará el lock de escritura después de que todas las demás transacciones que tengan locks de lectura sobre el mismo objeto, lo

(37)

Two Phase Locking

• Durante la fase de “obtención”, la transacción trata de obtener todos los locks que necesite. Si no es posible obtener alguno, entonces espera.

• La segunda fase comienza cuando la transacción libera alguno de los locks, a partir de ese momento no podrá solicitar ningún otro lock (si lo hace, será abortada).

• Desventaja: si una transacción en la fase de liberación

había desbloqueado algunos objetos y los mismos habían sido accedidos por otras transacciones antes de que la

primera hiciera commit, entonces las demás transacciones deberían abortar (esto es abortos en cascada).

(38)

Strict Two Phase Locking:

• La fase de “liberación” se realiza sólo cuando la transacción hace commit.

• La mejora: evita los abortos en cascada • Desventajas:

– El nivel de paralelismo se degrada

– Permanece la posibilidad de deadlock

(39)
(40)

Control optimista de la concurrencia

• Se basa en las siguientes premisas:

– “Los conflictos suceden poco”

– “Como vaya viniendo vamos viendo”

– “¡Adelante!, haz lo que quieras sin atender lo que los otros hacen, no te preocupes por los problemas ahora, preocúpate más tarde”

• La idea es muy sencilla:

– Se sigue adelante y se hace todo lo que se deba hacer, sin prestar atención a lo que hacen los demás.

(41)

Control optimista de la concurrencia

• Se mantiene un registro de los archivos leídos o grabados. En el momento del compromiso:

– Se verifican todas las demás transacciones para ver si alguno de los archivos ha sido modificado desde el

inicio de la transacción:

o Si esto ocurre la transacción aborta.

o Si esto no ocurre se realiza el compromiso.

(42)

Control optimista de la concurrencia

Cada transacción cumple tres fases:

• Trabajo: Todos los reads se ejecutan inmediatamente sobre

la última versión “comprometida” del dato. Los writes crean

versiones tentativas. Se mantiene un conjunto de lectura (datos leídos) y un conjunto de escritura (versiones

tentativas de los datos).

• Validación: Ante la solicitud de un commit, se valida si la transacción realizó operaciones conflictivas con otras transacciones.

(43)

Control optimista de la concurrencia

Fase de validación:

• Ante el close_transaction, a cada transacción se le asigna un número (secuencial ascendente, i) que define su

posición en el tiempo.

• La validación se basa en las siguientes reglas (i < j):

• Simplificación: fases de validación y escritura son secciones críticas, entonces se satisface la regla 3. • Sólo hay que validar las reglas 1 y 2.

Ti Tj Regla

read write Ti no debe leer datos escritos por Tj write read Tj no debe leer datos escritos por Ti

(44)

Control de Concurrencia

• Las principales ventajas son:

– Ausencia de bloqueos.

– Paralelismo máximo ya que no se esperan lock.

• La principal desventaja es:

– Re-ejecución de la transacción en caso de falla.

– La probabilidad de fallo puede crecer si la carga de trabajo es muy alta.

(45)

Control de Concurrencia

• Se asocia a cada transacción 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

transacción 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 (más

antiguas) que la marca de la transacción activa.

• Si la marca de tiempo de la transacción activa es menor que la del archivo que intenta acceder:

– Una transacción iniciada posteriormente ha accedido al archivo y ha efectuado un compromiso.

– La transacción activa se ha realizado tarde y se aborta.

(46)

Control de Concurrencia

• En el método de las marcas no preocupa que las transacciones concurrentes utilicen los mismos archivos, pero sí importa que la transacción con el número menor esté en primer lugar.

• Las marcas de tiempo tienen propiedades distintas a las de los lock:

– Una transacción aborta cuando encuentra una marca mayor (posterior).

– En iguales circunstancias y en un esquema de cerraduras podría esperar o continuar inmediatamente.

Las marcas de tiempo son libres de lock, lo que es una gran ventaja.

(47)
(48)

Deadlock

• En sistemas centralizados el manejo de interbloqueos es o muy costoso o extremadamente restrictivo.

• En sistemas distribuidos debemos agregar el costo que se

paga por tener a los elementos de procesamiento físicamente separados.

• Todos los sistemas concurrentes (paralelos o distribuidos) están propensos a presentar deadlocks en su estado global. • Los interbloqueos son factores no deseables.

• Cuando se presentan, el único medio para restablecerse de ellos, es reiniciando una o varias tareas participantes en el interbloqueo.

• Esto implica un gasto de trabajo en actividades no útiles.

(49)

Deadlock

• Muchos sistemas han optado por garantizar que nunca se presentarán deadlocks dentro de ellos.

• Esto se hace imponiendo restricciones en cuanto a la forma y orden de solicitar recursos administrados por el sistema.

• Esta estrategia no es útil en los sistemas distribuidos pues el ordenamiento de eventos en los sistemas distribuidos es un problema complicado y costoso.

(50)

El problema del Deadlock

El ejemplo del puente

• Trafico solo en una dirección.

• Cada sección del puente se puede ver como un recurso. • Si ocurre un deadlock, se puede resolver si un auto hace

marcha atrás.

(51)

Modelo del Sistema

• Tipos de recursos: R1,R2,….,Rn

ciclos de CPU, espacio de memoria, E/S • Cada Recurso Ri posee Wi instancias.

• Un proceso solo puede utilizar una instancia de un recurso, siguiendo esta secuencia:

o Solicitud: Si la solicitud no puede atenderse de inmediato, el proceso debe esperar.

o Uso: El proceso opera con el recurso.

(52)

Modelo del Sistema

• El uso de los recursos solo puede ser hecho por medio de llamadas al sistema (System Calls)

• Ejemplo

o open/close para archivos

o malloc/free para memoria

o request/release para dispositivos (waits y signal)

(53)

Deadlock - Concepto

Un deadlock es una situación en donde un grupo de procesos se bloquea permanente como resultado de que cada proceso ha obtenido un subconjunto de los recursos necesarios para su terminación y se encuentra esperando indefinidamente por lo la liberación de otros recursos que están siendo ocupados por otros procesos los cuales también esperan por recursos

(54)

Deadlock - Concepto

• Los deadlocks están relacionados tanto a aspectos de sincronización como de administración de recursos. • Los recursos pueden ser:

o propios de la aplicación (señales o mensajes de sincronización) y deben ser administrados por la aplicación misma.

o del sistema completo (servidores de bases de datos,

servidores de llaves, etc.) y deben ser administrados por el propio sistema.

(55)

Condiciones para la presencia de Deadlock

1.Exclusión mutua. Los recursos compartidos se obtienen y se usan en una forma mutuamente exclusiva, esto es, a lo más un proceso a la vez.

2.Hold and wait. Cada proceso continúa manteniendo el control de un recurso mientras espera obtener otros recursos.

3.No preemption. Los recursos concedidos a un proceso

pueden ser liberados al sistema solo como resultado de una acción voluntaria de tal proceso; el sistema no puede liberar los recursos por la fuerza.

(56)

Gráfica de estado del sistema

• Procesos

• Recursos y Instancias

Pi pide una instancia de Rj

Pi se le asigna una instancia de Rj

solicita

(57)
(58)
(59)
(60)

Condiciones para la presencia de Deadlock

• Si el grafo NO contiene ciclos

NO deadlock

• Si el grafo contiene ciclos

o

Deadlock si hay una instancia por recurso.

o

Posibilidad de deadlock si hay muchas

instancias por tipo de recursos.

(61)

Estratégias para manejo de Deadlocks

Prevenir Deadlocks

La idea es prevenir que se presente alguna de las cuatro condiciones necesarias para la existencia de un deadlock. •Exclusion Mutua: No es posible prevenir por negación de la exclusión mutua, ya que existe recursos intrínsecamente no compartibles. Ej printer.

Hold and wait: Se debe garantizar que siempre que un proceso solicite un recurso, el no tiene otro.

o Protocolo 1: Hacer que cada proceso adquiera de antemano los recursos que va a utilizar.

(62)

Estratégias para manejo de Deadlocks

Prevenir Deadlocks

No preemption: Si un proceso solicita recursos que NO pueden ser asignados inmediatamente, entonces:

o Todos los recursos que el tiene asignado son liberados.

o Los recursos quitados son sumados a la lista de recursos por la cual el proceso espera.

o El proceso continua cuando le sean devueltos los recursos quitados, mas los nuevos.

(63)

Estratégias para manejo de Deadlocks

Prevenir Deadlocks

Las desventajas son:

• Decremento de la concurrencia del sistema.

• Los procesos puede entrar en un deadlock en la fase de adquisición.

(64)

Estratégias para manejo de Deadlocks

Evitación de Deadlocks

•Se le da a los procesos los recursos siempre que sea posible. •Se requiere toda la información acerca de los request y

release.

•Con esta información se decide si el proceso debe esperar o no.

•Información requerida

o Recursos disponibles

o Recursos asignados a cada proceso

o Liberaciones y futuras solicitudes de recursos.

(65)

Estratégias para manejo de Deadlocks

Evitación de Deadlocks

Los inconvenientes de esta estrategia es sistemas distribuidos son:

•Requiere una gran capacidad de almacenamiento para el estado global en cada parte del sistema distribuido.

•El proceso que verifica la seguridad del estado global debe

trabajar en forma mutuamente exclusiva; esto limita severamente la concurrencia y “throughput” del sistema.

(66)

Estado Seguro

• Cuando un proceso solicita recursos, el sistema debe decidir si la inmediata asignación deja al sistema en estado seguro.

• Un sistema está en estado seguro, si existe una secuencia segura de todos los procesos.

• La secuencia <P1,P2,….Pn> es segura si P∀ i, los recursos que Pi que aun necesita pueden ser satisfechos por los recursos disponibles, mas los que libere Pj para todo j < I.

• Si los recursos que Pi necesita no están disponibles inmediatamente, entonces Pi puede esperar hasta que Pj haya finalizado.

• Cuando Pj finaliza, Pi puede obtener los recursos, se ejecuta y devuelve los recursos asignados.

(67)

Estado Seguro - Ejemplo

Consideremos un sistema con 12 unidades de cintas y 3 procesos: p0, p, y p2. El proceso p0 requiere 10 unidades, el p1 puede necesitar hasta 4 y p2 hasta 9. Supongamos que en el instante TO, p0 ya tiene asignadas 5

unidades, p1 2 unidades y p2 tiene 2. (Hay 3 unidades libres)

• En TO el sistema esta en estado seguro.

• La secuencia ( p1, p0, p2 ) satisface la condición de seguridad:

o p1 puede obtener las unidades que necesita,

o luego de liberadas el sistema tendrá 5 unidades libres, entonces p0 consigue las 5 adicionales,

o luego las libera y p2 consigue las 7 necesarias.

o luego el sistema tendrá las 12 cintas disponibles.

Necesidades Máximas Actualmente Asignadas

p0 10 5

p1 4 2

(68)

Estado Seguro - Ejemplo

Observemos que es posible pasar de un estado seguro a otro inseguro.

•Suponiendo que en T1, p2 pida una cinta adicional y se le asigne.

•En esta situación, el sistema ya no esta en estado seguro, ya que solo a p1 se le podrá asignar los recursos remanentes.

•Cuando p1 termine, el sistema contara con solo 4 cintas libres y si p0 pide 5, debe esperar.

•Ssi p2 solicita las 6 cintas adicionales también tendrá que esperar, entrando en deadlock.

•El error fue asignar a p2 la primer cinta adicional.

•Si hubiésemos hecho esperar a p2 hasta que cualquiera de los otros procesos termine y libere las cintas, se puede evitar el

(69)

Estratégias para manejo de Deadlocks

Detección de Deadlocks

•La idea de la detección de deadlocks es conceder los recursos sujeto únicamente a su disponibilidad y verificar periódicamente si el sistema ha entrado o no a un deadlock.

•Cuando se detecta un deadlock se elige alguna estrategia para romperlo.

Tiene las siguientes ventajas:

• una vez que un ciclo se ha formado en la gráfica del estado global, éste persiste hasta que es detectado y resuelto.

• la detección de deadlocks puede proceder

(70)

Estratégias para manejo de Deadlocks

Detección de Deadlocks

Los algoritmos de detección de deadlocks fundamentalmente incluyen dos actividades:

(71)

Algoritmo para detección de deadlocks

• Sean ASIGNADOS y SOLICITADOS estructuras de datos para

mantener la información sobre los recursos asignados y solicitados y aún no obtenidos por un proceso, respectivamente.

• Sea DISPONIBLES la estructura de datos en la cual se almacena la información sobre los recursos disponibles.

1. Identificar el estado del sistema.

Actualizar la información de las estructuras, ASIGNADOS,

(72)

Algoritmo para detección de deadlocks

2. Encontrar un proceso no marcado i, tal que,

SOLICITADOSi <= DISPONIBLES.

• Si se encuentra, marcar al proceso i y actualizar a DISPONIBLES haciendo:

DISPONIBLES = DISPONIBLES + ASIGNADOSi • Repetir este paso.

• Si no se encuentran procesos con tal propiedad, se procede al paso siguiente.

(73)
(74)

Ejemplo de Algoritmo

• Como puede verse el sistema se encuentra en un deadlock ya que ninguno de los dos procesos podrá obtener los

recursos que solicita ya que están siendo ocupados por el otro.

• Si ellos no liberan algún recurso en forma voluntaria, los procesos quedarán bloqueados indefinidamente.

• En caso de los sistemas distribuidos debido a que son

(75)

Ejemplo 2 de Algoritmo

Considere la secuencia de acciones siguiente. Debido a que varios mensajes pueden estar en tránsito. P1, P2 son

(76)

Ejemplo 2 de Algoritmo

(77)

Clases de algoritmos para detección de

deadlocks en sistemas distribuidos

Existen tres clases de algoritmos de detección de deadlocks:

1.Centralizados, el mantenimiento y detección se realiza en un

solo lugar.

2.Distribuidos, la gráfica del estado del sistema se encuentra

distribuido en varios lugares.

3.Jerárquicos, los lugares del sistema se arreglan en una

jerarquía y cada nodo es responsable por la gráfica de estado de sus descendientes.

Para que un algoritmo de detección de deadlocks se correcto, se deben satisfacer los siguientes dos criterios:

(78)

Algoritmos Centralizados

• En cada lugar existe una tabla que contiene el estado de todos los procesos iniciados en ese lugar (recursos

asignados y solicitados por los procesos).

• Periódicamente, un lugar es elegido como control, el cual realiza las siguientes acciones:

1. Envía un mensaje a todos los lugares en el sistema

solicitando sus tablas de estado y espera a que lleguen todas ellas.

2. Construye una gráfica de asignacion de recursos.

3. Si no existe un ciclo en la gráfica, no existen deadlocks y termina.

(79)

Algoritmos Centralizados

4. Si existen ciclos en la gráfica, envía un segundo

mensaje solicitando de nuevo las tablas de estado de cada lugar.

5. Construye una nueva gráfica de asignamiento de

recursos, usando solo las transacciones comunes a las dos solicitudes.

6. Si no hay ciclos dirigidos, el sistema no está en un deadlock y termina.

7. Si se presenta el mismo ciclo nuevamente, se declara un deadlock en el sistema.

(80)

Algoritmos Centralizados

4. Si existen ciclos en la gráfica, envía un segundo

mensaje solicitando de nuevo las tablas de estado de cada lugar.

5. Construye una nueva gráfica de asignación de recursos, usando solo las transacciones comunes a las dos

solicitudes.

6. Si no hay ciclos dirigidos, el sistema no está en un deadlock y termina.

7. Si se presenta el mismo ciclo nuevamente, se declara un deadlock en el sistema.

(81)

Algoritmos Centralizados

Observaciones.

• Requiere de dos fases para determinar un deadlock. • Utiliza 4n mensajes en un sistema con n nodos.

• Obteniendo dos reportes consecutivos, se reduce pero no se elimina la probabilidad de obtener una visión

inconsistente.

(82)

Algoritmos Centralizados

En cada nodo se mantienen dos tablas:

•Tabla de estado de los recursos. Indica las transacciones

que han obtenido el acceso a los recursos controlados por el nodo o que están esperando por el recurso.

•Tabla de estado de los procesos. Indica las transacciones

del nodo que han obtenido el acceso o que están esperando por recursos en ese u otros nodos.

(83)

Algoritmos Centralizados

Periódicamente un nodo se elige como control, el cual realiza las siguientes acciones:

1.Envía un mensaje a todos los lugares en el sistema

solicitando sus tablas de estado y espera a que lleguen todas ellas.

2.Construye una gráfica de asignación de recursos usando solo las transacciones para las cuales la tabla de recursos concuerda con la tabla de procesos (existen entradas

idénticas en ambas tablas).

3.Si no existe algún ciclo dirigido, el sistema no se encuentra en un deadlock y termina.

4.Si se detecta algún ciclo, el sistema se declara en un deadlock.

(84)

Algoritmos Distribuidos

• Se utiliza un mensaje especial llamado una prueba. Una prueba es una tripleta (i,j,k) denotando que pertenece a la detección de deadlocks iniciada por Pi y está siendo

enviada del nodo en el cual reside Pj al nodo donde reside Pk.

• Un mensaje viaja a lo largo de los arcos de la gráfica de

transacciones en espera, se detecta un deadlock cuando el mensaje original llega al proceso de donde partió.

(85)

Figure

Actualización...

Referencias

Actualización...

Related subjects :