Distributed Systems

1. Distributed Systems Topic 10: Concurrency Control Dr. Michael R. Lyu Computer Science & Engineering Department The Chinese University of Hong Kong

2. Outline 1 Motivation 2 Concurrency Control Techniques 3 CORBA Concurrency Control Service 4 Summary

3. 1 Motivation • Components of distributed systems use shared resources concurrently: • Hardware Components • Operating system resources • Databases • Objects • Resources may have to be accessed in mutual exclusion.

4. 1 Motivation • Concurrent access and updates of resources which maintain state information may lead to: • lost updates • inconsistent analysis. • Motivating example for lost updates: • Cash withdrawal from ATM and concurrent • Credit of check. • Motivating example for inconsistent analysis: • Funds transfer between accounts of one customer • Sum of account balances (Report for Internal Revenue).

5. 1 Motivating Examples class Account { protected: float balance; public: void debit(float amount){ float new=balance-amount; balance=new; }; void credit(float amount) { float new=balance+amount; balance=new; }; float get_balance() {return balance;}; };

6. Balance of account anAcc at t0 is 100 Customer@ATM: Clerk@Counter: t0 anAcc->debit(50): new=50; balance=50; t1 anAcc->credit(50); new=150; balance=150; t2 t3 t4 t5 t6 Time 1 Lost Updates

7. Balances at t0Acc1: 7500, Acc2: 0 Funds transfer: Internal Revenue Report: t0 Acc1->debit(7500): Acc1.new=0; Acc1.balance=0; Acc2->credit(7500): Acc2.new=7500; Acc2.balance=7500; t1 float sum=0; sum+=Acc2->get_bal(): sum=0; sum+=Acc1->get_bal(): sum=0; t2 t3 t4 t5 t6 t7 Time 1 Inconsistent Analysis

8. 2 Concurrency Control Techniques 1 Assessment Criteria 2 Two Phase Locking (2PL) 3 Optimistic Concurrency Control 4 Comparison

9. 2.1 Assessment Criteria • Serializability • Deadlock Freedom • Fairness • Degree of Concurrency • Complexity

10. 2.2 Two Phase Locking (2PL) • The most popular concurrency control technique. Used in: • RDBMSs (Oracle, Sybase, DB/2, etc.) • ODBMSs (O2, ObjectStore, Versant, etc.) • Transaction Monitors (CICS, etc) • Concurrent processes acquire locks on shared resources from lock manager. • Lock manager grants lock if request does not conflict with already granted locks. • Guarantees serializability.

11. 2.2 Locks • A lock is a token that indicates that a process accesses a resource in a particular mode. • Minimal lock modes: read and write. • Locks are used to indicate to concurrent processes the current use of that resource.

12. Number of locks held Time 2.2 Locking • Processes acquire locks before they access shared resources and release locks afterwards. • 2PL: Processes do not acquire locks once they have released a lock. • Typical 2PL locking profile of a process:

13. 2.2 Lock Compatibility • Lock manager grants locks. • Grant depends on compatibility of acquisition request with modes of already granted locks. • Compatibility defined in lock compatibility matrix. • Minimal lock compatibility matrix:

14. 2.2 Locking Conflicts • Lock requests cannot be granted if incompatible locks are held by concurrent processes. • This is referred to as a locking conflict. • Approaches to handle conflicts: • Force requesting process to wait until conflicting locks are released. • Tell process or thread that lock cannot be granted.

15. Balance of account anAcc at t0 is 100 Customer@ATM: Clerk@Counter: anAcc->debit(50): anAcc->lock(write); new=50; balance=50; anAcc->unlock(write); t0 anAcc->credit(50); anAcc->lock(write); new=100; balance=100; anAcc->unlock(write); t1 t2 t3 t4 t5 t6 Time 2.2 Example (Avoiding Lost Updates)

