Capítulo 7: Control de Concurrencia - Parte 2

Capítulo 7
Control de Concurrencia – Parte 2

Problemas de los protocolos
basados en bloqueos
 ¿Qué problemas encuentran con los protocolos basados en
bloqueos (de dos fases)?
basados en bloqueos
 ¿Qué problemas encuentran con los protocolos basados en
bloqueos (de dos fases)?
 Esperas de transacciones para obtención de bloqueos sobre elementos de
datos.
 Carga de almacenamiento para cada elemento de datos en tabla de gestor
de bloqueos.
 Este efecto es peor cuantas más transacciones hay accediendo a un
elemento de datos.
 Los dos primeros problemas anteriores se agravan cuando se garantiza
ausencia de cascadas.
 Manejo de interbloqueos: Hay dos enfoques:
 prevención de interbloqueos, o
 detección y recuperación de interbloqueos.
basados en bloqueos
 Meta: Definir protocolos de control de concurrencia donde
estos problemas no ocurran.
 Que las transacciones no tengan que esperar.
 Que no haya carga de almacenamiento por elemento de datos o que
la misma sea muy baja.
 Que no haya que preocuparse por los interbloqueos porque no
suceden.
• Idea: no trabajar con bloqueos
Protocolos no basados en bloqueos
• Problema: ¿Cómo hacer para garantizar
secuencialidad por conflictos a medida que
se va generando la planificación?
• Problema: ¿Cómo hacer para garantizar
secuencialidad por conflictos a medida que
se va generando la planificación?
• Hay que definir alguna regla a respetar que
garantiza que el grafo de precedencia de la
planificación que se va generando no tenga
ciclos.
• ¿Cómo lograr eso?
 Idea: definir un orden total entre las transacciones (que se va
actualizando a medida que se agregan transacciones) que se
tiene que respetar por el grafo de precedencia de la
planificación siguiendo el protocolo.
 Un orden total es anti-simétrico, transitivo y en el mismo todo par de
elementos esta relacionado.
 Todos los arcos en el grafo de precedencia (de la parte generada de la
planificación) tienen la forma:
 Por lo tanto en el grafo de precedencia no va a haber ciclos y la

planificación va a ser secuenciable por conflictos.
• Fíjense que cada vez que una transacción necesita
ejecutar un read(Q) o un write(Q) no se pueden generar
arcos en el grafo de precedencia que no respetan el
orden entre transacciones.
• ¿Qué pasa si ejecutar un read(Q) o un write(Q) lleva a
violar la regla anterior?
• Fíjense que cada vez que una transacción necesita
ejecutar un read(Q) o un write(Q) no se pueden generar
arcos en el grafo de precedencia que no respetan el
orden entre transacciones.
• ¿Qué pasa si ejecutar un read(Q) o un write(Q) lleva a
violar la regla anterior?
• Como la transacción no puede ejecutar la instrucción y
tampoco puede esperar, no queda otra que retrocederla.
• ¿En base a qué puedo comparar dos transacciones?
• Esa comparación debe ser lo más sencilla posible y poder
hacerse de manera eficiente.
Protocolos basados en
marcas temporales
 Solución: protocolos basados en marcas temporales (timestamp).
 A cada transacción le asigno una marca temporal que tiene que ver con el
instante en que ocurre un evento importante de la ejecución de la
transacción.
 Regla: Los arcos del grafo de precedencia de la planificación deben
respetar el ordenamiento de marcas temporales.
 O sea, todos los arcos en el grafo de precedencia tienen la forma:
 Así no hay ciclos en el grafo de precedencia y la planificación será

