Mutual Exclusion

1
Mutual Exclusion

• What is mutual exclusion?
• Make sure that no other will use the shared data
  structure at the same time.
• Single processor systems
• use semaphores and monitors
• Three different algorithms
• Centralized Algorithm
• Distributed Algorithm
• Token Ring Algorithm

2
Mutual ExclusionCentralized Algo(1)

• One process is elected as coordinator
• Other processes send it a message asking for
  permission
• coordinator grants permission
• or says no-permission (or doesnt reply at all)
• queues the request
• When the critical region is free
• it sends a message to the first one in the queue

3
Mutual Exclusion A Centralized Algorithm(2)

1. Process 1 asks the coordinator (ask)for
   permission to enter a critical region.
   Permission is granted
2. Process 2 then asks permission to enter the same
   critical region. The coordinator does not reply.
3. When process 1 exits the critical region, it
   tells the coordinator,(release) when then replies
   to 2

4
Mutual Exclusion A Centralized Algorithm(3)

• Coordinator only let one process to enter the
  critical region.
• The request is granted in the order no process
  ever waits forever ( no starvation).
• Three messages is use in accessing the critical
  region/shared resources
• Request
• Grant
• Release
• Drawbackcoordinator is single point failure
• If process blocked after making a request- it is
  cannot distinguish either the coordinator is dead
  or resource not available.
• Performance bottleneck in a large system.

5
Mutual ExclusionA Distributed Algo(1)

• There are total ordering of all event in the
  system
• Provide timestamps by using Lamport Algorithm
• Algorithm
• A process wanting to enter the Critical Section
  (CS)
• Build a msg -
• forms ltcs-name, its process id, current-timegt
• sends to all processes including itself.
• assume that sending is reliable every msg is
  acknowledge

6
Mutual Exclusion A Distributed Algorithm(2)

• Every receiving process
• sends an OK, if it is not interested in the CS
• if it is already in the CS, just queues the
  message
• if it itself has sent out a message for the CS
• compares the time stamps
• if an incoming message has lower timestamp
• it sends out an OK
• else it just queues it
• Once it receives an OK from everyone
• it enters the CS
• once its done, its sends an OK to everyone in
  its queue

7
Mutual Exclusion A Distributed Algo(3)
8
12

• Two processes(02) want to enter the same
  critical region at the same moment.
• Process 1 not interested for CS-gt send OK to 0
  and 2.
• 0 1 compare the timestampsgt Process 0 has the
  lowest timestamp, so it wins.
• When process 0 is done, it sends an OK also, so 2
  can now enter the critical region.

8
A Token Ring Algorithm(1)

• Create a logical ring (in software)
• each process knows who is next
• When a process have the token, it can enter the
  CS
• Finished, release the token and pass to the next
  guy
• The token circulate at high speed around the ring
  if no process wants to enter the CS.
• No starvation
• at worst wait for each other process to complete
• Detecting that a token has been lost is hard
• What if a process crashes?
• recovery depends on the processes being able to
  skip this process while passing on the ring

9
A Token Ring Algorithm(2)
K18
Token
6187

• 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 token lost (detection is hard), regenerate
  token.
• If host down, recover ring.

10
Comparison

• A comparison of three mutual exclusion algorithms.

Algorithm Messages per entry/exit Delay before entry (in message times) Problems
Centralized 3 2 Coordinator crash
Distributed 2 ( n 1 ) 2 ( n 1 ) Crash of any process
Token ring 1 to ? 0 to n 1 Lost token, process crash

• Centralized most efficient
• Token ring efficient when many want to use
  critical region

11
The Transaction Model(1)

• A transaction is a unit of program execution that
  accesses and possibly updates various data
  items.
• A transaction must see a consistent database.
• During transaction execution the database may be
  inconsistent.
• When the transaction is committed, the database
  must be consistent.
• Two main issues to deal with
• Failures of various kinds, such as hardware
  failures and system crashes
• Concurrent execution of multiple transactions

12
The Transaction Model (3)

• Examples of primitives for transactions.

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

• Above may be system calls, libraries or
  statements in a language (Sequential Query
  Language or SQL)

13
The Transaction Model (4)
Reserving Flight from White Plains to Malindi
BEGIN_TRANSACTION reserve WP -gt JFK reserve JFK -gt Nairobi reserve Nairobi -gt MalindiEND_TRANSACTION (a) BEGIN_TRANSACTION reserve WP -gt JFK reserve JFK -gt Nairobi reserve Nairobi -gt Malindi full gtABORT_TRANSACTION (b)

