0% found this document useful (0 votes)
63 views46 pages

Synchronization: CS403/534 Distributed Systems Erkay Savas Sabanci University

This document summarizes several algorithms for distributed systems including election algorithms, mutual exclusion algorithms, and distributed transactions. It discusses the Bully algorithm for coordinator election, describes ring and centralized approaches for mutual exclusion, and outlines the transaction model and primitives for distributed transactions. Key challenges addressed include electing a coordinator dynamically without single point of failure, allowing exclusive access to shared resources across processes, and ensuring all-or-nothing atomicity of distributed operations.

Uploaded by

Umesh Thoriya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
63 views46 pages

Synchronization: CS403/534 Distributed Systems Erkay Savas Sabanci University

This document summarizes several algorithms for distributed systems including election algorithms, mutual exclusion algorithms, and distributed transactions. It discusses the Bully algorithm for coordinator election, describes ring and centralized approaches for mutual exclusion, and outlines the transaction model and primitives for distributed transactions. Key challenges addressed include electing a coordinator dynamically without single point of failure, allowing exclusive access to shared resources across processes, and ensuring all-or-nothing atomicity of distributed operations.

Uploaded by

Umesh Thoriya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 46

Synchronization

Part II
CS403/534
Distributed Systems
Erkay Savas
Sabanci University

1
Election Algorithms
• Issue:
– Many distributed algorithms require that one process
act as a coordinator (initiator, etc).
– In many systems this is done manually. This leads to
centralized solutions  single point of failure
– The question is how to select this special process
dynamically.
• Advantage of dynamic selection
– If the coordinator dies, then another coordinator can
be elected dynamically.
• Assumptions:
– Every process has a unique ID and processes know each
other’s ID
– A running process with the highest ID becomes the
coordinator
2
The Bully Algorithm
• Algorithm: When a process P notices that the
coordinator is not responding, it holds an election
as follows:
1. Process P sends an ELECTION message to all processes
with higher ID numbers
2. If no one responds, P wins the election and becomes
coordinator
3. If an OK message is returned by a process, P gives up
and responding process holds an election.

3
The Bully Algorithm: Example (1)

1 1 1
2 n 5 2 5 2 5
ctio OK
ele election
election OK 4 6
4 6 4 6

0 3 0 3 0 3
7 7 7

• Process 4 holds an election


• Process 5 and 6 respond, telling 4 to stop
• Now 5 and 6 each hold an election 4
The Bully Algorithm: Example (2)
d) Process 6 tells 5 to stop
e) Process 6 wins and tells everyone

1 1
2 5 2 5
OK
4 6 4 6
Coordinator

0 3 0 3
7 7

5
A Ring Algorithm (1)
• Principle:
– Processes are arranged on a ring and process with the
highest ID number is elected as a coordinator
• Algorithm:
– Any process that notices the coordinator is down can
start the election.
– It first builds an ELECTION message containing its
own ID number
– Sends this message to its successor
– Process that receives this message adds its number
and passes it along
– Eventually, the message comes back to the initiator
with a list of alive processes.
6
A Ring Algorithm (2)

[5,6,0] 1 [5,6,0,1]

0 2
[2]

7 [5, 6] 3
6 is the new
coordinator [2,3]
no response
6 4
[5] 5

• Both 2 and 5 notice the coordinator (7) is down 7


Mutual Exclusion
• Problem:
– A number of processes in a distributed system want
exclusive access to a resource
• Solutions:
1. Via a coordinator
2. Completely distributed, with no topology imposed
3. Completely distributed, making use of a (logical) ring
• Centralized approach
– The coordinator grants or defers permission
– It keeps the deferred requests in a queue
– When the resource is available, it picks up the
deferred request from the top of queue and sends
the blocked process a grant message
8
Mutual Exclusion:
A Centralized Algorithm
0 1 2 0 1 2 0 1 2

request OK request no reply release


OK
coordinator 3 3 3
2

Queue Queue Queue

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 9
Distributed Mutual Exclusion Algorithm
• Assumptions:
– Processes use logical clocks (totally-ordered)
– Sending messages are reliable (i.e. ACKed)
• Algorithm: When a process wants to enter a
critical region, it sends to all other processes a
message containing the name of the critical
region, its process ID, and its current logical time
1. If the receiver is not in the critical region and does
not want to enter it, it sends back an OK message
2. If the sender is already in the critical region, it does
not reply. It queues the request.
3. If the receiver also wants to enter the critical region
but has not yet done so, it compares the timestamps.
The one with the lower timestamp wins.
10
A Distributed Algorithm
8
0 enters
critical region
0 0 0
8 12 OK OK
8 OK

