1. Distributed Systems Topic 6: Concurrency Control Dr. Michael R. Lyu
Computer Science & Engineering Department
The Chinese University of Hong Kong
We have discussed two basic techniques to achieve location and migration transparency, i.e. naming and trading. We also examined time, coordination, and replication issues.
We are going to look at basic techniques that are widely used to achieve concurrency transparency. This current session can be summarized through: How can multiple components in a distributed system use a shared component concurrently without violating the integrity of the component?
This question is of fundamental importance as there are very few distributed systems where all components are only used by a single component at a time.
During this session, we are going to review pessimistic and optimistic concurrency control techniques. They either use locking techniques that restrict the potential schedules of concurrent component to those that cannot violate the integrity of a shared component or that detect potentially integrity violating schedules and force the components to undo their changes in order to restore integrity.

2. Outline 1 Motivation 2 Concurrency Control Techniques
– two-phase locking protocol
– optimistic concurrency control protocol
– comparison
3 Lock Compatibility Matrix in Concurrency Control Service
4 Summary
We are going to start with a motivation, where we identify two different types of integrity violations that may happen through unrestricted concurrent access of a shared component. We give examples for each of these types.
The focus of this session is on the explanation of basic concurrency control techniques where we introduce pessimistic and optimistic techniques.
The most commonly used pessimistic technique is two-phase locking (2PL), where components lock shared resources in particular modes and a lock request in a mode that is not compatible to previously granted locks makes the requester to wait until the lock can be granted.
With optimistic techniques no explicit measures are taken to prevent integrity violation, but the access patterns of resources are recorded. At a certain point in time the recorded access patterns are checked whether they could have violated the integrity and if so the changes have to be undone.
We draw a comparison between these two concurrency control techniques
We then summarize a lock compatibility matrix used in a typical concurrency control service in distributed system framework.
Finally a summary indicates the learning goals of this session, highlights what you should remember.

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 (requiring safety, liveness, and ordering).
Components of distributed systems frequently use resources maintained by other components in a concurrent manner. These resources may be fairly heterogeneous. They may be
hardware components (e.g. a printer).
operating system resources (e.g. files or sockets),
databases (e.g. the bank accounts kept by different banks) or
shared distributed system service objects (e.g. naming service objects, security service objects).
For some types of accesses, resources may have to be accessed in mutual exclusion
It does not make sense to have print jobs of different users being printed in an interleaved way.
Only one user should be editing a file at a time, otherwise the changes made by other users would be overwritten if the last user saves his or her file.
integrity of databases or distributed system objects may be lost through concurrent updates.
Hence, the need arises to restrict the concurrent access of multiple components to a shared resource in a sensible way.
Resources sharing may require mutual exclusion properties, including safety, liveness, and ordering (discussed in the last lecture).

4. 1 Motivation
Concurrent access and updates of resources which maintain state information may lead to:
lost updates
inconsistent retrievals.
Motivating example for lost updates:
Cash withdrawal from ATM, and concurrently
Credit of a check.
Motivating example for inconsistent retrievals:
Funds transfer between accounts of one customer
Summary of account balances (Report for Inland Revenue Department).
Let us now look at the two types of integrity violations that can happen through concurrent accesses. These types of violations are commonly referred to as lost updates and inconsistent retrievals.
On the next slides we are going to look at instances of these types. We use examples taken from the ATM network.
The scenario motivating lost updates is a cash withdrawal by a customer from an ATM and a concurrent credit of a check. We will see that the unrestricted concurrent access may lead to a situation where money disappears. This is certainly undesirable.
The scenario motivating inconsistent retrievals is a funds transfer between accounts of one customer and the concurrent production of a statement for Inland Revenue Department that includes a sum of the account balances. We will reveal a concurrent schedule where the Internal Revenue statement does not reflect the proper sum of account balances because money was on its way from one account to another when the sum was computed.

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;
float get_balance() {return balance;};
For the example we need to refer to the declaration of an account object, which we assume is a distributed object implemented in C++. The slide above gives the implementation of the object.
The object stores the balance in the instance variable balance. The object can return the current balance through operation get_balance().
The object also supports a debit() and a credit() operation. The debit() operation subtracts the amount passed as a parameter from the balance and the credit() operation adds the amount passed as a parameter.

