2. 1 Mutual Exclusion: A Centralized Algorithm a)Process 1 asks the coordinator for permission to enter a critical region. Permission is granted b)Process 2 then asks permission to enter the same critical region. The coordinator does not reply. c)When process 1 exits the critical region, it tells the coordinator, when then replies to 2

3. 2 Advantages: –Guarantees mutual exclusion –Fair –Requires only three messages per use of a critical region (request, grant, release) Shortcomings –Single point of failure –If processes normally blocks after making request, they cannot distinguish a dead coordinator from “permission denied”. –In a large system, a single coordinator becomes a performance bottleneck. A Centralized Algorithm

4. 3 A Distributed Algorithm Assuming there is a total ordering of all events in the system 1.When a process wants to enter a critical region, it builds a message containing the name of the critical region it wants to enter, its process number, and the current time. Then it sends the message to all other processes. 2.When a process receives a request, 1.If the receiver is not in the critical region, and does not want to enter it, it sends back an OK message to the sender. 2.If the receiver is already in the critical region, it does not reply. It queues the request. 3.If the receiver wants to enter the critical region, but has not yet done so, it compares the timestamp in the incoming message with the one contained in the message that it has sent to everyone. The lowest one wins. If the incoming message is lower, the receiver sends back an OK message. Otherwise, it queues the message. 3.As soon as all permissions are in, it may enter the critical region. When it exits the critical region, it sends OK message to all processes on its queue and deletes them all from the queue.

5. 4 A Distributed Algorithm a)Two processes want to enter the same critical region at the same moment. b)Process 0 has the lowest timestamp, so it wins. c)When process 0 is done, it sends an OK also, so 2 can now enter the critical region.

6. 5 A Distributed Algorithm Advantage –No deadlock or starvation –Number of message per entry is 2(n-1) –No single point of failure Disadvantage –n points of failure If any process crashes, the failure to respond to requests will be interpreted as denial of permission Patch: When a request comes in, the receiver always sends a reply, either granting or denying. Whenever a request or reply is lost, the sender times out and keep trying until a reply comes back or the sender concludes that the receiver is dead. After a request is denied, the sender should block waiting for a subsequent OK message. – group communication support needed –If one process is unable to handle the load, it is unlikely that forcing everyone to do exactly the same thing in parallel is going to help much. Modify the algorithm so that when a process has collected permission from majority of the other processes.

7. 6 A Toke Ring Algorithm (a)An unordered group of processes on a network. (b)A logical ring constructed in software. When a process acquires the token from its neighbor, if it wants to enter a critical region, it can enter that critical region, do its work, and then leave the region. It then can pass the token to the next process. Otherwise, it just passes the token to the next process.

8. 7 A Toke Ring Algorithm If the token is lost, it must be regenerated. Detecting the lost is difficult, since the amount of time between successive appearances of the token on the network is unbounded. If a process crashes, the algorithm will fail too. –We could amend the problem by requiring a process receiving the token to acknowledge receipt. A dead process will be detected when its neighbor tries to give it the token and fails. The token holder can send the token to the successor of the dead process in the ring.

9. 8 Comparison A comparison of three mutual exclusion algorithms. Algorithm Messages per entry/exit Delay before entry (in message times) Problems Centralized32Coordinator crash Distributed2 ( n – 1 ) Crash of any process Token ring 1 to  0 to n – 1 Lost token, process crash

10. 9 The Transaction Model (1) Updating a master tape is fault tolerant.

11. 10 The Transaction Model (2) Examples of primitives for transactions. PrimitiveDescription BEGIN_TRANSACTIONMake the start of a transaction END_TRANSACTIONTerminate the transaction and try to commit ABORT_TRANSACTIONKill the transaction and restore the old values READRead data from a file, a table, or otherwise WRITEWrite data to a file, a table, or otherwise