1 2 1 2 1 2
12 OK
2 enters
12 critical region

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. 11
Token Ring Mutual Exclusion
Algorithm
• Essence:
– Organize the processes in a logical ring, and let a token
be passed between them.
– The one that holds the token is allowed to enter the
critical region (if it wants to)
• Problems:
– The token may get lost (It is not easy to detect it)
– A process can crash and it cannot pass the token along.
– If we require a process receiving the token to
acknowledge the receipt, a dead process can be
detected.

12
A Toke Ring Algorithm

2
1 3

0 4

7 5
6

A logical ring constructed in software.


13
Comparison of Mutual Exclusion
Algorithms
Delay before
Messages per
Algorithm entry (in message Problems
entry/exit
numbers)
Coordinator
Centralized 3 2
crash
Crash of any
Distributed 2(n–1) 2(n–1)
process
Lost token,
Token ring 1 to ∞ 0 to n – 1
process crash

• A comparison of three mutual exclusion algorithms.


• Assumption: Point-to-point communication channels are
used
14
Distributed Transactions
• They allow a process to access and modify many
data items as a single atomic operation
• Therefore they are strongly related to mutual
exclusion.
• If the process cannot complete all the
suboperations, everything will be restored to the
state before the transaction began  All-or-
nothing property
• Outline
– The transaction model
– Classification of transactions
– Concurrency control
15
Transactions
• Example:
– A customer performs the following two operations on
its bank account remotely
1. Withdraw an amount A from account 1
2. Deposit amount A to account 2

– What happens if the connection is broken only after


the first operation is performed?
– Two operations in this example, must be treated as
part of a transaction
– either both would be completed, or neither would be
completed

16
Transaction Primitives
Primitive Description

BEGIN_TRANSACTION Make the start of a transaction


Terminate the transaction and try to
END_TRANSACTION
commit
Kill the transaction and restore the old
ABORT_TRANSACTION
values
Read data from a file, a table, or
READ
otherwise
WRITE Write data to a file, a table, or otherwise

• Primitives must either be supplied


– by the underlying distributed systems or
– by the language runtime system
17
Example: Plane Reservation

BEGIN_TRANSACTION 1. BEGIN_TRANSACTION
reserve ANK -> IST; 2. reserve ANK -> IST; OK
reserve IST -> CHI; 3. reserve IST -> CHI; OK
reserve CHI -> LAX;
END_TRANSACTION 4. reserve CHI -> LAX full
5. ABORT_TRANSACTION
(a)
(b)

a) Transaction to reserve three flights commits


b) Transaction aborts when third flight is
unavailable

18
Transaction: ACID Properties
• Atomicity:
– To the outside world, a transaction is indivisible.
• Consistent:
– The transaction does not violate system invariants.
– e.g., the law of conservation of money in a bank.
– A transaction establishes a valid state transition.
– Invalid, intermediate states during the transaction’s
execution are possible
• Isolated:
– Concurrent transactions do not interfere with each
other.
– Transactions are isolated or serializable.
• Durable:
– Once a transaction commits, the changes are permanent
19
Classification: Flat Transaction
• The simplest and most familiar one. Satisfies the
ACID properties.
• Problem:
– It does not allow partial results to be committed or
aborted.
• Example: flight reservation
– It would be nice if we made any subset of the three
reservations (commit them) and dealt with the rest
later.

20
Classification: Nested Transactions
• A nested transaction is constructed from a
number of subtransactions
• Parent transaction may fork off subtransactions
that may execute in isolation (possibly on
different machines)
• Once a subtransaction commits, its state will
become visible to the parent transaction.
• If the parent transaction aborts, all child
subtransactions have to abort as well
– The permanency of subtransactions are not applicable
• A subtransaction is given a private copy of all the
data in the entire system to manipulate it.
21
Classification: Distributed Transactions
• A distributed transaction is a flat, indivisible
transaction that operates on distributed data.
• Nested transactions generally follow logical
division of the work of the original transaction.
– A subtransaction can still be distributed
• The main problem of distributed transaction is
that it requires distributed locking algorithms.