1. Transaction to reserve three flights commits
2. Transaction aborts when third flight is
   unavailable

14
Characteristics of Transaction(5)

• Atomic
• Completely happened or nothing
• Consistent
• The system not violate system invariant-one state
  to another
• Ex no money lost after operations
• Isolated
• Operations can happen in parallel but as if were
  done serially
• Durable
• The result become permanent when its
  finish/commit
• ACID- FLAT TRANSACTION

15
Example Funds Transfer

• Transaction to transfer 50 from account A to
  account B
• 1. read(A)
• 2. A A 50
• write(A)
• 4. read(B)
• 5. B B 50
• 6. write(B)
• Consistency requirement the sum of A and B is
  unchanged by the execution of the transaction.
• Atomicity requirement if the transaction fails
  after step 3 and before step 6, the system
  ensures that its updates are not reflected in the
  database.

16
Example Funds Transfer continued

• Durability requirement once the user has been
  notified that the transaction has completed
  (i.e., the transfer of the 50 has taken place),
  the updates to the DB must persist despite
  failures.
• Isolation requirement if between steps 3 and 6,
  another transaction is allowed to access the
  partially updated database, it will see an
  inconsistent database (the sum A B will be less
  than it should be).Can be ensured by running
  transactions serially.

17
Flat Transaction

• Simplest type of transaction all sub transaction
  were group into a single transaction.
• Limitation
• what if want to keep first part of flight
  reservation? If abort and then restart, those
  might be gone.
• Does not allowed partial result to be
• committed or
• Aborted
• Solve by using nested transaction

18
Atomic Transactions

• Transaction an operation composed of a number of
  discrete steps.
• All the steps must be completed for the
  transaction to be committed. The results are made
  permanent.
• Otherwise, the transaction is aborted and the
  state of the system reverts to what it was before
  the transaction started.

19
Example

• Buying a house
• Make an offer
• Sign contract
• Deposit money in escrow
• Inspect the house
• Critical problems from inspection?
• Get a mortgage
• Have seller make repairs
• Commit sign closing papers transfer deed
• Abort return escrow and revert to pre-purchase
  state
• All or nothing property

20
Basic Operations

• Transaction primitives
• Begin transaction mark the start of a
  transaction
• End transaction mark the end of a transaction
  try to commit
• Abort transaction kill the transaction, restore
  old values
• Read/write data from files (or object stores)
  data will have to be restored if the transaction
  is aborted.

21
Programming in a Transaction System

• Begin_transaction
• Mark the start of a transaction
• End_transaction
• Mark the end of a transaction and try to commit
• Abort_transaction
• Terminate the transaction and restore old values
• Read
• Read data from a file, table, etc., on behalf of
  the transaction
• Write
• Write data to file, table, etc., on behalf of the
  transaction

22
Tools for Implementing Atomic Transactions
(continued)

• Begin_transaction
• Place a begin entry in log
• Write
• Write updated data to log
• Abort_transaction
• Place abort entry in log
• End_transaction (i.e., commit)
• Place commit entry in log
• Copy logged data to files
• Place done entry in log

23
Programming in a Transaction System (continued)

• As a matter of practice, separate transactions
  are handled in separate threads or processes
• Isolated property means that two concurrent
  transactions are serialized
• I.e., they run in some indeterminate order with
  respect to each other

24
Programming in a Transaction System (continued)

• Nested Transactions
• One or more transactions inside another
  transaction
• May individually commit, but may need to be
  undone
• Example
• Planning a trip involving three flights
• Reservation for each flight commits
  individually
• Must be undone if entire trip cannot commit

25
Another Example

• Book a flight from Penang, KLIA to Waikato. No
  non-stop flights are available
• Transaction begin
• Reserve a seat for Penang to KLIA (PNG?KLIA)
• Reserve a seat for KLIA to Bangkok (KLIA?BGK)
• Reserve a seat for Bangkok to Waikato (BGK?WK)
• Transaction end
• If there are no seatsavailable on the BGK?WK leg
  of the journey, the transaction is aborted and
  reservations for (1) and (2) are undone.

26
Tools for Implementing Atomic Transactions
(single system)

• Stable storage
• i.e., write to disk atomically
• Log file
• i.e., record actions in a log before committing
  them
• Log in stable storage
• Locking protocols
• Serialize Read and Write operations of same data
  by separate transactions

27
Tools for Implementing Atomic Transactions
(continued)

• Crash recovery search log
• If begin entry, look for matching entries
• If done, do nothing (all files have been updated)
• If abort, undo any permanent changes that
  transaction may have made
• If commit but not done, copy updated blocks from
  log to files, then add done entry