6. 1 Lost Updates Time Customer@ATM: Clerk@Counter:
Balance of account anAcc at t0 is 100 t0
anAcc->debit(50):
new=50;
balance=50;
anAcc->credit(50):
new=150;
balance=150; t1 t2 t3 t4 t5 t6
This slide displays a schedule of two concurrent requests to an instance of the account type that causes a lost update.
Let us assume that the balance of the account identified by the reference anAcc is $100 at the beginning (t0). Assume further that a customer withdraws $50 from an ATM and a clerk credits a check worth $50 to the account. Hence the object referenced by anAcc is concurrently used by two distributed components, the ATM Controller and the user interface the clerk uses to credit the check.
At t1, the ATM controller invokes the debit operation, and at t2 the clerk invokes the credit operation. The difference between t1 and t2 is in reality very small, in the order of less than a millisecond.
At t3 the debit operation computes the new balance as 50 and at t4 the credit operation computes the new balance as 150.
At t5 the debit operation assigns the new balance of 50 to the instance variable of the object and at t6 the credit operation assigns the new value of 150 and overwrites the change done by the debit operation: The update of the debit operation is lost.

7. 1 Inconsistent Retrievals
Funds transfer:
Inland Revenue Report: t0 t1 t2 t3 t4
Time
Balances at t0 Acc1: 7500, Acc2: 0 t5 t6 t7
Acc1->debit(7500):
Acc1.new=0;
Acc1.balance=0;
Acc2->credit(7500):
Acc2.new=7500;
Acc2.balance=7500;
float sum=0;
sum+=Acc2->get_bal():
sum=0;
sum+=Acc1->get_bal():
This slide displays a schedule of two concurrent requests to two instance of account type that causes an inconsistent retrieval.
We assume that at the beginning of the scenario, the balance of account Acc1 is $7500, while the other account Acc2 does not contain any money. The scenario assumes that there is a funds transfer, displayed on the left-hand side, that transfers the sum of $7500 from Acc1 to Acc2. The transfer is implemented by invoking the debit operation on Acc1 and the credit operation on Acc2. The right-hand side displays the steps that need to be performed to compute the sum of both accounts, which may be reported to Inland Revenue Department.
The timing of the operations is such that the sum of the balance for the Inland Revenue report is computed while the money is on neither of the two accounts, leading to a sum of 0, i.e. an inconsistent retrieval.
This example suggests that integrity violations can also arise with operations that do not change shared resources. Hence it is not sufficient for a concurrency control technique to deal only with those schedules that modify shared resources.

8. 2 Concurrency Control Techniques
1 Assessment Criteria
2 Two Phase Locking (2PL)
3 Optimistic Concurrency Control
4 Comparison
Having motivated the need for controlling concurrent access to resources, we can now have a closer look at two concurrency control techniques.
We shall attempt a comparison of two phase locking and optimistic concurrency control in this part of the lecture. The comparison is based on some assessment criteria that we outline in the first part.
We then discuss two phase locking, the most commonly used concurrency control technique.
After that we discuss optimistic concurrency control.
The comparison will reveal in which situations which technique is more appropriate.

9. 2.1 Assessment Criteria Serializability Deadlock Freedom Fairness
Degree of Concurrency
Complexity
The most important criterion for a concurrency control technique is serializability. Concurrent threads are serializable, if they can be executed one after another and have the same effect on shared resources. It is proven that serializable threads do not lead to lost updates and inconsistent retrievals. You may want to think about why the examples given in the previous parts are not serializable.
Concurrency control techniques that use locking may force threads to wait for other threads to release a lock before they can access a resource. This may lead to situations where the wait-for relationship is cyclic and threads are deadlocked. We are therefore interested in whether deadlocks can occur with a given concurrency control technique, how they can be detected and how they can be resolved.
Fairness refers to the fact whether all threads have the same chances to get access to a resources.
We are also interested in the degree of concurrency that a control scheme allows threads to perform. It is obviously undesirable to restrict schedules that do not cause serializability problems.
On the other hand, to compute precisely those and only those schedules that are serializable may be very complex, and we are interested in the complexity that a concurrency control schedule implies, in order to estimate its performance overhead.

