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 • <Tistarts> 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 • <Ti commits> 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 <Tistarts> without <Ticommits>, undo(Ti) • If log contains <Tistarts> and <Ticommits>, 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 <checkpoint> 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 don’t 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) < 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) < 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) < 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) < 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) < 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