Affidabilità e Concorrenza

Transcript

1 Affidabilità e Concorrenza Affidabilità Resistenza ai guasti Concorrenza Efficienza: più transazioni contemporanee Senza introdurre fenomeni indesiderati 2

2 Transazione Unità elementare di lavoro Ben formata: Sequenza di operazioni tra inizio (begin) e fine (commit o abort) Necessaria la concorrenza per avere transazioni in parallelo. 3

3 Lost update Transazione t1 r1(x) x = x + 1 w1(x) commit Transazione t2 r2(x) x = x + 1 w2(x) commit 4

4 Dirty read Transazione t1 r1(x) x = x + 1 w1(x) abort Transazione t2 r2(x) commit 5

5 Letture inconsistenti Transazione t1 r1(x) r1(x) commit Transazione t2 r2(x) x = x + 1 w2(x) commit 6

6 Aggiornamento fantasma Transazione t1 r1(x) r1(y) commit Transazione t2 r2(x) r2(y) x = x + 1 y = y - 1 w2(x) w2(y) commit 7

7 A. Ricerca di anomalie Indicare se le sequenze di operazioni possono produrre anomalie; i simboli c i e a i indicano l'esito (commit o abort) della transazione i. 8

8 A.1 r 1 (x) w 1 (x) r 2 (x) w 2 (y) a 1 c 2 Lettura Sporca: r 1 (x) w 1 (x) r 2 (x) w 2 (y) a 1 c 2 t 2 legge uno stato che non dovrebbe essere esposto, poiché t 1 si conclude con un abort. 10

9 A.2 r 1 (x) w 1 (x) r 2 (y) w 2 (y) a 1 c 2 Nessuna anomalia 12

10 A.3 r 1 (x) r 2 (x) r 2 (y) w 2 (y) r 1 (z) a 1 c 2 Nessuna anomalia 14

11 A.4 r 1 (x) r 2 (x) w 2 (x) w 1 (x) c 1 c 2 Perdita di aggiornamento r 1 (x) r 2 (x) w 2 (x) w 1 (x) c 1 c 2 L effetto di t 2 è sovrascritto e annullato da t 1, ma nessuna delle due transazioni legge valori inconsisenti 16

12 A.5 r 1 (x) r 2 (x) w 2 (x) r 1 (y) c 1 c 2 Nessuna anomalia 18

13 A.6 r 1 (x) w 1 (x) r 2 (x) w 2 (x) c 1 c 2 Nessuna anomalia 20

14 Controllo di concorrenza Schedule: Sequenza di operazioni r/w Scheduler: Accetta gli schedule che non generano errori e rifiuta gli altri Ipotesi [forte]: sappiamo già il risultato delle operazioni e rimuoviamo gli abort (commit-proiezione) 21

15 Schedule seriali e serializzabili Schedule seriali: azioni di ciascuna transazione in sequenza Schedule corretto se ha lo stesso risultato di uno schedule seriale: serializzabile. 22

16 Metodologie di controllo Teorici: View-serializzabilità (VSR) Conflict-serializzabilità (CSR) Pratici: Locking a due fasi (2PL) Timestamp (TS Singolo, TS Multi) 23

17 Metodologie di controllo VSR CSR 2PL TS 24

18 View-Serializzabile VSR Stesse scritture finali e legge-da di un qualsiasi altro schedule seriale. w0(x) r2(x) r1(x) w2(x) w2(z) w0(x) r1(x) r2(x) w2(x) w2(z) 25

19 B.1 Classificare il seguente schedule come non-vsr, VSR o CSR: r 1 (x) r 2 (y) w 3 (y) r 5 (x) w 5 (u) w 3 (s) w 2 (u) w 3 (x) w 1 (u) r 4 (y) w 5 (z) r 5 (z) 26

20 Consideriamo le operazioni relative a ogni risorsa separatamente S: w 3 U: w 5 w 2 w 1 X: r 1 r 5 w 3 Y: r 2 w 3 r 4 Z: w 5 r 5 27

21 Costruzione Grafo Conflitti CSR Ogni nodo è una transazione Un arco orientato per ogni conflitto di tipo: read / write write / write write / read I CONFLITTI SI GENERANO ANCHE SE LE AZIONI NON SONO CONSECUTIVE 28

