Synchronization Chapter 5

Clock Synchronization When each machine has its own clock, an event that occurred after another event may nevertheless be assigned an earlier time. Fact: Different machines have different clocks. Problem: How to synchronize (distributed) clocks?  clock synchronization algorithms Example: “make” program (real) time

Cristian's Algorithm Getting the current time from a time server. Main idea: Use a time server. This server has its own clock, and all other machines use its time as reference time. Time server: passive  it only responds to “what time is it?”-requests. Problem: Client gets “current” time after delay D! Simple estimates for D : D est = (T1-T0)/2 or if I is known D est = (T1-T0-I) /2 If T is the time reported by the time server, the client sets its current time to T + D est Delay D

The Berkeley Algorithm a)The time daemon asks all the other machines for their clock values b)The machines answer c)The time daemon tells everyone how to adjust their clock Characteristics:  Also based on a time server.  Time server is active (unlike Cristian’s algorithm) Ave = 1/3 *(0 + (-10) + 25) = 5

Lamport Timestamps Idea: Why synchronization with “real” time? Approach: Processes that interact with each other should agree on the ordering of events only. Actual event times are not important (in many applications).  logical time 0 Machine Machine 2 Machine 3 m1 m2 m3 m4 Situation: Three machines, each has own clock. Each clock has its own rate. Clocks must be corrected (forward), if sending time happens to be after receiving time. S: sending time, R: receiving time. S R Action m1: 0 2 Nothing m2: 4 9 Nothing m3: Correction m4: 12 7 Correction Corrections

Example: Totally-Ordered Multicasting Updating a replicated database and leaving it in an inconsistent state. Solution: Use timestamps. These deliver a global notion of time. All messages are multicast (to all replicas) and all replicas multicast acknowledgements back to other ones. Each replica process holds a queue ordered using timestamps. Thus, all queues will be the same in all processes. An operation (e.g. update) is performed only after the acknowledgement of all processes and if it has the smallest timestamp (at head of queue).

Global State (1) a)A consistent cut: Send events of each receive event are included in the cut. b)An inconsistent cut: Receive event of m2 has no corresponding send event!

Global State (2) a)Organization of a process and channels for a distributed snapshot Snapshot: Models a (consistent) global state of the (distributed) system including local states of processes/machines and states of communication channels (e.g. sent/received messages).

Global State (3) b)Process Q receives a marker for the first time and records its local state c)Q records all incoming messages (new marker received) d)Q receives a marker for its incoming channel and finishes recording the state of the incoming channel  Useful for distributed termination detection.

The Bully Algorithm (1) The bully election algorithm a)Process 4 holds an election b)Process 5 and 6 respond, telling 4 to stop c)Now 5 and 6 each hold an election

Global State (3) d)Process 6 tells 5 to stop e)Process 6 wins and tells everyone

A Ring Algorithm Election algorithm using a ring. Process 2 and Process 5 detect simultaneously that the coordinator (Process 7) is down. Messages initiated from 5 Messages initiated from 2

Mutual Exclusion: A Centralized Algorithm: Algorithm 1 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  Main problems: Coordinator must be always up. Scalability problems, when many processes are involved.

A Distributed Algorithm: Algorithm 2 a)Two processes want to enter the same critical region at the same moment. b)Process 0 has the lowest timestamp, so it wins. c)When process 0 is done, it sends an OK also, so 2 can now enter the critical region.  - : Every process does almost the same work (performance degradation). - : Too much message traffic. - : Worse yet, ANY process crash means that ALL processes will hang; solution: use of additional “denial” messages (when receiver is in critical region). + : ? or it is a distributed algorithm. 2 Process 0 releases resource

A Token Ring Algorithm: Algorithm 3 a)An unordered group of processes on a network. b)A logical ring constructed in software.  Token circulates in defined order  Only process holding the token can access resource  Problems: Token may be lost; process may crash. Token

Comparison A comparison of three mutual exclusion algorithms. Algorithm Messages per entry/exit Delay before entry (in message times) Problems Algorithm 1 (Centralized) 3 Request, Grant, Release 2 Request + (delayed) Grant Coordinator crash (unusual case: centralized algorithm is more reliable as decentralized ones!) Algorithm 2 (Distributed) 2 ( n – 1 ) Request + Grant to/from each process 2 ( n – 1 ) n Requests and n (delayed) Grants Crash of any process Algorithm 3 (Token ring, also distributed) 1 to  1 token pass, when every process is using the resource. Unlimited number of token passes, when none of the processes is using resource. 0 to n – 1 0: Token is now here n-1: Token just left Lost token, process crash

The Transaction Model (1) Examples of primitives for transactions. Transactions are data(base)-oriented operations that have the so-called ACID property: A: Atomicity or All-or-nothing: Operations of a transaction are indivisible. C: Consistency: Data are left consistent after transactions. I: Isolation: Concurrent transactions do not interfere with each other. D: Durability: Changes of a committed transaction are permanent. 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

The Transaction Model (2) a)Transaction to reserve three flights commits b)Transaction aborts when third flight is unavailable BEGIN_TRANSACTION reserve Lethbridge  Calgary; reserve Calgary  Toronto; reserve Toronto  New York; END_TRANSACTION (a) BEGIN_TRANSACTION reserve Lethbridge  Calgary; reserve Calgary  Toronto; reserve Toronto  New York: full  ABORT_TRANSACTION (b)

Distributed Transactions a)A nested transaction: Made of subtransactions operating on logically different databases. b)A distributed transaction: Made of subtransactions operating on logically the same but distributed database. A B (B) Hotel database Hotel database

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)After committing Failure  Private index and new (shadow) blocks are deleted.

Writeahead Log a) A transaction b) – d) The log before each statement is executed Failure  File is reconstructed by means of log; rollback recovery (log is read backwards) 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)

Concurrency Control a)General organization of managers for handling transactions. b)Distributed transactions. a) b)

Serializability a) – c) Three transactions T 1, T 2, and T 3 d) Possible schedules 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)

Two-Phase Locking Two-phase locking. Strict two- phase locking.

Pessimistic Timestamp Ordering Concurrency control using timestamps. (a) and (b): T2 can proceed, since only earlier TAs (T1) used item x. (c) and (d): T3 now used item x, so abort T2. (e): T2 can read. (f): T2 has to wait until T3 has done its work. (g) and (h): abort T2, since item has later changed by T3.