secuenciable por conflictos.
marcas temporales
• A toda transacción Ti del sistema se le asocia una única marca
temporal fijada, denotada por TS(Ti) (o MT(Ti)).
• ¿Cómo se pueden representar las marcas temporales?
marcas temporales
• A toda transacción Ti del sistema se le asocia una única marca
temporal fijada, denotada por TS(Ti) (o MT(Ti)).
• ¿Cómo se pueden representar las marcas temporales?
1. Usar el valor del reloj del sistema como marca temporal.
• La marca temporal de una transacción es igual al valor del reloj del
sistema en el momento que se asigna la marca temporal.
2. Usar un contador lógico que se incrementa cada vez que se asigna
una nueva marca temporal.
• La marca temporal de una transacción es igual al valor del contador
en el momento en el cual se asigna la marca temporal a la
transacción
Protocolo de ordenación
por marcas temporales
• ¿Qué ideas les vienen en mente para ordenar transacciones
usando marcas temporales? ¿O sea, dar ejemplos de marcas
temporales potenciales?
• ¿Qué ideas les vienen en mente para ordenar transacciones
usando marcas temporales? ¿O sea, dar ejemplos de marcas
temporales potenciales?
• Protocolo de ordenación por marcas temporales
– A cada transacción se le da una marca temporal cuando entra al sistema.
– Si una transacción viejaTi tiene una marca temporal TS(Ti), a una nueva
transacción Tj se le asigna una marca temporal TS(Tj) cumpliendo
TS(Ti) < TS(Tj).
• El protocolo gestiona la ejecución concurrente de modo que
las marcas temporales determinan el orden de
secuenciamiento de las transacciones.
 Problema: Cuando una transacción quiere ejecutar una
operación read(Q) o write(Q),
 hay que estar seguros que si se le da permiso para hacer esta
operación no se viola la regla que debe cumplir el grafo de
precedencia.
 ¿Cómo asegurarse de esto?
precedencia.
 Solución 1: revisar la planificación hasta este momento para
estar seguros si no se genera un conflicto con una instrucción
de otra transacción sobre el mismo elemento de datos y
 ese conflicto hace que se viole la regla que debe cumplir el grafo de
precedencia.
 ¿Qué les parece esta idea?
precedencia.
 Solución 1: revisar la planificación hasta este momento para
estar seguros si no se genera un conflicto con una instrucción
de otra transacción sobre el mismo elemento de datos y
 ese conflicto hace que se viole la regla que debe cumplir el grafo de
precedencia.
 Evaluación: Hacer este chequeo es demasiado costoso.
• Idea: uno no necesitaría hacer la comprobación
anterior si contara con cierta información resumida
de antemano.
• ¿Por ejemplo, si T necesita hacer read(Q) qué
información resumida necesito para comprobar que
todo va a estar bien si T hace read(Q)?
• Idea: uno no necesitaría hacer la comprobación
anterior si contara con cierta información resumida
de antemano.
• ¿Por ejemplo, si T necesita hacer read(Q) qué
información resumida necesito para comprobar que
todo va a estar bien si T hace read(Q)?
• La mayor marca temporal de todas las transacciones
que ejecutaron write(Q)
 Solución 2: Con el fin de asegurar la regla que debe cumplir el
grafo de precedencia, se mantiene para cada elemento de
datos Q dos valores de marca temporal:
 W-timestamp(Q) – o MTE(Q) - es la mayor marca temporal de todas
las transacciones que ejecutaron write(Q) exitosamente.
 R-timestamp(Q) – o MTL(Q) - es la mayor marca temporal de todas las
transacciones que ejecutaron read(Q) exitosamente.
 Evaluación: Estas marcas temporales se actualizan cada vez que
se ejecuta una nueva operación read(Q) o write(Q).
 Como veremos, actualizar estas marcas es barato.
 Considere la propiedad P diciendo que todos los arcos en el grafo
de precedencia tienen la forma:
 Así, no va a haber ciclos en el grafo de precedencia.

 Usando P, es posible derivar las reglas de un protocolo que
satisface P.
 El protocolo de marcas temporales deseado debe asegurar que
todo par de instrucciones read y write en conflicto son ejecutadas en
el orden de las marcas temporales.
 Suponga que la transacción Ti emite read(Q)

 ¿Qué comprobación hay que hacer? ¿Qué casos se
tienen? ¿Qué se hace en cada uno?
 Suponga que la transacción Ti emite read(Q)

1. Si TS(Ti) < W-timestamp(Q), entonces Ti necesita leer un valor de
Q que ya fue sobreescrito. Entonces, la operación read es
rechazada, y Ti es retrocedida.
2. Si TS(Ti)  W-timestamp(Q), entonces la operación read es
ejecutada, y R-timestamp(Q) es fijado al máximo de R-
timestamp(Q) y TS(Ti).
 Suponga que la transacción Ti emite write(Q).
 ¿Qué comprobación hay que hacer? ¿Qué casos se
tienen? ¿Qué se hace en cada uno?
 Suponga que la transacción Ti emite write(Q).