10. 2.1 Serial Equivalence
Transactions are sequences of operations that are clustered together.
Interleaving – concurrent operations in multiple transactions
Serially equivalent interleaving – An interleaving of the operations of transactions in which the combined effect is the same as if the transaction had been performed one at a time in some order.
Serial equivalence as a criterion for correct concurrent execution prevents lost updates and inconsistent retrievals.
Transactions are sequences of operations that are clustered together.
Interleaving means operations in multiple transactions are concurrently executed.
If each of several transactions is known to have the correct effect when it is done on its own, then we can infer that if these transactions are done one at a time in some order the combined effect will also be correct. An interleaving of the operations of transactions in which the combined effect is the same as if the transactions had been performed one at a time in some order is a serially equivalent interleaving.
When we say that two different transactions have the same effect as one another, we mean that the read operations return the same values and that the instance variable of the objects have the same values at the end.
The use of serial equivalence as a criterion for correct concurrent execution prevents the occurrence of lost updates and inconsistent retrievals.

11. 2.1 Serial Equivalence
When a pair of operations conflicts, it means their combined effect depends on the order in which they are executed.
For two transactions to be serially equivalent, it is necessary and sufficient that all pairs of conflicting operations of the two transactions be executed in the same order at all of the objects they both access.
For any pair transactions, it is possible to determine the order of pairs of conflicting operations on objects accessed by both of them. Serial equivalence can be defined in terms of operation conflicts as follows:
For two transactions to be serially equivalent, it is necessary and sufficient that all pairs of conflicting operations of the two transactions be executed in the same order at all of the objects they both access.
Conflicting operations
When we say that a pair of operations conflicts we mean that their combined effect depends on the order in which they are executed. To simplify matters we consider a pair of operations read and write. Read access the value of an object and write changes its value. The effect of an operation refers to the value of an object set by a write operation and the result returned by a read operation. The conflict rules for read and write operations are given in the above table.

12. 2.1 Serial Equivalence Examples
Transaction T: Read(a); Write(b,3); Read(c);
Transaction U: Write(a,2); Write(b,4);
Assume a is 0 and b is 0 at t0,
Time
Transaction T
Transaction U t0
Read(a);
Write(b,3);
Read(c);
Write(a,2);
Write(b,4); t1 t2 t3 t4 t5 t6
Example 1
Time
Transaction T
Transaction U t0
Read(a);
Write(b,3);
Read(c);
Write(a,2);
Write(b,4); t1 t2 t3 t4 t5 t6
Example 2
Example 1 shows the interleaving of transaction T before transaction U. Premature writes may occur if T aborts and U commits, causing writing wrong value to data b.
Example 2 shows the interleaving of transaction U before transaction T. Dirty reads may occur if U aborts and T commits, causing reading wrong value of data a. (There is also a premature writes possibility for writing wrong value of data b).

