4' Synchronization II

1
4. Synchronization II

• Mutual exclusion
• Distributed Transactions

2
Mutual Exclusion

• When a process has to read or update (write)
  certain data, it first enters a critical region
  (CR) to achieve mutual exclusion and ensure that
  no other processes will use the shared data at
  the same time.
• In single-processor systems, critical region can
  be protected using semaphores, monitors etc. In
  DS, several algorithms have been proposed
  centralized algorithm, distributed algorithm, and
  token ring algorithm.

3
Mutual Exclusion Centralized Algorithm

• One process is elected as the coordinator.
• Whenever a process P wants to enter a critical
  region (CR), it sends a request message to the
  coordinator stating which critical region it
  wants to enter and asking for permission.
• If no other process is currently in the CR, the
  coordinator sends back a reply granting
  permission to process P Otherwise, the
  coordinator may just refrain from replying, thus
  blocking P, or reply with permission denied to
  P.
• When a process exits the CR, it sends a message
  to the coordinator to release its exclusive
  access. The coordinator takes the first item off
  the queue of deferred requests and sends that
  process a grant message for it to enter CR.

4
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

5
Properties of Centralized Algorithm

• The centralized algorithm guarantees mutual
  exclusion because the coordinator only allows one
  process to enter the CR at a time.
• It is fair since requests are granted in their
  arriving order. It is also easy to implement.
• It requires only three messages per use of a CR
  (request, grant, release).
• It dose not lead deadlock or starvation no
  process ever waits forever.
• However, the coordinator is a single point of
  failure. In a large system, the coordinator may
  become a performance bottleneck.

6
Mutual Exclusion Distributed Algorithm I

• When a process P wants to enter a CR, it sends a
  message containing the CR name, its process
  number and the current logical time, to all the
  other processes (including itself).
• When a process Q receives a request message from
  P
• If Q is not in the CR and does not want to
  enter, it sends an OK message to P
• If Q is already in the CR, it does not
  reply and it queues the request
• If Q wants to enter the CR but has not done
  so, it compares the timestamp with the one in
  message from P. If its timestamp is higher, Q
  sends back an OK message, otherwise it queues the
  request and sends nothing.

7
Mutual Exclusion Distributed Algorithm II

• After process P receives all the permissions from
  all other processes, it may enter the CR
  otherwise it simply waits.
• When P exists the critical region, it sends OK
  messages to all processes on its queue and
  deletes them all from the queue.
• The number of messages required per entry is now
  2(n-1), n is the number of the processes in the
  system.
• Like the centralized method, it can guarantee
  mutual exclusion, and no deadlock and starvation.
• No single point of failure exists, but replaced
  by n points of failure!

8
A Distributed Algorithm

• Two processes want to enter the same critical
  region at the same moment.
• 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.

9
Distributed Algorithm Problems and Remedies

• If any process crashes, it will fail to response
  to requests, just like denying permission. It can
  be patched up by the method that each receiver
  always sends back a (granting or denying) reply
  to the process initializing the request.
• In the distributed algorithm, all processes are
  involved in all decisions concerning entry into
  CR. Various improvements are possible. The
  algorithm can be modified to allow a process to
  enter a CR when it has collected permission form
  a simple majority of the other processes, under
  the assumption that, at a time, one process can
  grant permission to only one process to enter the
  CR.
• The other problem is that the algorithm either
  needs to use a group communication primitives, or
  maintain the (current) group communication list
  itself.

10
Mutual Exclusion Token Ring Algorithm

• For a group of processes, in software, a logical
  ring is constructed in which each process is
  assigned a position in the ring (see the next
  slide). Each process knows who is next in the
  ring.
• When the ring is initialized, process 0 is given
  a token. The token circulates around the ring.
• When a process acquires the token from its
  neighbor, it checks to see if it is attempting to
  enter the CR
• If so, the process enters the CR, does
  something, then leaves the CR and passes the
  token along the ring It is not allowed to enter
  a second CR using the same token
• Otherwise, it just passes it along the ring.

11
A Toke Ring Algorithm

• An unordered group of processes on a network.
• A logical ring constructed in software.

12
Mutual Exclusion Token Ring Algorithm

• The algorithm can guarantee mutual exclusion
  only one process has the token at any moment, so
  only one process can actually be in a CR.
• No starvation or deadlock could occur. Since the
  token circulates among the processes in a
  well-defined order.
• However, if the token is lost, it must be
  regenerated, but detecting that it is lost is
  difficult.
• Another problem is that a crashed process may
  stop the token circulation. A token receiver may
  reply with an acknowledged message to the sender
  to detect a dead process. It may require that
  every process maintains the current ring
  configuration.

13
Comparison

• A comparison of three mutual exclusion algorithms.

14
Distributed Transactions

• Transactions not only protect a shared resource
  against simultaneous access by several concurrent
  processes, they also allow a process to access
  and modify multiple data items as a single atomic
  operation (all-or-nothing property).
• For example, to transfer an amount money a from a
  saving account S to a checking account C for a
  customer, the operation is performed in two
  steps
• withdraw an amount a from the saving
  account S
• deposit amount a to checking account C.
• The two operations are grouped into a
  transaction as a single atomic operation Either
  both would be completed, or neither would be
  completed (all-or-nothing property).

15
The Transaction Model

• Examples of primitives for transactions.

16
The Transaction Model

• Transaction to reserve three flights commits
• Transaction aborts when third flight is
  unavailable

17
Characteristic Properties of Transactions (ACID
Properties)

• Atomic the transaction happens indivisibly to
  the outside world, i.e., all-or-nothing property.