1. Si TS(Ti) < R-timestamp(Q), entonces el valor de Q que Ti está
produciendo fue necesitado previamente, y el sistema asumió que
ese valor no debería haber sido nunca producido. Entonces la
operación write es rechazada, y Ti es retrocedida.
2. Si TS(Ti) < W-timestamp(Q), entonces Ti está tratando de escribir
un valor obsoleto de Q. Luego, la operación write es rechazada, y
Ti es retrocedida.
3. De otro modo, la operación write es ejecutada, y W-timestamp(Q)
es fijado a TS(Ti).
• ¿Qué conviene hacer con las transacciones que
retrocedieron?
• ¿Qué conviene hacer con las transacciones que
retrocedieron?
• A una transacción Ti que el esquema de control de
concurrencia haya retrocedido como resultado de la
ejecución de una operación leer o escribir,
o se le asigna una nueva marca temporal y se la inicia de
nuevo.
• Notación a usar al construir planificaciones:
 Para cada elemento de datos Q usar una columna. En la
misma:
 L = X significa que MTL(Q) = X
 E = X significa que MTE(Q) = X.
 La última columna se usa para registrar las marcas
temporales de las transacciones. En la misma
 Ti = X significa que MT(Ti) = X.
 Not exists Tj : significa que no hay una marca temporal
para Tj.
• Ejercicio:
– Sean las transacciones:
T1 : st; r(A); w(C)
T2 : st; r(B); w(B)
T3 : st; r(B); r(C); w(A)
– st significa que la transacción comienza.
– Las marcas temporales para los elementos de dato
inicialmente valen 0.
– Construir una planificación legal por el protocolo
de ordenación por marcas temporales.
Ejemplo de planificación
para las transacciones
anteriores.
 Evaluación:
 ¿El protocolo de ordenación por marcas temporales garantiza
secuencialidad?
 Evaluación:
 El protocolo de ordenación por marcas temporales garantiza
secuencialidad debido a que todos los arcos en el grafo de precedencia
son de la forma:
 ¿Con el protocolo de ordenación por marcas temporales puede

haber interbloqueos?
 Evaluación:
 El protocolo de ordenación por marcas temporales garantiza
secuencialidad debido a que todos los arcos en el grafo de precedencia
son de la forma:
 El protocolo de ordenación por marcas temporales asegura ausencia de

interbloqueos
 debido a que ninguna transacción espera jamás.
 Pero la planificación puede no ser libre de cascadas, y puede incluso
no ser recuperable.
Recuperabilidad y ausencia de cascadas
 Repaso:
 ¿Qué pasa si Ti aborta, pero Tk ha leído un ítem de datos escrito por
Ti?
 Repaso:
Ti?
 Entonces Tk debe abortar;
 ¿Qué sucede si a Tk se le ha permitido comprometerse antes?
 Repaso:
Ti?
 Entonces Tk debe abortar;
 ¿Qué sucede si a Tk se le ha permitido comprometerse antes?
 En ese caso la planificación no es recuperable.
 Más aún, toda transacción que ha leído un ítem de datos escrito por Ti
debe abortarse.
 Esto puede llevar a retrocesos en cascada--- o sea, una cadena de
retrocesos.
 Meta: garantizar al menos la recuperabilidad y si es posible la
ausencia de cascadas.
• ¿Para garantizar recuperabilidad qué debemos pedir para

cada transacción T de la planificación?

• Si T lee elementos de datos previamente escritos por una
transacción T’, la operación comprometer de T’ debe aparecer
antes que la operación comprometer de T.
• ¿Qué información necesitamos para poder comprobar
eficientemente si T se puede comprometer ?

• Si T lee elementos de datos previamente escritos por una
transacción T’, la operación comprometer de T’ debe aparecer
antes que la operación comprometer de T.
• ¿Qué información necesitamos para poder comprobar
eficientemente si T se puede comprometer ?
• Para cada elemento de datos Q sobre el que T hizo read(Q) necesito
saber si hay una transacción no comprometida que hizo el último
write(Q).
• A esa información se la llama dependencia commit.
 Solución para garantizar recuperabilidad (solamente)

 Para cada item de datos Q que fue escrito por transacciones no
comprometidas aun, registramos la transacción T’ (de esas) que hizo el último
write(Q).
 Esta información debe ser mantenida. ¿Qué se hace si una transacción se
