Solution to Dining Philosophers

1
Solution to Dining Philosophers
2
Solution to Dining Philosophers
3
Solution to Dining Philosophers

• Each philosopher I invokes the operations
  pickup() and putdown() in the following sequence
• dp.pickup(i)
• EAT
• dp.putdown(i)

4
6.8 Synchronization Examples

• Solaris
• Windows XP
• Linux

5
Synchronization in Solaris

• It provides adaptive mutexes, condition
  variables, semaphores, reader-writer locks and
  turnstiles

6
Adaptive Mutexes

• Adaptive mutexes protects access to every
  critical data item
• If a lock is held by a thread that is currently
  running on another CPU, the thread spins while
  waiting for the lock, because the thread holding
  the lock is likely to finish soon
• If the thread holding the lock is not currently
  in run state, the thread blocks, going to sleep
  until it is awaken by the release of the lock
• (kernel preemption)

7
Synchronization in Solaris

• Reader-Writer locks multiple threads can read
  data concurrently, where semaphores always
  serialize access to data
• Turnstile a queue structure containing threads
  blocked on a lock.

8
Synchronization in Windows XP

• Uses interrupt masks to protect access to global
  resources on uniprocessor systems
• Uses spin locks on multiprocessor systems

9
Synchronization in Linux

• Linux uses an interesting approach to disable and
  enable kernel preemption by two system calls
• preempt disable()
• preempt enable()

10
6.9 Atomic Transactions

• The mutual exclusion of critical sections ensures
  that the critical sections are executed
  atomically. That is, if two critical sections
  are executed concurrently, the result is
  equivalent to their sequential execution.
• An example is funds transfer, where one account
  is debited and another is credited

11
6.9 Atomic Transactions

• Consistency of data is a concern often associated
  with database system
• Recently, there has been an upsurge of system
  interest in using database-system techniques in OS

12
6.9 Atomic Transactions

• A collection of instructions that performs a
  single logical function is called a transaction
• If a terminated transaction has completed its
  execution successfully, it is committed,
  otherwise, it is aborted

13
Types of storage media

• Volatile storage information stored here does
  not survive system crashes
• Example main memory, cache
• Nonvolatile storage Information usually survives
  crashes
• Example disk
• Stable storage Information never lost
• Example magnetic tape

14
6.9 Atomic Transactions

• Our goal is to ensure transaction atomicity in an
  environment where failures result in the loss of
  information on volatile storage

15
Log-Based Recovery Algorithm

• Most common is write-ahead logging
• Each log contains
• Transaction name
• Data item name
• Old value
• New value

16
Log-Based Recovery Algorithm

• ltTistartsgt written to log when transaction Ti
  starts
• During its execution, any write operation by Ti
  is preceded by the writing of the appropriate new
  record to the log
• ltTi commitsgt written when Ti commits

17
Log-Based Recovery Algorithm

• Log entry must reach stable storage before
  operation on data occurs
• Performance penalty
• 1. two physical writes are required
• 2. extra storage is required

18
Log-Based Recovery Algorithm

• Using the log, system can handle any volatile
  memory errors
• Undo(Ti) restores value of all data updated by
  Ti
• Redo(Ti) sets values of all data in transaction
  Tito new values

19
Log-Based Recovery Algorithm

• If system fails, restore state of all updated
  data via log
• If log contains ltTistartsgt without ltTicommitsgt,
  undo(Ti)
• If log contains ltTistartsgt and ltTicommitsgt,
  redo(Ti)

20
Checkpoints

• When a system failure occurs, we must consult the
  log to determine those transactions that need to
  be redone and those need to be undone
• The search is time consuming

21
Checkpoints

• To reduce the overhead, we introduce the concept
  of checkpoints
• During execution, the system maintains the
  write-ahead log. In addition, the system
  periodically performs checkpoints that require
  the following sequence of actions to take place
• 1. Output all log records currently in volatile
  storage to stable storage
• 2.Output all modified data from volatile to
  stable storage
• 3.Output a log record ltcheckpointgt to the log on
  stable storage

22
Concurrent Transactions

• We have been considering an environment where
  only one transaction can be executing at a time.
• We now turn to the case where multiple
  transactions are active simultaneously
• Serializability since each transaction is
  atomic, the concurrent execution of transactions
  must be equivalent to the case where these
  transactions are executed serially.

23
Concurrency-control algorithms

• Concurrency-control algorithms provide
  serializability

24
Schedule 1 T0 then T1
25
Concurrency-control algorithms

• Non-serial schedule allows overlapped execute
  (Resulting execution not necessarily incorrect)
• Conflict Consider schedule S, we say that
  operations Oi, Oj conflict if they access same
  data item, with at least one of them is write
  operation

26
Schedule 2 Concurrent Serializable Schedule
27
Concurrency-control algorithms

• If Oi, Oj consecutive and operations of different
  transactions Oi and Oj dont conflict, then S
  with swapped order Oj Oi equivalent to S
• Example
• Swap read(B) of T0 with write(A) of T1
• Swap read(B) of T0 with read(A) of T1
• Swap write(B) of T0 with write(A) of T1
• Swap write(B) of T0 with read(A) of T1

28
Concurrency-control algorithms

• If S can become S via swapping non-conflicting
  operations then S is conflict serializable

29
Timestamp Timestamp-based Protocols

• Select order among transactions in advance
  timestamp-ordering
• Transaction Ti associated with timestamp
  TS(Ti) before Tistarts
• TS(Ti) lt TS(Tj) if Ti entered system before Tj
• TS can be generated from system clock or as
  logical counter incremented at each entry of
  transaction

30
Timestamp Timestamp-based Protocols

• Timestamps determine serializability order
• If TS(Ti) lt TS(Tj), system must ensure produced
  schedule equivalent to serial schedule where Ti
  appears before Tj

31
Timestamp Timestamp-based Protocols

• Data item Q gets two timestamps
• W-timestamp(Q) largest timestamp of any
  transaction that executed write(Q) successfully
• R-timestamp(Q) largest timestamp of successful
  read(Q)
• Updated whenever read(Q) or write(Q) executed

32
Timestamp Timestamp-based Protocols

• Suppose Ti executes read(Q)
• If TS(Ti) lt W-timestamp(Q), Ti needs to read
  value of Q that was already overwritten
• Read operation rejected and Ti rolled back
• If TS(Ti) W-timestamp(Q)
• Read executed, R-timestamp(Q) set to
• max(R-timestamp(Q), TS(Ti))

33
Timestamp Timestamp-based Protocols

• Suppose Ti executes write(Q)
• If TS(Ti) lt R-timestamp(Q), value Q produced by
  Ti was needed previously and Ti assumed it would
  never be produced
• Write operation rejected, Ti rolled back
• If TS(Ti) lt W-tiimestamp(Q), Ti attempting to
  write obsolete value of Q
• Write operation rejected and Ti rolled back
• Otherwise, write executed

34
Timestamp Timestamp-based Protocols

• Any rolled back transaction Ti is assigned new
  timestamp and restarted
• Algorithm ensures conflict serializability and
  freedom from deadlock