• Consistent The transaction does not violate
  system invariants. In the above example, the sum
  of the amounts of saving and checking should be
  the same before and after transfer transaction
  between the two accounts.
• Isolated (serializable) Concurrent transactions
  do not interfere each other If more than one
  transaction are running at the same time, to each
  of them and others, the final result looks as
  through all transactions ran in some sequential
  order (system dependent).
• Durable Once a transaction commits, the changes
  are permanent no failure after the commit of a
  transaction can undo the transaction results or
  cause them to be lost.

18
Classification of Transactions

• A transaction is basically considered as a
  series of operations satisfying the above ACID
  properties, which is also called flat
  transaction.
• The main limitation of flat transaction is that
  they do not allow partial results to be committed
  or aborted.
• A nested transaction is constructed from a number
  of sub-transactions. The top-level transaction
  may fork off children running in parallel with
  one another on different machines (for
  performance and easy programming etc). Each child
  may also execute one or more sub-transactions, or
  fork off its own children.

19
Classification of Transactions

• A transaction may starts several sub-transactions
  in parallel. If one of them commits, its results
  are visible to the parent transaction.
• If the parent later aborts, the results of the
  sub-transaction that committed must also be
  undone. The permanence is applied only to
  top-level transactions.
• If a sub-transaction commits and then later a new
  sub-transaction is started, the second one can
  see the results from the first one. Like wise, if
  an enclosing (higher-level) transaction aborts,
  all its underlying sub-transactions have to be
  aborted.
• Transactions can be nested arbitrarily.

20
Classification of Transactions

• The nested transactions generally follow a
  logical division of the work of the original
  transactions.
• In distributed transaction, the (flat)
  sub-transaction operates on data that are
  distributed across multiple machines.
• The difference between nested and distributed
  transactions is that the former is logically
  decomposed into a hierarchy of sub-transactions
  while the latter is a logically flat, indivisible
  transaction that operates on distributed data.

21
Distributed Transactions

• A nested transaction
• A distributed transaction

22
Implementation of Transactions

• For simplicity, transactions on a file system are
  considered. Two methods are commonly used
  private workspace and writeahead log.
• In private workspace method, a process is given a
  private workspace when it starts a transaction.
  All the reads/writes in the transaction go to the
  private workspace before it commits (or aborts).
  When it commits, all the results in the private
  workspace are copied to the file system.
• Problem with private workspace high cost of
  copying,
• Solution Several improvements are proposed
  below.
• For read operation, it may use the real file. To
  read a file, a back pointer (in its private
  workspace) to real file is used

23
Implementation of Transactions

• For write operation, the file could be located
  and copied to the private workspace.
• For further improvement, only the files index
  (indicating the locations of its disk blocks) is
  copied to the private workspace.
• The file can be read in a usually way
• For a write, a copy of block is made and
  the address of the copy is inserted into the
  index. Appending (creating a new) blocks is
  handled in the same way (see the example in the
  next slide).
• The method also works for distributed transaction.

24
Private Workspace Example

• The file index and disk blocks for a three-block
  file
• The situation after a transaction has modified
  block 0 and appended block 3
• After committing

25
Implementation of Transactions

• In writeahead method, files are actually modified
  in place, but before any block is changed, a
  record is written to a log file, recording all
  information about the changes. The changes are
  made to the file only after the log has been
  written successfully.
• If the transaction succeeds and is committed, a
  commit record is written to the log no change to
  data is required because it has already done
  before. If it aborts, the log can be used to
  restore to the original state. Such an action is
  called a rollback.
• The scheme also works for distributed
  transactions.

26
Writeahead Log Example

• a) A transaction
• b) d) The log before each statement is executed

27
Concurrency Control

• Concurrent control is to control transaction
  accesses to (shared) data items in specific
  order, so that several transactions can be be
  executed simultaneously, and collection of data
  items (files or database records) being
  manipulated is left in a consistent state.
• Consistent state the final results are the same
  as if the transactions were executed in some
  specific order.
• The general organization of managers for handling
  transactions consists of transaction manager,
  scheduler, and data manager as shown in the next
  slide.
• Data manager performs the actual read and write
  operations.

28
Concurrency Control (1)

• General organization of managers for handling
  transactions.

29
Concurrency Control (2)

• General organization of managers for handling
  distributed transactions.

30
Concurrency Control

• Scheduler carries the main responsibility for
  properly controlling concurrency.
• Transaction manager primarily responsible for
  guaranteeing atomicity of transactions. It
  process transaction primitives by transforming
  them into scheduling requests for the scheduler.
• Serializability For several transactions running
  simultaneously, the final result is the same as
  if all transactions had run sequentially (see the
  next slide).
• The key to concurrent control is to properly
  schedule conflicting operations in transactions.
• Two operations conflict if they operate on the
  same data item, and at least one of them is a
  write operation.

31
Serializability
(d)

• a) c) Three transactions T1, T2, and T3
• d) Possible schedules

32
Summary

• The distributed mutual exclusion ensures that at
  most one process at a time in a distributed
  collection of processes has accessed a shared
  data.
• Distributed mutual exclusion can easily be
  achieved using centralized coordinator method.
  Distributed algorithms also exist, but are not
  efficient and susceptible to failures. Token ring
  may also be used.
• A transaction consists of a series of operations
  on (shared) data, and must have the
  all-or-nothing property.
• A number of transactions can be executed
  simultaneously so that the overall effect is as
  if they had been carried out in some arbitrary
  but sequential order.
• Finally, a transaction should also be durable.