comprometió?

write(Q).
comprometió?
 Si T figura que es la última en haber hecho algún write(Q) se quita esa
información.
 Si una transacción T hace un read(Q), registramos una dependencia commit
de T con la transacción no comprometida que hizo el último write(Q) (entre
todas las transacciones).
 ¿Qué pasa con esta información si una transacción se comprometió?

write(Q).
comprometió?
 Si T figura que es la última en haber hecho algún write(Q) se quita esa
información.
 Si una transacción T hace un read(Q), registramos una dependencia commit
de T con la transacción no comprometida que hizo el último write(Q) (entre
todas las transacciones).
 ¿Qué pasa con esta información si una transacción se comprometió?
 Hay que eliminar dependencias commit que la involucran
 Solución para garantizar recuperabilidad (solamente) - continuación

 ¿Cuándo se puede comprometer una transacción T?

 Una transacción T no puede comprometerse hasta que se compromenten
todas las transacciones con las cuales tiene una dependencia commit.
 Si una de esas transacciones aborta, entonces T debe abortar.
 ¿Qué chequeo debo hacer antes de que T se comprometa?

 Una transacción T no puede comprometerse hasta que se compromenten
todas las transacciones con las cuales tiene una dependencia commit.
 Si una de esas transacciones aborta, entonces T debe abortar.
 ¿Qué chequeo debo hacer antes de que T se comprometa?
 Que no tenga dependencias commit con otras transacciones.
 Evaluación:
o No se ponen restricciones sobre la forma de las transacciones ni sobre la
ejecución concurrente, solo sobre el orden de los commit.
o Pero se pierde ausencia de cascadas.
• ¿Qué hay que pedir para cada transacción T para garantizar

ausencia de cascadas?

• Para cada transacción T’ tal que T lee un elemento de datos
previamente escrito por T’, la operación comprometer de T’
debe aparecer antes de la operación read de T.
• Se pueden diseñar las transacciones con una organización
especial para garantizar la propiedad anterior. ¿Cómo se
puede hacer eso?

• Para cada transacción T’ tal que T lee un elemento de datos
previamente escrito por T’, la operación comprometer de T’
debe aparecer antes de la operación read de T.
• Se pueden diseñar las transacciones con una organización
especial para garantizar la propiedad anterior. ¿Cómo se
puede hacer eso?
• Una transacción es estructurada tal que sus escrituras son
todas realizadas al final de su procesamiento.
 Solución que garantiza la ausencia de cascadas

 Una transacción es estructurada tal que sus escrituras son todas
realizadas al final de su procesamiento.
 Todas las escrituras de una transacción forman una acción atómica
 i.e. ninguna otra transacción puede ejecutarse mientras una
transacción está escribiendo.
 ¿Qué se hace si una transacción no pudo hacer alguna de las
escrituras, al final?
 Solución que garantiza la ausencia de cascadas

 Una transacción es estructurada tal que sus escrituras son todas
realizadas al final de su procesamiento.
 Todas las escrituras de una transacción forman una acción atómica
 i.e. ninguna otra transacción puede ejecutarse mientras una
transacción está escribiendo.
 ¿Qué se hace si una transacción no pudo hacer alguna de las
escrituras, al final?
 La transacción aborta.
 Una transacción que aborta es reiniciada con una nueva marca
temporal.
Situación con protocolo de ordenación por
marcas temporales
 Evaluación: El protocolo de la filmina anterior:
 Garantiza secuencialidad por conflictos, recuperabilidad y ausencia de
cascadas.
 Hay una fase de escritura al final, donde se deben chequear que se
pueden hacer las escrituras y sino se retrocede la transacción.
 ¿Cuáles son algunas desventajas de este protocolo?
marcas temporales
 Evaluación: El protocolo de la filmina anterior:
 Garantiza secuencialidad por conflictos, recuperabilidad y ausencia de
cascadas.
 Hay una fase de escritura al final, donde se deben chequear que se
pueden hacer las escrituras y sino se retrocede la transacción.
 ¿Cuáles son algunas desventajas de este protocolo?
1. Hace falta chequear que se puede hacer cada lectura y sino se retrocede
la transacción.
2. Se tiene una sobrecarga por manejar marcas temporales sobre
elementos de datos.
 Consecuencias:
 El primer problema hace que el protocolo ande peor que uno basado en