13. 2.1 Recoverability from Aborts
Dirty reads
Read the uncommitted state of other transactions
In Example 2, transaction U aborts after transaction T has committed
Premature writes
Write on the same object of another transaction that may abort
In Example 1, transaction U commits and then transaction T aborts
Cascading aborts
The aborting of latter transactions may cause further transactions to be aborted. Such situations are called cascading aborts
Strict transactions
The service delays both read and write operations on an object until all transactions that previously wrote that object have either committed or aborted. This can avoid premature writes and cascading aborts.
Dirty Read – The isolation property of transactions requires that transactions do not see the uncommitted state of other transactions. The “dirty read” problem is caused by the interaction between a read operation in one transaction and an earlier write operation in another transaction on the same object. In example 2, transaction U aborts after transaction T has committed. Then transaction T will have seen a value that never existed, since object a will be restored to its original value.
Premature Write – Consider another implications of the possibility that a transaction may abort. This one is related to the interaction between write operations on the same object belonging to different transactions. Now consider example 1 when transaction U commits and then transaction T aborts. The value of object b should be 4, but as the ‘before image’ of transaction T on object b’s write is 0, we get the wrong value of 0. To ensure correct results in a recovery scheme that uses before images, write operations must be delayed until earlier transactions that updated the same objects have either committed or aborted. However, premature writes are fine if the recovery does not use the ‘before image’ to overwrite objects written by other transactions. That is, if ‘overlaps’ are allowed for write operations of different transactions on the same object, then premature writes may not cause problems (such as cascading aborts).
Cascading aborts – The aborting of latter transactions may cause further transactions to be aborted. Such situations are called cascading aborts. To avoid cascading aborts, transactions are only allowed to read objects that were written by committed transactions. To ensure that this is the case, any read operation must be delayed until other transactions that applied a write operation to the same object have committed or aborted. The avoidance of cascading aborts is a stronger condition than recoverability.
Generally, it is required that transactions delay both their read and write operations so as to avoid both ‘dirty reads’ and ‘premature writes’. The executions of transactions are called strict if the service delays both read and write operations on an object until all transactions that previously wrote that object have either committed or aborted. The strict execution of transactions enforces the desired property of isolation.

14. 2.2 Two Phase Locking (2PL)
The most popular concurrency control technique. Used in:
Relational Database Management System (RDBMS)
Object Database Management System (ODBMS)
Transaction Monitor
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.
Two phase locking (2PL) is the most popular concurrency control technique. It is used in almost all relational database management systems and it is also used in many object database management systems. Mainframe computers, such as IBM/370, have a transaction monitor as part of their operating system which also performs two phase locking so that concurrent access between resources (usually files) can be restricted to serializable schedules.
The principal component that implements 2PL is a lock manager from which concurrent processes or threads acquire locks on every shared resource they access.
The lock manager investigates the request and compares it with the locks that were already granted on the resource. If the requested lock does not conflict with an already granted lock, the lock manager will grant the lock and note that the requester is now using the resource.
Two phase locking guarantees serializability.

15. 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.
Let us now take a closer look at locks.
Locks are tokens indicating that a process or thread accesses a resource in a particular mode.
There have to be at least two different lock modes: read and write. Many implementations of 2PL, however, define additional lock modes for optimization purposes.
Locks are used to indicate to concurrent processes or threads the way in which a resource is used. The lock manager, therefore, maintains a set of locks for each resource. An item in the set would then indicate that a particular process uses the resource in the mode identified by the lock.

16. 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:
The lock manager grants locks to requesting processes or threads on the basis of already granted locks and their compatibility with the requested lock.
The very core of any pessimistic concurrency control technique that is based on locking is the definition of a lock compatibility matrix. It defines the different lock modes and the compatibility between them.
The minimal matrix is displayed at the bottom of the slide. It defines that read locks are compatible to previously granted read locks, but write locks are neither compatible to already granted read locks nor to already granted write locks.
For a lock request the compatibility has to be checked with every lock that has been granted before and the request is only granted if the lock is compatible to every single lock that has been granted before.

17. 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 that the lock cannot be granted.
If a single lock that has been granted on a resource conflicts with a lock request for that resource a locking conflict arises.
On the occasion of a locking conflict, the requester cannot use the resource until the conflicting lock has been released.
There are two approaches to handle locking conflicts.
The requesting process can be forced to wait until the conflicting locks are released. This may, however, be too restrictive since the process or thread may well do other computations in between.
The better approach is, therefore, to tell the process that the lock cannot be granted. It can then continue with other processing until a point in time when it definitely needs to get access to the resource.
Several 2PL implementations provide two locking operations, a blocking and a non-blocking one. Then the requester can decide whether or not it wants to wait for a lock to be granted by invoking one or the other locking operation.

18. 2.2 Example (Avoiding Lost Updates)
Time
Balance of account anAcc at t0 is 100 t0
anAcc->debit(50):
anAcc->lock(write);
new=50;
balance=50;
anAcc->unlock(write);
anAcc->credit(50):
new=100;
balance=100; t1 t2 t3 t4 t5 t6
This slide displays how the lost update problem that we discussed during the motivation is prevented using locking.
The difference now is that before the account objects are changed, the debit and credit operations request a lock on the account object from the lock manager.
Then the lock manager detects a write/write locking conflict and forces the second process to wait until the first process has released its lock. Then the second process reads the up-to-date value of the balance of the account and modifies it without losing the update of the first process.