12. 11 The Transaction Model (3) a)Transaction to reserve three flights commits b)Transaction aborts when third flight is unavailable BEGIN_TRANSACTION reserve WP -> JFK; reserve JFK -> Nairobi; reserve Nairobi -> Malindi; END_TRANSACTION (a) BEGIN_TRANSACTION reserve WP -> JFK; reserve JFK -> Nairobi; reserve Nairobi -> Malindi full => ABORT_TRANSACTION (b)

13. 12 The Transaction Model (4) Four characteristics that transactions have: –Atomic: To the outside world, the transaction happens individually –Consistent: The transaction does not violate system invariants –Isolated: Concurrent transactions do not interfere with each other –Durable: Once a transaction commits, the changes are permanent

14. 13 Nested vs. Distributed Transactions a)A nested transaction b)A distributed transaction

15. 14 Private Workspace a)The file index and disk blocks for a three-block file b)The situation after a transaction has modified block 0 and appended block 3 c)After committing The scheme works for distributed transaction too. A process is started on each machine containing a file that is to be accessed as part of the transaction. Each process is given its own private workspace. If the transaction aborts, all processes just discard its private workspace. When the transaction commits, updates are propagated.

16. 15 Writeahead Log a) A transaction b) – d) The log before each statement is executed 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) Before any block is changed, a record is written to a log telling which transaction is making the change, which file and block are being changed, and what the new and old values are. Only after the log has been written successfully, the change will be made to the file. If the transaction commits, a commit record is written to the log. If the transaction aborts, a rollback must be performed.

17. 16 Concurrency Control (1) General organization of managers for handling transactions.

18. 17 Concurrency Control (2) General organization of managers for handling distributed transactions.

19. 18 Serializability a) – c) Three transactions T 1, T 2, and T 3 d) Possible schedules BEGIN_TRANSACTION x = 0; x = x + 1; END_TRANSACTION (a) BEGIN_TRANSACTION x = 0; x = x + 2; END_TRANSACTION (b) BEGIN_TRANSACTION x = 0; x = x + 3; END_TRANSACTION (c) Schedule 1x = 0; x = x + 1; x = 0; x = x + 2; x = 0; x = x + 3Legal Schedule 2x = 0; x = 0; x = x + 1; x = x + 2; x = 0; x = x + 3;Legal Schedule 3x = 0; x = 0; x = x + 1; x = 0; x = x + 2; x = x + 3;Illegal (d)

20. 19 Conflicting Operations Two operations conflict if they operate on the same data item, and if at least one of them is a write operation. Concurrency control can be classified –by their synchonization methods: Locking or timestamps –By the expected frequency of conflicts Pessimistic Optimistic

21. 20 Two-Phase Locking (1) Two-phase locking.

22. 21 Two-Phase Locking (2) Strict two-phase locking eliminates cascaded aborts.

23. 22 Two-Phase Locking (3) Deadlock problem –Fixed by asking to acquire locks in some canonical order –Deadlock detection Distributed –Centralized 2PL –Primary 2PL: each data item is assigned a primary copy. The lock manager on that copy’s machine is responsible for granting and releasing locks. –Distributed 2PL: assumes data may be replicated. The scheduler 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.

24. 23 Pessimistic Timestamp Ordering Every operation that is part of a transaction T, is timestamped with ts(T). Every data item x has a read timestamp set to the timestamp of the transaction that most recently read x. Every data item x has a write timestamp set to the timestamp of the transaction that most recently write x. For operation read(T, x), suppose timestamp of T is ts. If ts <, then T aborts. Otherwise, let the read take place, and set to For operation write(T, x), suppose timestamp of T is ts. If ts <, then T aborts. Otherwise, let the write take place, and set to

25. 24 Pessimistic Timestamp Ordering Concurrency control using timestamps.

26. 25 Optimistic Timestamp Ordering Idea: just go ahead and do whatever you want. It keeps tracks of which data items have been read and written. At the point of committing, it checks all other transactions to see if any of them have been changed since the transaction started. If so, it is aborted. Otherwise, it is committed. It fits best with the implementation based on private workspaces. It is deadlock free and allows maximum parallelism. Disadvantage: when failed, the transaction has to be run again.