16. 2.2 Deadlocks • 2PL may lead to situations where processes are waiting for each other to release locks. • These situations are called deadlocks. • Deadlocks have to be detected by the lock manager. • Deadlocks have to be resolved by aborting one or several of the processes involved. • This requires to undo all the actions that these processes have done.

17. 2.2 Locking Granularity • 2PL applicable to resources of any granularity. • High degree of concurrency with small locking granularity. • For small granules large number of locks required. • May involve significant locking overhead. • Trade-off between degree of concurrency and locking overhead. • Hierarchical locking as a compromise.

18. 2.2 Hierarchical Locking • Used with container resources, e.g. • file (containing records) • set or sequence (containing objects) • Lock modes intention read (IR) and intention write (IW). • Lock compatibility:

19. 2.2 Transparency of Locking • Who is acquiring locks? • Concurrency control infrastructure • Implementation of components • Clients of components • First option desirable but not always possible: • Infrastructure must manage all resources • Infrastructure must know all resource accesses. • Last option is undesirable and avoidable!

20. 2.3 Optimistic Concurrency Control • Complexity of 2PL is linear in number of accessed resources. • Unreasonable if conflicts are unlikely. • Idea of optimistic concurrency control: • Processes modify (logical) copies of resources. • Validate access pattern against conflicts with concurrent processes. • If no conflicts: write copy back. • else: undo all modifications and start over again.

21. 2.3 Validation Prerequisites • Units of concurrency control required. • For each unit the following information has to be gathered: • Starting time of the unit st(U). • Time stamp for start of validation TS(U). • Ending time of unit E(U). • Read and write sets RS(U) and WS(U). • Needs precise time information. • Requires synchronization of local clocks.

22. 2.3 Validation Set • A unit u has to be validated against a set of other units VU(u) that have been validated earlier. • VU(u) is formally defined as: VU(u):={u´|st(u)<E(u´) and u´ has been validated}

23. 2.3 Read/Write Conflict Detection • A read/write conflict occurred during the course of a unit u iff: u´  VU(u) : WS(u)  RS(u´)  RS(u)  WS(u´)  • Then u has written a resource that this other unit u´ has read or vice versa. • Then u cannot be completed and has to be undone.

24. 2.3 Write/Write Conflict Detection • A write/write conflict occured during the course of a unit u iff: u´  VU(u) : WS(u)  WS(u´)  • Then u has modified a resource that this other unit u´ has modified as well. • Then u cannot be completed and has to be undone.

25. 2.4 Comparison • Both approaches • guarantee serializsability. • need ability to undo processes. • Pessimistic control (2PL): • overhead for locking. • not deadlock free • works efficient also in the case of likely conflicts • Optimistic control: • small overhead when conflicts are unlikely. • deadlock free. • computation of conflict sets difficult in distributed systems. • overhead for time synchronization.

26. Application Objects CORBAfacilities Object Request Broker CORBAservices Concurrency Control 3 CORBA Concurrency Control Service

27. 3 Lock Compatibility • CORBA concurrency control service supports hierarchical locking. • Upgrade locks for decreasing probability of deadlocks. • Compatibility matrix:

28. 3 Locksets • A lockset is associated to a resource (usually in the implementation of that resource). • Each shared resource has a lockset. • Operations of that resource acquire locks before they access or modify the resource.

29. 3 The IDL Interfaces interface LocksetFactory { LockSet create(); }; interface Lockset { void lock(in lock_mode mode); boolean try_lock(in lock_mode mode); void unlock(in lock_mode mode); void change_mode(in lock_mode held, in lock_mode new); };

30. 4 Summary • Lost updates and inconsistent analysis. • Pessimistic vs. optimistic concurrency control • Pessimistic control: • higher overhead for locking. • works efficiently in cases where conflicts are likely • Optimistic control: • small overhead when conflicts are unlikely. • distributed computation of conflict sets expensive. • requires global clock. • CORBA uses pessimistic two-phase locking.