28
Distributed Atomic Transactions

• Atomic transactions that span multiple sites
  and/or systems
• Same semantics as atomic transactions on single
  system
• A C I D
• Failure modes
• Crash or other failure of one site or system
• Network failure or partition
• Byzantine failures

29
Properties of transactions ACID

• Atomic
• The transaction happens as a single indivisible
  action. Others do not see intermediate results.
  All or nothing.
• Consistent
• If the system has invariants, they must hold
  after the transaction. E.g., total amount of
  money in all accounts must be the same before and
  after a transfer funds transaction.
• Isolated (Serializable)
• If transactions run at the same time, the final
  result must be the same as if they executed in
  some serial order.
• Durable
• Once a transaction commits, the results are made
  permanent. No failures after a commit will cause
  the results to revert.

30
Nested Transactions

• A top-level transaction may create
  subtransactions
• Problem
• subtransactions may commit (results are durable)
  but the parent transaction may abort.
• One solution private workspace
• Each subtransaction is given a private copy of
  every object it manipulates. On commit, the
  private copy displaces the parents copy (which
  may also be a private copy of the parents parent)

31
Nested Transaction

• Constructed from a number of sub-transaction
• Top-level transaction may fork children run in
  parallel in different machine
• The children itself may fork another child or
  subs transaction
• When one transaction is commit- it will make
  visible to their parent

32
Nested transactions

• transactions may be composed of other
  transactions
• several transactions may be started from within a
  transaction
• we have a top-level transaction and
  subtransactions which may have their own
  subtransactions

33
Nested transactions (12.3)

• To a parent, a subtransaction is atomic with
  respect to failures and concurrent access
• transactions at the same level (e.g. T1 and T2)
  can run concurrently but access to common objects
  is serialised
• a subtransaction can fail independently of its
  parent and other subtransactions
• when it aborts, its parent decides what to do,
  e.g. start another subtransaction or give up

34
Example Nested Transaction

• Nested transaction gives you a hierarchy
• Can distribute (example WP?JFK, JFK?Nairobi,
  Nairobi -gt Malindi)
• Each of them can be manage independently
• But may require multiple databases

TransactionBooking a ticket
Commit
WP?JFK
JFK?Nairobi
Commit
Nairobi ?Malindi
Abort
35
Distributed transaction

1. A distributed transaction is composed of several
   sub-transactions each running on a different
   site.
2. Separate algorithms are needed to handle the
   locking of data and committing the entire
   transaction.

Differences between nested transaction and
distributed transaction
36
TransactionImplementation

• Two methods are used
• Private Workspace
• Writeahead Log
• Consideration on a file system

37
Private Workspace

• Conceptually, when a process starts a
  transaction, it is given a private workspace
  (copies) containing all the files and data
  objects to which it has access.
• When it commits, the private workspace replaces
  the corresponding data items in the permanent
  workspace. If the transaction aborts, the
  private workspace can simply be discarded.
• This type of implementation leads to many private
  workspaces and thus consumes a lot of space.
• Optimization (as cost of copying is very
  expensive)
• No need for a private copy when a process reads a
  file.
• For writing a file, only the files index is
  copied.

38
Private Workspace

• Original file index and disk blocks for a
  three-block file
• The situation after a transaction has
  modified/update block 0 and appended block 3
• Copy file index only. Copy blocks only when
  written.
• Modified block 0 and appended block 3
• After committing

39
More Efficient Implementation/Write ahead log

• Files are actually modified, but before changes
  are made, a record ltTi,Oid,OldValue,NewValuegt is
  written to the writeahead log on the stable
  storage. Only after the log has been written
  successfully is the change made to the file.
• If the transaction succeeds and is committed, a
  record is written to the log, but the data
  objects do not have to be changed, as they have
  already been updated.
• If the transaction aborts, the log can be used to
  back up to the original state (rollback).
• The log can also be used for recovering from
  crash.

40
Writeahead Log
Dont make copies. Instead, record action plus
old and new values
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)
Old value
New value

• a) A transaction
• b) d) The log before each statement is executed
• If transaction commits, nothing to do
• If transaction is aborted, use log to rollback

41
Concurrency Control (1)
The goal of concurrency control is to allow
several transactions to be executed
simultaneously, but the collection of data item
is remains in a consistent state. The consistency
can be achieved by giving access to the items in
a specific order

• General organization of managers for handling
  transactions.

42
Concurrency Control (2)

• General organization of managers for handling
  distributed transactions.