22
Implementing Transactions
• Solution 1: private workspace
• Case Study: Transactions on file system
• When a process starts a transaction, it is given a
private workspace to work
• All the reads and writes are done on this private
workspace, not on the original disk blocks.
• All the other processes see the original blocks of
file until the transaction commits
• The transaction will have a private view of the
file system
• After committing, this view will be globally unique
23
Private Workspace
index original private
index
0 index workspace
0
1 0 0’
1
2 1 1
2
2 2
3
3’

1 2 0 1 2 0
1 2
0’ 3’ 0 3

free blocks

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
24
Implementing Transactions
Solution 2: writeahead log
Use a writeahead log in which changes are recorded allowing
you to rollback when things go wrong.
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 25
Concurrency Control (1)
• Problem
– Increase efficiency by allowing several transactions to
execute at the same time
– and we have to do it in such a way that consistency and
isolation properties are not violated.
• Constraint
– Effect should be the same as if the transactions were
executed in some serial (sequential) order.
– The same data items must be accessed in a specific
order by different transactions
– However, the final result is the same as if all
transactions had run sequentially.

26
Concurrency Control: Layered Organization
Transactions

READ/WRITE
BEGIN_TRANSACTION
Transaction
Atomicity
END_TRANSACTION manager

LOCK/RELEASE
or Scheduler Controlling concurrency
Timestamp operations (isolation & consistency )

Data
manager Execute read/write

General organization of managers for handling transactions.


27
Concurrency Control in Distributed Systems

• General
transaction organization
manager of managers
for handling
distributed
transactions
scheduler scheduler scheduler .

data data data


manager manager manager

Machine A Machine B Machine C


28
Serializability
• Consider a collection E of transactions:
T1, …, Tn.
• Goal is to conduct a serializable execution of E:
– Transactions in E are possibly concurrently executed
according to some schedule S.
– Schedule S is equivalent to some totally ordered
execution of suboperations in T1, …, Tn.

29
Serializability: Example
T1: T2: T3:
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/serialized
Schedule 2 x = 0; x = 0; x = x + 1; x = x + 2; x = 0; x = x + 3; Legal/unseriliazed
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
30
Serializability : Conflicts
• Model of computation:
– Since we are not interested in the specific
computations of each transaction, a transaction can be
modeled as a series of read and write operations on
data items.
• Conflicting operations:
– Two operations oper(Ti, x) and oper(Tj, x) of two
transactions Ti and Tj on the same data item x may
conflict at data manager.
– read-write conflict: One operation is a read and the
other is a write
– write-write conflict: Both are write operations
– Two read operations never conflict
31
Synchronization
• Concurrency control algorithms can generally be
classified by looking at the way read and write
operations are synchronized
• Synchronization can be achieved through
– Mutual exclusion mechanism on shared data (i.e.
locking). Before writing or reading of a data item, a
lock must be obtained.
– Explicitly ordering operations using timestamps. Data
managers are forced to execute read and writes
following timestamp order
• Optimistic and pessimistic concurrency control
32
Two-Phase Locking (2PL)
• Transactions indicate their intentions by
requesting locks from the scheduler (a.k.a lock
manager).
• Locks are either read lock (a.k.a. shared lock) or
write lock (a.k.a. exclusive lock)
• Read locks and write locks conflict (because read
and write operations are incompatible)
Read lock Write lock
Read lock Yes No
Write lock No No

• Scheduler needs to apply an algorithm that


provides only serializable schedules. 33
2PL: Rules
1. A transaction must lock an object before using it.
2. If the object is locked by another transaction,
the requesting transaction must wait (unless it is a
non-conflicting lock).
3. When a transaction releases a lock, it may not
request another lock.
• These rules guarantee lock  operation  release
• Growing phase: A transaction collects locks on
data items it needs to operate on
• Shrinking phase: starts with the first unlock
operation
34
2PL
• Two-phase locking.

35
Strict-2PL
• Strict two-phase locking.

36
Strict-2PL: Advantages
1. A transaction reads a value written by a
committed transaction;
– therefore a transaction never has to abort because
another transaction aborts
– extreme case is cascaded aborts.
2. All lock acquisitions and releases can be handled
by the system automatically;
– locks are acquired whenever a data item is to be
accessed and released when the transaction commits.