bloqueos (i.e. abortar es en principio peor que esperar).
marcas temporales
• Meta: encontrar un protocolo basado en marcas temporales
donde:
– Se tengan los beneficios de la versión con ausencia de cascadas del
protocolo anterior.
– Las transacciones tengan la forma de de ese protocolo en el sentido
del orden de las instrucciones read y write (todos los write al final).
– Que los read siempre se puedan ejecutar con éxito.
– La sobrecarga por guardar y mantener información de marcas
temporales disminuya significativamente.
marcas temporales
• Idea: siempre permitir los read y antes de hacer los
write comprobar que no se vaya a violar la
secuencialidad por conflictos.
– Para hacer esa comprobación tener cierta información del
estado del sistema que es información sobre las
transacciones de la planificación.
• Solución: protocolo basado en validación.
Protocolo basado en validación
• Protocolo basado en validación: ¿Qué fases tenemos en la
ejecución de una transación Ti ?
• Protocolo basado en validación: ¿Qué fases tenemos en la
ejecución de una transación Ti ?
1. Fase de lectura y ejecución: Se leen los valores de varios elementos
de datos. La transacción Ti escribe sólamente en las variables locales
temporales.
2. Fase de validación: La transacción Ti realiza una “prueba de
validación'' para determinar si las variables locales pueden ser
escritas sin violar la secuencialidad.
3. Fase de escritura: Si Ti fue validada exitosamente, las actualizaciones
son aplicadas a la base de datos; de otro modo, Ti es retrocedida.
• Las tres fases de ejecutar concurrentemente transacciones
pueden ser entrelazadas, pero cada transacción debe ir por
las tres fases en ese orden.
• Protocolo basado en validación (continuación): Cada

transacción Ti tiene 3 marcas temporales:
 Start(Ti): el tiempo cuando Ti comenzó con su ejecución.
 Validation(Ti): el tiempo cuando Ti entró en su fase de
validación.
 Finish(Ti): el tiempo cuando Ti terminó con su fase de escritura.
• El Orden de secuencialidad es determinado por las marcas
temporales dadas en el tiempo de validación, para aumentar
la concurrencia.
– Así, a TS(Ti) se le da el valor de Validation(Ti).
Prueba de validación para la transacción Tk
• ¿Para hacer la validación de Tk qué transacciones

tengo que mirar? ¿O sea, con cuáles transacciones
podría haber arcos en el grafo de precedencia?
• ¿Para hacer la validación de Tk qué transacciones

tengo que mirar? ¿O sea, con cuáles transacciones
podría haber arcos en el grafo de precedencia?
• Con aquellas transacciones Ti con TS (Ti) < TS (Tk) que
hicieron su fase de escritura.
• ¿Qué puedo pedir para esas transacciones para que
la validación pase con éxito? Ayuda: hacer un
análisis de casos comparando finish(Ti) comparando
con marcas temporales de Tk.
 Prueba de Validación: Si para todo Ti con TS (Ti) < TS (Tk) una
de las siguientes condiciones vale:
 finish(Ti) < start(Tk).
 start(Tk) < finish(Ti) < validation(Tk) y el conjunto de ítems
de datos escritos por Ti no se interseca con el conjunto de
ítems de datos leídos por Tk.
 Si si cumple la condicón anterior, entonces la validación tiene
éxito y Tk puede ser comprometida.
 De otro modo, la validación falla y T es abortada
k
 Sea P la propiedad que dice que todos los arcos en el grafo de
precedencia son de la forma:
 Entonces no va a haber ciclos en el grafo de precedencia.

 Teorema: Sea S una planificación legal bajo el protocolo basado en
