1. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Distributed Locking Jyrki Nummenmaa http://www.cs.uta.fi/~jyrki/ds01/ jyrki@cs.uta.fi

2. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Mutual Exclusion (Locking) n The problem of managing access to a single, indivisible resource (e.g. a data item) that can only support one user (or process, or thread, or whatever) at a time.

3. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Failure model / 1 n If a site fails, it halts completely. n Messages between sites are not spontaneously generated. n Messages do not change in transmission. n All messages arriving at a site, j, are processed in the order they were sent.

4. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Failure Model / 2 n The communication medium does not fail. n Message transfer delays are unpredictable. n Messages are transferred eventually.

5. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Properties n Safety: Mutual exclusion is never violated. (Only one process gets the lock). n Liveness: Each request will be granted (eventually). n Ordering (or Fairness): Access to the resource should happen in the order of requests (needs discussion).

6. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Coordinator-based solutions / 1 n There is a coordinator to control access. n When a process needs access, that process sends a request to coordinator. n The coordinator queues requests. n When the resource is available, the coordinator sends a grant message to the process P first in the queue.

7. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Coordinator-based solutions / 2 n When P sees the grant message, it may use the resource. n When P does need the resource anymore, it sends a message to the coordinator.

8. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Coordinator-based solutions / properties n These coordinator-based solutions obviously have the safety and the liveness properties. n We can argue that they are also fair, since requests are queued.

9. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Coordinator-based solutions / weaknesses n The system does not tolerate a crashing coordinator. n The coordinator may become a bottleneck for performance.

10. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Using coordinator-based solutions n If data is not replicated, then to use a data item, you must contact the site containing the item. If a site gives locks for its items, communication is simple. n If the data is replicated, then we can have a ”primary copy”, which is accessed for locking.

11. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Permission-based algorithms n When a process, say P i, needs access to the shared resource, it will send a message to other processes asking for the permission. n Then, P i waits until the replies are in.

12. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Giving permissions n When some other process Pj receives the request, it has several options: l If P j is not interested in the shared resource, it just sends its permission. l If P j has the shared resource, it queues the request. When it is done with the shared resource, it sends its permission. l If P j does not have the shared resource, but it wants it, there is a conflict in priorities, which has to be solved somehow.

13. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Permission conflicts n One way to solve these conflicts is to use timestamps. l The timestamps must give an order for events. l Processor ids can be used to solve the case of equal timestamps.

14. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Who to ask? n In principle, it could be enough to ask only a subset of processes for a permission. n This subset could be statically defined. n It could also be dynamic, and not even the same for all processes.

15. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. How many processes to ask? n Suppose we have n processes, and we consult k processes for a write-lock and m processes for a read-lock. n We must have k > n/2. n We must have k + m > n.

16. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Who needs to give permission? n If we need a permission from all processes, then we do not tolerate site failures. n Generally, a majority is enough. n There are also ways other than simple majority or unanimous vote, but one has to be careful to preserve the mutual exclusion.

17. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Token-based algorithms n In the token-based algorithms, there is a token to represent the permission. n Whoever has the token, has the permission, and can pass it on.

18. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Perpetuum mobile n The token travels around (say, a ring). n When a process receives the token, it may use the resource, if it so wishes. n Then the process passes the token on.

19. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Token-asking algorithms n The token does not travel around if it is not needed. n When a process needs the token, it asks for it. n Requests are queued.