19. 2.2 Deadlocks
Locking 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.
Given that the lock manager may force processes or threads to wait for other processes to release locks, situations may arise where two or more processes or threads are mutually waiting for each other to release their locks. Hence locking process in 2PL is not deadlock-free.
These situations are called deadlocks and are very undesirable as they block threads and prevent them from finishing their jobs.
Hence deadlocks have to be detected by the lock manager. The lock manager, therefore, has to maintain data structures that can be used to efficiently decide which process or thread has been granted access to which resource. It also has to maintain a list that identifies which process is waiting for which resource. To detect a deadlock, the lock manager then has to find cycles in the waits-for relationship.
To resolve a deadlock lock managers have to select one process or thread that participates in such a cycle and abort it.
An abortion of a process requires to undo all actions that the process has performed and to release all locks the process has held.

20. 2.2 Locking Number of locks held by one process Time
Processes acquire locks before they access shared resources and release locks afterwards.
2-phase locking : Processes do not acquire locks once they have released a lock.
Strict 2-phase locking : A transaction does not release any of its locks until after it terminates (by committing or aborting)
Typical 2PL locking profile of a process:
2PL is based on the assumption that processes or threads always acquire locks before they access a shared resource and that they release a lock if they do not need the resource anymore.
In 2PL, processes do not acquire locks once they have released a lock. This means that a process operates in cycles where there is a lock acquisition phase and a lock release phase in each cycle. 2PL has its name due to these two phases. The reason for not acquiring any more locks once a lock is released is to avoid deadlocks. The algorithm tries to collect all the locks first. If any lock is not acquired on the first attempt the algorithm can abort the operations and give up all the locks it had previously held, and starts all over again.
Strict 2PL: A transaction does not release any of its locks until after it terminates (by committing). Strict 2PL is not deadlock-free, unless combined with conservative 2PL. But it helps to overcome the update lost problem even in the presence of failure. This is because a process can abort all its operations consistently since no locks have been released before it terminates. If all transactions in a schedule S follow the strict 2PL protocol, S is called a strict schedule.
The figure at the bottom of the slide displays the typical locking profile of a process or thread. It would acquire a number of locks during the acquisition phase then hold these locks for a certain period of time to do its operations and then release the locks again. Operations may be interleaved with lock acquisition and release. Very often, however, all locks are released altogether.
Number of
locks held
by one
process
Time

21. 2.2 Example T1 T2 write(A) write(B)
Apply two-phase locking protocol to the schedules below by adding statements like S-lock(A), X-lock(A), and unlock(A).
S-lock stands for Share lock, e.g. READ LOCK
X-lock stands for eXclusive lock, e.g. WRITE LOCK T1 T2
write(A)
write(B)
There are 2 transactions in this example. We want to apply two-phase locking protocol to the schedules.
Exclusive locks: Once an exclusive lock is assigned to a transaction for a particular data object, other transactions cannot modify or access this object. Transactions that check for the existence of exclusive locks, or that want to set exclusive or shared lock, conflict with the existing exclusive lock of another transaction. They do not have access to the locked object.
Once a shared lock is assigned to a transaction for a particular data object, concurrent transactions can access the object but not modify it. Other transactions can set a shared lock, but not an exclusive locks for this object.

22. 2.2 Example Answer T1 T2 X-lock(A) write(A) X-lock(B) unlock(A)
write(B)
unlock(B)
For 2PL, processes do not acquire locks once they have released a lock.
For T1, it needs to write A, so it needs to lock A with X-lock.
Holding the X-lock for B (“X-lock(B)”) can be done before or after “write(A)” but must before “unlock(A)”. It is because once a lock is released, processes can not acquire locks again.
T2 only can lock A after T1 release the lock.
Holding the X-lock for B (“X-lock(B)”) should be done before “unlock(A)”.
After write(A) and write(B), T2 can release the locks for both A and B