22 Consideriamo le operazioni relative a ogni risorsa 1 4 separatamente S: w U: w 5 w 2 w 1 X: r 1 r 5 w 3 Y: r 2 w 3 r 4 Z: w 5 r 5 Si verifica dapprima l appartenenza a CSR: il grafo dei conflitti è aciclico: lo schedule è CSR (e quindi anche VSR) 30

23 Supponendo di aggiungere lo schedule r 2 (u) w 2 (s) come prefisso oppure come suffisso dello schedule precedente, classificare i due schedule risultanti. Aggiungiamolo come prefisso: r 2 (u) w 2 (s) r 1 (x) r 2 (y) w 3 (y) r 5 (x) w 5 (u) w 3 (s) w 2 (u) w 3 (x) w 1 (u) r 4 (y) w 5 (z) r 5 (z) 31

24 S: w 2 w 3 U: r 2 w 5 w 2 w X: r 1 r 5 w Y: r 2 w 3 r 4 Z: w 5 r 5 5 Il prefisso introduce 4 nuovi conflitti, dei quali uno solo causa un nuovo arco nel grafo, che diventa ciclico. Lo schedule NON è CSR. Sarà VSR? 32

25 S: w 2 w 3 U: r 2 w 5 w 2 w 1 X: r 1 r 5 w 3 Y: r 2 w 3 r 4 Z: w 5 r 5 Lo schedule (seriale) S = t 2, t 5, t 1, t 3, t 4 ha le stesse legge-da e scritture finali, quindi lo schedule è VSR. Ma come individuare S a occhio? 33

26 Definizione: una scrittura w i (X) si dice cieca se non è l ultima azione sulla risorsa X e l azione successiva su X è una scrittura [w j (X)] Proprietà: ogni schedule S tale che S VSR ma S CSR ha, nel grafo dei conflitti, cicli a cui concorrono archi che corrispondono a coppie di scritture cieche. Tali scritture possono essere invertite senza impatto sulla relazione legge-da e sulle scritture finali (ma con l effetto di invertire un arco nel grafo dei conflitti). Con questi scambi si può rendere aciclico il grafo, e si può ispezionarlo per individuare uno schedule seriale view-equivalente a quello iniziale. 34

27 S: w 2 w 3 U: r 2 w 5 w 2 w 1 X: r 1 r 5 w 3 Y: r 2 w 3 r 4 Z: w 5 r Il grafo precedente può essere reso aciclico operando uno scambio tra due scritture cieche S: w 2 w 3 U: r 2 w 2 w 5 w 1 X: r 1 r 5 w 3 Y: r 2 w 3 r 4 Z: w 5 r

28 Lo schedule seriale S =t, t, t, t, t, indicato in precedenza, si può riconoscere corrispondente ad un cammino che tocca tutti i nodi del grafo dei conflitti dello schedule modificato. Ora mettiamo r 2 (u) w 2 (s) come suffisso: r (x) r (y) w (y) r (x) w (u) w (s) w (u) w (x) w (u) r (y) w (z) r (z) r 2 (u) w 2 (s) 37

29 S: w 3 w 2 U: w 5 w 2 w 1 r X: r 1 r 5 w 3 Y: r 2 w 3 r 4 Z: w 5 r Il nuovo grafo è ciclico: lo schedule NON è CSR Sarà VSR? 38

30 S: w 3 w 2 U: w 5 w 2 w 1 r 2 X: r 1 r 5 w 3 Y: r 2 w 3 r 4 Z: w 5 r 5 Non è VSR infatti è piuttosto evidente che non è possibile decidere se t 2 debba precedere o seguire t 3 : nel primo caso w 2 (s) non sarebbe più finale, nel secondo caso si introdurrebbe una relazione r 2 (y) legge-da w 3 (y) non presente nello schedule da classificare. 39

31 S: w 3 w 2 U: w 5 w 2 w 1 r 2 X: r 1 r 5 w 3 Y: r 2 w 3 r 4 Z: w 5 r 5 Oppure basta considerare il sotto-schedule w 2 (u) w 1 (u) r 2 (u): nessuno schedule seriale potrà mai preservare la relazione r 2 (u) leggeda w 1 (u) evidenziata dalla freccia, poiché ogni schedule seriale avrà w 2 (u) e r 2 (u) adiacenti. 40

32 B.2 Classificare il seguente schedule come non-vsr, VSR o CSR: r 1 (x) r 4 (x) w 4 (x) r 1 (y) r 4 (z) w 4 (z) w 3 (y) w 3 (z) w 2 (t) w 2 (z) w 1 (t) w 5 (t) Se possibile, aggiungere e togliere una azione in modo da far cambiare classe allo schedule. 41