validación. Entonces S es secuenciable por conflictos y se pueden
ordenar las transacciones según sus marcas temporales de menor
a mayor.
Prueba: Supongamos que: (*) Ii (Q), …, Ik (Q) en S, Ii (Q) entra en
conflicto con Ik (Q).
Vamos a hacer una prueba por el absurdo. Supongamos que MT(Ti) >
MT(Tk) en S. Entonces Tk validó en S con éxito antes de que Ti validó
con éxito en S. Entonces al momento de la validación de Ti con éxito se
cumple una de las siguientes condiciones:
1.finish(Tk) < start(Ti)
2.start(Ti) < finish(Tk) < validation(Ti) and el conjunto de ítems
de datos escritos por Tk no se interseca con el conjunto de
ítems de datos leídos por Ti.
Si se da el primer caso, se contradice la suposición inicial (*), porque
no se puede tener en S una instrucción de Ti antes que una instrucción
de Tk .
Si se da el segundo caso:
• ri(Q), …, wk(Q) queda descartado, por la segunda parte de la
condición del item 2.
• wi(Q), …, wk(Q) queda descartado, por la primera parte de la
• wi(Q), …, rk(Q) queda descartado, por la primera parte de la
Por lo tanto se contradice la suposición inicial (*) y se tiene un
absurdo.
Q.E.D
 Ejemplo de planificación producida usando validación
• Notación a usar al construir planificaciones:

o Para cada transacción hay una columna donde se expresan
sus marcas temporales. En la columna para la transacción
Ti:
 S = X significa que Start(Ti) = X
 V = X significa que Validation(Ti) = X
 F = X significa que Finish(Ti) = X, y
 Not exists S; V: significa que debido a que Ti se retrocedió, dejan
de existir Inicio(Ti) y validación(Ti).
• Ejercicio: Sean las transacciones:

T1 : st; r(A); r(B); V; w(C)
T2 : st; r(B); r(C); V; w(A)
T3 : st; r(C); r(D); V; w(D)
o st significa que la transacción comienza.
o Además V significa intentar validar.
o retr. se usa para decir que se retrocede la transacción.
• Construir una planificación para esas transacciones
Protocolo
basado en
validación
• ¿Puede haber retrocesos en cascada con el protocolo

basado en validación?
• ¿Puede haber retrocesos en cascada con el protocolo

basado en validación?
• El esquema de validación evita automáticamente los retrocesos
en cascada, ya que las escrituras reales tienen lugar solo
después de que la transacción que ejecuta la escritura se haya
comprometido.
marcas temporales
Conclusiones:
• Los protocolos basados en marcas temporales tienen una
desventaja en relación a los protocolos basados
bloqueos:
 Puede ser necesario retroceder una transacción aun cuando no ocurren
interbloqueos y hay ausencia de cascadas
• Pero en ellos las transacciones no tienen que esperar y no
ocurren Interbloqueos y la sobrecarga de almacenamiento es
bastante menor.

Capítulo 7: Control de Concurrencia - Parte 2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Capítulo 7: Control de Concurrencia - Parte 2

Cargado por

Copyright:

Formatos disponibles

Capítulo 7

Control de Concurrencia – Parte 2

 Por lo tanto en el grafo de precedencia no va a haber ciclos y la

 Así no hay ciclos en el grafo de precedencia y la planificación será

 Así, no va a haber ciclos en el grafo de precedencia.

 Suponga que la transacción Ti emite read(Q)

 Suponga que la transacción Ti emite read(Q)

 ¿Con el protocolo de ordenación por marcas temporales puede

 El protocolo de ordenación por marcas temporales asegura ausencia de

• ¿Para garantizar recuperabilidad qué debemos pedir para

• ¿Para garantizar recuperabilidad qué debemos pedir para

• ¿Para garantizar recuperabilidad qué debemos pedir para

 Solución para garantizar recuperabilidad (solamente)

 Solución para garantizar recuperabilidad (solamente)

 Solución para garantizar recuperabilidad (solamente)

 Solución para garantizar recuperabilidad (solamente) - continuación

 Solución para garantizar recuperabilidad (solamente) - continuación

 Solución para garantizar recuperabilidad (solamente) - continuación

• ¿Qué hay que pedir para cada transacción T para garantizar

• ¿Qué hay que pedir para cada transacción T para garantizar

• ¿Qué hay que pedir para cada transacción T para garantizar

 Solución que garantiza la ausencia de cascadas

 Solución que garantiza la ausencia de cascadas

• Protocolo basado en validación (continuación): Cada

• ¿Para hacer la validación de Tk qué transacciones

• ¿Para hacer la validación de Tk qué transacciones

 Entonces no va a haber ciclos en el grafo de precedencia.

• Notación a usar al construir planificaciones:

• Ejercicio: Sean las transacciones:

• ¿Puede haber retrocesos en cascada con el protocolo

• ¿Puede haber retrocesos en cascada con el protocolo

También podría gustarte