23. 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.
Hierarchic locking as a compromise.
Two phase locking is applicable to resources of any granularity. It works for distributed system objects as well as for files and directories or even complete databases.
However, the degree of concurrency that is achieved with 2PL depends on the granularity that is used for locking. A high degree of concurrency is achieved with small locking granules. If a set of tuples in a relational database are locked, other processes may concurrently lock other tuples and they may concurrently finish their job. If, however, the complete database is locked, the processes will have to wait for each other.
The disadvantage of choosing a small locking granularity is that a huge number of locks have to be acquired if many granules have to be locked. In the database example, all the tuples of a table will have to be locked if the whole table must be locked, while only a single lock would be required if the granularity would be database tables. Hence small granules may impose a considerable complexity on the locking scheme.
We have now come across a trade-off between the degree of concurrency that is achievable and the locking overhead. If we decrease the granularity we can process more processes concurrently but have to be prepared to spend higher costs for the management of locks.
The dilemma can be resolved using an optimization, which is hierarchic locking.

24. 2.2 Hierarchic 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:
The observation that is exploited for hierarchic locking is that resources are very often aggregated in more coarse-grained container resources in a hierarchic manner. Directories, for instance, contain files, files contain records and records contain attributes. Likewise, distributed system objects may have attributes that contain sets or sequences of other objects.
The idea of hierarchic locking is then to indicate at container resources that a process is intending to use resources contained in that container in a particular mode.
The hierarchic locking schemes therefore introduce intentional locks, such as intention read and intention write locks.
Processes that want to lock a certain resource would then acquire intention locks on the container of that resource and all its containers.
The lock compatibility matrix is defined in a way that a locking conflict will arise if a container object is already locked in either read or write mode.
Hence the advantage of hierarchic locking is that it enables different lock granularities to be used at the same time while the number of locks that have to be acquired for a single resource is limited by the depth of the container aggregation hierarchy.

25. 2.2 Transparency of Locking
Who is acquiring locks? Options:
Concurrency control infrastructure
Implementation of resource components
Clients of resource 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!
The last question that we have to discuss is who is acquiring the locks, i.e. who invokes the lock operation for a resource. The options are:
the concurrency control infrastructure, such as the concurrency control manager of a database management system;
the implementation of the resource components; or
the clients of the resource components.
The first option is very much desirable as then concurrency control would be transparent to the application programmers of both the component and its clients.
Unfortunately this is only possible on limited occasions (in a database system) because the concurrency control manager would have to manage all resources and it would have to be informed about every single resource access.
The last option is very undesirable and it is in fact always avoidable. Hence distributed components should be designed in a way that concurrency control is hidden within their implementation and not exposed at their interface.

26. 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.
In general, the complexity of two phase locking is linear in the number of the accessed resources. With hierarchical locking it is even slightly more complex as also containers of resources have to be locked in intentional mode.
This overhead, however, is unreasonable if the probability of a locking conflict is very limited.
Given the motivating examples we discussed earlier, it is quite unlikely that you withdraw cash from an ATM in that very millisecond when a clerk credits a check. This is where optimistic concurrency control comes in. It follows a laissez-faires approach and works as a watchdog that detects conflicts only when they really happen.
The principle idea can be sketched as follows: Every thread or process works on its private copy of the set of shared resources. This copy must not be understood as a physical copy (which would be far too expensive to create), but the concurrency control manager provides every process or thread with a logical copy. While a process or thread accesses resources, the concurrency control manager keeps a log of them. At a certain point in time, the access patterns are validated against conflicts with concurrent processes or threads. If no conflicts occurred the changes done can be made known to the global set of resources. Otherwise the process has to discard its logical copy and start over again on an up-to-date copy of the resources.

