Presentation is loading. Please wait.

Presentation is loading. Please wait.

Real-Time & MultiMedia Lab Synchronization Chapter 5.

Similar presentations


Presentation on theme: "Real-Time & MultiMedia Lab Synchronization Chapter 5."— Presentation transcript:

1 Real-Time & MultiMedia Lab Synchronization Chapter 5

2 Real-Time & MultiMedia Lab Election Algorithms Often need one process as a coordinator All processes in distributed systems may be equal Assume have some “ID” that is a number Need way to “elect” process with the highest number as leader

3 Real-Time & MultiMedia Lab The Bully Algorithm (1) The bully election algorithm Process 4 notices 7 down Process 4 holds an election Process 5 and 6 respond, telling 4 to stop Now 5 and 6 each hold an election

4 Real-Time & MultiMedia Lab Global State (3) Process 6 tells process 5 to stop Process 6 wins and tells everyone Eventually “biggest” (bully) wins If processes 7 comes up, starts elections again everyone

5 Real-Time & MultiMedia Lab A Ring Algorithm Election algorithm using a ring. Coordinator down, start ELECTION Send message down ring, add ID Once around, change to COORDINATOR (biggest) Even if two ELECTIONS started at once, everyone will pick same leader

6 Real-Time & MultiMedia Lab Mutual Exclusion: A Centralized Algorithm a)Process 1 asks the coordinator for permission to enter a critical region. Permission is granted b)Process 2 then asks permission to enter the same critical region. The coordinator does not reply. c)When process 1 exits the critical region, it tells the coordinator, when then replies to 2 d)But centralized, single point of failure

7 Real-Time & MultiMedia Lab A Distributed Algorithm 1.Processes 0 and 2 want to enter the same critical region at the same moment. 2.Process 1 doesn’t want to, says “OK”. Process 0 has the lowest timestamp, so it wins. Queues up “OK” for 2. 3.When process 0 is done, it sends an OK to 2 so can now enter the critical region. 4.(Again, can modify to say “denied”)

8 Real-Time & MultiMedia Lab A Toke Ring Algorithm An unordered group of processes on a network. A logical ring constructed in software. Process must have token to enter. If don’t want to enter, pass token along. If host down, recover ring. If token lost, regenerate token. If in critical section long

9 Real-Time & MultiMedia Lab Comparison A comparison of three mutual exclusion algorithms. Centralized most efficient Token ring efficient when many want to use critical region Algorithm Messages per entry/exit Delay before entry (in message times) Problems Centralized32Coordinator crash Distributed2 ( n – 1 ) Crash of any process Token ring 1 to  0 to n – 1 Lost token, process crash

10 Real-Time & MultiMedia Lab The Transaction Model (1) Updating a master tape is fault tolerant.

11 Real-Time & MultiMedia Lab The Transaction Model Gives you mutual exclusion plus… Consider using PC (Quicken) to: Withdraw $a from account 1 Deposit $a to account 2 If interrupt between 1) and 2), $a gone! Multiple items in single, atomic action It all happens, or none If process backs out, as if never started

12 Real-Time & MultiMedia Lab The Transaction Model (2) Examples of primitives for transactions. Above may be system calls, libraries or statements in a language (Sequential Query Language or SQL) PrimitiveDescription BEGIN_TRANSACTIONMake the start of a transaction END_TRANSACTIONTerminate the transaction and try to commit ABORT_TRANSACTIONKill the transaction and restore the old values READRead data from a file, a table, or otherwise WRITEWrite data to a file, a table, or otherwise

13 Real-Time & MultiMedia Lab The Transaction Model (3) a)Transaction to reserve three flights commits b)Transaction aborts when third flight is unavailable c)The “all-or-nothing” is one property. Others BEGIN_TRANSACTION reserve WP -> JFK; reserve JFK -> Nairobi; reserve Nairobi -> Malindi; END_TRANSACTION (a) BEGIN_TRANSACTION reserve WP -> JFK; reserve JFK -> Nairobi; reserve Nairobi -> Malindi full => ABORT_TRANSACTION (b)

14 Real-Time & MultiMedia Lab Transaction Properties ACID Atomic – Others don’t see intermediate results, either Consistent System invariants not violated Ex: no money lost after operations) Isolated Operations can happen in parallel but as if were done serially Durability Once commits, move forward (Ch 7, won’t cover more)

