Synchronization

1
Synchronization

• Chapter 5

2
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
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
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
A Ring Algorithm

• Coordinator down, start ELECTION
• Send message down ring, add ID
• Once around, change to COORDINATOR (biggest)

• Election algorithm using a ring.

Even if two ELECTIONS started at once, everyone
will pick same leader
6
Mutual Exclusion A Centralized Algorithm

• Process 1 asks the coordinator for permission to
  enter a critical region. Permission is granted
• Process 2 then asks permission to enter the same
  critical region. The coordinator does not reply.
• When process 1 exits the critical region, it
  tells the coordinator, when then replies to 2
• But centralized, single point of failure

7
A Distributed Algorithm

• Processes 0 and 2 want to enter the same critical
  region at the same moment.
• Process 1 doesnt want to, says OK. Process 0
  has the lowest timestamp, so it wins. Queues up
  OK for 2.
• When process 0 is done, it sends an OK to 2 so
  can now enter the critical region.
• (Again, can modify to say denied)

8
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 dont want to enter, pass token along.
• If host down, recover ring. If token lost,
  regenerate token. If in critical section long

9
Comparison

• A comparison of three mutual exclusion
  algorithms.
• Centralized most efficient
• Token ring efficient when many want to use
  critical region

10
The Transaction Model (1)

• Updating a master tape is fault tolerant.

11
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
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)

13
The Transaction Model (3)

• Transaction to reserve three flights commits
• Transaction aborts when third flight is
  unavailable
• The all-or-nothing is one property. Others

14
Transaction Properties

• ACID
• Atomic
• Others dont 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, wont cover more)

15
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
Distributed Transactions

• A nested transaction
• 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
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
Private Workspace

• The file index and disk blocks for a three-block
  file
• The situation after a transaction has modified
  block 0 and appended block 3
• Replace original file (new blocks plus
  descriptor) after commit

19
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

20
Concurrency Control (1)

• General organization of managers for
  handling transactions.

21
Concurrency Control (2)

• General organization of managers for handling
  distributed transactions.

22
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
Serializability
(d)

• a) Three transactions T1, T2, and T3. Answer
  could be 1, 2 or 3. All valid.
• 2 is serialized
• Concurrency controller needs to manage

24
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
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
Pessimistic Timestamp Ordering

• Concurrency control using timestamps.

27
Timestamp Ordering

• Pessimistic
• Every read and write gets a timestamp (unique,
  using Lamports alg)
• If conflict, abort sub-operation and re-try
• Optimistic
• Allow all operations since conflict rate
• At end, if conflict, roll-back

28
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