TP-systemes-concurrents/TP7/reponses.md

Scénario 1

Quelles seront les transactions validées, bloquées ou abandonnées ?

TMPP

• Transaction T1 annulée (ft1 == 0), car il essaie de read y à la date 5 alors que celui-ci est lock par T2 à la date 4.
• Transaction T2 annulée (ft2 == 0), car il essaie de write z à la date 7 alors que celui-ci est lock par T3 à la date 6.
• Transaction T3 validée (ft3 == 1), T1 et T2 ayant été annulés, T3 n'a pas de problème pour terminer sa transaction.

TMPC

• Transaction T1 validée (ft1 == 1)
• Transaction T2 validée (ft2 == 1)
• Transaction T3 annulée (ft3 == 0), car T3 la valeur de z est modifié entre son read par T3 à la date 6 et son commit date 16, par T2 à la date 7.

TM2PL

• Transaction T1 validée (ft2 == 1)
• Transaction T2 validée (ft2 == 1)
• Transaction T3 validée (ft3 == 1)

Il n'y a pas d'interblocages, donc la politique de verouillage à deux phases fait se terminer toutes les transactions de l'exemple.

Quelles seront les valeurs de variables affichées par la commande list ?

TMPP

T_objets :
ft1 0
ft3 1
ft2 0
x 3
y 0
z 0

TMPC

T_objets :
ft1 1
ft3 0
ft2 1
x 0
y 1
z 2

TM2PL

T_objets :
ft1 1
ft3 0
ft2 1
x 0
y 1
z 2

Scénario 2

Quelles seront les transactions validées, bloquées ou abandonnées ?

TMPP

Transaction T1 validée (ft1 == 1), T2 et T3 ayant été annulés, T3 n'a pas de problème pour terminer sa transaction. Transaction T2 annulée (ft2 == 0), car il essaie de write z à la date 7 alors que celui-ci est lock par T3 à la date 6. Transaction T3 annulée (ft3 == 0), car il essaie de write x à la date 10 alors que celui-ci est lock par T1 à la date 5.

TMPC

• Transaction T1 validée (ft1 == 1).
• Transaction T2 validée (ft2 == 1).
• Transaction T3 annulée (ft3 == 0), car la valeur de z est modifié entre son read par T3 à la date 6 et son commit date 16, par T2 à la date 7.

TM2PL

• Transaction T1 bloqué (ft2 == 0)
• Transaction T2 bloqué (ft2 == 0)
• Transaction T3 bloqué (ft3 == 0)

Il y a interblocages.

Quelles seront les valeurs de variables affichées par la commande list ?

TMPP

T_objets :
ft1 1
ft3 0
ft2 0
x 0
y 0
z 0

TMPC

T_objets :
ft1 1
ft3 0
ft2 1
x 0
y 1
z 2

TM2PL

T_objets :
ft1 0
ft3 0
ft2 0
x 0
y 1
z 0

Illustrer la limite de la propagation directe sur un scénario simple, interprété par le shell.

init TM2PL (x,0) (ft1,0) (ft2,0) (ft3,0)
new T1 ; new T2 ; new T3

T1 write x 1
T2 read x
T1 write x 2
T3 read x

T1 write ft1 1 ; T1 commit
T2 write ft2 1 ; T2 commit
T3 write ft3 1 ; T3 commit

À la fin de ces transaction, à cause de la propagation directe, T2 et T3 n'aurons pas lu la même valeur de x, et cela peut causer des comportements inattendus.

Évaluation de protocoles

Commenter les scénarios fournis

Scénario 1

Transaction t1 validée
0 unités de temps perdues
44  unités de temps attendues
26 unités de temps utiles
Transaction t2 validée
0 unités de temps perdues
19  unités de temps attendues
31 unités de temps utiles
Transaction t3 validée
0 unités de temps perdues
0  unités de temps attendues
33 unités de temps utiles

Temps total : 70
Temps optimal : 33
Temps séquentiel : 90

Scénario 2

Transaction t1 validée
0 unités de temps perdues
0  unités de temps attendues
26 unités de temps utiles
Transaction t2 validée
0 unités de temps perdues
0  unités de temps attendues
31 unités de temps utiles
Transaction t3 annulée
33 unités de temps perdues
0  unités de temps attendues
0 unités de temps utiles

Temps total : 33
Temps optimal : 33
Temps séquentiel : 90

Scénario 3

Transaction t1 validée
0 unités de temps perdues
0  unités de temps attendues
26 unités de temps utiles
Transaction t2 validée
0 unités de temps perdues
0  unités de temps attendues
31 unités de temps utiles
Transaction t3 validée
33 unités de temps perdues
0  unités de temps attendues
33 unités de temps utiles

Temps total : 66
Temps optimal : 33
Temps séquentiel : 90

Le scénario 2 est plus rapide que le scénario 1, puisque ses transactions n'attendent pas les autres, cependant la transaction T3 échoue. Le scénario 3 est plus rapide que le scénario 1, ceci est dû à l'utilsation de super-transactions, en effet la transaction T3 du scénario 2 est rejoué à la fin des transaction T1 et T2.

Définir des scénarios permettant de caractériser les situations favorables à chacune des politiques

TODO

Mise en œuvre des protocoles de contrôle de concurrence

Indiquer (et justifier) pour chacun de ces protocoles

A

• optimiste, les modifications sont écrites sur la mémoire principale et "undo" si la transaction abort
• l'algorithme est optimiste, il peut ne pas assurer la sérialisabilité
• différée, les locks ne sont libérés qu'à la toute fin
• Il y a risque d'interblocage
• Il y a risque de rejet en cascade

B

• pessimiste, les modificatison des transactions sont effectuées dans une mémoire à part, et transférée vers la mémoire principale lors du commit.
• l'algorithme est pessimiste, il assure la sérialisabilité
• différée, puisque le protocole est pessimiste
• Il n'y a pas de risque d'interblocage
• Il n'y a pas risque de rejet en cascade