110 lines
3.2 KiB
Scheme
110 lines
3.2 KiB
Scheme
(display "\nex-3.38\n")
|
|
(display "[answered]\n")
|
|
|
|
; Peter Paul Mary
|
|
; 110 90 45
|
|
|
|
; Peter Mary Paul
|
|
; 110 55 35
|
|
|
|
; Mary Peter Paul
|
|
; 50 60 40
|
|
|
|
; Mary Paul Peter
|
|
; 50 30 40
|
|
|
|
; Paul Mary Peter
|
|
; 80 40 50
|
|
|
|
; Paul Peter Mary
|
|
; 80 90 45
|
|
|
|
(display "\nex-3.39\n")
|
|
(display "[answered]\n")
|
|
|
|
; (define x 10)
|
|
; (define s (make-serializer))
|
|
; (parallel-execute (lambda () (set! x ((s (lambda () (* x x))))))
|
|
; (s (lambda () (set! x (+ x 1)))))
|
|
|
|
; 101: P1 sets x to 100 and then P2 increments x to 101.
|
|
; 121: P2 increments x to 11 and then P1 sets x to x times x.
|
|
; 100: P1 accesses x (twice), then P2 sets x to 11, then P1 sets x.
|
|
; 11: P2 accesses x, then P1 sets x to 100, then P2 sets x.
|
|
|
|
; My friends on Scheme-Wiki agree with this solution so I feel good about this.
|
|
|
|
(display "\nex-3.40\n")
|
|
(display "[answered]\n")
|
|
|
|
; (define x 10)
|
|
; (parallel-execute (lambda () (set! x (* x x)))
|
|
; (lambda () (set! x (* x x x))))
|
|
|
|
; 10 * 10 = 100
|
|
; 10 * 10 * 10 = 1'000
|
|
; 10 * 1000 = 10'000
|
|
; 10 * 10 * 100 = 10'000
|
|
; 10 * 100 * 100 = 100'000
|
|
; 10^6 = 1'000'000
|
|
|
|
; (define x 10)
|
|
; (define s (make-serializer))
|
|
; (parallel-execute (s (lambda () (set! x (* x x))))
|
|
; (s (lambda () (set! x (* x x x)))))
|
|
|
|
; 10^2 = 100 -> 100^3 = 1000000
|
|
; 10^3 = 1000 -> 1000^2 = 1000000
|
|
|
|
(display "\nex-3.41\n")
|
|
(display "[answered]\n")
|
|
|
|
; Ben's concern does not apply. Say, we have a withdraw and a balance check.
|
|
; Depending on the order of execution the balance check would show the balance
|
|
; before or after the withdraw. This behavior is expected and would not be
|
|
; avoided by serializing balance.
|
|
|
|
(display "\nex-3.42\n")
|
|
(display "[answered]\n")
|
|
|
|
; This should work without issues in all cases. I don't have a good mental
|
|
; model of how the serializer works, yet.
|
|
|
|
(display "\nex-3.43\n")
|
|
(display "[answered]\n")
|
|
|
|
; A swap of account balances maintains each individual balance. Hence, only the
|
|
; order of $10, $20, $30 can change and not the value.
|
|
|
|
; a b c
|
|
; $10 $20 $30 (swap a b = 10) (swap a c = 20)
|
|
; $20 $10 $30
|
|
; $40 $10 $10
|
|
|
|
; The sum of balances will be preserved because the exchange procedure deposits
|
|
; what it withdraws. That works because it calculates `difference` before doing
|
|
; the transactions.
|
|
|
|
; If the individual transactions would not be serialized we could run into a
|
|
; situation where (swap a c) overrides a to be $30, for example, as we have
|
|
; seen in previous exercises.
|
|
|
|
(display "\nex-3.44\n")
|
|
(display "[answered]\n")
|
|
|
|
; Louis Reasoner is wrong. Assuming the balance on from-account is high enough
|
|
; transfer is going to work. The essential difference is that executing a list
|
|
; of transactions of absolute amounts is commutative. Exchange, on the other,
|
|
; is not commutative. On exchange has to finish before another one and the
|
|
; order matters.
|
|
|
|
(display "\nex-3.45\n")
|
|
(display "[answered]\n")
|
|
|
|
; When serialized-exchange is call it tries to serialize the deposit and
|
|
; withdraw calls that are already serialized by the same serializer. That would
|
|
; result in a deadlock because because the outer serialized procedure would
|
|
; have to call the inner serialized procedure and they cannot be executed at
|
|
; the same time because they are serialized by the same serializer.
|
|
|