27. 2.3 Validation Prerequisites
Units (distinguishable segments of the operation sequence) 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.
As a pre-requisite for optimistic concurrency control it is required to separate the overall sequence of operations a process performs into distinguishable units. A validation of the access pattern of a unit is then performed during a validation phase at the end of each unit.
The validation procedure requires the gathering of certain information during the course of each concurrency control unit. The following information is needed:
The start time when unit U began execution will be denoted as st(U).
The start of the validation for unit U will be denoted as TS(U).
The ending time for unit U will be denoted as E(U).
The set of resources U has accessed in read mode will be denoted as RS(U) and the set of resources U has accessed in write mode will be denoted as WS(U).
Note that the approach relies on the provision of precise time information. The provision of precise time information in a distributed setting is a serious problem in its own right, as there is no global clock.
A global clock is often implemented by the synchronization of local clocks. The distributed system Time Service, for instance, provides primitives for these concerns.

28. 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}
The validation of a unit has to be done against all concurrent units that have already been successfully validated. We therefore denote the set of those units as the validation set VU(u). Its formal definition is given in the last line of the slide.
VU(u) contains all units that were active concurrently with u but have been validated before.

29. 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.
During the validation phase, the concurrency control manager has to look for two types of conflicts: read/write and write/write conflicts.
The first bullet point on this slide gives the formal definition of a read/write conflict.
A read/write conflict has occurred if the unit to be validated has written a resource that a validated unit has read or if the unit has read a resource that a validated unit has written.
In these cases the unit cannot be completed but has to be undone.

30. 2.3 Write/Write Conflict Detection
A write/write conflict occurred 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.
Likewise, a write/write conflict occurred if the unit has modified a resource that a validated unit has modified as well.
Again, the unit that is being validated cannot be completed and needs to be undone.
After the undo of the unit, the unit is usually started over again on a fresh copy of the set of shared resources and might then succeed.
Other concepts: Backward validation vs. forward validation; timestamp ordering (details in textbook).

31. 2.4 Comparison Both approaches Pessimistic control (2PL):
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.
Let us now summarize what we have learned in an assessment of the two techniques.
Both, pessimistic (2PL) and optimistic techniques, achieve the most important criterion as they guarantee serializability of processes. Both approaches, however, also impose a serious complexity in that they need an ability to undo the effect of processes and threads. With 2PL this is needed to recover from a deadlock and with optimistic concurrency control this is required to undo the effect of a conflicting unit.
Pessimistic techniques cause a considerable concurrency control overhead through locking and they are not deadlock-free. However, they work sufficiently efficient also in the case of a likely conflict.
A serious advantage of optimistic techniques is that they have a negligible overhead when conflicts are unlikely. Furthermore they are deadlock-free. However the computation of conflict sets is very very difficult and complex in a distributed setting. Moreover, the optimistic techniques assume the existence of a precise clock, which are generally not available in a distributed setting.
In summary, the disadvantages of optimistic concurrency control overwhelm the advantages and in most distributed systems, concurrency is controlled using pessimistic techniques.

32. 3 An Additional Lock Compatibility
Some concurrency control services support hierarchic locking.
Upgrade locks for decreasing probability of deadlocks.
Compatibility matrix:
Some Concurrency Control services support hierarchic locking, as many objects take the role of container objects.
As a further optimization the services defines a lock type for upgrade locks. Upgrade locks are read locks that are not compatible to themselves. Upgrade locks are used in occasions when the requester knows that it only needs a read lock to start with but later will have to acquire a write lock on that resource as well. If two processes are in this situation, they would run into a deadlock if they used only read locks. With upgrade locks the deadlock can be prevented as the second process trying to acquire the upgrade lock will be delayed already.
In summary the lock-compatibility matrix is displayed at the bottom of the slide.

33. 4 Summary Lost updates and inconsistent retrievals.
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.
Additional lock compatibility is introduced.
Read Textbook Chapter 16 (16.2 and 16.3 in next lecture).
In this week's lecture we have seen two motivations for concurrency control: to avoid lost updates and inconsistent retrievals.
We then have compared pessimistic and optimistic concurrency control. We have come to the conclusion that the considerable overhead of the computation of conflict sets and the provision of a clock let optimistic techniques seem less adequate for concurrency control in a distributed setting.
We have briefly discussed the additional Concurrency Control service to include
Read Textbook Chapter 16 (16.2 and 16.3 will be discussed in detail in the next lecture).