37
2PL: Example (1)
• Initial values: x = y = z = 50;
• Two Transactions:
T1: T2:
x = x + 100 z = 2z + x
y = y + 150 x = 2x
z = y + z y = 2y
• (Serialized) Order: T1 T2
T1: x = 150 y = 200 z = 250
T2: x = 300 y = 400 z = 650
• T2 T1
x = 200 y = 250 z = 350
38
Ordering without 2PL: Example
• Initial values: x = y = z = 50
T1 T2
lock x lock z
modify x (x=150) x=x+100 wait for lock on x
unlock x …
lock y lock x
modify y (y=200) y=y+150 modify z (z = 250) z=2z + x
unlock y unlock z
lock z modify x (x=300) x = 2x
modify z (z=450) z=y+z lock y
unlock z modify y (y = 400) y= 2y
unlock x and y

• Result: x = 300, y = 400, z = 450 39


2PL: Problems
• System can come to a deadlock
– If two transactions each try to acquire the same pair
of locks but in the opposite order, a deadlock may
occur (see the previous result)
• Solution
– Put a timeout on locks and abort transaction on lock
expiration.
– Deadlock detection algorithms. Maintaining an explicit
graph of which process has which locks and wants
which locks; and checking the graph for cycles

40
Timestamp Ordering (1)
• Basic idea:
– Transaction manager assigns a unique timestamp
ts(Ti) to each transaction Ti.
– Every operation in Ti is timestamped with ts(Ti).
– Each data item x has also a read timestamp,
tsRD(x), and a write timestamp tsWR(x).
– tsRD(x)is set to the timestamp of the transaction
that has most recently read x.
– Similarly, tsWR(x)is set to timestamp of the
transaction that has most recently changed x.
– In case of conflicting operations on data item x, the
data manager processes the one with the lowest
timestamp first.
41
Timestamp Ordering (2)
• Suppose: two conflicting operations
read(Ti, x), write(Tj, x)
– ts(Ti) < ts(Tj), but write(Tj, x) has already
been processed by the data manager
– Then, the scheduler must reject read(Ti, x)
• Note: Timestamp ordering is rather aggressive
for if a single operation is rejected, the
transaction will have to be aborted
• Example: read(T, x)
– if ts(T) < tsWR(x) then T must be aborted
– if ts(T) > tsWR(x) then read(T, x) can be
executed (tsRD(x):= max(ts(T), tsRD(x)))
42
Timestamp Ordering (3)
• Example: write(T, x)
– if ts(T) < tsRD(x) then T must be aborted
– if ts(T) > tsRD(x) then write(T, x) can be
executed

• Suppose: two conflicting operations


oper(Ti, x) and oper(Tj, x)
– ts(Ti) < ts(Tj), and oper(Ti, x) is submitted to
the data manager
– It holds back oper(Tj, x)

43
Pessimistic Timestamp Ordering: Example (1)
• ts(T1) << ts(T2) < ts(T3).
• Initially, tsRD(x) = tsWR(x) = ts(T1)
• T2 is trying to write x

tsRD(x) tsWR(x) ts(T2) ts(T2) tsWR(x)

(T1) (T1) (T2) (T2) (T3)

time time
write is accepted write is not accepted

ts(T2) tsRD(x)

(T2) (T3)

time
write is not accepted
44
Pessimistic Timestamp Ordering: Example (2)
• ts(T1) << ts(T4) < ts(T2) < ts(T3)
• Initially, tsRD(x) = tsWR(x) = ts(T1)
• T2 is trying to read x
tsWR(x) ts(T2) ts(T2) tsWR(x)

(T1) (T2) (T2) (T3)

time time
no conflict Abort

tsWR(x) tstent(x) ts(T2) ts(T2) tstent(x)

(T1) (T4) (T2) (T2) (T3)

time time
no conflict, T2 just waits Abort

45
Optimistic Concurrency Control
• Observation:
1. Maintaining locks is expensive
2. In practice, there are not many conflicts
• Alternative
– Go ahead immediately with all operations, use
tentative writes everywhere (shadow or private
copies), solve conflicts while committing
• Phases:
1. Allow operations tentatively
2. validate effects (through checking all transactions)
3. make updates permanent
46

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy