6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 32.2.11 So if we go back to our bank account example, here is an easy way Serializing access to a shared state variable to use this idea to fix the problem. Here we serialize both the [detine (make-acceumt halance) deposits and withdrawals if t> balane anent (begin tset Balance(- balance amount)) With this implementation, two processes cannot be withdrawing Insuffieient fundal from or depositing into a single account concurrently. This eliminates the source of the error illustrated in our earlier bank (Iet ((protected (make-xerializer))t account example, where Peter changes the account balance Protected withdraW) tween the times when Paul accesses the balance to compute the holand 1 t lerrer "unknown regu们t”m)))) new value and when Paul actually performs the assignment On th other hand, each account has its own serializer, so that deposits peter (make-account 100)) and withdrawals for different accounts can proceed concurrently. 4 6.001 Notes: Section 32.3 Slide 323.1 Multiple shared resources Serializers provide a powerful abstraction that helps isolate the complexities of concurrent programs so that they can be dealt with carefully and(hopefully) correctly. However, while using =2 balance))) serializers is relatively straightforward when there is only a single shared resource(such as a single bank account), ((account2 'deposit) difference))) concurrent programming can be treacherously difficult when there are multiple shared resources To see some of the difficulties that can arise, suppose we wish to swap the balances in two bank accounts. We access each account to find the balance, compute the difference between the balances,withdraw this difference from one account, and deposi /p it in the other account. We could implement this with the code shown on the slide Slide 32.3.2 Multiple shared resources This procedure works well when only a single process is trying to do the exchange. Suppose, however, that Peter and Paul both have (define (erchange account account2 let ((difference (-(account balance access to accounts al. a2 and a3, and that peter exchanges al and nt2 balance)) a2 while Paul concurrently exchanges al and a3 ( account2‘ deposit) difference)》 Even with account deposits and withdrawals serialize A3=200 individual accounts(as in the make-account procedure shown (exchange a1 a2)&(exchange a2 a3) above), exchange can still produce incorrect results. For 1. Difference a1 &82= d1 example, Peter might compute the difference in the balances for al 3. Deposit d1 to a2 6+a3=300 and a2 but then paul might change the balance in al before peter 4. Difference a1 &a3= d2 2+a1=0 is able to complete the exchange 5. Withdraw d2 from a1 In more specific detail, the stages of the computation of the two 6. Deposit d2 to a3 exchanges are shown. We know by serialization that steps 2 and 5 must each complete in entirety before the other can begin. However, it is still possible for the sequence of steps shown on the right to take place, resulting in an incorrect behavior(the total amount of money is preserved but we intended to simply swap amounts between the accounts, meaning there should be 100, 200 and 300 dollars in the accounts)6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 32.2.11 So if we go back to our bank account example, here is an easy way to use this idea to fix the problem. Here we serialize both the deposits and withdrawals. With this implementation, two processes cannot be withdrawing from or depositing into a single account concurrently. This eliminates the source of the error illustrated in our earlier bank account example, where Peter changes the account balance between the times when Paul accesses the balance to compute the new value and when Paul actually performs the assignment. On the other hand, each account has its own serializer, so that deposits and withdrawals for different accounts can proceed concurrently. 6.001 Notes: Section 32.3 Slide 32.3.1 Serializers provide a powerful abstraction that helps isolate the complexities of concurrent programs so that they can be dealt with carefully and (hopefully) correctly. However, while using serializers is relatively straightforward when there is only a single shared resource (such as a single bank account), concurrent programming can be treacherously difficult when there are multiple shared resources. To see some of the difficulties that can arise, suppose we wish to swap the balances in two bank accounts. We access each account to find the balance, compute the difference between the balances, withdraw this difference from one account, and deposit it in the other account. We could implement this with the code shown on the slide. Slide 32.3.2 This procedure works well when only a single process is trying to do the exchange. Suppose, however, that Peter and Paul both have access to accounts a1, a2, and a3, and that Peter exchanges a1 and a2 while Paul concurrently exchanges a1 and a3. Even with account deposits and withdrawals serialized for individual accounts (as in the make-account procedure shown above), exchange can still produce incorrect results. For example, Peter might compute the difference in the balances for a1 and a2, but then Paul might change the balance in a1 before Peter is able to complete the exchange. In more specific detail, the stages of the computation of the two exchanges are shown. We know by serialization that steps 2 and 5 must each complete in entirety before the other can begin. However, it is still possible for the sequence of steps shown on the right to take place, resulting in an incorrect behavior (the total amount of money is preserved but we intended to simply swap amounts between the accounts, meaning there should be 100, 200 and 300 dollars in the accounts)