Synchronization
Chapter 5
Synchronization
• Synchronization in distributed systems is harder than
in centralized systems because of the need for
distributed algorithms.
• Distributed algorithms have the following properties:
– No machine has complete information about the system
state.
– Machines make decisions based only on local information.
– Failure of one machine does not ruin the algorithm.
– There is no implicit assumption that a global clock exists.
• Clocks are needed to synchronize in a distributed
system.
Clock Synchronization
• Time is unambiguous in centralized systems.
– System clock keeps time, all entities use this for time.
• In distributed systems each node has own system
clock.
– Each crystal-based clock runs at slightly different rates. This
difference is called clock skew.
– Problem: An event that occurred after another may be
assigned an earlier time.
Physical Clocks: A Primer
• Accurate clocks are atomic oscillators
• Most clocks are less accurate (e.g., mechanical watches)
– Computers use crystal-based blocks
– Results in clock drift
• How do you tell time?
– Use astronomical metrics (solar day)
• Coordinated universal time (UTC) – international
standard based on atomic time same as Greenwich
Mean Time
– Add leap seconds to be consistent with astronomical time
– UTC broadcast on radio (satellite and earth)
– Receivers accurate to 0.1 – 10 ms
• The goal is to synchronize machines with a master
(UTC receiver machine) or with one another.
Physical Clocks
Computation of the mean solar day (transit of the sun – noon)
Physical Clocks
• TAI (Temps Atomique International) seconds are of constant
length, unlike solar seconds. Leap seconds are introduced
when necessary to keep in phase with the sun.
Clock Synchronization Algorithms
The relation between clock time and UTC when clocks tick at different rates.
Clock Synchronization
• Each clock has a maximum drift rate r
– 1-r resynchronize every d/2r
seconds (2r Dt C(B)
• Solution:
– Each processor maintains a logical clock LCi
– Whenever an event occurs locally at I, LCi = LCi+1
– When i sends message to j, piggyback LCi
– When j receives message from i
• If LCj JFK; reserve WP -> JFK;
reserve JFK -> Nairobi; reserve JFK -> Nairobi;
reserve Nairobi -> Malindi; reserve Nairobi -> Malindi full =>
END_TRANSACTION ABORT_TRANSACTION
(a) (b)
a) Transaction to reserve three flights commits (White
Plains New York Nairobi Malindi)
b) Transaction aborts when third flight is unavailable
Classification of Transactions.
• A flat transaction is a series of operations that
satisfy the ACID properties.
– It does not allow partial results to be committed or
aborted.
– Example: flight reservation, Web link update.
• A nest transaction is constructed from a
number of subtransactions.
• A distributed transaction is logically a flat,
indivisible transaction that operates on
distributed data.
Distributed Transactions
a) A nested transaction (transaction is decomposed into
subtransactions)
b) A distributed transaction (subtransaction on different data)
Implementation of transactions
• Two methods can be used to implement transactions:
– Private workspace: Until the transaction either commits or
aborts, all of its reads and writes go to the private workspace.
– Writeahead log: Use a log to record the change. Only after
the log has been written successfully is the change made to
the file.
• Private workspace
– Each transaction get copies of all files, objects
– It can optimize for reads by not making copies
– It can optimize for writes by copying only what is required
(An appended block and a copy of modified block are created.
These new blocks are called shadow blocks.)
– Commit requires making local workspace global
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
Implementation: Write-ahead Logs
• In-place updates: transaction makes changes directly to
all files/objects and keeps these changes in a log.
• Write-ahead log: prior to making change, transaction
writes to log on stable storage
– Transaction ID, block number, original value, new value
• Force logs on commit
• If abort, read log records and undo changes [rollback]
• Log can be used to rerun transaction after failure
• Both workspaces and logs work for distributed
transactions
• Commit needs to be atomic [will return to this issue in
Ch. 7]
Writeahead Log
x = 0; Log Log Log
y = 0;
BEGIN_TRANSACTION;
x = x + 1; [x = 0 / 1] [x = 0 / 1] [x = 0 / 1]
y=y+2 [y = 0/2] [y = 0/2]
x = y * y; [x = 1/4]
END_TRANSACTION;
(a) (b) (c) (d)
a) A transaction
b) – d) The log before each statement is executed
Concurrency Control
• Goal: Allow several transactions to be executing
simultaneously such that
– Collection of manipulated data item is left in a
consistent state
• Achieve consistency by ensuring data items are
accessed in an specific order
– Final result should be same as if each transaction ran
sequentially
Concurrency Control
• Concurrency control can implemented in a
layered fashion:
– Bottom layer - A data manager performs the actual
read and write operations on data.
– Middle layer - A scheduler carries the main
responsibility for properly controlling concurrency.
Scheduling can be based on the use of locks or
timestamps.
– Highest layer – The transaction manager is
responsible for guaranteeing atomicity of
transactions.
Concurrency Control
General organization of managers for handling transactions.
Concurrency Control
General organization of
managers for handling
distributed transactions.
Serializability
• Key idea: properly schedule conflicting operations
• Conflict is possible if at least one operation is write
– Read-write conflict
– Write-write conflict
BEGIN_TRANSACTION BEGIN_TRANSACTION BEGIN_TRANSACTION
x = 0; x = 0; x = 0;
x = x + 1; x = x + 2; x = x + 3;
END_TRANSACTION END_TRANSACTION END_TRANSACTION
(a) (b) (c)
Schedule 1 x = 0; x = x + 1; x = 0; x = x + 2; x = 0; x = x + 3 Legal
Schedule 2 x = 0; x = 0; x = x + 1; x = x + 2; x = 0; x = x + 3; Legal
Schedule 3 x = 0; x = 0; x = x + 1; x = 0; x = x + 2; x = x + 3; Illegal
(d)
a) – c) Three transactions T1, T2, and T3
d) Possible schedules (Schedule 2 is legal because it results in a
valid x value.)
Serializability
• Two approaches are used in concurrency control:
– Pessimistic approaches: operations are synchronized
before they are carried out.
– Optimistic approaches: operations are carried out
and synchronization takes place at the end of
transaction. At the conflict point, one or more
transactions are aborted.
Two-phase Locking (2PL)
• Widely used concurrency control technique
• Scheduler acquires all necessary locks in
growing phase, releases locks in shrinking
phase
– Check if operation on data item x conflicts with
existing locks
• If so, delay transaction. If not, grant a lock on x
– Never release a lock until data manager finishes
operation on x
– Once a lock is released, no further locks can be
granted.
Two-Phase Locking
Two-phase locking.
Two-phase Locking (2PL)
• In strict two-phase locking, the shrinking
phase does not take place until the transaction
has finished running.
• Advantages:
– A transaction always reads a value written by a
committed transaction.
– All lock acquisitions and releases can be handled by
the system without the transaction being aware of
them.
• Problem: deadlock possible
– Example: acquiring two locks in different order
Two-Phase Locking
Strict two-phase locking.
Two-phase Locking (2PL)
• In centralized 2PL, a single site is responsible
for granting and releasing locks.
• In primary 2PL, each data item is assigned a
primary copy. The lock manager on that copy‟s
machine is responsible for granting and
releasing locks.
• 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.
Timestamp-based Concurrency Control
• Each transaction Ti is given timestamp ts(Ti)
• If Ti wants to do an operation that conflicts with
Tj
– Abort Ti if ts(Ti) < ts(Tj)
• When a transaction aborts, it must restart with a
new (larger) time stamp
• Two values for each data item x
– Max-rts(x): max time stamp of a transaction that read
x
– Max-wts(x): max time stamp of a transaction that
wrote x
Reads and Writes using Timestamps
• Readi(x)
– If ts(Ti) < max-wts(x) then Abort Ti
– Else
• Perform Ri(x)
• Max-rts(x) = max(max-rts(x), ts(Ti))
• Writei(x)
– If ts(Ti)
Ti
– Else
• Perform Wi(x)
• Max-wts(x) = ts(Ti)
Pessimistic Timestamp Ordering
Concurrency control using timestamps.
Optimistic Concurrency Control
• Transaction does what it wants and validates changes
prior to commit
– Check if files/objects have been changed by committed
transactions since they were opened
– Insight: conflicts are rare, so works well most of the time
• Works well with private workspaces
• Advantage:
– Deadlock free
– Maximum parallelism
• Disadvantage:
– Rerun transaction if aborts
– Probability of conflict rises substantially at high loads
• Not used widely