3.38-3.42

[sns...@gmail.com]

Exercise 3.38
a. To list the possible values, I'll map the possible orders of
execution:

[peter, paul, mary] -> 45
[peter, mary, paul] -> 35
[mary, peter, paul] -> 40
[mary, paul, peter] -> 40
[paul, peter, mary] -> 45
[paul, mary, peter] -> 50
It is interesting to notice here that order between commutative
operations (Peter and Paul) doesn't matter. The relative order of Mary
does matter, however.

b. Consider one option: Peter's code runs first, fetches the balance
of 100 and adds 10 to it, but doesn't get the chance to store it back
before a task switch. Then comes a task switch and Paul's code runs
fully, setting the balance to 80. Peter's code then comes back and
stores the 110 it has computed to balance (thus completely hiding
Paul's operation). Mary's code then sets balance to 55.

Exercise 3.39
Note that this is not a full serialization of the computations. The
second computation can still interfere between the computation and
assignment of the first. Therefore, the possible results are:

101: P1 completes, then P2 completes
100: P1 computes (* x x), then P2 completes (and sets x to 101), then
P1 executes the assignment.
121: P2 completes, then P1 completes
Exercise 3.40
Now we have a full serialization, and the only thing that can differ
between two executions is the order in the execution of P1 and P2.
However, since the operations P1 and P2 are commutative, the same
result will be produced in both cases: 1,000,000

Exercise 3.41
Since both withdraw and deposit make a single modification to the
balance, I can't see how accessing it can result in anomalous
behavior. Depending on the order of execution of the access relatively
to withdraw, one can either see the old or the new value - but this is
allowed, since the value is consistent with reality.

Perhaps, had withdraw did two assignments to the balance, for whatever
reason, we could hit an intermediate state with an access.

Exercise 3.42
It is a safe change to make, and I can't see any kind of concurrency
allowed by the original solution but not this one.

The reason for this is that the real work of the serializer is done in
the call to protected procedures, and not in their creation. In their
creation the function serialized-p is created and returned, and only
when it's called it waits on the mutex.