33 T: w 2 w 1 w 5 X: r 1 r 4 w 4 Y: r 1 w 3 Z: r 4 w 4 w 3 w Il grafo è ciclico (1,4,2 1,3,2 1,4,3,2). 2,1 è l unico arco comune a tutti e tre i cicli Lo schedule non è CSR sarà VSR? 43

34 T: w 2 w 1 w 5 X: r 1 r 4 w 4 Y: r 1 w 3 Z: r 4 w 4 w 3 w 2 Si riconosce agevolmente che lo schedule (seriale) t 1, t 4, t 3, t 2, t 5 è view-equivalente allo schedule dato, che quindi è VSR. Lo schedule seriale si intuisce a occhio, oppure si costruisce, ad esempio, notando che lo scambio tra w 2 (t) e w 1 (t) rende aciclico il grafo dei conflitti. 44

35 Togliendo l ultima operazione dello schedule [w 5 (t)] si ottiene l effetto di renderlo non-vsr (infatti w 1 (t) diventa finale per t, e non si può più agire sul grafo per derivarne uno aciclico, relativo a uno schedule diverso ma view-equivalente a quello dato). Alternativamente si può aggiungere, ad esempio, r 5 (t) subito prima di w 1 (t), ottenendo lo stesso effetto. Togliendo w 1 (t), invece, lo schedule diventa CSR. 45

36 B.3 Classificare il seguente schedule come non-vsr, VSR o CSR: r 4 (x) r 2 (x) w 4 (x) w 2 (y) w 4 (y) r 3 (y) w 3 (x) w 4 (z) r 3 (z) r 6 (z) r 8 (z) w 6 (z) w 9 (z) r 5 (z) r 10 (z) 46

37 Costruiamo il grafo dei conflitti X: r 4 r 2 w 4 w 3 Y: w 2 w 4 r 3 Z: w 4 r 3 r 6 r 8 w 6 w 9 r 5 r Il grafo è aciclico: lo schedule è CSR (e quindi anche VSR). Il grafo suggerisce lo schedule seriale 2,4,3,8,6,9,5,10 (costruito scegliendo ed eliminando via via i nodi senza archi entranti). 49

38 B.4 Classificare il seguente schedule come non-vsr, VSR o CSR: w 4 (x) r 2 (x) w 2 (y) w 4 (y) w 3 (x) w 4 (z) r 3 (z) r 6 (z) r 8 (z) w 9 (z) w 5 (z) r 10 (z) 50

39 Costruiamo il grafo dei conflitti X: w 4 r 2 w 3 Y: w 2 w 4 Il grafo è ciclico (4, 2): lo schedule Z: w 4 r 3 r 6 r 8 w 9 w 5 r 10 non è CSR. 3 8 Non è nemmeno VSR (2 e 4 non 2 sono serializzabili: 9 r 2 (x) legge-da w 4 (x), ma w 4 (y) è finale). Del resto non esistono scritture cieche scambiabili. 53

40 B.5 Classificare il seguente schedule come non-vsr, VSR o CSR: r 5 (x) r 3 (y) w 3 (y) r 6 (t) r 5 (t) w 5 (z) w 4 (x) r 3 (z) w 1 (y) r 6 (y) w 6 (t) w 4 (z) w 1 (t) w 3 (x) w 1 (x) r 1 (z) w 2 (t) w 2 (z) 54

41 T: r 6 r 5 w 6 w 1 w 2 X: r 5 w 4 w 3 w 1 Y: r 3 w 3 w 1 r 6 Z: w 5 r 3 w 4 r 1 w Lo schedule non è CSR: sfrondando il grafo dai nodi 2 e 5 (che hanno solo archi in ingresso e in uscita rispettivamente) si vede bene che ci sono due cicli (6-1 e 4-3). Il conflitto 4-3 può essere rimosso se si considera lo schedule viewequivalente a quello dato ottenibile per scambio di w 4 (x) e w 3 (x). Non è invece eliminabile il conflitto 6-1: lo scambio di w 6 (t) e w 1 (t) non elimina il conflitto dovuto a r 6 (t). Quindi lo schedule non appartiene neanche a VSR. 57

42 C.1 Verificare se la seguente sequenza di operazioni è compatibile con il protocollo di locking a due fasi: r 1 (A) r 2 (B) w 1 (C) r 2 (A) r 1 (B) w 2 (C) r 3 (C) w 2 (B) r 3 (B) w 1 (A) w 3 (A) 58