15 Real-Time & MultiMedia Lab Classification of Transactions Flat Transactions Limited Example: what if want to keep first part of flight reservation? If abort and then restart, those might be gone. Example: what if want to move a Web page. All links pointing to it would need to be updated. It could lock resources for a long time Also Distributed and Nested Transactions

16 Real-Time & MultiMedia Lab Distributed Transactions a)A nested transaction b)A distributed transaction Nested transaction gives you a hierarchy –Can distribute (example: WP  JFK, JFK  Nairobi) –But may require multiple databases Distributed transaction is “flat” but across distributed data (example: JFK and Nairobi dbase

17 Real-Time & MultiMedia Lab Private Workspace (1) File system with transaction across multiple files Normally, updates seen + No way to undo Private Workspace  Copy files Only update Public Workspace once done If abort transaction, remove private copy. But copy can be expensive! How to fix?

18 Real-Time & MultiMedia Lab Private Workspace a)The file index and disk blocks for a three-block file b)The situation after a transaction has modified block 0 and appended block 3 c)Replace original file (new blocks plus descriptor) after commit

19 Real-Time & MultiMedia Lab Writeahead Log a) A transaction b) The log before each statement is executed If transaction commits, nothing to do If transaction is aborted, use log to rollback x = 0; y = 0; BEGIN_TRANSACTION; x = x + 1; y = y + 2 x = y * y; END_TRANSACTION; (a) Log [x = 0 / 1] (b) Log [x = 0 / 1] [y = 0/2] (c) Log [x = 0 / 1] [y = 0/2] [x = 1/4] (d)

20 Real-Time & MultiMedia Lab Concurrency Control (1) General organization of managers for handling transactions.

21 Real-Time & MultiMedia Lab Concurrency Control (2) General organization of managers for handling distributed transactions.

22 Real-Time & MultiMedia Lab Serializability The whole idea behind concurrency control is to properly schedule conflicting operations (two read operations never conflict ) Synchronization can take place either through mutual exclusion mechanisms on shared data (i.e. locking) Or explicitly ordering operations using timestamps

23 Real-Time & MultiMedia Lab Serializability a) Three transactions T 1, T 2, and T 3. Answer could be 1, 2 or 3. All valid. –2 is serialized Concurrency controller needs to manage BEGIN_TRANSACTION x = 0; x = x + 1; END_TRANSACTION (a) BEGIN_TRANSACTION x = 0; x = x + 2; END_TRANSACTION (b) BEGIN_TRANSACTION x = 0; x = x + 3; END_TRANSACTION (c) Schedule 1x = 0; x = x + 1; x = 0; x = x + 2; x = 0; x = x + 3Legal Schedule 2x = 0; x = 0; x = x + 1; x = x + 2; x = 0; x = x + 3;Legal Schedule 3x = 0; x = 0; x = x + 1; x = 0; x = x + 2; x = x + 3;Illegal (d)

24 Real-Time & MultiMedia Lab Two-Phase Locking (1) Two-phase locking A transaction T is granted a lock if there is no conflict The scheduler will never release a lock for data item x, until the data manager acknowledges it has performed the operation for which the lock was set Once the scheduler has released a lock on behalf of a transaction T, it will never grant another lock on behalf of T Acquire locks (ex: in previous example). Perform update. Release. Can lead to deadlocks (use OS techniques to resolve) Can prove: if used by all transactions, then all schedules will be serializable

25 Real-Time & MultiMedia Lab Two-Phase Locking (2) Strict two-phase locking In centralized 2PL: a single site is responsible for granting and releasing locks In primary 2PL: each data item is assigned a primary copy In distributed 2PL: the schedulers on each machine not only take care that locks are granted and released, but also that the operation is forwarded to the (local) data manager

26 Real-Time & MultiMedia Lab Pessimistic Timestamp Ordering Concurrency control using timestamps.

27 Real-Time & MultiMedia Lab Timestamp Ordering Pessimistic Every read and write gets a timestamp (unique, using Lamport’s alg) If conflict, abort sub-operation and re-try Optimistic Allow all operations since conflict rate At end, if conflict, roll-back

28 Real-Time & MultiMedia Lab Conclusion & Critical Idea A transaction consists of a series of operations. A transaction is durable, meaning that if it completes, its effects are permanent. Two-phase locking can lead to dead lock Acquiring all locks in some canonical order to prevent hold-and-wait cycles. Using deadlock detection by maintaining an explicit graph for cycles. Inheritance Priority Protocol


Download ppt "Real-Time & MultiMedia Lab Synchronization Chapter 5."

Similar presentations


Ads by Google