43
Serializability
BEGIN_TRANSACTION x 0 x x 1END_TRANSACTION (a) BEGIN_TRANSACTION x 0 x x 2END_TRANSACTION (b) BEGIN_TRANSACTION x 0 x x 3END_TRANSACTION (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

44
One-phase atomic commit protocol

• The protocol
• Client request to end a transaction
• The coordinator communicates the commit or abort
  request to all of the participants and to keep on
  repeating the request until all of them have
  acknowledged that they had carried it out
• The problem
• some servers commit, some servers abort
• How to deal with the situation that some servers
  decide to abort?

45
Introduction to two-phase commit protocol

• Allow for any participant to abort
• First phase
• Each participant votes to commit or abort
• The second phase
• All participants reach the same decision
• If any one participant votes to abort, then all
  abort
• If all participants votes to commit, then all
  commit
• The challenge
• work correctly when error happens
• Failure model
• Server crash, message may be lost

46
The two-phase commit protocol

• When the client request to abort
• The coordinator informs all participants to abort
• When the client request to commit
• First phase
• The coordinator ask all participants if they
  prepare to commit
• If a participant prepare to commit, it saves in
  the permanent storage all of the objects that it
  has altered in the transaction and reply yes.
  Otherwise, reply no
• Second phase
• The coordinator tell all participants to commit (
  or abort)

47
The two-phase commit protocol continued

• Operations for two-phase commit protocol
• The two-phase commit protocol
• Record updates that are prepared to commit in the
  permanent storage
• When the server crash, the information can be
  retrieved by a new process
• If the coordinator decide to commit, all
  participants will commit eventually

48
Timeout actions in the two-phase commit protocol

• Communication in two-phase commit protocol
• New processes to mask crash failure
• Crashed process of coordinator and participant
  will be replaced by new processes
• Time out for the participant
• Timeout of waiting for canCommit abort
• Timeout of waiting for doCommit
• Uncertain status Keep updates in the permanent
  storage
• getDecision request to the coordinator
• Time out for the coordinator
• Timeout of waiting for vote result abort
• Timeout of waiting for haveCommited do nothing
• The protocol can work correctly without the
  confirmation

49
Two-phase commit protocol for nested transactions

• Nested transaction semantics
• Subtransaction
• Commit provisionally
• abort
• Parent transaction
• Abort all subtransactions abort
• Commit exclude aborting subtransactions
• Distributed nested transaction
• When a subtransaction completes
• provisionally committed updates are not saved in
  the permanent storage

50
Distributed nested transactions commit protocol

• Each subtransaction
• If commit provisionally
• Report the status of it and its descendants to
  its parent
• If abort
• Report abort to its parent
• Top level transaction
• Receive a list of status of all subtransactions
• Start two-phase commit protocol on all
  subtransactions that have committed provisionally

51
Example of a distributed nested transactions

• The execution process
• The information held by each coordinator
• Top level coordinator
• The participant list the coordinators of all the
  subtransactions in the tree that have
  provisionally committed but do not have aborted
  parent
• Two-phase commit protocol
• Conducted on the participant of T, T1 and T12

52
Different two-phase commit protocol

• Hierarchic two-phase commit protocol
• Messages are transferred according to the
  hierarchic relationship between successful
  participants
• The interface
• Flat two-phase commit protocol
• Messages are transferred from top-level
  coordinator to all successful participants
  directly
• The interface

53
Locking

• Locking is the oldest, and still most widely
  used, form of concurrency control
• When a process needs access to a data item, it
  tries to acquire a lock on it - when it no longer
  needs the item, it releases the lock
• The schedulers job is to grant and release locks
  in a way that guarantees valid schedules

54

• In 2PL, the scheduler grants all the locks during
  a growing phase, and releases them during a
  shrinking phase
• In describing the set of rules that govern the
  scheduler,
• we will refer to an operation on data item x by
  transaction T as oper(T,x)

55
Two-Phase Locking Rules (Part 1)

• When the scheduler receives an operation
  oper(T,x), it
• tests whether that operation conflicts with any
  operation
• on x for which it has already granted a lock
• If it conflicts, the operation is delayed
• If not, the scheduler grants a lock for x and
  passes the operation
• to the data manager
• The scheduler will never release a lock for x
  until the
• data manager acknowledges that it has performed
  the
• operation on x

56
Two-Phase Locking Rules (Part 2)

• Once the scheduler has released any lock on
  behalf of
• transaction T, it will never grant another lock
  on behalf of
• T, regardless of the data item T is requesting
  the lock for
• An attempt by T to acquire another lock after
  having
• released any lock is considered a programming
  error,
• and causes T to abort

57
Two-Phase Locking (1)

• Two-phase locking.