43 Vincoli temporali sulle richieste di lock/unlock (quando si rendano necessarie delle attese) Numeriamo progressivamente gli istanti in cui avvengono le azioni Otteniamo un sistema di disequazioni Approccio necessario : il 2PL non strict non permette di conoscere con precisione i momenti di rilascio (è invece possibile con il 2PL strict) 59

44 Istante A B C 1 r1 2 r2 3 w1 4 r2 5 r1 6 w2 7 r3 8 w2 9 r3 10 w1 11 w3 Diagrammiamo lo schedule separando le azioni in base alla risorsa a cui si riferiscono 60

45 Istante A B C 1 r1 2 r2 3 w1 4 r2 5 r1 6 w2 7 r3 8 w2 9 r3 10 w1 11 w3 Dal comportamento di t 2 derivano i seguenti vincoli 4 < U r 2 A < L w 1 A U r 1 B < L w 2 B < 8 Interpretiamoli... 61

46 Istante A B C 1 r1 2 r2 3 w1 4 r2 5 r1 6 t w2 1 non può acquisire presto A 7 r3 8 w2 9 r3 10 w1 11 w3 Né rilasciare tardi B Dal comportamento di t 2 derivano i seguenti vincoli 4 < U r 2 A < L w 1 A U r 1 B < L w 2 B < 8 62

47 Istante A B C 1 r1 2 r2 3 w1 4 r2 5 r1 6 w2 7 r3 t 2 non può rilasciare 8 w2 9 tardi A r3 10 w1 11 w3 Né acquisire presto B Dal comportamento di t 2 derivano i seguenti vincoli 4 < U r 2 A < L w 1 A U r 1 B < L w 2 B < 8 63

48 Istante A B C 1 r1 2 r2 3 w1 4 r2 5 r1 6 w2 7 r3 8 w2 9 r3 10 w1 11 w3 4 < U r 2 A < L w 1 A U r 1 B < L w 2 B < 8 Inoltre il 2PL impone di non acquisire alcun lock dopo il primo rilascio: L w 1 A < U r 1 B L w 2 B < U r 2 A Componendo i vincoli: U A < L A < U B < L B < U A Non esiste alcun assegnamento che li soddisfi: lo schedule non è compatibile con il 2PL. 64

49 Istante A B C 1 r1 2 r2 3 w1 4 r2 5 r1 6 w2 7 r3 8 w2 9 r3 10 w1 11 w3 DEL RESTO LO SCHEDULE NON È NEMMENO SERIALIZZABILE! Sia iniziando con t 1 sia iniziando con t 2 si introducono legge-da non presenti nello schedule iniziale. 65

50 C.2 Verificare se la seguente sequenza di operazioni è compatibile con il protocollo di locking a due fasi: r 1 (A), r 2 (B), w 1 (C), r 2 (A), r 1 (B), w 2 (C), r 3 (C), w 2 (B), r 3 (B), w 2 (A), w 3 (A) 66

51 Istante A B C 1 r1 2 r2 3 w1 4 r2 5 r1 6 w2 7 r3 8 w2 9 r3 10 w2 11 w3 t 1 può acquisire tutti i lock all inizio e rilasciare ogni risorsa subito dopo l uso. t 3 può acquisire ogni risorsa subito prima dell uso e rilasciarle tutte alla fine. t 2 deve rilasciare (C) già tra 6 e 7, e non può acquisire (B) prima di 6, ma questo è possibile. 67

52 C.3 Si consideri il seguente schedule, in cui l'identificativo di una transazione rappresenta il timestamp della stessa: r 4 (x) r 2 (x) w 4 (x) w 2 (y) w 4 (y) r 3 (y) w 3 (x) w 4 (z) r 3 (z) r 6 (z) r 8 (z) w 6 (z) w 9 (z) r 5 (z) r 10 (z) Si assuma inizialmente RTM = WTM = 0 per ogni risorsa. Discutere il comportamento del sistema con controllo di concorrenza basato su timestamp mono-versione (a) e multi-versione (b). Infine, si classifichi lo schedule. 68

53 Rappresentiamo l evoluzione del sistema con una tabella che mostri: (a) monoversione: Il valore dei due indicatori associati a ciascuna risorsa e le transazioni uccise (b) multiversione: Il valore di RTM e tutti i valori di WTM i di ogni risorsa, oltre alle transazioni uccise. Per ogni lettura indichiamo anche (tra parentesi) il timestamp della versione effettivamente letta. 69

