Synchronisation Mechanisms

We have described the synchronisation mechanisms between end systems when they communicate. We now discuss synchronisation between instances of communication. In a distributed system, many concurrent applications may attempt to access the same object simultaneously. The classic example is that of access to a bank account database and is shown in #fnconsist#607>. Two clerks start to update the same bank account as they clear two separate cheques:

Figure: Distributed Access and Consistency

Consider the different order in which these operations can occur in #fnconsist#611>: If B.1 happens between A.1 and A.3, or A.1 happens between B.1 and B.3, account P would be short 23 or 42 dollars respectively. Any other ordering has the desired effect. What is required is some synchronization mechanism. It is worth noting for now that if A and B had been accessing different accounts, or A and/or B only <#612#> read<#612#> the account, then no synchronization would be necessary. The solution is to provide a locking mechanism. Each application must acquire a lock before attempting its set of operations. Setting locks must be indivisible with respect to the normal operations. Locks should apply to groups of operation at an appropriate level of granularity. There is a tradeoff of concurrency versus blocking, which will need adjusting based on the number of commonly linked operations by a single client versus the number of clients concurrently carrying out operations. A problem then arises as to when to release the locks: Next we see how transactions help structure these sets of operations.