<< Previous exercise (3.40) | Index | Next exercise (3.42) >>
No, if you get balance in different order with withdraw and deposit, you will get different result. but all they all legal.
I disagree. I think the answer is yes. Another process could access balance mid-withdraw or mid-deposit and get the wrong info.
It's not wrong info. If a withdraw or deposit isn't finished, then the original balance is still valid. Accessing balance is a single operation, it cannot be interleaved with other procedures. Therefore, we don't need to protect it.
I believe the book uses these two requirements on concurrency:
An "unprotected" access to balance fulfills both requirements so I would say it does not really matter.
serializing balance is not necessary because getting the balance *doesn't change the state of the account*. Even if you serialize the balance accessor, a parallel execution of a series of withdraw!'s deposit!'s and balance's will still occur in an undefined order. Hence, any ambiguities that would occur when the balance accessor is *not* serialized would still occur if it *is* serialized.
When balance is not serialized, then calls to balance may interleave into a call to withdraw! or deposit!. However, since there is only one call to set! in each of these functions, balance will still either get only the "before" or "after" values of the balance, and not some "intermediate" value that is neither the value before or after the withdraw! or deposit!
Hence, whether we serialize the balance accessor or not, we will always get the same results.