54 X Y Z RTM WTM RTM WTM RTM WTM T uccisa R4(x) R2(x) 4 W4(x) 4 W2(y) 2 W4(y) 4 R3(y) 3 ( 3 < WTM(y)=4 ) W3(x) (già uccisa) W4(z) 4 R3(z) (già uccisa) R6(z) 6 R8(z) 8 W6(z) 6 ( 6 < RTM(z)=8 ) W9(z) 9 R5(z) 5 ( 5 < WTM(z)=9 ) R10(z) 10 70

55 X Y Z RTM WTM(i) RTM WTM(i) RTM WTM(i) T uccisa R4(x) 4 (0) R2(x) 4 (0) W4(x) 0, 4 W2(y) 0, 2 W4(y) 0, 2, 4 R3(y) 3 (2) W3(x) 3 ( 3 < RTM(x)=4 ) W4(z) 0, 4 R3(z) (già uccisa) R6(z) 6 (4) R8(z) 8 (4) W6(z) 6 ( 6 < RTM(z)=8 ) W9(z) 0, 4, 9 R5(z) 8 (4) R10(z) 10(9) 71

56 C.4 Si consideri il seguente schedule, in cui l'identificativo di una transazione rappresenta il timestamp della stessa: w 4 (x) r 2 (x) w 2 (y) w 4 (y) w 3 (x) w 4 (z) r 3 (z) r 6 (z) r 8 (z) w 9 (z) w 5 (z) r 10 (z) Si assuma inizialmente RTM = WTM = 0 per ogni oggetto. Discutere il comportamento del sistema con controllo di concorrenza basato su timestamp mono-versione e multi-versione. 72

57 X Y Z RTM WTM RTM WTM RTM WTM T uccisa W4(x) R2(x) 2 ( 2 < WTM(x)=4 ) W2(y) (già uccisa) W4(y) 4 W3(x) 3 ( 3 < WTM(x)=4 ) W4(z) 4 R3(z) (già uccisa) R6(z) 6 R8(z) 8 W9(z) 9 W5(z) 5 ( 5 < WTM(z)=9 ) R10(z) 10 73

58 X Y Z RTM WTM i RTM WTM i RTM WTM i W4(x) 0 0, R2(x) 2 (0) W2(y) 0, 2 W4(y) 0, 2, 4 T uccisa W3(x) 0, 3, 4 [un sistema reale probabilmente ucciderebbe t3] W4(z) 0, 4 R3(z) 3 (0) R6(z) 6 (4) R8(z) 8 (4) W9(z) 0, 4, 9 W5(z) 5 (5< RTM(z)=9 =8 ) R10(z) 10(9) 74

59 D.1 Si assuma che L r i X (L w i X ) rappresenti una richiesta di lock in lettura (scrittura) da parte della transazione i sulla risorsa X. Sia data la sequenza di richieste di lock: L r 1 A L r 2 A L w 3 B L r 4 C L w 2 D L w 3 A L w 1 C L w 5 E L r 5 D L r 4 E Si verifichi se la sequenza di richieste di lock porta ad una situazione di blocco critico. 75

60 Costruiamo un grafo in cui l arco i,j indica che t i aspetta un rilascio da t j L r 1 A L r 2 A L w 3 B L r 4 C L w 2 D L w 3 A L w 1 C L w 5 E L r 5 D L r 4 E L aciclicità del grafo garantisce l assenza di deadlock. t 2 può terminare per prima, poi nel ordine t 5, t 4, t 1, t 3 76

61 D.2 Si verifichi che la sequenza di richieste di lock porta ad una situazione di blocco critico. L r 1 A L r 2 A L w 3 B L w 3 A L r 4 C L w 2 A L r 1 B L w 5 E L r 5 B L r 4 E Si individui inoltre quale transazione può essere fatta terminare per rimuovere la situazione di blocco. 77

62 L r 1 A L r 2 A L w 3 B L w 3 A L r 4 C L w 2 A L r 1 B L w 5 E L r 5 B L r 4 E Il grafo è ciclico. C è un deadlock tra le transazioni t 1, t 2 e t 3, che si può risolvere uccidendo t 3 (non t 2 [t 1 ], ché rimarrebbe il ciclo tra t 1 e t 3 [tra t 2 e t 3 ]) 78