6.6 Regioni Critiche Condizionali. 6.9 Transazioni Atomiche Modello del Sistema Transazionale

Transcript

1 Regioni Critiche Condizionali 6.7 Monitor Costrutti linguistici inventati per evitare i problemi di programmazione che facilmente si fanno con i semafori Attenzione con i thread: in tale ambiente ci sono in genere solo semafori o poco più Li vedrete nel prossimo corso 6.9 Transazioni Atomiche 46 Mutua esclusione esecuzione indivisibile di sezioni critiche Transazione Atomica =:= transazione indivisibile che avviene completamente oppure non avviene affatto non sono osservabili stati intermedi se non può essere completata con successo, lascia il mondo inalterato È un concetto del mondo dei data base, ma utile nei SO i SO possono fornire le primitive per realizzarle Modello del Sistema Transazionale Transazione =:= funzione logica costituita da molteplici operazioni, fra le quali interessano read/write commit/abort abort causato dal SO o dall hardware (crash!) Quando la transazione abortisce bisogna ripristinare lo stato come prima dell inizio della transazione roll-back. È compito del sistema transazionale (SO+ambiente specifico) realizzare il roll-back. 47 1

2 48 Proprietà delle Memorie Volatile: si perde per crash (ad es RAM) Non volatile: sopravvive ai crash (EEPROM, dischi, nastri, etc) ma ha comunque una significativa probabilità di perdita Stabile: non si perde mai (quasi, mai apprezzabilmente) 49 Problematiche replicare l'informazione, scriverla e modificarla in modo appropriato realizzare transazioni atomiche in un ambiente in cui ci può essere perdita di informazione su memoria volatile (cioè la memoria volatile non è considerata sufficiente) recuperare l info in modo appropriato Ripristino Basato su Log Log =:= registrazione (non logaritmo!) registrare su memoria stabile tutte le modifiche fatte dalla transazione ai dati (che in genere vengono tenuti su memoria non volatile) Write-ahead logging: ogni record contiene nome della transazione nome del dato vecchio valore nuovo valore 2

3 Ripristino Basato su Log Record per registrare inizio, commit, abort di transazione Il log record di write viene scritto prima di fare la write due write al posto di una! due procedure undo(t i ) e redo(t i ) che si basano sul log. Sono ambedue idempotenti Ripristino Basato su Log Se il log contiene < T i start> e < T i commit> e la memoria non volatile si è perduta redo(t i ) Se il sistema ha un crash allora se esiste < T i start> ma non esiste < T i commit> undo(t i ) se esistono ambedue < T i start> e < T i commit> redo(t i ) Checkpoint Possibile che ad ogni crash dobbiamo rifare tutte le transazioni eseguite dal crash precedente? No! Checkpoint =:= punto di verifica tutti i record di log da memoria volatile a memoria stabile tutti i dati da memoria volatile a memoria stabile emettere un log record <checkpoint> sul log in memoria stabile 3

4 Checkpoint Ci si comporta poi così: 1. Ad ogni crash si esamina il log cercando dal fondo (all indietro) l ultimo record di <checkpoint> che vi si trova 2. A partire da tale record di checkpoint si trova all indietro (prima di tale ultimo <checkpoint>) la più recente T i che è partita prima del checkpoint la prima < T i start> che si trova leggendo all indietro il file di log Checkpoint Nota bene: l ipotesi è che nel sistema si esegua una transazione alla volta 3. Si legge in avanti il file di log facendo undo o redo di tutte le transazioni che si trovano, come nel caso che non si utilizzi il checkpoint Transazioni Atomiche 56 Devono godere della proprietà di serializzabilità =:= l effetto finale complessivo ottenuto deve essere identico all effetto che si sarebbe ottenuto con uno degli ordini di esecuzioni seriale possibili abbiamo un problema di mutua esclusione e sezioni critiche Utilizzare un unico semaforo è troppo restrittivo poco parallelismo 4

5 6.9.4 Transazioni Atomiche Il parallelismo massimo dipende dal modo con cui i dati vengono usati nelle transazioni Serial schedule di due transazioni =:= ognuna delle due transazioni è eseguita in modo atomico, senza parallelismo T 0 T 1 read(a) - write(a) - read(b) - write(b) - - read(a) - write(a) - read(b) - write(b) Transazioni Atomiche 58 Se dobbiamo eseguire n transazioni abbiamo n! possibili serial schedule Ci interessano le schedule non seriali, che però siano equivalenti ad una schedule seriale Schedule non seriali =:= schedule in cui le transazioni si sovrappongono in tempo almeno in parte Transazioni Atomiche 59 Quando sono possibili e ancora corrette? Operazioni O i T i, O j T j sono dette conflittuali sse accedono allo stesso dato e almeno una delle due è una write Operazioni non conflittuali possono essere eseguite in ordine scambiato senza modificare l effetto finale =:= scambio non conflittuale. 5

6 6.9.4 Transazioni Atomiche 60 Se con una serie di scambi non conflittuali si ottiene una schedule seriale allora la schedule di partenza è conflict serializable è equivalente ad una seriale è una valida esecuzione ha maggior parallelismo! Transazioni Atomiche 61 Esempio di conflitto in una schedule non seriale T 0 T 1 read(a) - write(a) - conflitto - read(a) - write(a) non read(b) - conflitto write(b) - - read(b) - write(b) 62 Protocollo di Locking Per assicurare serializzabilità associamo un lock ad ogni dato e seguiamo una regola di comportamento (=:=protocollo) per acquisire i lock prima di accedere alle variabili Come nel caso di lettori/scrittori: lock condiviso per leggere lock esclusivo per scrivere Stranamente, rilasciare il lock subito dopo l ultimo accesso ad un dato può produrre non serializzabilità 6

7 63 Protocollo di locking a due fasi fase di crescita: si acquisiscono lock ma non se ne rilascia nessuno fase di assottigliamento: si rilasciano lock ma non se ne acquisisce nessuno la transazione è costituita da una sola crescita seguita da un solo assottigliamento appena si fa un rilascio non si può che continuare a rilasciare 64 Protocollo di locking a due fasi Può dare deadlock Non produce tutte le possibili schedule serializzabili (quindi alcune schedule con parallelismo maggiore non vengono generate/permesse) 65 Protocolli basati su Timestamp Determinare in anticipo (prima che a runtime) l ordinamento fra le operazioni delle transazioni associare a T i un timestamp TS(T i ) Timestamp totalmente ordinati, assegnati dal sistema alla partenza di ogni T i TS: clock di sistema o contatore logico 7

8 66 Protocolli basati su Timestamp Se TS(T i ) < TS(T j ) allora la schedule non seriale deve essere equivalente alla seriale (T i ; T j ) Ad ogni dato Q associare W_TS(Q) =:= il max TS di ogni T i che ha eseguito con successo write(q), e R_TS(Q) =:= il max TS di ogni T i che ha eseguito con successo read(q). NB: valori da tenere aggiornati a run-time 67 Protocolli basati su Timestamp Logica: far fallire quelle operazioni che farebbero acquisire alla transazione dati sbagliati (attraverso la read) o invaliderebbero dati già acquisiti per la write. Se quando tento di leggere ho che TS < W_TS(Q), i dati che leggo sono sbagliati 68 Protocolli basati su Timestamp Se quando tento di scrivere ho che TS < R_TS(Q), i dati che sovrascrivo sono stati letti e presi per buoni da un altra transazione Quando posso eseguire l operazione il R_TS o W_TS di Q viene aggiornato Quando l operazione fallisce, la transazione è abortita, rolled-back e deve essere ritentata, ma questa volta avrà un TS maggiore! 8